HOKEY Working Group                                            T. Clancy
Internet-Draft                                                       LTS
Intended status: Informational                               M. Nakhjiri
Expires: May August 13, 2008                                        Motorola
                                                            V. Narayanan
                                                              L. Dondeti
                                                       February 10, 2007 2008

    Handover Key Management and Re-authentication Problem Statement

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May August 13, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).


   This document describes the Handover Keying (HOKEY) re-authentication
   problem statement.  The current Extensible Authentication Protocol
   (EAP) keying framework is not designed to support re-authentication
   handovers. handovers without re-executing an EAP method.  This often causes
   unacceptable latency in various mobile wireless environments.  The HOKEY Working Group plans to address
   these problems by designing  This
   document details the problem and defines design goals for a generic
   mechanism to reuse derived EAP keying material for handover.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Security Goals . . . . . . . . . . . . . . . . . . . . . . . .  5  6
     5.1.  Key Context and Domino Effect  . . . . . . . . . . . . . .  6
     5.2.  Key Freshness  . . . . . . . . . . . . . . . . . . . . . .  6  7
     5.3.  Authentication . . . . . . . . . . . . . . . . . . . . . .  6  7
     5.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  7
     5.5.  Channel Binding  . . . . . . . . . . . . . . . . . . . . .  7
     5.6.  Transport Aspects  . . . . . . . . . . . . . . . . . . . .  7  8
   6.  Use Cases and Related Work . . . . . . . . . . . . . . . . . .  8
     6.1.  IEEE 802.11r Applicability . . . . . .  Method-Specific EAP Re-authentication  . . . . . . . . . .  8
     6.2.  IEEE 802.21 802.11r Applicability . . . . . . . . . . . . . . . .  8  9
     6.3.  CAPWAP Applicability . . . . . . . . . . . . . . . . . . .  9
     6.4.  Inter-Technology Handover 10
   7.  Security Considerations  . . . . . . . . . . . . . . . .  9
   7.  Security . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations . . 10
   9.  Contributors . . . . . . . . . . . . . . . . . . . . 10
   9.  Contributors . . . . . 11
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
   10. . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 11 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 13 15

1.  Introduction

   The Extensible Authentication Protocol (EAP), specified in RFC 3748
   [RFC3748] is a generic framework supporting multiple authentication
   methods.  The primary purpose of EAP is network access control.  It
   also supports exporting session keys derived during the
   authentication.  The EAP keying hierarchy defines two keys that are
   derived at the top level, the Master Session Key (MSK) and the
   Extended Master Session Key (EMSK).

   In many common deployment scenario, an EAP peer and EAP server
   authenticate each other through a third party known as the pass-
   through authenticator (hereafter referred to as simply
   "authenticator").  The authenticator is responsible for translating encapsulating
   EAP packets from the layer 2 (L2) or layer 3 (L3) a network access technology to lower layer within 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

   After successful authentication, the EAP server
   to transports the MSK to
   the authenticator.  Note that this is performed using AAA protocols,
   not EAP itself.  The underlying L2 or L3 protocol uses the MSK to
   derive additional keys, including the transient session keys (TSKs)
   used for per-packet encryption and authentication.

   Note that while the authenticator is one logical device, there can be
   multiple physical devices involved.  For example, the CAPWAP model
   [RFC3990] splits authenticators into two logical devices: Wireless
   Termination Points (WTPs) and Access Controllers (ACs).  Depending on
   the configuration, authenticator features can be split in a variety
   of ways between physical devices, however from the EAP perspective
   there is only one logical authenticator.

   The current models of EAP authentication and keying are unfortunately frequently
   not efficient in cases where the peer is a mobile device.  When device
   [MSA03][KP01].  In existing implementations, when a peer arrives at
   the new authenticator, the security restraints will
   require the peer to run it runs an EAP method irrespective of whether
   it has been authenticated to the network recently and has unexpired
   keying material.  A full EAP method execution may involve several involves an EAP-
   Response/Identity message from the peer to server, followed by one or
   more round trips between the EAP peer server and peer to perform the
   authentication, followed by the EAP-Success or EAP-Failure message
   from the EAP server to peer.  At a minimum, the peer has 2 round
   trips with the EAP server.

   There have been attempts to solve the problem of efficient re-
   authentication in various ways.  However, those solutions are either
   EAP-method specific, specific or EAP lower-layer specific, or are otherwise
   limited in scope. specific.  Furthermore, these
   solutions do not deal with scenarios involving handovers to new
   authenticators, or do not conform to the AAA keying requirements
   specified in [RFC4962].

   This document provides a detailed description of efficient EAP-based
   re-authentication protocol requirements. design goals.  The scope of this protocol
   is specifically re-authentication and handover between authenticators
   within a single administrative domain.  Inter-technology handover and
   inter-administrative-domain handover are outside the scope of this

