draft-ietf-hokey-reauth-ps-03.txt		draft-ietf-hokey-reauth-ps-04.txt
	HOKEY Working Group T. Clancy, Ed.		HOKEY Working Group T. Clancy, Editor
	Internet-Draft LTS		Internet-Draft LTS
	Intended status: Informational September 10, 2007		Intended status: Informational September 28, 2007
	Expires: March 13, 2008		Expires: March 31, 2008
	Handover Key Management and Re-authentication Problem Statement		Handover Key Management and Re-authentication Problem Statement
	draft-ietf-hokey-reauth-ps-03		draft-ietf-hokey-reauth-ps-04
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 13, 2008.		This Internet-Draft will expire on March 31, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes the Handover Keying (HOKEY) problem		This document describes the Handover Keying (HOKEY) problem
	statement. The current EAP keying framework is not designed to		statement. The current EAP keying framework is not designed to
	support re-authentication and handovers. This often cause		support re-authentication and handovers. This often cause
	unacceptable latency in various mobile wireless environments. HOKEY		unacceptable latency in various mobile wireless environments. HOKEY
	plans to address these HOKEY plans to address these problems by		plans to address these HOKEY plans to address these problems by
	implementing a generic mechanism to reuse derived EAP keying material		implementing a generic mechanism to reuse derived EAP keying material
	for handover.		for handover.
	Table of Contents		Table of Contents
	1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5		4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
	5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7		6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6
	6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 8		6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
	6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8		6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7
	6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8		6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7
	6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8		6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7
	6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8		6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
	7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9		7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8
	7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9		7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8
	7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 10		7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 9
	7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10		7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9
	7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 10		7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 13		Intellectual Property and Copyright Statements . . . . . . . . . . 12
	1. Authors		1. Contributors
	The following authors contributed to the HOKEY problem statement		The following authors contributed to the HOKEY problem statement
	draft:		document:
	o Julien Bournelle, France Telecom R&D,		o Julien Bournelle, France Telecom R&D,
	julien.bournelle@orange-ftgroup.com		julien.bournelle@orange-ftgroup.com
	o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com		o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com
	o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es		o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es
	o Madjid Nakhjiri, Huawei, mnakhjiri@huawei.com		o Madjid Nakhjiri, Motorola, madjid.nakhjiri@motorola.com
	o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com		o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com
	o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com		o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com
	o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com		o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com
	2. Introduction		2. Introduction
	The extensible authentication protocol (EAP), specified in [RFC3748]		The Extensible Authentication Protocol (EAP), specified in RFC 3748
	is a generic framework supporting multiple authentication methods.		[RFC3748] is a generic framework supporting multiple authentication
	The primary purpose of EAP is network access control. It also		methods. The primary purpose of EAP is network access control. It
	supports exporting session keys derived during the authentication.		also supports exporting session keys derived during the
	The EAP keying hierarchy defines two keys that are derived at the top		authentication. The EAP keying hierarchy defines two keys that are
	level, the master session key (MSK) and the extended MSK (EMSK).		derived at the top level, the master session key (MSK) and the
			extended MSK (EMSK).
	In many common deployment scenario, an EAP peer and EAP server		In many common deployment scenario, an EAP peer and EAP server
	authenticate each other through a third party known as the pass-		authenticate each other through a third party known as the pass-
	through authenticator (hereafter referred to as simply		through authenticator (hereafter referred to as simply
	"authenticator"). The authenticator is responsible for translating		"authenticator"). The authenticator is responsible for translating
	EAP packets from the layer 2 (L2) or layer 3 (L3) network access		EAP packets from the layer 2 (L2) or layer 3 (L3) network access
	technology to the AAA protocol.		technology to the AAA protocol.
	According to [RFC3748], after successful authentication, the server		According to [RFC3748], after successful authentication, the server
	transports the MSK to the authenticator. The underlying L2 or L3		transports the MSK to the authenticator. The underlying L2 or L3
	protocol uses the MSK to derive additional keys, including the		protocol uses the MSK to derive additional keys, including the
	transient session keys (TSK) used per-packet access encryption and		transient session keys (TSK) used per-packet access encryption and
	enforcement. Figure Figure 1 depicts this process.		enforcement.
	+--------+ +---------+ +--------+
	| EAP |<----->| Authen- |<------------------->| EAP |
	| Client | L2/L3 | ticator | AAA | Server |
	+--------+ +---------+ +--------+
	^ ^
	| +---------+ |
	\-------------------------->| Authen- |<--------/
	L2/L3 | ticator | AAA
	+---------+
	Initial Authentication:
	<----------------- EAP Authentication ------------->
	<------ MSK Transport -------------
	<- TSK Generation ->
	Re-Authentication / Handover:
	<----------------- EAP Authentication ------------->
	<- MSK Transport -
	<---------- TSK Generation --------->
	Figure 1: Logical diagram of EAP authentication and key derivation
	using passthrough authenticator
	Note that while the authenticator is one logical device, there can be		Note that while the authenticator is one logical device, there can be
	many physical devices involved. For example, in the CAPWAP model		multiple physical devices involved. For example, the CAPWAP model
	[RFC3990] WTPs communicate using L2 protocols with the EAP client and		[RFC3990] splits authenticators into two logical devices: Wireless
	ACs communicate using AAA to the EAP server, while using CAPWAP		Termination Points (WTPs) and Access Controllers (ACs). Depending on
	protocols to communicate with each other. Depending on the		the configuration, authenticator features can be split in a variety
	configuration, authenticator features can be split in a variety of		of ways between physical devices, however from the EAP perspective
	ways between physical devices, however from the EAP perspective there		there is only one logical authenticator.
	is only one logical authenticator.
	The current models of EAP authentication and keying are unfortunately		The current models of EAP authentication and keying are unfortunately
	not efficient in case of mobile and wireless networks. When a peer		not efficient in case of mobile and wireless networks. When a peer
	arrives at the new authenticator, or is expected to re-affirm its		arrives at the new authenticator, or is expected to re-affirm its
	access through the current authenticator, the security restraints		access through the current authenticator, the security restraints
	will require the peer to run an EAP method irrespective of whether it		will require the peer to run an EAP method irrespective of whether it
	has been authenticated to the network recently and has unexpired		has been authenticated to the network recently and has unexpired
	keying material. A full EAP method execution involves several round		keying material. A full EAP method execution may involves several
	trips between the EAP peer and the server.		round trips between the EAP peer and the server.
	There have been attempts to solve the problem of efficient re-		There have been attempts to solve the problem of efficient re-
	authentication in various ways. However, those solutions are either		authentication in various ways. However, those solutions are either
	EAP-method specific, EAP lower-layer specific, or are otherwise		EAP-method specific, EAP lower-layer specific, or are otherwise
	limited in scope. Furthermore, these solutions do not deal with		limited in scope. Furthermore, these solutions do not deal with
	scenarios involving handovers to new authenticators, or do not		scenarios involving handovers to new authenticators, or do not
	conform to the AAA keying requirements specified in [RFC4962].		conform to the AAA keying requirements specified in [RFC4962].
	This document provides a detailed description of EAP efficient re-		This document provides a detailed description of EAP efficient re-
	authentication protocol requirements.		authentication protocol requirements.
	3. Terminology		3. Terminology
	In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
	of the specification. These words are often capitalized. The key		of the specification. These words are often capitalized. The key
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
	"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document		"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
	are to be interpreted as described in [RFC2119].		are to be interpreted as described in [RFC2119].
	This document follows the terminology that has been defined in		With respect to EAP, this document follows the terminology that has
	[RFC3748].		been defined in [RFC3748] and [I-D.ietf-eap-keying].
	4. Problem Statement		4. Problem Statement
	When a peer needs to re-affirm access to an authenticator or moves		When a peer needs to re-affirm access to an authenticator or moves
	from one authenticator and reattaches to another authenticator, the		from one authenticator to another, the current model requires the
	current EAP keying model requires the peer to engage in a full EAP		peer to engage in a full EAP exchange with the EAP server in its home
	exchange with the authentication server in its home domain [RFC3748].		domain [RFC3748].
	An EAP conversation with a full EAP method run takes several round		An EAP conversation with a full EAP method run can take several round
	trips and significant time to complete, causing delays in re-		trips and significant time to complete, causing delays in re-
	authentication and handover times. Some methods [RFC4187] specify		authentication and handover times. Some methods [RFC4187] specify
	the use of keys and state from the initial authentication to finish		the use of keys and state from the initial authentication to finish
	subsequent authentications in fewer round trips. However, even in		subsequent authentications in fewer round trips. However, even in
	those cases, several round trips to the EAP server are still		those cases, multiple round trips to the EAP server are still
	involved. Furthermore, many commonly-used EAP methods do not offer		involved. Furthermore, many commonly-used EAP methods do not offer
	such a fast re-authentication feature. In summary, it is undesirable		such a fast re-authentication feature. In summary, it is undesirable
	to have to run a full EAP method each time a peer associates with a		to have to run a full EAP method each time a peer authenticates to a
	new authenticator or needs to extend its current association with the		new authenticator or needs to extend its current authentication with
	same authenticator. Furthermore, it is desirable to specify a		the same authenticator. Furthermore, it is desirable to specify a
	method-independent, efficient, re-authentication protocol. Keying		method-independent, efficient, re-authentication protocol. Keying
	material from the full authentication can be used to enable efficient		material from the full authentication can be used to enable efficient
	re-authentication.		re-authentication.
	Another problem with respect to authentication is when the EAP server		Significant network latency between the peer and EAP server is
	is several hops away from the peer, causing too much delay in		another source of delay during re-authentication. It is desirable to
	executing the re-authentication. It is desirable to allow a locally		have a local server with low-latency connectivity to the peer that
	reachable server with EAP efficient re-authentication capability with		can facilitate re-authentication.
	which the peer can execute such re-authentication without having to
	involve the original EAP server all the time. An EAP re-
	authentication solution defined MUST NOT prevent its extension to a
	fast re-authentication protocol that operates between EAP servers,
	and the defined keying hierarchy MUST be designed such that this
	could be supported.
	Lastly, a re-authentication protocol should also be capable of		Lastly, a re-authentication protocol should also be capable of
	supporting handover keying. Handover keying allows re-authentication		supporting handover keying. Handover keying allows re-authentication
	keys to be passed to a different domain. Execution of the re-		keys to be passed to a different domain. Execution of the re-
	authentication protocol in that domain will then allow handover from		authentication protocol in that domain will then allow handover from
	one domain to another.		one domain to another.
	These problems are the primary issue to be resolved. In solving		These problems are the primary issues to be resolved. In solving
	them, there are a number of constraints to conform to and those		them, there are a number of constraints to conform to and those
	result in some additional work to be done in the area of EAP keying.		result in some additional work to be done in the area of EAP keying.
	5. Design Goals		5. Design Goals
	The following are the goals and constraints in designing the EAP re-		The following are the goals and constraints in designing the EAP re-
	authentication and key management protocol:		authentication and key management protocol:
	Lower latency operation: The protocol MUST be responsive to handover		Lower latency operation: The protocol MUST be responsive to handover
	and re-authentication latency performance objectives within a		and re-authentication latency performance objectives within a
	skipping to change at page 6, line 47		skipping to change at page 6, line 9
	required as a result of the re-authentication protocol. There		required as a result of the re-authentication protocol. There
	MUST be no requirements imposed on future EAP methods. Note that		MUST be no requirements imposed on future EAP methods. Note that
	the only EAP methods for which independence is required are those		the only EAP methods for which independence is required are those
	that conform to the specifications of [I-D.ietf-eap-keying] and		that conform to the specifications of [I-D.ietf-eap-keying] and
	[RFC4017].		[RFC4017].
	AAA protocol compatibility and keying: Any modifications to EAP and		AAA protocol compatibility and keying: Any modifications to EAP and
	EAP keying MUST be compatible with RADIUS and Diameter.		EAP keying MUST be compatible with RADIUS and Diameter.
	Extensions to both RADIUS and Diameter to support these EAP		Extensions to both RADIUS and Diameter to support these EAP
	modifications are acceptable. The designs and protocols must		modifications are acceptable. The designs and protocols must
	satisfy the AAA key management requirements specified in		satisfy the AAA key management requirements specified in RFC 4962
	[RFC4962].		[RFC4962].
	Compatability: Compatibility and co-existence with compliant		Compatability: Compatibility and co-existence with compliant
	([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be		([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be
	provided. The keying hierarchy or protocol extensions MUST NOT		provided. The keying hierarchy or protocol extensions MUST NOT
	preclude the use of CAPWAP or IEEE 802.11r.		preclude the use of CAPWAP or IEEE 802.11r.
	6. Security Goals		6. Security Goals
	The section draws from the guidance provided in [RFC4962] to further		The section draws from the guidance provided in [RFC4962] to further
	skipping to change at page 11, line 28		skipping to change at page 10, line 32
	and authorization. See section Section 6 for further details.		and authorization. See section Section 6 for further details.
	9. IANA Considerations		9. IANA Considerations
	This document does not introduce any new IANA considerations.		This document does not introduce any new IANA considerations.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[I-D.ietf-eap-keying]
			Aboba, B., "Extensible Authentication Protocol (EAP) Key
			Management Framework", draft-ietf-eap-keying-18 (work in
			progress), February 2007.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	RFC 3748, June 2004.		RFC 3748, June 2004.
	[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible		[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
	Authentication Protocol (EAP) Method Requirements for		Authentication Protocol (EAP) Method Requirements for
	Wireless LANs", RFC 4017, March 2005.		Wireless LANs", RFC 4017, March 2005.
	[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,		[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
	Authorization, and Accounting (AAA) Key Management",		Authorization, and Accounting (AAA) Key Management",
	BCP 132, RFC 4962, July 2007.		BCP 132, RFC 4962, July 2007.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-eap-keying]
	Aboba, B., "Extensible Authentication Protocol (EAP) Key
	Management Framework", draft-ietf-eap-keying-18 (work in
	progress), February 2007.
	[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and		[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
	Provisioning for Wireless Access Points (CAPWAP) Problem		Provisioning for Wireless Access Points (CAPWAP) Problem
	Statement", RFC 3990, February 2005.		Statement", RFC 3990, February 2005.
	[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication		[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
	Protocol Method for 3rd Generation Authentication and Key		Protocol Method for 3rd Generation Authentication and Key
	Agreement (EAP-AKA)", RFC 4187, January 2006.		Agreement (EAP-AKA)", RFC 4187, January 2006.
	[IEEE.802-11R-D7.0]		[IEEE.802-11R-D7.0]
	"Information technology - Telecommunications and		"Information technology - Telecommunications and
End of changes. 25 change blocks.
	97 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/