[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                                   Y. Ohba (Editor)
Internet-Draft                                                   Toshiba
Expires: April 22, 2009                                 October 19, 2008


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

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-
   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 April 22, 2009.

Abstract

   This document describes a mechanism for delivering a usage-specific
   root key (USRK), a domain-specific root key (DSRK) and a usage-
   specific domain-specific root key (USDSRK) using RADIUS.  The root
   keys are derived as part of an Extended Master Session Key (EMSK)
   hierarchy in Extensible Authentication Protocol (EAP), and delivered
   from a server to an intended third-party key holder.  The mechanism
   supports different scenarios for key delivery, depending on the type
   of keys being delivered.  The mechanism description includes the
   definition for a key distribution exchange (KDE) protocol.






Ohba (Editor)            Expires April 22, 2009                 [Page 1]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Key Delivery Architecture  . . . . . . . . . . . . . . . . . .  4
   4.  Key Distribution Exchange (KDE)  . . . . . . . . . . . . . . .  6
     4.1.  Context and scope for distributed keys . . . . . . . . . .  7
     4.2.  Key distribution exchange scenarios  . . . . . . . . . . .  8
   5.  RADIUS KDE Attribute . . . . . . . . . . . . . . . . . . . . .  8
   6.  Conflicting Messages . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
     7.1.  Requirements on RADIUS Key Transport . . . . . . . . . . . 11
     7.2.  Distributing Kpt without Peer Consent  . . . . . . . . . . 11
   8.  IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     11.2. Informative references . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14






























Ohba (Editor)            Expires April 22, 2009                 [Page 2]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


1.  Introduction

   The ability of the Extensible Authentication Protocol (EAP) framework
   [RFC3748] to incorporate desired authentication methods and generate
   master session keys (an MSK and an EMSK) [RFC5247] has led to the
   idea of using the MSK and/or the EMSK for bootstrapping further keys
   for a variety of security mechanisms.  The MSK has been widely used
   for bootstrapping the wireless link security associations between the
   peer and the network attachment points.  Issues arising from the use
   of the MSK and the current bootstrapping methods when it comes to
   mobility performance and security are described in [RFC5169].  The
   EMSK is used for bootstrapping of keys for use cases that are not
   covered by the use case of the MSK [RFC5295].  For instance [RFC5295]
   defines a way to create a usage-specific root key (USRK) for
   bootstrapping security for a specific use case.  [RFC5295] also
   defines ways to create domain-specific root keys for bootstrapping
   security of a set of services within a domain.

   Along with those lines, this document provides a specification of a
   mechanism for secure delivery of such EMSK child keys from the EAP
   server, holding the EMSK, to the intended third-party destinations by
   using RADIUS [RFC2865], [RFC3579].  This document also describes
   security requirements on delivery for this keying material over
   RADIUS.


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 generated from the EMSK
      and is used for a specific usage that is authorized for a peer,
      following an EAP authentication.  USRKs are domain independent.

   USR-KH:  USRK Holder.  The USR-KH is responsible for receiving,
      holding and protecting the USRK derived directly from the EMSK.

   DSRK:  Domain-Specific Root Key. A root key generated from the EMSK
      and is used within a specific domain that EAP-authenticated peer
      is authorized to receive services from or roam into.  DSRKs are
      usage independent.

   DSR-KH:  DSRK holder.  The DSRK holder is responsible for receiving,
      holding and protecting the DSRK derived directly from the EMSK.





Ohba (Editor)            Expires April 22, 2009                 [Page 3]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


   DSUSRK:  Domain-Specific Usage-Specific Root Key. A root key
      generated from the DSRK and is used for a specific usage within a
      specific domain that an EAP-authenticated peer is authorized to
      receive services from.  DSUSRKs are both usage and domain
      dependent.

   DSUSR-KH:  DSRK holder.  The DSUSRK holder is responsible for
      receiving, holding and protection of the DSUSRK.


3.  Key Delivery Architecture

   The EAP server is only responsible for performing EAP authentication
   and is not expected to be involved in any service authorization
   decisions, nor is the EAP server aware of the future service requests
   at the time of authentication.  The authorization decisions based on
   the user service profile and provisioning of services including
   support for service security is expected to happen by third-parties,
   such as AAA servers or service servers.  When EAP-based keying is
   used, such servers will cache and use the USRKs, DSRKs or DSUSRKs,
   generated from the EMSK, as root keys for derivation of further keys
   to secure the services they are providing.  Thus they are considered
   third-party key holders (KH) with respect to the initial two EAP
   parties (EAP peer and server).  However, since the EMSK cannot be
   exported from the EAP server, such third-parties need to request the
   EAP server to generate the relevant root key (e.g., a USRK) from the
   EMSK and deliver the requested key to them.  The third-party needs to
   provide the required input data to be used along with the pseudo
   random function (PRF) to the EAP server to generate the requested
   key.  The following types of top level key holders can be envisioned:

   USRK holder (USR-KH):  An entity acting as a recipient and then
      holder of the usage-specific root key (USRK).  The USR-KH is
      responsible for derivation and distribution of any child keys
      derived from the USRK for that specific usage.  We assume that the
      USR-KH and the EAP server are separate entities, logically if not
      physically, and we specify the delivery of the USRK from EAP
      server to USR-KH accordingly.

   DSRK holder (DSR-KH):  An entity acting as a recipient and then
      holder of the domain-specific root key (DSRK).  The DSR-KH is
      responsible for derivation and distribution of any child keys
      derived from the DSRK for that specific domain.  The most likely
      realization of a DSR-KH is a AAA server in the corresponding
      domain, responsible for setting the policies for usage of the DSRK
      within the domain.





Ohba (Editor)            Expires April 22, 2009                 [Page 4]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


   DSUSRK holder (DSUSR-KH):  An entity acting as a recipient and then
      holder of the domain-specific usage-specific root key (DSUSRK)
      delivered from the EAP server.  The DSUSR-KH is responsible for
      derivation and distribution of any child keys derived from the
      DSUSRK for that specific domain and usage.  The most likely
      realization of a DSUSR-KH is a AAA server in the corresponding
      domain, responsible for the service offered within the domain for
      the specific usage at hand.


                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |       EAP server                |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    /          |         \         \
                   /           |          \         \
         USRK1    /            | USRK2     \ USRK3   \ USRK4
         (ABC)   /             | (XYZ)      \(DSRK1)  \ (DSRK2)
   +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+   +-+-+-+-+-+ +-+-+-+-+-+
   |   USR-KH1     |   |   USR-KH2 |   | DSR-KH1 | | DSR-KH2 |
   | HOKEY server  |   | XYZ server|   +-+-+-+-+-+ +-+-+-+-+-+
   +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+      |               |
                                    +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
                                    | Domain 1    | | Domain 2    |
                                    | DSUSR-KH1   | | DSUSR-KH2   |
                                    |(home        | |(visited     |
                                    | domain      | | domain      |
                                    |HOKEY server)| |HOKEY server)|
                                    +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+

                            +-+-+-+-+-+-+
                            |   peer    |
                            +-+-+-+-+-+-+

        Figure 1: Key delivery for various EMSK child key cateories

   USR-KHs and DSR-KHs are the top-level key holders where each key
   holder has an interface with the EAP server.  The interface between a
   USR-KH and the EAP server is used for delivering usage-specific data
   needed for generating a USRK to the EAP server and receiving the
   resulting root key from the EAP server.  Similary, the interface
   between a DSR-KH and the EAP server is used for delivering domain-
   specific data needed for generating a DSRK to the EAP server and
   receiving the resulting root key from the EAP server.  DSUSR-KHs are
   considered a second-level key holder and has an interface with a
   DSR-KH.






Ohba (Editor)            Expires April 22, 2009                 [Page 5]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


4.  Key Distribution Exchange (KDE)

   In the following we describe the generic mechanism for a key
   distribution exchange (KDE), where a key is distributed from a
   network server (with parent key holder) to a third-party.  The
   following shows a generic trust model for the key distribution
   mechanism to the third-party.  The peer (P) and a parent key holder,
   called "server" (S) in this model share a parent key.  The goal of
   the keying solution is to use the parent key and generate a child key
   (Kpt) to be shared between the peer and the third-party intermediary
   (T).  The peer is able to generate Kpt, but Kpt needs to be
   distributed to a third-party intermediary (T).  The goal of this
   section is to provide a the general description of the KDE over
   RADIUS for distribution of Kpt from S to T. It is required that the
   communication path between the server (S) and the third-party (T) is
   protected by use of an appropriate RADIUS transport security
   mechanism (see Section 7).

             +-+-+-+-+                              +-+-+-+-+-+-+-+
             |       |            shared SA1        |             |
             |       |------------------------------|    server   |
             | Peer  |                              |       KH    |
             +-+-+-+-+                              +-+-+-+-+-+-+-+
                                                           |
                                 +-+-+-+-+-+-+             V
                                 | 3 rd party|             |   SA2 (Kpt)
                                 |       KH  |   ----------|
                                 +-+-+-+-+-+-+

   Figure 2: Distribution of a child key from a parent key key holder to
                     a 3rd party child key key holder

   The key distribution to a third-party consists of 1 exchange, i.e. 2
   messages between the third-party and the server.  A RADIUS KDE
   attribute is introduced for this exchange (see Section 5.  A KDE-
   Request is sent by the third-party as a RADIUS Access-Request message
   with a KDE attribute with K-flag cleared.  A KDE-Response is sent by
   the server as a RADIUS Access-Accept message with a KDE attribute
   with K-flag set.












Ohba (Editor)            Expires April 22, 2009                 [Page 6]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


   Third-Party                                Server
   --------                                   -------
       |                                          |
       |                                          |
       |  KDE-Request (TRT)                       |
       | (i.e., RADIUS Access-Request{KDE(K=0)})  |
       |----------------------------------------->|
       |  KDE-Response(TOK)                       |
       | (i.e., RADIUS Access-Accept{KDE(K=1)})   |
       |<-----------------------------------------|


                          Figure 3: KDE Exchange

   KDE-Request:  Third-party sends a third party request token (TRT) to
      the server.  The contents of TRT are detailed below.

   KDE-Response:  Server sends the Kpt to third-party wrapped inside a
      token called Key Token (TOK).

   TRT : (PID, KT, KL)

      TRT (Third-party Request Token) carries the identifiers of the
      peer (PID) as well as the key type (KT) and the key label (KL).
      See [RFC5295] for the specification of key labels.

   TOK : (KT, KL, Kpt, KN_Kpt, LT_Kpt)

      TOK (Key Token) carries the key to be distributed to the third-
      party (Kpt).  LT_Kpt is the key lifetime for a Kpt.

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 are 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 Key Derivation
   Function (KDF) used to generate the keys includes context and scope
   information that binds the key to the specific channel [RFC5295].





Ohba (Editor)            Expires April 22, 2009                 [Page 7]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


4.2.  Key distribution exchange scenarios

   There are three scenarios for distribution of EMSK child keys third-
   parties.  We assume that the peer and the EAP server have mutually
   authenticated to each other using an EAP method and have generated an
   EMSK.  For all scenarios, the trigger and mechanism for key delivery
   may involve a specific request from the peer and another intermediary
   (such as authenticator).  For simplicity, we assume that USR-KHs
   reside in the same domain as the EAP server.

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

   Scenario 2: EAP server to DSR-KH:  In this scenario, an 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 the 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 4.  KDE-Request and KDE-Response are
   messages for Scenarios 2.  KDE-Request' and KDE-Response' are
   messages for Scenarios 3.

   DSUSR-KH                   DSR-KH                    EAP Server
   --------                  -------                      -----
      |  KDE-Request'(TRT')     |   KDE-Request(TRT)        |
      |------------------------>|-------------------------->|
      |  KDE-Response'(TOK')    |   KDE-Response(TOK)       |
      |<----------------------- |<--------------------------|
      |                         |                           |


                    Figure 4: Combined Message Exchange


