< draft-sheffer-emu-eap-eke-08.txt		draft-sheffer-emu-eap-eke-09.txt >
	Network Working Group Y. Sheffer		Network Working Group Y. Sheffer
	Internet-Draft Independent		Internet-Draft Independent
	Intended status: Informational G. Zorn		Intended status: Informational G. Zorn
	Expires: February 26, 2011 Network Zen		Expires: April 13, 2011 Network Zen
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	S. Fluhrer		S. Fluhrer
	Cisco		Cisco
	August 25, 2010		October 10, 2010
	An EAP Authentication Method Based on the EKE Protocol		An EAP Authentication Method Based on the EKE Protocol
	draft-sheffer-emu-eap-eke-08		draft-sheffer-emu-eap-eke-09
	Abstract		Abstract
	The Extensible Authentication Protocol (EAP) describes a framework		The Extensible Authentication Protocol (EAP) describes a framework
	that allows the use of multiple authentication mechanisms. This		that allows the use of multiple authentication mechanisms. This
	document defines an authentication mechanism for EAP called EAP-EKE,		document defines an authentication mechanism for EAP called EAP-EKE,
	based on the Encrypted Key Exchange (EKE) protocol. This method		based on the Encrypted Key Exchange (EKE) protocol. This method
	provides mutual authentication through the use of a short, easy to		provides mutual authentication through the use of a short, easy to
	remember password. Compared with other common authentication		remember password. Compared with other common authentication
	methods, EAP-EKE is not susceptible to dictionary attacks. Neither		methods, EAP-EKE is not susceptible to dictionary attacks. Neither
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on February 26, 2011.		This Internet-Draft will expire on April 13, 2011.
	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 3, line 25 ¶		skipping to change at page 3, line 25 ¶
	4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 10		4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 10
	4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11		4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11
	4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 12		4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 12
	4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13		4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13
	4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14		4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14
	4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14		4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14
	5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 16		5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 16		5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 16
	5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 17		5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 17
	5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 18		5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 18
	5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 18		5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 19
	5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19		5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19		6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19
	6.1. Deriving a Key from the Password . . . . . . . . . . . . . 19		6.1. Generating Keying Material . . . . . . . . . . . . . . . . 19
	6.2. Generating Keying Material . . . . . . . . . . . . . . . . 20		6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20
	6.3. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20		6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 20
	6.4. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 21
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 24		8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27		8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27
	8.2. Diffie Hellman Group Considerations . . . . . . . . . . . 27		8.2. Diffie Hellman Group Considerations . . . . . . . . . . . 27
	8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28		8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28
	8.4. Identity Protection, Anonymity and Pseudonymity . . . . . 28		8.4. Identity Protection, Anonymity and Pseudonymity . . . . . 28
	8.5. Password Processing and Long Term Storage . . . . . . . . 28		8.5. Password Processing and Long Term Storage . . . . . . . . 28
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	skipping to change at page 16, line 24 ¶		skipping to change at page 16, line 24 ¶
	The server computes		The server computes
	y_s = g ^ x_s (mod p),		y_s = g ^ x_s (mod p),
	where x_s is a randomly chosen number in the range 2 .. p-1. The		where x_s is a randomly chosen number in the range 2 .. p-1. The
	randomly chosen number is the ephemeral private key, and the		randomly chosen number is the ephemeral private key, and the
	calculated value is the corresponding ephemeral public key. The		calculated value is the corresponding ephemeral public key. The
	server and the peer MUST both use a fresh, random value for x_s and		server and the peer MUST both use a fresh, random value for x_s and
	the corresponding x_p on each run of the protocol.		the corresponding x_p on each run of the protocol.
	The server transmits the encrypted field (Section 4.4)		The server computes and transmits the encrypted field (Section 4.4)
	DHComponent_S = Encr(kmac+(password), y_s).		temp = prf(0+, password)
			key = prf+(temp, ID_S | ID_P)
			DHComponent_S = Encr(key, y_s).
	See Section 6.1 for the kmac+ notation. The first output octets of		See Section 6.1 for the prf+ notation. The first argument to "prf"
	kmac+ are used as the encryption key for the negotiated encryption		is a string of zero octets whose length is the output size of the
	algorithm, according to that algorithm's key length.		base hash algorithm, e.g. 20 octets for HMAC-SHA1; the result is of
			the same length. The first output octets of prf+ are used as the
			encryption key for the negotiated encryption algorithm, according to
			that algorithm's key length.
			Since the PRF function is required to be an application of the HMAC
			operator to a hash function, the above construction implements HKDF
			as defined in [RFC5869].
	When using block ciphers, it may be necessary to pad y_s on the		When using block ciphers, it may be necessary to pad y_s on the
	right, to fit the encryption algorithm's block size. In such cases,		right, to fit the encryption algorithm's block size. In such cases,
	random padding MUST be used, and this randomness is critical to the		random padding MUST be used, and this randomness is critical to the
	security of the protocol. Randomness recommendations can be found in		security of the protocol. Randomness recommendations can be found in
	[RFC4086], and see also [NIST.800-90.2007] for additional		[RFC4086], and see also [NIST.800-90.2007] for additional
	recommendations on cryptographic-level randomness. When decrypting		recommendations on cryptographic-level randomness. When decrypting
	this field, the real length of y_s is determined according to the		this field, the real length of y_s is determined according to the
	negotiated Diffie Hellman group.		negotiated Diffie Hellman group.
	If the password needs to be stored on the server, it is RECOMMENDED		If the password needs to be stored on the server, it is RECOMMENDED
	to store the randomized password value, i.e. kmac+(password, ...), as		to store a randomized password value as a password-equivalent, rather
	a password-equivalent, rather than the cleartext password. See also		than the cleartext password. We note that implementations may choose
			the output of either of the two steps of the password derivation.
			Using the output of the second step, where the password is salted by
			the identity values, is more secure; however it may create an
			operational issue if identities are likely to change. See also
	Section 8.5.		Section 8.5.
	The input password string SHOULD be processed according to the rules		The input password string SHOULD be processed according to the rules
	of the [RFC4013] profile of [RFC3454]. A password SHOULD be		of the [RFC4013] profile of [RFC3454]. A password SHOULD be
	considered a "stored string" per [RFC3454] and unassigned code points		considered a "stored string" per [RFC3454] and unassigned code points
	are therefore prohibited. The output is the binary representation of		are therefore prohibited. The output is the binary representation of
	the processed UTF-8 [RFC3629] character string. Prohibited output		the processed UTF-8 [RFC3629] character string. Prohibited output
	and unassigned codepoints encountered in SASLprep preprocessing		and unassigned codepoints encountered in SASLprep preprocessing
	SHOULD cause a preprocessing failure and the output SHOULD NOT be		SHOULD cause a preprocessing failure and the output SHOULD NOT be
	used.		used.
	5.2. EAP-EKE-Commit/Response		5.2. EAP-EKE-Commit/Response
	The peer computes		The peer computes
	y_p = g ^ x_p (mod p)		y_p = g ^ x_p (mod p)
	and sends		computes and sends
	DHComponent_P = Encr(kmac+(password), y_p)		temp = prf(0+, password)
			key = prf+(temp, ID_S | ID_P)
			DHComponent_P = Encr(key, y_p)
	formatted as an encrypted field (Section 4.4).		formatted as an encrypted field (Section 4.4).
	Both sides calculate		Both sides calculate
	SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p))		SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p))
	If an HMAC-based pseudo-random function is used, the first argument		The first argument to "prf" is a string of zero octets whose length
	to "prf" is a string of zero octets whose length is the output size		is the output size of the base hash algorithm, e.g. 20 octets for
	of the base hash algorithm, e.g. 20 octets for HMAC-SHA1; the result		HMAC-SHA1; the result is of the same length. This extra application
	is of the same length. If a non HMAC-based prf is used, the		of the pseudo-random function is the "extraction step" of [RFC5869].
	algorithm should specify its preferred input length (to be used as		Note that the peer needs to compute the SharedSecret value before
	the length of the string of zeros). This extra application of the		sending out its response.
	pseudo-random function is the "extraction step" of [RFC5869]. Note
	that the peer needs to compute the SharedSecret value before sending
	out its response.
	The encryption and integrity protection keys are computed:		The encryption and integrity protection keys are computed:
	Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P)		Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P)
	And the peer generates the Protected Nonce:		And the peer generates the Protected Nonce:
	PNonce_P = Prot(Ke, Ki, Nonce_P),		PNonce_P = Prot(Ke, Ki, Nonce_P),
	where Nonce_P is a randomly generated binary string. The length of		where Nonce_P is a randomly generated binary string. The length of
	skipping to change at page 19, line 29 ¶		skipping to change at page 19, line 43 ¶
	are used.		are used.
	At this point, both protocol participants MUST discard all		At this point, both protocol participants MUST discard all
	intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke,		intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke,
	Ki, Ka, SharedSecret. Similarly, both parties MUST immediately		Ki, Ka, SharedSecret. Similarly, both parties MUST immediately
	discard these values whenever the protocol terminates with a failure		discard these values whenever the protocol terminates with a failure
	code or as a result of timeout.		code or as a result of timeout.
	6. Cryptographic Details		6. Cryptographic Details
	6.1. Deriving a Key from the Password		6.1. Generating Keying Material
	The negotiated keyed MAC algorithm is used as a hash function, to
	derive a bit string (albeit with low entropy) from the password. If
	"kmac" is the negotiated algorithm, we define:
	kmac+(P) = T1 | T2 | ...
	where each Ti is an application of the keyed MAC with a fixed key:
	T1 = kmac("S"+, P | 0x01)
	T2 = kmac("S"+, T1 | P | 0x02)
	T3 = kmac("S"+, T2 | P | 0x03)
	The key is a string containing the octet ASCII "S" (0x53) repeated N
	times, where N is the key length of the algorithm. Similarly to prf+
	(Section 6.2), The keys are taken from the output string without
	regard to boundaries.
	6.2. Generating Keying Material
	Keying material is derived as the output of the negotiated pseudo-		Keying material is derived as the output of the negotiated pseudo-
	random function (prf) algorithm. Since the amount of keying material		random function (prf) algorithm. Since the amount of keying material
	needed may be greater than the size of the output of the prf		needed may be greater than the size of the output of the prf
	algorithm, we will use the prf iteratively. We denote by "prf+" the		algorithm, we will use the prf iteratively. We denote by "prf+" the
	function that outputs a pseudo-random stream based on the inputs to a		function that outputs a pseudo-random stream based on the inputs to a
	prf as follows (where | indicates concatenation):		prf as follows (where | indicates concatenation):
	prf+ (K, S) = T1 | T2 | T3 | T4 | ...		prf+ (K, S) = T1 | T2 | T3 | T4 | ...
	skipping to change at page 20, line 33 ¶		skipping to change at page 20, line 24 ¶
	taken from the output string without regard to boundaries (e.g., if		taken from the output string without regard to boundaries (e.g., if
	the required keys are a 256-bit Advanced Encryption Standard (AES)		the required keys are a 256-bit Advanced Encryption Standard (AES)
	key and a 160-bit HMAC key, and the prf function generates 160 bits,		key and a 160-bit HMAC key, and the prf function generates 160 bits,
	the AES key will come from T1 and the beginning of T2, while the HMAC		the AES key will come from T1 and the beginning of T2, while the HMAC
	key will come from the rest of T2 and the beginning of T3).		key will come from the rest of T2 and the beginning of T3).
	The constant concatenated to the end of each string feeding the prf		The constant concatenated to the end of each string feeding the prf
	is a single octet. prf+ in this document is not defined beyond 255		is a single octet. prf+ in this document is not defined beyond 255
	times the size of the prf output.		times the size of the prf output.
	6.3. Diffie-Hellman Groups		6.2. Diffie-Hellman Groups
	Many of the commonly used Diffie Hellman groups are inappropriate for		Many of the commonly used Diffie Hellman groups are inappropriate for
	use in EKE. Most of these groups use a generator which is not a		use in EKE. Most of these groups use a generator which is not a
	primitive element of the group. As a result, an attacker running a		primitive element of the group. As a result, an attacker running a
	dictionary attack would be able to learn at least 1 bit of		dictionary attack would be able to learn at least 1 bit of
	information for each decrypted password guess.		information for each decrypted password guess.
	Any MODP Diffie Hellman group defined for use in this protocol MUST		Any MODP Diffie Hellman group defined for use in this protocol MUST
	have the following properties, to ensure that it does not leak a		have the following properties, to ensure that it does not leak a
	usable amount of information about the password:		usable amount of information about the password:
	skipping to change at page 21, line 7 ¶		skipping to change at page 20, line 46 ¶
	2. The most significant 64 bits of the prime number are 1.		2. The most significant 64 bits of the prime number are 1.
	3. The group's order p is a "safe prime", i.e. (p-1)/2 is also		3. The group's order p is a "safe prime", i.e. (p-1)/2 is also
	prime.		prime.
	The last requirement is related to the strength of the Diffie Hellman		The last requirement is related to the strength of the Diffie Hellman
	algorithm, rather than the password encryption. It also makes it		algorithm, rather than the password encryption. It also makes it
	easy to verify that the generator is primitive.		easy to verify that the generator is primitive.
	Suitable groups are defined in Section 7.1.		Suitable groups are defined in Section 7.1.
	6.4. Mandatory Algorithms		6.3. Mandatory Algorithms
	To facilitate interoperability, the following algorithms are		To facilitate interoperability, the following algorithms are
	mandatory to implement:		mandatory to implement:
	o ENCR_AES128_CBC (encryption algorithm)		o ENCR_AES128_CBC (encryption algorithm)
	o PRF_HMAC_SHA1 (pseudo random function)		o PRF_HMAC_SHA1 (pseudo random function)
	o MAC_HMAC_SHA1 (keyed message digest)		o MAC_HMAC_SHA1 (keyed message digest)
	o DHGROUP_EKE_14 (DH-group)		o DHGROUP_EKE_14 (DH-group)
	7. IANA Considerations		7. IANA Considerations
	IANA shall allocate (has allocated) the EAP method type TBD, for		IANA shall allocate (has allocated) the EAP method type TBD from the
	"EAP-EKE Version 1". [Note to RFC Editor: insert the IANA-allocated		range 1-191, for "EAP-EKE Version 1". [Note to RFC Editor: insert
	value here.]		the IANA-allocated value here.]
	This document requests that IANA create the registries described in		This document requests that IANA create the registries described in
	the following sub-sections. Values (other than private-use ones) can		the following sub-sections. Values (other than private-use ones) can
	be added to these registries per Specification Required [RFC5226],		be added to these registries per Specification Required [RFC5226],
	with two exceptions: the Exchange and Failure Code registries can		with two exceptions: the Exchange and Failure Code registries can
	only be extended per RFC Required [RFC5226].		only be extended per RFC Required [RFC5226].
	7.1. Diffie-Hellman Group Registry		7.1. Diffie-Hellman Group Registry
	This section defines an IANA registry for Diffie-Hellman groups.		This section defines an IANA registry for Diffie-Hellman groups.
	This table defines the initial contents of this registry. The Value		This table defines the initial contents of this registry. The Value
	column is used when negotiating the group. Additional groups may be		column is used when negotiating the group. Additional groups may be
	defined through IANA allocation. Any future specification that		defined through IANA allocation. Any future specification that
	defines a non-MODP group MUST specify its use within EAP-EKE and MUST		defines a non-MODP group MUST specify its use within EAP-EKE and MUST
	demonstrate the group's security in this context.		demonstrate the group's security in this context.
	+----------------+--------+---------+-------------------------------+		+-----------------+---------+---------------------------------------+
	| Name | Length | Value | Description |		| Name | Value | Description |
	+----------------+--------+---------+-------------------------------+		+-----------------+---------+---------------------------------------+
	| Reserved | | 0 | |		| Reserved | 0 | |
	| DHGROUP_EKE_2 | 1024 | 1 | The prime number of Group 2 |		| DHGROUP_EKE_2 | 1 | The prime number of the 1024-bit |
	| | | | [RFC4306], with the generator |		| | | Group 2 [RFC5996], with the generator |
	| | | | 5 (decimal) |		| | | 5 (decimal) |
	| DHGROUP_EKE_5 | 1536 | 2 | The prime number of Group 5 |		| DHGROUP_EKE_5 | 2 | The prime number of the 1536-bit |
	| | | | [RFC3526], g=31 |		| | | Group 5 [RFC3526], g=31 |
	| DHGROUP_EKE_14 | 2048 | 3 | The prime number of Group 14 |		| DHGROUP_EKE_14 | 3 | The prime number of the 2048-bit |
	| | | | [RFC3526], g=11 |		| | | Group 14 [RFC3526], g=11 |
	| DHGROUP_EKE_15 | 3072 | 4 | The prime number of Group 15 |		| DHGROUP_EKE_15 | 4 | The prime number of the 3072-bit |
	| | | | [RFC3526], g=5 |		| | | Group 15 [RFC3526], g=5 |
	| DHGROUP_EKE_16 | 4096 | 5 | The prime number of Group 16 |		| DHGROUP_EKE_16 | 5 | The prime number of the 4096-bit |
	| | | | [RFC3526], g=5 |		| | | Group 16 [RFC3526], g=5 |
	| Available for | | 6-127 | |		| Available for | 6-127 | |
	| allocation via | | | |		| allocation via | | |
	| IANA | | | |		| IANA | | |
	| Reserved for | | 128-255 | |		| Reserved for | 128-255 | |
	| private use | | | |		| private use | | |
	+----------------+--------+---------+-------------------------------+		+-----------------+---------+---------------------------------------+
	7.2. Encryption Algorithm Registry		7.2. Encryption Algorithm Registry
	This section defines an IANA registry for encryption algorithms:		This section defines an IANA registry for encryption algorithms:
	+-----------------+---------+-----------------------------------+		+-----------------+---------+-----------------------------------+
	| Name | Value | Definition |		| Name | Value | Definition |
	+-----------------+---------+-----------------------------------+		+-----------------+---------+-----------------------------------+
	| Reserved | 0 | |		| Reserved | 0 | |
	| ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode |		| ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode |
	skipping to change at page 22, line 42 ¶		skipping to change at page 22, line 37 ¶
	| Name | Value | Definition |		| Name | Value | Definition |
	+-------------------+---------+-------------------------------------+		+-------------------+---------+-------------------------------------+
	| Reserved | 0 | |		| Reserved | 0 | |
	| PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] |		| PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] |
	| PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] |		| PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] |
	| | 3-127 | Available for allocation via IANA |		| | 3-127 | Available for allocation via IANA |
	| | 128-255 | Reserved for private use |		| | 128-255 | Reserved for private use |
	+-------------------+---------+-------------------------------------+		+-------------------+---------+-------------------------------------+
	A pseudo-random function takes two parameters K and S (the key and		A pseudo-random function takes two parameters K and S (the key and
	input string respectively), and, to be usable in this context, must		input string respectively), and, to be usable in this protocol, must
	be defined for all lengths of K between 0 and 65,535 bits		be defined for all lengths of K between 0 and 65,535 bits
	(inclusive).		(inclusive).
			Any future pseudo-random function MUST be based on the HMAC
			construct, since the security of HKDF is only known for such
			functions.
	7.4. Keyed Message Digest (MAC) Registry		7.4. Keyed Message Digest (MAC) Registry
	This section defines an IANA registry for keyed message digest		This section defines an IANA registry for keyed message digest
	algorithms:		algorithms:
	+-------------------+---------+--------------+----------------------+		+-------------------+---------+--------------+----------------------+
	| Name | Value | Key Length | Definition |		| Name | Value | Key Length | Definition |
	| | | (Octets) | |		| | | (Octets) | |
	+-------------------+---------+--------------+----------------------+		+-------------------+---------+--------------+----------------------+
	| Reserved | 0 | | |		| Reserved | 0 | | |
	skipping to change at page 23, line 34 ¶		skipping to change at page 23, line 34 ¶
	| Name | Value | Definition |		| Name | Value | Definition |
	+-----------+---------+---------------------------------------------+		+-----------+---------+---------------------------------------------+
	| Reserved | 0 | |		| Reserved | 0 | |
	| ID_OPAQUE | 1 | An opaque octet string |		| ID_OPAQUE | 1 | An opaque octet string |
	| ID_NAI | 2 | A Network Access Identifier, as defined in |		| ID_NAI | 2 | A Network Access Identifier, as defined in |
	| | | [RFC4282] |		| | | [RFC4282] |
	| ID_IPv4 | 3 | An IPv4 address, in binary format |		| ID_IPv4 | 3 | An IPv4 address, in binary format |
	| ID_IPv6 | 4 | An IPv6 address, in binary format |		| ID_IPv6 | 4 | An IPv6 address, in binary format |
	| ID_FQDN | 5 | A fully qualified domain name, see note |		| ID_FQDN | 5 | A fully qualified domain name, see note |
	| | | below |		| | | below |
	| | 6-127 | Available for allocation via IANA |		| ID_DN | 6 | An LDAP Distinguished Name formatted as a |
			| | | string, as defined in [RFC4514] |
			| | 7-127 | Available for allocation via IANA |
	| | 128-255 | Reserved for private use |		| | 128-255 | Reserved for private use |
	+-----------+---------+---------------------------------------------+		+-----------+---------+---------------------------------------------+
	An example of a ID_FQDN is "example.com". The string MUST NOT		An example of an ID_FQDN is "example.com". The string MUST NOT
	contain any terminators (e.g., NULL, CR, etc.). All characters in		contain any terminators (e.g., NULL, CR, etc.). All characters in
	the ID_FQDN are ASCII; for an "internationalized domain name", the		the ID_FQDN are ASCII; for an "internationalized domain name", the
	syntax is as defined in [RFC5891], for example "xn--tmonesimerkki-		syntax is as defined in [RFC5891], for example "xn--tmonesimerkki-
	bfbb.example.net".		bfbb.example.net".
	7.6. EAP-EKE Channel Binding Type Registry		7.6. EAP-EKE Channel Binding Type Registry
	This section defines an IANA registry for the Channel Binding Type		This section defines an IANA registry for the Channel Binding Type
	registry, a 16-bit long code. The value 0x0000 has been defined as		registry, a 16-bit long code. The value 0x0000 has been defined as
	Reserved. All other values up to and including 0xfeff are available		Reserved. All other values up to and including 0xfeff are available
	skipping to change at page 27, line 37 ¶		skipping to change at page 27, line 37 ¶
	8.2. Diffie Hellman Group Considerations		8.2. Diffie Hellman Group Considerations
	It is fundamental to the dictionary attack resistance that the Diffie		It is fundamental to the dictionary attack resistance that the Diffie
	Hellman public values y_s and y_p are indistinguishable from a random		Hellman public values y_s and y_p are indistinguishable from a random
	string. If this condition is not met, then a passive attacker can do		string. If this condition is not met, then a passive attacker can do
	trial-decryption of the encrypted DHComponent_P or DHComponent_S		trial-decryption of the encrypted DHComponent_P or DHComponent_S
	values based on a password guess, and if they decrypt to a value		values based on a password guess, and if they decrypt to a value
	which is not a valid public value, they know that the password guess		which is not a valid public value, they know that the password guess
	was incorrect.		was incorrect.
	For MODP groups, Section 6.3 gives conditions on the group to make		For MODP groups, Section 6.2 gives conditions on the group to make
	sure that this criterion is met. For other groups (for example,		sure that this criterion is met. For other groups (for example,
	Elliptic Curve groups), some other means of ensuring this must be		Elliptic Curve groups), some other means of ensuring this must be
	employed. The standard way of expressing Elliptic Curve public		employed. The standard way of expressing Elliptic Curve public
	values does not meet this criterion, as a valid Elliptic Curve X		values does not meet this criterion, as a valid Elliptic Curve X
	coordinate can be distinguished from a random string with probability		coordinate can be distinguished from a random string with probability
	approximately 0.5.		approximately 0.5.
	A future document might introduce a group representation, and/or a		A future document might introduce a group representation, and/or a
	slight modification of the password encryption scheme, so that		slight modification of the password encryption scheme, so that
	Elliptic Curve groups can be accommodated. [BR02] presents several		Elliptic Curve groups can be accommodated. [BR02] presents several
	skipping to change at page 29, line 44 ¶		skipping to change at page 29, line 44 ¶
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	RFC 3748, June 2004.		RFC 3748, June 2004.
	[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names		[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
	and Passwords", RFC 4013, February 2005.		and Passwords", RFC 4013, February 2005.
	[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The		[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
	Network Access Identifier", RFC 4282, December 2005.		Network Access Identifier", RFC 4282, December 2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
	RFC 4306, December 2005.		(LDAP): String Representation of Distinguished Names",
			RFC 4514, June 2006.
	[RFC5891] Klensin, J., "Internationalized Domain Names in		[RFC5891] Klensin, J., "Internationalized Domain Names in
	Applications (IDNA): Protocol", RFC 5891, August 2010.		Applications (IDNA): Protocol", RFC 5891, August 2010.
	[SHA] National Institute of Standards and Technology, U.S.		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
			"Internet Key Exchange Protocol Version 2 (IKEv2)",
			RFC 5996, September 2010.
			[SHA] National Institute of Standards and Technology, U.S.
	Department of Commerce, "Secure Hash Standard", NIST FIPS		Department of Commerce, "Secure Hash Standard", NIST FIPS
	180-3, October 2008.		180-3, October 2008.
	10.2. Informative References		10.2. Informative References
	[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange:		[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange:
	Password-Based Protocols Secure Against Dictionary		Password-Based Protocols Secure Against Dictionary
	Attacks", Proc. IEEE Symp. on Research in Security and		Attacks", Proc. IEEE Symp. on Research in Security and
	Privacy , May 1992.		Privacy , May 1992.
	skipping to change at page 31, line 29 ¶		skipping to change at page 31, line 35 ¶
	Key Derivation Function (HKDF)", RFC 5869, May 2010.		Key Derivation Function (HKDF)", RFC 5869, May 2010.
	[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication		[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
	Protocol (EAP) Authentication Using Only a Password",		Protocol (EAP) Authentication Using Only a Password",
	RFC 5931, August 2010.		RFC 5931, August 2010.
	Appendix A. Change Log		Appendix A. Change Log
	Note to RFC Editor: please remove this section before publication.		Note to RFC Editor: please remove this section before publication.
	A.1. -08		A.1. -09
			Implemented all remaining "discuss" comments. This includes two
			changes to the IANA Considerations: clarification of the range where
			the EAP method number is to be allocated, and removal of the Length
			column from the DH Group registry.
			Eliminated the "kmac+" construction, reusing the prf+ notation
			instead. Key derivation from the password uses HKDF, and the PRF
			function is required to be an HMAC (thanks Dan and Brian!).
			Added an identity type for LDAP DNs.
			A.2. -08
	Implemented Alexey Melnikov's "discuss" comments.		Implemented Alexey Melnikov's "discuss" comments.
	A.2. -07		A.3. -07
	Implemented IETF LC review comments, primarily from Dan Harkins.		Implemented IETF LC review comments, primarily from Dan Harkins.
	Changed the derivation of an encryption key from the plaintext		Changed the derivation of an encryption key from the plaintext
	password. Changed the derivation of EMSK for efficiency. Clarified		password. Changed the derivation of EMSK for efficiency. Clarified
	the ranges of IANA allocations, and added a key length column for		the ranges of IANA allocations, and added a key length column for
	keyed MAC algorithms. Renamed some protocol fields for clarity.		keyed MAC algorithms. Renamed some protocol fields for clarity.
	A.3. -06		A.4. -06
	Lots of small changes based on Russ's AD review. Clarified		Lots of small changes based on Russ's AD review. Clarified
	processing of Channel Binding Values, some of which is currently out		processing of Channel Binding Values, some of which is currently out
	of scope. Made a small but non-backward compatible change to the		of scope. Made a small but non-backward compatible change to the
	generation of Ke, Ki. Changed the rules for nonce lengths (however		generation of Ke, Ki. Changed the rules for nonce lengths (however
	this results in no change for the currently specified algorithms).		this results in no change for the currently specified algorithms).
	A.4. -05		A.5. -05
	Revised the Anonymity section. Added more MODP groups. Note that		Revised the Anonymity section. Added more MODP groups. Note that
	DHGROUP_EKE_14 was renumbered.		DHGROUP_EKE_14 was renumbered.
	A.5. -04		A.6. -04
	Changed the intended document status to Informational.		Changed the intended document status to Informational.
	A.6. -03		A.7. -03
	Added a provision for channel binding.		Added a provision for channel binding.
	Clarified the notation for protected vs. encrypted fields.		Clarified the notation for protected vs. encrypted fields.
	Explained how pseudonymity can be provided.		Explained how pseudonymity can be provided.
	Implementations need not implement the "password not found" failure.		Implementations need not implement the "password not found" failure.
	Eliminated the Design Options appendix.		Eliminated the Design Options appendix.
	A.7. -02		A.8. -02
	Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes.		Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes.
	Eliminated protected failures: they are too rarely useful.		Eliminated protected failures: they are too rarely useful.
	Added the "extraction step" of HKDF.		Added the "extraction step" of HKDF.
	Removed the check for g^x != 0, since this can never happen for an		Removed the check for g^x != 0, since this can never happen for an
	honest peer, and otherwise requires an active password-guessing		honest peer, and otherwise requires an active password-guessing
	attacker, against which other protections are required. Added a		attacker, against which other protections are required. Added a
	related subsection about rate limiting.		related subsection about rate limiting.
	Added an Exchange Registry to the IANA Considerations.		Added an Exchange Registry to the IANA Considerations.
	A general structure for protected (and merely encrypted) fields,		A general structure for protected (and merely encrypted) fields,
	which clarifies the protocol and also adds explicit integrity		which clarifies the protocol and also adds explicit integrity
	protection for the encrypted nonces, as recommended by [BM92].		protection for the encrypted nonces, as recommended by [BM92].
	A.8. -01		A.9. -01
	Revised following comments raised on the CFRG mailing list. In		Revised following comments raised on the CFRG mailing list. In
	particular, added security considerations and a new DH group		particular, added security considerations and a new DH group
	definition, to resolve the vulnerability in case the group's		definition, to resolve the vulnerability in case the group's
	generator is not a primitive element.		generator is not a primitive element.
	A.9. -00		A.10. -00
	Initial version.		Initial version.
	Authors' Addresses		Authors' Addresses
	Yaron Sheffer		Yaron Sheffer
	Independent		Independent
	Email: yaronf.ietf@gmail.com		Email: yaronf.ietf@gmail.com
	Glen Zorn		Glen Zorn
	Network Zen		Network Zen
	1310 East Thomas Street		227/358 Thanon Sanphawut
	#306		Bang Na, Bangkok 10260
	Seattle, Washington 98102		Thailand
	USA
	Phone: +1 (206) 377-9035		Phone: +66 (0) 87-040-4617
	Email: gwz@net-zen.net		Email: gwz@net-zen.net
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
End of changes. 37 change blocks.
	94 lines changed or deleted		108 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/