draft-josefsson-password-auth-00.txt		draft-josefsson-password-auth.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 29, 2007		Expires: June 22, 2008
	A Password-based Authentication Protocol		A Password-based Authentication Protocol
	draft-josefsson-password-auth-00		draft-josefsson-password-auth-01rc
	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 29, 2007.		This Internet-Draft will expire on June 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	There is a lack of a simple, standardized, secure and modern		There is a lack of a simple, standardized, secure and modern
	password-based mechanism for user authentication in application		password-based mechanism for user authentication in application
	protocols. This document specify a challenge/response protocol that		protocols. This document specify a challenge/response protocol that
	provide password-based authentication services. We describe how the		provide password-based authentication services. We describe how the
	protocol may be used as a GSS-API mechanism and, using the GS2		protocol may be used as a GSS-API mechanism. Via the GS2 framework,
	framework, how it may be used as a SASL mechanism. The protocol		it can also be used as a SASL mechanism. The protocol supports HMAC-
	supports HMAC-SHA-256 as the mandatory to implement algorithm, and it		SHA-256 as the mandatory to implement algorithm, and it supports
	supports channel bindings. The intended use is by application		channel bindings. The intended use is by application protocol that
	protocol that today use CRAM-MD5 or DIGEST-MD5 via SASL, or by GSS-		today use CRAM-MD5 or DIGEST-MD5 via SASL, or by GSS-API applications
	API applications that needs a password based method. The protocol is		that needs a password based method. The protocol is applicable to
	applicable to other environments, such as EAP, should the need arise.		other environments, such as EAP, should the need arise.
	See <http://josefsson.org/password/> for more information.		See <http://josefsson.org/password/> for more information.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used in this Document . . . . . . . . . . . . . . 4		2. Conventions Used in this Document . . . . . . . . . . . . . . 4
	3. Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Challenge Token . . . . . . . . . . . . . . . . . . . . . 5		3.1. Challenge Token . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Mandatory to implement algorithm: HMAC-SHA-256 . . . . . . . . 7		4. Mandatory to implement algorithm: HMAC-SHA-256 . . . . . . . . 7
	4.1. HMAC-SHA-256 Challenge . . . . . . . . . . . . . . . . . . 7		4.1. HMAC-SHA-256 Challenge . . . . . . . . . . . . . . . . . . 7
	4.2. HMAC-SHA-256 Response . . . . . . . . . . . . . . . . . . 7		4.2. HMAC-SHA-256 Response . . . . . . . . . . . . . . . . . . 7
	5. Using the protocol with GSS-API . . . . . . . . . . . . . . . 9		5. Using the protocol with GSS-API . . . . . . . . . . . . . . . 9
	5.1. How Applications Specify the Password . . . . . . . . . . 9		5.1. How Applications Specify the Password . . . . . . . . . . 9
	6. Using the protocol with SASL . . . . . . . . . . . . . . . . . 10		6. SASL GS2 Mechanism Name . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 13		9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Introduction		1. Introduction
	skipping to change at page 3, line 22		skipping to change at page 3, line 22
	DIGEST-MD5 or the Kerberos V5 mechanism. Other mechanisms are (to my		DIGEST-MD5 or the Kerberos V5 mechanism. Other mechanisms are (to my
	knowledge) not standardized nor widely deployed.		knowledge) not standardized nor widely deployed.
	A quick overview of some perceived disadvantages with the current		A quick overview of some perceived disadvantages with the current
	options:		options:
	TLS+EXTERN lack support for channel bindings, and TLS-SRP is not		TLS+EXTERN lack support for channel bindings, and TLS-SRP is not
	widely recognized thus leaving TLS without any password based		widely recognized thus leaving TLS without any password based
	authentication mechanism.		authentication mechanism.
	TLS+PLAIN lack support for channel bindings [2], and it transmits the		TLS+PLAIN lack support for channel bindings [4], and it transmits the
	password to the peer, which is considered sub-optimal from a security		password to the peer, which is considered sub-optimal from a security
	perspective.		perspective.
	CRAM-MD5 lack support for channel bindings, authorization identities,		CRAM-MD5 lack support for channel bindings, authorization identities,
	and is based on the deprecated MD5 hash algorithm.		and is based on the deprecated MD5 hash algorithm.
	DIGEST-MD5 is based on the deprecated MD5 hash algorithm, and does		DIGEST-MD5 is based on the deprecated MD5 hash algorithm, and does
	not use HMAC or a similar widely studied hash-based authentication		not use HMAC or a similar widely studied hash-based authentication
	mode.		mode.
	skipping to change at page 5, line 5		skipping to change at page 4, line 11
	Finally, we note that the GSS-API framework currently do not have any		Finally, we note that the GSS-API framework currently do not have any
	password-based standard mechanism, and this document provides one.		password-based standard mechanism, and this document provides one.
	2. Conventions Used in this Document		2. Conventions Used in this Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"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].
			The term "big-endian" is used for brevity to refer to the most-
			significant-octet-first encoding of integers in binary structures.
	3. Wire Protocol		3. Wire Protocol
	This section describes the format of the tokens which are exchanged		This section describes the format of the tokens which are exchanged
	between the client and the server.		between the client and the server.
	The protocol consists of one challenge packet, sent from the server		The protocol consists of one challenge packet, sent from the server
	to the client, and one response packet, send from the client to the		to the client, and one response packet, send from the client to the
	server.		server.
	For compatibility with the GSS-API framework, the challenge is		For compatibility with the GSS-API framework, the challenge is
	prefixed with the mechanism-independent token format, as described by		prefixed with the mechanism-independent token format, as described by
	RFC 2743 section 3.1. This description is self-contained and you		RFC 2743 section 3.1. This description is self-contained and you
	need not implement GSS-API to support this protocol.		need not implement GSS-API to support this protocol.
			The protocol does not specify control messages to signal
			(un)successful authentication to the peer. It is anticipated that
			this protocol will be used in other authentication protocols or
			frameworks that has sufficient signalling capabilities. This is true
			for GSS-API, SASL and EAP. If a need arise to specify control
			messages, the protocol is flexible and allows this do be made inside
			a specific algorithm.
	3.1. Challenge Token		3.1. Challenge Token
	The challenge is sent from the server to the client, and its format		The challenge is sent from the server to the client, and its format
	is illustrated below.		is illustrated below.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x60 | length... /		| 0x60 | length... /
	/ algorithm_identifier /		/ algorithm_identifier /
	skipping to change at page 6, line 4		skipping to change at page 6, line 11
	order) set to "0" and the remaining bits representing the value. If		order) set to "0" and the remaining bits representing the value. If
	the indicated value is 128 or more, it shall be represented in two or		the indicated value is 128 or more, it shall be represented in two or
	more octets, with bit 8 of the first octet set to "1" and the		more octets, with bit 8 of the first octet set to "1" and the
	remaining bits of the first octet specifying the number of additional		remaining bits of the first octet specifying the number of additional
	octets. The subsequent octets carry the value, 8 bits per octet,		octets. The subsequent octets carry the value, 8 bits per octet,
	most significant digit first. The minimum number of octets shall be		most significant digit first. The minimum number of octets shall be
	used to encode the length (i.e., no octets representing leading zeros		used to encode the length (i.e., no octets representing leading zeros
	shall be included within the length encoding).		shall be included within the length encoding).
	[XXX: Add example code to encode/decode DER lengths]		[XXX: Add example code to encode/decode DER lengths]
	The "algorithm_identifier" contains a fixed string that correspond to		The "algorithm_identifier" contains a fixed string that correspond to
	the algorithm which is used. The strings will be DER encoded Object		the algorithm which is used. The strings will be DER encoded Object
	Identifiers (including the DER tag and length) but it is suggested		Identifiers (including the DER tag and length) but it is suggested
	that implementations compare the field against known supported		that implementations compare the field against known supported
	algorithms.		algorithms.
	The "channel_binding_length" is a 4 byte integer encoded in big-		The "channel_binding_length" is a 4 byte integer encoded in big-
	endien order (i.e., most significant byte first) denoting the length		endian order (i.e., most significant byte first) denoting the length
	of the "channel_binding" field.		of the "channel_binding" field.
	The "channel_binding" contains the channel binding data. See [2] for		The "channel_binding" contains the channel binding data. See [4] for
	more information.		more information.
	The "challenge" field contains the challenge data associated with the		The "challenge" field contains the challenge data associated with the
	algorithm indicated by the "algorithm_identifier" field.		algorithm indicated by the "algorithm_identifier" field.
	3.2. Response		3.2. Response
	The response is sent from the client to the server, and its format is		The response is sent from the client to the server, and its format is
	illustrated below.		illustrated below.
	skipping to change at page 7, line 8		skipping to change at page 7, line 8
	/ response /		/ response /
	/ |		/ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The "response" field contains the response for the given challenge.		The "response" field contains the response for the given challenge.
	Its format depends on the "algorithm_identifier" used.		Its format depends on the "algorithm_identifier" used.
	4. Mandatory to implement algorithm: HMAC-SHA-256		4. Mandatory to implement algorithm: HMAC-SHA-256
	Implementations MUST support the HMAC-SHA-256 algorithm. It is based		Implementations MUST support the HMAC-SHA-256 algorithm. It is based
	on HMAC [3] and SHA-256 [4]. The "algorithm_identifier" value for it		on HMAC [2] and SHA-256 [3]. The "algorithm_identifier" value for it
	is:		is:
	algorithm algorithm_identifier (in HEX)		algorithm algorithm_identifier (in HEX)
	------------ -----------------------------		------------ -----------------------------
	HMAC-SHA-256 06BC12783278CBBC2783CBBA9832892389		HMAC-SHA-256 06092B06010401DA470401
	4.1. HMAC-SHA-256 Challenge		4.1. HMAC-SHA-256 Challenge
	The "challenge" field MUST consist of 32 bytes of random data.		The "challenge" field MUST consist of 32 bytes of random data.
	4.2. HMAC-SHA-256 Response		4.2. HMAC-SHA-256 Response
	The "response" field is structured, illustrated as follows:		The "response" field is structured, illustrated as follows:
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	skipping to change at page 7, line 42		skipping to change at page 7, line 42
	/ /		/ /
	/ [authorization_identity] /		/ [authorization_identity] /
	/ |		/ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The "hmac_response" MUST consist of the output from the HMAC-SHA-256		The "hmac_response" MUST consist of the output from the HMAC-SHA-256
	algorithm using the "challenge" as input and the password as "key".		algorithm using the "challenge" as input and the password as "key".
	The size is always 32 bytes.		The size is always 32 bytes.
	The "authentication_identity_length" is a 4 byte integer encoded in		The "authentication_identity_length" is a 4 byte integer encoded in
	big-endien order (i.e., most significant byte first) denoting the		big-endian order (i.e., most significant byte first) denoting the
	length of the "authentication_identity" field.		length of the "authentication_identity" field.
	The "authentication_identity" is a variable-length field (the length		The "authentication_identity" is a variable-length field (the length
	is in "authentication_identity_length") which contains an		is in "authentication_identity_length") which contains an
	authentication identity.		authentication identity.
	The "authorization_identity" is a variable-length field; its length		The "authorization_identity" is a variable-length field; its length
	can be deduced from "authentication_identity_length" and the size of		can be deduced from "authentication_identity_length" and the size of
	the entire structure. In particular, if there is data left in the		the entire structure. In particular, if there is data left in the
	structure after the "authentication_identity" field, the data		structure after the "authentication_identity" field, the data
	skipping to change at page 9, line 9		skipping to change at page 9, line 9
	[XXX: Support stored hashed password on the server. For example, the		[XXX: Support stored hashed password on the server. For example, the
	"key" stored on the server wouldn't have to be the password straight,		"key" stored on the server wouldn't have to be the password straight,
	it could be a hashed value, possibly the PBKDF2 output, based on the		it could be a hashed value, possibly the PBKDF2 output, based on the
	authid and password. ]		authid and password. ]
	5. Using the protocol with GSS-API		5. Using the protocol with GSS-API
	The Challenge Token has the necessary format to serve as a mechanism-		The Challenge Token has the necessary format to serve as a mechanism-
	independent GSS-API Request Token. The Response Token serve as the		independent GSS-API Request Token. The Response Token serve as the
	GSS-API Response Token. The protocol consits only of one round-trip.		GSS-API Response Token. The protocol consists only of one round-
	Calling GSS_Init_sec_context will return the Challenge Token with a		trip. Calling GSS_Init_sec_context will return the Challenge Token
	GSS_S_CONTINUE_NEEDED status return. Passing the token to		with a GSS_S_CONTINUE_NEEDED status return. Passing the token to
	GSS_Accept_sec_context will either lead to a GSS_S_COMPLETE status		GSS_Accept_sec_context will either lead to a GSS_S_COMPLETE status
	return or a failure (thus, in particular, it will never lead to a		return or a failure (thus, in particular, it will never lead to a
	GSS_S_CONTINUE_NEEDED status return).		GSS_S_CONTINUE_NEEDED status return).
	The HMAC-SHA-256 value is derived from the registered Object		The HMAC-SHA-256 value is derived from the registered Object
	Identifier 1.3.6.1.4.1.11591.4.1.		Identifier 1.3.6.1.4.1.11591.4.1.
	[XXX: Discuss GSS-API flags.]		[XXX: Discuss GSS-API flags.]
	5.1. How Applications Specify the Password		5.1. How Applications Specify the Password
	The GSS-API framework does not deal with initial acquisation of		The GSS-API framework does not deal with initial acquisation of
	credentials. Thus, how application set the password that the GSS-		credentials. Thus, how application set the password that the GSS-
	CRAM implementation will use is outside of the scope of GSS-API.		CRAM implementation will use is outside of the scope of GSS-API.
	However, this particular GSS-API design choice seriously limits the		However, this particular GSS-API design choice seriously limits the
	usefulness of this mechanism, therefor it is considered whether to		usefulness of this mechanism, therefor it is considered whether to
	mandate, for use with GSS-CRAM, a specific method for applications to		mandate, for use with GSS-CRAM, a specific method for applications to
	set the password. One option here would be [8]. [XXX]		set the password. One option here would be [8]. [XXX]
	6. Using the protocol with SASL		6. SASL GS2 Mechanism Name
	The GS2 [7] framework can use the GSS-API mechanism based on this		The GS2 [7] framework can use the GSS-API mechanism based on this
	protocol directly.		protocol directly.
	The GS2 mechanism name for the HMAC-SHA-256 mandatory algorithm is		The OID is 1.3.6.1.4.1.11591.4.1. The ASN.1 DER encoding of the OID,
	computed from the OID, and is "GS2-TBC".		including the tag and length, is (in hex) 06 09 2B 06 01 04 01 DA 47
			04 01. The SHA-1 hash of the ASN.1 DER encoding is (in hex) 3e 0d 90
			8a 97 7b 6c da 9e 48 29 2b ca 63 7b 8d 9d 6b 96 d1. Convert the
			first ten octets to binary, and re-group them in groups of 5, and
			convert them back to decimal, which results in these computations:
			hex:
			3E 0D 90 8A 97 7B 6C DA 9E 48
			binary:
			00111110 00001101 10010000 10001010 10010111
			01111011 01101100 11011010 10011110 01001000
			binary in groups of 5:
			00111 11000 00110 11001 00001 00010 10100 10111
			01111 01101 10110 01101 10101 00111 10010 01000
			decimal of each group:
			7 24 6 25 1 2 20 23 15 13 22 13 21 7 18 8
			base32 encoding:
			H Y G Z B C U X P N W N V H S I
			The last step translate each decimal value using table 3 in Base32
			[6]. Thus the SASL mechanism name for the HMAC-SHA-256 mechanism is
			"GS2-HYGZBCUXPNWNVHSI".
	7. IANA Considerations		7. IANA Considerations
	None		None
	8. Security Considerations		8. Security Considerations
	TBA		TBA
	9. Copying conditions		9. Copying conditions
	skipping to change at page 14, line 12		skipping to change at page 14, line 12
	works do not contain misleading author or version information.		works do not contain misleading author or version information.
	Derivative works need not be licensed under similar terms.		Derivative works need not be licensed under similar terms.
	10. References		10. References
	10.1. Normative References		10.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] Williams, N., "On the Use of Channel Bindings to Secure		[2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
	Channels", draft-williams-on-channel-binding-00 (work in
	progress), August 2006.
	[3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
	for Message Authentication", RFC 2104, February 1997.		for Message Authentication", RFC 2104, February 1997.
	[4] National Institute of Standards and Technology, "Secure Hash		[3] National Institute of Standards and Technology, "Secure Hash
	Standard", FIPS PUB 180-2, August 2002,		Standard", FIPS PUB 180-2, August 2002,
	<http://csrc.nist.gov/publications/fips/fips180-2/		<http://csrc.nist.gov/publications/fips/fips180-2/
	fips180-2.pdf>.		fips180-2.pdf>.
			[4] Williams, N., "On the Use of Channel Bindings to Secure
			Channels", RFC 5056, November 2007.
	10.2. Informative References		10.2. Informative References
	[5] Linn, J., "Generic Security Service Application Program		[5] 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.
	[6] Melnikov, A. and K. Zeilenga, "Simple Authentication and		[6] Melnikov, A. and K. Zeilenga, "Simple Authentication and
	Security Layer (SASL)", RFC 4422, June 2006.		Security Layer (SASL)", RFC 4422, June 2006.
	[7] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2		[7] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2
	Mechanism Family", draft-ietf-sasl-gs2-06 (work in progress),		Mechanism Family", draft-ietf-sasl-gs2-06 (work in progress),
End of changes. 20 change blocks.
	29 lines changed or deleted		65 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/