Network Working Group INTERNET-DRAFT J. Salowey Document: draft-salowey-eap-key-deriv-02.txt Cisco P. Eronen Nokia Expires: June 2004 November 2003 Guidelines for using the EAP Extended Master Session Key (EMSK) 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. EAP defines an Extended Master Session Key (EMSK) that is reserved. This document provides guidelines for using the EMSK to avoid conflicts between applications requiring different key material. 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..............3 1.2 Cryptographic separation between devices...................3 1.3 Use cases..................................................3 INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 1.4 Motivation.................................................4 1.5 Terminology................................................4 2. Requirements for EAP methods and applications..................5 2.1 Requirements for EAP methods...............................5 2.2 Requirements for EAP applications..........................6 3. EAP AMSK Key Derivation Framework..............................6 3.1 The EAP AMSK Key Derivation Function.......................7 3.2 Naming the EMSK............................................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.............................................9 5. IANA Considerations............................................9 Normative References..............................................9 Informative References............................................9 Acknowledgments..................................................11 Author's Addresses...............................................11 Appendix A: Test vectors for KDF.................................11 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 provides guidelines on how to use this key to derive keys for specific applications. Salowey and Eronen Expires June 2004 [Page 2]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 1.1 Cryptographic separation between applications If the keying material is used to provide keys for multiple applications, it is desired that the keys will be cryptographically separate. Cryptographic separation means that knowledge of one key does not provide an easy way to determine another key derived from the same key material. This is also known as computationally independent. 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. Specifications such as [802.11i] and [MPPE] specify such functions. 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 Not EAP methods. The methods should be independent of the applications their keys will be used for. o Not the application specifications. All applications would have to know what other current and future applications could be used together. This document provides guidelines for a mechanism, which can be used with existing and new EAP methods and applications to provide cryptographic separation between applications. 1.2 Cryptographic separation between devices A related issue is that the keys could be used by separate devices. In this case, it is desirable that their knowledge is cryptographically separate. This implies that some key derivation must be done at the EAP server instead of the authenticator and that authenticator should be sent only keys derived that are derived for it. This means that the EAP server has to know what the keys will be used for, which is a change from the current practice. This document attempts to specify a mechanism that allows the EAP server to derive cryptographically separate keys from the EMSK 1.3 Use cases There are several applications for ciphering keys outside of link layer protection as in 802.11 already being defined. This specification could derive keys to protect credentials distributed to Salowey and Eronen Expires June 2004 [Page 3]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 an EAP peer in a protected TLV [PRO-TLV]. A recent proposals for 802.11 handoff in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],[IEEE-03- 084], and [IEEE-03-155] provide examples where cryptographic separation between different devices was required. To derive cryptographically separate keys for different WLAN access points some of the specifications specify the use of the EMSK. 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 A consumer of EAP keying material. Examples include link layer encryption such as 802.11i encryption, MPPE, etc. Master Session Key (MSK) Salowey and Eronen Expires June 2004 [Page 4]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 Keying material exported by an EAP method. Usually sent to the NAS. Extended Master Session Key (EMSK) Keying material exported by an EAP method for use in deriving keys used by other applications. 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 derived from the EMSK for a particular application as specified in this document. It is 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. This is also known as computationally independent. 2. Requirements for EAP methods and applications 2.1 Requirements for EAP methods In order for an EAP method to meet the guidelines for EMSK usage 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 MSK and TEKs. o The EMSK MUST NOT be used for any other purpose than the key derivation described in this document. o The EMSK MUST be secret and not known to someone observing the authentication mechanism protocol exchange. Salowey and Eronen Expires June 2004 [Page 5]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 o The EMSK MSUT be maintained within the EAP server. Only keys (AMSKs) derived according to this specification may be exported from the EAP server. o The EMSK MUST be unique for each session. o The EAP mechanism SHOULD provide a way of naming the EMSK. 2.2 Requirements for EAP applications In order for an application to meet the guidelines for EMSK usage it must meet the following, o The application MAY use the MSK transmitted to the NAS in any way it chooses. This is required for backward compatibility. New applications following this specification SHOULD NOT use the MSK. If more than one application uses the MSK, then the cryptographic separation is not achieved. Implementations SHOULD prevent such combinations. o The application MUST NOT use the EMSK in any other way except to derive Application Master Session Keys (AMSK) using the key derivation specified in section 3 this document. They MUST NOT use the EMSK directly. o Applications MUST define distinct key labels and application specific data used in the key derivation described in section 3. o Applications MUST define how they use their AMSK to derive TSKs for their use. 3. EAP AMSK Key Derivation Framework The EAP EMSK usage guidelines provide 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 EMSK usage guidelines AMSK key derivation function (KDF) derives an AMSK from the Extended Master Session Key (EMSK) described above, an application key label, optional application data, and output length. AMSK = KDF(EMSK, key label, optional application data, length) Salowey and Eronen Expires June 2004 [Page 6]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 The key labels are printable ASCII strings unique for each application (see Section 5 for IANA Considerations). Additional ciphering keys (TSKs) can be derived from the AMSK using an application specific key derivation mechanism. In many cases, this AMSK->TSK derivation can simply split the AMSK to pieces of correct length. In particular, it is not necessary to use a cryptographic one-way function. Note that the length of the AMSK must be specified by the application. 3.1 The EAP AMSK Key Derivation Function The EAP key derivation function is taken from the PRF+ key expansion PRF from [IKEv2]. This KDF takes 4 parameters as input: secret, label, application data, and output length. It is only defined for 255 iterations so it may produce up to 5100 bytes of key 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, the application data is also described above and the output length is two bytes. The application data is optional and may not be used by some applications. The KDF is based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we have: KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) prf = HMAC-SHA1 K = EMSK L = key label D = application data O = OutputLength (2 bytes) S = L | "\0" | D | O The prf+ construction was chosen because of its simplicity and efficiency over other PRFs such as those used in [TLS]. The motivation for the design of this PRF is described in [SIGMA]. 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 June 2004 [Page 7]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 3.2 Naming the EMSK The EAP mechanism should provide a name for the context that contains the EMSK key material so it can be referenced if needed. If a name is not provided by the mechanism, then a name may be derived from the EMSK using the KDF defined above: EMSK name = KDF(EMSK, "EAP-EMSK-Key name", "", 128 bits) If the name needs to be represented as a string then it should be converted to a lowercase ASCII representation of the hex values of each byte. <This needs a bit more analysis since the name will be public. If the KDF is sound perhaps this shouldnt lead to vulnerabilities, but perhaps it would be better if the name somehow was not a static function of the key. Salt perhaps?> <Maybe this name should be broader than the EMSK, perhaps identifying the whole EAP-MSK.> 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. Salowey and Eronen Expires June 2004 [Page 8]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 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. 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 reference 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. The String "EAP-EMSK-Key name" is reserved for key naming in section 3.2. Normative References [EAP] Blunk, L., J. Vollbrecht, B. Aboba, J. Carlson, "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-06, September 2003 (work in progress). [RFC2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", RFC 2119, March 1997. [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) http://csrc.nist.gov/fips/fip180-1.ps (postscript) [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. Informative References [IKEv2] Salowey and Eronen Expires June 2004 [Page 9]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", <draft- ietf-ipsec-ikev2-06.txt>, 2003 [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", in Advances in Cryptography - CRYPTO 2003 Proceedings, LNCS 2729, Springer, 2003. Available at: http://www.ee.technion.ac.il/~hugo/sigma.html [EAP-Key] Aboba, B. et. al., "EAP Key Management Framework", draft-ietf- eap-keying-00.txt, October 2003 (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. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [MPPE] Zorn, G., "Deriving Keys for use with Microsoft-to-Point Encryption (MPPE)", RFC 3079, March 2001. [80211i] Institute of Electrical and Electronics Engineers, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", IEEE Draft 802.11I/ D6.1, August 2003. Salowey and Eronen Expires June 2004 [Page 10]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003 [I-D.irtf-aaaarch-handoff] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-03 (work in progress), October 2003. [IEEE-03-155] Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, IEEE-03-155r0-I, http://www.ieee802.org/11/Documents/DocumentHolder/3-155.zip, March 2003. 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> Salowey and Eronen Expires June 2004 [Page 11]