draft-ietf-sasl-gs2-06.txt		draft-ietf-sasl-gs2-07.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Intended status: Standards Track		Intended status: Standards Track
	Expires: August 10, 2007		Expires: September 1, 2007
	Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family		Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	draft-ietf-sasl-gs2-06		draft-ietf-sasl-gs2-07
	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 August 10, 2007.		This Internet-Draft will expire on September 1, 2007.
	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 6, line 12		skipping to change at page 6, line 12
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [1].		document are to be interpreted as described in [1].
	3. Mechanism name		3. Mechanism name
	3.1. Generating SASL mechanism names from GSS-API OIDs		3.1. Generating SASL mechanism names from GSS-API OIDs
	The SASL mechanism name for a GSS-API mechanism is the concatenation		The SASL mechanism name for a GSS-API mechanism is the concatenation
	of the string "GS2-" and the Base32 encoding [6] (with an upper case		of the string "GS2-" and the Base32 encoding [6] (with an upper case
	alphabet) of the first ten bytes of the binary SHA-1 hash [4] string		alphabet) of the first ten bytes of the binary SHA-1 hash [4] string
	computed over the ASN.1 DER encoding [8], including the tag and		computed over the ASN.1 DER encoding [7], including the tag and
	length octets, of the GSS-API mechanism's Object Identifier. The		length octets, of the GSS-API mechanism's Object Identifier. The
	Base32 rules on padding characters and characters outside of the		Base32 rules on padding characters and characters outside of the
	base32 alphabet are not relevant to this use of Base32. If any		base32 alphabet are not relevant to this use of Base32. If any
	padding or non-alphabet characters are encountered, the name is not a		padding or non-alphabet characters are encountered, the name is not a
	GS2 family mechanism name.		GS2 family mechanism name.
	3.2. Computing mechanism names manually		3.2. Computing mechanism names manually
	The SASL mechanism name may be computed manually. This is useful		The SASL mechanism name may be computed manually. This is useful
	when the set of supported GSS-API mechanisms is known in advance. It		when the set of supported GSS-API mechanisms is known in advance. It
	skipping to change at page 15, line 28		skipping to change at page 15, line 28
	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.
	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 [7].		channel binding data for various security protocols, see [8]. For
			easy reference, the channel binding format used for The Transport
			Layer Security (TLS) Protocol [14] is specified in [16].
	6. Protocol Overview		6. Protocol Overview
	This section describe several high-level protocol exchanges. The		This section describe several high-level protocol exchanges. The
	descriptions do not assume any properties of the actual GSS-API		descriptions do not assume any properties of the actual GSS-API
	mechanism. Protocol profiles, GSS-API mechanism specific behaviour,		mechanism. Protocol profiles, GSS-API mechanism specific behaviour,
	and to some extent implementation and policy choices, will dictate		and to some extent implementation and policy choices, will dictate
	which packets are sent in what order. The protocol exchanges are		which packets are sent in what order. The protocol exchanges are
	examples and other exchanges are permitted and will occur.		examples and other exchanges are permitted and will occur.
	skipping to change at page 25, line 27		skipping to change at page 25, line 27
	11.2. Resolving the problem		11.2. Resolving the problem
	If the Kerberos V5 mechanism is supported under GS2 in a server, the		If the Kerberos V5 mechanism is supported under GS2 in a server, the
	server SHOULD also support Kerberos V5 through the "GSSAPI"		server SHOULD also support Kerberos V5 through the "GSSAPI"
	mechanism, to avoid interoperability problems with older clients.		mechanism, to avoid interoperability problems with older clients.
	Reasons for violating this recommendation may include security		Reasons for violating this recommendation may include security
	considerations regarding the absent features in the GS2 mechanism.		considerations regarding the absent features in the GS2 mechanism.
	The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which		The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
	could enable certain tunnel attacks [17].		could enable certain tunnel attacks [18].
	11.3. Additional recommendations		11.3. Additional recommendations
	It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism		It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism
	rather than through the "GSSAPI" mechanism, if both are available,		rather than through the "GSSAPI" mechanism, if both are available,
	because of the additional features in the GS2 mechanism.		because of the additional features in the GS2 mechanism.
	12. Mechanisms that negotiate other mechanisms		12. Mechanisms that negotiate other mechanisms
	A GSS-API mechanism that negotiate other mechanisms interact badly		A GSS-API mechanism that negotiate other mechanisms interact badly
	skipping to change at page 26, line 36		skipping to change at page 26, line 36
	when it ideally should have used mechanism Y. For this reason, the		when it ideally should have used mechanism Y. For this reason, the
	use of GSS-API mechanisms that negotiate other mechanisms are		use of GSS-API mechanisms that negotiate other mechanisms are
	disallowed under GS2.		disallowed under GS2.
	12.3. Resolving the problems		12.3. Resolving the problems
	GSS-API mechanisms that negotiate other mechanisms MUST NOT be used		GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
	with the GS2 SASL mechanism. This specifically exclude negotiating		with the GS2 SASL mechanism. This specifically exclude negotiating
	SPNEGO [11] under GS2.		SPNEGO [11] under GS2.
	The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [16]		The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [17]
	can be used to identify such mechanisms.		can be used to identify such mechanisms.
	13. IANA Considerations		13. IANA Considerations
	The IANA is advised that SASL mechanism names starting with "GS2-"		The IANA is advised that SASL mechanism names starting with "GS2-"
	are reserved for SASL mechanisms which conform to this document. The		are reserved for SASL mechanisms which conform to this document. The
	IANA is directed to place a statement to that effect in the sasl-		IANA is directed to place a statement to that effect in the sasl-
	mechanisms registry.		mechanisms registry.
	Subject: Registration of SASL mechanism GS2-*		Subject: Registration of SASL mechanism GS2-*
	skipping to change at page 28, line 7		skipping to change at page 28, line 7
	Security considerations: RFC [THIS-DOC]		Security considerations: RFC [THIS-DOC]
	Published specification: RFC [THIS-DOC]		Published specification: RFC [THIS-DOC]
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Simon Josefsson <simon@josefsson.org>		Simon Josefsson <simon@josefsson.org>
	Intended usage: COMMON		Intended usage: COMMON
	Owner/Change controller: iesg@ietf.org		Owner/Change controller: iesg@ietf.org
	Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.		Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
	14. Security Considerations		14. Security Considerations
	Security issues are discussed throughout this memo.
	The security provided by GS2 depends on the security provided by the		The security provided by GS2 depends on the security provided by the
	GSS-API mechanism. If the mechanism do not provide integrity		GSS-API mechanism. If the mechanism do not provide integrity
	protection, the authorization identity can be replaced by a man in		protection, the authorization identity can be replaced by a man in
	the middle, and channel bindings and security layers cannot be		the middle, and channel bindings and security layers cannot be
	negotiated. Therefor, it is generally recommended against using any		negotiated. Therefor, it is generally recommended against using any
	GSS-API mechanism widely on the Internet that do not support		GSS-API mechanism widely on the Internet that do not support
	integrity.		integrity.
	Because the negotiation of a GSS-API mechanism may be done in the		Because the negotiation of a particular GSS-API mechanism may be done
	clear, it is important for the GSS-API mechanisms to be designed such		in the clear, it is important for the GSS-API mechanisms to be
	that an active attacker cannot obtain an authentication with weaker		designed such that an active attacker cannot obtain an authentication
	security properties by modifying the challenges and responses.		with weaker security properties by modifying the challenges and
			responses. This is a generic design critera for the GSS-API
			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. There are several ways to mitigate this problem:
	1. Integrity protected transports can be used, e.g., TLS [14]. To		1. Integrity protected transports can be used, e.g., TLS [14]. To
	protect against certain tunnel attacks [17] with that solution,		protect against certain tunnel attacks [18], the GSS-API
	the GSS-API mechanisms has to support integrity to provide		mechanism need to support integrity to provide support for
	support for channel bindings		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.		supported mechanism. This solution, however, is not guaranteed
			to the lead to the mutually most secure mechanism, and is
			therefor only recommended as an additional precaution.
	3. Specify how to use the SPNEGO mechanism in SASL.		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].
	GS2 hard code the use of the SHA-1 algorithm to compute the mechanism		The GS2 protocol hard code the SHA-1 algorithm for computing the
	names, and it is not possible to negotiate the use of other hash		mechanism names. It is not possible to negotiate another hash
	algorithms. However, no traditional cryptographic hash properties		algorithm. However, no traditional cryptographic hash properties
	(such as collision resistance or pre-image resistance) are required		(such as collision resistance or pre-image resistance) are required
	nor assumed. The required and assumed property is that it is		nor assumed. The required and assumed property is that it is
	statistically unlikely that two different DER-encoded OID's share the		statistically unlikely that two different DER-encoded OID's share the
	same first 10 octets of the SHA-1 value.		same first 10 octets of the SHA-1 value. It is possible to
			practically confirm that the SHA-1 algorithm has the necessary
			property, by testing many different inputs.
	Additional security considerations are in the SASL and GSSAPI		Additional security considerations are in the SASL and GSSAPI
	specifications. Additional security considerations for the Kerberos		specifications. Additional security considerations for the Kerberos
	V5 GSSAPI mechanism can be found in [10]. We stress that service		V5 GSSAPI mechanism can be found in [10]. We stress that service
	names should not be canonicalized using an unsecured directory		names should not be canonicalized using an unsecured directory
	service such as the DNS without DNSSEC.		service such as the DNS without DNSSEC. Security issues are also
			discussed throughout this memo.
	15. Acknowledgements		15. Acknowledgements
	This document is a revision of RFC 2222. This version was derived		The history of GS2 can be traced to the GSSAPI mechanism described in
	from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov		RFC 2222. The GSSAPI mechanism had some drawbacks, which created a
	with significant contributions from John G. Myers, although the		need for an improved version. This document was derived from
	majority of this document has been rewritten by the current author.		draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
			significant contributions from John G. Myers, although the majority
			of this document has been rewritten by the current author.
	Contributions of many members of the SASL mailing list are gratefully		Contributions of many members of the SASL mailing list are gratefully
	acknowledged. In particular, ideas and feedback from Sam Hartman,		acknowledged. In particular, ideas and feedback from Sam Hartman,
	Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu		Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu
	improved the document and the protocol.		improved the document and the protocol.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Melnikov, A. and K. Zeilenga, "Simple Authentication and		[2] Melnikov, A. and K. Zeilenga, "Simple Authentication and
	Security Layer (SASL)", RFC 4422, June 2006.		Security Layer (SASL)", RFC 4422, June 2006.
	[3] Linn, J., "Generic Security Service Application Program		[3] Linn, J., "Generic Security Service Application Program
	Interface Version 2, Update 1", RFC 2743, January 2000.		Interface Version 2, Update 1", RFC 2743, January 2000.
	[4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",		[4] National Institute of Standards and Technology, "Secure Hash
	RFC 3174, September 2001.		Standard", FIPS PUB 180-1, April 1995,
			<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
	[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646",		[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
	STD 63, RFC 3629, November 2003.		STD 63, RFC 3629, November 2003.
	[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] Williams, N., "On the Use of Channel Bindings to Secure		[7] International Telecommunications Union, "Information Technology
	Channels", draft-ietf-nfsv4-channel-bindings-04 (work in		- ASN.1 encoding rules: Specification of Basic Encoding Rules
	progress), June 2006.		(BER), Canonical Encoding Rules (CER) and Distinguished
			Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.
	[8] International Organization for Standardization, "Information		[8] Williams, N., "On the Use of Channel Bindings to Secure
	Processing Systems - Open Systems Interconnection -		Channels", draft-williams-on-channel-binding-00 (work in
	Specification of Abstract Syntax Notation One (ASN.1)",		progress), August 2006.
	ISO Standard 8824, December 1990.
	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 13		skipping to change at page 32, line 15
	[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",		[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
	RFC 2025, October 1996.		RFC 2025, October 1996.
	[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)		[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
	Protocol Version 1.1", RFC 4346, April 2006.		Protocol Version 1.1", RFC 4346, April 2006.
	[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] Williams, N., "Extended Generic Security Service Mechanism		[16] Altman, J. and N. Williams, "On the Use of Channel Bindings to
			Secure Channels", draft-altman-tls-channel-bindings-01 (work in
			progress), December 2006.
			[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-01 (work
	in progress), October 2005.		in progress), October 2005.
	[17] 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
	Full Copyright Statement		Full Copyright Statement
End of changes. 20 change blocks.
	37 lines changed or deleted		51 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/