[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5749

Network Working Group                                 K. Hoeper (Editor)
Internet-Draft                                                  Motorola
Intended status: Standards Track                        Y. Ohba (Editor)
Expires: August 29, 2009                                         Toshiba
                                                       February 25, 2009


 Derivation, delivery and management of EAP based keys for handover and
                           re-authentication
                      draft-ietf-hokey-key-mgm-05

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 1]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes a mechanism for delivering root keys from an
   Extensible Authentication Protocol (EAP) server to another network
   server that requires the keys for offering security protected
   services, such as re-authentication, to an EAP peer.  The distributed
   root key can be either a usage-specific root key (USRK), a domain-
   specific root key (DSRK) or a usage-specific domain-specific root key
   (USDSRK) that has been derived from an Extended Master Session Key
   (EMSK) hierarchy previously established between the EAP server and an
   EAP peer.  The document defines a key distribution exchange (KDE)
   protocol using Remote Authentication Dial In User Service (RADIUS)
   that can distribute these different types of root keys and discusses
   its security requirements.































Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 2]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Key Delivery Architecture  . . . . . . . . . . . . . . . . . .  5
   4.  Key Distribution Exchange (KDE)  . . . . . . . . . . . . . . .  7
     4.1.  Context and Scope for Distributed Keys . . . . . . . . . .  8
     4.2.  Key Distribution Exchange Scenarios  . . . . . . . . . . .  8
   5.  RADIUS KDE Attribute . . . . . . . . . . . . . . . . . . . . .  9
   6.  KDE used in the EAP Re-authentication Protocol (ERP) . . . . . 10
   7.  Conflicting Messages . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
     8.1.  Requirements on RADIUS Key Transport . . . . . . . . . . . 11
     8.2.  Distributing RK without Peer Consent . . . . . . . . . . . 12
   9.  IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     12.2. Informative references . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14






























Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 3]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


1.  Introduction

   The Extensible Authentication Protocol (EAP) [RFC3748] is an
   authentication framework supporting authentication methods that are
   specified in EAP methods.  By definition, any key-generating EAP
   method derives an Master Session Key (MSK) and an Extended Master
   Session Key (EMSK).  [RFC5295] reserves the EMSK for the sole purpose
   of deriving root keys that can be used for specific purposes called
   usages.  In particular, [RFC5295] defines how to create a usage-
   specific root key (USRK) for bootstrapping security in a specific
   application, a domain-specific root key (DSRK) for bootstrapping
   security of a set of services within a domain, and a usage-specific
   DSRK (USDSRK) for a specific application within a domain.

   MSK and EMSK may be used to derive further keying material for a
   variety of security mechanisms [RFC5247].  For example, the MSK has
   been widely used for bootstrapping the wireless link security
   associations between the peer and the network attachment points.
   However, performance as well as security issues arise when using the
   MSK and the current bootstrapping methods in mobile scenarios that
   require handovers, as described in [RFC5169].  To address handover
   latencies and other shortcomings, [RFC5296] specifies an EAP re-
   authentication protocol (ERP) that uses keys derived from EMSK or
   DSRK to enable efficient re-authentications in handover scenarios.
   [RFC5295] and [RFC5296] both do not specify how root keys are
   delivered to the network server requiring the key.  Such a key
   delivery mechanism is essential because the EMSK cannot leave the EAP
   server ([RFC5295]) but root keys are needed by other network servers
   disjoint with the EAP server.  For example, in order to enable an EAP
   peer to re-authenticate to a network during a handover, certain root
   keys need to be made available by the EAP server to the server
   carrying out the re-authentication.

   This document specifies a mechanism for the delivery of EMSK child
   keys from the server holding the EMSK or a root key to another
   network server that requests a root key for providing protected
   services (such as re-authentication and other usage and domain-
   specific services) to EAP peers.  In the remainder of this document,
   a server delivering root keys is referred to as Key Delivering Server
   (KDS) and a server authorized to request and receive root keys from a
   KDS is referred to as Key Requesting Server (KRS).  The Key
   Distribution Exchange (KDE) protocol defined in this document uses
   RADIUS [RFC2865], [RFC3579] and has several variants depending on the
   type of key that is requested and delivered (i.e.  DRSK, USRK, and
   USDSRK).  The document also describes security requirements for the
   secure key delivery over RADIUS.





Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 4]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