2.  Terminology

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119]. [RFC2119], with the
   qualification that unless otherwise stated they apply to the design
   of the re-authentication protocol, not its implementation or

   With respect to EAP, this document follows the terminology that has
   been defined in [RFC3748] and [I-D.ietf-eap-keying].

3.  Problem Statement

   Under the existing model, any re-authentication requires a full EAP
   exchange with the EAP server in its home domain to which the peer initially
   authenticated [RFC3748].  This introduces handover latency from both
   network transit time and processing delay.  In service provider
   networks, the home EAP server for a peer could be on the other side
   of the world, and typical intercontinental latencies across the
   Internet are 100 to 300 milliseconds per round trip [LGS07].
   Processing delays average a couple of milliseconds for symmetric-key
   operations and hundreds of milliseconds for public-key operations.

   An EAP conversation with a full EAP method run can take several two or more
   round trips and significant time to complete, causing delays in re-authentication and
   handover times.  Some methods [RFC4187] specify the use of keys and state from
   the initial authentication to finish subsequent authentications in
   fewer round trips. trips and without using public-key operations (detailed
   Section 6.1).  However, even in those cases, multiple round trips to
   the EAP server are still involved.
   Furthermore, many commonly-used EAP methods do not offer such a fast
   re-authentication feature. required, resulting in unacceptable handover

   In summary, it is undesirable to have to run a full an EAP Identity and complete EAP
   method exchange each time a peer authenticates to a new authenticator
   or needs to extend its current authentication with the same
   authenticator.  Furthermore, it is desirable to specify a
   method-independent, method-
   independent, efficient, re-authentication protocol.  Keying material
   from the full initial authentication can be used to enable efficient

   Significant network latency between the peer and EAP server is
   another source of delay during re-authentication. re-
   authentication.  It is also desirable to have a local server with
   low-latency connectivity to the peer that can facilitate re-authentication. re-
   authentication.  Lastly, a re-authentication protocol should also be
   capable of supporting handover keying.  Handover keying allows scenarios where an EAP server to
   pass passes
   authentication information to a remote re-authentication server,
   allowing a peer to re-authenticate to that re-authentication server locally without having to
   communicate with its home re-authentication server.

   These problems are the primary issues to be resolved.  In solving
   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.

