Network Working Group V. Narayanan Internet-Draft L. Dondeti Expires: October 22, 2006 QUALCOMM, Inc. April 20, 2006 Gap analysis on the EAP keying hierarchy draft-vidya-eap-keying-gap-analysis-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 October 22, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The extensible authentication protocol (EAP) keying framework [1] leaves out guidelines for using the extended master session key (EMSK) for future discussion and specification. While the keying framework does provide guidance for EAP master session key (MSK) usage, some SDOs use that key in a non-compliant manner. This document provides a description and analysis of MSK and EMSK usage and provides an outline for a discussion on these topics. Narayanan & Dondeti Expires October 22, 2006 [Page 1] Internet-Draft EAP Keying Gap Analysis April 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Summary of EAP keying hierarchy . . . . . . . . . . . . . . . 4 4. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. EAP Architecture Models . . . . . . . . . . . . . . . . . 5 4.1.1. Basic EAP Model . . . . . . . . . . . . . . . . . . . 5 4.1.2. Distinct Authenticator and EP Entities . . . . . . . . 6 4.1.3. Distinct EAP Server and AAA Server . . . . . . . . . . 8 4.2. Authenticator-EP Interface . . . . . . . . . . . . . . . . 8 4.3. Handoffs and Authentication . . . . . . . . . . . . . . . 9 4.3.1. EAP-Based Pre-authentication . . . . . . . . . . . . . 9 4.3.2. Fast Re-authentication in EAP . . . . . . . . . . . . 10 4.3.3. Pro-Active Key Distribution . . . . . . . . . . . . . 10 4.4. On MSKs . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. MSK key hierarchy . . . . . . . . . . . . . . . . . . 11 4.5. On the extended MSK (EMSK) . . . . . . . . . . . . . . . . 12 4.5.1. EMSK derivation from EAP methods . . . . . . . . . . . 13 4.5.2. EMSK handling at the peer and the server . . . . . . . 15 4.5.3. EMSK lifetime and replacement . . . . . . . . . . . . 15 4.6. Key naming . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Narayanan & Dondeti Expires October 22, 2006 [Page 2] Internet-Draft EAP Keying Gap Analysis April 2006 1. Introduction The EAP Keying Framework [1] and the EAP Keying Extensions [4] documents explain the EAP keying hierarchy and the uses of the various keying materials derived as a result of EAP method execution. However, there are some gaps in the key derivation and usage guidelines specified in these two documents. The goal of this document is to identify those gaps and provide an analysis to help adequately specify the key hierarchy and guidelines. There are some gray areas in the manner in which other SDOs have used EAP keying to create session keys for the peer. For example, in IEEE 802.11 networks, the use of 802.11i [5] often follows the model where the EAP peer is in the STA and the EAP authenticator is in a Wireless LAN switch. In this model, the Enforcement Point (defined below) is often in the 802.11 Access Point to which the STA associates. The TSKs are used to establish a mutually authenticated secure channel between the AP and the peer. The secure channel's primary purpose is link layer access control. Given that the authenticator is in the switch, the MSK from the EAP exchange arrives at the switch. TSK derivation from the MSK when the Authenticator is separate from the EP(s) is not specified in any IETF documents. Proprietary protocols and other SDO specifications (e.g., IEEE 802.11r, IEEE 802.16e, etc.), completed or in progress, fill the gap currently. The EAP keying documents [1], [4], also explain the keys derived by EAP methods (MSK, EMSK) and explain the usage of each of those keys. However, EMSK and AMSK usage remain undefined at this point. This document provides an analysis on what remains to be specified and outlines some of the approaches considered by other documents. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. This document follows the terminology that has been defined in RFC3748 [3] and the EAP Keying I-D. In addition, this document uses the following terms: Enforcement Point (EP) A logical entity that shares the TSK with the EAP peer and is responsible for port control. Examples of EP include specific ports on an authenticator or Layer2 devices such as WLAN APs or cellular base stations, etc. Narayanan & Dondeti Expires October 22, 2006 [Page 3] Internet-Draft EAP Keying Gap Analysis April 2006 3. Summary of EAP keying hierarchy This section captures in a brief description, a summary of the EAP keying framework [1] as well as the current snapshot of the EAP keying extensions [4]. The EAP keying framework [1] describes the creation of the MSK and EMSK and the usage of the MSK. The three phases in authentication and key derivation of the peer have been identified as the discovery phase, where the EAP peer discovers a valid authenticator, followed by an authentication phase, where the EAP authentication is performed and key material (e.g., MSK) is derived and transported, followed by a secure association establishment phase, where the session keys are derived. Of these, [1] identifies the EAP authentication and the key derivation as being within the scope of EAP. In a nutshell, EAP keying framework [1] requires key generating EAP methods to derive an MSK and an EMSK. The MSK is then exported to the AAA layer of the server, which then transports the key to the authenticator. The AAA layer of the authenticator passes the MSK on to the EAP lower layer that would eventually derive the TSKs from it. The EMSK is derived by the EAP method in the peer and server and exported to the EAP layer. In accordance with the current status of the EAP keying framework [1], it is never transported out of the EAP layer and specifically, never shared with a third party. RFC3748 [3] and the EAP keying framework [1] provide some detail on channel binding that can be used to ensure that the EAP server and peer are communicating with the same and a valid authenticator. Here, the channel binding information is seen as an opaque blob by the EAP layer and may be carried in the EAP method. It is only interpreted by the lower layer. Channel binding allows the peer and the server to unambiguously identify the authenticator's architecture to cover cases such as that of virtual authenticators, multiple ports of an authenticator, or a cluster of authenticators. The peer may end up participating in a security association protocol with one of the ports of an authenticator or one of the authenticators among the cluster of authenticators, etc. In addition to carrying channel binding information via EAP methods, other proposals have been made to incorporate channel binding information into EAP keying framework: [6] proposes a method by which channel binding can be done without a need to carry the service information in EAP methods. Here, keys are derived by the method layer for channel binding purposes. Aside from an in-depth description of the lower layer behavior and EAP key management, the EAP keying framework [1] also explains some guidelines with respect to handoffs that do not result in a full EAP re-authentication. The description alludes to the fact that it may be acceptable to perform such faster hanodffs when the respective Narayanan & Dondeti Expires October 22, 2006 [Page 4] Internet-Draft EAP Keying Gap Analysis April 2006 authenticators or ports/SSIDs within the authenticator have similar policies and are within the same administrative domain. Again, this points to the case where the authenticator that shares the MSK with the peer and the EP that shares the TSK with the peer may potentially be logically or physically different entities. There is an EAP keying extensions [4] document that was separated from an originally published EAP keying framework [1] that provides some insight into EMSK usage and AMSK derivations. However, that document is currently expired and needs to be updated in light of some of the changes adopted in the EAP keying frameworkre. 4. Gap analysis The goal of this section is to analyze the missing pieces in the currently available documentation on EAP keying and propose some next steps to bridge the gap. For the purpose of discussion within this document, only the pass-through mode of the authenticator will be considered. However, the multiplexing mode works very similarly and the behavior of the authenticator portion remains unchanged. 4.1. EAP Architecture Models 4.1.1. Basic EAP Model In the simplest case, the EP is collocated with the authenticator as shown in the figure below. +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | EAP |--------| Auth/ |--------| EAP | | Peer | | EP | |Server | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ Figure 1: EAP Authenticator Collocated with the Enforcement Point The key distribution described in the EAP keying framework [1] is adequate to describe this case. For reference, the transport of the EAP keying material (i.e., MSK) from the EAP server to the authenticator is shown below. Narayanan & Dondeti Expires October 22, 2006 [Page 5] Internet-Draft EAP Keying Gap Analysis April 2006 Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | V | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | |EAP | EAP | | | ! | | ! | |Peer | Auth.| EAP Auth. | | ! | |EAP ! peer| | | +-----------+ | |EAP !Auth.| | ! | | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | V | | V | ! | | ! | |Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP | | | | | ! | | ! | +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! +---------<-------+ Figure 2: EAP MSK Transport in Pass-Through Model 4.1.2. Distinct Authenticator and EP Entities In other EAP architecture models, the authenticator and the EP are not logically and/or physically collocated. This may be the case when there are multiple ports on an authenticator or multiple physical EPs (e.g., 802.11 APs) connected to an authenticator (e.g., WLAN switch). The following figure illustrates this case of separated authenticator and EPs. Narayanan & Dondeti Expires October 22, 2006 [Page 6] Internet-Draft EAP Keying Gap Analysis April 2006 +-+-+-+-+ | | | EAP | |Server | +-+-+-+-+ | | | +-+-+-+-+ | | | Auth | | | +-+-+-+-+ | | | / | \ / | \ / | \ / | \ / | \ / | \ +-+-+-+ +-+-+-+ +-+-+-+ | EP1 | | EP2 |..| EPn | +-+-+-+ +-+-+-+ +-+-+-+ | | | +-+-+-+-+ | | | EAP | | Peer | +-+-+-+-+ Figure 3: EAP Authenticator Not Collocated with the Enforcement Point In a case like this, the EAP authenticator is not the entity sharing the TSK with the EAP peer. In accordance with EAP, the MSK will be delivered to the authenticator. However, the TSK generated is shared by say, EP1 and the peer in the figure above. In many implementations available today, the interface between the Authenticator and the EPs remains either proprietary or different in various SDOs. When the authenticator and the EPs are devices employing the same Narayanan & Dondeti Expires October 22, 2006 [Page 7] Internet-Draft EAP Keying Gap Analysis April 2006 access technology (such as 802.11, 3GPP2 L2 technologies, 802.16e), it can be concluded that the interface under question is not within the scope of the IETF. However, when the authenticator and EP do not map to the same access technology, the definition of the interface between them in the IETF might become important. The analysis on handovers, re-authentication and pre-authentication done further in this document indicates that there is not a practical need for the case where the authenticator and EP do not map to the access technology. 4.1.3. Distinct EAP Server and AAA Server Another possible architecture that would be compliant with EAP is the case where the EAP and AAA servers are separate entities. Even though the EAP architecture allows for this, existing documentation is insufficient to clearly define this model. For instance, the function of the AAA layer in the EAP server and its interactions with the AAA layer in the AAA server in this case, although can be extracted, is not explicitly clear. The presence of distinct EAP and AAA servers does not have any advantages to it. Hence, this case of distinct EAP and AAA servers is considered not a practical use case and will not be explored further in this document. 4.2. Authenticator-EP Interface As mentioned earlier, the interface between the authenticator and the EP is not currently defined in the IETF, in a generic sense (the CAPWAP [7] protocol is currently 802.11 specific, and does not quite cover the use case being discussed here). Other SDOs have defined this interface in some cases. For instance, IEEE 802.11r specifies a two-level key holder hierarchy for fast BSS transition. However, there are some other cases that remain proprietary - for instance, the interface between a WLAN switch and an Access Point. One question in this case is this - when the authenticator and EP are not collocated, how does the MSK delivered to the authenticator enable the establishment of a TSK between the peer and the EP? In many implementations today, one of the following three approaches are taken. In one approach, the authenticator provides the MSK to every EP that the peer attaches to and the EP establish the TSK with the peer via Secure Association Protocol. In this case, all EPs under the authenticator share the same MSK. In another approach, the authenticator provides the MSK to the first EP and the MSK is transferred via EP-to-EP context transfer mechanisms to the other EPs as needed. The EPs share the same MSK in this case as well. In a Narayanan & Dondeti Expires October 22, 2006 [Page 8] Internet-Draft EAP Keying Gap Analysis April 2006 third approach, the authenticator derives an EP-specific key to hand to each EP as needed and that key is used to derive the TSK. The first two approaches are the commonly used ones, since in those cases, the peer does not have to even know that the authenticator and EP are not collocated. In the third approach, the peer would have to know to derive an EP specific key to use for the Secure Association Protocol. If the interface between the authenticator and the EP does not need to be defined in the IETF (i.e., if the authenticator and the EPs associated with each other always belong to the same access technology), then, effectively, there is not an open issue here. Currently, this is considered to be true and hence, we conclude that the A-EP interface is, in fact, outside the scope of the IETF. 4.3. Handoffs and Authentication The EAP keying framework [1] identifies some vulnerabilities that may arise during handoffs due to the ways in which the EAP keying is used today. Many of the concerns relate to the above mentioned use of mechanisms that share the MSK or perform some faster re- authentication without performing a new EAP authentication. The EAP keying framework [1] acknowledges these approaches and provides some guidelines for the correct usage of the MSK. While referring to handoffs, roundtrip latency to the AAA server incurred while employing certain EAP methods may be undesirable. Some EAP methods such as EAP-PSK only incur a maximum of two roundtrips to the AAA server and could be viewed as being acceptable. However, there may be reasons why optimizations need to be considered in the case of handoffs. The following sections discuss concepts that relate to secure handoff optimizations. Some of these concepts have been worked on and analyzed in other documents written in the past. 4.3.1. EAP-Based Pre-authentication Several lower layers support the concept of pre-authentication, where the EAP peer can authenticate with a target authenticator prior to actually needing to run the secure association protocol on the new link. As RFC 3748 [3] points out, the MSK derived as a result of pre-authentication may or may not even be used to create session keys. If the EAP peer pre-authenticates with an authenticator and does not move to that authenticator, the MSK will be unused. There are some questions on the behavior of pre-authentication that remain unanswered. For now, since the pre-authentication is not Narayanan & Dondeti Expires October 22, 2006 [Page 9] Internet-Draft EAP Keying Gap Analysis April 2006 signaled in EAP (it is only signaled in lower layers like IEEE 802.11i for appropriate routing of the EAP frames to the correct authenticator), the EAP server is unaware of whether a certain EAP exchange is for pre-authentication or regular authentication. AAA servers need to understand pre-authentication so that appropriate state (e.g., the NAS ID of the authenticator with which the peer has pre-authenticated) and accounting information can be maintained for the peer. If pre-authentication could be signaled in EAP itself, then the EAP server would be able to distinguish between a normal authentication and a pre-authentication. While this may be difficult given the legacy implementations of EAP and EAP methods, this could be signaled at the AAA layer at a minimum, so that the server can adequately distinguish between the two. It should be noted that pre-authentication is no different from regular EAP authentication, except that the EAP signaling between the peer and the authenticator is exchanged via the current EP or authenticator. Pre-authentication still results in execution of the EAP method as in the case of regular authentication. 4.3.2. Fast Re-authentication in EAP EAP does not have a means for fast re-authentication. When the peer needs to obtain a new MSK, it needs to perform a full EAP exchange today. With other techniques such as pre-authentication, pro-active key distribution, etc., available, there is no need for EAP to deal with re-authentication in any different manner. Depending on the EAP method used, even the full authentication may not be that disruptive, at least in the case where the peer is accessing its home domain (in the non-roaming case). 4.3.3. Pro-Active Key Distribution The AAA Architecture document [8] describes a method of pro-actively distributing keys to neighboring authenticators based on authentication at a current authenticator. The EAP keying extensions [4] document summarizes the pro-active key distribution mechanism. In this case, the AAA server is said to learn about the neighboring authenticators by observing a node's movement pattern. Hence, the AAA server creates a neighbor graph for the node and creates a key for each neighboring authenticator. The authenticator may then request the key from the AAA server to obtain it. This method of pro-active key generation and distribution has its advantages and issues. It may be impractical for the AAA server to know or learn the network topology and identify the neighboring Narayanan & Dondeti Expires October 22, 2006 [Page 10] Internet-Draft EAP Keying Gap Analysis April 2006 authenticators correctly. On the other hand, this mechanism clearly avoids having to authenticate the peer again and hence, could be significantly faster. Another point to be noted that the AAA architecture work is agnostic to the type of authentication and does not directly apply to EAP. Hence, it must be studied to see if the keying framework [1] in EAP brings any additional considerations. When EAP is used for authentication and key derivation, the EAP method layer is the one deriving the MSK. In accordance with EAP behavior, the EAP method must derive subsequent MSKs. Pro-active key distribution should be done without requiring changes to EAP methods in order to be widely adopted. EAP methods currently only derive one MSK and EMSK as a result of one method exchange and hence, pro-active derivation of multiple MSKs for other authenticators does not fit this model. Pro-active key distribution itself is somewhat of a misleading concept in the sense that AAA protocols do not particularly allow for unsolicited signaling from the server to the NAS needed for such distribution. However, pro-active key generation itself may have its place in speeding up handoffs. In addition to being pro-active about MSK generation for target authenticators, it could also be derived on-demand when requested from a target authenticator. This, in fact, fits well with today's AAA model, which is always client initiated. When a given network allows for both pre-authentication and proactive key distribution, both may in fact be performed. Keys derived from pre-authentication must override any keys obtained via proactive key derivation methods. If an MSK is available at an authenticator via EAP pre-authentication, any key (MSK) obtained via proactive distribution must be deleted and the MSK received from the pre- authentication must be used to derive TSKs. 4.4. On MSKs The EAP keying framework [1] clearly explains the fact that the MSK is derived by the EAP method and transported to the authenticator. The AAA layer of the authenticator receives it from the AAA layer of the Authentication Server (AS) and transports it typically to another lower layer. The sections below analyze two separate cases, depending on the relative location of the authenticator and EP. 4.4.1. MSK key hierarchy Narayanan & Dondeti Expires October 22, 2006 [Page 11] Internet-Draft EAP Keying Gap Analysis April 2006 Keys Entity(ies) that hold(s) the key -------- ---------------------------------- MSK Virtual authenticator & peer | +--------------------------+ | | | EP1MSK EP2MSK EP3MSK EPi holds EPiMSK & peer ^ ^ ^ | | | | | | v v v TSK1 TSK2 TSK3 Peer & EP1 derive TSK1 Figure 4: MSK key hierarchy Figure 4 above shows the MSK Key Hierarchy in the case where the authenticator and the EP are distinct entities. As seen, there is potentially an EPiMSK that is derived from the MSK to provide an EP specific key. As described earlier, these keys are currently either defined by lower layers or in other cases, the EPiMSK is the same as the MSK. In either case, channel binding must be clearly specified so that the peer and the server have the same understanding of the scope of the key. 4.5. On the extended MSK (EMSK) The EAP specification [3] defines the EMSK as follows: The extended master key (EMSK) is additional keying material -- in addition to the TEK and the MSK -- derived between the EAP client and server that is exported by the EAP method. It is at least 64 octets in length and is not shared with the authenticator or any other third party. The EMSK must be cryptographically separate from the MSK. The MSK and the keys derived from the EMSK are used for different purposes and may be provided to entities that do not trust each other. Thus it must not be possible to derive the MSK from the EMSK or vice versa, without breaking cryptographic assumptions such as reversing a one-way function. The EMSK must not be used directly to protect data. The EMSK is exported from the EAP method layer to the EAP layer, but never transported out of the EAP server. The EMSK MUST NOT be transported Narayanan & Dondeti Expires October 22, 2006 [Page 12] Internet-Draft EAP Keying Gap Analysis April 2006 by the AAA layer. RFC3748 specifies that the EMSK is reserved for future use and 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 to derive any other keys. The eventual intent is to use the EMSK to derive keys; RFC3748 postpones that discussion to a future IETF specification. 4.5.1. EMSK derivation from EAP methods Guidelines for the derivation of EMSK within a method are adapted from the previous work of Salowey et. al. [9]. Some of the following rules have been stated earlier, but included below for completeness: o The EAP method must specify how to derive the EMSK. o The EMSK must be unique for each session. o The EAP mechanism should provide a way of naming the EMSK. o 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 64 octets, used in the derivation of the MSK and EMSK. o The EMSK must be cryptographically independent of the MSK and TEKs. o The EMSK must be secret and not known to someone observing the authentication mechanism protocol exchange. o The EMSK must be maintained within the EAP server. Only keys derived from the EMSK may be exported from the EAP server. o The use of EMSK and key derivation thereof must be defined in one document, and the EMSK must not be used for any other purpose. Application-level key material requests must be fulfilled with the keys derived from the EMSK. 4.5.1.1. Examples of EMSK derivation in EAP methods Examples of EMSK derivation in various EAP methods are described below for reference (copied from various EAP method specifications): Narayanan & Dondeti Expires October 22, 2006 [Page 13] Internet-Draft EAP Keying Gap Analysis April 2006 EAP-FAST MSK and EMSK derivation The session_key_seed derived as part of EAP-FAST phase 2 is used in EAP-FAST phase 2 to generate an Intermediate Compound Key (IMCK) used to verify the integrity of the TLS tunnel after each successful inner authentication and in the generation of Master Session Key (MSK) and Extended Master Session Key (EMSK) defined in [RFC3748]. EAP-FAST Authentication assures the master session key (MSK) and Extended Master Session Key (EMSK) output from the EAP method are the result of all authentication conversations by generating an intermediate compound session key (IMCK). The IMCK is mutually derived by the peer and the server as described in Section 5.2 by combining the MSKs from inner EAP methods with key material from EAP-FAST phase 1. The resulting MSK and EMSK are generated as part of the IMCKn key hierarchy as follows: MSK = T-PRF(S-IMCK[j], "Session Key Generating Function", 64) EMSK = T-PRF(S-IMCK[j],"Extended Session Key Generating Function", 64) where j is the number of the last successfully executed inner EAP method. If no EAP methods have been negotiated inside the tunnel or no EAP methods have been successfully completed inside the tunnel, the MSK and EMSK will be generated directly from the session_key_seed meaning S-IMCK = session_key_seed. PEAPv2 MSK and EMSK derivation PEAPv2 derives an Extended Master Session Key (EMSK) which is reserved for use in deriving keys in other ciphering applications. The compound session key (CSK) is derived on both the peer and EAP server. CSK = PRF+(S-IPMKn, "Session Key Generating Function", OutputLength) where, IPMKj = PRF+(S-IPMK(j-1),"Inner Methods Compound Keys " | ISKj, 60); Where S-IPMKj are the first 40 octets of IPMKj and CMKj are the last 20 octets of IPMKj used to generate the intermediate Compound MACs. ISK1..ISKn are the MSK portion of the EAP keying material obtained from methods 1 to n. The ISKj shall be the first 32 octets of the generated MSK of the jth EAP method. The output length of the CSK must be at least 128 bytes. The first 64 octets are taken as the MSK and the second 64 octets are taken as the EMSK. Narayanan & Dondeti Expires October 22, 2006 [Page 14] Internet-Draft EAP Keying Gap Analysis April 2006 TTLS MSK and EMSK derivation Upon successful conclusion of an EAP-TTLSv1 negotiation, a 64- octet MSK (Master Session Key) is generated and exported for use in securing the data connection between client and access point. The MSK is generated using the TLS PRF function [RFC2246], with inputs consisting of the inner secret exported by TLS/IA, the ASCII- encoded constant string "ttls v1 keying material", the TLS client random, and the TLS server random. The constant string is not null- terminated. The TLS/IA inner secret, rather than the TLS master secret, is used because it binds session keys from inner authentications with the TLS master secret and therefore provides greater security in the (unlikely) case that an adversary is able to compromise the master secret. MSK = PRF(inner_secret, "ttls v1 keying material", SecurityParameters.client_random + SecurityParameters.server_random) [0..63] TTLS does not specify the derivation of EMSK. 4.5.2. EMSK handling at the peer and the server EMSK handling itself is specified in the EAP keying document [1] and there are ongoing discussions on the handling of that key. Section 7.10 of RFC 3748 [3] notes that the EMSK is reserved for future use and 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 to derive any other keys. (This restriction will be relaxed in a future document that specifies how the EMSK can be used.) The EAP keying framework states that the EMSK MUST NOT be provided to an entity outside the EAP server or peer, nor is it permitted to pass any quantity to an entity outside the EAP server or peer from which the EMSK could be computed without breaking some cryptographic assumption, such as inverting a one-way function. 4.5.3. EMSK lifetime and replacement The EMSK is associated with a lifetime parameter. When the lifetime expires, the EMSK must be deleted and no further keys can be derived from it. When a peer reauthenticates, a new MSK and EMSK will be generated. An AS maintains a single EMSK per peer, and thus the new EMSK will replace the old EMSK. Narayanan & Dondeti Expires October 22, 2006 [Page 15] Internet-Draft EAP Keying Gap Analysis April 2006 4.6. Key naming MSK and EMSK names are among the parameters exported by the EAP peer and EAP server, and can be referred to using the EAP Session-ID and a binary or textual indication of the parameter being referred to. The EAP method layer exports the MSK and EMSK name to the peer or the authenticator layers. The EAP Session-ID is defined as the concatenation of the EAP Expanded Type with the Method-ID. 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 a KDF with the EMSK, peer and server IDs and an identifying string as the inputs. 5. Security Considerations This draft provides an analysis of EAP MSK and EMSK derivation, usage and handling. [10] specifies detailed guidelines for AAA key management. Those criteria are all applicable in handling MSKs and EMSKs. In the following, we will briefly describe the salient requirements: Algorithm independence: Key derivation from the MSK and EMSK must be specified in an algorithm independent fashion. HMAC-SHA-1 as a PRF is common in many EAP methods, but future proofing just in case there are vulnerabilities found in the HMAC construction or even to allow using cipher-based PRFs would be a desirable feature. Note further that in future, longer keys may be required. The MSK and the EMSK are already required to be 64 octets or more in length, which allows easy accommodation of SHA- 256 or other cryptographic functions requiring the use of long keys. Strong, fresh keys: It is important that EAP methods include nonces and other session specific random information to derive the MSK and EMSK. These rules apply to keys derived from the MSK and the EMSK also. Limiting key scope: Section Section 4.2 discusses how in certain cases, the MSK may be shared between multiple entities. That is in general not a recommended practice. Note that compromise of any of the entities that hold the MSK results in compromise of the MSK and requires re-authentication. It is also plausible that the compromise is not easily detectable since the peer may not be involved in any communication with some of the entities that may hold the MSK. Similar rules apply to EMSK. EMSK handling Narayanan & Dondeti Expires October 22, 2006 [Page 16] Internet-Draft EAP Keying Gap Analysis April 2006 guidelines are quite strict in that the EMSK itself is not transported to any third party entity. It is also prudent to limit the delivery of any derived keys from the MSK or the EMSK to entities that absolutely require that key. It is also prudent to deliver a separate key for each third party entity to limit any key exposure. Key naming and binding: It is important to name the MSK, EMSK and derived keys thereof to easily and unambiguously identify the keys. Similarly, it is important to bind the keys to the context, including the identities of the parties that use the key, lifetime, key length etc. 6. IANA Considerations No IANA registrations are required for this document. 7. Acknowledgments The authors would like to thank AC Mahendran for helping out with discussions on the topic. Note that the text in this draft in certain places has been liberally borrowed from other EAP keying related drafts. 8. References 8.1. Normative References [1] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-12 (work in progress), April 2006. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 8.2. Informative References [4] Aboba, B., "EAP Key Management Extensions", draft-aboba-eap-keying-extens-00 (work in progress), April 2005. Narayanan & Dondeti Expires October 22, 2006 [Page 17] Internet-Draft EAP Keying Gap Analysis April 2006 [5] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security, IEEE 802.11i", July 2004. [6] Ohba, Y., "Channel Binding Mechanism based on Parameter Binding in Key Derivation", draft-ohba-eap-channel-binding-00 (work in progress), January 2006. [7] Calhoun, P., "CAPWAP Protocol Specification", draft-ietf-capwap-protocol-specification-00 (work in progress), March 2006. [8] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress), November 2003. [9] Salowey, J. and P. Eronen, "EAP Key Derivation for Multiple Applications", draft-salowey-eap-key-deriv-02 (work in progress), October 2003. [10] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-02 (work in progress), March 2006. [11] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", RFC 4137, August 2005. [12] Chowdhury, K., "Problem Statement for the AMSK", draft-chowdhury-hoakey-amsk-ps-00 (work in progress), February 2006. [13] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work in progress), January 2006. [14] Giaretta, G., "Application Master Session Key (AMSK) for Mobile IPv6", draft-giaretta-mip6-amsk-01 (work in progress), March 2006. [15] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004", Dec 2004. Narayanan & Dondeti Expires October 22, 2006 [Page 18] Internet-Draft EAP Keying Gap Analysis April 2006 Authors' Addresses Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Narayanan & Dondeti Expires October 22, 2006 [Page 19] Internet-Draft EAP Keying Gap Analysis April 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayanan & Dondeti Expires October 22, 2006 [Page 20]