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

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

Network Working Group                                   M. Nakhjiri, Ed.
Internet-Draft                                                Huawei USA
Expires: December 24, 2007                                  Y. Ohba, Ed.
                                                                 Toshiba
                                                           June 22, 2007


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

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 December 24, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes a delivery framework for usage and/ or domain
   specific keys, derived as part of an EAP EMSK hierarchy, and
   delivered from an EAP server to an intended third party key holder.
   The framework description includes different scenarios for key
   delivery, depending on the type of keys being delivered.  It also
   includes, specification of derivation of keys required for security



Nakhjiri & Ohba         Expires December 24, 2007               [Page 1]


Internet-Draft               Hokey hierarchy                   June 2007


   protection of key requests and delivery signaling.  The key delivery
   framework also includes proper specification and conveyance of the
   context and scope of the keys being delivered.  Derivation of the
   EMSK based handover root key (HRK) and domain specific handover root
   keys (DSHRK) for use in the problem of handover keying and re-
   authentication is also described.


Table of Contents

   1.  Introduction and Problem statement . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  EMSK key delivery architecture . . . . . . . . . . . . . . . .  6
   4.  Distribution of EAP based keys to a third party  . . . . . . . 10
     4.1.  Overview of the 3 party key distribution exchange (KDE)  . 11
     4.2.  3 party key exchange scenarios . . . . . . . . . . . . . . 13
     4.3.  Derivation of keys protecting the KDE  . . . . . . . . . . 14
       4.3.1.  keys protecting the KDE within a domain  . . . . . . . 16
     4.4.  Specification of context and scope for distributed keys  . 17
   5.  key derivation and delivery scenarios  . . . . . . . . . . . . 17
     5.1.  Derivation and delivery of Handover Root Key . . . . . . . 17
       5.1.1.  Delivery of HRK to HOKEY server  . . . . . . . . . . . 18
     5.2.  Derivation and delivery of Domain Specific Root keys . . . 20
       5.2.1.  Delivery of DSRK to domain server  . . . . . . . . . . 20
     5.3.  Domain Specific Handover Root key  . . . . . . . . . . . . 22
     5.4.  key delivery within a domain . . . . . . . . . . . . . . . 22
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   7.  IANA consideration . . . . . . . . . . . . . . . . . . . . . . 24
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 25
   Appendix A.  Appendix A: Roaming hieararchy based on HRK . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 28
















Nakhjiri & Ohba         Expires December 24, 2007               [Page 2]


Internet-Draft               Hokey hierarchy                   June 2007


1.  Introduction and Problem statement

   The ability of Extensible Authentication Protocol (EAP) framework
   ([RFC3748] ) in incorporating desired authentication methods and
   generating master session keys [I-D.ietf-eap-keying]) has led to the
   idea of using EAP authentication and the resulting key material for
   bootstrap further keys for a variety of security mechanisms.  Out of
   two master session keys, generated from EAP, the MSK is used heavily
   for bootstrapping the security associations for the wireless link
   between the peer and the network.  However, the combination of the
   heavy deployment of these solution and their issues around mobility
   performance and agility ([I-D.nakhjiri-aaa-hokey-ps],
   [I-D.ohba-hokey-3party-keydist-ps] and [I-D.ietf-hokey-reauth-ps])
   had led the IETF HOKEY to consider use of the extended master session
   key (EMSK) for providing future security bootstrapping problems, such
   as handover keying, re-authentications and IP mobility provisioning
   signaling.

   Currently, specifications on use of EAP EMSK for generating further
   keys in still work under progress.  A general guideline document
   ([I-D.ietf-hokey-emsk-hierarchy]) describes how one can use EMSK to
   generate the following child keys:

   USRK:  Usage Specific Root key.  A root key generated from EMSK and
      is used for a specific usage that is authorized for a peer,
      following an EAP authentication.  USRK is domain independent.

   DSRK:  Domain Specific Root key.  A root key generated from EMSK and
      is used within a specific domain that peer is authorized to
      receive services from or roam into, following an EAP
      authentication.  DSRK is usage independent.

   DSUSRK:  Domain Specific Usage Specific Root key.  A root key
      generated from EMSK and is used for a specific usage within a
      specific domain that peer is authorized to receive services from,
      following an EAP authentication.  DSUSRK is both usage and domain
      dependent.




                          EMSK
          ________________|_____________________________
          |        |            |      |        |       |
          DSRK1 .. DSRKn      USRK1..USRKm  DSUSRK1 DSUSRKj


             Figure 1: Different categories of EMSK Child keys



Nakhjiri & Ohba         Expires December 24, 2007               [Page 3]


Internet-Draft               Hokey hierarchy                   June 2007


   [I-D.ietf-hokey-emsk-hierarchy] also describes how the knowledge
   related to a specific usage or an administrative domain can be used
   as standardized format input data into a cryptographic function to
   generate USRKs, DSRK and DSUSRKs.  The guidelines assure that
   different child keys generated from the EMSK are cryptographically
   separate from each other, so that compromise any EMSK child key does
   not lead to compromise of the parent EMSK or the sibling child keys.
   It should be noted that a USRK can be used to generate domain
   specific keys for that specific usage (DSUSRK), while on the other
   hand, a DSRK may have been authorized to a specific domain for a set
   of allowed services.  So it is also possible to create DSUSRKs for
   those services at that domain.  Thus coordination is necessary
   between the home and visited domain on which DSUSRKs are generated
   from USRK at home, which DSUSRKs can be generated from DSRK at
   visited domain and which DSUSRKs can be generated directly as EMSK
   child keys at the EAP server.

   Since EAP authentication is a 2 party protocol, additional measures
   should be taken to properly utilize the EAP generated keys in a 3
   party key management arrangement.  While USRK, DSRK and DSUSRK are
   typically stored and utilized at third party key holders (e.g.  AAA
   servers/ entities) logically or physically separate from the EAP
   server or peer, the security restrictions ([I-D.ietf-eap-keying])
   forbid against transport of EMSK outside the EAP server/ layer.  On
   the other hand, EAP authentication and EMSK generation process is
   oblivious to the future service requests and authorizations.  This
   will imply that the input data required for creation of the USRK,
   DSRK or DSUSRK needs to be delivered to the EAP server, performing
   the derivation function, followed by a secure delivery of the
   resulting keys to these third party key holders.  It is the purpose
   of this document to show how such input data can be delivered to the
   EAP server, and how the generated key material is delivered to the
   third party key holder in a secure manner, while considering the
   security requirements and principles defined in
   [I-D.housley-aaa-key-mgmt] and [I-D.ohba-hokey-3party-keydist-ps]
   into account.  Thus, the specification includes derivation of key
   material required for secure key delivery and channel binding
   procedures to ensure that not only the keys are not exposed to
   unintended parties during delivery, but also the scope and usage
   context for the key is properly understood and agreed upon by the
   initial parties.

   To provide a complete solution for the problem of handover keying and
   re-authentication, the key hierarchy specified in this document
   includes specification of use of EMSK in derivation of top level
   handover root keys (HRK), domain specific root keys (DSRK) and the
   DSUSRK specifically for handover, called domain specific handover
   root key (DSHRK), according to [I-D.ietf-hokey-emsk-hierarchy] and