2.  Terminology

   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].

   USRK:  Usage-Specific Root Key. A root key that is derived from the
      EMSK, see [RFC5295].

   USR-KH:  USRK Holder.  A network server that is authorized to request
      and receive a USRK from the EAP server.  The USR-KH can be an AAA
      server or dedicated service server.

   DSRK:  Domain-Specific Root Key. A root key that is derived from the
      EMSK, see [RFC5295].

   DSR-KH:  DSRK Holder.  A network server that is authorized to request
      and receive a DSRK from the EAP server.  The most likely
      implementation of a DSR-KH is an AAA server in a domain, enforcing
      the policies for the usage of the DSRK within this domain.

   DSUSRK:  Domain-Specific Usage-Specific Root Key. A root key that is
      derived from the DSRK, see [RFC5295].

   DSUSR-KH:  DSUSRK holder.  A network server authorized to request and
      receive a DSUSRK from the DSR-KH.  The most likely implementation
      of a DSUSR-KH is an AAA server in a domain, responsible for a
      particular service offered within this domain.

   RK:  Root Key. An EMSK child key, i.e. a USRK, DSRK, or DSUSRK.

   KDS:  Key Delivering Server.  A network server that holds an EMSK or
      DSRK and delivers root keys to KRS requesting root keys.  The EAP
      server and DSR-KH can act as KDS.

   KRS:  Key Requesting Server.  A network server that shares an
      interface with a KDS and is authorized to request root keys from
      the KDS.  USR-KH, DSR-KH, and DSUSR-KH can all act as KRS.


3.  Key Delivery Architecture

   An EAP server carries out the EAP authentications with EAP peers but
   is typically not making any, potentially future, service
   authorization decisions involving peers.  Authorizations as well as
   the service provisioning are handled by the respective network server
   offering the requested service.  These servers can be AAA servers or
   other service servers.  Whenever EAP-based keying material is used to



Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 5]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


   protect a requested service, a network server needs to request the
   root key associated with the offered service from the respective KDS.
   This kind of key requests and distributions are necessary because an
   EMSK cannot leave the EAP server ([RFC5295]).  Hence, any root key
   that is directly derived from an EMSK must be derived and delivered
   by the EAP server itself, whereas root keys derived from EMSK child
   keys, such as a DSUSRK, can be requested from the respective root key
   holder.  Hence, a KDS can be either the EAP server or a DSRK holder
   (DSR-KH), whereas a KRS can be either a USRK holder (USR-KH), a
   DSR-KH or a DSUSRK holder (DSUSR-KH).

   The KRS needs to share an interface with the KDS to be able to send
   all necessary input data to derive the requested key and to receive
   the requested key.  The provided data includes the Key Derivation
   Function (KDF) that should be used to derive the requested key.  The
   KRS uses the received root key to derive further keying material in
   order to secure its offered services.  Every KDS is responsible for
   storing and protecting the received root key as well as the
   derivation and distribution of any child key derived from the root
   key.  An example of a key delivery architecture is illustrated in
   Figure 1 showing the different types of KRS and their interfaces to
   the KDS.

                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 |             EAP server                  |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  /             |             |          \
                 /              |             |           \
                /               |             |            \
        +-+-+-+-+-+-+-+   +-+-+-+-+-+-+  +-+-+-+-+-+  +-+-+-+-+-+
        |   USR-KH1   |   |  USR-KH2  |  | DSR-KH1 |  | DSR-KH2 |
        | HOKEY server|   | XYZ server|  |Domain 1 |  | Domain 2|
        +-+-+-+-+-+-+-+   +-+-+-+-+-+-+  +-+-+-+-+-+  +-+-+-+-+-+
                                             /             |
                                            /              |
                                           /               |
                                    +-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
                                    |  DSUSR-KH   |  |  DSUSR-KH2    |
                                    |  Domain 1   |  |   Domain 2    |
                                    |Home domain  |  |Visited domain |
                                    |HOKEY server |  |HOKEY server   |
                                    +-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+


   Figure 1: Example Key Delivery Architecture for the Different KRS and
                                    KDS





Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 6]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


