GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5169

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5169.txt · Last modified: 2008/03/28 23:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki