draft-ietf-hokey-erp-aak-09.txt		draft-ietf-hokey-erp-aak-10.txt
	Network Working Group Z. Cao		Network Working Group Z. Cao
	Internet-Draft H. Deng		Internet-Draft H. Deng
	Intended status: Standards Track China Mobile		Intended status: Standards Track China Mobile
	Expires: August 15, 2012 Q. Wu		Expires: August 20, 2012 Q. Wu
	Huawei		Huawei
	G. Zorn, Ed.		G. Zorn, Ed.
	Network Zen		Network Zen
	February 12, 2012		February 17, 2012
	EAP Re-authentication Protocol Extensions for Authenticated Anticipatory		EAP Re-authentication Protocol Extensions for Authenticated Anticipatory
	Keying (ERP/AAK)		Keying (ERP/AAK)
	draft-ietf-hokey-erp-aak-09		draft-ietf-hokey-erp-aak-10
	Abstract		Abstract
	The Extensible Authentication Protocol (EAP) is a generic framework		The Extensible Authentication Protocol (EAP) is a generic framework
	supporting multiple types of authentication methods.		supporting multiple types of authentication methods.
	The EAP Re-authentication Protocol (ERP) specifies extensions to EAP		The EAP Re-authentication Protocol (ERP) specifies extensions to EAP
	and the EAP keying hierarchy to support an EAP method-independent		and the EAP keying hierarchy to support an EAP method-independent
	protocol for efficient re-authentication between the peer and an EAP		protocol for efficient re-authentication between the peer and an EAP
	re-authentication server through any authenticator.		re-authentication server through any authenticator.
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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 August 15, 2012.		This Internet-Draft will expire on August 20, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 2, line 31		skipping to change at page 2, line 31
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3		2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3
	2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4		3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4
	4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7		4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7
	4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8		4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8
	5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9		5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9
	5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9		5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9
	5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 9		5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10
	5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 11		5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 12
	5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14		5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14
	6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 14		6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 15
	7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 14		7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 17		11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Extensible Authentication Protocol (EAP) [RFC3748] is a generic		The Extensible Authentication Protocol (EAP) [RFC3748] is a generic
	framework supporting multiple types of authentication methods. In		framework supporting multiple types of authentication methods. In
	systems where EAP is used for authentication, it is desirable to not		systems where EAP is used for authentication, it is desirable to not
	repeat the entire EAP exchange with another authenticator. The EAP		repeat the entire EAP exchange with another authenticator. The EAP
	Re-authentication Protocol (ERP) [RFC5296] specifies extensions to		Re-authentication Protocol (ERP) [RFC5296] specifies extensions to
	EAP and the EAP keying hierarchy to support an EAP method-independent		EAP and the EAP keying hierarchy to support an EAP method-independent
	protocol for efficient re-authentication between the EAP re-		protocol for efficient re-authentication between the EAP re-
	skipping to change at page 5, line 11		skipping to change at page 5, line 11
	specification is out of the scope of this document. Figure 1 shows		specification is out of the scope of this document. Figure 1 shows
	the general protocol exchange by which the keying material is		the general protocol exchange by which the keying material is
	established on the CAP.		established on the CAP.
	+------+ +-----+ +-----+ +-----------+		+------+ +-----+ +-----+ +-----------+
	| Peer | | SAP | | CAP | | EA Server |		| Peer | | SAP | | CAP | | EA Server |
	+--+---+ +--+--+ +--+--+ +-----+-----+		+--+---+ +--+--+ +--+--+ +-----+-----+
	| | | |		| | | |
	a. | [EAP-Initiate/ | | |		a. | [EAP-Initiate/ | | |
	| Re-auth-start | | |		| Re-auth-start | | |
	| (E-flag) | | |		| (E-flag)] | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	b. | EAP-Initiate/ | | |		b. | EAP-Initiate/ | | |
	| Re-auth | | |		| Re-auth | | |
	| (E-flag) | | |		| (E-flag) | | |
	|--------------->| | |		|--------------->| | |
	c. | | AAA(EAP-Initiate/Re-auth(E-flag))|		c. | | AAA(EAP-Initiate/Re-auth(E-flag))|
	| |--------------------------------->|		| |--------------------------------->|
	| | | +---------+---------+		| | | +---------+---------+
	| | | | CA authorized & |		| | | | CA authorized & |
	skipping to change at page 8, line 36		skipping to change at page 8, line 36
	K = EMSK or K = DSRK and		K = EMSK or K = DSRK and
	S = pRK Label | "\0" | length		S = pRK Label | "\0" | length
	The pRK Label is an IANA-assigned 8-bit ASCII string:		The pRK Label is an IANA-assigned 8-bit ASCII string:
	EAP Early-Authentication Root Key@ietf.org		EAP Early-Authentication Root Key@ietf.org
	assigned from the "USRK key labels" name space in accordance with		assigned from the "USRK key labels" name space in accordance with
	Salowey, et al. [RFC5295]. The KDF and algorithm agility for the		Salowey, et al. [RFC5295]. The KDF and algorithm agility for the
	KDF are also defined in RFC 5295.		KDF are also defined in RFC 5295. The KDF algorithm is indicated in
			the cryptosuit field or list of cryptosuits TLV payload as specified
			in the section 5.2 and section 5.3.
	The pMSK is derived as follows:		The pMSK uses the same PDF as pRK and is derived as follows:
	pMSK = KDF (K, S), where		pMSK = KDF (K, S), where
	K = pRK and		K = pRK and
	S = pMSK label | "\0" | SEQ | length		S = pMSK label | "\0" | SEQ | length
	The pMSK label is the 8-bit ASCII string:		The pMSK label is the 8-bit ASCII string:
	Early-Authentication Master Session Key@ietf.org		EAP Early-Authentication Master Session Key@ietf.org
	The length field refers to the length of the pMSK in octets encoded		The length field refers to the length of the pMSK in octets encoded
	as specified in RFC 5295. SEQ is sent by either the peer or the		as specified in RFC 5295. SEQ is sent by either the peer or the
	server in the ERP/AAK message using the SEQ field or the Sequence		server in the ERP/AAK message using the SEQ field or the Sequence
	number TLV and encoded as an 16-bit number as specified in		number TLV and encoded as an 16-bit number as specified in
	Section 5.2 and Section 5.3.		Section 5.2 and Section 5.3.
	5. Packet and TLV Extension		5. Packet and TLV Extension
	This section describes the packet and TLV extensions for the ERP/AAK		This section describes the packet and TLV extensions for the ERP/AAK
	exchange.		exchange.
	5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension		5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension
	Figure 5 shows the changed parameters contained in the EAP-Initiate/		Figure 5 shows the new parameters contained in the EAP-Initiate/
	Re-auth-Start packet defined in RFC 5296 [RFC5296].		Re-auth-Start packet defined in RFC 5296 [RFC5296].
	0 1 2 3		0 1 2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code | Identifier | Length |		| Code | Identifier | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type |E| Reserved | 1 or more TVs or TLVs ~		| Type |E| Reserved | 1 or more TVs or TLVs ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 49		skipping to change at page 10, line 7
	that of a DiameterIdentity [RFC3588]. It is used by the SAP to		that of a DiameterIdentity [RFC3588]. It is used by the SAP to
	advertise the identity of the CAP to the peer. Exactly one CAP-		advertise the identity of the CAP to the peer. Exactly one CAP-
	Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start		Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start
	packet if the SAP has performed CAP discovery.		packet if the SAP has performed CAP discovery.
	If the EAP-Initiate/Re-auth-Start packet is not supported by the		If the EAP-Initiate/Re-auth-Start packet is not supported by the
	peer, it SHOULD be discarded silently.		peer, it SHOULD be discarded silently.
	5.2. EAP-Initiate/Re-auth Packet and TLV Extension		5.2. EAP-Initiate/Re-auth Packet and TLV Extension
	Figure 6 illustrates the changed parameters contained in the EAP-		Figure 6 illustrates the new parameters contained in the EAP-
	Initiate/Re-auth packet defined in RFC 5296 [RFC5296].		Initiate/Re-auth packet defined in RFC 5296 [RFC5296].
	0 1 2 3		0 1 2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code | Identifier | Length |		| Code | Identifier | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type |R|x|L|E|Resved | SEQ |		| Type |R|x|L|E|Resved | SEQ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 or more TVs or TLVs ~		| 1 or more TVs or TLVs ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cryptosuite | Authentication Tag ~		| Cryptosuite | Authentication Tag ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6		Figure 6
	Flags		Flags
	'x' - The x flag is reserved. It MUST be ignored on receipt.		'x' - The x flag is reserved. It MUST be ignored on receipt.
			'L' - As defined in section 5.3.2 of [RFC5296], this bit is used to
			request the key lifetimes from the server.
	'E' - The E flag is used to indicate early-authentication.		'E' - The E flag is used to indicate early-authentication.
	The final 4 bits (Resved) MUST be set to 0 and ignored on reception.		The first bit(R) and final 4 bits (Resved) MUST be set to 0 and
			ignored on reception.
	SEQ		SEQ
	As defined in Section 5.3.2 of [RFC5296],this field is 16-bit		As defined in Section 5.3.2 of [RFC5296],this field is 16-bit
	sequence number and used for replay protection.		sequence number and used for replay protection.
	TVs and TLVs		TVs and TLVs
	keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a		keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a
	TLV payload. The Type is 1. The NAI is variable in length, not		TLV payload. The Type is 1. The NAI is variable in length, not
	skipping to change at page 11, line 50		skipping to change at page 12, line 11
	If the EAP-Initiate/Re-auth packet is not supported by the SAP, it		If the EAP-Initiate/Re-auth packet is not supported by the SAP, it
	SHOULD be discarded silently. The peer MUST maintain retransmission		SHOULD be discarded silently. The peer MUST maintain retransmission
	timers for reliable transport of the EAP-Initiate/Re-auth message.		timers for reliable transport of the EAP-Initiate/Re-auth message.
	If there is no response to the EAP-Initiate/Re-auth message from the		If there is no response to the EAP-Initiate/Re-auth message from the
	server after the necessary number of retransmissions (see Section 6),		server after the necessary number of retransmissions (see Section 6),
	the peer MUST assume that ERP/AAK is not supported by the SAP.		the peer MUST assume that ERP/AAK is not supported by the SAP.
	5.3. EAP-Finish/Re-auth packet and TLV extension		5.3. EAP-Finish/Re-auth packet and TLV extension
	Figure 7 shows the changed parameters contained in the EAP-Finish/		Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth
	Re-auth packet defined in [RFC5296].		packet defined in [RFC5296].
	0 1 2 3		0 1 2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code | Identifier | Length |		| Code | Identifier | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type |R|x|L|E|Resved | SEQ |		| Type |R|x|L|E|Resved | SEQ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 or more TVs or TLVs ~		| 1 or more TVs or TLVs ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cryptosuite | Authentication Tag ~		| Cryptosuite | Authentication Tag ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7		Figure 7
	Flags		Flags
			'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used to
			used as the Result flag. This field MUST be set to '1' if indicates
			success and MUST be set to '0' otherwise.
	'x' - The x flag is reserved. It MUST be ignored on receipt.		'x' - The x flag is reserved. It MUST be ignored on receipt.
			'L' - As defined in section 5.3.3 of [RFC5296], this bit is used to
			request the key lifetimes from the server.
	'E' - The E flag is used to indicate early-authentication.		'E' - The E flag is used to indicate early-authentication.
	The final 4 bits (Resved) MUST be set to 0 and ignored on reception.		The final 4 bits (Resved) MUST be set to 0 and ignored on reception.
	SEQ		SEQ
	As defined in Section 5.3.2 of [RFC5296], this field is a 16-bit		As defined in Section 5.3.3 of [RFC5296], this field is a 16-bit
	sequence number and used for replay protection.		sequence number and used for replay protection.
	TVs and TLVs		TVs and TLVs
	keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a		keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a
	TLV payload. The Type is 1. The NAI is variable in length, not		TLV payload. The Type is 1. The NAI is variable in length, not
	exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be		exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be
	present in an EAP-Finish/Re-auth packet.		present in an EAP-Finish/Re-auth packet.
	ERP/AAK-Key: Carried in a TLV payload for the key container. The		ERP/AAK-Key: Carried in a TLV payload for the key container. The
	skipping to change at page 13, line 43		skipping to change at page 14, line 8
	cryptosuite values are as specified in Section 5.2, above. The		cryptosuite values are as specified in Section 5.2, above. The
	server SHOULD include this attribute if the cryptosuite used in		server SHOULD include this attribute if the cryptosuite used in
	the EAP-Initiate/Re-auth message was not acceptable and the		the EAP-Initiate/Re-auth message was not acceptable and the
	message is being rejected. The server MAY include this attribute		message is being rejected. The server MAY include this attribute
	in other cases. The server MAY use this attribute to signal to		in other cases. The server MAY use this attribute to signal to
	the peer about its cryptographic algorithm capabilities.		the peer about its cryptographic algorithm capabilities.
	Cryptosuite		Cryptosuite
	This field indicates the integrity algorithm and PRF used for ERP/		This field indicates the integrity algorithm and PRF used for ERP/
	AAK. HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled		AAK. HMAC-SHA256-128 is REQUIRED to implement and SHOULD be enabled
	in the default configuration. Key lengths and output lengths are		in the default configuration. Key lengths and output lengths are
	either indicated or obvious from the cryptosuite name.		either indicated or obvious from the cryptosuite name.
	Authentication Tag		Authentication Tag
	This field contains the integrity checksum over the ERP/AAK packet		This field contains the integrity checksum over the ERP/AAK packet
	from the first bit of the Code field to the last bit of the		from the first bit of the Code field to the last bit of the
	Cryptosuite field excluding the Authentication Tag field itself. The		Cryptosuite field excluding the Authentication Tag field itself. The
	value field is calculated using the integrity algorithm indicated in		value field is calculated using the integrity algorithm indicated in
	the Cryptosuite field and the rIK [RFC5296] as the integrity key.		the Cryptosuite field and the rIK [RFC5296] as the integrity key.
	skipping to change at page 14, line 37		skipping to change at page 14, line 51
	in the EAP-Initiate and EAP-Finish messages are defined as below:		in the EAP-Initiate and EAP-Finish messages are defined as below:
	o Sequence number: This is a TV payload. The type is 7.		o Sequence number: This is a TV payload. The type is 7.
	o ERP/AAK-Key: This is a TLV payload. The type is 8.		o ERP/AAK-Key: This is a TLV payload. The type is 8.
	o pRK-Lifetime: This is a TV payload. The type is 9.		o pRK-Lifetime: This is a TV payload. The type is 9.
	o pMSK-Lifetime: This is a TV payload. The type is 10.		o pMSK-Lifetime: This is a TV payload. The type is 10.
			o CAP-Identifier: This is a TLV payload. The type is 11.
	6. Lower Layer Considerations		6. Lower Layer Considerations
	Similar to ERP, some lower layer specifications may need to be		Similar to ERP, some lower layer specifications may need to be
	revised to support ERP/AAK; refer to Section 6 of [RFC5296] for		revised to support ERP/AAK; refer to Section 6 of [RFC5296] for
	additional guidance.		additional guidance.
	7. AAA Transport Considerations		7. AAA Transport Considerations
	The AAA transport of ERP/AAK messages is the same as that of the ERP		The AAA transport of ERP/AAK messages is the same as that of the ERP
	message [RFC5296]. In addition, this document requires AAA transport		message [RFC5296]. In addition, this document requires AAA transport
	skipping to change at page 16, line 33		skipping to change at page 16, line 48
	with the following numbers:		with the following numbers:
	o Sequence number: This is a TV payload. The type is 7.		o Sequence number: This is a TV payload. The type is 7.
	o ERP/AAK-Key: This is a TLV payload. The type is 8.		o ERP/AAK-Key: This is a TLV payload. The type is 8.
	o pRK Lifetime: This is a TLV payload. The type is 9.		o pRK Lifetime: This is a TLV payload. The type is 9.
	o pMSK Lifetime: This is a TLV payload. The type is 10.		o pMSK Lifetime: This is a TLV payload. The type is 10.
			o CAP-Identifier: This is a TLV payload. The type is 11.
	This document reuses the crytosuites have already created for 'Re-		This document reuses the crytosuites have already created for 'Re-
	authentication Cryptosuites' in [RFC5296].		authentication Cryptosuites' in [RFC5296].
	Further, this document instructs IANA to add a new label in the User		Further, this document instructs IANA to add a new label in the User
	Specific Root Keys (USRK) Key Labels of the Extended Master Session		Specific Root Keys (USRK) Key Labels of the Extended Master Session
	Key (EMSK) Parameters registry, as follows:		Key (EMSK) Parameters registry, as follows:
	EAP Early-Authentication Root Key@ietf.org		EAP Early-Authentication Root Key@ietf.org
			This document creates a new registry for the flags in the EAP
			Initiate/Re-auth-Start message called the "EAP Initiate/Re-auth-Start
			Flags" and assigns a new flag (E) as follows:
			(E) 0x80
			The rest of the values in the 8-bit field are reserved. New values
			can be assigned by Standards Action or IESG approval.
			This document also creates a new registry for the flags in the EAP
			Initiate/Re-auth message called the "EAP Initiate/Re-auth Flags".
			The following flag are reserved:
			(B) 0x40 [RFC5296]
			(L) 0x20 [RFC5296]
			This document assigns a new flag (E) as follows:
			(E) 0x10
			The rest of the values in the 8-bit field are reserved. New values
			can be assigned by Standards Action or IESG approval.
			Further,this document creates a new registry for the flags in the EAP
			Finish/Re-auth message called the "EAP Finish/Re-auth Flags". The
			following values are reserved.
			(R) 0x80 [RF5296]
			(B) 0x40 [RFC5296]
			(L) 0x20 [RFC5296]
			This document assigns a new flag (E) as follows:
			(E) 0x10
			The rest of the values in the 8-bit field are reserved. New values
			can be assigned by Standards Action or IESG approval.
	10. Acknowledgement		10. Acknowledgement
	In writing this document, Yungui Wang contributed to early versions		In writing this document, Yungui Wang contributed to early versions
	of this document and we have received reviews from many experts in		of this document and we have received reviews from many experts in
	the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon		the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon
	Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia and		Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia and
	Sujing Zhou. We apologize if we miss some of those who have helped		Sujing Zhou. We apologize if we miss some of those who have helped
	us.		us.
	11. References		11. References
End of changes. 23 change blocks.
	23 lines changed or deleted		81 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/