4.  Design Goals

   The following are the goals and constraints in designing the EAP re-
   authentication and key management protocol:

   Lower latency operation:  The protocol MUST be responsive to handover
      and re-authentication latency performance objectives within a
      mobile access network.  A solution that reduces latency as
      compared to a full EAP authentication will be most favorable. favorable,
      since in networks that rely on reactive re-authentication this
      will directly impact handover times.

   EAP lower-layer independence:  Any keying hierarchy and protocol
      defined MUST be lower layer independent in order to provide the
      capabilities over heterogeneous technologies.  The defined
      protocols MAY require some additional support from the lower
      layers that use
      it.  Any keying hierarchy and protocol defined MUST accommodate
      inter-technology heterogeneous handover. it, but should not require any particular lower

   EAP method independence:  Changes to existing EAP methods MUST NOT be
      required as a result of the re-authentication protocol.  There
      MUST be no requirements imposed on future EAP methods. methods, provided
      they satisfy [I-D.ietf-eap-keying] and [RFC4017].  Note that the
      only EAP methods for which independence is required are those that
      currently conform to the specifications of [I-D.ietf-eap-keying]
      and [RFC4017].  In particular, methods that do not generate the
      keys required by [I-D.ietf-eap-keying] need not be supported by
      the re-authentication protocol.

   AAA protocol compatibility and keying:  Any modifications to EAP and
      EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design]
      and Diameter. Diameter [I-D.ietf-dime-app-design-guide].  Extensions to both
      RADIUS and Diameter to support these EAP modifications are
      acceptable.  The designs and protocols must be configurable to
      satisfy the AAA key management requirements specified in RFC 4962


   Compatibility:  Compatibility and co-existence with compliant
      ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be
      provided.  The keying hierarchy or  Specifically, the protocol extensions MUST NOT
      preclude should be designed such that
      fall back to EAP authentication occurs if not all devices in the use of CAPWAP or IEEE 802.11r.
      network support fast re-authentication.
   Cryptographic Agility:  Any re-authentication protocol MUST support
      cryptographic algorithm agility, to avoid hard-coded primitives
      whose security may eventually prove to be compromised.  The
      protocol MAY support cryptographic algorithm negotiation, provided
      it does not adversely affect overall performance (i.e. by
      requiring additional round trips).

5.  Security Goals

   The section draws from the guidance provided in [RFC4962] to further
   define the security goals to be achieved by a complete re-
   authentication keying solution.

5.1.  Key Context and Domino Effect

   Any key MUST must have a well-defined scope and MUST must be used in a specific
   context and for the intended use.  This specifically means the
   lifetime and scope of each key MUST must be defined clearly so that all
   entities that are authorized to have access to the key have the same
   context during the validity period.  In a hierarchical key structure,
   the lifetime of lower level keys MUST NOT must not exceed the lifetime of
   higher level keys.  This requirement MAY may imply that the context and
   the scope parameters have to be exchanged.  Furthermore, the
   semantics of these parameters MUST must be defined to provide proper
   channel binding specifications.  The definition of exact parameter
   syntax definition is part of the design of the transport protocol
   used for the parameter exchange and that may be outside scope of this

   If a key hierarchy is deployed, compromising lower level keys MUST
   NOT must
   not result in a compromise of higher level keys which they were used to
   derive the lower level keys.  The compromise of keys at each level
   must not result in compromise of other keys at the same level.  The
   same principle applies to entities that hold and manage a particular
   key defined in the key hierarchy.  Compromising keys on one
   authenticator MUST NOT must not reveal the keys of another authenticator.
   Note that the compromise of higher-level keys has security
   implications on lower levels.

   Guidance on parameters required, caching, storage and deletion
   procedures to ensure adequate security and authorization provisioning
   for keying procedures MUST must be defined in a solution document.

   All the keying material MUST must be uniquely named so that it can be
   managed effectively.

5.2.  Key Freshness

   As [RFC4962] defines, a fresh key is one that is generated for the
   intended use.  This would mean the key hierarchy MUST must provide for
   creation of multiple cryptographically separate child keys from a
   root key at higher level.  Furthermore, the keying solution needs to
   provide mechanisms for refreshing each of the keys within the key

5.3.  Authentication

   Each party in the handover keying architecture MUST participant must be authenticated to any other
   party with whom it communicates, communicates to the extent it is necessary to
   ensure proper key scoping, and securely provide its identity to any
   other entity that may require the identity for defining the key
   scope.  The identity provided MUST be meaningful
   according to the protocol over which the two parties communicate.