Nakhjiri & Ohba         Expires December 24, 2007               [Page 4]


Internet-Draft               Hokey hierarchy                   June 2007


   the delivery of these keys to the intended third parties.

   The purpose of this document is not to provide exact syntax for the
   signaling, only the general semantics for the parameters involved are
   defined.  The exact syntax for these parameters when carried by
   specific protocols, such as AAA protocols or EAP protocols are out of
   scope of this document.


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

   DSRK:  Domain Specific Root key.  A root key generated from EMSK and
      is used within a specific domain that peer is authorized to
      receive services from or roam into, following an EAP
      authentication.  DSRK is usage independent.

   DSRK holder (DSR-KH):  The DSR-KH is responsible for receiving,
      holding and protection of the DSRK derived directly from EMSK.
      The DSR-KH is possibly responsible for derivation and distribution
      of any child keys derived from DSRK for that specific domain.  The
      most likely realization of DSR-KH is a AAA server in the
      corresponding domain, responsible for setting the policies for
      usage of DSRK within the domain.

   DSUSRK:  Domain Specific Usage Specific Root key.  A root key
      generated from EMSK and is used for a specific usage within a
      specific domain that peer is authorized to receive services from,
      following an EAP authentication.  DSUSRK is both usage and domain
      dependent.

   DSUSRK holder (DSUSR-KH):  The DSUSR-KH is responsible for receiving,
      holding and protection of the DSUSRK derived directly from EMSK.
      The DSUSR-KH is possibly responsible for derivation and
      distribution of any child keys derived from DSUSRK for that
      specific domain and usage.  The most likely realization of
      DSUSR-KH is a AAA server in the corresponding domain, responsible
      for the service offered within the domain for the specific usage
      at hand.

   HOKEY server:  This is essentially a usage specific server, that
      deals with handover and re-authentication as specific usage
      (USR-KH for HOKEY).  For the purpose of this document, a HOKEY
      server is domain independent and interacts directly with EAP
      server to receive HRK from EAP server.  This top level HOKEY



Nakhjiri & Ohba         Expires December 24, 2007               [Page 5]


Internet-Draft               Hokey hierarchy                   June 2007


      server can generate and deliver domain specific HRKs (DSHRK) to
      domain HOKEY servers.

   domain HOKEY server:  This is a server handling HOKEY service and
      holding the domain specific HRK (DSHRK) for a specific domain.
      For practical purposes, this can be a domain AAA server handling
      HOKEY service.  When DSHRK is generated from HRK, domain HOKEY
      server deals with top level HOKEY server.  When DSHRK is generated
      directly from EMSK, the domain HOKEY server deals directly with
      EAP server.

   HRK:  Handover root key is a key that will be used as the root key to
      solve the handover keying and re-authentication problem.  The HRK
      is considered a usage specific root key (USRK) (defined in
      [I-D.ietf-hokey-emsk-hierarchy]) and is derived directly from
      EMSK.  HRK is a domain independent specific root key for re-
      authentication and handover, meaning that it can be used to create
      domain-specific HRK for various domains (DSHRK).  HRK is generated
      using a Pseudo random function (PRF) that complies with
      requirements and guidance in [I-D.ietf-hokey-emsk-hierarchy].  For
      simplicity we refer to this PRF as USRK_PRF.

   DSHRK:  Domain specific handover root key: A key that can only be
      used for HOKEY service within a specific domain.

   IK and CK:  Integrity and cipher keys, used to protect the key
      delivery signaling between the peer and the EAP server.  These two
      keys are some times referred to as key delivery keys.

   USRK:  Usage Specific Root key.  A root key generated from EMSK and
      is used for a specific usage that is authorized for a peer,
      following an EAP authentication.  USRK is domain independent.

   USRK holder (USR-KH):  The USR-KH is responsible for receiving,
      holding and protection of the USRK derived directly from EMSK.
      The USR-KH is possibly responsible for derivation and distribution
      of any child keys derived from USRK for that specific usage.


3.  EMSK key delivery architecture

   As mentioned earlier, EMSK can be used to generate any of the USRKs,
   DSRK and DSUSRKs.  It should however be noted that a USRK can be used
   to generate domain specific keys for that specific usage (DSUSRK),
   while on the other hand, a DSRK may have been authorized to a
   specific domain for a set of allowed services.  So it is also
   possible to create DSUSRKs for those services at that domain.  While
   the end result, a DSUSRK, is the same, the way to arrive at and



Nakhjiri & Ohba         Expires December 24, 2007               [Page 6]