4.  Key Distribution Exchange (KDE)

   In this section, a generic mechanism for a key distribution exchange
   (KDE)over RADIUS is described in which a root key (RK) is distributed
   from a KDS to a KRS.  It is required that the communication path
   between the KDS and the KRS is protected by the use of an appropriate
   RADIUS transport security mechanism (see Section 8).  Here, it is
   assumed that the KRS and the KDS are separate entities, logically if
   not physically, and the delivery of the requested RK is specified
   accordingly.

   The key distribution exchange consists of one roundtrip, i.e. two
   messages between the KRS and the KDS, as illustrated in Figure 2.
   First, the KRS sends a KDE-Request consisting of a RADIUS Access-
   Request message with a KDE attribute in which the K-flag is cleared.
   As a response, the KDS sends a KDE-Response consisting of a RADIUS
   Access-Accept message with a KDE attribute in which the K-flag set.
   The RADIUS KDE attribute used in this exchange is defined in
   Section 5.

     KRS                                        KDS
   --------                                   -------
       |                                          |
       |                                          |
       |  KDE-Request (KRT)                       |
       | (i.e., RADIUS Access-Request{KDE(K=0)})  |
       |----------------------------------------->|
       |  KDE-Response(KDT)                       |
       | (i.e., RADIUS Access-Accept{KDE(K=1)})   |
       |<-----------------------------------------|


                        Figure 2: KDE Message Flow

   KDE-Request:  The KRS sends a Key Request Token (KRT) to the KDS.
      The contents of KRT are detailed below.

   KDE-Response:  As a response, the KDS sends the requested RK to the
      KRS wrapped inside a token called Key Delivery Token (KDT).  The
      contents of KDT are detailed below.

   KRT : (PID, KT, KL)

      KRT carries the identifiers of the peer (PID), the key type (KT)
      and the key label (KL).  See [RFC5295] for the specification of
      key labels.





Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 7]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


   KDT : (KT, KL, RK, KN_RK, LT_RK)

      KDT carries the root key (RK) to be distributed to the KRS, as
      well as the key type (KT), the key label (KL), the key name
      (KN_RK) and the lifetime of RK (LT_RK).

4.1.  Context and Scope for Distributed Keys

   The key lifetime of each distributed key MUST NOT be greater than
   that of its parent key.

   The key context of each distributed key is determined by the sequence
   of KTs in the key hierarchy.  When a DSRK is being delivered and the
   DSRK applies to only a specific set of services, the service types
   may need to be carried as part of context for the key.  Carrying such
   a specific set of services is outside the scope of this document.

   The key scope of each distributed key is determined by the sequence
   of (PID, KT, KL)-tuples in the key hierarchy.  The KDF used to
   generate the requested keys includes context and scope information,
   thus, binding the key to the specific channel [RFC5295].

4.2.  Key Distribution Exchange Scenarios

   Given the three types of KRS, there are three scenarios for the
   distribution of EMSK child keys.  For all scenarios, the trigger and
   mechanism for key delivery may involve a specific request from an EAP
   peer and/or another intermediary (such as an authenticator).  For
   simplicity, it is assumed that USR-KHs reside in the same domain as
   the EAP server.

   Scenario 1: EAP server to USR-KH:  In this scenario, the EAP server
      delivers a USRK to a USR-KH.

   Scenario 2: EAP server to DSR-KH:  In this scenario, the EAP server
      delivers a DSRK to a DSR-KH.

   Scenario 3: DSR-KH to DSUSR-KH:  In this scenario, a DSR-KH in a
      specific domain delivers keying material to a DSUSR-KH in the same
      domain.

   The key distribution exchanges for Scenario 3 can be combined with
   the key distribution exchanges for Scenario 2 into a single roundtrip
   exchange as shown in Figure 3.  Here, KDE-Request and KDE-Response
   are messages for Scenarios 2, whereas KDE-Request' and KDE-Response'
   are messages for Scenarios 3.





Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 8]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


   DSUSR-KH                   DSR-KH                    EAP Server
   --------                  -------                      -----
      |  KDE-Request'(KRT')     |   KDE-Request(KRT)        |
      |------------------------>|-------------------------->|
      |  KDE-Response'(KDT')    |   KDE-Response(KDT)       |
      |<----------------------- |<--------------------------|
      |                         |                           |


                    Figure 3: Combined Message Exchange