5.4.  Authorization

   The EAP Key management document [I-D.ietf-eap-keying] discusses
   several vulnerabilities that are common to handover mechanisms.  One
   important issue arises from the way the authorization decisions might
   be handled at the AAA server during network access authentication.
   For example, if AAA proxies are involved, they may also influence in
   authorization decision. decisions.  Furthermore, the reasons for making a
   particular authorization decision are not communicated to the
   authenticator.  In fact, the authenticator only knows the final
   authorization result.  The proposed solution MUST must make efforts to
   document and mitigate authorization attacks.

5.5.  Channel Binding

   Channel Binding procedures are needed to avoid a compromised
   intermediate authenticator providing unverified and conflicting
   service information to each of the peer and the EAP server.  In the
   architecture introduced in this document,  To
   support fast re-authentication, there are multiple will be intermediate entities
   between the peer and the back-end EAP server.  Various keys need to
   be established and scoped between these parties and some of these
   keys may be parents to other keys.  Hence the channel binding for
   this architecture will need to consider layering intermediate
   entities at each level to make sure that an entity with higher level
   of trust can examine the truthfulness of the claims made by
   intermediate parties.

5.6.  Transport Aspects

   Depending on the physical architecture and the functionality of the
   elements involved, there may be a need for multiple protocols to
   perform the key transport between entities involved in the handover
   keying architecture.  Thus, a set of requirements for each of these
   protocols, and the parameters they will carry, MUST must be developed.
   Following the requirement specifications, recommendations will be
   provided as to whether new protocols or extensions to existing
   protocols are needed.

   As mentioned, the

   The use of existing AAA protocols for carrying EAP messages and
   keying material between the AAA server and AAA clients that have a
   role within the architecture considered for the keying problem will
   be carefully examined.  Definition of specific parameters, required
   for keying procedures and to be transferred over any of the links in
   the architecture, are part of the scope.  The relation of the
   identities used by the transport protocol and the identities used for
   keying also needs to be explored.

6.  Use Cases and Related Work

   In order to further clarify the items listed in scope of the proposed
   work, this section provides some background on related work and the
   use cases envisioned for the proposed work.

6.1.  Method-Specific EAP Re-authentication

   A number of EAP methods support fast re-authentication.  In this
   section we examine their properties in further detail.

   EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast re-
   authentication, bootstrapped by the keys generated during an initial
   full authentication.  In response to the typical EAP-Request/
   Identity, the peer sends a specially formatted identity indicating a
   desire to perform a fast re-authentication.  A single round-trip
   occurs to verify knowledge of the existing keys and provide fresh
   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
   and authenticator, followed by another round trip between the peer
   and EAP server.  AKA is based on symmetric-key cryptography, so
   processing latency is minimal.

   EAP-TTLS [I-D.funk-eap-ttls-v0] and PEAP
   [I-D.josefsson-pppext-eap-tls-eap] support using TLS session
   resumption for fast re-authentication.  During the TLS handshake, the
   client includes the message ID of the previous session he wishes to
   resume, and the server can echo that ID back if it agrees to resume
   the session.  EAP-FAST [RFC4851] also supports TLS session
   resumption, but additionally allows stateless session resumption as
   defined in [RFC4507].  Overall, for all three protocols there are
   still two round trips between the peer and EAP server, in addition to
   the local round trip for the Identity request and response.

   To improve performance, fast re-authentication needs to reduce the
   number of overall round trips.  Optimal performance could result from
   eliminating the EAP-Request/Identity and EAP-Response/Identity
   messages observed in typical EAP method execution, and allowing a
   single round trip between the peer and a local re-authentication

