    Internet Engineering Task Force (IETF)                    K. Hoeper, Ed.
    Request for Comments: 5749                                   M. Nakhjiri
    Category: Standards Track                                       Motorola
    ISSN: 2070-1721                                             Y. Ohba, Ed.
                                                                     Toshiba
                                                                  March 2010

       Distribution of EAP-Based Keys for Handover and Re-Authentication

    Abstract

       This document describes an abstract mechanism for delivering root
       keys from an Extensible Authentication Protocol (EAP) server to
       another network server that requires the keys for offering security
       protected services, such as re-authentication, to an EAP peer.  The
       distributed root key can be either a usage-specific root key (USRK),
       a domain-specific root key (DSRK), or a domain-specific usage-
       specific root key (DSUSRK) that has been derived from an Extended
       Master Session Key (EMSK) hierarchy previously established between
       the EAP server and an EAP peer.  This document defines a template for
       a key distribution exchange (KDE) protocol that can distribute these
       different types of root keys using a AAA (Authentication,
       Authorization, and Accounting) protocol and discusses its security
       requirements.  The described protocol template does not specify
       message formats, data encoding, or other implementation details.  It
       thus needs to be instantiated with a specific protocol (e.g., RADIUS
       or Diameter) before it can be used.

    Status of This Memo

       This is an Internet Standards Track document.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Further information on
       Internet Standards is available in Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc5749.

    Hoeper, et al.               Standards Track                    [Page 1]

    RFC 5749                 HOKEY Key Distribution               March 2010

    Copyright Notice

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

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (http://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.

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

    Table of Contents

       1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
       3.  Key Delivery Architecture  . . . . . . . . . . . . . . . . . .  5
       4.  Key Distribution Exchange (KDE)  . . . . . . . . . . . . . . .  6
         4.1.  Context and Scope for Distributed Keys . . . . . . . . . .  7
         4.2.  Key Distribution Exchange Scenarios  . . . . . . . . . . .  8
       5.  KDE Used in the EAP Re-Authentication Protocol (ERP) . . . . .  8
       6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
         6.1.  Requirements on AAA Key Transport Protocols  . . . . . . .  9
         6.2.  Distributing RK without Peer Consent . . . . . . . . . . . 10
       7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
       8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
       9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
         9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
         9.2.  Informative References . . . . . . . . . . . . . . . . . . 11

    Hoeper, et al.               Standards Track                    [Page 2]

    RFC 5749                 HOKEY Key Distribution               March 2010

    1.  Introduction

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

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

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

    Hoeper, et al.               Standards Track                    [Page 3]

    RFC 5749                 HOKEY Key Distribution               March 2010

       presented KDE mechanism is a protocol template that must be
       instantiated for a particular protocol, such as RADIUS or Diameter,
       to specify the format and encoding of the abstract protocol messages.
       Only after such an instantiation can the KDE mechanism described in
       this document be implemented.  This document also describes security
       requirements for the secure key delivery over AAA.

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

       The following acronyms are used.

       AAA
          Authentication, Authorization and Accounting.  AAA protocols with
          EAP support include RADIUS ([RFC2865], [RFC3579]) and Diameter
          [RFC3588].

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

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

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

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

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

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

    Hoeper, et al.               Standards Track                    [Page 4]

    RFC 5749                 HOKEY Key Distribution               March 2010

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

       KDS
          Key Delivering Server.  A network server that holds an EMSK or
          DSRK and delivers root keys to a KRS requesting root keys.  The
          EAP server (together with the AAA server to which it exports the
          keys for delivery) and the DSR-KH can both act as KDS.

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

       HOKEY
          Handover Keying.

    3.  Key Delivery Architecture

       An EAP server carries out normal EAP authentications with EAP peers
       but is typically not involved in potential handovers and re-
       authentication attempts by the same EAP peer.  Other servers are
       typically in place to offer these requested services.  These servers
       can be AAA servers or other service network servers.  Whenever EAP-
       based keying material is used to protect a requested service, the
       respective keying material has to be available to the server
       providing the requested service.  For example, the first time a peer
       requests a service from a network server, this server acts as a KRS.
       The KRS requests the root keys needed to derive the keys for
       protecting the requested service from the respective KDS.  In
       subsequent requests from the same peer and as long as the root key
       has not expired, the KRS can use the same root keys to derive fresh
       keying material to protect the requested service.  These kinds of key
       requests and distributions are necessary because an EMSK cannot leave
       the EAP server ([RFC5295]).  Hence, any root key that is directly
       derived from an EMSK can only be derived by the EAP server itself.
       The EAP server then exports these keys to a server that can
       distribute the keys to the KRS.  In the remainder of this document,
       the KDS consisting of the EAP server that derives the root keys
       together with the AAA server that distributes these keys is denoted
       EAP/AAA server.  Root keys derived from EMSK child keys, such as a
       DSUSRK, can be requested from the respective root key holder.  Hence,
       a KDS can be either the EAP/AAA server or a DSRK holder (DSR-KH),
       whereas a KRS can be either a USRK holder (USR-KH), a DSR-KH, or a
       DSUSRK holder (DSUSR-KH).

    Hoeper, et al.               Standards Track                    [Page 5]

    RFC 5749                 HOKEY Key Distribution               March 2010

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

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

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

    4.  Key Distribution Exchange (KDE)

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

       The key distribution exchange consists of one round-trip, i.e., two
       messages between the KRS and the KDS, as illustrated in Figure 2.

    Hoeper, et al.               Standards Track                    [Page 6]

    RFC 5749                 HOKEY Key Distribution               March 2010

       First, the KRS sends a KDE-Request carrying a Key Request Token
       (KRT).  As a response, the KDS sends a KDE-Response carrying a Key
       Delivery Token (KDT).  Both tokens are encapsulated in AAA messages.
       The definition of the AAA attributes depends on the implemented AAA
       protocol and is out of scope of this document.  However, the security
       requirements for AAA messages carrying KDE messages are discussed in
       Section 6.  The contents of KRT and KDT are defined in the following.

         KRS                                        KDS
       --------                                   -------
           |                                          |
           |       KDE-Request: AAA{KRT}              |
           |----------------------------------------->|
           |       KDE-Response: AAA{KDT}             |
           |<-----------------------------------------|

                            Figure 2: KDE Message Flow

       KRT : (PID, KT, KL)

          KRT carries the identifiers of the peer (PID), the key type (KT)
          and the key label (KL).  The key type specifies which type of root
          key is requested, e.g., DSRK, USRK and DSUSRK.  The encoding rules
          for each key type are left to the protocol developers who define
          the instantiation of the KDE mechanism for a particular protocol.
          For the specification of key labels and the associated IANA
          registries, please refer to [RFC5295], which specifies key labels
          for USRKs and establishes an IANA registry for them.  The same
          specifications can be applied to other root keys.

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

          KDT carries the root key (RK) to be distributed to the KRS, as
          well as the key type (KT) of the key, the key label (KL), the key
          name (KN_RK), and the lifetime of RK (LT_RK).  The key lifetime of
          each distributed key MUST NOT be greater than that of its parent
          key.

    4.1.  Context and Scope for Distributed Keys

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

    Hoeper, et al.               Standards Track                    [Page 7]

    RFC 5749                 HOKEY Key Distribution               March 2010

    4.2.  Key Distribution Exchange Scenarios

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

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

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

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

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

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

                        Figure 3: Combined Message Exchange

    5.  KDE Used in the EAP Re-Authentication Protocol (ERP)

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

       In implicit bootstrapping, the local EAP Re-authentication (ER)
       server requests the DSRK from the home AAA server during the initial
       EAP exchange.  Here, the local ER server acts as the KRS and the home

    Hoeper, et al.               Standards Track                    [Page 8]

    RFC 5749                 HOKEY Key Distribution               March 2010

       AAA server as the KDS.  In this case, the local ER server requesting
       the DSRK includes a KDE-Request in the AAA packet encapsulating the
       first EAP-Response message from the peer.  Here, a AAA User-Name
       attribute is used as the PID.  If the EAP exchange is successful, the
       home AAA server includes a KDE-Response in the AAA message that
       carries the EAP-Success message.

       Explicit bootstrapping is initiated by peers that do not know the
       domain.  Here, the peer sends an EAP-Initiate message with the
       bootstrapping flag turned on.  The local ER server (acting as KRS)
       includes a KDE-Request message in the AAA message that carries the
       peer's EAP-Initiate message and sends it to the peer's home AAA
       server.  Here, a AAA User-Name attribute is used as the PID.  In its
       response, the home AAA server (acting as KDS) includes a KDE-Response
       in the AAA message that carries the EAP-Finish message with the
       bootstrapping flag set.

    6.  Security Considerations

       This section provides security requirements and a discussion of
       distributing RK without peer consent.

    6.1.  Requirements on AAA Key Transport Protocols

       Any KDE attribute that is exchanged as part of a KDE-Request or KDE-
       Response MUST be integrity-protected and replay-protected by the
       underlying AAA protocol that is used to encapsulate the attributes.
       Additionally, a secure key wrap algorithm MUST be used by the AAA
       protocol to protect the RK in a KDE-Response.  Other confidential
       information as part of the KDE messages (e.g., identifiers if privacy
       is a requirement) SHOULD be encrypted by the underlying AAA protocol.

       When there is an intermediary, such as a AAA proxy, on the path
       between the KRS and the KDS, there will be a series of hop-by-hop
       security associations along the path.  The use of hop-by-hop security
       associations implies that the intermediary on each hop can access the
       distributed keying material.  Hence, the use of hop-by-hop security
       SHOULD be limited to an environment where an intermediary is trusted
       not to abuse the distributed key material.  If such a trusted AAA
       infrastructure does not exist, other means must be applied at a
       different layer to ensure the end-to-end security (i.e., between KRS
       and KDS) of the exchanged KDE messages.  The security requirements
       for such a protocol are the same as previously outlined for AAA
       protocols and MUST hold when encapsulated in AAA messages.

    Hoeper, et al.               Standards Track                    [Page 9]

    RFC 5749                 HOKEY Key Distribution               March 2010

    6.2.  Distributing RK without Peer Consent

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

       On the other hand, when a KDE-Request is sent as a result of implicit
       ERP bootstrapping [RFC5296], cryptographic verification of peer
       consent on distributing an RK is not provided.  A peer is not
       involved in the process and, thus, not aware of key delivery requests
       for root keys derived from its established EAP keying material.
       Hence, a peer has no control where keys derived from its established
       EAP keying material are distributed.  A possible consequence of this
       is that a KRS may request and obtain an RK from the home server even
       if the peer does not support ERP.  EAP-Initiate/Re-auth-Start
       messages send to the peer will be silently dropped by the peer
       causing further waste of resources.

    7.  Acknowledgments

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

    8.  Contributors

       The following people contributed to this document: Kedar Gaonkar,
       Lakshminath Dondeti, Vidya Narayanan, and Glen Zorn.

    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.

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

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

    Hoeper, et al.               Standards Track                   [Page 10]

    RFC 5749                 HOKEY Key Distribution               March 2010

    9.2.  Informative References

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

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

       [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
                  Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

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

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

    Hoeper, et al.               Standards Track                   [Page 11]

    RFC 5749                 HOKEY Key Distribution               March 2010

    Authors' Addresses

       Katrin Hoeper (editor)
       Motorola, Inc.
       1295 E Algonquin Road
       Schaumburg, IL  60196
       USA

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

       Madjid F. Nakhjiri
       Motorola, Inc.
       6450 Sequence Drive
       San Diego, CA  92121
       USA

       EMail: madjid.nakhjiri@motorola.com

       Yoshihiro Ohba (editor)
       Toshiba Corporate Research and Development Center
       1 Komukai-Toshiba-cho
       Saiwai-ku, Kawasaki, Kanagawa  212-8582
       Japan

       Phone: +81 44 549 2230
       EMail: yoshihiro.ohba@toshiba.co.jp

    Hoeper, et al.               Standards Track                   [Page 12]