5.  RADIUS KDE Attribute

   A RADIUS Key Distribution Exchange (KDE) attribute has the following
   format.  See Section 7 for security requirements on transporting this
   RADIUS attribute.








Ohba (Editor)            Expires April 22, 2009                 [Page 8]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


    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.

   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_Kpt. The first octet contains the length
      of the rest of this field in octets.  This field is contained if



Ohba (Editor)            Expires April 22, 2009                 [Page 9]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


      and only if K-flag is set.

   Key

      A field to contain a Kpt. 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_Kpt. This field is
      contained if and only if K-flag is set.

   A KDE-Request, i.e., an RADIUS Access-Request message carrying a KDE
   attribute with K-flag cleared, is transmitted by the third-party in
   one of the following cases.  One case is for explicit ERP
   bootstrapping [RFC5296] in which an EAP-Initiate and EAP-Finish
   exchange is performed between the peer and the home AAA server, with
   the bootstrapping flag in the EAP-Initiate message set.  In this
   case, the third-party that requests a Kpt MUST include a KDE
   attribute with K-bit cleared in a RADIUS Access-Request message that
   carries an EAP-Initiate message with the bootstrapping flag turned on
   [RFC5296].  Another case is implicit ERP bootstrapping [RFC5296] in
   which Kpt key distribution occurs during initial EAP authentication.
   In this case, the third-party that requests a Kpt MUST include a KDE
   attribute with K-flag cleared in the RADIUS Access-Request message
   that carries the first EAP-Response message from the peer.  In both
   cases, a value of the RADIUS User-Name attribute is used as the PID.

   A KDE-Response, i.e., an RADIUS Access-Accept message carrying a KDE
   attribute with K-flag set, is transmitted by a server in one of the
   following ways.  In the case of explicit ERP bootstrapping, the
   server MUST include a KDE attribute with K-flag set in a RADIUS
   Access-Accept message that carries an EAP-Finish message [RFC5296]
   for which the bootstrapping flag is set.  In the case of implicit ERP
   bootstrapping, the server that received a valid KDE-Request includes
   a KDE attribute with K-flag set in a RADIUS Access-Accept message
   that carries an EAP-Success.