6.2.  IEEE 802.11r Applicability

   One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], [IEEE.802-11R-D9.0], is in
   the process of specifying a mechanism to avoid the problem of
   repeated full EAP exchanges in a limited setting, by introducing a
   two-level key hierarchy.  The EAP authenticator is collocated with
   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
   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
   the peer moves from one R1-KH to another, a new PMK-R1 is generated
   by the R0-KH and handed out to the new R1-KH.  The transport protocol
   used between the R0-KH and the R1-KH is not specified.

   In some cases, a mobile may seldom move beyond the domain of the
   R0-KH and this model works well.  A full EAP authentication will
   generally be repeated when the PMK-R0 expires.  However, in general
   cases mobiles may roam beyond the domain of R0-KHs (or EAP
   authenticators), and the latency of full EAP authentication remains
   an issue.

   Another consideration is that there needs to be a key transfer
   protocol between the R0-KH and the R1-KH; in other words, there is
   either a star configuration of security associations between the key
   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
   of security associations between all authenticators.  This is

   The proposed work on EAP efficient re-authentication protocol aims at
   addressing re-authentication in a lower layer agnostic manner that
   also can fill some of the gaps in IEEE 802.11r.

6.2.  IEEE 802.21

6.3.  CAPWAP Applicability

   The IEEE 802.21 working group [IEEE.802-21] is standardizing
   mechanisms for media-independent handover.  More specifically, they
   are looking at transitions from one link-layer CAPWAP protocol to another,
   which is currently beyond [I-D.ietf-capwap-protocol-specification] allows
   the scope functionality of the HOKEY charter.

   The techniques developed within HOKEY could be applicable to an IEEE
   802.21 if the necessary issues with handover between different lower
   layers can be resolved.  In particular, pre-authentication may 802.11 access point to be
   more appropriate than re-authentication.

6.3.  CAPWAP Applicability

   The IETF CAPWAP Working Group [RFC3990] is developing split into two
   physical devices in enterprise deployments.  Wireless Termination
   Points (WTPs) implement the physical and low-level MAC layers, while
   a protocol
   between what is termed an centralized Access Controller (AC) provides higher-level management
   and Wireless
   Termination Points (WTP).  The protocol execution.  Client authentication is handled by the AC,
   which acts as the AAA authenticator.

   One of the many features provided by CAPWAP is the ability to roam
   between WTPs without executing an EAP authentication.  To accomplish
   this, the AC caches the MSK from an initial EAP authentication, and WTP can be mapped
   uses it to execute a WLAN
   switch and Access Point respectively.  The CAPWAP model supports both
   split and integrated MAC architectures, separate four-way handshake with the authenticator always
   being implemented at station as
   it moves between WTPs.  The keys resulting from the four-way
   handshake are then distributed to the WTP to which the AC. station is
   associated.  CAPWAP is transparent to the station.

   CAPWAP currently has no means to support roaming between ACs in an
   enterprise network.  The proposed work on EAP efficient re-authentication protocol re-
   authentication addresses an inter-authenticator handover problem from
   an EAP perspective, which applies during handover between ACs.  Inter-
   Inter-AC handover is a topic yet to be addressed in great detail and
   the re-authentication work can potentially address it in an effective

6.4.  Inter-Technology Handover

   EAP is used for access authentication by several technologies and is
   under consideration for use over several other technologies going
   forward.  Given that, it should be feasible to support smoother
   handover across technologies.  That is one of the big advantages of
   using a common authentication protocol.  Authentication procedures
   typically add substantial handover delays.

   An EAP peer that has multiple radio technologies (802.11 and GSM, for
   instance) must perform the full EAP exchange on each interface upon
   every horizontal or vertical handover.  With a method independent EAP
   efficient re-authentication, it is feasible to support faster
   handover even in the vertical handover cases, when the peer may be
   roaming from one technology to another.

7.  Security Considerations

   This document details the HOKEY problem statement.  Since HOKEY is an
   authentication protocol, there are a myriad of security-related
   issues surrounding its development and deployment.

   In this document, we have detailed a variety of security properties
   inferred from [RFC4962] to which HOKEY must conform, including the
   management of key context, scope, freshness, and transport;
   resistance to attacks based on the domino effect; and authentication
   and authorization.  See section Section 5 for further details.

