draft-ietf-hokey-erp-aak-07.txt		draft-ietf-hokey-erp-aak-08.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: July 20, 2012 Q. Wu		Expires: August 11, 2012 Q. Wu
	Huawei		Huawei
	G. Zorn		G. Zorn
	Network Zen		Network Zen
	January 17, 2012		February 8, 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-07		draft-ietf-hokey-erp-aak-08
	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 July 20, 2012.		This Internet-Draft will expire on August 11, 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 26		skipping to change at page 2, line 26
	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 Description . . . . . . . . . . . . . . . . . . . . . 4
	4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 6		4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 6
	4.1. pRK, pMSK derivation . . . . . . . . . . . . . . . . . . . 7		4.1. pRK, pMSK derivation . . . . . . . . . . . . . . . . . . . 7
	5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 8		5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 8
	5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 8		5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 8
	5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 8		5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 8
	5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 10		5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 10
	5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 13		5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 13
	6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 13		6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 13
	7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 13		7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	AAA Authentication, Authorization and Accounting [RFC3588]		AAA Authentication, Authorization and Accounting [RFC3588]
	CAP Candidate Attachment Point [RFC5836]		CAP Candidate Attachment Point [RFC5836]
	EA Abbreviation for "ERP/AAK"; used in figures		EA Abbreviation for "ERP/AAK"; used in figures
	MH Mobile Host		MH Mobile Host
	SAP Serving Attachment Point [RFC5836]		SAP Serving Attachment Point [RFC5836]
	3. ERP/AAK Overview		3. ERP/AAK Description
	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) upon request
			by the peer.
	In this document, ERP/AAK support for the peer is assumed. Also it		In this document, ERP/AAK support for the peer is assumed. Also it
	is assumed that the peer has previously completed full EAP		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. Note that the behavior of the peer		neighboring attachment points. Note that the behavior of the peer
	that does not support the ERP-AAK scheme defined in this		that does not support the ERP-AAK scheme defined in this
	specification is out of the scope of this document.Figure 1 shows the		specification is out of the scope of this document.Figure 1 shows the
	general protocol exchange by which the keying material is established		general protocol exchange by which the keying material is established
	on the CAP.		on the CAP.
	skipping to change at page 5, line 51		skipping to change at page 5, line 51
	RFC5296 and used to protect the integrity of the message. The		RFC5296 and used to protect the integrity of the message. The
	sequence number is used for replay protection.		sequence number is used for replay protection.
	The SAP SHOULD verify the integrity of the message at step b. If		The SAP SHOULD verify the integrity of the message at step b. If
	This verifications fail, the SAP MUST send an EAP- Finish/Re-auth		This verifications fail, the SAP MUST send an EAP- Finish/Re-auth
	message with the Result flag set to '1' (Failure).In success case,		message with the Result flag set to '1' (Failure).In success case,
	the SAP SHOULD encapsulate the early-authentication message into a		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		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).		indicated in the keyName-NAI field (see c. in the figure 1).
	Upon receiving the message, the ERP/AAK server first uses the keyName		Upon receiving the message, the ERP/AAK server MUST first use the
	indicated in the keyName-NAI to look up the rIK and checks the		keyName indicated in the keyName-NAI to look up the rIK and MUST
	integrity and freshness of the message, then verifies the identity of		check the integrity and freshness of the message. Then the ERP/AAK
	the peer by checking the username portion of the KeyName-NAI. If any		server MUST verify the identity of the peer by checking the username
	of the checks fail, the server SHOULD send an early- authentication		portion of the KeyName-NAI. If any of the checks fail, the server
	finish message (EAP-Finish/Re-auth with E-flag set) with the Result		MUST send an early- authentication finish message (EAP-Finish/Re-auth
	flag set to '1'. Next, the server SHOULD authorize the CAP specified		with E-flag set) with the Result flag set to '1'. Next, the server
	in the CAP-Identifier TLV. In success case, the server derives a		MUST authorize the CAP specified in the CAP-Identifier TLV. In
	pMSK from the pRK for each CAP carried in the the CAP-Identifier		success case, the server MUST derive a pMSK from the pRK for each CAP
	field using the sequence number associated with CAP-Identifier as an		carried in the the CAP-Identifier field using the sequence number
	input to the key derivation. (see d. in the figure 1)		associated with CAP-Identifier as an input to the key derivation.
			(see d. in the figure 1)
	Then The ERP/AAK server transports the pMSK to the authorized CAP via		Then The ERP/AAK server MUST transport the pMSK to the authorized CAP
	AAA Section 7 as described in figure 2 (see e.1,e.2 in the figure 2).		via AAA Section 7 as described in figure 2 (see e.1,e.2 in the figure
	Note that key distribution in the figure 2 is one part of step d. in		2). Note that key distribution in the figure 2 is one part of step
	the figure 1.		d. in the figure 1.
	Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK		Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK
	server sends the early-authentication finish message (EAP-Finish/		server SHOULD send the early-authentication finish message (EAP-
	Re-auth with E-flag set) containing the identity of the authorized		Finish/ Re-auth with E-flag set) containing the identity of the
	CAP to the peer via the SAP and associated lifetime of pMSK,		authorized CAP to the peer via the SAP and associated lifetime of
	Optionally, if the peer also requests the server for the rRK		pMSK, OPTIONALLY, if the peer also requests the server for the rRK
	lifetime, the EA server SHOULD send the rRK lifetime in the EAP-		lifetime, the ERP/AAK server SHOULD send the rRK lifetime in the EAP-
	Finish/Re-auth message. (see f.,g. in the figure 1).		Finish/Re-auth message. (see f.,g. in the figure 1).
	4. ERP/AAK Key Hierarchy		4. ERP/AAK Key Hierarchy
	As an extension of ERP, ERP/AAK uses a key hierarchy similar to that		As an extension of ERP, ERP/AAK uses a key hierarchy similar to that
	of ERP. The ERP/AAK pre-established Root Key (pRK) is derived from		of ERP. The ERP/AAK pre-established Root Key (pRK) is derived from
	either EMSK or DSRK as specified in the section 4.1. In general, the		either EMSK or DSRK as specified in the section 4.1. In general, the
	pRK is derived from the EMSK in case of the peer moving in the home		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		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/		visited realm. The DSRK is delivered from the EAP server to the ERP/
	skipping to change at page 8, line 43		skipping to change at page 8, line 43
	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 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 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 |
	skipping to change at page 9, line 42		skipping to change at page 9, line 42
	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 if the peer communicates with the home EA server or		home domain name if the peer communicates with the home EA server or
	the domain to which the peer is currently attached (i.e., local		the domain to which the peer is currently attached (i.e., local
	domain name) if the peer communicates with the local EA server. The		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		SAP knows whether the KeyName-NAI carries the local domain name by
	domain name carried in KeyName-NAI with local domain name which is		comparing the domain name carried in KeyName-NAI with local domain
	associated with the SAP and SAP has already known. Exactly one		name which is associated with the SAP and SAP has already known.
	keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth		Exactly one keyName-NAI attribute SHALL be present in an EAP-
	packet and The realm part of it SHOULD follows the use of		Initiate/Re-auth packet and The realm part of it SHOULD follows the
	internationalized domain names defined in the RFC5890 [RFC5890].		use of internationalized domain names defined in the RFC5890
			[RFC5890].
	CAP-Identifier: Carried in a TLV payload.The Type is TBD (less than		CAP-Identifier: Carried in a TLV payload.The Type is TBD (less than
	128). This field is used to indicate the FQDN of a CAP. The value		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		field MUST be encoded as specified in Section 8 of RFC 3315
	[RFC3315]. There at least one instance of the CAP-Identifier TLV		[RFC3315]. There at least one instance of the CAP-Identifier TLV
	MUST be present in the ERP/AAK-Key TLV.		MUST be present in the ERP/AAK-Key TLV.
	Sequence number: The Type is TBD (less than 128). The value field is		Sequence number: The Type is TBD (less than 128). The value field is
	a 16-bit field and used in the derivation of the pMSK for a CAP. If		a 16-bit field and used in the derivation of the pMSK for a CAP. If
	multiple CAP-Identifiers are carried,each CAP-Identifier in the		multiple CAP-Identifiers are carried,each CAP-Identifier in the
	packet MUST be associated with a unique sequence number and followed		packet MUST be associated with a unique sequence number and followed
	by that sequence number.		by that sequence number.
	Cryptosuite		Cryptosuite
	skipping to change at page 10, line 27		skipping to change at page 10, line 29
	the SHA-256 function [RFC4868] and with the 256 bit key length and		the SHA-256 function [RFC4868] and with the 256 bit key length and
	output truncated to 128 bits [RFC2104]. We specify some cryptosuites		output truncated to 128 bits [RFC2104]. We specify some cryptosuites
	below:		below:
	0~1 RESERVED		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 REQUIRED to implement and SHOULD be enabled in the
	the default configuration.		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 value field is		excluding the authentication tag field itself. The value field is
	calculated using the integrity algorithm indicated in the Cryptosuite		calculated using the integrity algorithm indicated in the Cryptosuite
	field and rIK specified in [RFC5296] as the secret key. The length		field and rIK specified in [RFC5296] as the secret key. The length
	of the field is indicated by the Cryptosuite.		of the field is indicated by the Cryptosuite.
	The peer uses authentication tag to determine the validity of the		The peer uses authentication tag to determine the validity of the
	EAP-Finish/Re-auth message originates at a server.		EAP-Finish/Re-auth message originates at a server.
	If the message doesn't pass verification or authentication tag is not		If the message doesn't pass verification or authentication tag is not
	included in the message, the message SHOULD be discarded silently.		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
	discarded silently.		SHOULD be discarded silently.
	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 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 |
	skipping to change at page 11, line 37		skipping to change at page 11, line 37
	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
	exceeding 253 octets. The realm part of the NAI is the home domain		exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be
	name. Exactly one keyName-NAI attribute SHALL be present in an EAP-		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 only be present in an		type is TBD. Exactly one ERP/AAK-key SHALL only be present in an
	EAP-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 }
	skipping to change at page 15, line 33		skipping to change at page 15, line 33
	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.
	This document reuses the crytosuites we have already created for 'Re-		This document reuses the crytosuites we have already created for 'Re-
	authentication Cryptosuites' in [RFC5296].		authentication Cryptosuites' in [RFC5296].
	Further, this document registers a Early authentication usage label		Further, this document instructs IANA to add a new label in the User
	from the "USRK Key Labels" name space with a value:		Specific Root Keys (USRK) Key Labels of the Extended Master Session
			Key (EMSK) Parameters registry, as follows:
	EAP Early-Authentication Root Key@ietf.org		EAP Early-Authentication Root Key@ietf.org
	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 and		the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and
	Semyon Mizikovsky, Stephen Farrell,Sujing Zhou. We apologize if we		Semyon Mizikovsky, Stephen Farrell,Sujing Zhou. We apologize if we
	miss some of those who have helped us.		miss some of those who have helped us.
End of changes. 17 change blocks.
	43 lines changed or deleted		47 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/