6.  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:







Ohba (Editor)            Expires April 22, 2009                [Page 10]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


   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


7.  Security Considerations

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

7.1.  Requirements on RADIUS Key Transport

   RADIUS messages that carry a KDE attribute MUST be encrypted and
   integrity 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 third-party and the server, 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
   intermediary is trusted not to use the distributed key material.

7.2.  Distributing Kpt 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 Kpt 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 Kpt is not provided.  As a result, it is possible
   for a third-party to request a Kpt from the server and obtain the Kpt
   even if a peer actually does not support ERP, which can lead to an
   unintended use of a Kpt.





Ohba (Editor)            Expires April 22, 2009                [Page 11]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


8.  IANA consideration

   This document defines a new namespace for maintaining Key Type used
   to identify the type of Kpt. 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 defined in
   Section 5.


9.  Acknowledgements

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


10.  Contributors

   The following people contributed to this document.

        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)


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.

   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
              RFC 2548, March 1999.

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




Ohba (Editor)            Expires April 22, 2009                [Page 12]


Internet-Draft       HOKEY Key Distribution Exchange        October 2008


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

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

11.2.  Informative references

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              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-01 (work in progress),
              August 2008.


Author's Address

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

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




Ohba (Editor)            Expires April 22, 2009                [Page 13]


Internet-Draft       HOKEY Key Distribution Exchange        October 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.











Ohba (Editor)            Expires April 22, 2009                [Page 14]


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