8.  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, and
   involvement in the early documents.

      Mohan Parthasarathy
      Email: mohan.parthasarathy@nokia.com

      Julien Bournelle
      France Telecom R&D
      Email: julien.bournelle@orange-ftgroup.com

      Hannes Tschofenig
      Email: Hannes.Tschofenig@siemens.com

      Rafael Marin Lopez
      Universidad de Murcia
      Email: rafa@dif.um.es

10.  Acknowledgements

   The authors would like to thank the participants of the HOKEY working
   group for their review and comments, including Glen Zorn, Dan
   Harkins, Joe Salowey, and Yoshi Ohba.  The authors would also like to
   thank those that provided last call reviews, including Bernard Aboba,
   Alan DeKok, and Hannes Tschofenig.

11.  References


11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4017]  Stanley, D., Walker, J., and B. Aboba, "Extensible
              Authentication Protocol (EAP) Method Requirements for
              Wireless LANs", RFC 4017, March 2005.

   [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
              Authorization, and Accounting (AAA) Key Management",
              BCP 132, RFC 4962, July 2007.


11.2.  Informative References

              Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
              Authentication Protocol Version 0 (EAP-TTLSv0)",
              draft-funk-eap-ttls-v0-02 (work in progress),
              November 2007.

              Calhoun, P., "CAPWAP Protocol Specification",
              draft-ietf-capwap-protocol-specification-08 (work in
              progress), November 2007.

              Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G.,
              and J. Loughney, "Diameter Applications Design
              Guidelines", draft-ietf-dime-app-design-guide-06 (work in
              progress), January 2008.

              Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              draft-ietf-eap-keying-22 (work in progress), October
              November 2007.

              Weber, G. and A. DeKok, "RADIUS Design Guidelines",
              draft-ietf-radext-design-02 (work in progress),
              December 2007.

              Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
              "Protected EAP Protocol (PEAP) Version 2",
              draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
              October 2004.

   [RFC3990]  O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
              Provisioning for Wireless Access Points (CAPWAP) Problem
              Statement", RFC 3990, February 2005.

   [RFC4186]  Haverinen, H. and J. Salowey, "Extensible Authentication
              Protocol Method for Global System for Mobile
              Communications (GSM) Subscriber Identity Modules (EAP-
              SIM)", RFC 4186, January 2006.

   [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
              Protocol Method for 3rd Generation Authentication and Key
              Agreement (EAP-AKA)", RFC 4187, January 2006.


   [RFC4507]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 4507, May 2006.

   [RFC4851]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
              Flexible Authentication via Secure Tunneling Extensible
              Authentication Protocol Method (EAP-FAST)", RFC 4851,
              May 2007.

              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications - Amendment 2: Fast BSS
              Transition", IEEE Standard 802.11r, June 2007.

              "Media Independent January 2008.

   [KP01]     Koodli, R. and C. Perkins, "Fast Handover Working Group", and Context
              Relocation in Mobile Networks", ACM SIGCOMM Computer and
              Communications Review, October 2001.

   [LGS07]    Ledlie, J., Gardner, P., and M. Selter, "Network
              Coordinates in the Wild", USENIX Symposium on Networked
              System Design and Implementation, April 2007.

   [MSA03]    Mishra, A., Shin, M., and W. Arbaugh, "An Empirical
              Analysis of the IEEE Working
              Group 802.21. 802.11 MAC-Layer Handoff Process",
              ACM SIGCOMM Computer and Communications Review,
              April 2003.

Authors' Addresses

   T. Charles Clancy, Editor
   Laboratory for Telecommunications Sciences
   US Department of Defense
   College Park, MD

   Email: clancy@LTSnet.net
   Madjid Nakhjiri

   Email: madjid.nakhjiri@motorola.com

   Vidya Narayanan
   Qualcomm, Inc.
   San Diego, CA

   Email: vidyan@qualcomm.com

   Lakshminath Dondeti
   Qualcomm, Inc.
   San Diego, CA

   Email: ldondeti@qualcomm.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).