EAP Working Group B. Aboba INTERNET-DRAFT D. Simon Category: Standards Track Microsoft J. Arkko 15 November 2004 Ericsson J. Salowey Cisco Systems Extensible Authentication Protocol (EAP) Key Hierarchy By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 June 22, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document specifies the EAP key hierarchy. Aboba, et al. Standards Track [Page 1] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Table of Contents 1. Introduction .......................................... 3 1.1 Requirements Language ........................... 3 1.2 Terminology ..................................... 3 1.3 Overview ........................................ 4 2. EAP Key Hierarchy ..................................... 5 2.1 Key Terminology ................................. 5 2.2 Key Hierarchy ................................... 6 2.3 Key Lifetimes ................................... 8 2.4 Key Names and Scopes ............................ 15 2.5 AAA-Key Derivation .............................. 18 2.6 AMSK Key Derivation ............................. 19 2.7 Key Scope Issues ................................ 20 3. Security Considerations .............................. 22 3.1 Security Terminology ............................ 22 3.2 Threat Model .................................... 22 3.3 EAP Method Requirements ......................... 24 3.4 AAA Protocol Requirements ....................... 27 3.5 Secure Association Protocol Requirements ........ 28 3.6 Ciphersuite Requirements ........................ 30 4. IANA Considerations ................................... 30 5. References ............................................ 31 5.1 Normative References ............................ 31 5.2 Informative References .......................... 32 Acknowledgments .............................................. 35 Author's Addresses ........................................... 36 Appendix A - Ciphersuite Keying Requirements ................. 37 Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 38 Appendix C - EAP-TLS Key Hierarchy ........................... 39 Appendix D - Example Transient Session Key (TSK) Derivation .. 41 Appendix E - Key Names and Scope in Existing Methods ......... 42 Intellectual Property Statement .............................. 43 Disclaimer of Validity ....................................... 43 Copyright Statement .......................................... 43 Aboba, et al. Standards Track [Page 2] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 1. Introduction The Extensible Authentication Protocol (EAP), defined in [RFC3748], was designed to enable extensible authentication for network access in situations in which the IP protocol is not available. Originally developed for use with PPP [RFC1661], it has subsequently also been applied to IEEE 802 wired networks [IEEE8021X]. This document specifies the generation and usage of keying material generated by EAP authentication algorithms, known as "methods". In EAP keying material is generated by EAP methods. Part of this keying material may be used by EAP methods themselves and part of this material may be exported. The exported keying material may be transported by AAA protocols or transformed by Secure Association Protocols into session keys which are used by lower layer ciphersuites. 1.1. Requirements Language 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 BCP 14 [RFC2119]. 1.2. Terminology This document frequently uses the following terms: authenticator The end of the link initiating EAP authentication. The term Authenticator is used in [IEEE-802.1X], and authenticator has the same meaning in this document. peer The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant. Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. In this document, this end of the link is called the peer. backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X]. AAA Authentication, Authorization and Accounting. AAA protocols with EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- Aboba, et al. Standards Track [Page 3] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 eap]. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably. EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. security association A set of policies and cryptographic state used to protect information. Elements of a security association may include cryptographic keys, negotiated ciphersuites and other parameters, counters, sequence spaces, authorization attributes, etc. 1.3. Overview EAP is typically deployed in order to support extensible network access authentication in situations where a peer desires network access via one or more authenticators. Since both the peer and authenticator may have more than one physical or logical port, a given peer may simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator may offer network access to multiple peers, each via a separate physical or logical port. Where authenticators are deployed standalone, the EAP conversation occurs between the peer and authenticator, and the authenticator must locally implement an EAP method acceptable to the peer. However, one of the advantages of EAP is that it enables deployment of new authentication methods without requiring development of new code on the authenticator. While the authenticator may implement some EAP methods locally and use those methods to authenticate local users, it may at the same time act as a pass-through for other users and methods, forwarding EAP packets back and forth between the backend authentication server and the peer. This is accomplished by encapsulating EAP packets within the Authentication, Authorization and Accounting (AAA) protocol, spoken between the authenticator and backend authentication server. AAA protocols supporting EAP include RADIUS [RFC3579] and Diameter [I- D.ietf-aaa-eap]. 2. EAP Key Hierarchy Aboba, et al. Standards Track [Page 4] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 2.1. Key Terminology The EAP Key Hierarchy makes use of the following types of keys: Long Term Credential EAP methods frequently make use of long term secrets in order to enable authentication between the peer and server. In the case of a method based on pre-shared key authentication, the long term credential is the pre-shared key. In the case of a public-key based method, the long term credential is the corresponding private key. Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. Extended Master Session Key (EMSK) Additional keying material derived between the peer and server that is exported by the EAP method. The EMSK is at least 64 octets in length, and is never shared with a third party. AAA-Key A key derived by the peer and EAP server, used by the peer and authenticator in the derivation of Transient Session Keys (TSKs). Where a backend authentication server is present, the AAA-Key is transported from the backend authentication server to the authenticator, wrapped within the AAA-Token; it is therefore known by the peer, authenticator and backend authentication server. Despite the name, the AAA-Key is computed regardless of whether a backend authentication server is present. AAA-Key derivation is discussed in Section 2.5; in existing implementations the MSK is used as the AAA-Key. Application-specific Master Session Keys (AMSKs) Keys derived from the EMSK which are cryptographically separate from each other and may be subsequently used in the derivation of Transient Session Keys (TSKs) for extended uses. AMSK derivation is discussed in Section 2.6. AAA-Token Where a backend server is present, the AAA-Key and one or more attributes is transported between the backend authentication server and the authenticator within a package known as the AAA-Token. The format and wrapping of the AAA-Token, which is intended to be accessible only to the backend authentication server and authenticator, is defined by the AAA protocol. Examples include RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. Aboba, et al. Standards Track [Page 5] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Initialization Vector (IV) A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the peer and EAP server. Since the IV is a known value in methods such as EAP- TLS [RFC2716], it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and EAP methods are not required to generate it. However, when it is generated it MUST be unpredictable. Pairwise Master Key (PMK) The AAA-Key is divided into two halves, the "Peer to Authenticator Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer Encryption Key" (Enc-SEND-Key) (reception is defined from the point of view of the authenticator). Within [IEEE80211i] Octets 0-31 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key (PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive their Transient Session Keys (TSKs) solely from the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives its TSKs from both halves of the AAA-Key. Transient EAP Keys (TEKs) Session keys which are used to establish a protected channel between the EAP peer and server during the EAP authentication exchange. The TEKs are appropriate for use with the ciphersuite negotiated between EAP peer and server for use in protecting the EAP conversation. Note that the ciphersuite used to set up the protected channel between the EAP peer and server during EAP authentication is unrelated to the ciphersuite used to subsequently protect data sent between the EAP peer and authenticator. An example TEK key hierarchy is described in Appendix C. Transient Session Keys (TSKs) Session keys used to protect data exchanged between the peer and the authenticator after the EAP authentication has successfully completed. TSKs are appropriate for the lower layer ciphersuite negotiated between the EAP peer and authenticator. Examples of TSK derivation are provided in Appendix D. 2.2. Key Hierarchy The EAP Key Hierarchy, illustrated in Figure 1, has at the root the long term credential utilized by the selected EAP method. If authentication is based on a pre-shared key, the parties store the EAP method to be used and the pre-shared key. The EAP server also stores the peer's identity and/or other information necessary to decide whether access to some service should be granted. The peer stores information necessary to choose which secret to use for which service. Aboba, et al. Standards Track [Page 6] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 If authentication is based on proof of possession of the private key corresponding to the public key contained within a certificate, the parties store the EAP method to be used and the trust anchors used to validate the certificates. The EAP server also stores the peer's identity and/or other information necessary to decide whether access to some service should be granted. The peer stores information necessary to choose which certificate to use for which service. Based on the long term credential established between the peer and the server, EAP derives two types of keys: [1] Keys calculated locally by the EAP method but not exported by the EAP method, such as the TEKs. [2] Keys exported by the EAP method: MSK, EMSK, IV From the keys exported by the EAP method, two other types of keys may be derived: [3] Keys calculated from exported quantities: AAA-Key, AMSKs. [4] Keys calculated by the Secure Association Protocol from the AAA-Key or AMSKs: TSKs. In order to protect the EAP conversation, methods supporting key derivation typically negotiate a ciphersuite and derive Transient EAP Keys (TEKs) for use with that ciphersuite. The TEKs are stored locally by the EAP method and are not exported. As noted in [RFC3748] Section 7.10, EAP methods generating keys are required to calculate and export the MSK and EMSK, which must be at least 64 octets in length. EAP methods also may export the IV; however, the use of the IV is deprecated. On both the peer and EAP server, the exported MSK and keys derived from the AMSK are utilized in order to calculate the AAA-Key, as described in Section 2.5. Where a backend authentication server is present, the AAA-Key is transported from the backend authentication server to the authenticator within the AAA-Token, using the AAA protocol. Once EAP authentication completes and is successful, the peer and authenticator obtain the AAA-Key and the Secure Association Protocol is run between the peer and authenticator in order to securely negotiate the ciphersuite, derive fresh TSKs used to protect data, and provide mutual proof of possession of the AAA-Key. When the authenticator acts as an endpoint of the EAP conversation rather than a pass-through, EAP methods are implemented on the Aboba, et al. Standards Track [Page 7] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 authenticator as well as the peer. If the EAP method negotiated between the EAP peer and authenticator supports mutual authentication and key derivation, the EAP Master Session Key (MSK) and Extended Master Session Key (EMSK) are derived on the EAP peer and authenticator and exported by the EAP method. In this case, the MSK and EMSK are known only to the peer and authenticator and no other parties. The TEKs and TSKs also reside solely on the peer and authenticator. This is illustrated in Figure 2. As demonstrated in [I-D.ietf-roamops-cert], in this case it is still possible to support roaming between providers, using certificate-based authentication. Where a backend authentication server is utilized, the situation is illustrated in Figure 3. Here the authenticator acts as a pass- through between the EAP peer and a backend authentication server. In this model, the authenticator delegates the access control decision to the backend authentication server, which acts as a Key Distribution Center (KDC). In this case, the authenticator encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the backend authentication server, which acts as the EAP server. Since the authenticator acts as a pass-through, EAP methods reside only on the peer and EAP server As a result, the TEKs, MSK and EMSK are derived on the peer and EAP server. On completion of EAP authentication, EAP methods on the peer and EAP server export the Master Session Key (MSK) and Extended Master Session Key (EMSK). The peer and EAP server then calculate the AAA- Key from the MSK and EMSK, and the backend authentication server sends an Access-Accept to the authenticator, providing the AAA-Key within a protected package known as the AAA-Token. The AAA-Key is then used by the peer and authenticator within the Secure Association Protocol to derive Transient Session Keys (TSKs) required for the negotiated ciphersuite. The TSKs are known only to the peer and authenticator. 2.3. Key Lifetimes Key lifetime issues are discussed in the sections that follow. Issues include: [a] Key lifetime negotiation. Where key lifetimes cannot be assumed, it may be necessary to negotiate them. Where negotiation is supported, it is RECOMMENDED that the negotiation be secured. Note that key lifetime negotiation may not always be required. A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA Aboba, et al. Standards Track [Page 8] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 when necessary. [b] Key resynchronization. It is possible for the peer or authenticator to reboot or reclaim resources, clearing portions or all of the key cache. Therefore, key lifetime negotiation cannot guarantee that the key cache will remain synchronized, and the peer may not be able to determine before attempting to use it whether a particular key exists within the authenticator cache. It is therefore RECOMMENDED for the lower layer to provide a mechanism for key state resynchronization. Since in this situation one or more of the parties initially do not possess a key with which to protect the resynchronization exchange, securing this mechanism may be difficult. 2.3.1. Parent-child relationships When keying material exported by EAP methods expires, all keying material derived from the exported keying material, (including the AAA-Key, AMSKs and TSKs) also expires. Similarly, when an EAP reauthentication takes place, new keying material is derived and exported by the EAP method, which eventually results in replacement of calculated keys, including the AAA-Key, AMSKs, and TSKs. As a result, the lifetime of keys calculated from the exported keying material can be no longer than the lifetime of the exported keying material itself. However, the lifetime of calculated keys can be less than that of the exported keys. For example, TSK rekey may occur prior to EAP reauthentication. Note that deletion of the AAA-Key does not necessarily imply deletion of the corresponding TSKs. Replacement or deletion of TSKs only implies replacement of the AAA-Key when the TSKs are taken from a portion of the AAA-Key. Failure to mutually prove possession of the AAA-Key during the Secure Association Protocol exchange need not be grounds for deletion of the AAA-Key by both parties; rate-limiting Secure Association Protocol exchanges could be used to prevent a brute force attack. Aboba, et al. Standards Track [Page 9] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | EAP Method | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | | | | | | | | EAP Method Key |<->| Long-Term | | | | | Derivation | | Credential | | | | | | | | | | | | | +-+-+-+-+-+-+-+ | Local to | | | | | EAP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | | | | | | | | | | | | | | | | | | | | | | | | | | V | | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | TEK | | MSK | |EMSK | |IV | | | | |Derivation | |Derivation | |Derivation | |Derivation | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | | | | | | | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | | ^ | | | | | MSK (64B) | EMSK (64B) | IV (64B) | | | | Exported| | | | by | V V V EAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| | AAA Key Derivation, | | Known | | | Naming & Binding | |(Not Secret) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V | ---+ | AAA-Key/ Transported | | Name by AAA | | Protocol | V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | TSK Derivation | Lower layer | | [AAA-Key Cache] | Specific | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ Figure 1: EAP Key Hierarchy Aboba, et al. Standards Track [Page 10] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ | | | | | |===============| | | |EAP, TEK Deriv.|Authenti-| | |<------------->| cator | | | | | | | Secure Assoc. | | | peer |<------------->| (EAP | | |===============| server) | | | Link layer | | | | (PPP,IEEE802) | | | | | | |MSK,EMSK | |MSK,EMSK | | AAA-Key/| | AAA-Key/| | Name | | Name | | (TSKs) | | (TSKs) | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | MSK, EMSK | MSK, EMSK | | | | +-+-+-+-+-+ +-+-+-+-+-+ | | | | | EAP | | EAP | | Method | | Method | | | | | | (TEKs) | | (TEKs) | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 2: Relationship between EAP peer and authenticator (acting as an EAP server), where no backend authentication server is present. Aboba, et al. Standards Track [Page 11] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | |===============| |========| | | |EAP, TEK Deriv.| | | | | |<-------------------------------->| backend | | | | |AAA-Key/| | | | Secure Assoc. | | Name | | | peer |<------------->|Authenti-|<-------| auth | | |===============| cator |========| server | | | Link Layer | | AAA | (EAP | | | (PPP,IEEE 802)| |Protocol| server) | |MSK,EMSK | | | | | | AAA-Key/| | AAA-Key/| |MSK,EMSK,| | Name | | Name | | AAA-Key/| | (TSKs) | | (TSKs) | | Name | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | MSK, EMSK | MSK, EMSK | | | | +-+-+-+-+-+ +-+-+-+-+-+ | | | | | EAP | | EAP | | Method | | Method | | | | | | (TEKs) | | (TEKs) | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 3: Pass-through relationship between EAP peer, authenticator and backend authentication server. 2.3.2. Local Key Lifetimes The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are Aboba, et al. Standards Track [Page 12] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 not exported. TEKs are typically created during an EAP conversation, used until the end of the conversation and then discarded. However, methods may rekey TEKs during a conversation. When using TEKs within an EAP conversation or across conversations, it is necessary to ensure that replay protection and key separation requirements are fulfilled. For instance, if a replay counter is used, TEK rekey MUST occur prior to wrapping of the counter. Similarly, TSKs MUST remain cryptographically separate from TEKs despite TEK rekeying or caching. This prevents TEK compromise from leading directly to compromise of the TSKs and vice versa. EAP methods may cache local keying material which may persist for multiple EAP conversations when fast reconnect is used [RFC 3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local keying material calculated within the EAP method is defined by the method. Note that in general, when using fast reconnect, there is no guarantee to that the original long-term credentials are still in the possession of the peer. For instance, a card hold holding the private key for EAP-TLS may have been removed. EAP servers should verify that the long-term credentials are still valid, such as by checking that certificate used in the original authentication has not yet expired. 2.3.3. Exported and Calculated Key Lifetimes All EAP methods generating keys are required to generate the MSK and EMSK, and may optionally generate the IV. Existing EAP methods do not negotiate the lifetime of the exported keys. EAP, defined in [RFC3748], also does not support the negotiation of lifetimes for exported keying material such as the MSK, EMSK and IV. Several mechanisms exist for managing key lifetimes: [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and Diameter [DiamEAP] support the Session-Timeout attribute. The Session-Timeout value represents the maximum lifetime of the exported keys, and all keys calculated from it, in all circumstances. The AAA server MUST expire the exported keys, and all keys calculated from them, prior to the future time indicated by Session-Timeout. On the authenticator, where EAP is used for authentication, the Session-Timeout value represents the maximum session time prior to re-authentication, as described in [RFC3580]. Where EAP is used for pre-authentication, the session may not start until some future time, or may never occur. Nevertheless, the Session-Timeout value represents the time after which the AAA-Key, and all keys calculated from it, will have expired on the Aboba, et al. Standards Track [Page 13] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 authenticator. If the session subsequently starts, re- authentication will be initiated once the Session-Time has expired. If the session never started, or started and ended, the AAA-Key and all keys calculated from it will be expired by the authenticator prior to the future time indicated by Session-Timeout. Since the TSK lifetime is often determined by authenticator resources, the AAA server has no insight into the TSK derivation process, and by the principle of ciphersuite independence, it is not appropriate for the AAA server to manage any aspect of the TSK derivation process, including the TSK lifetime. [b] Lower layer mechanisms. While AAA attributes can communicate the maximum exported key lifetime, this only serves to synchronize the key lifetime between the backend authentication server and the authenticator. Lower layer mechanisms can then be used to enable the lifetime of exported and calculated keys to be negotiated between the peer and authenticator. Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include secure negotiation of the TSK lifetime between the peer and authenticator. Where the TSK is taken from the AAA-Key, there is no need to manage the TSK lifetime as a separate parameter, since the TSK lifetime and AAA-Key lifetime are identical. [c] System defaults. Where the EAP method does not support the negotiation of the exported key lifetime, and a negotiation mechanism is not provided by the lower lower, there may be no way for the peer to learn knowledge of the exported key liftime. In this case it is RECOMMENDED that the peer assume a default value of the exported key lifetime; 8 hours is suggested. Similarly, the lifetime of calculated keys can also be managed as a system parameter on the authenticator. 2.3.4. Key cache synchronization Issues arise when attempting to synchronize the key cache on the peer and authenticator. Lifetime negotiation alone cannot guarantee key cache synchronization. One problem is that the AAA protocol cannot guarantee synchronization of key lifetimes between the peer and authenticator. Where the Secure Association Protocol is not run immediately after EAP authentication, the exported and calculated key lifetimes will not be known by the peer during the hiatus. Where EAP pre-authentication occurs, this can leave the peer uncertain whether a subsequent Aboba, et al. Standards Track [Page 14] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 attempt to use the exported keys will prove successful. However, even where the Secure Association Protocol is run immediately after EAP, it is still possible for the authenticator to reclaim resources if the created key state is not immediately utilized. The lower layer may utilize Discovery mechanisms to assist in this. For example, the authenticator manages the AAA-Key cache by deleting the oldest AAA-Key first (LIFO), the relative creation time of the last AAA-Key to be deleted could be advertised with the Discovery phase, enabling the peer to determine whether a given AAA-Key had been expired from the authenticator key cache prematurely. 2.4. Key Names and Scopes Each key created within the EAP key management framework has a name (the identifier by which the key can be identified), as well as a scope (the parties to whom the key is available). This section describes how keys are named, and the scope within which that name applies. Session-Id EAP methods supporting key naming MUST specify a temporally unique method identifier known as the EAP Method-Id, which is typically constructed from nonces or counters used within the exchange. Since multiple EAP sessions may exist between an EAP peer and EAP server, the Method-Id allows MSKs to be differentiated. The combination of the EAP Type and the Method-Id is known as the EAP Session-Id. The inclusion of the Type in the EAP Session-Id ensures that each EAP method has a distinct name space. The EAP Session-Id uniquely identifies the EAP session to the EAP peer and server terminating the EAP conversation. However, suitable EAP peer and server names may not always be available. As described in [RFC3748] Section 7.3, the identity provided in the EAP- Response/Identity, may be different from the identity authenticated by the EAP method, and as a result the EAP-Response/Identity is unsuitable for determination of the peer identity. As a result, the Session-Id scope is defined by the EAP peer name (if securely exchanged within the method) concatenated with the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used. Since an EAP session is not bound to a particular authentication or specific ports on the peer and authenticator, the authenticator port or identity are not included in the Session-Id scope. Aboba, et al. Standards Track [Page 15] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 The EAP Session-Id is exported by the EAP method along with the Session-Id scope, if available, and is used to construct names for other EAP keys. Note that the EAP Session-Id and scope are only known by the EAP method. As a result, the format of the EAP Session- Id and the definition of the Session-Id scope needs to be specified within the method. Appendix E defines the EAP Session-Id and scope provided by existing methods. MSK Name This key is created between the EAP peer and EAP server, and can be referred to using the string "MSK" and the EAP Session-Id. As with the EAP Session-Id, the MSK scope is defined by the EAP peer name (if securely exchanged within the method) and the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used. EMSK Name The EMSK can be referred to using the string "EMSK" and the EAP Session-Id. As with the EAP Session-Id, the EMSK scope is defined by the EAP peer name (if securely exchanged within the method) and the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used. AMSK Name AMSKs, if any, can be referred to using the string "AMSK", the key label, application data (see Section 2.6) and the EAP Session-Id. As with the EAP Session-Id, the AMSK scope is defined by the EAP peer name (if securely exchanged within the method) and the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used. AAA-Key Name The AAA-Key is derived from either the MSK or AMSK and so can be referred to using the MSK or AMSK names. The AAA-Key scope is provided by the concatenation of the EAP peer name (if securely provided to the authenticator), and the authenticator name (if securely provided to the peer). For the purpose of identifying the authenticator to the peer, the value of the NAS-Identifier attribute is recommended. The Aboba, et al. Standards Track [Page 16] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 authenticator may include the NAS-Identifier attribute to the AAA server in an Access-Request, and the authenticator may provide the NAS-Identifier (unsecured) to the EAP peer in the EAP- Request/Identity or via a lower layer mechanism (such as the 802.11 Beacon/Probe Response). Where the NAS-Identifier is provided by the authenticator to the peer a secure mechanism is RECOMMENDED. For the purpose of identifying the peer to the authenticator, the EAP peer identifier provided within the EAP method is recommended. It cannot be assumed that the authenticator is aware of the EAP peer name used within the method. Therefore alternatives mechanisms need to be used to provide the EAP peer name to the authenticator. For example, the AAA server may include the EAP peer name in the User- Name attribute of the Access-Accept or the peer may provide the authenticator with its name via a lower layer mechanism. Absent an explicit binding step within the Secure Association Protocol, the AAA-Key is not bound to a specific peer or authenticator port. As a result, the peer or authenticator port over which the EAP conversation takes place is not included in the AAA-Key scope. PMK Name This document does not specify a naming scheme for the PMK. The PMK is only identified by the AAA-Key from which it is derived. Similarly, the PMK scope is the same as the AAA-Key scope. Note: IEEE 802.11i names the PMKID for the purposes of being able to refer to it in the Secure Association protocol; this naming is based on a hash of the PMK itself as well as some other parameters (see Section 8.5.1.2 [IEEE80211i]). TEKs The TEKs may or may not be named. Their naming is specified in the EAP method. Since the TEKs are only known by the EAP peer and server, the TEK scope is the same as the Session-Id scope. TSKs The TSKs are typically named. Their naming is specified in the Secure Association (phase 2) protocol, so that the correct set of transient session keys can be identified for processing a given packet. The scope of the TSKs is negotiated within the Secure Association Protocol. TSK creation and deletion operations are typically supported so that Aboba, et al. Standards Track [Page 17] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 establishment and re-establishment of TSKs can be synchronized between the parties. In order to avoid confusion in the case where an EAP peer has more than one AAA-Key (phase 1b) applicable to establishment of a phase 2 security association, the secure Association protocol needs to utilize the AAA-Key name so that the appropriate phase 1b keying material can be identified for use in the Secure Association Protocol exchange. 2.5. AAA-Key Derivation Where a AAA-Key is generated as the result of a successful EAP authentication with the authenticator A, the AAA-Key is based on the MSK: AAA-Key = MSK(0,63). As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], [IEEE-03-084], and [8021XHandoff], keying material may be required for use in fast handoff between authenticators. Where the backend authentication server provides keying material to additional authenticators in order to facilitate fast handoff, it is highly desirable for the keying material used on different authenticators B, C to be cryptographically separate, so that if one authenticator is compromised, it does not lead to the compromise of other authenticators. Where keying material is provided by the backend authentication server, a key hierarchy derived from the AMSK can be used to provide cryptographically separate keying material for use in fast handoff. Instead of using the EMSK directly an application specific key (AMSK) is derived as described in Section 2.6: AAA-Key = MSK(0,63) AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments", length) AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key, B-Called-Station-Id, Calling-Station-Id,length) AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments",AAA-Key, C-Called-Station-Id, Calling-Station-Id, length) Where: Calling-Station-Id = STA MAC address B-Called-Station-Id = AP B MAC address C-Called-Station-Id = AP C MAC address prf = HMAC-SHA1 Aboba, et al. Standards Track [Page 18] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 KDF = defined in Section 2.6 length = length of derived key material Here AAA-Key is derived during the initial EAP authentication between the peer and authenticator A. Based on this initial EAP authentication, an AMSK is also derived, which can be used to derive AAA-Keys for fast authentication between the EAP peer and authenticators B and C. Since the AMSK is cryptographically separate from the MSK, each of these AAA-Keys is cryptographically separate from each other, and are guaranteed to be unique between the EAP peer (also known as the STA) and the authenticator (also known as the AP). 2.6. AMSK Key Derivation The EAP AMSK key derivation function (KDF) derives an AMSK from the Extended Master Session Key (EMSK), an application key label, optional application data, and output length. AMSK = KDF(EMSK, key label, optional application data, length) The key labels are printable ASCII strings unique for each application (see Section 7 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. The length of the AMSK MUST be specified by the application. The AMSK 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. Application data MAY be an empty string. 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) Aboba, et al. Standards Track [Page 19] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 T4 = prf (K, T3 | S | 0x04) prf = HMAC-SHA1 K = EMSK L = key label D = application data O = OutputLength (2 bytes) S = L | " " | 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. Where another prf needs to be negotiated, this can be handled within the EAP method. 2.7. Key Scope Issues As described in Section 2.5, the AAA-Key is calculated from the EMSK and MSK by the EAP peer and server, and is used as the root of the ciphersuite-specific key hierarchy. Where a backend authentication server is present, the AAA-Key is transported from the EAP server to the authenticator; where it is not present, the AAA-Key is calculated on the authenticator. Regardless of how many sessions are initiated using it, the AAA-Key scope is between the EAP peer that calculates it, and the authenticator that either calculates it (where no backend authenticator is present) or receives it from the server (where a backend authenticator server is present). It should be understood that an authenticator or peer: [a] may contain multiple physical ports; [b] may advertise itself as multiple "virtual" authenticators or peers; [c] may utilize multiple CPUs; [d] may support clustering services for load balancing or failover. As illustrated in Figure 1, an EAP peer with multiple ports may be attached to one or more authenticators, each with multiple ports. Where the peer and authenticator identify themselves using a port Aboba, et al. Standards Track [Page 20] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 identifier such as a link layer address, it may not be obvious to the peer which authenticator ports are associated with which authenticators. Similarly, it may not be obvious to the authenticator which peer ports are associated with which peers. As a result, the peer and authenticator may not be able to determine the scope of the AAA-Key. When a single physical authenticator advertises itself as multiple "virtual authenticators", the EAP peer and authenticator also may not be able to agree on the scope of the AAA-Key, creating a security vulnerability. For example, the peer may assume that the "virtual authenticators" are distinct and do not share a key cache, whereas, depending on the architecture of the physical AP, a shared key cache may or may not be implemented. Where the AAA-Key is shared between "virtual authenticators" an attacker acting as a peer could authenticate with the "Guest" "virtual authenticator" and derive a AAA-Key. If the virtual authenticators share a key cache, then the peer can utilize the AAA- Key derived for the "Guest" network to obtain access to the "Corporate Intranet" virtual authenticator. Several measures are recommended to address these issues: [a] Authenticators are REQUIRED to cache associated authorizations along with the AAA-Key and apply authorizations consistently. This ensures that an attacker cannot obtain elevated privileges even where the AAA-Key cache is shared between "virtual authenticators". [b] It is RECOMMENDED that physical authenticators maintain separate AAA-Key caches for each "virtual authenticator". [c] It is RECOMMENDED that each "virtual authenticator" identify itself distinctly to the AAA server, such as by utilizing a distinct NAS- identifier attribute. This enables the AAA server to utilize a separate credential to authenticate each "virtual authenticator". [d] It is RECOMMENDED that Secure Association Protocols identify peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures. Using port-specific MAC addresses as identifiers is NOT RECOMMENDED where peers and authenticators may support multiple ports. [e] The AAA server and authenticator MAY implement additional attributes in order to further restrict the AAA-Key scope. For example, in 802.11, the AAA server may provide the authenticator with a list of authorized Called or Calling-Station-Ids and/or SSIDs for which the AAA-Key is valid. Aboba, et al. Standards Track [Page 21] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 [f] Where the AAA server provides attributes restricting the key scope, it is RECOMMENDED that restrictions be securely communicated by the authenticator to the peer. This is typically accomplished using the Secure Association Protocol, but also can be accomplished via the EAP method or the lower layer. 3. Security Considerations 3.1. Security Terminology "Cryptographic binding", "Cryptographic separation", "Key strength" and "Mutual authentication" are defined in [RFC3748] and are used with the same meaning here. 3.2. Threat Model The EAP threat model is described in [RFC3748] Section 7.1. In order to address these threats, EAP relies on the security properties of EAP methods (known as "security claims", described in [RFC3784] Section 7.2.1). EAP method requirements for application such as Wireless LAN authentication are described in [WLANREQ]. The RADIUS threat model is described in [RFC3579] Section 4.1, and responses to these threats are described in [RFC3579] Sections 4.2 and 4.3. Among other things, [RFC3579] Section 4.2 recommends the use of IPsec ESP with non-null transform to provide per-packet authentication and confidentiality, integrity and replay protection for RADIUS/EAP. Given the existing documentation of EAP and AAA threat models and responses, there is no need to duplicate that material here. However, there are many other system-level threats no covered in these document which have not been described or analyzed elsewhere. These include: [1] An attacker may try to modify or spoof Secure Association Protocol packets. [2] An attacker compromising an authenticator may provide incorrect information to the EAP peer and/or server via out-of-band mechanisms (such as via a AAA or lower layer protocol). This includes impersonating another authenticator, or providing inconsistent information to the peer and EAP server. [3] An attacker may attempt to perform downgrading attacks on the ciphersuite negotiation within the Secure Association Protocol in order to ensure that a weaker ciphersuite is used to protect data. Aboba, et al. Standards Track [Page 22] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Depending on the lower layer, these attacks may be carried out without requiring physical proximity. In order to address these threats, [Housley56] describes the mandatory system security properties: Algorithm independence Wherever cryptographic algorithms are chosen, the algorithms must be negotiable, in order to provide resilient against compromise of a particular algorithm. Algorithm independence must be demonstrated within all aspects of the system, including within EAP, AAA and the Secure Association Protocol. However, for interoperability, at least one suite of algorithms MUST be implemented. Strong, fresh session keys Session keys must be demonstrated to be strong and fresh in all circumstances, while at the same time retaining algorithm independence. Replay protection All protocol exchanges must be replay protected. This includes exchanges within EAP, AAA, and the Secure Association Protocol. Authentication All parties need to be authenticated. The confidentiality of the authenticator must be maintained. No plaintext passwords are allowed. Authorization EAP peer and authenticator authorization must be performed. Session keys Confidentiality of session keys must be maintained. Ciphersuite negotiation The selection of the "best" ciphersuite must be securely confirmed. Unique naming Session keys must be uniquely named. Domino effect Compromise of a single authenticator cannot compromise any other part of the system, including session keys and long-term secrets. Key binding The key must be bound to the appropriate context. Aboba, et al. Standards Track [Page 23] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 The following sections summarize the security requirements that must be met by EAP methods, AAA protocols, Secure Association Protocols and Ciphersuites in order to address the security threats. These requirements MUST be met by specifications requesting publication as an RFC. Each requirement provides a pointer to the sections of this document describing the threat that it mitigates. 3.3. EAP Method Requirements It is possible for the peer and EAP server to mutually authenticate and derive keys. In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server. The MSK and EMSK MUST NOT be used directly to protect data; however, they are of sufficient size to enable derivation of a AAA-Key subsequently used to derive Transient Session Keys (TSKs) for use with the selected ciphersuite. Each ciphersuite is responsible for specifying how to derive the TSKs from the AAA-Key. The AAA-Key is derived from the keying material exported by the EAP method (MSK and EMSK). This derivation occurs on the AAA server. In many existing protocols that use EAP, the AAA-Key and MSK are equivalent, but more complicated mechanisms are possible (see Section 2.5 for details). EAP methods SHOULD ensure the freshness of the MSK and EMSK even in cases where one party may not have a high quality random number generator. A RECOMMENDED method is for each party to provide a nonce of at least 128 bits, used in the derivation of the MSK and EMSK. EAP methods export the MSK and EMSK and not Transient Session Keys so as to allow EAP methods to be ciphersuite and media independent. Keying material exported by EAP methods MUST be independent of the ciphersuite negotiated to protect data. Depending on the lower layer, EAP methods may run before or after ciphersuite negotiation, so that the selected ciphersuite may not be known to the EAP method. By providing keying material usable with any ciphersuite, EAP methods can used with a wide range of ciphersuites and media. It is RECOMMENDED that methods providing integrity protection of EAP packets include coverage of all the EAP header fields, including the Code, Identifier, Length, Type and Type-Data fields. Aboba, et al. Standards Track [Page 24] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 In order to preserve algorithm independence, EAP methods deriving keys SHOULD support (and document) the protected negotiation of the ciphersuite used to protect the EAP conversation between the peer and server. This is distinct from the ciphersuite negotiated between the peer and authenticator, used to protect data. The strength of Transient Session Keys (TSKs) used to protect data is ultimately dependent on the strength of keys generated by the EAP method. If an EAP method cannot produce keying material of sufficient strength, then the TSKs may be subject to brute force attack. In order to enable deployments requiring strong keys, EAP methods supporting key derivation SHOULD be capable of generating an MSK and EMSK, each with an effective key strength of at least 128 bits. Methods supporting key derivation MUST demonstrate cryptographic separation between the MSK and EMSK branches of the EAP key hierarchy. Without violating a fundamental cryptographic assumption (such as the non-invertibility of a one-way function) an attacker recovering the MSK or EMSK MUST NOT be able to recover the other quantity with a level of effort less than brute force. Non-overlapping substrings of the MSK MUST be cryptographically separate from each other. That is, knowledge of one substring MUST NOT help in recovering some other non-overlapping substring without breaking some hard cryptographic assumption. This is required because some existing ciphersuites form TSKs by simply splitting the AAA-Key to pieces of appropriate length. Likewise, non-overlapping substrings of the EMSK MUST be cryptographically separate from each other, and from substrings of the MSK. The EMSK MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used for purposes other than AMSK derivation (see Section 2.6). Since EAP does not provide for explicit key lifetime negotiation, EAP peers, authenticators and authentication servers MUST be prepared for situations in which one of the parties discards key state which remains valid on another party. The development and validation of key derivation algorithms is difficult, and as a result EAP methods SHOULD reuse well established and analyzed mechanisms for MSK and EMSK key derivation (such as those specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. Aboba, et al. Standards Track [Page 25] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 3.3.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 computationally 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. o The EMSK MUST NOT be exported from 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 a unique identifier suitable for naming the EMSK. Implementations of EAP frameworks on the EAP-Peer and EAP-Server SHOULD provide an interface to obtain AMSKs. The implementation MAY restrict which callers can obtain which keys. 3.3.2. Requirements for EAP applications In order for an application to meet the guidelines for EMSK usage it must meet the following requirements: o 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 A peer MUST NOT use the EMSK in any other way except to derive Application Master Session Keys (AMSKs) using the key derivation specified in Section 2.6. It MUST NOT use the EMSK directly for cryptographic protection of data, and SHOULD provide only the AMSKs to applications. o Applications MUST define distinct key labels, application specific data, and the length of derived key material used in the key derivation described in Section 2.6. Aboba, et al. Standards Track [Page 26] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 o Applications MUST define how they use their AMSK to derive TSKs for their use. 3.4. AAA Protocol Requirements AAA protocols suitable for use in transporting EAP MUST provide the following facilities: Security services AAA protocols used for transport of EAP keying material MUST implement and SHOULD use per-packet integrity and authentication, replay protection and confidentiality. These requirements are met by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec [RFC3579]. Session Keys AAA protocols used for transport of EAP keying material MUST implement and SHOULD use dynamic key management in order to derive fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and RADIUS over IPsec [RFC3579], rather than using a static key, as originally defined in RADIUS [RFC2865]. Mutual authentication AAA protocols used for transport of EAP keying material MUST provide for mutual authentication between the authenticator and backend authentication server. These requirements are met by Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579]. Authorization AAA protocols used for transport of EAP keying material SHOULD provide protection against rogue authenticators masquerading as other authenticators. This can be accomplished, for example, by requiring that AAA agents check the source address of packets against the origin attributes (Origin-Host AVP in Diameter, NAS-IP- Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details, see [RFC3579] Section 4.3.7. Key transport Since EAP methods do not export Transient Session Keys (TSKs) in order to maintain media and ciphersuite independence, the AAA server MUST NOT transport TSKs from the backend authentication server to authenticator. Key transport specification In order to enable backend authentication servers to provide keying material to the authenticator in a well defined format, AAA protocols suitable for use with EAP MUST define the format and wrapping of the AAA-Token. Aboba, et al. Standards Track [Page 27] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 EMSK transport Since the EMSK is a secret known only to the backend authentication server and peer, the AAA-Token MUST NOT transport the EMSK from the backend authentication server to the authenticator. AAA-Token protection To ensure against compromise, the AAA-Token MUST be integrity protected, authenticated, replay protected and encrypted in transit, using well-established cryptographic algorithms. Session Keys The AAA-Token SHOULD be protected with session keys as in Diameter [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, as in [RFC2548]. Key naming In order to ensure against confusion between the appropriate keying material to be used in a given Secure Association Protocol exchange, the AAA-Token SHOULD include explicit key names and context appropriate for informing the authenticator how the keying material is to be used. Key Compromise Where untrusted intermediaries are present, the AAA-Token SHOULD NOT be provided to the intermediaries. In Diameter, handling of keys by intermediaries can be avoided using Redirect functionality [RFC3588]. 3.5. Secure Association Protocol Requirements The Secure Association Protocol supports the following: Entity Naming The peer and authenticator SHOULD identify themselves in a manner that is independent of their attached ports. Mutual proof of possession The peer and authenticator MUST each demonstrate possession of the keying material transported between the backend authentication server and authenticator (AAA-Key). Key Naming The Secure Association Protocol MUST explicitly name the keys used in the proof of possession exchange, so as to prevent confusion when more than one set of keying material could potentially be used as the basis for the exchange. Aboba, et al. Standards Track [Page 28] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Creation and Deletion In order to support the correct processing of phase 2 security associations, the Secure Association (phase 2) protocol MUST support the naming of phase 2 security associations and associated transient session keys, so that the correct set of transient session keys can be identified for processing a given packet. The phase 2 Secure Association Protocol also MUST support transient session key activation and SHOULD support deletion, so that establishment and re-establishment of transient session keys can be synchronized between the parties. Integrity and Replay Protection The Secure Association Protocol MUST support integrity and replay protection of all messages. Direct operation Since the phase 2 Secure Association Protocol is concerned with the establishment of security associations between the EAP peer and authenticator, including the derivation of transient session keys, only those parties have "a need to know" the transient session keys. The Secure Association Protocol MUST operate directly between the peer and authenticator, and MUST NOT be passed-through to the backend authentication server, or include additional parties. Derivation of transient session keys The Secure Association Protocol negotiation MUST support derivation of unicast and multicast transient session keys suitable for use with the negotiated ciphersuite. TSK freshness The Secure Association (phase 2) Protocol MUST support the derivation of fresh unicast and multicast transient session keys, even when the keying material provided by the backend authentication server is not fresh. This is typically supported by including an exchange of nonces within the Secure Association Protocol. Bi-directional operation While some ciphersuites only require a single set of transient session keys to protect traffic in both directions, other ciphersuites require a unique set of transient session keys in each direction. The phase 2 Secure Association Protocol SHOULD provide for the derivation of unicast and multicast keys in each direction, so as not to require two separate phase 2 exchanges in order to create a bi-directional phase 2 security association. Secure capabilities negotiation The Secure Association Protocol MUST support secure capabilities Aboba, et al. Standards Track [Page 29] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 negotiation. This includes security parameters such as the security association identifier (SAID) and ciphersuites, as well as negotiation of the lifetime of the TSKs, AAA-Key and exported EAP keys. Secure capabilities negotiation also includes confirmation of the capabilities discovered during the discovery phase (phase 0), so as to ensure that the announced capabilities have not been forged. Key Scoping The Secure Association Protocol MUST ensure the synchronization of key scope between the peer and authenticator. This includes negotiation of restrictions on key usage. 3.6. Ciphersuite Requirements Ciphersuites suitable for keying by EAP methods MUST provide the following facilities: TSK derivation In order to allow a ciphersuite to be usable within the EAP keying framework, a specification MUST be provided describing how transient session keys suitable for use with the ciphersuite are derived from the AAA-Key. EAP method independence Algorithms for deriving transient session keys from the AAA-Key MUST NOT depend on the EAP method. However, algorithms for deriving TEKs MAY be specific to the EAP method. Cryptographic separation The TSKs derived from the AAA-Key MUST be cryptographically separate from each other. Similarly, TEKs MUST be cryptographically separate from each other. In addition, the TSKs MUST be cryptographically separate from the TEKs. 4. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to EAP key management, in accordance with BCP 26, [RFC2434]. The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration". The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action". Aboba, et al. Standards Track [Page 30] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published. The Designated expert will post a request to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable. This document introduces a new name space for "key labels". Key labels are ASCII strings and are assigned via IETF Consensus. It is expected that key label specifications will include 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. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Aboba, et al. Standards Track [Page 31] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 5.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Aboba, et al. Standards Track [Page 32] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) Protocol", RFC 3078, March 2001. [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2004. [FIPSDES] National Institute of Standards and Technology, "Data Encryption Standard", FIPS PUB 46, January 1977. [DESMODES] National Institute of Standards and Technology, "DES Modes of Operation", FIPS PUB 81, December 1980, . [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture", ANSI/IEEE Standard 802, 1990. [IEEE80211] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE IEEE Standard 802.11-1999, 1999. [IEEE8021X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, September 2004. [IEEE8021Q] Institute of Electrical and Electronics Engineers, "IEEE Aboba, et al. Standards Track [Page 33] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks", IEEE Standard 802.1Q/D8, January 1998. [IEEE80211F] Institute of Electrical and Electronics Engineers, "Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, July 2003. [IEEE80211i] 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/ D8, February 2004. [IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Caching Strategies for IAPP Latency Improvement during 802.11 Handoff", IEEE 802.11 Working Group, IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, January 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. [I-D.ietf-roamops-cert] Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- cert-02 (work in progress), April 1999. [I-D.ietf-aaa-eap] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa- eap-08 (work in progress), June 2004. [I-D.irtf-aaaarch-handoff] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Aboba, et al. Standards Track [Page 34] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 draft-irtf-aaaarch-handoff-04 (work in progress), October 2003. [I-D.puthenkulam-eap-binding] Puthenkulam, J., "The Compound Authentication Binding Problem", draft-puthenkulam-eap-binding-04 (work in progress), October 2003. [I-D.aboba-802-context] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", draft-aboba-802-context-03 (work in progress), October 2003. [I-D.arkko-pppext-eap-aka] Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- arkko-pppext-eap-aka-11 (work in progress), October 2003. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- ietf-ipsec-ikev2-14 (work in progress), June 2004. [8021XHandoff] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Public Wireless LAN Based on IEEE 802.1X Model", School of Computer Science and Engineering, Seoul National University, Seoul, Korea, 2002. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes, Vol.2 No.2, 1996. [WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements for Wireless LANs", draft-walker-ieee802-req-02.txt (work in progress), July 2004. [Housley56] Housley, R., "Key Management in AAA", Presentation to the AAA WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, March 2003. Acknowledgments Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ Housley of Vigil Security for useful feedback. Aboba, et al. Standards Track [Page 35] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Author Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: dansimon@microsoft.com Phone: +1 425 706 6711 Fax: +1 425 936 7329 Jari Arkko Ericsson Jorvas 02420 Finland Phone: EMail: jari.arkko@ericsson.com Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 Phone: +1 206 256 3380 Email: jsalowey@cisco.com Aboba, et al. Standards Track [Page 36] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Appendix A - Ciphersuite Keying Requirements To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by EAP. This Appendix describes the keying requirements of common PPP and 802.11 ciphersuites. PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE [RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in [RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single 56-bit encryption key is required, used in both directions. For PPP 3DES, a 168-bit encryption key is needed, used in both directions. As described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, which is different in each direction, is "deduced from an explicit 64-bit nonce, which is exchanged in the clear during the [ECP] negotiation phase." There is therefore no need for the IV to be provided by EAP. For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in each direction, as described in [RFC3078]. No initialization vector is required. While these PPP ciphersuites provide encryption, they do not provide per-packet authentication or integrity protection, so an authentication key is not required in either direction. Within [IEEE80211], Transient Session Keys (TSKs) are required both for unicast traffic as well as for multicast traffic, and therefore separate key hierarchies are required for unicast keys and multicast keys. IEEE 802.11 ciphersuites include WEP-40, described in [IEEE80211], which requires a 40-bit encryption key, the same in either direction; and WEP-128, which requires a 104-bit encryption key, the same in either direction. These ciphersuites also do not support per-packet authentication and integrity protection. In addition to these unicast keys, authentication and encryption keys are required to wrap the multicast encryption key. Recently, new ciphersuites have been proposed for use with IEEE 802.11 that provide per-packet authentication and integrity protection as well as encryption [IEEE80211i]. These include TKIP, which requires a single 128-bit encryption key and two 64-bit authentication keys (one for each direction); and AES CCMP, which requires a single 128-bit key (used in both directions) in order to authenticate and encrypt data. As with WEP, authentication and encryption keys are also required to wrap the multicast encryption (and possibly, authentication) keys. Aboba, et al. Standards Track [Page 37] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Appendix B - Transient EAP Key (TEK) Hierarchy Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], which is based on the TLS key hierarchy described in [RFC2246]. The TLS-negotiated ciphersuite is used to set up a protected channel for use in protecting the EAP conversation, keyed by the derived TEKs. The TEK derivation proceeds as follows: master_secret = TLS-PRF-48(pre_master_secret, "master secret", client.random || server.random) TEK = TLS-PRF-X(master_secret, "key expansion", server.random || client.random) Where: TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], computed to X octets. | | | | | pre_master_secret | server| | | client Random| V | Random | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | +---->| master_secret |<------+ | | (TMS) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Key Block | | (TEKs) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | client | server | client | server | client | server | MAC | MAC | write | write | IV | IV | | | | | | V V V V V V Figure B-1 - TLS [RFC2246] Key Hierarchy Aboba, et al. Standards Track [Page 38] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Appendix C - EAP-TLS Key Hierarchy In EAP-TLS [RFC2716], the MSK is divided into two halves, corresponding to the "Peer to Authenticator Encryption Key" (Enc- RECV-Key, 32 octets, also known as the PMK) and "Authenticator to Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- Key attribute. The EMSK is also divided into two halves, corresponding to the "Peer to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 octets). The IV is a 64 octet quantity that is a known value; octets 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master secret via a one-way function. This ensures that the TLS master secret cannot be derived from the MSK, EMSK or IV unless the one-way function (TLS PRF) is broken. Since the MSK is derived from the the TLS master secret, if the TLS master secret is compromised then the MSK is also compromised. As described in [RFC2716], the formula for the derivation of the MSK, EMSK and IV is as follows: MSK = TLS-PRF-64(TMS, "client EAP encryption", client.random || server.random) EMSK = second 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) IV = TLS-PRF-64("", "client EAP encryption", client.random || server.random) AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) (MS-MPPE-Recv-Key in [RFC2548]). Also known as the PMK. AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) (MS-MPPE-Send-Key in [RFC2548]) EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) Where: Aboba, et al. Standards Track [Page 39] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. IV(W,Z) = Octets W through Z inclusive of the IV. MSK(W,Z) = Octets W through Z inclusive of the MSK. EMSK(W,Z) = Octets W through Z inclusive of the EMSK. TMS = TLS master_secret TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets client.random = Nonce generated by the TLS client. server.random = Nonce generated by the TLS server. Figure C-1 describes the process by which the MSK,EMSK,IV and ultimately the TSKs, are derived from the TLS Master Secret. ---+ | ^ | TLS Master Secret (TMS) | | | V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | EAP | | Master Session Key (MSK) | Method | | Derivation | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+ | | | API ^ | MSK | EMSK | IV | | | | | V V V v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | | | | | | backend authentication server | | | | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | AAA-Key(0,31) | AAA-Key(32,63) | | (PMK) | Transported | | | via AAA | | | | V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | Ciphersuite-Specific Transient Session | Auth.| | Key Derivation | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ Figure C-1 - EAP TLS [RFC2716] Key hierarchy Aboba, et al. Standards Track [Page 40] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Appendix D - Example Transient Session Key (TSK) Derivation Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient session key used to protect unicast traffic, is derived from the PMK (octets 0-31 of the MSK), known in [RFC2716] as the Peer to Authenticator Encryption Key. In [IEEE80211i], the PTK is derived from the PMK via the following formula: PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) || Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) Where: PMK = AAA-Key(0,31) SA = Station MAC address (Calling-Station-Id) AA = Access Point MAC address (Called-Station-Id) ANonce = Access Point Nonce SNonce = Station Nonce EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating a PTK of size X octets. TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. The EAPOL-Key Confirmation Key (KCK) is used to provide data origin authenticity in the TSK derivation. It utilizes the first 128 bits (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides confidentiality in the TSK derivation. It utilizes bits 128-255 of the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is ciphersuite specific. Details are available in [IEEE80211i]. Aboba, et al. Standards Track [Page 41] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Appendix E - Key Names and Scope in Existing Methods This appendix specifies the key names and scope in methods that have been published prior to the publication of this RFC. What is needed in addition to the rules in Section 2.4 is the definition of what EAP peer and server names are used, what Method-Id is used, and how these are encoded. EAP-TLS The EAP-TLS Method-Id is provided by the concatenation of the peer and server nonces. Where certificates are used, the Session-Id scope is determined via the EAP peer and server names, deduced from the altSubjectName in the peer and server certificates. Issue: What happens if a pre-shaked key ciphersuite is negotiated? How are the EAP peer and server names determined? EAP-AKA The EAP-AKA Method-Id is the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute. The EAP peer name is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast reauthentication identity. The EAP server name is an empty string. EAP-SIM The Method-Id is the contents of the RAND field from the AT_RAND attribute, followed by the contents of the NONCE_MT field in the AT_NONCE_MT attribute. The EAP peer name is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast reauthentication identity. The EAP server name is an empty string. Aboba, et al. Standards Track [Page 42] INTERNET-DRAFT EAP Key Hierarchy 15 November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Open Issues Open issues relating to this specification are tracked on the following web site: http://www.drizzle.com/~aboba/EAP/eapissues.html Aboba, et al. Standards Track [Page 43]