draft-ietf-hokey-erp-aak-03.txt		draft-ietf-hokey-erp-aak-04.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: May 12, 2011 Y. Wang		Expires: September 15, 2011 Y. Wang
	Q. Wu		Q. Wu
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	G. Zorn		G. Zorn
	Network Zen		Network Zen
	November 8, 2010		March 14, 2011
	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-03		draft-ietf-hokey-erp-aak-04
	Abstract		Abstract
	The Extensible Authentication Protocol (EAP) is a generic framework		The Extensible Authentication Protocol (EAP) is a generic framework
	supporting multiple of authentication methods.		supporting multiple 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 2, line 4
	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 May 12, 2011.		This Internet-Draft will expire on September 15, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 2, line 33		skipping to change at page 2, line 33
	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 . . . . . . . . . . . . . . . . . . . . 5
	5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6		5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6
	5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6		5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6
	5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7		5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7
	5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 9		5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 9
	5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 11		5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 10
	6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11		6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11
	7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11		7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . . 12		11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
			11.2. Informative References . . . . . . . . . . . . . . . . . . 13
	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 8		skipping to change at page 4, line 8
	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 Overview
	ERP/AAK is intended to allow the establishment of cryptographic		ERP/AAK is intended to allow the establishment of cryptographic
	keying materials on one or more Candidate Attachment Points prior to		keying materials on a single Candidate Attachment Points prior to the
	the arrival of the MH at the Candidate Access Network (CAN). The		arrival of the MH at the Candidate Access Network (CAN). The
	document also specifies a method by which the SAP may send the		document also specifies a method by which the SAP may send the
	identities of neighboring attachment points to the peer in the EAP-		identities of neighboring attachment points to the peer in the EAP-
	Initiate/Re-auth-Start message.		Initiate/Re-auth-Start message.
	It is assumed that the peer has previously completed full EAP		It is assumed that the peer has previously completed full EAP
	authentication. Figure 1 shows the general protocol exchange by		authentication. Figure 1 shows the general protocol exchange by
	which the keying material is established on the CAP(s).		which the keying material is established on the CAP. This document
			only discusses the case of distributing the key to a single CAP.
			+------+ +-----+ +-----+ +-----------+
			| Peer | | SAP | | CAP | | EA Server |
			+--+---+ +--+--+ +--+--+ +-----+-----+
			| | | |
			1. | [EAP-Initiate/ | | |
			| Re-auth-start | | |
			| (E-flag) | | |
			|<---------------| | |
			| | | |
			2. | EAP-Initiate/ | | |
			| Re-auth | | |
			| (E-flag) | | |
			|--------------->| | |
			3. | | AAA(EAP-Initiate/Re-auth(E-flag))|
			| |--------------------------------->|
			| | | +---------+---------+
			| | | | CA authorized & |
			4. | | | | authenticated; |
			| | | | EA keying |
			| | | | materials derived |
			| | | +---------+---------+
			5. | | | |
			| | | AAA(pMSK) |
			| | |<----------------->|
			| | | |
			6. | | AAA (EAP-Finish/Re-auth(E-flag)) |
			| |<---------------------------------|
			7. | EAP-Finish/ | | |
			| Re-auth(E-flag)| | |
			|<---------------| | |
			| | | |
	+------+ +-----+ +-----+ +-----+ +-----------+
	| Peer | | SAP | |CAP1 | |CAPx | | EA Server |
	+--+---+ +--+--+ +--+--+ +--+--+ +-----+-----+
	| | | | |
	1. | [EAP-Initiate/ | | |
	| Re-auth-start | | |
	| (E-flag) | | | |
	|<----------| | | |
	| | | | |
	2. | EAP-Initiate/ | | |
	| Re-auth | | | |
	| (E-flag) | | | |
	|---------->| | | |
	3. | | AAA (EAP-Initiate/Re-auth(E-flag))|
	| |---------------------------------->|
	| | | | |
	| | | | +---------+---------+
	| | | | | CA authorized & |
	4. | | | | | authenticated; |
	| | | | | EA keying |
	| | | | | materials derived |
	| | | | +---------+---------+
	| | | | |
	5. | | | | AAA(pMSKx) |
	| | |AAA(pMSK1)|<----------->|
	| | |<---------------------->|
	| | | | |
	6. | | AAA (EAP-Finish/Re-auth(E-flag)) |
	| |<----------------------------------|
	| | | | |
	7. | EAP-Finish/ | | |
	| Re-auth(E-flag) | | |
	|<----------| | | |
	| | | | |
	Figure 1: ERP/AAK Operation		Figure 1: ERP/AAK Operation
	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. In
	this document, it is required that the SAP should support ERP/AAK.		this document, it is required that the SAP should support ERP/AAK.
	If either the peer or the SAP does not support ERP/AAK, it should		If either the peer or the SAP does not support ERP/AAK, it should
	fall back to full EAP authentication.		fall back to full EAP authentication.
	The peer sends an early-authentication request message (EAP-Initiate/		The peer sends an early-authentication request message (EAP-Initiate/
	Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS-		Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS-
	Identifier, rIK and sequence number. The realm in the keyName-NAI		Identifier, rIK and sequence number. The realm in the keyName-NAI
	field is used to locate the peer's ERP/AAK server. The NAS-		field is used to locate the peer's ERP/AAK server. The NAS-
	Identifier is used to identify the CAP(s). The rIK is used to		Identifier is used to identify the CAP. The rIK is used to protect
	protect the message. The sequence number is used for replay		the message. The sequence number is used for replay protection. To
	protection. To avoid the same pre-established Master Session Key		avoid the same pre-established Master Session Key (pMSK) being
	(pMSK) being derived for multiple CAPs, the sequence number MUST be		derived for multiple CAPs, the sequence number MUST be unique for
	unique for each CAP.		each CAP.
	The SAP encapsulates the early-authentication message into a AAA		The SAP encapsulates the early-authentication message into a AAA
	message and sends it to the peer's ERP/AAK server in the realm		message and sends it to the peer's ERP/AAK server in the realm
	indicated in the keyName-NAI field.		indicated in the keyName-NAI field.
	Upon receiving the message, the ERP/AAK server first checks its		Upon receiving the message, the ERP/AAK server first checks its
	integrity and freshness, then authenticates and authorizes the CAP(s)		integrity and freshness, then authenticates and authorizes the CAP
	presented in the NAS-Identifier TLV(s). After the CAP(s) is		presented in the NAS-Identifier TLV(s). After the CAP is
	authenticated and authorized successfully, the ERP/AAK server derives		authenticated and authorized successfully, the ERP/AAK server derives
	the pRK and the subsequent pMSK for each CAP.		the pRK and the subsequent pMSK for the CAP.
	The ERP/AAK server transports the pMSK to the authenticated and		The ERP/AAK server transports the pMSK to the authenticated and
	authorized CAP(s) via AAA as described in Section 7. After the		authorized CAP(s) via AAA as described in Section 7.
	keying materials are delivered, the ERP/AAK server should determine
	each CA whether accepts the pMSK and whether the peer could be
	attached to.
	At last, the ERP/AAK server sends the early-authentication finish		Finally, the ERP/AAK server sends the early-authentication finish
	message (EAP-Finish/Re-auth with E-flag set) containing the		message (EAP-Finish/Re-auth with E-flag set) containing the
	determinate CAP(s) to the peer via the SAP.		determinated CAP to the peer via the SAP.
	4. ERP/AAK Key Hierarchy		4. ERP/AAK Key Hierarchy
	As an optimization of ERP, ERP/AAK uses key hierarchy similar to that		As an optimization of ERP, ERP/AAK uses key hierarchy similar to that
	of ERP. The EMSK is used to derive the ERP/AAK pre-established Root		of ERP. The EMSK is used to derive the ERP/AAK pre-established Root
	Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key		Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key
	(pIK) and the pre-established Master Session Key (pMSK) are derived		(pIK) and the pre-established Master Session Key (pMSK) are derived
	from the pRK. The pMSK is established for the CAP(s) when the peer		from the pRK. The pMSK is established for the CAP(s) when the peer
	early authenticates to the network. The pIK is established for the		early authenticates to the network. The pIK is established for the
	peer to re-authenticate the network after handover. The hierarchy		peer to re-authenticate the network after handover. The hierarchy
	skipping to change at page 8, line 26		skipping to change at page 8, line 16
	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 identify the peer. The realm part of the NAI is the peer's home		used 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 attached.		domain name or the domain to which the peer is currently attached.
	Exactly one keyName-NAI attribute SHALL be present in an EAP-		Exactly one keyName-NAI attribute SHALL be present in an EAP-
	Initiate/Re-auth packet.		Initiate/Re-auth packet.
	NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a		NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a
	TLV payload. It is used to indicate the identifier of a CAP. One or		TLV payload. It is used to indicate the identifier of a CAP. Though
	more NAS-Identifier may be included in the EAP-Initiate/Re-auth		this document only introduces the case of a single CAP, two or more
	packet.		NAS-Identifier may be included in the EAP-Initiate/Re-auth packet to
			identify multiple CAPs.
	Sequence number: It is carried in a TV payload. The Type is TBD		Sequence number: It is carried in a TV payload. The Type is TBD
	(which is lower than 128). It is used in the derivation of the pMSK		(which is lower than 128). It is used in the derivation of the pMSK
	for each CAP to avoid multiple CAP using the same pMSK. Each NAS-		for each CAP to avoid multiple CAP using the same pMSK. Each NAS-
	Identifier in the packet MUST be associated with a unique sequence		Identifier in the packet MUST be associated with a unique sequence
	number.		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
	skipping to change at page 11, line 51		skipping to change at page 11, line 43
	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 Diameter ERP/AAK application message
	should be specified to transport the keying materials.		should be specified to transport the keying materials.
	8. Security Considerations		8. Security Considerations
	TBD.		This section provides an analysis of the protocol in accordance with
			the AAA key management requirements specified in [RFC4962]
			o Cryptographic algorithm independence: ERP-AAK satisfies this
			requirement. The algorithm chosen by the peer is indicated in the
			EAP-Initiate/Re-auth message. If the chosen algorithm is
			unacceptable, the EAP server returns an EAP- Finish/Re-auth
			message with Failure indication
			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
			always derived on-demand when the peer requires a key with a new
			CAP. The derivation ensures that the compromise of one pMSK does
			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
			well defined. The pRK is used to derive the pIK and pMSK for the
			CAP. Different sequence numbers for each CAP MUST be used to
			derive the unique pMSK.
			o Replay detection mechanism: For replay protection of ERP-AAK
			messages, a sequence number associated with the pMSK is used.
			o Authenticate all parties: The EAP Re-auth Protocol provides mutual
			authentication of the peer and the server. The peer and SAP are
			authenticated via ERP. The CAP is authenticated and trusted by
			the SAP.
			o Peer and authenticator authorization: The sequence number is
			maintained by the peer and the server, and incremented by them
			synchronously.
			o Keying material confidentiality: The peer and the server derive
			the keys independently using parameters known to each entity.
			o Uniquely named keys: All keys produced within the ERP context can
			be referred to uniquely as specified in this document.
			o Prevent the domino effect: Different sequence numbers for each CAP
			MUST be used to derive the unique pMSK. So the compromise of one
			pMSK does not hurt any other CAP.
			o Bind key to its context: the pMSK are binded to the context where
			the sequence numbers are transmitted.
			o Confidentiality of identity: this is the same with ERP protocol as
			analyzed in [RFC5296].
			o Authorization restriction: All the keys derived are limited in
			lifetime by that of the parent key or by server policy. Any
			domain-specific keys are further restricted for use only in the
			domain for which the keys are derived. Any other restrictions of
			session keys may be imposed by the specific lower layer and are
			out of scope for this specification.
	9. IANA Considerations		9. IANA Considerations
	New TLV types:		New TLV types:
	NAS-Identifier
	Sequence number		Sequence number
	ERP/AAK-Key		ERP/AAK-Key
	New sub-TLV types:		New sub-TLV types:
	NAS-Identifier
	pRK Lifetime		pRK Lifetime
	pMSK Lifetime		pMSK Lifetime
	List of Cryptosuites		10. Acknowledgement
	10. References		In writing this document, we have received reviews from many experts
			in IETF, including Tom Taylor, Tena Zou, Tim Polk. We apologize if
			we miss some names that have helped us.
	10.1. Normative References		11. 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.
	[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.
	10.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-08 (work		draft-ietf-dime-local-keytran-08 (work
	in progress), October 2010.		in progress), October 2010.
	[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.
			[RFC4962] Housley, R. and B. Aboba, "Guidance
			for Authentication, Authorization, and
			Accounting (AAA) Key Management",
			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.
	Authors' Addresses		Authors' Addresses
	Zhen Cao		Zhen Cao
	China Mobile		China Mobile
	53A Xibianmennei Ave., Xuanwu District		53A Xibianmennei Ave., Xuanwu District
End of changes. 25 change blocks.
	73 lines changed or deleted		129 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/