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/