[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                                        M. Nakhjiri
Internet-Draft                                                  Motorola
Expires: May 10, 2008                                            Y. Ohba
                                                                 Toshiba
                                                        November 7, 2007


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

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 May 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes a delivery framework for usage and domain
   specific root keys (USRK and DSRK), 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



Nakhjiri & Ohba           Expires May 10, 2008                  [Page 1]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   required for security protection of key requests and delivery
   signaling.


Table of Contents

   1.  Introduction and Problem statement . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Key Delivery Architecture  . . . . . . . . . . . . . . . . . .  5
     3.1.  Three Party Key distribution Exchange (KDE)  . . . . . . .  7
     3.2.  Derivation of keys protecting the KDE  . . . . . . . . . . 10
     3.3.  Specification of context and scope for distributed keys  . 11
     3.4.  3 party key exchange scenarios . . . . . . . . . . . . . . 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  IANA consideration . . . . . . . . . . . . . . . . . . . . . . 15
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     7.2.  Informative references . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18






























Nakhjiri & Ohba           Expires May 10, 2008                  [Page 2]


Internet-Draft       HOKEY 3-Party Key Distribution        November 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 (MSK and EMSK) [I-D.ietf-eap-keying]
   has led to the idea of using MSK and/or EMSK for bootstrapping
   further keys for a variety of security mechanisms.  Especially, 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 MSK and the current bootstrapping
   methods when it comes to mobility performance and security are
   described in [I-D.ietf-hokey-reauth-ps].  Thus new efforts are under
   way to use EMSK instead of MSK for bootstrapping of keys for future
   use cases [I-D.ietf-hokey-emsk-hierarchy], [I-D.ietf-hokey-erx].  For
   instance [I-D.ietf-hokey-emsk-hierarchy] defines ways to create usage
   specific root keys (USRK) for bootstrapping security of a specific
   use case.  [I-D.ietf-hokey-emsk-hierarchy] 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 on the other hand 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.  This is to address the following concerns:

   1.  EAP authentication is a 2 party protocol executed between an EAP
       peer and an EAP server and the EMSK is only generated and held at
       these two parties [I-D.ietf-eap-keying], while USRK, DSRK and
       DSUSRK are also generated only by these two parties, but they
       typically need to be stored and utilized at third party key
       holders (e.g.  AAA servers/entities) that are logically or even
       physically separate from the EAP server or peer.  For instance,
       handover keying and re-authentication service requires
       distribution of keys a variety of intermediaries.  This would
       mean these root keys need to be delivered to these third party
       key holders (KH) in a secure manner, while considering the
       requirements stated in [RFC4962]

   2.  EAP authentication and EMSK generation process is oblivious to
       the service and authorization requests following the initial EAP
       authentication.  Thus at the time of EAP authentication, the EAP
       parties do not have access to the input data required for
       creation of the USRK, DSRK or DSUSRK
       [I-D.ietf-hokey-emsk-hierarchy].  Such input data is typically
       acquired and delivered to the EAP server at a later stage.  The
       EAP server then performs the derivation function, followed by a
       secure delivery of the resulting keys to these third party key
       holders.



Nakhjiri & Ohba           Expires May 10, 2008                  [Page 3]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   The purpose of this document is to show how the required input data
   for root key derivation 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.  The specification also includes derivation of
   key material required for secure delivery and channel binding
   procedures for these key materials 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.

   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 [RFC3579] [RFC4072] 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].

   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.

   USR-KH:  USRK holder.  The USR-KH is responsible for receiving,
      holding and protection of the USRK derived directly from EMSK.

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

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

   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 an EAP-authenticated peer is authorized to
      receive services from.  DSUSRK is both usage and domain dependent.

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





