summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5169.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5169.txt')
-rw-r--r--doc/rfc/rfc5169.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc5169.txt b/doc/rfc/rfc5169.txt
new file mode 100644
index 0000000..2a4d914
--- /dev/null
+++ b/doc/rfc/rfc5169.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group T. Clancy
+Request for Comments: 5169 LTS
+Category: Informational M. Nakhjiri
+ Motorola
+ V. Narayanan
+ L. Dondeti
+ Qualcomm
+ March 2008
+
+
+ Handover Key Management and Re-Authentication Problem Statement
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Abstract
+
+ 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
+ and handovers without re-executing an EAP method. This often causes
+ unacceptable latency in various mobile wireless environments. This
+ document details the problem and defines design goals for a generic
+ mechanism to reuse derived EAP keying material for handover.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clancy, et al. Informational [Page 1]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7
+ 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8
+ 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
+ 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9
+ 6.1. Method-Specific EAP Re-Authentication . . . . . . . . . . 9
+ 6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 10
+ 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clancy, et al. Informational [Page 2]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+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 scenarios, 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 encapsulating
+ EAP packets from a network-access technology 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.
+
+ After successful authentication, the EAP server 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.
+
+ Wireless handover between access points or base stations is typically
+ a complex process that involves several layers of protocol execution.
+ Often times executing these protocols results in unacceptable delays
+ for many real-time applications such as voice [MSA03]. One part of
+ the handover process is EAP re-authentication, which can contribute
+ significantly to the overall handover time [MSPCA04]. Thus, in many
+ environments we can lower overall handover time by lowering EAP re-
+ authentication time.
+
+ In EAP existing implementations, when a peer arrives at the new
+ 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 the server, followed by one or more round trips
+ between the EAP server and peer to perform the authentication,
+
+
+
+Clancy, et al. Informational [Page 3]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+ 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 (Extensible Authentication Protocol - Transport
+ Layer Security) requires at least 3, but typically 4 or more, round
+ trips.
+
+ There have been attempts to solve the problem of efficient re-
+ authentication in various ways. However, those solutions are either
+ EAP-method specific or EAP lower-layer specific. Furthermore, these
+ solutions do not deal with scenarios involving handovers to new
+ authenticators, or they do not conform to the AAA keying requirements
+ specified in [RFC4962].
+
+ This document provides a detailed description of efficient EAP-based
+ re-authentication protocol design goals. The scope of this protocol
+ is specifically re-authentication and handover between authenticators
+ within a single administrative domain. While the design goals
+ presented in this document may facilitate inter-technology handover
+ and inter-administrative-domain handover, they are outside the scope
+ of this protocol.
+
+2. Terminology
+
+ In this document, several words are used to signify the requirements
+ of the specification. These words are often capitalized. The key
+ words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+ "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
+ are to be interpreted as described in [RFC2119], with the
+ qualification that, unless otherwise stated, they apply to the design
+ of the re-authentication protocol, not its implementation or
+ application.
+
+ With respect to EAP, this document follows the terminology that has
+ been defined in [RFC3748] and [EAP-KEYING].
+
+3. Problem Statement
+
+ Under the existing model, any re-authentication requires a full EAP
+ exchange with the EAP server 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].
+
+
+
+Clancy, et al. Informational [Page 4]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+ 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 two or more
+ round trips to complete, causing delays in re-authentication and
+ handover times. Some methods specify the use of keys and state from
+ the initial authentication to finish subsequent authentications in
+ fewer round trips and without using public-key operations (detailed
+ in Section 6.1). However, even in those cases, multiple round trips
+ to the EAP server are required, resulting in unacceptable handover
+ times.
+
+ In summary, it is undesirable to run 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, efficient, re-authentication protocol. Keying material
+ from the initial authentication can be used to enable efficient re-
+ authentication. It is also desirable to have a local server with
+ low-latency connectivity to the peer that can facilitate re-
+ authentication. Lastly, a re-authentication protocol should also be
+ capable of supporting scenarios where an EAP server passes
+ authentication information to a remote re-authentication server,
+ allowing a peer to re-authenticate 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,
+ 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
+ capabilities over heterogeneous technologies. The defined
+ protocols MAY require some additional support from the lower
+ layers that use it, but should not require any particular lower
+ layer.
+
+
+
+Clancy, et al. Informational [Page 5]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+ 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, provided
+ they satisfy [EAP-KEYING] and [RFC4017]. Note that the only EAP
+ methods for which independence is required are those that
+ currently conform to the specifications of [EAP-KEYING] and
+ [RFC4017]. In particular, methods that do not generate the keys
+ required by [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 [RADEXT-DESIGN] and
+ Diameter [DIME-APP-DESIGN]. 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 [RFC4962].
+
+ Compatibility: Compatibility and coexistence with compliant
+ ([RFC3748] [EAP-KEYING]) EAP deployments MUST be provided.
+ Specifically, the protocol should be designed such that a peer not
+ supporting fast re-reauthentication should still 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 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).
+
+ 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
+
+ This section draws from the guidance provided in [RFC4962] to further
+ define the security goals to be achieved by a complete re-
+ authentication keying solution.
+
+
+
+
+
+
+
+
+Clancy, et al. Informational [Page 6]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+5.1. Key Context and Domino Effect
+
+ 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
+ lifetime and scope of each key must be defined clearly so that all
+ entities that are authorized to have access to the key have the same
+ context during the validity period. In a hierarchical key structure,
+ the lifetime of lower-level keys must not exceed the lifetime of
+ higher-level keys. This requirement may imply that the context and
+ the scope parameters have to be exchanged. Furthermore, the
+ semantics of these parameters 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 protocol.
+
+ If a key hierarchy is deployed, compromising lower-level keys must
+ not result in a compromise of higher-level keys that 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 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, and storage and deletion
+ procedures to ensure adequate security and authorization provisioning
+ for keying procedures must be defined in a solution document.
+
+ All the keying material 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 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
+ hierarchy.
+
+
+
+
+
+
+
+
+
+
+Clancy, et al. Informational [Page 7]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+5.3. Authentication
+
+ Each handover keying participant must be authenticated to any other
+ party with whom it 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.
+
+5.4. Authorization
+
+ The EAP Key management document [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.
+ 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 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. To
+ support fast re-authentication, there 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 a 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 be developed.
+
+ 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 for being transferred over any of the links
+
+
+
+
+Clancy, et al. Informational [Page 8]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+ in the architecture, are part of the scope. The relation between 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] support 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 [EAP-TTLS] and PEAP (Protected EAP Protocol)
+ [JOSEFSSON-PPPEXT] 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
+ [RFC5077]. 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
+ server.
+
+
+
+
+
+
+
+Clancy, et al. Informational [Page 9]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+6.2. IEEE 802.11r Applicability
+
+ One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in
+ the process of specifying a fast handover mechanism. Access Points
+ (APs) are grouped into mobility domains. Initial authentication to
+ any AP in a mobility domain requires execution of EAP, but handover
+ between APs within the mobility domain does not require the use of
+ EAP.
+
+ Internal to the mobility domain are sets of security associations to
+ support key transfers between APs. In one model, relatively few
+ devices, called R0-KHs, act as authenticators. All EAP traffic
+ traverses an R0-KH, and it derives the initial IEEE 802.11 keys. It
+ then distributes cryptographically separate keys to APs in the
+ mobility domain, as necessary, to support the client mobility. For a
+ deployment with M designated R0-KHs and N APs, this requires M*N
+ security associations. For small M, this approach scales reasonably.
+ Another approach allows any AP to act as an R0-KH, necessitating a
+ full mesh of N2 security associations, which scales poorly.
+
+ The model that utilizes designated R0-KHs is architecturally similar
+ to the fast re-authentication model proposed by HOKEY. HOKEY,
+ however, allows for handover between authenticators. This would
+ allow an IEEE 802.11r-enabled peer to handover from one mobility
+ domain to another without performing an EAP authentication.
+
+6.3. CAPWAP Applicability
+
+ The CAPWAP (Control and Provisioning of Wireless Access Points)
+ protocol [CAPWAP-PROTOCOL-SPEC] allows the functionality of an IEEE
+ 802.11 access point to be split into two physical devices in
+ enterprise deployments. Wireless Termination Points (WTPs) implement
+ the physical and low-level Media Access Control (MAC) layers, while a
+ centralized Access Controller (AC) provides higher-level management
+ and 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
+ uses it to execute a separate four-way handshake with the station as
+ it moves between WTPs. The keys resulting from the four-way
+ handshake are then distributed to the WTP to which the 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 addresses is an inter-authenticator handover problem
+
+
+
+Clancy, et al. Informational [Page 10]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+ from an EAP perspective, which applies during handover between ACs.
+ 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
+ manner.
+
+7. Security Considerations
+
+ This document details the HOKEY problem statement. Since HOKEY is an
+ authentication protocol, there is 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 5 for further details.
+
+8. 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
+ Nokia
+ EMail: mohan.parthasarathy@nokia.com
+
+ Julien Bournelle
+ France Telecom R&D
+ EMail: julien.bournelle@orange-ftgroup.com
+
+ Hannes Tschofenig
+ Siemens
+ EMail: Hannes.Tschofenig@siemens.com
+
+ Rafael Marin Lopez
+ Universidad de Murcia
+ EMail: rafa@dif.um.es
+
+9. 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, Jari Arkko, and Hannes Tschofenig.
+
+
+
+
+
+Clancy, et al. Informational [Page 11]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+10. References
+
+10.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.
+
+10.2. Informative References
+
+ [CAPWAP-PROTOCOL-SPEC] Calhoun, P., Montemurro, M., and D. Stanely,
+ "CAPWAP Protocol Specification", Work
+ in Progress, March 2008.
+
+ [DIME-APP-DESIGN] Fajardo, V., Asveren, T., Tschofenig, H.,
+ McGregor, G., and J. Loughney, "Diameter
+ Applications Design Guidelines", Work
+ in Progress, January 2008.
+
+ [EAP-KEYING] Aboba, B., Simon, D., and P. Eronen,
+ "Extensible Authentication Protocol (EAP) Key
+ Management Framework", Work in Progress,
+ November 2007.
+
+ [EAP-TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled
+ TLS Authentication Protocol Version 0 (EAP-
+ TTLSv0)", Work in Progress, March 2008.
+
+
+
+
+
+
+
+
+
+Clancy, et al. Informational [Page 12]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+ [IEEE.802-11R-D9.0] "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,
+ January 2008.
+
+ [JOSEFSSON-PPPEXT] Josefsson, S., Palekar, A., Simon, D., and G.
+ Zorn, "Protected EAP Protocol (PEAP) Version
+ 2", Work in Progress, October 2004.
+
+ [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 802.11 MAC-
+ Layer Handoff Process", ACM SIGCOMM Computer
+ and Communications Review, 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.
+
+ [RADEXT-DESIGN] Weber, G. and A. DeKok, "RADIUS Design
+ Guidelines", Work in Progress, December 2007.
+
+ [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.
+
+
+
+
+
+Clancy, et al. Informational [Page 13]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+ [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.
+
+ [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H.
+ Tschofenig, "Transport Layer Security (TLS)
+ Session Resumption without Server-Side
+ State", RFC 5077, January 2008.
+
+Authors' Addresses
+
+ T. Charles Clancy, Editor
+ Laboratory for Telecommunications Sciences
+ US Department of Defense
+ College Park, MD
+ USA
+
+ EMail: clancy@LTSnet.net
+
+
+ Madjid Nakhjiri
+ Motorola
+
+ EMail: madjid.nakhjiri@motorola.com
+
+
+ Vidya Narayanan
+ Qualcomm, Inc.
+ San Diego, CA
+ USA
+
+ EMail: vidyan@qualcomm.com
+
+
+ Lakshminath Dondeti
+ Qualcomm, Inc.
+ San Diego, CA
+ USA
+
+ EMail: ldondeti@qualcomm.com
+
+
+
+
+
+
+
+
+
+Clancy, et al. Informational [Page 14]
+
+RFC 5169 HOKEY Re-Auth PS March 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+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
+ http://www.ietf.org/ipr.
+
+ 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
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Clancy, et al. Informational [Page 15]
+