5.  RADIUS KDE Attribute

   This section defines the format of the RADIUS KDE attribute.  See
   Section 8 for security requirements on transporting this RADIUS
   attribute.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |K|  Reserved   |   Key Type    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Key Label                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Key Name       (included only when K=1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Key            (included only when K=1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Key Lifetime   (included only when K=1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      = X (KDE) [X to be assigned by IANA].

   Length

      >4

   K (Key included)

      A flag to indicate whether this attribute contains a Key field.
      This flag is set for a KDE-Response.  This flag is cleared for a
      KDE-Request.





Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009        [Page 9]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


   Reserved

      Reserved bits.  All reserved bits MUST be set to 0 by the sender
      and ignored by the recipient.

   Key Type

      A field to contain a KT.  The following KT values are defined: 0
      (DSRK), 1 (USRK) and 2 (DSUSRK).

   Key Label

      A field to contain a key label (KL).  The first octet contains the
      length of the rest of this field in octets.

   Key Name

      A field to contain a KN_RK.  The first octet contains the length
      of the rest of this field in octets.  This field is contained if
      and only if K-flag is set.

   Key

      A field to contain a RK.  The first octet contains the length of
      the rest of this field in octets.  This field is contained if and
      only if K-flag is set.

   Key Lifetime

      A 4-octet unsigned integer to indicate a LT_RK.  This field is
      contained if and only if K-flag is set.


6.  KDE used in the EAP Re-authentication Protocol (ERP)

   This section describes how the presented KDE should be used to
   request and deliver the root keys used for re-authentication in the
   EAP Re-authentication Protocol (ERP) defined in [RFC5296].  ERP
   supports two forms of bootstrapping, implicit as well as explicit
   bootstrapping, and KDE is discussed for both cases in the remainder
   of this section.

   In implicit bootstrapping the local EAP Re-authentication (ER) server
   requests the DSRK from the home AAA server during the initial EAP
   exchange.  Here, the local ER server acts as the KRS and the home AAA
   server as the KDS.  In this case, the local ER server requesting the
   DSRK MUST include a KDE attribute with the K-flag cleared in the
   RADIUS Access-Request message that carries the first EAP-Response



Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009       [Page 10]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


   message from the peer.  A value of the RADIUS User-Name attribute is
   used as the PID.  Upon receiving a valid KDE-Request, the home AAA
   server includes a KDE attribute with K-flag set in the RADIUS Access-
   Accept message that carries the EAP-Success message.

   Explicit bootstrapping is initiated by a peer if it doesn't know the
   domain.  Here, EAP-Initiate and EAP-Finish messages are exchanged
   between the peer and the home AAA server, with the bootstrapping flag
   in the EAP-Initiate message set.  In this case, the local ER server
   (acting as KRS) MUST include a KDE attribute with the K-bit cleared
   in a RADIUS Access-Request message that carries an EAP-Initiate
   message with the bootstrapping flag turned on.  A value of the RADIUS
   User-Name attribute is used as the PID.  In its response, the home
   AAA server (acting as KDS) MUST include a KDE attribute with K-flag
   set in a RADIUS Access-Accept message that carries an EAP-Finish
   message for which the bootstrapping flag is set.


7.  Conflicting Messages

   In addition to the rules specified in Section 2.6.3. of [RFC3579],
   the following combinations SHOULD NOT be sent by a RADIUS Server:

   Access-Accept/EAP-Message/EAP-Finish with 'R' flag set to 1
   Access-Reject/EAP-Message/EAP-Finish with 'R' flag set to 0
   Access-Reject/Keying-Material
   Access-Reject/KDE
   Access-Challenge/EAP-Message/EAP-Initiate
   Access-Challenge/EAP-Message/EAP-Finish
   Access-Challenge/KDE


8.  Security Considerations

   This section provides security requirements and an analysis on
   transporting EAP keying material using RADIUS.

8.1.  Requirements on RADIUS Key Transport

   RADIUS messages that carry a KDE attribute MUST be encrypted,
   integrity-protected and replay-protected with a security association
   created by a RADIUS transport protocol such as TLS
   [I-D.ietf-radext-radsec].  When there is an intermediary such as a
   RADIUS proxy on the path between the KRS and the KDS, there will be a
   series of hop-by-hop security associations along the path.  The use
   of hop-by-hop security associations implies that the intermediary on
   each hop can access the distributed keying material.  Hence the use
   of hop-by-hop security SHOULD be limited to an environment where an



Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009       [Page 11]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


   intermediary is trusted not to abuse the distributed key material.

8.2.  Distributing RK without Peer Consent

   When a KDE-Request message is sent as a result of explicit ERP
   bootstrapping [RFC5296], cryptographic verification of peer consent
   on distributing a RK is provided by the integrity checksum of the
   EAP-Initiate message with the bootstrapping flag turned on.

   When a KDE-Request message is sent as a result of implicit ERP
   bootstrapping [RFC5296], cryptographic verification of peer consent
   on distributing a RK is not provided.  As a result, it is possible
   for a KRS to request a RK from the home server and obtain the RK even
   if the peer does not support ERP, which can lead to an unintended use
   of a RK and failed authentication attempts.


9.  IANA consideration

   This document defines a new namespace for maintaining Key Type used
   to identify the type of the root key RK.  The range of values 0 - 255
   are for permanent, standard message types, allocated by IETF Review
   [IANA].  This document defines the values 0 (DSRK), 1 (USRK) and 2
   (DSUSRK).

   This document defines a new RADIUS Attribute Type for KDE in
   Section 5.


10.  Acknowledgements

   The author would like to thank Dan Harkins, Chunqiang Li, Rafael
   Marin Lopez and Charles Clancy for their valuable comments.


11.  Contributors

   The following people contributed to this document.













Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009       [Page 12]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


        Madjid Nakhjiri (madjid.nakhjiri@motorola.com)

        Yoshihiro Ohba (yohba@tari.toshiba.com)

        Kedar Gaonkar (kgaonkar3@gatech.edu)

        Lakshminath Dondeti (ldondeti@qualcomm.com)

        Vidya Narayanan (vidyan@qualcomm.com)

        Glen Zorn (glenzorn@comcast.net)


12.  References

12.1.  Normative References

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

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

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

   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
              "Specification for the Derivation of Root Keys from an
              Extended Master Session Key (EMSK)", RFC 5295,
              August 2008.

   [RFC5296]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
              authentication Protocol (ERP)", RFC 5296, August 2008.

   [IANA]     Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",  BCP 26, RFC 5226,
              May 2008.

12.2.  Informative references

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",



Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009       [Page 13]


Internet-Draft       HOKEY Key Distribution Exchange       February 2009


              RFC 5247, August 2008.

   [RFC5169]  Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
              "Handover Key Management and Re-Authentication Problem
              Statement", RFC 5169, March 2008.

   [I-D.ietf-radext-radsec]
              Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
              "TLS encryption for RADIUS over TCP (RadSec)",
              draft-ietf-radext-radsec-03 (work in progress),
              February 2009.


Authors' Addresses

   Katrin Hoeper
   Motorola
   1301 E Algonquin Road
   Schaumburg, IL  60196
   USA

   Phone: +1 847 576 4714
   Email: khoeper@motorola.com


   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Phone: +1 732 699 5305
   Email: yohba@tari.toshiba.com


















Hoeper (Editor) & Ohba (Editor)  Expires August 29, 2009       [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/