Internet-Draft               Hokey hierarchy                   June 2007


   deliver the DSUSRK to the proper destination is important: First,
   coordination is necessary between the home and visited domain on
   which DSUSRKs are generated from USRK at home, which DSUSRKs can be
   generated from DSRK at visited domain and which DSUSRKs can be
   generated directly as EMSK child keys.  Second, the destination to
   which the key is delivered is dictated by the type of key being
   generated.  This is important, since the EAP keying framework
   ([I-D.ietf-eap-keying]) forbids against transport of EMSK outside the
   EAP server/ layer to ensure the security of EMSK.  On the other hand,
   the EAP server is not expected to be involved in any service
   authorization decisions.  To keep the generality of the specification
   of the key delivery mechanism, we introduce the notion of key
   holders:

   USRK holder (USR-KH):  For the purpose of the key delivery mechanism
      specified in this document, this is an entity acting as a
      recipient of the usage specific root key (USRK) derived from the
      EMSK and delivered from the EAP server.  Also, for the purpose of
      the key delivery mechanism, the USR-KH has a interface with the
      EAP server and is responsible for delivering the usage specific
      input data required for derivation of USRK from EMSK to the EAP
      server.  Thus USR-KH is responsible for receiving, holding and
      protection of the USRK derived directly from EMSK.  The USR-KH is
      possibly responsible for derivation and distribution of any child
      keys derived from USRK for that specific usage.

   DSRK holder (DSR-KH):  For the purpose of the key delivery mechanism
      specified in this document, this is an entity acting as a
      recipient of the domain specific root key (DSRK) derived from the
      EMSK and delivered from the EAP server.  Also, for the purpose of
      the key delivery mechanism, the DSR-KH has a interface with the
      EAP server and is responsible for delivering the domain specific
      input data required for derivation of DSRK from EMSK to the EAP
      server.  Thus DSR-KH is responsible for receiving, holding and
      protection of the DSRK derived directly from EMSK.  The DSR-KH is
      possibly responsible for derivation and distribution of any child
      keys derived from DSRK for that specific domain.  The most likely
      realization of DSR-KH is a AAA server in the corresponding domain,
      responsible for setting the policies for usage of DSRK within the
      domain.

   DSUSRK holder (DSUSR-KH):  For the purpose of the key delivery
      mechanism specified in this document, this is an entity acting as
      a recipient of the domain specific and usage specific root key
      (DSUSRK) derived from the EMSK and delivered from the EAP server.
      Also, for the purpose of the key delivery mechanism, the DSUSR-KH
      has a interface with the EAP server and is responsible for
      delivering the domain and usage specific input data required for



Nakhjiri & Ohba         Expires December 24, 2007               [Page 7]


Internet-Draft               Hokey hierarchy                   June 2007


      derivation of USRK from EMSK to the EAP server.  Thus DSUSR-KH is
      responsible for receiving, holding and protection of the DSUSRK
      derived directly from EMSK.  The DSUSR-KH is possibly responsible
      for derivation and distribution of any child keys derived from
      DSUSRK for that specific domain and usage.  The most likely
      realization of DSUSR-KH is a AAA server in the corresponding
      domain, responsible for the service offered within the domain for
      the specific usage at hand.

   In a general case, we can assume that the EAP server at the time of
   authentication is unaware of any future service authorization
   requests from the peer.  Thus, the EAP server caches EMSK and creates
   each of the EMSK child keys based on request, using its cache of
   EMSK.  Thus, the key holder needs to provide the EAP server with
   proper input data before receiving the requested key.  For instance a
   visited domain HOKEY server, needs to authorize the peer for handover
   keying and re-authentication service, and then request a handover
   root key for its domain (visited domain HRK, VHRK) from the EAP
   server.  A home domain may also operate a home HOKEY server that uses
   a home handover root key (HHRK) to serve the peer's re-authentication
   and handover keying needs within home domain.  The following figure
   shows the assumed logical architecture for each type of EMSK child
   key being created and delivered:




























Nakhjiri & Ohba         Expires December 24, 2007               [Page 8]


Internet-Draft               Hokey hierarchy                   June 2007


                  +-+-+-+-+-+-+
                   | EAP server|
                   +-+-+-+-+-+-+
          USRK1  /           \ USRK2
          (HRK) /             \  (XYZ)
          +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+
          |   USR-KH1     |   |   USR-KH2 |
          | HOKEY server  |   | XYZ server|
          +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+

                      +-+-+-+-+-+-+
                      |   peer    |
                      +-+-+-+-+-+-+
                         (A)


                     +-+-+-+-+-+-+
                     | EAP server|
                     +-+-+-+-+-+-+
          DSUSRK1  /           \ DSUSRK2
           (HHRK) /             \  (VHRK)
          +-+-+-+-+-+-+-+         +-+-+-+-+-+-+
          | Domain 1    |        | Domain 2      |
          | DSUSR-KH    |        | DSUSR-KH      |
          |(home domain |        |(visited domain|
          |HOKEY server)|        |HOKEY server)  |
          +-+-+-+-+-+-+-+        +-+-+-+-+-+-+-+-+

                      +-+-+-+-+-+-+
                      |   peer    |
                      +-+-+-+-+-+-+
                       (B)



                      +-+-+-+-+-+-+-+-+-+
                      | EAP server      |
                      +-+-+-+-+-+-+-+-+-+
                      /  DSRK1            \ DSRK2
                    /                       \
                +-+-+-+-+-+-+         +-+-+-+-+-+-+-+
                |   DSR-KH1 |         | DSR-KH2     |
                +-+-+-+-+-+-+         +-+-+-+-+-+-+-+

                      +-+-+-+-+-+-+
                      |   peer    |
                      +-+-+-+-+-+-+
                           (C)



Nakhjiri & Ohba         Expires December 24, 2007               [Page 9]


Internet-Draft               Hokey hierarchy                   June 2007


        Figure 2: Key delivery for various EMSK child key cateories

   As one can see, depending on the type of key being delivered,
   different third party key holders are involved.  The general
   mechanism for delivering a key to 3rd party is described in the
   following section.


4.  Distribution of EAP based keys to a third party

   EAP authentication method signaling and the following EMSK generation
   is performed between the peer and the EAP server in a manner that is
   almost transparent to all intermediaries.  However, providing a
   keying service, such as the handover keying and re-authentication
   services, involves a set of key management services, including
   creation of a key hierarchy and installation of specific keys at one
   or more of such third party intermediaries (figure 2).  Requirements
   for such AAA/ EAP based key management procedures are stated in
   several documents ([I-D.housley-aaa-key-mgmt],
   [I-D.ietf-hokey-reauth-ps], [I-D.ohba-hokey-3party-keydist-ps] ).
   Requirements such as well-defined key scope and authentication of all
   parties are addressed by the following 3 party key distribution
   mechanism, which allows distribution of a key, initially only known
   to two parties (typically directly and mutually authenticated), to a
   well-identified third party.

   As seen above handover keying and re-authentication service requires
   distribution of keys a variety of intermediaries.  In the following
   we describe the mechanism for a 3 party key distribution exchange
   (KDE), where a key is distributed from a network server (with parent
   key holder) to a generic third party.  The following shows a generic
   trust model for the 3 party key distribution mechanism.  The peer (P)
   and a parent key holder, called "server" (S) in this model share a
   parent key from the key hierarchy.  From this parent key, a key (Kpt)
   is to be generated and distributed to a third party intermediary (T).
   We keep the generation of Kpt out of the general description of the
   KDE (key distribution exchange) as the goal is show the process for
   distribution of Kpt from S to T. To support the key distribution
   mechanism, we assume that the peer and the server share a set of
   security associations, including keys for integrity and privacy
   protection of the signaling between the peer and the server (KIps and
   KCps for integrity and privacy protection).  We also assume that the
   server (S) and the third party (T) share a similar set security
   association (KIts, KCts).







