draft-ietf-sasl-gs2-19.txt		draft-ietf-sasl-gs2-20.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Intended status: Standards Track N. Williams		Intended status: Standards Track N. Williams
	Expires: July 12, 2010 Sun Microsystems		Expires: July 13, 2010 Sun Microsystems
	January 8, 2010		January 9, 2010
	Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family		Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	draft-ietf-sasl-gs2-19		draft-ietf-sasl-gs2-20
	Abstract		Abstract
	This document describes how to use a Generic Security Service		This document describes how to use a Generic Security Service
	Application Program Interface (GSS-API) mechanism in the the Simple		Application Program Interface (GSS-API) mechanism in the the Simple
	Authentication and Security Layer (SASL) framework. This is done by		Authentication and Security Layer (SASL) framework. This is done by
	defining a new SASL mechanism family, called GS2. This mechanism		defining a new SASL mechanism family, called GS2. This mechanism
	family offers a number of improvements over the previous "SASL/		family offers a number of improvements over the previous "SASL/
	GSSAPI" mechanism: it is more general, uses fewer messages for the		GSSAPI" mechanism: it is more general, uses fewer messages for the
	authentication phase in some cases, and supports negotiable use of		authentication phase in some cases, and supports negotiable use of
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 12, 2010.		This Internet-Draft will expire on July 13, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 11, line 5		skipping to change at page 11, line 5
	GSS_Init_sec_context as described below.		GSS_Init_sec_context as described below.
	o Upon receipt of the initial authentication message the server		o Upon receipt of the initial authentication message the server
	checks the gs2-cb-flag in the GS2 header and constructs a		checks the gs2-cb-flag in the GS2 header and constructs a
	chan_bindings parameter for GSS_Accept_sec_context as described		chan_bindings parameter for GSS_Accept_sec_context as described
	below. If the client channel binding flag was "y" and the server		below. If the client channel binding flag was "y" and the server
	did advertise support for channel bindings then the server MUST		did advertise support for channel bindings then the server MUST
	fail authentication. If the client channel binding flag was "p"		fail authentication. If the client channel binding flag was "p"
	and the server does not support the indicated channel binding type		and the server does not support the indicated channel binding type
	then the server MUST fail authentication.		then the server MUST fail authentication.
	FLAG SERVER CB SUPPORT DISPOSITION		FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION
	---- ----------------- -----------		---- ----------------- ----------------- -----------
	n Irrelevant If server disallows non-channel-		n no support N/A If server disallows
	bound authentication, then fail		non-channel-bound
			authentication, then
			fail
	y CB not supported Authentication may succeed		y Yes, not required No Authentication may
			succeed; CB not used
	y CB supported Authentication must fail		y Yes, not required Yes Authentication must fail
	p CB supported Authentication may succeed, with		p Yes Yes Authentication may
	CB used		succeed, with CB used
	p CB not supported Authentication will fail		p Yes No Authentication will fail
	<none> CB not supported Client does not even try because		N/A Yes, required No Client does not even try
	it insists on CB
	For more discussions of channel bindings, and the syntax of the		For more discussions of channel bindings, and the syntax of the
	channel binding data for various security protocols, see [RFC5056].		channel binding data for various security protocols, see [RFC5056].
	5.1. Content of GSS-CHANNEL-BINDINGS structure		5.1. Content of GSS-CHANNEL-BINDINGS structure
	The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a		The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a
	chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS		chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS
	structure [RFC5554].		structure [RFC5554].
End of changes. 10 change blocks.
	15 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/