Nakhjiri & Ohba           Expires May 10, 2008                  [Page 4]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   HOKEY server (HS):  This is essentially a usage specific server, that
      deals with re-authentication as specific usage (USR-KH for HOKEY).

   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.


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, neither 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 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 EMSK cannot be
   exported from EAP server, such third parties need to request the EAP
   server to generate the relevant root key (USRK, DSRK, or DSUSRK) 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
      possibly responsible for derivation and distribution of any child
      keys derived from USRK for that specific usage.  The USR-KH by
      definition is domain independent, which means the USR-KH can use
      USRK to generate DSUSRK for each domain deploying that service.
      It is possible that this USR-KH server is not physically disjunct
      from the EAP server but is simply considered as a separate logic
      to off-load the EAP server from the need to handle usage specific
      services, such as HOKEY service.  Security Requirements for
      delivery of USRK from EAP server to a collocated USR-KH is
      currently TBD.  However, to keep the security 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 accordingly.






Nakhjiri & Ohba           Expires May 10, 2008                  [Page 5]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   DSRK holder (DSR-KH):  An entity acting as a recipient and then
      holder of the domain specific root key (DSRK).  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):  An entity acting as a recipient and then
      holder of the domain specific and usage specific root key (DSUSRK)
      delivered from the EAP server.  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.


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

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

        Figure 1: 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.  Each of the top
   level key holders (USR-KH, DSR-KH has a interface with the EAP
   server, for delivering usage specific (and/or domain specific) input
   data needed for root key generation (USRK, DSRK) to the EAP server
   and receiving the resulting root key from the EAP server.  The



Nakhjiri & Ohba           Expires May 10, 2008                  [Page 6]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   DSUSR-KH is considered a top level key holder and has an interface
   with EAP server, only when the DSUSRK is directly derived from the
   EMSK and by the EAP server.

   Regardless of the type of key being delivered, the model for EAP
   based key derivation and delivery interface can be generalized as a 3
   party key distribution model, since 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, while the EMSK is used to derive the top level root
   keys and deliver those to a third party key holder, such as USR-KH or
   DSR-KH.

3.1.  Three Party Key distribution Exchange (KDE)

   In the following we describe the generic mechanism for a 3 party 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 3 party key
   distribution mechanism.  The peer (P) and a parent key holder, called
   "server" (S) in this model share a parent key (Kps) and a set of
   security associations (SA1) for integrity and privacy protection of
   signaling between the peer and the server (KIps and KCps).  The goal
   of the keying solution is to use the parent key (Kps) 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 (key
   distribution exchange) for distribution of Kpt from S to T. We also
   assume that the server (S) and the third party (T) share a similar
   set security association, SA2 (KIts, KCts).

             +-+-+-+-+                              +-+-+-+-+-+-+-+
             |       |            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 exchange described here is a modified version of
   the Otway-Rees protocol that meets the requirements for such 3-party



Nakhjiri & Ohba           Expires May 10, 2008                  [Page 7]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   lay-out, providing channel binding and avoids the lying intermediary
   scenario.  The exchange proposed below is to perform a channel
   binding and avoid the lying intermediary scenario.  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 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.

              peer                 Third party           server
              -----                --------              -------
              |    KDE0(TID, SID, DID) |                    |
              |<-----------------------|                    |
              |    KDE1 (PRT)          |  KDE2 (TRT)        |
              |----------------------->|------------------->|
              |    KDE4 (SAT)          |  KDE3 (TOK)        |
              |<-----------------------|<-------------------|


                      Figure 3: Handover using EAP-HR

   KDE message 0:  Third party sends its own identifier (TID), the
      Server ID (SID) and the Domain ID (DID) to peer.  These
      identifiers need to be recognizable by the server S and when AAA
      signaling is used may be carried as AAA attributes.  Domain ID is
      used to create domain specific keys or to assist in key
      distribution.

   KDE message 1:  Peer sends a peer request token (PRT) to the third
      party including the TID reported by the third party and a
      freshness value.  The contents of PRT are detailed below.

   KDE message 2:  Third party uses the PRT and creates a third party
      request token (TRT) and sends it to the server.  The contents of
      TRT are detailed below.







Nakhjiri & Ohba           Expires May 10, 2008                  [Page 8]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   KDE message 3:  Server sends the Kpt to third party wrapped inside a
      token called Key Token (TOK).  The TOK carries a Server
      Authorization Token (SAT) destined for the peer, carrying
      assurance for the peer that the server has sent the key Kpt to the
      properly identified third party (identified by TID)

   KDE message 4:  The third party extracts the SAT out of the encrypted
      message from the server and forwards it to the peer.  The
      successful receipt of SAT by peer means that the third party has
      successfully decrypted TOK and have gotten Kpt without seeing the
      content of SAT.

   {X}K: X encrypted with key K

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

   PRT : Int[KIps,(PID, TID, SID, DID, FVp, KT, KN_KIps)]

      PRT (Peer Request Token) carries the identities of peer (PID),
      server (SID), third party (TID) and domain (DID) along with the
      signature.  The signature is called the peer request authenticator
      (PRA).  KIps is a symmetric key shared between peer and Server for
      signing and identified by KN_KIps.  FVx is the Freshness Value
      provided by the party X. A Freshness Value can be a nonce or a
      time stamp.  Use of nonce for FV may require additional mechanism
      for the server to maintain the freshness.  KT is the Key Type
      requested by the peer.  The KT is an 2-octet unsigned integer
      which uniquely identifies the type of the key.

   TRT : Int[KIts, (PID, TID), PRT]

      TRT (Third party Request Token) carries the token from the peer
      along with the third party and peer IDs and a signature for
      integrity protection.  KIts is the shared key used for signing
      purposes.  Providing third party identifier both explicitly by the
      third party and both implicitly through PRT allows the server to
      detect a lying third party.

   TOK : {PID, TID, KN_Kpt, KL_Kpt, Kpt, SAT}KCts

      TOK(Key Token) carries the key to be distributed to the third
      party (Kpt) wrapped with an encryption key (KCts).  KL_Kx is the
      key lifetime for key Kx.







Nakhjiri & Ohba           Expires May 10, 2008                  [Page 9]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   SAT : Int[KIps,(PID, TID, SID, DID, FVp+1, KN_Kpt, KL_Kpt, KN_KIps)]

      SAT (Server Authorization Token) carries assurance (in form of
      signature on the incremented nonce value) for the peer that the
      server has sent the key Kpt to the properly identified third party
      (identified by TID).

   The exchange proposed above can avoid the lying intermediary
   scenario, as follows: if an intermediary decided to announce two
   different identifiers to the peer versus to the server, e.g. 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.

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

                             KDRK (=EMSK or USRK or DSUSRK)
                               |
                          +----+---+
                          |        |
                          CK       IK

              Figure 4: Key delivery keys as EMSK Child keys

   Cipher key (CK) and Integrity Key (IK) are used to protect KDE for
   delivery of USRKs, DSRKs, DSUSRKs, per-authenticator master keys and
   any other keys generated from EMSK.  CK and IK are generated from
   KDRK (Key Distribution Root Key) which is EMSK or DSRK.  When KDRK is
   EMSK, CK and IK are defined as USRKs.  When KDRK is DSRK, CK and IK
   are defined as DSUSRKs.




Nakhjiri & Ohba           Expires May 10, 2008                 [Page 10]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


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

   CK and IK, and their key names are defined using the algorithms
   defined in [I-D.ietf-hokey-emsk-hierarchy] as follows:

   IK = KDF(KDRK, IK_Label | NULL | Key_length)

   IK_name = prf-64( Name_Base, IK_Label)

   CK = KDF(KDRK, CK_Label | NULL | Key_length)

   CK_name = prf-64( Name_Base, CK_Label)

   The IK_Label and CK_Label are IANA-assigned ASCII strings "Key
   Distribution Integrity Key" and "Key Distribution Cipher Key"
   assigned from the Key Label name space in accordance with
   [I-D.ietf-hokey-emsk-hierarchy].  This document specifies IANA
   registration for the IK_Label and CK_Label above.

   When KDRK is EMSK, Name_Base is EAP Session ID.

   When KDRK is a USRK or a DSUSRK, Name_Base is the name of the USRK or
   DSUSRK, respectively.

3.3.  Specification of 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.

   The key scope of each distributed key is determined by the sequence
   of (PID, SID, TID, DID)-tuples in the key hierarchy.

3.4.  3 party key exchange scenarios

   As mentioned earlier, EMSK can be used to generate any of the USRKs,
   DSRKs and DSUSRKs.  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.  Since the EAP server
   performing EAP method authentication and EMSK generation resides in
   peer's home domain, for practical purposes, for the mechanisms
   described in this document, the USR-KH MUST reside in this domain.



Nakhjiri & Ohba           Expires May 10, 2008                 [Page 11]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


   Note that other key distribution scenarios may also be possible
   depending how an USRK is defined.

   Scenario 1: EAP server to NAS:  In this scenario, a per-authenticator
      key such as an MSK is transfered from the EAP server to the NAS.

   Scenario 2: EAP server to USR-KH:  The specific use case considered
      in this document is HOKEY re-authentication service: The USR-KH is
      a HOKEY server and USRK is rRK.  The EAP server delivers the rRK
      to the USR-KH.  The trigger and mechanism for key delivery may
      involve a specific request from the peer and another intermediary
      (such as authenticator).

   Scenario 3: EAP server to DSR-KH:  In this scenario, a domain server,
      typically a domain AAA server requires delivery of a DSRK for a
      set of prespecified usages within the domain.  DSR-KH and EAP
      server are physically disjunct.  Thus deployment of 3 party key
      distribution exchange is required.

   Scenario 4: 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.

   Scenario 5: USR-KH to NAS:  In this scenario, an USR-KH in the home
      domain directly delivers keying material to the NAS in the home or
      a visited domain.

   Scenario 6: DSUSR-KH to NAS:  In this scenario, a DSUSR-KH in the
      home or a visited domain receives keying material from the EAP
      server in the home domain and delivers it to the NAS in the same
      domain as the DSUSR-KH.

   Scenario 7: USR-KH to USDSR-KH:  In this scenario, a USDSR-KH, a key
      holder of a domain specific key designated for a specific usage,
      in the home or a visited domain receives keying material from an
      USR-KH in the home domain.

   The mapping between the protocol parameters in each scenario to the
   protocol parameters of the KDE protocol defined in Section 3.1 is
   given below, where IK_X and CK_X are IK and CK derived from key X,
   respectively.










Nakhjiri & Ohba           Expires May 10, 2008                 [Page 12]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


           +-----------------------------------------------------------+
           |                    Scenarios                              |
   +-------+---------+---------+---------+---------+---------+---------+
   | KDE   |    1    |    2    |    3    |    4    |    5    |    6    |
   | Param.|         |         |         |         |         |         |
   +-------+---------+---------+---------+---------+---------+---------+
   | PID   |                      EAP Peer ID                          |
   +-------+---------+---------+---------+---------+---------+---------+
   | SID   |         EAP Server ID       |DSR-KH ID|       HS ID(*1)   |
   +-------+---------+---------+---------+---------+---------+---------+
   | TID   |  NAS ID |HS ID(*1)|DSR-KH ID|HS ID(*2)|       NAS ID      |
   +-------+---------+---------+---------+---------+---------+---------+
   | Kpt   |   MSK   |  rRK    |  DSRK   |  rRK    |        rMSK       |
   +-------+---------+---------+---------+---------+---------+---------+
   | KIps  |          IK_EMSK            | IK_DSRK | IK_USRK |IK_DSUSRK|
   +-------+---------+---------+---------+---------+---------+---------+
   | KCps  |          CK_EMSK            | CK_DSRK | CK_USRK |CK_DSUSRK|
   +-------+---------+---------+---------+---------+---------+---------+
   | KIts  |                   Any pre-existing key                    |
   +-------+---------+---------+---------+---------+---------+---------+
   | KCts  |                   Any pre-existing key                    |
   +-------+---------+---------+---------+---------+---------+---------+
   (*1) HS ID is USR-KH ID for HOKEY
   (*2) HS ID is DSUSR-KH ID for HOKEY



























Nakhjiri & Ohba           Expires May 10, 2008                 [Page 13]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


           +-----------------------+
           |       Scenarios       |
   +-------+-----------------------+
   | KDE   |           7           |
   | Param.|                       |
   +-------+-----------------------+
   | PID   |     EAP Peer ID       |
   +-------+-----------------------+
   | SID   |      USR-KH ID        |
   +-------+-----------------------+
   | TID   |     USDSR-KH ID(*3)   |
   +-------+-----------------------+
   | Kpt   |       USDSRK(*3)      |
   +-------+-----------------------+
   | KIps  |       IK_USRK         |
   +-------+-----------------------+
   | KCps  |       CK_USRK         |
   +-------+-----------------------+
   | KIts  |  Any pre-existing key |
   +-------+-----------------------+
   | KCts  |  Any pre-existing key |
   +-------+-----------------------+
   (*3) USDSR-KH is a key holder of USDSRK.  USDSRK is a domain specific
   key designated for a specific usage


   The key distribution exchanges for some of the above scenarios can be
   recursively combined into a single 1.5-roundtrip exchange.  For
   example, a combined key distribution exchange for Scenarios 3 and 6
   is illustrated in Figure 5 where KDE[0-4] and KDE'[0-4] are messages
   for Scenarios 3 and 6, respectively.  It is assumed in Figure 5 that
   DSR-KH and DSUSR-KH are co-located in the same HOKEY server (i.e.,
   DSR-KH and DSUSR-KH have the same identity).

        peer              NAS                DSR-KH/          EAP Server
                                             DSUSR-KH
        -----             --------           -------          -----
         |  KDE0(TID,  SID)  |                 |                |
         |  KDE0'(TID',SID') |                 |                |
         |<------------------|                 |                |
         |   KDE1(PRT)       |   KDE1(PRT)     |   KDE2(TRT)    |
         |   KDE1'(PRT')     |   KDE2'(TRT')   |                |
         |------------------>|---------------->|--------------->|
         |   KDE4(SAT)       |   KDE4(SAT)     |   KDE3(TOK)    |
         |   KDE4'(SAT')     |   KDE3'(TOK')   |                |
         |<------------------|<--------------- |<---------------|
         |                   |                 |                |




