draft-ietf-hokey-erp-aak-06.txt		draft-ietf-hokey-erp-aak-07.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: April 20, 2012 Y. Wang		Expires: July 20, 2012 Q. Wu
	Q. Wu		Huawei
	Huawei Technologies Co., Ltd.		G. Zorn
	G. Zorn, Ed.
	Network Zen		Network Zen
	October 18, 2011		January 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-06		draft-ietf-hokey-erp-aak-07
	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 2, line 4		skipping to change at page 1, line 48
	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 April 20, 2012.
			This Internet-Draft will expire on July 20, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	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 Overview . . . . . . . . . . . . . . . . . . . . . . . 4		3. ERP/AAK Overview . . . . . . . . . . . . . . . . . . . . . . . 4
	4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 5		4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 6
	5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6		4.1. pRK, pMSK derivation . . . . . . . . . . . . . . . . . . . 7
	5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6		5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 8
	5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7		5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 8
	5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 8		5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 8
	5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 10		5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 10
	6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11		5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 13
	7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11		6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
			11.2. Informative References . . . . . . . . . . . . . . . . . . 16
	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 peer and an EAP		protocol for efficient re-authentication between the peer and an EAP
	skipping to change at page 4, line 11		skipping to change at page 4, line 11
	MH Mobile Host		MH Mobile Host
	SAP Serving Attachment Point [RFC5836]		SAP Serving Attachment Point [RFC5836]
	3. ERP/AAK Overview		3. ERP/AAK Overview
	ERP/AAK is intended to allow the establishment of cryptographic		ERP/AAK is intended to allow the establishment of cryptographic
	keying materials on a single Candidate Attachment Points prior to the		keying materials on a single Candidate Attachment Points prior to the
	arrival of the MH at the Candidate Access Network (CAN).		arrival of the MH at the Candidate Access Network (CAN).
	It is assumed that the peer has previously completed full EAP		In this document, ERP/AAK support for the peer is assumed. Also it
			is assumed that the peer has previously completed full EAP
	authentication and the peer or SAP knows the identities of		authentication and the peer or SAP knows the identities of
	neighboring attachment points. Figure 1 shows the general protocol		neighboring attachment points. Note that the behavior of the peer
	exchange by which the keying material is established on the CAP.		that does not support the ERP-AAK scheme defined in this
	This document only discusses the case of distributing the key to a		specification is out of the scope of this document.Figure 1 shows the
	single CAP.		general protocol exchange by which the keying material is established
			on the CAP.
	+------+ +-----+ +-----+ +-----------+		+------+ +-----+ +-----+ +-----------+
	| Peer | | SAP | | CAP | | EA Server |		| Peer | | SAP | | CAP | | EA Server |
	+--+---+ +--+--+ +--+--+ +-----+-----+		+--+---+ +--+--+ +--+--+ +-----+-----+
	| | | |		| | | |
	1. | [EAP-Initiate/ | | |		a. | [EAP-Initiate/ | | |
	| Re-auth-start | | |		| Re-auth-start | | |
	| (E-flag) | | |		| (E-flag) | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	2. | EAP-Initiate/ | | |		b. | EAP-Initiate/ | | |
	| Re-auth | | |		| Re-auth | | |
	| (E-flag) | | |		| (E-flag) | | |
	|--------------->| | |		|--------------->| | |
	3. | | AAA(EAP-Initiate/Re-auth(E-flag))|		c. | | AAA(EAP-Initiate/Re-auth(E-flag))|
	| |--------------------------------->|		| |--------------------------------->|
	| | | +---------+---------+		| | | +---------+---------+
	| | | | CA authorized & |		| | | | CA authorized & |
	4. | | | | authenticated; |		d. | | | | and EA Keying |
	| | | | EA keying |		| | | | Distribution |
	| | | | materials derived |
	| | | +---------+---------+		| | | +---------+---------+
	5. | | | |
	| | | AAA(pMSK) |
	| | |<----------------->|
	| | | |		| | | |
	6. | | AAA (EAP-Finish/Re-auth(E-flag)) |		| | | |
			f. | | AAA (EAP-Finish/Re-auth(E-flag)) |
	| |<---------------------------------|		| |<---------------------------------|
	7. | EAP-Finish/ | | |		g. | EAP-Finish/ | | |
	| Re-auth(E-flag)| | |		| Re-auth(E-flag)| | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	Figure 1: ERP/AAK Operation		Figure 1: ERP/AAK Exchange
			+-----------+ +---------+
			| | | |
			| EA Server | | CAP |
			| | | |
			+-----|-----+ +----|----+
			| |
			| |
			| AAA Request(pMSK) |
			e.1|------------------------->|
			| |
			| |
			| |
			| AAA Response (Success) |
			e.2|<-------------------------|
			| |
			| |
			| |
			Figure 2: Key Distribution for ERP/AAK
	ERP/AAK re-uses the packet format defined by ERP, but specifies a new		ERP/AAK re-uses the packet format defined by ERP, but specifies a new
	flag to differentiate EAP early-authentication from EAP re-		flag to differentiate EAP early-authentication from EAP re-
	authentication. The peer initiates ERP/AAK itself, or does so in		authentication. The peer initiates ERP/AAK itself, or does so in
	response to an EAP-Initiate/Re-Auth-Start message from the SAP. In		response to an EAP-Initiate/Re-Auth-Start message from the SAP.
	this document, SAP support for ERP/AAK is assumed. If either the
	peer or the SAP does not support ERP/AAK, it should fall back to full
	EAP authentication.
	The SAP may send the identity of a candidate attachment point to the		In the latter case, the SAP MAY send the identity of a candidate
	peer in the EAP-Initiate/Re-auth-Start message. If the EAP-Initiate/		attachment point to the peer in the EAP-Initiate/Re-auth-Start
	Re-auth-Start packet is not supported by the peer, it is silently		message (see a. in the figure 1). If the EAP-Initiate/ Re-auth-Start
	discarded.		packet is not supported by the peer, it MUST be silently discarded.
	The peer sends an early-authentication request message (EAP-Initiate/		If the peer initiate ERP/AAK, the peer MAY send an early-
	Re-auth with the 'E' flag set) containing the keyName-NAI, the CAP-		authentication request message (EAP-Initiate/ Re-auth with the 'E'
	Identifier, rIK and sequence number. The realm in the keyName-NAI		flag set) containing the keyName-NAI, the CAP- Identifier, rIK and
	field is used to locate the peer's ERP/AAK server. The CAP-		sequence number (see b. in the figure 1). The realm in the keyName-
	Identifier is used to identify the CAP. The rIK is used to protect		NAI field is used to locate the peer's ERP/AAK server. The CAP-
	the message. The sequence number is used for replay protection.		Identifier is used to identify the CAP. The rIK is defined in
			RFC5296 and used to protect the integrity of the message. The
			sequence number is used for replay protection.
	The SAP encapsulates the early-authentication message into a AAA		The SAP SHOULD verify the integrity of the message at step b. If
	message and sends it to the peer's ERP/AAK server in the realm		This verifications fail, the SAP MUST send an EAP- Finish/Re-auth
	indicated in the keyName-NAI field.		message with the Result flag set to '1' (Failure).In success case,
			the SAP SHOULD encapsulate the early-authentication message into a
			AAA message and send it to the peer's ERP/AAK server in the realm
			indicated in the keyName-NAI field (see c. in the figure 1).
	Upon receiving the message, the ERP/AAK server first checks its		Upon receiving the message, the ERP/AAK server first uses the keyName
	integrity and freshness, then verifies the identity of the peer by		indicated in the keyName-NAI to look up the rIK and checks the
	checking the username portion of the KeyName-NAI. Next, the server		integrity and freshness of the message, then verifies the identity of
	authenticates and authorizes the CAP specified in the CAP-Identifier		the peer by checking the username portion of the KeyName-NAI. If any
	TLV. If any of the checks fail, the server sends an early-		of the checks fail, the server SHOULD send an early- authentication
	authentication finish message (EAP-Finish/Re-auth with E-flag set)		finish message (EAP-Finish/Re-auth with E-flag set) with the Result
	with the Result flag set to '1'.		flag set to '1'. Next, the server SHOULD authorize the CAP specified
			in the CAP-Identifier TLV. In success case, the server derives a
			pMSK from the pRK for each CAP carried in the the CAP-Identifier
			field using the sequence number associated with CAP-Identifier as an
			input to the key derivation. (see d. in the figure 1)
	The ERP/AAK server transports the pMSK to the authenticated and		Then The ERP/AAK server transports the pMSK to the authorized CAP via
	authorized CAP via AAA as described in Section 7.		AAA Section 7 as described in figure 2 (see e.1,e.2 in the figure 2).
			Note that key distribution in the figure 2 is one part of step d. in
			the figure 1.
	Finally, the ERP/AAK server sends the early-authentication finish		Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK
	message (EAP-Finish/Re-auth with E-flag set) containing the identity		server sends the early-authentication finish message (EAP-Finish/
	of the authorized CAP to the peer via the SAP.		Re-auth with E-flag set) containing the identity of the authorized
			CAP to the peer via the SAP and associated lifetime of pMSK,
			Optionally, if the peer also requests the server for the rRK
			lifetime, the EA server SHOULD send the rRK lifetime in the EAP-
			Finish/Re-auth message. (see f.,g. in the figure 1).
	4. ERP/AAK Key Hierarchy		4. ERP/AAK Key Hierarchy
	As an optimization of ERP, ERP/AAK uses a key hierarchy similar to		As an extension of ERP, ERP/AAK uses a key hierarchy similar to that
	that of ERP. The EMSK is used to derive the ERP/AAK pre-established		of ERP. The ERP/AAK pre-established Root Key (pRK) is derived from
	Root Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key		either EMSK or DSRK as specified in the section 4.1. In general, the
	(pIK) and the pre-established Master Session Key (pMSK) are derived		pRK is derived from the EMSK in case of the peer moving in the home
	from the pRK. The pMSK is established for the CAP when the peer		AAA realm and derived from the DRSK in case of the peer moving in a
	early authenticates to the network. The pIK is established for the		visited realm. The DSRK is delivered from the EAP server to the ERP/
	peer to re-authenticate the network after handover. The hierarchy		AAK server as specified in [I-D.ietf-dime-local-keytran]. If the
	relationship is illustrated in Figure 2, below.
	DSRK EMSK
	| |
	+---+---+---+---+
	| | |
	pRK rRK ...
	Figure 2
	The EMSK and DSRK both can be used to derive the pRK. In general,
	the pRK is derived from the EMSK in case of the peer moving in the
	home AAA realm and derived from the DRSK in case of the peer moving
	in a visited realm. The DSRK is delivered from the EAP server to the
	ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. If the
	peer has previously been authenticated by means of ERP or ERP/AAK,		peer has previously been authenticated by means of ERP or ERP/AAK,
	the DSRK SHOULD be directly re-used.		the DSRK SHOULD be directly re-used.
			DSRK EMSK
			| |
			+---+---+---+---+
			|
			pRK ...
			Figure 3: ERP/AAK Root Key Derivation
			Similarly,the pre-established Master Session Key (pMSK) are derived
			from the pRK. The pMSK is established for the CAP when the peer
			early authenticates to the network. The hierarchy relationship is
			illustrated Figure 4,
	pRK		pRK
	|		|
	+--------+--------+		+--------+--------+
	| | |		|
	pIK pMSK ...		pMSK ...
	Figure 3		Figure 4: ERP/AAK Key Hierarchy
	The pRK is used to derive the pIK and pMSK for the CAP.		below.
			4.1. pRK, pMSK derivation
			The rRK is derived as specified in [RFC5295].
			pRK = KDF (K, S), where
			K = EMSK or K = DSRK and
			S = pRK Label | "\0" | length
			The pRK Label is an IANA-assigned 8-bit ASCII string:
			EAP Early-Authentication Root Key@ietf.org
			assigned from the "USRK key labels" name space in accordance with
			[RFC5295]. The KDF and algorithm agility for the KDF are as defined
			in [RFC5295].
			The pMSK is derived as follows.
			pMSK = KDF (K, S), where
			K = pRK and
			S = pMSK label | "\0" | SEQ | length
			The pMSK label is the 8-bit ASCII string:
			Early-Authentication Master Session Key@ietf.org
			The length field refers to the length of the pMSK in octets encoded
			as specified in [RFC5295]. SEQ is sent by either the peer or the
			server in the ERP/AAK message using SEQ field or Sequence number TLV
			and encoded as an 8-bit number specified in the 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 Extension		5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension
	Figure 4 shows the changed parameters contained in the EAP-Initiate/		Figure 5 shows the changed 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 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4		Figure 5
	Flags		Flags
	'E' - The E flag is used to indicate early-authentication.
	Reserved: MUST be set to 0.		'E' - The E flag is used to indicate early-authentication. This
			field MUST be set to '1' if early authentication is in use and MUST
			be set to '0' otherwise.
			The rest of the 7 bits (Reserved ) MUST be set to 0 and ignored on
			reception.
	TVs and TLVs		TVs and TLVs
	CAP-Identifier: Carried in a TLV payload. The format is identical to		CAP-Identifier: Carried in a TLV payload. The format is identical to
	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 is discarded silently.		peer, it is discarded silently.
	5.2. EAP-Initiate/Re-auth Packet Extension		5.2. EAP-Initiate/Re-auth Packet and TLV Extension
	Figure 5 illustrates the changed parameters contained in the EAP-		Figure 6 illustrates the changed 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 5		Figure 6
	Flags		Flags
	'x' - The x flag is reserved. It MUST be set to 0.		'x' - The x flag is reserved. It MUST be set to 0.
	'E' - The E flag is used to indicate early-authentication.		'E' - The E flag is used to indicate early-authentication.
	The rest of the 4 bits (Resved) MUST be set to 0 and ignored on		The rest of the 4 bits (Resved) MUST be set to 0 and ignored on
	reception.		reception.
	SEQ		SEQ
	A 16-bit sequence number is used for replay protection.		As defined in Section 5.3.2 of [RFC5296],this field is 16-bit
			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. The username part of the NAI is the EMSKname		exceeding 253 octets. The username part of the NAI is the EMSKname
	used to identify the peer. The realm part of the NAI is the peer's		used to identify the peer. The realm part of the NAI is the peer's
	home domain name or the domain to which the peer is currently		home domain name if the peer communicates with the home EA server or
	attached. Exactly one keyName-NAI attribute SHALL be present in an		the domain to which the peer is currently attached (i.e., local
	EAP-Initiate/Re-auth packet.		domain name) if the peer communicates with the local EA server. The
			SAP knows if the KeyName-NAI carry local domain name by comparing the
			domain name carried in KeyName-NAI with local domain name which is
			associated with the SAP and SAP has already known. Exactly one
			keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth
			packet and The realm part of it SHOULD follows the use of
			internationalized domain names defined in the RFC5890 [RFC5890].
	CAP-Identifier: Carried in a TLV payload. It is used to indicate the		CAP-Identifier: Carried in a TLV payload.The Type is TBD (less than
	FQDN of a CAP.		128). This field is used to indicate the FQDN of a CAP. The value
			field MUST be encoded as specified in Section 8 of RFC 3315
			[RFC3315]. There at least one instance of the CAP-Identifier TLV
			MUST be present in the ERP/AAK-Key TLV.
	Sequence number: Carried in a TV payload. The Type is TBD (less than		Sequence number: The Type is TBD (less than 128). The value field is
	128). It is used in the derivation of the pMSK for each CAP. Each		a 16-bit field and used in the derivation of the pMSK for a CAP. If
	CAP-Identifier in the packet MUST be associated with a unique		multiple CAP-Identifiers are carried,each CAP-Identifier in the
	sequence number.		packet MUST be associated with a unique sequence number and followed
			by that sequence number.
	Cryptosuite		Cryptosuite
	This field indicates the integrity algorithm used for ERP/AAK. Key		This field indicates the integrity algorithm used for ERP/AAK. Key
	lengths and output lengths are either indicated or obvious from the		lengths and output lengths are either indicated or obvious from the
	cryptosuite name. We specify some cryptosuites below:		cryptosuite name, e.g., HMAC-SHA256-128 denotes HMAC computed using
			the SHA-256 function [RFC4868] and with the 256 bit key length and
	0 RESERVED		output truncated to 128 bits [RFC2104]. We specify some cryptosuites
			below:
	1 HMAC-SHA256-64		0~1 RESERVED
	2 HMAC-SHA256-128		2 HMAC-SHA256-128
	3 HMAC-SHA256-256		3 HMAC-SHA256-256
	HMAC-SHA256-128 is mandatory to implement and should be enabled in		HMAC-SHA256-128 is mandatory to implement and should be enabled in
	the default configuration.		the default configuration.
	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,
	excluding the authentication tag field itself. The length of the		excluding the authentication tag field itself. The value field is
	field is indicated by the Cryptosuite.		calculated using the integrity algorithm indicated in the Cryptosuite
			field and rIK specified in [RFC5296] as the secret key. The length
			of the field is indicated by the Cryptosuite.
			The peer uses authentication tag to determine the validity of the
			EAP-Finish/Re-auth message originates at a server.
			If the message doesn't pass verification or authentication tag is not
			included in the message, the message SHOULD be discarded silently.
	If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is		If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is
	discarded silently.		discarded silently.
	5.3. EAP-Finish/Re-auth extension		5.3. EAP-Finish/Re-auth packet and TLV extension
	Figure 6 shows the changed parameters contained in the EAP-Finish/		Figure 7 shows the changed parameters contained in the EAP-Finish/
	Re-auth packet defined in [RFC5296].		Re-auth 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 6		Figure 7
	Flags		Flags
	'x' - The x flag is reserved. It MUST be set to 0.		'x' - The x flag is reserved. It MUST be set to 0.
	'E' - The E flag is used to indicate early-authentication.		'E' - The E flag is used to indicate early-authentication.
	The rest of the 4 bits (Resved) MUST be set to 0 and ignored on		The rest of the 4 bits (Resved) MUST be set to 0 and ignored on
	reception.		reception.
	SEQ		SEQ
	A 16-bit sequence number is used for replay protection.		As defined in Section 5.3.2 of [RFC5296], this field is 16-bit
			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. The realm part of the NAI is the home domain		exceeding 253 octets. The realm part of the NAI is the home domain
	name. Exactly one keyName-NAI attribute SHALL be present in an EAP-		name. Exactly one keyName-NAI attribute SHALL be present in an EAP-
	Finish/Re-auth packet.		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
	type is TBD. Exactly one ERP/AAK-key SHALL be present in an EAP-		type is TBD. Exactly one ERP/AAK-key SHALL only be present in an
	Finish/Re-auth packet.		EAP-Finish/Re-auth packet.
	ERP/AAK-Key ::=		ERP/AAK-Key ::=
	{ sub-TLV: CAP-Identifier }		{ sub-TLV: CAP-Identifier }
	{ sub-TLV: pMSK-lifetime }		{ sub-TLV: pMSK-lifetime }
	{ sub-TLV: pRK-lifetime }		{ sub-TLV: pRK-lifetime }
	{ sub-TLV: Cryptosuites }		{ sub-TLV: Cryptosuites }
	CAP-Identifier		CAP-Identifier
	Carried in a sub-TLV payload. It is used to indicate the		Carried in a sub-TLV payload. The Type is TBD (less than 128).
	identifier of the candidate authenticator. There exactly one		This field is used to indicate the identifier of the candidate
	instance of the CAP-Identifier TLV MUST be present in the ERP/		authenticator. The value field MUST be encoded as specified in
	AAK-Key TLV.		Section 8 of RFC 3315 [RFC3315]. There at least one instance of
			the CAP-Identifier TLV MUST be present in the ERP/ AAK-Key TLV.
	pMSK-lifetime		pMSK-lifetime
	Carried in a sub-TLV payload. The Type is TBD. The value field		Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The
	is a 32-bit field and contains the lifetime of the pMSK in		Type is TBD. The value field is an unsigned 32-bit field and
	seconds. If the 'L' flag is set, the pMSK Lifetime attribute		contains the lifetime of the pMSK in seconds. This value is
	SHOULD be present.		calculated by the server after pRK-lifetime computation upon
			receiving EAP-Initiate/Re-auth message. The rIK SHOULD share the
			same lifetime as pMSK.If the 'L' flag is set, the pMSK-Lifetime
			attribute MUST be present.
	pRK-lifetime		pRK-lifetime
	Carried in a sub-TLV payload. The Type is TBD. The value field		Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The
	is a 32-bit field and contains the lifetime of the pRK in seconds.		Type is TBD. The value field is an unsigned 32-bit field and
	If the 'L' flag is set, the pRK Lifetime attribute SHOULD be		contains the lifetime of the pRK in seconds. This value is
	present.		calculated by the server before pMSK-lifetime computation upon
			receiving EAP-Initiate/Re-auth message. If the 'L' flag is set,
			the pRK-Lifetime attribute MUST be present.
	List of Cryptosuites		List of Cryptosuites
	Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value		Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value
	field contains a list of cryptosuites, each 1 octet in length.		field contains a list of cryptosuites (at least one cryptosuite
	The allowed cryptosuite values are as specified in Section 5.2,		SHOULD be included), each 1 octet in length. The allowed
	above. The server SHOULD include this attribute if the		cryptosuite values are as specified in Section 5.2, above. The
	cryptosuite used in the EAP-Initiate/Re-auth message was not		server SHOULD include this attribute if the cryptosuite used in
	acceptable and the message is being rejected. The server MAY		the EAP-Initiate/Re-auth message was not acceptable and the
	include this attribute in other cases. The server MAY use this		message is being rejected. The server MAY include this attribute
	attribute to signal to the peer about its cryptographic algorithm		in other cases. The server MAY use this attribute to signal to
	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. Key lengths and output lengths are either indicated or obvious		AAK. HMAC-SHA256-128 is mandatory to implement and should be enabled
	from the cryptosuite name.		in the default configuration. Key lengths and output lengths are
			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,
	excluding the authentication tag field itself. The length of the		excluding the authentication tag field itself. The value field is
	field is indicated by the Cryptosuite.		calculated using the integrity algorithm indicated in the Cryptosuite
			field and rIK [RFC5296] as the integrity key. The length of the
			field is indicated by the corresponding Cryptosuite.
			The peer uses authentication tag to determine the validity of the
			EAP-Finish/Re-auth message originates at a server.
			If the message doesn't pass verification or authentication tag is not
			included in the message, the message SHOULD be discarded silently.
			If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is
			discarded silently.
	5.4. TV and TLV Attributes		5.4. TV and TLV Attributes
	With the exception of the rRK Lifetime and rMSK Lifetime TV payloads,		With the exception of the rRK-Lifetime and rMSK-Lifetime TV payloads,
	the attributes specified in Section 5.3.4 of [RFC5296] also apply to		the attributes specified in Section 5.3.4 of [RFC5296] also apply to
	this document. In this document, new attributes which may be present		this document. In this document, new attributes which may be present
	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 TBD.		o Sequence number: This is a TV payload. The type is TBD.
	o ERP/AAK-Key: This is a TLV payload. The type is TBD.		o ERP/AAK-Key: This is a TLV payload. The type is TBD.
	o pRK Lifetime: This is a TV payload. The type is TBD.		o pRK-Lifetime: This is a TV payload. The type is TBD.
	o pMSK Lifetime: This is a TV payload. The type is TBD.		o pMSK-Lifetime: This is a TV payload. The type is TBD.
	o List of Cryptosuites: This is a TLV payload. The type is TBD.		o List of Cryptosuites: This is a TLV payload. The type is TBD.
	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 of Section 6 [RFC5296] for		revised to support ERP/AAK; refer to of Section 6 [RFC5296] for
	additional guidance.		additional guidance.
	7. AAA Transport Considerations		7. AAA Transport Considerations
	AAA transport of ERP/AAK messages is the same as AAA transport of the		AAA transport of ERP/AAK messages is the same as AAA transport of the
	ERP message [RFC5296]. In addition, the document requires AAA		ERP message [RFC5296]. In addition, the document requires AAA
	transport of the ERP/AAK keying materials delivered by the ERP/AAK		transport of the ERP/AAK keying materials delivered by the ERP/AAK
	server to the CAP. Hence, a new Diameter ERP/AAK application message		server to the CAP. Hence, a new AAA message for ERP/AAK application
	should be specified to transport the keying materials.		should be specified to transport the keying materials.
	8. Security Considerations		8. Security Considerations
	This section provides an analysis of the protocol in accordance with		This section provides an analysis of the protocol in accordance with
	the AAA key management requirements specified in RFC 4962 [RFC4962].		the AAA key management requirements specified in RFC 4962 [RFC4962].
	o Cryptographic algorithm independence: ERP-AAK satisfies this		o Cryptographic algorithm independence: ERP-AAK satisfies this
	requirement. The algorithm chosen by the peer is indicated in the		requirement. The algorithm chosen by the peer for calculating the
	EAP-Initiate/Re-auth message. If the chosen algorithm is		authentication tag is indicated in the EAP-Initiate/Re-auth
	unacceptable, the EAP server returns an EAP- Finish/Re-auth		message. If the chosen algorithm is unacceptable, the EAP server
	message with Failure indication.		returns an EAP- Finish/Re-auth message with Failure indication.
	o Strong, fresh session keys: ERP-AAK results in the derivation of		o Strong, fresh session keys: ERP-AAK results in the derivation of
	strong, fresh keys that are unique for the given CAP. An pMSK is		strong, fresh keys that are unique for the given CAP. An pMSK is
	always derived on-demand when the peer requires a key with a new		always derived on-demand when the peer requires a key with a new
	CAP. The derivation ensures that the compromise of one pMSK does		CAP. The derivation ensures that the compromise of one pMSK does
	not result in the compromise of a different pMSK at any time.		not result in the compromise of a different pMSK at any time.
	o Limit key scope: The scope of all the keys derived by ERP-AAK is		o Limit key scope: The scope of all the keys derived by ERP-AAK is
	well defined. The pRK is used to derive the pIK and pMSK for the		well defined. The pRK is used to derive the pMSK for the CAP.
	CAP. Different sequence numbers for each CAP MUST be used to		Different sequence numbers for each CAP MUST be used to derive a
	derive a unique pMSK.		unique pMSK.
	o Replay detection mechanism: For replay protection of ERP-AAK		o Replay detection mechanism: For replay protection of ERP-AAK
	messages, a sequence number associated with the pMSK is used.		messages, a sequence number associated with the pMSK is used.The
			peer increments the sequence number by one after it sends an ERP/
			AAK message. The server sets the expected sequence number to the
			received sequence number plus one after verifying the validity of
			the received message and responds to the message. If multiple
			CAP-identifier are carried, a unique sequence number for each pMSK
			SHOULD be associated for each CAP-Identifier.
	o Authenticate all parties: The EAP Re-auth Protocol provides mutual		o Authenticate all parties: The EAP Re-auth Protocol provides mutual
	authentication of the peer and the server. The peer and SAP are		authentication of the peer and the server. The peer and SAP are
	authenticated via ERP. The CAP is authenticated and trusted by		authenticated via ERP. The CAP is authenticated and trusted by
	the SAP.		the SAP.
	o Peer and authenticator authorization: The peer and authenticator		o Peer and authenticator authorization: The peer and authenticator
	demonstrate possession of the same key material without disclosing		demonstrate possession of the same key material without disclosing
	it, as part of the lower layer secure authentication protocol.		it, as part of the lower layer secure authentication protocol.
	skipping to change at page 12, line 42		skipping to change at page 15, line 20
	domain-specific keys are further restricted to be used only in the		domain-specific keys are further restricted to be used only in the
	domain for which the keys are derived. Any other restrictions of		domain for which the keys are derived. Any other restrictions of
	session keys may be imposed by the specific lower layer and are		session keys may be imposed by the specific lower layer and are
	out of scope for this specification.		out of scope for this specification.
	9. IANA Considerations		9. IANA Considerations
	IANA is requested to assign four TLV type values from the registry of		IANA is requested to assign four TLV type values from the registry of
	EAP Initiate and Finish Attributes maintained at		EAP Initiate and Finish Attributes maintained at
	http://www.iana.org/assignments/eap-numbers/eap-numbers.xml.		http://www.iana.org/assignments/eap-numbers/eap-numbers.xml.
	New TLV types:		with the following assigned number:
	o Sequence number		o Sequence number: This is a TV payload. The type is 7.
	o ERP/AAK-Key		o ERP/AAK-Key: This is a TLV payload. The type is 8.
	o pRK Lifetime		o pRK Lifetime: This is a TLV payload. The type is 9.
	o pMSK Lifetime		o pMSK Lifetime: This is a TLV payload. The type is 10.
			This document reuses the crytosuites we have already created for 'Re-
			authentication Cryptosuites' in [RFC5296].
			Further, this document registers a Early authentication usage label
			from the "USRK Key Labels" name space with a value:
			EAP Early-Authentication Root Key@ietf.org
	10. Acknowledgement		10. Acknowledgement
	In writing this document, we have received reviews from many experts		In writing this document, Yungui Wang contributed to early versions
	in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and		of this document and we have received reviews from many experts in
	Semyon Mizikovsky. We apologize if we miss some of those who have		the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and
	helped us.		Semyon Mizikovsky, Stephen Farrell,Sujing Zhou. We apologize if we
			miss some of those who have helped us.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in		[RFC2119] Bradner, S., "Key words for use in
	RFCs to Indicate Requirement Levels",		RFCs to Indicate Requirement Levels",
	BCP 14, RFC 2119, March 1997.		BCP 14, RFC 2119, March 1997.
			[RFC3315] Droms, R., Ed., Bound, J., Volz, B.,
			Lemon, T., Perkins, C., and M. Carney,
			"Dynamic Host Configuration Protocol
			for IPv6 (DHCPv6)", RFC 3315,
			July 2003.
			[RFC5295] Salowey, J., Dondeti, L., Narayanan,
			V., and M. Nakhjiri, "Specification
			for the Derivation of Root Keys from
			an Extended Master Session Key
			(EMSK)", August 2008.
	[RFC5296] Narayanan, V. and L. Dondeti, "EAP		[RFC5296] Narayanan, V. and L. Dondeti, "EAP
	Extensions for EAP Re-authentication		Extensions for EAP Re-authentication
	Protocol (ERP)", RFC 5296,		Protocol (ERP)", RFC 5296,
	August 2008.		August 2008.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev,		[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev,
	"Diameter Attribute-Value Pairs for		"Diameter Attribute-Value Pairs for
	Cryptographic Key Transport",		Cryptographic Key Transport",
	draft-ietf-dime-local-keytran-14 (work		draft-ietf-dime-local-keytran-14 (work
	in progress), August 2011.		in progress), August 2011.
			[RFC2104] Krawczyk, H., Bellare, M., and R.
			Canetti, "HMAC: Keyed-Hashing for
			Message Authentication", RFC 2104,
			February 1997.
	[RFC3588] Calhoun, P., Loughney, J., Guttman,		[RFC3588] Calhoun, P., Loughney, J., Guttman,
	E., Zorn, G., and J. Arkko, "Diameter		E., Zorn, G., and J. Arkko, "Diameter
	Base Protocol", RFC 3588,		Base Protocol", RFC 3588,
	September 2003.		September 2003.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J.,		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J.,
	Carlson, J., and H. Levkowetz,		Carlson, J., and H. Levkowetz,
	"Extensible Authentication Protocol		"Extensible Authentication Protocol
	(EAP)", RFC 3748, June 2004.		(EAP)", RFC 3748, June 2004.
			[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-
			SHA-256, HMAC-SHA-384, and HMAC-SHA-
			512 with IPsec", RFC 4868, May 2007.
	[RFC4962] Housley, R. and B. Aboba, "Guidance		[RFC4962] Housley, R. and B. Aboba, "Guidance
	for Authentication, Authorization, and		for Authentication, Authorization, and
	Accounting (AAA) Key Management",		Accounting (AAA) Key Management",
	BCP 132, RFC 4962, July 2007.		BCP 132, RFC 4962, July 2007.
	[RFC5836] Ohba, Y., Wu, Q., and G. Zorn,		[RFC5836] Ohba, Y., Wu, Q., and G. Zorn,
	"Extensible Authentication Protocol		"Extensible Authentication Protocol
	(EAP) Early Authentication Problem		(EAP) Early Authentication Problem
	Statement", RFC 5836, April 2010.		Statement", RFC 5836, April 2010.
			[RFC5890] Klensin, J., "Internationalized Domain
			Names for Applications (IDNA):
			Definitions and Document Framework",
			RFC 5890, August 2010.
	Authors' Addresses		Authors' Addresses
	Zhen Cao		Zhen Cao
	China Mobile		China Mobile
	53A Xibianmennei Ave., Xuanwu District		53A Xibianmennei Ave., Xuanwu District
	Beijing, Beijing 100053		Beijing, Beijing 100053
	P.R. China		P.R. China
	EMail: zehn.cao@gmail.com		EMail: zehn.cao@gmail.com
	Hui Deng		Hui Deng
	China Mobile		China Mobile
	53A Xibianmennei Ave., Xuanwu District		53A Xibianmennei Ave., Xuanwu District
	Beijing, Beijing 100053		Beijing, Beijing 100053
	P.R. China		P.R. China
	EMail: denghui02@gmail.com		EMail: denghui02@gmail.com
	Yungui Wang
	Huawei Technologies Co., Ltd.
	Floor 10, HuiHong Mansion, No.91 BaiXia Rd.
	Nanjing, Jiangsu 210001
	P.R. China
	Phone: +86 25 84565893
	EMail: w52006@huawei.com
	Qin Wu		Qin Wu
	Huawei Technologies Co., Ltd.		Huawei
	Floor 12, HuiHong Mansion, No.91 BaiXia Rd.		Floor 12, HuiHong Mansion, No.91 BaiXia Rd.
	Nanjing, Jiangsu 210001		Nanjing, Jiangsu 210001
	P.R. China		P.R. China
	Phone: +86 25 84565892		Phone: +86 25 56623633
	EMail: bill.wu@huawei.com		EMail: sunseawq@huawei.com
	Glen Zorn (editor)		Glen Zorn
	Network Zen		Network Zen
	227/358 Thanon Sanphawut		227/358 Thanon Sanphawut
	Bang Na, Bangkok 10260		Bang Na, Bangkok 10260
	Thailand		Thailand
	Phone: +66 (0) 87-040-4617		Phone: +66 (0) 87-040-4617
	EMail: glenzorn@gmail.com		EMail: glenzorn@gmail.com
End of changes. 75 change blocks.
	182 lines changed or deleted		323 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/