draft-ietf-sasl-gs2-08.txt		draft-ietf-sasl-gs2-09.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 30, 2007		Expires: April 11, 2008
	Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family		Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	draft-ietf-sasl-gs2-08		draft-ietf-sasl-gs2-09
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 September 30, 2007.		This Internet-Draft will expire on April 11, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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
	skipping to change at page 3, line 22		skipping to change at page 3, line 22
	3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. SASL Authentication Exchange Message Format . . . . . . . . . 8		4. SASL Authentication Exchange Message Format . . . . . . . . . 8
	4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 8		4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 9		4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 9		4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 10		4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11		4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11
	4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12		4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12
	4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12		4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12
	4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13		4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13
	4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 13		4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 14
	4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14		4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14
	5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15		5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15
	6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16		6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16
	7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20		7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20
	8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21		8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21
	9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22		9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22
	9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22		9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24		10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24
	11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25		11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25
	11.1. The interoperability problem . . . . . . . . . . . . . . . 25		11.1. The interoperability problem . . . . . . . . . . . . . . . 25
	skipping to change at page 8, line 45		skipping to change at page 8, line 45
	The "Context token" field, if present, contain a GSS-API context		The "Context token" field, if present, contain a GSS-API context
	establishment token generated by GSS_Init_sec_context or		establishment token generated by GSS_Init_sec_context or
	GSS_Accept_sec_context.		GSS_Accept_sec_context.
	The "Wrap token" field, if present, contain the output generated by		The "Wrap token" field, if present, contain the output generated by
	the GS2_Wrap function.		the GS2_Wrap function.
	The fields need not be aligned to 32-bit a boundary. There is no		The fields need not be aligned to 32-bit a boundary. There is no
	padding between fields.		padding between fields.
	Messages shorter than or equal to 8 octets are invalid. From that it		Messages shorter than or equal to 8 octets are invalid. (The only
	follows that at least one of the "Context token length" and the "Wrap		exception is the initial empty challenge sent by the server which may
	token length" integers MUST be non-zero in a particular message. If		be 0 octets.) From that it follows that at least one of the "Context
	the sum of the length integers is longer than the entire message		token length" and the "Wrap token length" integers MUST be non-zero
	size, minus 8 octets for the length fields, the message is invalid.		in a particular message. If the sum of the length integers is longer
			than the entire message size, minus 8 octets for the length fields,
			the message is invalid.
	During any successful authentication exchange, the client and server		During any successful authentication exchange, the client and server
	will each send exactly one (non-empty) "Wrap token".		will each send exactly one (non-empty) "Wrap token".
	Conforming implementations MUST NOT send additional data after the		Conforming implementations MUST NOT send additional data after the
	above message syntax, and MUST ignore additional data. To		above message syntax, and MUST ignore additional data. To
	illustrate, implementations MUST NOT assume that the last "Wrap token		illustrate, implementations MUST NOT assume that the last "Wrap token
	length" octets of the packet correspond to the "Wrap token", because		length" octets of the packet correspond to the "Wrap token", because
	that would be incorrect if the packet contained additional data not		that would be incorrect if the packet contained additional data not
	described by this document.		described by this document.
	skipping to change at page 15, line 22		skipping to change at page 15, line 22
	channel bindings do not match.		channel bindings do not match.
	Client and servers MUST set the "chan_binding" parameter in the calls		Client and servers MUST set the "chan_binding" parameter in the calls
	to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to		to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to
	NULL.		NULL.
	Implementations SHOULD set the "client_cbqops" and "server_cbqops" to		Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
	no security layer and instead depend on the session security afforded		no security layer and instead depend on the session security afforded
	by the bound-in channel.		by the bound-in channel.
			In order to accomodate the requirement in [16] "Authentication
			frameworks and mechanisms that support channel binding MUST
			communicate channel binding failure to applications" implementations
			MUST provide a way to communicate channel binding failures to
			applications.
	Use of no SASL security layers in combination with channel binding		Use of no SASL security layers in combination with channel binding
	should provide better performance than using SASL security layers		should provide better performance than using SASL security layers
	over secure channels, and better security characteristics than using		over secure channels, and better security characteristics than using
	no SASL security layers over secure channels without channel binding.		no SASL security layers over secure channels without channel binding.
	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 [8]. For		channel binding data for various security protocols, see [8]. For
	easy reference, the channel binding format used for The Transport		easy reference, the channel binding format used for The Transport
	Layer Security (TLS) Protocol [14] is specified in [16].		Layer Security (TLS) Protocol [14] is specified in [16].
	skipping to change at page 16, line 25		skipping to change at page 16, line 25
	below. GS2_Wrap refer to the operation of calling GS2_Wrap on the		below. GS2_Wrap refer to the operation of calling GS2_Wrap on the
	indicated fields, formatted in the structures described earlier.		indicated fields, formatted in the structures described earlier.
	GSS_Init_sec_context and GSS_Accept_sec_context refer to the context		GSS_Init_sec_context and GSS_Accept_sec_context refer to the context
	token generated by calling the respective function. The GS2 SASL		token generated by calling the respective function. The GS2 SASL
	Message is denoted as [Context_token, Wrap_token], and the length		Message is denoted as [Context_token, Wrap_token], and the length
	fields are not mentioned.		fields are not mentioned.
	An authentication exchange using GS2 may look like:		An authentication exchange using GS2 may look like:
	C: Request authentication exchange		C: Request authentication exchange
	S: Send ["", ""] token		S: Empty Challenge
	C: Send [GSS_Init_sec_context, ""] token		C: Send [GSS_Init_sec_context, ""] token
	...		...
	S: After PROT_READY is set,		S: After PROT_READY is set,
	send [GSS_Accept_sec_context,		send [GSS_Accept_sec_context,
	GS2_Wrap(server_qops | server_maxbuf]		GS2_Wrap(server_qops | server_maxbuf]
	...		...
	C: After PROT_READY is set,		C: After PROT_READY is set,
	send [GSS_Init_sec_context,		send [GSS_Init_sec_context,
	GS2_Wrap (client_qop | client_maxbuf | authzid)]		GS2_Wrap (client_qop | client_maxbuf | authzid)]
	S: Send [GSS_Accept_sec_context, ""] token		S: Send [GSS_Accept_sec_context, ""] token
	C: Send [GSS_Init_sec_context, ""] token		C: Send [GSS_Init_sec_context, ""] token
	...		...
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	Because GSS-API authentication is initiated by the client, the length		GSS-API authentication is always initiated by the client. The SASL
	field will be 0 in the initial token from the server to the client		framework allows either the client and server to initiate
	when the protocol profile does not support additional information to		authentication. In GS2 the server will send an initial empty
	be sent together with the authentication request.		challenge (zero byte string) if it has not yet received a token from
			the client. See section 3 of [2].
	The next example illustrate when the client sends its Wrap token		The next example illustrate when the client sends its Wrap token
	first.		first.
	C: Request authentication exchange		C: Request authentication exchange
	S: Send ["", ""] token		S: Empty Challenge
	C: Send [GSS_Init_sec_context, ""] token		C: Send [GSS_Init_sec_context, ""] token
	...		...
	C: After PROT_READY is set,		C: After PROT_READY is set,
	send [GSS_Init_sec_context,		send [GSS_Init_sec_context,
	GS2_Wrap(client_qops | client_maxbuf |		GS2_Wrap(client_qops | client_maxbuf |
	channel_binding_length=0 | authzid)]		channel_binding_length=0 | authzid)]
	...		...
	S: After PROT_READY is set,		S: After PROT_READY is set,
	send [GSS_Accept_sec_context,		send [GSS_Accept_sec_context,
	GS2_Wrap (server_qop | server_maxbuf)]		GS2_Wrap (server_qop | server_maxbuf)]
	skipping to change at page 20, line 10		skipping to change at page 20, line 10
	as additional information.		as additional information.
	The last example illustrate the optimal (round-trip wise)		The last example illustrate the optimal (round-trip wise)
	authentication possible using this protocol.		authentication possible using this protocol.
	7. Authentication Conditions		7. Authentication Conditions
	Authentication MUST NOT succeed if any one of the following		Authentication MUST NOT succeed if any one of the following
	conditions are true:		conditions are true:
	o An invalid SASL token is received (i.e., length shorter than 4		o An invalid SASL token is received (e.g., length field checks
	octets).		discussed in section 4.1 fail).
	o GSS_Init/Accept_sec_context() return anything other than		o GSS_Init/Accept_sec_context() return anything other than
	GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.		GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
	o GSS_Wrap() returns anything other than GSS_S_COMPLETE.		o GSS_Wrap() returns anything other than GSS_S_COMPLETE.
	o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There		o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There
	can't be supplementary status codes in GS2 at this point, so any		can't be supplementary status codes in GS2 at this point, so any
	indications of out of order processing or replays is fatal.)		indications of out of order processing or replays is fatal.)
	skipping to change at page 28, line 25		skipping to change at page 28, line 25
	Because the negotiation of a particular GSS-API mechanism may be done		Because the negotiation of a particular GSS-API mechanism may be done
	in the clear, it is important for the GSS-API mechanisms to be		in the clear, it is important for the GSS-API mechanisms to be
	designed such that an active attacker cannot obtain an authentication		designed such that an active attacker cannot obtain an authentication
	with weaker security properties by modifying the challenges and		with weaker security properties by modifying the challenges and
	responses. This is a generic design critera for the GSS-API		responses. This is a generic design critera for the GSS-API
	mechanisms used under GS2.		mechanisms used under GS2.
	When a server or client supports multiple GSS-API mechanisms, each of		When a server or client supports multiple GSS-API mechanisms, each of
	which has a different security strength, it is possible for an active		which has a different security strength, it is possible for an active
	attacker to cause a party to use the least secure mechanism		attacker to cause a party to use the least secure mechanism
	supported. There are several ways to mitigate this problem:		supported. This problem and a solution is discussed in section 6.1.2
			of [2], but some additional methods to mitigate the problem include:
	1. Integrity protected transports can be used, e.g., TLS [14]. To		1. Use of an integrity protected transport, such as TLS [14]. To
	protect against certain tunnel attacks [18], the GSS-API		protect against certain tunnel attacks [18], channel bindings
	mechanism need to support integrity to provide support for		need to be used.
	channel bindings.
	2. A client or server which supports mechanisms of different		2. A client or server which supports mechanisms of different
	strengths should have a configurable minimum strength that it		strengths should have a configurable minimum strength that it
	will use. It is not sufficient for this minimum strength check		will use. It is not sufficient for this minimum strength check
	to only be on the server, since an active attacker can change		to only be on the server, since an active attacker can change
	which mechanisms the client sees as being supported, causing the		which mechanisms the client sees as being supported, causing the
	client to send authentication credentials for its weakest		client to send authentication credentials for its weakest
	supported mechanism. This solution, however, is not guaranteed		supported mechanism. This solution, however, is not guaranteed
	to lead to the most secure mechanism supported by both parties,		to lead to the most secure mechanism supported by both parties,
	and is therefor only recommended as an additional precaution.		and is therefor only recommended as an additional precaution.
	3. Specify how to use the SPNEGO mechanism in SASL.
	The channel binding is sent without privacy protection and knowledge		The channel binding is sent without privacy protection and knowledge
	of it is assumed to provide no advantage to an attacker. This is a		of it is assumed to provide no advantage to an attacker. This is a
	property that has to be considered when specifying channel bindings		property that has to be considered when specifying channel bindings
	for a security protocol that will be used with GS2.		for a security protocol that will be used with GS2.
	When constructing the input_name_string, the client should not		When constructing the input_name_string, the client should not
	canonicalize the server's fully qualified domain name using an		canonicalize the server's fully qualified domain name using an
	insecure or untrusted directory service, such as the Domain Name		insecure or untrusted directory service, such as the Domain Name
	System [9] without DNSSEC [15].		System [9] without DNSSEC [15].
	skipping to change at page 31, line 34		skipping to change at page 31, line 34
	[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",		[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
	RFC 4648, October 2006.		RFC 4648, October 2006.
	[7] International Telecommunications Union, "Information Technology		[7] International Telecommunications Union, "Information Technology
	- ASN.1 encoding rules: Specification of Basic Encoding Rules		- ASN.1 encoding rules: Specification of Basic Encoding Rules
	(BER), Canonical Encoding Rules (CER) and Distinguished		(BER), Canonical Encoding Rules (CER) and Distinguished
	Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.		Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.
	[8] Williams, N., "On the Use of Channel Bindings to Secure		[8] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", draft-williams-on-channel-binding-00 (work in		Channels", draft-williams-on-channel-binding-04 (work in
	progress), August 2006.		progress), August 2007.
	16.2. Informative References		16.2. Informative References
	[9] Mockapetris, P., "Domain names - concepts and facilities",		[9] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,		[10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
	June 1996.		June 1996.
	[11] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The		[11] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
	skipping to change at page 32, line 20		skipping to change at page 32, line 20
	[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	"DNS Security Introduction and Requirements", RFC 4033,		"DNS Security Introduction and Requirements", RFC 4033,
	March 2005.		March 2005.
	[16] Altman, J. and N. Williams, "On the Use of Channel Bindings to		[16] Altman, J. and N. Williams, "On the Use of Channel Bindings to
	Secure Channels", draft-altman-tls-channel-bindings-01 (work in		Secure Channels", draft-altman-tls-channel-bindings-01 (work in
	progress), December 2006.		progress), December 2006.
	[17] Williams, N., "Extended Generic Security Service Mechanism		[17] Williams, N., "Extended Generic Security Service Mechanism
	Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work		Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-02 (work
	in progress), October 2005.		in progress), June 2006.
	[18] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in		[18] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in
	Tunneled Authentication",		Tunneled Authentication",
	WWW http://www.saunalahti.fi/~asokan/research/mitm.html.		WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
	Author's Address		Author's Address
	Simon Josefsson		Simon Josefsson
	Email: simon@josefsson.org		Email: simon@josefsson.org
End of changes. 15 change blocks.
	28 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/