Nakhjiri & Ohba           Expires May 10, 2008                 [Page 14]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


                    Figure 5: Combined Message Exchange


4.  Security Considerations

   The key distribution mechanism described in this document assumes
   existence of direct trust relationship between the server and the
   third party key holder.  On the other hand, it is quite possible that
   key distribution from server to third party is carried over a AAA
   infrastructure where transitive trust relationship with use of AAA
   proxies is common.  In such an environment, protection between the
   third party and the server may be relaxed to rely on hop-by-hop
   security associations along the transitive trust relationship rather
   than end-to-end protection based on KIts and KCts.  However, hop-by-
   hop security associations will create security consideration with
   respect to the privacy of the keys being distributed.

   EDITOR'S NOTE: For a key distribution mechanism that works with
   indirect trust relationship, a Kerberos-like key distribution
   protocol that supports "inter-realm" keys would be needed.


5.  IANA consideration

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

   This document defines KT (Key Type) which is an IANA-assigned 2-octet
   unsigned integer.  The following Key Type values are allocated in
   this document:

   0 (MSK)

   1 (DSRK)

   2 (rRK)

   3 (rMSK)


6.  Acknowledgements

   The author would like to thank Dan Harkins for his valuable
   contribution to the formation of the KDE.





Nakhjiri & Ohba           Expires May 10, 2008                 [Page 15]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


7.  References

7.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., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              draft-ietf-eap-keying-21 (work in progress), October 2007.

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

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

   [I-D.ietf-hokey-erx]
              Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
              authentication Protocol (ERP)", draft-ietf-hokey-erx-06
              (work in progress), November 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.

   [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
              Authorization, and Accounting (AAA) Key Management",
              BCP 132, RFC 4962, July 2007.

7.2.  Informative references






Nakhjiri & Ohba           Expires May 10, 2008                 [Page 16]


Internet-Draft       HOKEY 3-Party Key Distribution        November 2007


Authors' Addresses

   Madjid Nakhjiri
   Motorola


   Email: madjid.nakhjiri@motorola.com


   Yoshihiro Ohba
   Toshiba


   Email: yohba@tari.toshiba.com





































Nakhjiri & Ohba           Expires May 10, 2008                 [Page 17]


Internet-Draft       HOKEY 3-Party Key Distribution        November 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 May 10, 2008                 [Page 18]


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