Nakhjiri & Ohba         Expires December 24, 2007              [Page 10]


Internet-Draft               Hokey hierarchy                   June 2007


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

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

4.1.  Overview of the 3 party key distribution exchange (KDE)

   The key distribution mechanism described below is a modified version
   of the Otway-Rees protocol that meets the requirements for such
   3-party lay-out.  The description below can be carried over a generic
   transport and thus is independent of the exact type of protocol that
   is used.  However for the purpose of this document the assumption is
   that the 3 party mechanism parameters are carried for EAP messages
   that are themselves encapsulated over a lower layer such as a AAA
   protocol or an access protocol.

   The exchange proposed below is to perform a channel binding and avoid
   the lying intermediary scenario, where the intermediary announces a
   down link ID to the peer (DTID) and a different uplink ID to the
   server (UTID).  The peer uses DTID in its token towards the server,
   while the intermediary uses its UTID in its token to the server.
   Server must use the UTID from peer token to calculate the MIC in the
   third party token ([PID, UTID]KIts) and if there is a match, then the
   server can verify that DTID and UTID are the same as the TID and
   proceed with generating and provisioning of Kpt, otherwise the server
   MUST return a failure code instead of generating an Kpt.

   The 3 party key distribution basically consists of 1 exchange, i.e. 2
   messages between the peer and the server.  However, in most scenarios
   each message traverses through the intermediary, i.e.  Over two
   logical hops (peer-third party) and (third party-server) even though
   the exchange seems to consist of 4 logical messages.  It should be
   noted that the information in message 0 is typically conveyed as an
   advertisement through other means.

   0  Third party to peer: (DTID, DID)






Nakhjiri & Ohba         Expires December 24, 2007              [Page 11]


Internet-Draft               Hokey hierarchy                   June 2007


   1  Peer to Third party: Int[ KIps, (PID, DTID, DID, Np,KN_KIps)]

   2  Third party to Server: Int[KIts, (PID, UTID)], Int[ KIps, (PID,
      DTID, DID, Np,KN_KIps)]

   3  Server to third party: {PID,TID,KN_Kpt, KL_Kpt, Kpt}KCts, Int[
      KIps, (PID, TID, DID, Np+1,KN_Kpt,KL_Kpt, KN_KIps)]

   4  Third party to Peer: Int[KIps, (PID, TID, DID, Np+1,
      KN_Kpt,KL_Kpt, KNps)]

   the notation is as follows:

   PID: peer ID.  The information is expected by carried by an existing
   attribute within EAP and/or AAA protocols.

   DID: Domain ID, used for generation of domain specific keys, such as
   HHRK (see key generation).

   TID: third party ID (obtained by the peer through beacon
   announcements or other means)

   DTID: third party ID as perceived by the peer (down link ID)

   UTID: third party ID as perceived by the server (uplink ID)

   {X}K: X encrypted with key K

   Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X
   with key K.

   KIps: A symmetric key shared between peer and Server for signing and
   identified by KN_KIps.

   KCps: A symmetric key shared between peer and Server for encryption
   and identified by KN_KCps

   KCts: A symmetric key shared between third party and Server for
   encryption (provisioned out of band).

   KIts: A symmetric key between third party and server for signing
   (provisioned out of band).

   Kpt: A symmetric key to be shared between peer and third party (key
   to be distributed to third party).  The key is named as KN_Kpt.

   KL_Kx : Key lifetime for key x




Nakhjiri & Ohba         Expires December 24, 2007              [Page 12]


Internet-Draft               Hokey hierarchy                   June 2007


   KN_Kx: Key name for Key x, e.g.  KN_KIas: key name for KIas

   Nx : Nonce provided by the party X

   Int[ KIps, (PID, DTID, DID, Np,KN_KIps)] is called the peer request
   token (PRT), which carries the identities of both peer and the third
   party along with a signature.  The signature is called the peer
   request authenticator (PRA).

   Int[KIts, (PID, UTID)] is called thirdparty_ID_token (TIT), which
   carries a signature, called third party ID authenticator.

   {PID,TID,KN_Kpt, KL_Kpt, Kpt}KCts is called key_token (KT), which
   carries the Kpt wrapped with KCts (encryption key shared between the
   third party and server).

   Int[ KIps, (PID, TID, DID, Np+1,KN_Kpt,KL_Kpt, KN_KIps)] is called
   Server_authorization_token (SAT).

4.2.  3 party key exchange scenarios

   The following scenarios can be envisioned for distribution of a key
   to a 3rd party.  All scenarios assume the peer and the EAP server
   have mutually authenticated to each other using an EAP method and
   have generated an EMSK.

   EAP server to USR-KH:  The service requested by the peer (e.g.
      Handover keying and re-authentication keying service) is provided
      by the a server that also authorizes that service.  This server is
      a AAA-style server other than the EAP server (e.g. a HOKEY
      server), since EAP server is typically only in charge of EAP
      authentication and MSK/EMSK generation.  For the purpose of this
      document, we assume that this server is the USR-KH for that
      service (usage).  Following the authorization of the service
      (usage) a request is placed with the EAP server and the USRK is
      generated and delivered to USR-KH.  The USR-KH is domain
      independent and the USR-KH can use USRK to generate DSUSRK for
      other domain.  It is possible that this USR-KH server is not
      physically disjunct from the EAP server and thus is identified
      with the same identity as the EAP server.  In such cases, the
      existence of USR-KH server is to off-load the EAP server from the
      need to handle usage specific services, such as HOKEY service, for
      multiple domains.  Security Requirements for delivery of USRK from
      EAP server to a collocated USR-KH is currently TBD.  However, to
      keep the specifications generic here, we assume that USR-KH and
      EAP server are physically separate and specify the delivery of
      USRK from EAP server to USR-KH according to the KDE.  The specific
      use case considered in this document is HOKEY service: The USR-KH



Nakhjiri & Ohba         Expires December 24, 2007              [Page 13]


