Network Working Group INTERNET-DRAFT J. Salowey Document: draft-salowey-eap-key-deriv-01.txt Cisco P. Eronen Nokia Expires: December 2003 June 2003 EAP Key Derivation for Multiple Applications Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract The Extensible Authentication Protocol (EAP) provides an extensible interface to various authentication mechanisms. Some EAP methods derive cryptographic material between the EAP peers; these keys can be used, for instance, with IEEE 802.11i encryption. This document proposes a mechanism that can be used to derive cryptographically separate keys for more than one cryptographic application, such as protecting subsequent EAP messages, distributing credentials for re- authentication, or handoff mechanisms involving multiple WLAN access points. Table of Contents 1. Introduction...................................................2 1.1 Cryptographic separation between applications..............2 1.2 Cryptographic separation between devices...................3 1.3 Use cases..................................................3 1.4 Motivation.................................................4 1.5 Terminology................................................4 INTERNET-DRAFT EAP Key Derivation June 2003 2. Requirements for EAP methods and applications..................5 2.1 Requirements for EAP methods...............................5 2.2 Requirements for EAP applications..........................6 3. EAP Key Derivation Framework...................................6 3.1 The EAP Key Derivation Function............................7 3.2 Multiple EAP mechanism keys................................8 3.3 Obtaining Keys.............................................8 4. Security Considerations........................................8 4.1 Key strength...............................................8 4.2 Cryptographic separation of keys...........................8 4.3 Implementation.............................................8 5. IANA Considerations............................................9 References........................................................9 Acknowledgments..................................................10 Author's Addresses...............................................10 Appendix A: Test vectors for KDF.................................10 1. Introduction EAP provides a consistent interface for exchanging authentication messages. It is also possible for some EAP methods to generate keying material that will be used to protect some subsequent application (e.g. 802.11i encryption). Typically, an EAP method produces a Master Session Key (MSK), which is sent by the EAP server to the authenticator (e.g. NAS, WLAN access point). The authenticator then uses the MSK to derive Transient Session Keys (TSKs), which are used to protect the actual communication. This derivation is specific to the particular application (e.g. MPPE, 802.11i encryption) and cipher suites used. The derivation is done by the authenticator, so the EAP server does not have to know about the applications and cipher suites. In addition, an EAP method may internally use some keys (Transient EAP Keys or TEKs) to protect its communication. In this document, we are not interested in these keys, only keys that are used after an EAP method has finished and exported some keying material. The current EAP specifications implicitly assume that the keying material produced by EAP will be used for a single application at a single device, however it does define an Extended Master Session Key (EMSK). This document describes how to use this key to derive keys for specific applications. 1.1 Cryptographic separation between applications Salowey and Eronen Expires December 2003 [Page 2]
INTERNET-DRAFT EAP Key Derivation June 2003 If the keying material is used to provide keys for multiple applications, it is often desired that the keys will be cryptographically separate. This separation currently depends on the individual key derivation functions (KDF) and protocols (which take the MSK and possibly via some intermediate steps, produce TSKs); for instance, 802.11 and MPPE specify such functions [references]. If multiple applications are used, it is important that these KDFs actually provide separate keys. How should this be done, i.e., who should coordinate that these KDFs actually achieve this? o Certainly not EAP methods; the methods should be independent of the applications their keys will be used for. o Probably not the application specifications, since otherwise all applications have to know what other applications (current and future) could be used together. This document attempts to specify such a mechanism, which can be used with existing and new EAP methods, and existing and new applications for these keys, in a way that provides cryptographic separation. 1.2 Cryptographic separation between devices A related issue is that the keys could be used by separate devices. In this case, it may be desirable that their knowledge is cryptographically separate. This implies that some key derivation must be done at the EAP server (which knows everything exported by the EAP method) instead of the authenticator, and that authenticator should be sent only keys derived from the MSK. This changes one of the traditional assumptions in EAP: that the EAP server should not know what the keys will be used for. Changing this assumption should not be taken lightly: alternative ways to achieving a particular goal should be investigated. This document attempts to specify a mechanism that allows the EAP server to derive cryptographically separate keys from the MSK. The mechanism is backward-compatible with existing application specs and authenticators. 1.3 Use cases There are several applications for ciphering keys outside of link layer protection as in 802.11. This specification could derive keys to protect sensitive authorization information requested from an EAP Salowey and Eronen Expires December 2003 [Page 3]
INTERNET-DRAFT EAP Key Derivation June 2003 peer by and EAP server [EAP-AUTH]. In another example the EAP server may wish to issue credentials to an EAP peer in a protected TLV [PRO- TLV]. Many other applications can be found for keys derived from EAP- mechanisms. A recent proposal for 802.11 handoff by Mishra et al. [IEEE-03-084] provides another example where cryptographic separation between different devices was required. To derive cryptographically separate keys for different WLAN access points, their proposal uses a value internal to a particular EAP method (TLS master secret in EAP-TLS), making it difficult to use for other EAP methods. 1.4 Motivation Cryptographic separation between devices within a single application can be addressed by existing specs, simply by considering the device- specific master keys to be just one kind of TSK. Cryptographic separation between different applications CANNOT be addressed by existing solutions UNLESS we require that the derivation of TSKs is somehow coordinated. This document specifies a way of coordinating these. We want to have a mechanism for deriving independent keys which (1) does not depend on a single EAP method, and (2) allows development of new applications without cumbersome coordination between different application specifications. 1.5 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]. Some of the following terms are taken from RFC 2284bis: EAP Peer The end of the EAP Link that responds to the authenticator. EAP server The entity that terminates the EAP authentication with the peer. In the case where there is no backend authentication server, this term refers to the authenticator. Where the authenticator operates in pass-through, it refers to the backend authentication server. EAP application Salowey and Eronen Expires December 2003 [Page 4]
INTERNET-DRAFT EAP Key Derivation June 2003 A consumer of EAP keying material. Examples include link layer encryption such as 802.11i encryption, MPPE, etc. Master Session Key (MSK) Keying material exported by an EAP method. Extended Master Session Key (EMSK) Keying material taken from a specific portion of the MSK that is not used for any other purpose than the key derivation described in this document. Usually bytes 64..N of MSK. Transient Session Key (TSK) Session keys used to protect communication in some particular application. They are derived from MSK(0,63) or an AMSK in an application-specific way. Application Master Session Key (AMSK) Keying material used to derive TSKs for the application in an application specific way. Cryptographic separation Two keys (X and Y) are "cryptographically separate" (or "independent") if an adversary that knows all messages exchanged in the protocol (and other public information) cannot compute X from Y or Y from X without "breaking" some cryptographic assumption. (definition borrowed from [EAP-Key]) 2. Requirements for EAP methods and applications 2.1 Requirements for EAP methods In order for an EAP method to participate in the EAP key derivation it must meet the following requirements. o It must specify how to derive the EMSK o The key material used for the EMSK MUST be independent of the backward-compatibility part (first 64 bytes) and TEKs. o The EMSK MUST NOT be used for any other purpose than the key derivation described in this document. Salowey and Eronen Expires December 2003 [Page 5]
INTERNET-DRAFT EAP Key Derivation June 2003 o The EMSK MUST be secret and not known to someone observing the authentication mechanism protocol exchange. o The EMSK MUST be unique for each session. 2.2 Requirements for EAP applications To be compatible with this spec, o The application MAY use the MSK in any way it chooses. This is required for backward compatibility. New applications following this specification SHOULD NOT use the MSK. o The application MUST NOT use the EMSK in any other way except the key derivation specified in this document. o Applications MUST use distinct key labels. o If more than one application uses the MSK, then the cryptographic separation is not achieved. Implementations SHOULD prevent such combinations. Most (all?) existing EAP applications use only the first 64 bytes of their generated key stream as the MSK. One suggestion is to define the EMSK as the next 64 bytes of the generated key stream. This may not be possible for every mechanism so other techniques are possible. 3. EAP Key Derivation Framework The EAP key derivation framework provides a means for generating multiple application-specific master keys (AMSKs). These AMSKs are then used to derive transient session keys (TSKs), which are used as actual ciphering keys. This allows multiple applications to use keys independently derived from the EAP method. The EAP key derivation framework provides a key derivation function (KDF) which takes the Extended Master Session Key (EMSK) described above, an application key label, and optional application data, and returns an application master session key (AMSK). AMSK = KDF(EMSK, key label, optional application data) The key labels are unique printable ASCII strings (see Section 5 for IANA Considerations). Additional ciphering keys (TSKs) can be derived from the AMSK using an application specific key derivation mechanism. In most cases, this Salowey and Eronen Expires December 2003 [Page 6]
INTERNET-DRAFT EAP Key Derivation June 2003 AMSK->TSK derivation can simply split the AMSK to pieces of correct length. In particular, it not necessary to use a cryptographic one- way function. Note that the length of the AMSK is not fixed, since the KDF can produce a (practically) unlimited amount of keying material. If the AMSK is, for instance, sent to another device, the EAP application MUST specify how many bytes must be sent. Unless otherwise specified, 128 bytes is recommended. 3.1 The EAP Key Derivation Function The EAP key derivation function is taken from the TLS P_SHA1 key expansion PRF [RFC2246]. This PRF takes three parameters as input: secret, label, and seed, and produces an arbitrary amount of keying material. For the purposes of this specification the secret is taken as the EMSK, the label is the key label described above concatenated with a NUL byte, and the seed is the application data. The seed is optional. For this specification we have: KDF = PRF(EMSK, key label + "\0", application data) PRF(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + ... Where + indicates concatenation. Secret is EMSK Seed = key label + "\0" + application data A() is defined as: A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) The P_SHA1 component of the TLS PRF was chosen over the TLS PRF because it does not split the secret before processing. IKE uses a very similar PRF [RFC2409], but it does not include label and seed fields. The NUL byte after the key label is used to avoid collisions if one key label is a prefix of another label (e.g. "foobar" and "foobarExtendedV2"). This is considered a simpler solution than requiring a key label assignment policy that prevents prefixes from occurring. Salowey and Eronen Expires December 2003 [Page 7]
INTERNET-DRAFT EAP Key Derivation June 2003 3.2 Multiple EAP mechanism keys It is possible that multiple EAP mechanisms may be chained or nested and the more than one of these mechanisms may generate keys. In this case it is desirable to combine the entropy of these keys. Since chaining requires an encapsulating method to control the EAP communication it is this layer that is responsible for combining keys. Since an EAP-Server may choose not to export the EMSK it is recommended that the AMSKs be combined instead. In this case each mechanism that generates keys must export the appropriate AMSKs. A possible approach to combining AMSKs into a combined application master session key is as follows: EAP-CAMSK_0 = AMSK_0 EAP-CAMSK_n = PRF(EAP-CAMSK_n-1 + AMSK_n, key-label, n) 3.3 Obtaining Keys Implementations of EAP frameworks on the EAP-Peer and EAP-Server MUST provide an interface to obtain AMSKs. The implementation MAY restrict which callers can obtain which keys. 4. Security Considerations 4.1 Key strength The effective key strength of the derived keys will never be greater than the strength of the EMSK (or a master key internal to an EAP mechanism). 4.2 Cryptographic separation of keys The intent of the KDF is to derive keys that are cryptographically separate: the compromise of one of the application master keys (AMSKs) should not compromise the security of other AMSKs or the EMSK. It is believed that the KDF chosen provides the desired separation. 4.3 Implementation An implementation of an EAP framework SHOULD keep the EMSK internally and only provide an interface to KDF for applications to obtain derived keys. It may also choose to restrict which callers have access to which keys. Salowey and Eronen Expires December 2003 [Page 8]
INTERNET-DRAFT EAP Key Derivation June 2003 5. IANA Considerations This specification introduces a new name space for "key labels". Key labels are ASCII strings and are assigned on a first come first served basis. It is RECOMMENDED that a referene to a specification that provides the following information o A description of the application o The key label to be used o How TSKs will be derived from the AMSK and how they will be used o If application specific data is used, what it is and how it is maintained o Where the AMSKs or TSKs will be used and how they are communicated if necessary. References [EAP] Blunk, L., J. Vollbrecht, B. Aboba, J. Carlson, "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-04, February 2003 (work in progress). [EAP-Auth] Grayson, M. and J. Salowey, "EAP Authorization", draft- grayson-eap-authorisation-00, January 2003 (work in progress). [EAP-Key] Aboba, B. and D. Simon, "EAP Keying Framework", draft-aboba- pppext-key-problem-06, December 2002 (work in progress). [PRO-TLV] Salowey, J., "Protected EAP TLV", draft-salowey-eap- protectedtlv-02.txt, January 2003 (work in progress) [IEEE-03-084] Mishra, A., M. Shin, W. Arbaugh, I. Lee, and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03-84r1-I, http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, January 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", RFC 2119, March 1997. Salowey and Eronen Expires December 2003 [Page 9]
INTERNET-DRAFT EAP Key Derivation June 2003 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2409] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. Acknowledgments This document expands upon ideas from conversations with Bernard Aboba, Jari Arkko, and Henry Haverinen. Author's Addresses Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US Phone: +1 206 256 3380 Email: jsalowey@cisco.com Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com Appendix A: Test vectors for KDF <insert test vectors for the KDF here; unfortunately, TLS spec does not include these> Salowey and Eronen Expires December 2003 [Page 10]