draft-ietf-hokey-reauth-ps-05.txt		draft-ietf-hokey-reauth-ps-06.txt
	HOKEY Working Group T. Clancy, Editor		HOKEY Working Group T. Clancy, Editor
	Internet-Draft LTS		Internet-Draft LTS
	Intended status: Informational November 2, 2007		Intended status: Informational November 6, 2007
	Expires: May 5, 2008		Expires: May 9, 2008
	Handover Key Management and Re-authentication Problem Statement		Handover Key Management and Re-authentication Problem Statement
	draft-ietf-hokey-reauth-ps-05		draft-ietf-hokey-reauth-ps-06
	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 May 5, 2008.		This Internet-Draft will expire on May 9, 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 Extensible Authentication Protocol (EAP)
	support re-authentication and handovers. This often cause		keying framework is not designed to support re-authentication and
	unacceptable latency in various mobile wireless environments. HOKEY		handovers. This often causes unacceptable latency in various mobile
	plans to address these HOKEY plans to address these problems by		wireless environments. The HOKEY Working Group plans to address
	implementing a generic mechanism to reuse derived EAP keying material		these problems by designing a generic mechanism to reuse derived EAP
	for handover.		keying material for handover.
	Table of Contents		Table of Contents
	1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
	4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4		4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6
	6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6		5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 6
	6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7		5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 6
	6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7		5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7
	6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7		5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7
	6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7		5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7
	6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7		6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8
	7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8		6.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8
	7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8		6.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 8
	7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 9		6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9
	7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9		6.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9
	7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 12		Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Contributors
	The following authors contributed to the HOKEY problem statement
	document:
	o Julien Bournelle, France Telecom R&D,
	julien.bournelle@orange-ftgroup.com
	o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com
	o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es
	o Madjid Nakhjiri, Motorola, madjid.nakhjiri@motorola.com
	o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com
	o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com
	o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com
	2. Introduction		1. Introduction
	The Extensible Authentication Protocol (EAP), specified in RFC 3748		The Extensible Authentication Protocol (EAP), specified in RFC 3748
	[RFC3748] is a generic framework supporting multiple authentication		[RFC3748] is a generic framework supporting multiple authentication
	methods. The primary purpose of EAP is network access control. It		methods. The primary purpose of EAP is network access control. It
	also supports exporting session keys derived during the		also supports exporting session keys derived during the
	authentication. The EAP keying hierarchy defines two keys that are		authentication. The EAP keying hierarchy defines two keys that are
	derived at the top level, the master session key (MSK) and the		derived at the top level, the Master Session Key (MSK) and the
	extended MSK (EMSK).		Extended Master Session Key (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 Authentication, Authorization, and Accounting (AAA)
			protocol. The authenticator does not directly participate in the EAP
			exchange, and simply acts as a gateway during the EAP method
			execution.
	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		to transports the MSK to the authenticator. Note that this is
	protocol uses the MSK to derive additional keys, including the		performed using AAA protocols, not EAP itself. The underlying L2 or
	transient session keys (TSK) used per-packet access encryption and		L3 protocol uses the MSK to derive additional keys, including the
	enforcement.		transient session keys (TSKs) used for per-packet encryption and
			authentication.
	Note that while the authenticator is one logical device, there can be		Note that while the authenticator is one logical device, there can be
	multiple physical devices involved. For example, the CAPWAP model		multiple physical devices involved. For example, the CAPWAP model
	[RFC3990] splits authenticators into two logical devices: Wireless		[RFC3990] splits authenticators into two logical devices: Wireless
	Termination Points (WTPs) and Access Controllers (ACs). Depending on		Termination Points (WTPs) and Access Controllers (ACs). Depending on
	the configuration, authenticator features can be split in a variety		the configuration, authenticator features can be split in a variety
	of ways between physical devices, however from the EAP perspective		of ways between physical devices, however from the EAP perspective
	there is only one logical authenticator.		there 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 cases where the peer is a mobile device. When a
	arrives at the new authenticator, or is expected to re-affirm its		peer arrives at the new authenticator, the security restraints will
	access through the current authenticator, the security restraints		require the peer to run an EAP method irrespective of whether it has
	will require the peer to run an EAP method irrespective of whether it		been authenticated to the network recently and has unexpired keying
	has been authenticated to the network recently and has unexpired		material. A full EAP method execution may involve 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 efficient EAP-based
	authentication protocol requirements.		re-authentication protocol requirements.
	3. Terminology		2. 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].
	With respect to EAP, this document follows the terminology that has		With respect to EAP, this document follows the terminology that has
	been defined in [RFC3748] and [I-D.ietf-eap-keying].		been defined in [RFC3748] and [I-D.ietf-eap-keying].
	4. Problem Statement		3. Problem Statement
	Under the existing model, any re-authentication requires a full EAP		Under the existing model, any re-authentication requires a full EAP
	exchange with the EAP server in its home domain [RFC3748]. An EAP		exchange with the EAP server in its home domain [RFC3748]. An EAP
	conversation with a full EAP method run can take several round trips		conversation with a full EAP method run can take several round trips
	and significant time to complete, causing delays in re-authentication		and significant time to complete, causing delays in re-authentication
	and handover times. Some methods [RFC4187] specify the use of keys		and handover times. Some methods [RFC4187] specify the use of keys
	and state from the initial authentication to finish subsequent		and state from the initial authentication to finish subsequent
	authentications in fewer round trips. However, even in those cases,		authentications in fewer round trips. However, even in those cases,
	multiple round trips to the EAP server are still involved.		multiple round trips to the EAP server are still involved.
	Furthermore, many commonly-used EAP methods do not offer such a fast		Furthermore, many commonly-used EAP methods do not offer such a fast
	skipping to change at page 5, line 11		skipping to change at page 4, line 45
	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.
	Significant network latency between the peer and EAP server is		Significant network latency between the peer and EAP server is
	another source of delay during re-authentication. It is desirable to		another source of delay during re-authentication. It is desirable to
	have a local server with low-latency connectivity to the peer that		have a local server with low-latency connectivity to the peer that
	can facilitate re-authentication.		can facilitate re-authentication.
	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 an EAP server to
	keys to be passed to a different re-authentication domain (not		pass authentication information to a remote re-authentication server,
	necessarily a different AAA domain or administrative domain).		allowing a peer to re-authenticate to that re-authentication server
	Execution of the re-authentication protocol in that re-authentication		without having to communicate with its home re-authentication server.
	domain will then allow handover from one re-authentication domain to
	another.
	These problems are the primary issues 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		4. 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
	mobile access network. A solution that reduces latency as		mobile access network. A solution that reduces latency as
	compared to a full EAP authentication will be most favorable.		compared to a full EAP authentication will be most favorable.
	EAP lower-layer independence: Any keying hierarchy and protocol		EAP lower-layer independence: Any keying hierarchy and protocol
	skipping to change at page 6, line 10		skipping to change at page 5, line 45
	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 RFC 4962		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		5. Security Goals
	The section draws from the guidance provided in [RFC4962] to further		The section draws from the guidance provided in [RFC4962] to further
	define the security goals to be achieved by a complete re-		define the security goals to be achieved by a complete re-
	authentication keying solution.		authentication keying solution.
	6.1. Key Context and Domino Effect		5.1. Key Context and Domino Effect
	Any key MUST have a well-defined scope and MUST be used in a specific		Any key MUST have a well-defined scope and MUST be used in a specific
	context and for the intended use. This specifically means the		context and for the intended use. This specifically means the
	lifetime and scope of each key MUST be defined clearly so that all		lifetime and scope of each key MUST be defined clearly so that all
	entities that are authorized to have access to the key have the same		entities that are authorized to have access to the key have the same
	context during the validity period. In a hierarchical key structure,		context during the validity period. In a hierarchical key structure,
	the lifetime of lower level keys MUST NOT exceed the lifetime of		the lifetime of lower level keys MUST NOT exceed the lifetime of
	higher level keys. This requirement MAY imply that the context and		higher level keys. This requirement MAY imply that the context and
	the scope parameters have to be exchanged. Furthermore, the		the scope parameters have to be exchanged. Furthermore, the
	semantics of these parameters MUST be defined to provide proper		semantics of these parameters MUST be defined to provide proper
	skipping to change at page 7, line 5		skipping to change at page 6, line 38
	Note that the compromise of higher-level keys has security		Note that the compromise of higher-level keys has security
	implications on lower levels.		implications on lower levels.
	Guidance on parameters required, caching, storage and deletion		Guidance on parameters required, caching, storage and deletion
	procedures to ensure adequate security and authorization provisioning		procedures to ensure adequate security and authorization provisioning
	for keying procedures MUST be defined in a solution document.		for keying procedures MUST be defined in a solution document.
	All the keying material MUST be uniquely named so that it can be		All the keying material MUST be uniquely named so that it can be
	managed effectively.		managed effectively.
	6.2. Key Freshness		5.2. Key Freshness
	As [RFC4962] defines, a fresh key is one that is generated for the		As [RFC4962] defines, a fresh key is one that is generated for the
	intended use. This would mean the key hierarchy MUST provide for		intended use. This would mean the key hierarchy MUST provide for
	creation of multiple cryptographically separate child keys from a		creation of multiple cryptographically separate child keys from a
	root key at higher level. Furthermore, the keying solution needs to		root key at higher level. Furthermore, the keying solution needs to
	provide mechanisms for refreshing each of the keys within the key		provide mechanisms for refreshing each of the keys within the key
	hierarchy.		hierarchy.
	6.3. Authentication		5.3. Authentication
	Each party in the handover keying architecture MUST be authenticated		Each party in the handover keying architecture MUST be authenticated
	to any other party with whom it communicates, and securely provide		to any other party with whom it communicates, and securely provide
	its identity to any other entity that may require the identity for		its identity to any other entity that may require the identity for
	defining the key scope. The identity provided MUST be meaningful		defining the key scope. The identity provided MUST be meaningful
	according to the protocol over which the two parties communicate.		according to the protocol over which the two parties communicate.
	6.4. Authorization		5.4. Authorization
	The EAP Key management document [I-D.ietf-eap-keying] discusses		The EAP Key management document [I-D.ietf-eap-keying] discusses
	several vulnerabilities that are common to handover mechanisms. One		several vulnerabilities that are common to handover mechanisms. One
	important issue arises from the way the authorization decisions might		important issue arises from the way the authorization decisions might
	be handled at the AAA server during network access authentication.		be handled at the AAA server during network access authentication.
	For example, if AAA proxies are involved, they may also influence in		For example, if AAA proxies are involved, they may also influence in
	the authorization decision. Furthermore, the reasons for making a		the authorization decision. Furthermore, the reasons for making a
	particular authorization decision are not communicated to the		particular authorization decision are not communicated to the
	authenticator. In fact, the authenticator only knows the final		authenticator. In fact, the authenticator only knows the final
	authorization result. The proposed solution MUST make efforts to		authorization result. The proposed solution MUST make efforts to
	document and mitigate authorization attacks.		document and mitigate authorization attacks.
	6.5. Channel Binding		5.5. Channel Binding
	Channel Binding procedures are needed to avoid a compromised		Channel Binding procedures are needed to avoid a compromised
	intermediate authenticator providing unverified and conflicting		intermediate authenticator providing unverified and conflicting
	service information to each of the peer and the EAP server. In the		service information to each of the peer and the EAP server. In the
	architecture introduced in this document, there are multiple		architecture introduced in this document, there are multiple
	intermediate entities between the peer and the back-end EAP server.		intermediate entities between the peer and the back-end EAP server.
	Various keys need to be established and scoped between these parties		Various keys need to be established and scoped between these parties
	and some of these keys may be parents to other keys. Hence the		and some of these keys may be parents to other keys. Hence the
	channel binding for this architecture will need to consider layering		channel binding for this architecture will need to consider layering
	intermediate entities at each level to make sure that an entity with		intermediate entities at each level to make sure that an entity with
	higher level of trust can examine the truthfulness of the claims made		higher level of trust can examine the truthfulness of the claims made
	by intermediate parties.		by intermediate parties.
	6.6. Transport Aspects		5.6. Transport Aspects
	Depending on the physical architecture and the functionality of the		Depending on the physical architecture and the functionality of the
	elements involved, there may be a need for multiple protocols to		elements involved, there may be a need for multiple protocols to
	perform the key transport between entities involved in the handover		perform the key transport between entities involved in the handover
	keying architecture. Thus, a set of requirements for each of these		keying architecture. Thus, a set of requirements for each of these
	protocols, and the parameters they will carry, MUST be developed.		protocols, and the parameters they will carry, MUST be developed.
	Following the requirement specifications, recommendations will be		Following the requirement specifications, recommendations will be
	provided as to whether new protocols or extensions to existing		provided as to whether new protocols or extensions to existing
	protocols are needed.		protocols are needed.
	As mentioned, the use of existing AAA protocols for carrying EAP		As mentioned, the use of existing AAA protocols for carrying EAP
	messages and keying material between the AAA server and AAA clients		messages and keying material between the AAA server and AAA clients
	that have a role within the architecture considered for the keying		that have a role within the architecture considered for the keying
	problem will be carefully examined. Definition of specific		problem will be carefully examined. Definition of specific
	parameters, required for keying procedures and to be transferred over		parameters, required for keying procedures and to be transferred over
	any of the links in the architecture, are part of the scope. The		any of the links in the architecture, are part of the scope. The
	relation of the identities used by the transport protocol and the		relation of the identities used by the transport protocol and the
	identities used for keying also needs to be explored.		identities used for keying also needs to be explored.
	7. Use Cases and Related Work		6. Use Cases and Related Work
	In order to further clarify the items listed in scope of the proposed		In order to further clarify the items listed in scope of the proposed
	work, this section provides some background on related work and the		work, this section provides some background on related work and the
	use cases envisioned for the proposed work.		use cases envisioned for the proposed work.
	7.1. IEEE 802.11r Applicability		6.1. IEEE 802.11r Applicability
	One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in		One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in
	the process of specifying a mechanism to avoid the problem of		the process of specifying a mechanism to avoid the problem of
	repeated full EAP exchanges in a limited setting, by introducing a		repeated full EAP exchanges in a limited setting, by introducing a
	two-level key hierarchy. The EAP authenticator is collocated with		two-level key hierarchy. The EAP authenticator is collocated with
	what is known as an R0 Key Holder (R0-KH), which receives the MSK		what is known as an R0 Key Holder (R0-KH), which receives the MSK
	from the EAP server. A pairwise master key (PMK-R0) is derived from		from the EAP server. A pairwise master key (PMK-R0) is derived from
	the last 32 octets of the MSK. Subsequently, the R0-KH derives an		the last 32 octets of the MSK. Subsequently, the R0-KH derives an
	PMK-R1 to be handed out to the attachment point of the peer. When		PMK-R1 to be handed out to the attachment point of the peer. When
	the peer moves from one R1-KH to another, a new PMK-R1 is generated		the peer moves from one R1-KH to another, a new PMK-R1 is generated
	skipping to change at page 9, line 12		skipping to change at page 8, line 44
	either a star configuration of security associations between the key		either a star configuration of security associations between the key
	holder and a centralized entity that serves as the R0-KH, or if the		holder and a centralized entity that serves as the R0-KH, or if the
	first authenticator is the default R0-KH, there will be a full-mesh		first authenticator is the default R0-KH, there will be a full-mesh
	of security associations between all authenticators. This is		of security associations between all authenticators. This is
	undesirable.		undesirable.
	The proposed work on EAP efficient re-authentication protocol aims at		The proposed work on EAP efficient re-authentication protocol aims at
	addressing re-authentication in a lower layer agnostic manner that		addressing re-authentication in a lower layer agnostic manner that
	also can fill some of the gaps in IEEE 802.11r.		also can fill some of the gaps in IEEE 802.11r.
	7.2. IEEE 802.21 Applicability		6.2. IEEE 802.21 Applicability
	The IEEE 802.21 working group [IEEE.802-21] is standardizing		The IEEE 802.21 working group [IEEE.802-21] is standardizing
	mechanisms for media-independent handover. More specifically, they		mechanisms for media-independent handover. More specifically, they
	are looking at transitions from one link-layer protocol to another,		are looking at transitions from one link-layer protocol to another,
	which is currently beyond the scope of the HOKEY charter.		which is currently beyond the scope of the HOKEY charter.
	The techniques developed within HOKEY could be applicable to IEEE		The techniques developed within HOKEY could be applicable to IEEE
	802.21 if the necessary issues with handover between different lower		802.21 if the necessary issues with handover between different lower
	layers can be resolved. In particular, pre-authentication may be		layers can be resolved. In particular, pre-authentication may be
	more appropriate than re-authentication.		more appropriate than re-authentication.
	7.3. CAPWAP Applicability		6.3. CAPWAP Applicability
	The IETF CAPWAP WG [RFC3990] is developing a protocol between what is		The IETF CAPWAP WG [RFC3990] is developing a protocol between what is
	termed an Access Controller (AC) and Wireless Termination Points		termed an Access Controller (AC) and Wireless Termination Points
	(WTP). The AC and WTP can be mapped to a WLAN switch and Access		(WTP). The AC and WTP can be mapped to a WLAN switch and Access
	Point respectively. The CAPWAP model supports both split and		Point respectively. The CAPWAP model supports both split and
	integrated MAC architectures, with the authenticator always being		integrated MAC architectures, with the authenticator always being
	implemented at the AC.		implemented at the AC.
	The proposed work on EAP efficient re-authentication protocol		The proposed work on EAP efficient re-authentication protocol
	addresses an inter-authenticator handover problem from an EAP		addresses an inter-authenticator handover problem from an EAP
	perspective, which applies during handover between ACs. Inter-		perspective, which applies during handover between ACs. Inter-
	controller handover is a topic yet to be addressed in great detail		controller handover is a topic yet to be addressed in great detail
	and the re-authentication work can potentially address it in an		and the re-authentication work can potentially address it in an
	effective manner.		effective manner.
	7.4. Inter-Technology Handover		6.4. Inter-Technology Handover
	EAP is used for access authentication by several technologies and is		EAP is used for access authentication by several technologies and is
	under consideration for use over several other technologies going		under consideration for use over several other technologies going
	forward. Given that, it should be feasible to support smoother		forward. Given that, it should be feasible to support smoother
	handover across technologies. That is one of the big advantages of		handover across technologies. That is one of the big advantages of
	using a common authentication protocol. Authentication procedures		using a common authentication protocol. Authentication procedures
	typically add substantial handover delays.		typically add substantial handover delays.
	An EAP peer that has multiple radio technologies (802.11 and GSM, for		An EAP peer that has multiple radio technologies (802.11 and GSM, for
	instance) must perform the full EAP exchange on each interface upon		instance) must perform the full EAP exchange on each interface upon
	every horizontal or vertical handover. With a method independent EAP		every horizontal or vertical handover. With a method independent EAP
	efficient re-authentication, it is feasible to support faster		efficient re-authentication, it is feasible to support faster
	handover even in the vertical handover cases, when the peer may be		handover even in the vertical handover cases, when the peer may be
	roaming from one technology to another.		roaming from one technology to another.
	8. Security Considerations		7. Security Considerations
	This document details the HOKEY problem statement. Since HOKEY is an		This document details the HOKEY problem statement. Since HOKEY is an
	authentication protocol, there are a myriad of security-related		authentication protocol, there are a myriad of security-related
	issues surrounding its development and deployment.		issues surrounding its development and deployment.
	In this document, we have detailed a variety of security properties		In this document, we have detailed a variety of security properties
	inferred from [RFC4962] to which HOKEY must conform, including the		inferred from [RFC4962] to which HOKEY must conform, including the
	management of key context, scope, freshness, and transport;		management of key context, scope, freshness, and transport;
	resistance to attacks based on the domino effect; and authentication		resistance to attacks based on the domino effect; and authentication
	and authorization. See section Section 6 for further details.		and authorization. See section Section 5 for further details.
	9. IANA Considerations		8. IANA Considerations
	This document does not introduce any new IANA considerations.		This document does not introduce any new IANA considerations.
			9. Contributors
			This document represents the synthesis of two problem statement
			documents. In this section, we acknowledge their contributions.
			Authors of "AAA based Keying for Wireless Handovers: Problem
			Statement" are:
			Madjid Nakhjiri
			Motorola Labs
			Email: madjid.nakhjiri@motorola.com
			Mohan Parthasarathy
			Nokia
			Email: mohan.parthasarathy@nokia.com
			Julien Bournelle
			France Telecom R&D
			Email: julien.bournelle@orange-ftgroup.com
			Hannes Tschofenig
			Siemens
			Email: Hannes.Tschofenig@siemens.com
			Rafael Marin Lopez, Editor
			Universidad de Murcia
			Email: rafa@dif.um.es
			Authors of "Problem Statement on EAP Efficient Re-authentication and
			Key Management" are:
			Vidya Narayanan
			QUALCOMM, Inc.
			Email: vidyan@qualcomm.com
			Lakshminath Dondeti
			QUALCOMM, Inc.
			Email: ldondeti@qualcomm.com
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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.
End of changes. 32 change blocks.
	88 lines changed or deleted		114 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/