Internet-Draft               Hokey hierarchy                   June 2007


      is a HOKEY service and USRK is HRK.  The EAP server delivers the
      HRK to the USR-KH (HOKEY server).  The details of this procedure
      is discussed later in this document.  The trigger and mechanism
      for key delivery may involve a specific request from the peer and
      another intermediary (such as authenticator) for HOKEY service.



   EAP server to DSR-KH  In this scenario, a domain server, typically a
      domain AAA server requires delivery of a DSRK for all allowed
      usage within the domain.  DSR-KH are EAP server are physically
      disjunct.  Thus deployment of 3 party key distribution exchange is
      required.

   USR-KH to DSUSR-KH:  This stage assumes that both peer and USR-KH
      server possess USRK, and further operation between peer and the
      domain that the peer intends to attach to, depends on delivery of
      a domain specific USRK (DSUSRK) to the DSUSR-KH.  It is best to
      assume that the USR-KH and DSUSR-KH HOKEY are physically separate
      and thus deployment of the 3 party KDE is required for the
      delivery of DSUSRK.

   domain specific key management operations:  Domain specific scenarios
      can involve delivery of keys that are at lower levels of the key
      hierarchy, for instance keys that are children of USRK, DSRK or
      DSUSRK and not children of EMSK.  Such key generation and
      management scenarios do not involve EAP server, but still can and
      need to use a 3 party key distribution exchange mechanism to
      ensure secure delivery of the key to a third party.  An example is
      delivery of per-authenticator keys from domain HOKEY server to an
      authenticator.

4.3.  Derivation of keys protecting the KDE

   As shown in the generic description of the key distribution exchange,
   to protect the exchange, at least one (or two) keys are required to
   protect the exchange.  These keys are an integrity and a cipher key.
   These keys are generated from the EMSK hierarchy themselves.
   However, as discussed when enumerating the various KDE use case
   scenarios, the KDE can and need to be used in many different
   scenarios for delivering keys.  Depending on the key that is being
   delivered, the integrity and cipher keys can be generated at
   different levels of the key hierarchy as well.  For instance to
   protect the KDE performed to deliver an EMSK child key (USRK, DSRK,
   or DSUSRK), these two keys are generated directly from EMSK.






Nakhjiri & Ohba         Expires December 24, 2007              [Page 14]


