diff options
Diffstat (limited to 'doc/rfc/rfc5749.txt')
| -rw-r--r-- | doc/rfc/rfc5749.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc5749.txt b/doc/rfc/rfc5749.txt new file mode 100644 index 0000000..543a36e --- /dev/null +++ b/doc/rfc/rfc5749.txt @@ -0,0 +1,675 @@ + + + + + + +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] + |