draft-ietf-hokey-reauth-ps-08.txt		draft-ietf-hokey-reauth-ps-09.txt
	HOKEY Working Group T. Clancy		HOKEY Working Group T. Clancy
	Internet-Draft LTS		Internet-Draft LTS
	Intended status: Informational M. Nakhjiri		Intended status: Informational M. Nakhjiri
	Expires: August 13, 2008 Motorola		Expires: August 26, 2008 Motorola
	V. Narayanan		V. Narayanan
	L. Dondeti		L. Dondeti
	Qualcomm		Qualcomm
	February 10, 2008		February 23, 2008
	Handover Key Management and Re-authentication Problem Statement		Handover Key Management and Re-authentication Problem Statement
	draft-ietf-hokey-reauth-ps-08		draft-ietf-hokey-reauth-ps-09
	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 38		skipping to change at page 1, line 38
	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 August 13, 2008.		This Internet-Draft will expire on August 26, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document describes the Handover Keying (HOKEY) re-authentication		This document describes the Handover Keying (HOKEY) re-authentication
	problem statement. The current Extensible Authentication Protocol		problem statement. The current Extensible Authentication Protocol
	(EAP) keying framework is not designed to support re-authentication		(EAP) keying framework is not designed to support re-authentication
	skipping to change at page 2, line 15		skipping to change at page 2, line 15
	document details the problem and defines design goals for a generic		document details the problem and defines design goals for a generic
	mechanism to reuse derived EAP keying material for handover.		mechanism to reuse derived EAP keying material for handover.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
	4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6		5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7
	5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7		5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7		5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7
	5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7		5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
	5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7		5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8
	5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8		5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
	6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8		6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9
	6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 8		6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 9
	6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9		6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9
	6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10		6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . . 12		11.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. 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 Master Session Key (EMSK).		Extended Master Session Key (EMSK).
	In many common deployment scenario, an EAP peer and EAP server		In many common deployment scenarios, 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 encapsulating		"authenticator"). The authenticator is responsible for encapsulating
	EAP packets from a network access technology lower layer within the		EAP packets from a network access technology lower layer within the
	Authentication, Authorization, and Accounting (AAA) protocol. The		Authentication, Authorization, and Accounting (AAA) protocol. The
	authenticator does not directly participate in the EAP exchange, and		authenticator does not directly participate in the EAP exchange, and
	simply acts as a gateway during the EAP method execution.		simply acts as a gateway during the EAP method execution.
	After successful authentication, the EAP server transports the MSK to		After successful authentication, the EAP server transports the MSK to
	the authenticator. Note that this is performed using AAA protocols,		the authenticator. Note that this is performed using AAA protocols,
	skipping to change at page 3, line 38		skipping to change at page 3, line 38
	used for per-packet encryption and authentication.		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 frequently		Wireless handover between access points or base stations is typically
	not efficient in cases where the peer is a mobile device		a complex process that involves several layers of protocol execution.
	[MSA03][KP01]. In existing implementations, when a peer arrives at		Often times executing these protocols results in unacceptable delays
	the new authenticator, it runs an EAP method irrespective of whether		for many real-time applications such as voice [MSA03]. One part of
	it has been authenticated to the network recently and has unexpired		the handover process is EAP re-authentication, which can contribute
	keying material. A full EAP method execution involves an EAP-		significantly to the overall handover time [MSPCA04]. Thus in many
	Response/Identity message from the peer to server, followed by one or		environments we can lower overall handover time by lowering EAP re-
	more round trips between the EAP server and peer to perform the		authentication time.
	authentication, followed by the EAP-Success or EAP-Failure message
	from the EAP server to peer. At a minimum, the peer has 2 round		In EAP existing implementations, when a peer arrives at the new
	trips with the EAP server.		authenticator, it runs an EAP method irrespective of whether it has
			been authenticated to the network recently and has unexpired keying
			material. This typically involves an EAP-Response/Identity message
			from the peer to server, followed by one or more round trips between
			the EAP server and peer to perform the authentication, followed by
			the EAP-Success or EAP-Failure message from the EAP server to the
			peer. At a minimum, the EAP exchange consists of 1.5 round trips.
			However, given the way EAP interacts with AAA, and given that an EAP
			identity exchange is typically employed, at least 2 round trips are
			required to the EAP server. An even higher number of round trips is
			required by the most commonly used EAP methods. For instance, EAP-
			TLS requires at least 3 but typically 4 or more round trips.
	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 or EAP lower-layer specific. Furthermore, these		EAP-method specific or EAP lower-layer specific. Furthermore, these
	solutions do not deal with scenarios involving handovers to new		solutions do not deal with scenarios involving handovers to new
	authenticators, or do not conform to the AAA keying requirements		authenticators, or do not conform to the AAA keying requirements
	specified in [RFC4962].		specified in [RFC4962].
	This document provides a detailed description of efficient EAP-based		This document provides a detailed description of efficient EAP-based
	re-authentication protocol design goals. The scope of this protocol		re-authentication protocol design goals. The scope of this protocol
	is specifically re-authentication and handover between authenticators		is specifically re-authentication and handover between authenticators
	within a single administrative domain. Inter-technology handover and		within a single administrative domain. While the design goals
	inter-administrative-domain handover are outside the scope of this		presented in this document may facilitate inter-technology handover
	protocol.		and inter-administrative-domain handover, they are outside the scope
			of this protocol.
	2. 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], with the		are to be interpreted as described in [RFC2119], with the
	qualification that unless otherwise stated they apply to the design		qualification that unless otherwise stated they apply to the design
	of the re-authentication protocol, not its implementation or		of the re-authentication protocol, not its implementation or
	skipping to change at page 4, line 38		skipping to change at page 5, line 4
	3. 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 to which the peer initially		exchange with the EAP server to which the peer initially
	authenticated [RFC3748]. This introduces handover latency from both		authenticated [RFC3748]. This introduces handover latency from both
	network transit time and processing delay. In service provider		network transit time and processing delay. In service provider
	networks, the home EAP server for a peer could be on the other side		networks, the home EAP server for a peer could be on the other side
	of the world, and typical intercontinental latencies across the		of the world, and typical intercontinental latencies across the
	Internet are 100 to 300 milliseconds per round trip [LGS07].		Internet are 100 to 300 milliseconds per round trip [LGS07].
	Processing delays average a couple of milliseconds for symmetric-key		Processing delays average a couple of milliseconds for symmetric-key
	operations and hundreds of milliseconds for public-key operations.		operations and hundreds of milliseconds for public-key operations.
	An EAP conversation with a full EAP method run can take two or more		An EAP conversation with a full EAP method run can take two or more
	round trips and to complete, causing delays in re-authentication and		round trips to complete, causing delays in re-authentication and
	handover times. Some methods specify the use of keys and state from		handover times. Some methods specify the use of keys and state from
	the initial authentication to finish subsequent authentications in		the initial authentication to finish subsequent authentications in
	fewer round trips and without using public-key operations (detailed		fewer round trips and without using public-key operations (detailed
	Section 6.1). However, even in those cases, multiple round trips to		Section 6.1). However, even in those cases, multiple round trips to
	the EAP server are required, resulting in unacceptable handover		the EAP server are required, resulting in unacceptable handover
	times.		times.
	In summary, it is undesirable to run an EAP Identity and complete EAP		In summary, it is undesirable to run an EAP Identity and complete EAP
	method exchange each time a peer authenticates to a new authenticator		method exchange each time a peer authenticates to a new authenticator
	or needs to extend its current authentication with the same		or needs to extend its current authentication with the same
	skipping to change at page 6, line 14		skipping to change at page 6, line 25
	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 [I-D.ietf-radext-design]		EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design]
	and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both		and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both
	RADIUS and Diameter to support these EAP modifications are		RADIUS and Diameter to support these EAP modifications are
	acceptable. The designs and protocols must be configurable to		acceptable. The designs and protocols must be configurable to
	satisfy the AAA key management requirements specified in RFC 4962		satisfy the AAA key management requirements specified in RFC 4962
	[RFC4962].		[RFC4962].
	Compatibility: Compatibility and co-existence with compliant		Compatibility: Compatibility and co-existence with compliant
	([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be		([RFC3748] [I-D.ietf-eap-keying]) EAP deployments MUST be
	provided. Specifically, the protocol should be designed such that		provided. Specifically, the protocol should be designed such that
	fall back to EAP authentication occurs if not all devices in the		a peer not supporting fast re-reauthentication should still
	network support fast re-authentication.		function in a network supporting fast re-authentication, and also
			a peer supporting fast re-authentication should still function in
			a network not supporting fast re-authentication.
	Cryptographic Agility: Any re-authentication protocol MUST support		Cryptographic Agility: Any re-authentication protocol MUST support
	cryptographic algorithm agility, to avoid hard-coded primitives		cryptographic algorithm agility, to avoid hard-coded primitives
	whose security may eventually prove to be compromised. The		whose security may eventually prove to be compromised. The
	protocol MAY support cryptographic algorithm negotiation, provided		protocol MAY support cryptographic algorithm negotiation, provided
	it does not adversely affect overall performance (i.e. by		it does not adversely affect overall performance (i.e. by
	requiring additional round trips).		requiring additional round trips).
			Impact to Existing Deployments: Any re-authentication protocol MAY
			make changes to the peer, authenticator, and EAP server, as
			necessary to meet the aforementioned design goals. In order to
			facilitate protocol deployment, protocols should seek to minimize
			the necessary changes, without sacrificing performance.
	5. 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.
	5.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
	skipping to change at page 7, line 39		skipping to change at page 8, line 12
	ensure proper key scoping, and securely provide its identity to any		ensure proper key scoping, and securely provide its identity to any
	other entity that may require the identity for defining the key		other entity that may require the identity for defining the key
	scope.		scope.
	5.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 influence		Furthermore, the reasons for making a particular authorization
	authorization decisions. Furthermore, the reasons for making a		decision are not communicated to the authenticator. In fact, the
	particular authorization decision are not communicated to the		authenticator only knows the final authorization result. The
	authenticator. In fact, the authenticator only knows the final		proposed solution must make efforts to document and mitigate
	authorization result. The proposed solution must make efforts to		authorization attacks.
	document and mitigate authorization attacks.
	5.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. To		service information to each of the peer and the EAP server. To
	support fast re-authentication, there will be intermediate entities		support fast re-authentication, there will be intermediate entities
	between the peer and the back-end EAP server. Various keys need to		between the peer and the back-end EAP server. Various keys need to
	be established and scoped between these parties and some of these		be established and scoped between these parties and some of these
	keys may be parents to other keys. Hence the channel binding for		keys may be parents to other keys. Hence the channel binding for
	skipping to change at page 8, line 25		skipping to change at page 8, line 45
	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.
	The use of existing AAA protocols for carrying EAP messages and		The use of existing AAA protocols for carrying EAP messages and
	keying material between the AAA server and AAA clients that have a		keying material between the AAA server and AAA clients that have a
	role within the architecture considered for the keying problem will		role within the architecture considered for the keying problem will
	be carefully examined. Definition of specific parameters, required		be carefully examined. Definition of specific parameters, required
	for keying procedures and to be transferred over any of the links in		for keying procedures and to be transferred over any of the links in
	the architecture, are part of the scope. The relation of the		the architecture, are part of the scope. The relation between the
	identities used by the transport protocol and the identities used for		identities used by the transport protocol and the identities used for
	keying also needs to be explored.		keying also needs to be explored.
	6. 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.
	6.1. Method-Specific EAP Re-authentication		6.1. Method-Specific EAP Re-authentication
	A number of EAP methods support fast re-authentication. In this		A number of EAP methods support fast re-authentication. In this
	section we examine their properties in further detail.		section we examine their properties in further detail.
	EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast re-		EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re-
	authentication, bootstrapped by the keys generated during an initial		authentication, bootstrapped by the keys generated during an initial
	full authentication. In response to the typical EAP-Request/		full authentication. In response to the typical EAP-Request/
	Identity, the peer sends a specially formatted identity indicating a		Identity, the peer sends a specially formatted identity indicating a
	desire to perform a fast re-authentication. A single round-trip		desire to perform a fast re-authentication. A single round-trip
	occurs to verify knowledge of the existing keys and provide fresh		occurs to verify knowledge of the existing keys and provide fresh
	nonces for generating new keys. This is followed by an EAP success.		nonces for generating new keys. This is followed by an EAP success.
	In the end, it requires a single local round trip between the peer		In the end, it requires a single local round trip between the peer
	and authenticator, followed by another round trip between the peer		and authenticator, followed by another round trip between the peer
	and EAP server. AKA is based on symmetric-key cryptography, so		and EAP server. AKA is based on symmetric-key cryptography, so
	processing latency is minimal.		processing latency is minimal.
	skipping to change at page 10, line 43		skipping to change at page 11, line 19
	7. 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 5 for further details.		and authorization. See Section 5 for further details.
	8. 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		9. Contributors
	This document represents the synthesis of two problem statement		This document represents the synthesis of two problem statement
	documents. In this section, we acknowledge their contributions, and		documents. In this section, we acknowledge their contributions, and
	involvement in the early documents.		involvement in the early documents.
	skipping to change at page 11, line 33		skipping to change at page 12, line 11
	Rafael Marin Lopez		Rafael Marin Lopez
	Universidad de Murcia		Universidad de Murcia
	Email: rafa@dif.um.es		Email: rafa@dif.um.es
	10. Acknowledgements		10. Acknowledgements
	The authors would like to thank the participants of the HOKEY working		The authors would like to thank the participants of the HOKEY working
	group for their review and comments, including Glen Zorn, Dan		group for their review and comments, including Glen Zorn, Dan
	Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to		Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to
	thank those that provided last call reviews, including Bernard Aboba,		thank those that provided last call reviews, including Bernard Aboba,
	Alan DeKok, and Hannes Tschofenig.		Alan DeKok, Jari Arkko, and Hannes Tschofenig.
	11. References		11. References
	11.1. Normative References		11.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)",
	skipping to change at page 12, line 17		skipping to change at page 12, line 42
	11.2. Informative References		11.2. Informative References
	[I-D.funk-eap-ttls-v0]		[I-D.funk-eap-ttls-v0]
	Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS		Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
	Authentication Protocol Version 0 (EAP-TTLSv0)",		Authentication Protocol Version 0 (EAP-TTLSv0)",
	draft-funk-eap-ttls-v0-02 (work in progress),		draft-funk-eap-ttls-v0-02 (work in progress),
	November 2007.		November 2007.
	[I-D.ietf-capwap-protocol-specification]		[I-D.ietf-capwap-protocol-specification]
	Calhoun, P., "CAPWAP Protocol Specification",		Calhoun, P., "CAPWAP Protocol Specification",
	draft-ietf-capwap-protocol-specification-08 (work in		draft-ietf-capwap-protocol-specification-09 (work in
	progress), November 2007.		progress), February 2008.
	[I-D.ietf-dime-app-design-guide]		[I-D.ietf-dime-app-design-guide]
	Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G.,		Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G.,
	and J. Loughney, "Diameter Applications Design		and J. Loughney, "Diameter Applications Design
	Guidelines", draft-ietf-dime-app-design-guide-06 (work in		Guidelines", draft-ietf-dime-app-design-guide-06 (work in
	progress), January 2008.		progress), January 2008.
	[I-D.ietf-eap-keying]		[I-D.ietf-eap-keying]
	Aboba, B., Simon, D., and P. Eronen, "Extensible		Aboba, B., Simon, D., and P. Eronen, "Extensible
	Authentication Protocol (EAP) Key Management Framework",		Authentication Protocol (EAP) Key Management Framework",
	skipping to change at page 13, line 26		skipping to change at page 13, line 50
	May 2007.		May 2007.
	[IEEE.802-11R-D9.0]		[IEEE.802-11R-D9.0]
	"Information technology - Telecommunications and		"Information technology - Telecommunications and
	information exchange between systems - Local and		information exchange between systems - Local and
	metropolitan area networks - Specific requirements - Part		metropolitan area networks - Specific requirements - Part
	11: Wireless LAN Medium Access Control (MAC) and Physical		11: Wireless LAN Medium Access Control (MAC) and Physical
	Layer (PHY) specifications - Amendment 2: Fast BSS		Layer (PHY) specifications - Amendment 2: Fast BSS
	Transition", IEEE Standard 802.11r, January 2008.		Transition", IEEE Standard 802.11r, January 2008.
	[KP01] Koodli, R. and C. Perkins, "Fast Handover and Context
	Relocation in Mobile Networks", ACM SIGCOMM Computer and
	Communications Review, October 2001.
	[LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network		[LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network
	Coordinates in the Wild", USENIX Symposium on Networked		Coordinates in the Wild", USENIX Symposium on Networked
	System Design and Implementation, April 2007.		System Design and Implementation, April 2007.
	[MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical		[MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical
	Analysis of the IEEE 802.11 MAC-Layer Handoff Process",		Analysis of the IEEE 802.11 MAC-Layer Handoff Process",
	ACM SIGCOMM Computer and Communications Review,		ACM SIGCOMM Computer and Communications Review,
	April 2003.		April 2003.
			[MSPCA04] Mishra, A., Shin, M., Petroni, N., Clancy, T., and W.
			Arbaugh, "Proactive Key Distribution using Neighbor
			Graphs", IEEE Wireless Communications, February 2004.
	Authors' Addresses		Authors' Addresses
	T. Charles Clancy, Editor		T. Charles Clancy, Editor
	Laboratory for Telecommunications Sciences		Laboratory for Telecommunications Sciences
	US Department of Defense		US Department of Defense
	College Park, MD		College Park, MD
	USA		USA
	Email: clancy@LTSnet.net		Email: clancy@LTSnet.net
	Madjid Nakhjiri		Madjid Nakhjiri
	Motorola		Motorola
	Email: madjid.nakhjiri@motorola.com		Email: madjid.nakhjiri@motorola.com
	Vidya Narayanan		Vidya Narayanan
	Qualcomm, Inc.		Qualcomm, Inc.
	San Diego, CA		San Diego, CA
	USA		USA
End of changes. 27 change blocks.
	50 lines changed or deleted		72 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/