Internet-Draft               Hokey hierarchy                   June 2007


                             EMSK
              ________________|________________
              |        |      |      |        |
              DSRK    USRK    DSUSRK  CK       IK


              Figure 4: Key delivery keys as EMSK Child keys

   Cipher key (CK) and Integrity Key (IK) are generated from EMSK as
   domain independent USRKs.  CK and IK are used to protect KDE for
   delivery of USRK, DSRK and those DSUSRKs that are generated from EMSK
   directly.

   We refer to PRF used to generate the USRKs, USRK-PRF, and assume that
   it can generate Z bits of output.

   In order to be able to perform the key delivery exchange,

   IK | IK_name_key=USRK-PRF (EMSK, "Integrity Key" | NULL | peer_ID |
   Key_length )

   IK_name=First(128, HMAC_SHA256(IK_name_key "Integrity Key"| NULL|
   peer_ID)

   CK | CK_name_key=USRK-PRF (EMSK, "Cipher Key" | NULL | peer_ID |
   Key_length )

   CK_name=First(128, HMAC_SHA256(CK_name_key, "Cipher Key" | NULL |
   peer_ID)

   Where, First (N, X) refers to the first N bits of X and it is assumed
   that USRK_PRF generates Z=X+Y bits, where the first X bits are used
   for key itself, while the remaining Y bits are used for key_name_key,
   which is used to create temporal uniqueness in the key name
   generation.  Choice of Z and X are outside scope of this document.

   The "Usage_label" value is to be assigned by IANA to the strings
   "Integrity Key" and "Cipher Key".

   NULL as domain label, since the IK and CK are considered to be a
   usage specific, but domain independent keys.  Thus domain label is
   wild carded.

   Peer_ID is the identifier for the peer.  This identifier is exchanged
   in the key distribution exchange (KDE) as described shortly.

   It is assumed the parties involved in the key distribution exchange
   will need to be able to have access (or derive??) to the CK and IK to



Nakhjiri & Ohba         Expires December 24, 2007              [Page 15]


Internet-Draft               Hokey hierarchy                   June 2007


   protect the key delivery signaling.

4.3.1.  keys protecting the KDE within a domain

   The following provides an example of derivation of integrity and
   cipher keys for distributions of service related keys within a
   domain.  We assume that the keys to be delivered (KX or KY) are
   derived from a DSUSRK for that domain and specific usage.  We call
   the cipher key and integrity key for delivering a domain and usage
   specific child of DSUSRK, the DUCK and DUIK, respectively.

                   DSUSRK
                ______|________________
                |      |      |        |
               KX    KY    DUCK       DUIK


        Figure 5: Keys for delivery of service keys within a domain

   DUIK | DUIK_name_key=PRF (DSUSRK, "domain usage Integrity Key" |
   Domain Label | peer_ID | Key_length )

   DUIK_name=First(128, HMAC_SHA256(DUIK_name_key "domain usage
   Integrity Key"| Domain Label | peer_ID)

   DUCK | DUCK_name_key=PRF (DSUSRK, "domain usage Cipher Key" | Domain
   Label | peer_ID | Key_length )

   DUCK_name=First(128, HMAC_SHA256(DUCK_name_key, " domain usage Cipher
   Key" | Domain Label | peer_ID)

   KX and KY above are both keys related to a specific service as
   defined in generation of DSUSRK.

   It is also possible to use the same keys to protect delivery of keys
   for all services within a domain, as long as service independent root
   keys (DSRK) are available.  In that case, the key delivery keys
   (integrity and cipher keys for KDE protection) are derived from a
   DSRK, so that the same keys can be used to protect KDE for delivery
   of keys for any type of key derived from DSRK.

                  DSRK
                ______|________________
                |      |      |        |
                KX    KY    DCK       DIK


            Figure 6: Keys for delivery of keys within a domain



Nakhjiri & Ohba         Expires December 24, 2007              [Page 16]


Internet-Draft               Hokey hierarchy                   June 2007


   DIK | DIK_name_key=PRF (DSRK, "domain Integrity Key" | Domain Label |
   peer_ID | Key_length )

   DIK_name=First(128, HMAC_SHA256(DIK_name_key "domain Integrity Key"|
   Domain Label | peer_ID)

   DCK | DCK_name_key=PRF (DSRK, "domain Cipher Key" | Domain Label |
   peer_ID | Key_length )

   DCK_name=First(128, HMAC_SHA256(DCK_name_key, " domain Cipher Key" |
   Domain Label | peer_ID)

4.4.  Specification of context and scope for distributed keys

   To be completed.


5.  key derivation and delivery scenarios

5.1.  Derivation and delivery of Handover Root Key

   Depending on the deployment and trust models, several key hierarchy
   models can be considered for solving the handover and re-
   authentication problem, based on the category of the EMSK child key
   categories used.  In this section we will discuss derivation and
   delivery of handover root key (HRK) as a top level root key for
   handover keying and re-authentication usage.  This will not only
   serve as an example for derivation and delivery of a USRK, but also
   provide enough specification to support other handover keying and re-
   authentication specifications.  HRK is considered as USRK.  The
   USR-KH to cache and maintain HRK is called HOKEY server.  Since the
   top level HRK is domain independent, a domain independent HOKEY
   server can hold HRK and can act authorization server for service to
   multiple domains, delivering domain specific HRK (DSHRK) to each
   domain as needed.  Domain dependent HOKEY servers are deployed in
   each domain to be only responsible for receiving DSHRK and
   authorization and delivery of handover keying and re-authentication
   services within that domain.

   In this section we only discuss delivery of HRK to top level HOKEY
   server, leaving delivery of DSHRKs for later.

   subscribing to the model of USRK for HRK derivation and delivery, the
   following portions of the EMSK hierarchy are considered in this
   section.  As mentioned in [I-D.ietf-hokey-emsk-hierarchy] the USRK-
   PRF used below can be negotiated, pre-configured based on network
   policy.  We assume that it can generate Z=X+Y bits of output, where
   the first X bits are used for HRK, while the remaining Y bits are



Nakhjiri & Ohba         Expires December 24, 2007              [Page 17]


Internet-Draft               Hokey hierarchy                   June 2007


   used for HRK_name_key, which is used to create temporal uniqueness in
   the key name generation.

                    EMSK
            ________|_____________
            |        |            |
            HRK      CK           IK


           Figure 7: Using EMSK for HRK derivation and delivery

   HRK | HRK_name_Key=USRK-PRF (EMSK, Usage_label | NULL | Peer_ID |
   Key_length)

   HRK_name=First (128, HMAC_SHA256(HRK_name_Key, "Usage_label | NULL |
   peer_ID))

   The "Usage_label" value is to be assigned by IANA to the string
   "Handover Root Key".

   NULL as domain label, since the HRK is considered to be a usage
   specific (for handover keying and re-authentication) but domain
   independent root key.  Thus domain label is wild carded.  This way
   the same HRK can be used to create root keys for all visited and home
   domains.

   Peer_ID is the identifier for the peer as known to the server
   generating HRK.  This identifier is exchanged in the key distribution
   exchange (KDE) as described shortly.

   The HRK is stored at this HOKEY server database.  We can call this
   database the HRK key holder (HRK-KH).

   HOKEY server can for instance generate a home HRK (HHRK) for the home
   HOKEY server or AAA server and a visited HRK (VHRK) for the visited
   HOKEY server or AAA server.

5.1.1.  Delivery of HRK to HOKEY server

   The HOKEY server is a USR-KH, which is considered a third party to
   the initial EAP parties (peer and EAP server).  The key distribution
   exchange (KDE) can be used to the deliver the HRK from EAP server to
   the domain independent HOKEY server, using the CK and IK derived from
   EMSK (described in earlier section).  Since HRK is domain
   independent, domain information is omitted from exchanged tokens.






Nakhjiri & Ohba         Expires December 24, 2007              [Page 18]


Internet-Draft               Hokey hierarchy                   June 2007


   0  HOKEY server to peer: (DHID)

   1  Peer to HOKEY server: Int[ IK, (PID, DHID, Np,KN_IK)]

   2  HOKEY server to EAP Server: Int[KIhs, (PID, UHID)], Int[ IK, (PID,
      DHID, Np,KN_IK)]

   3  EAP Server to HOKEY server: {PID,HID,KN_HRK, KL_HRK, HRK}KChs,
      Int[ IK, (PID, HID, Np+1,KN_HRK,KL_HRK, KN_IK)]

   4  HOKEY server to Peer: Int[IK, (PID, HID, Np+1, KN_HRK,KL_HRK,
      KN_IK)]

   the notation is as follows:

   PID: peer ID.  The information is expected by carried by an existing
   attribute within EAP and/or AAA protocols.

   HID: HOKEY server ID (obtained by the peer through beacon
   announcements or other means)

   DHID: downlink HOKEY server ID as perceived by the peer (down link
   ID)

   UHID: Uplink HOKEY server ID as perceived by the EAP server (uplink
   ID)

   {X}K: X encrypted with key K

   Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X
   with key K.

   IK: Integrity key, A symmetric key shared between peer and EAP Server
   for signing and identified by KN_IK.

   CK: A symmetric key shared between peer and EAP Server for encryption
   and identified by KN_CK

   KChs: A symmetric key shared between HOKEY and EAP servers for
   encryption (provisioned out of band).

   KIhs: A symmetric key between HOKEY and EAP servers for signing
   (provisioned out of band).

   HRK: to be shared between peer and HOKEY server.  The key is named as
   KN_HRK.

   KLx : Key lifetime for key x



Nakhjiri & Ohba         Expires December 24, 2007              [Page 19]


Internet-Draft               Hokey hierarchy                   June 2007


   KN_Kx: Key name for Key x, e.g.  KN_KIas: key name for KIas

   Nx : Nonce provided by the party X

   Roaming between two administrative domains, e.g. from home domain to
   visited domain, while mid-session, would require involvement of a top
   level HOKEY server, so that it can generate a domain-specific HRK
   (DSHRK) for that domain.

5.2.  Derivation and delivery of Domain Specific Root keys

   A domain server acts as an authority for authorizing services, and
   DSRK holder (DSR-KH) and can authorize and generate keys for a set of
   services for which DSRK is generated (see
   [I-D.ietf-hokey-emsk-hierarchy]).  In this model each domain server
   needs to refer to the EAP server to derive DSRK directly from the
   EMSK.

   DSRK | DSRK_name_Key=DSRK_PRF(EMSK, NULL | Domain_ID | Peer_ID |
   Key_length)

   DSRK_name=First (128, HMAC_SHA256(DSRK_name_Key, NULL | peer_ID))

   Where Usage label is wild carded by inserting a NULL.

   the Domain_ID is the identifier of the domain for which the DSRK is
   being derived, e.g.  Home_domain_ID for DSHRK.

5.2.1.  Delivery of DSRK to domain server

   The DSR-KH is considered as a third party and thus the key
   distribution exchange is to be used for distributing DSRKs to the
   DSR-KH.  CK and IK derived from EMSK (described in earlier section)
   are used for protecting the signaling.  The delivery of DSRK to
   DSR-KH is very similar to delivery of USRK to USR-KH, except the
   domain ID needs to be communicated to both peer and EAP server.

   0  Domain server to peer: (DDID, DID)

   1  Peer to Domain server: Int[ IK, (PID, DDID, DID, Np,KN_IK)]

   2  Domain server to EAP Server: Int[KIds, (PID, UDID)], Int[ IK,
      (PID, DDID, DID, Np,KN_IK)]

   3  EAP Server to Domain server: {PID,DID,KN_DSRK, KL_DSRK, DSRK}KCds,
      Int[ IK, (PID, DID, Np+1,KN_DSRK,KL_DSRK, KN_IK)]





Nakhjiri & Ohba         Expires December 24, 2007              [Page 20]


Internet-Draft               Hokey hierarchy                   June 2007


   4  Domain server to Peer: Int[IK, (PID, DID, Np+1, KN_DSRK,KL_DSRK,
      KN_IK)]

   the notation is as follows:

   PID: peer ID.  The information is expected by carried by an existing
   attribute within EAP and/or AAA protocols.

   DID: Domain server ID (obtained by the peer through beacon
   announcements or other means)

   DDID: down link Domain server ID as perceived by the peer (down link
   ID)

   UDID: Uplink Domain server ID as perceived by the EAP server (uplink
   ID)

   {X}K: X encrypted with key K

   Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X
   with key K.

   IK: Integrity key, A symmetric key shared between peer and EAP Server
   for signing and identified by KN_IK.

   CK: A symmetric key shared between peer and EAP Server for encryption
   and identified by KN_CK

   KCds: A symmetric key shared between Domain and EAP servers for
   encryption (provisioned out of band).

   KIds: A symmetric key between Domain and EAP servers for signing
   (provisioned out of band).

   DSRK: to be shared between peer and domain server.  The key is named
   as KN_DSRK.

   KLx : Key lifetime for key x

   KN_Kx: Key name for Key x, e.g.  KN_KIas: key name for KIas

   Nx : Nonce provided by the party X

   Roaming between two administrative domains, e.g. from home domain to
   visited domain, while mid-session, would require involvement of EAP
   server, so that it can generate a domain-specific HRK (DSRK) for that
   domain based on the knowledge of peer and domain server identities.




Nakhjiri & Ohba         Expires December 24, 2007              [Page 21]


Internet-Draft               Hokey hierarchy                   June 2007


5.3.  Domain Specific Handover Root key

   A domain server can act as domain HOKEY server, holding the DSUSRK
   for HOKEY usage (DSUSR-KH).  In this model each domain HOKEY server
   needs to refer to the EAP server to derive DSHRK directly from the
   EMSK.

   DSHRK | DSHRK_name_Key=DSUSRK_PRF(EMSK, Usage_lable| Domain_ID |
   Peer_ID | Key_length)

   DSHRK_name=First (128, HMAC_SHA256(DSHRK_name_Key, Usage_label |
   peer_ID))

   Where Usage label is "Domain Handover Root Key".

   the Domain_ID is the identifier of the domain for which the DSHRK is
   being derived, e.g.  Home_domain_ID for HHRK.

   When roaming from one domain to the next, a domain specific handover
   root key (DSHRK) needs to be requested and generated from the EMSK
   and based on the knowledge of peer and domain server identities.

5.4.  key delivery within a domain

   In this section we describe the use of KDE in delivery a key within a
   domain.  We use delivery of a key to be shared between a peer and an
   authenticator (Kpa) from a domain HOKEY server to an authenticator as
   an example.  The domain HOKEY server holds a domain specific handover
   root key (DSHRK) and thus is a DSUSR-KH.  The peer and the domain
   HOKEY server share the DSHRK and can be both generate the Kpa. The
   authenticator is considered as a third party.  The KDE is used to
   deliver the Kpa to the authenticator.  However, since the KDE is
   performed within a domain, domain and usage specific IK and CK (DUIK
   and DUCK) are used for protecting the signaling.  The derivation of
   DUIK and DUCK is described in section XXX.

   0  Authenticator to peer: (DAID, DID)

   1  Peer to Authenticator: Int[ DUIK, (PID, DAID, DID, Np,KN_DUIK)]

   2  Authenticator to Domain HOKEY Server: Int[KIas, (PID, UAID)], Int[
      DUIK, (PID, DAID, DID, Np,KN_DUIK)]

   3  Domain HOKEY server to Authenticator: {PID,DID,KN_Kpa, KL_Kpa,
      Kpa}KCas, Int[ DUIK, (PID, DID, Np+1,KN_Kpa,KL_Kpa, KN_DUIK)]






Nakhjiri & Ohba         Expires December 24, 2007              [Page 22]


Internet-Draft               Hokey hierarchy                   June 2007


   4  Authenticator to Peer: Int[DUIK, (PID, DID, Np+1, KN_Kpa,KL_Kpa,
      KN_DUIK)]

   the specific notation is as follows:

   PID: peer ID.  The information is expected by carried by an existing
   attribute within EAP and/or AAA protocols.

   DID: Domain ID, used for generation of domain specific keys, such as
   HHRK (see key generation).

   AID: Authenticator ID (obtained by the peer through beacon
   announcements or as part of EAP Identity Request)

   DAID: Authenticator ID as perceived by the peer (down link ID)

   UAID: Authenticator ID as perceived by the server (uplink ID)

   {X}K: X encrypted with key K

   Int[K, X]: X | MIC (K, X) Message Integrity Code over X with key K.

   X(Y): Y carried with X protocol

   DUIK: Integrity key, A symmetric key shared between peer and domain
   HOKEY server for signing and identified by KN_DUIK.

   DUCK: A symmetric key shared between peer and domain HOKEY server for
   encryption and identified by KN_DUCK

   KCas: A symmetric key shared between authenticator and Server for
   encryption (provisioned out of band).

   KIas: A symmetric key between authentication and server for MDCs for
   signing (provisioned out of band).

   Kpa: A symmetric key to be shared between peer and authenticator.
   The key is named as KN_Kpa.

   KLx : Key lifetime for key x

   KN_Kx: Key name for Key x, e.g.  KN_KIas: key name for KIas

   Nx : Nonce provided by the party X


6.  Security Considerations




Nakhjiri & Ohba         Expires December 24, 2007              [Page 23]


Internet-Draft               Hokey hierarchy                   June 2007


7.  IANA consideration

   This document defines new usage labels, such as those used in
   generation of CK, IK, HRK.  The corresponding labels (e.g.
   "Integrity Key" and "Cipher key") need to be assigned numerical
   values by IANA.


8.  Acknowledgements

   The author would like to thank XX feedback.


9.  References

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

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-18 (work in
              progress), February 2007.

   [I-D.nakhjiri-aaa-hokey-ps]
              Nakhjiri, M., "AAA based Keying for Wireless Handovers:
              Problem Statement", draft-nakhjiri-aaa-hokey-ps-03 (work
              in progress), June 2006.

   [I-D.ietf-hokey-reauth-ps]
              Clancy, C., "Handover Key Management and Re-authentication
              Problem Statement", draft-ietf-hokey-reauth-ps-01 (work in
              progress), January 2007.

   [I-D.ietf-hokey-emsk-hierarchy]
              Salowey, J., "Specification for the Derivation of Usage
              Specific Root Keys (USRK) from an  Extended Master Session
              Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-00 (work in
              progress), January 2007.

   [I-D.ohba-hokey-3party-keydist-ps]
              Ohba, Y., "Problem Statement and Requirements on a 3-Party
              Key Distribution Protocol  for Handover Keying",



Nakhjiri & Ohba         Expires December 24, 2007              [Page 24]


Internet-Draft               Hokey hierarchy                   June 2007


              draft-ohba-hokey-3party-keydist-ps-01 (work in progress),
              March 2007.

   [I-D.nakhjiri-hokey-hierarchy]
              Nakhjiri, M., "Keying and signaling for wireless access
              and handover using EAP (EAP-HR)",
              draft-nakhjiri-hokey-hierarchy-04 (work in progress),
              April 2007.

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

   [RFC4072]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application", RFC 4072,
              August 2005.

9.2.  Informative references

   [I-D.housley-aaa-key-mgmt]
              Housley, R. and B. Aboba, "Guidance for AAA Key
              Management", draft-housley-aaa-key-mgmt-09 (work in
              progress), February 2007.


Appendix A.  Appendix A: Roaming hieararchy based on HRK

   The HOKEY server can use HRK to generate separate domain specific
   handover root keys (DSHRK) for each domain, e.g. a home HRK (HHRK)
   for home domain and a visited HRK (VHRK) for each visited domain.

   HHRK | HHRK_name_Key=HO_PRF(HRK, Peer_ID | home_domain_ID |
   Key_length)

   VHRK | VHRK_name_Key=HO_PRF(HRK, Peer_ID | visited_domain_ID |
   Key_length)

   Since HHRK and VHRK are no longer derived from the EMSK, the PRF used
   for generating these keys may or may need to comply with the
   requirements in [I-D.ietf-hokey-emsk-hierarchy] and thus we have used
   the notion of HO_PRF to indicate this flexibility.

   HHRK_name=First (128, HMAC_SHA256(HHRK_name_Key, "domain handover
   root key derivation"| peer_ID))

   VHRK_name=First (128, HMAC_SHA256(VHRK_name_Key, "domain handover
   root key derivation"| peer_ID))




Nakhjiri & Ohba         Expires December 24, 2007              [Page 25]


Internet-Draft               Hokey hierarchy                   June 2007


   Home_domain_ID or the Visited_domain_ID are the identifier for the
   home or visited domain as known to both peer and the HOKEY server
   generating HHRK or VHRK.  When roaming from one domain to the next,
   the peer needs to request for the domain specific handover root key
   (DSHRK) to be generated from the HRK and exchange its own identity as
   well as the domain identity with the server.

   It should be mentioned that HHRK and VHRKs can be generated directly
   from EMSK as usage and specific root keys (USDSRK).  In that case it
   would be the EAP server that has to generate such domain specific
   handover root keys (DSHRK), which means each DSHRK request needs to
   be made directly to the EAP server, along with domain_label for the
   domain.  The preferred method is to generate DSHRK from HRK instead.

   Domain specific HRKs (DSHRK) are delivered to the domain HOKEY
   servers through secure transport and cached at domain HOKEY servers,
   at a so called DSHRK key holder (DSHRK-KH).  Proper care needs to be
   taken to assure that DSHRK is bound to the identity of the HOKEY
   server caching the DSHRK.  This is described later on.

   In case the peer is at home domain, HHRK is delivered to the home
   HOKEY server.

   Providing re-authentication and handover keying service within each
   domain is upon the HOKEY server within that domain.  This means
   integrity and cipher keys (IK and CK) for re-authentication and
   handover keying signaling can be domain specific (DSIK and CSIK).
   Also the mobility domain master session keys (MDMSK) passed to the
   authenticators within the administrative domain are also domain
   specific.  This means DSHRK is used for calculation of these keys.
   It should be obvious that DSHRK, DSIK and DSCK are only accessible to
   the peer and domain HOKEY server, but not to the authenticator within
   the domain.  The following describes derivation of IK and CK for home
   domain (HUIK and CUIK) from HHRK:

      HUIK | HUIK_name_key=HO-PRF (HHRK, "domain integrity Key" |
      peer_ID | Home_domain_ID | Key_length )

      HUIK_name=First(128, HMAC_SHA256(HUIK_name_key "domain integrity
      Key"| peer_ID)

      HUCK | HUCK_name_key=HO-PRF (HHRK, "domain cipher Key" | peer_ID |
      Home_domain_ID | Key_length )

      HUCK_name=First(128, HMAC_SHA256(HUCK_name_key, "domain cipher
      Key"| peer_ID)





Nakhjiri & Ohba         Expires December 24, 2007              [Page 26]


Internet-Draft               Hokey hierarchy                   June 2007





Authors' Addresses

   Madjid Nakhjiri (editor)
   Huawei USA


   Email: mnakhjiri@huawei.com


   Yoshihiro Ohba (editor)
   Toshiba


   Email: yohba@tari.toshiba.com


































Nakhjiri & Ohba         Expires December 24, 2007              [Page 27]


Internet-Draft               Hokey hierarchy                   June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

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





Nakhjiri & Ohba         Expires December 24, 2007              [Page 28]


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