Network Working Group V. Narayanan Internet-Draft L. Dondeti Expires: December 21, 2006 QUALCOMM, Inc. June 19, 2006 EAP Extensions for Efficient Re-authentication draft-vidya-eap-er-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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The extensible authentication protocol (EAP) is a generic framework supporting multiple authentication methods. In the most common deployment scenario, an EAP peer and server authenticate each other through an authenticator; the server sends one of the session keys to the authenticator so that the peer and the authenticator can establish a security association for per-packet access enforcement. It is desirable to not repeat the entire process of authentication when the peer moves to another authenticator in an EAP method Narayanan & Dondeti Expires December 21, 2006 [Page 1] Internet-Draft EAP-ER June 2006 independent manner. This document specifies extensions to EAP keying hierarchy and the protocol itself to facilitate such efficient re- authentication between the peer and the server through a new authenticator. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. EAP-ER Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. EAP-ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . 6 4.1. Rationale for using EMSK as the top level key . . . . . . 6 4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. rRK Derivation and Properties . . . . . . . . . . . . 7 4.2.2. rIK Derivation and properties . . . . . . . . . . . . 8 4.2.3. rMSK Derivation and Properties . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10 5.1. EAP ER Bootstrapping . . . . . . . . . . . . . . . . . . . 10 5.2. Steps in the EAP ER protocol . . . . . . . . . . . . . . . 11 5.3. New EAP Messages . . . . . . . . . . . . . . . . . . . . . 12 5.3.1. EAP Re-authentication Response . . . . . . . . . . . . 13 5.3.2. EAP Re-authentication Information . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Narayanan & Dondeti Expires December 21, 2006 [Page 2] Internet-Draft EAP-ER June 2006 1. Introduction The extensible authentication protocol (EAP) is a generic framework for transport of methods that authenticate two parties; the authentication is either one-way or mutual. The primary purpose is network access control and a key generating method is recommended: The EAP keying hierarchy defines two keys that are derived at the top level - the master session key (MSK) and the extended MSK (EMSK). In the most common deployment scenario, an EAP peer and server authenticate each other through a third party known as the authenticator. The authenticator or an entity controlled by the authenticator enforces access control. After successful authentication, the server transports the MSK to the authenticator; the authenticator and the peer derive transient session keys (TSK) using the MSK as the authentication key or a key derivation key and use the TSK and use the TSK for per-packet access enforcement. EMSK usage is defined in [1]. Its primary purpose is to derive usage specific root keys (USRKs). Among the proposed use cases for USRKs is efficient re-authentication between the peer and the server through a different authenticator. When a peer moves from one authenticator to another, it is desirable to avoid full EAP authentication. The full EAP exchange with another run of the EAP method takes several round trips and significant time to complete, causing delays in handoff times. Some methods specify the use of state from the initial authentication to finish subsequent authentications to finish in fewer roundtrips. However, most methods do not offer this support. It is beneficial to have efficient re- authentication support in EAP rather than in individual methods. One of the EAP lower layers, IEEE 802.11, provides a mechanism to avoid this problem in a limited setting, by introducing a two-level key hierarchy. The EAP authenticator is collocated with what is known as an R0 Key Holder (R0-KH), which of course receives the MSK from the EAP server. A pairwise master key (PMK-R0) is derived from the second half (last 32 octets) of the MSK. Subsequently, the R0-KH derives an R1-PMK to be handed out to the attachment point of the peer. When the peer moves from one R1-KH to another, a new PMK-R1 is generated by the R0-KH and handed out to the new R1-KH. The transport protocol used between the R0-KH and the R1-KH is not specified at the moment. In some cases, a mobile may seldom move beyond the domain of the R0-KH and this model works well. A full EAP authentication will generally be repeated when the PMK-R0 expires. However, in general cases mobiles may roam beyond the domain of R0-KHs (or EAP authenticators), and the latency of full EAP authentication remains an issue. Narayanan & Dondeti Expires December 21, 2006 [Page 3] Internet-Draft EAP-ER June 2006 Furthermore, in the 802.11r architecture, the R0-KH may actually be located close to the edge, thereby creating a vulnerability: If the R0-KH is compromised, all PMK-R1s derived from the corresponding PMK- R0s will also be compromised. Another consideration is that there needs to be a key transfer protocol between the R0-KH and the R1-KH; in other words, there is either a star configuration of security associations between the key holder and a centralized entity that serves as the R0-KH, or if the first authenticator is the default R0-KH, there will be a full-mesh of security associations between all authenticators. This is undesirable. In other lower layers, key sharing across authenticators is sometimes used as a practical solution to lower handoff times. In that case, compromise of any authenticator results in compromise of several more sessions than for instance in case of 802.11r based systems. Thus, there is a need to design an efficient EAP re-authentication mechanism that allows a fresh key to be established between the peer and an authenticator without having to execute the EAP method again. This document provides a means of performing EAP Efficient re- authentication. Efficient Re-authentication is defined as a means of performing EAP re-authentication for a peer that has valid, unexpired key material from a previously performed EAP authentication. The protocol and the key hierarchy required for EAP-ER is described in this document. 2. EAP-ER Overview The first time the peer attaches to an authenticator, it performs a full EAP exchange with the EAP server; as a result an MSK is distributed to the authenticator. The MSK is then used by the authenticator and the peer to generate TSKs as needed. At the time of the initial EAP exchange, the peer and the server also derive an EMSK. From the EMSK, a Re-authentication Root Key (rRK) is derived. The rRK is only available to the peer and server and is never handed out to any other entity. Further, a Re-authentication Integrity Key (rIK) is derived from the rRK; the peer uses the rIK to provide proof of possession while performing an EAP-ER exchange at a later time. The rIK is also never handed out to any entity and is only available to the peer and server. At the time of the first EAP exchange, the peer receives the server-id (either from the EAP method or via an out-of-band mechanism from the server) for use in a subsequent exchange. The server caches Narayanan & Dondeti Expires December 21, 2006 [Page 4] Internet-Draft EAP-ER June 2006 the rRK and rIK for the peer, along with a key name. When the peer subsequently identifies a target authenticator that supports EAP-ER, it may perform an EAP-ER exchange; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP-ER, or prior to attachment. In response to an EAP Request Identity from the new authenticator, the peer sends an EAP Re-authentication Response, including the peer-id, the server-id, a sequence number, and a random nonce generated by the peer, PNonce. The EAP Re-authentication Response is integrity protected with the rIK. The authenticator routes this message to the server indicated by the server-id. If AAA proxies are present, they need to parse the server-id to route the message to the correct server. The server, after verifying proof of possession using the rIK, and freshness of the message, derives a Re-authentication MSK (rMSK) using the PNonce, a random nonce from the AS, the ASNonce, and the peer-id, from the rRK. The server then sends an EAP Re-authentication Information message including the ASNonce; this message is integrity protected with the rIK. The server transports the rMSK along with this message to the authenticator. The rMSK is transported in a manner similar to the MSK transport along with the EAP Success message in a regular EAP exchange. The peer uses the ASnonce and the other parameters (locally available to the peer and hence not transported) to compute the rMSK. The lower layer secure association protocol for TSK generation can be triggered after this point. 3. Design Goals The following are the design goals for the re-authentication protocol. o The protocol must be independent of the lower layer used to carry EAP. o The protocol must be EAP method independent. o The protocol must satisfy the AAA key management requirements specified in [6]. o The protocol should employ a simple and extensible key hierarchy. o The protocol should not interfere with the currently defined fast transition mechanisms in IEEE 802.11r. Narayanan & Dondeti Expires December 21, 2006 [Page 5] Internet-Draft EAP-ER June 2006 o The protocol should be compatible with AAA protocols (RADIUS and Diameter). o The protocol should involve no more than one roundtrip to the EAP server. o The protocol must not preclude the use of the CAPWAP protocol. o It must be feasible to execute this protocol between a peer and a target authenticator via a current authenticator, on lower layers that allow it. 4. EAP-ER Key Hierarchy We define a key hierarchy for EAP-ER, rooted at the EMSK derived as a result of a full EAP exchange. This document derives a Usage Specifc Root Key (USRK) in accordance with [1] for EAP-ER. The USRK designated for re-authentication is the rRK. The rRK is used to derive a rIK and rMSKs. The rRK and rIK are derived by the peer when the EMSK is available, and have the same lifetime as the EMSK. The derivation of the rRK and the rIK at the server is typically triggered by the first EAP-ER message sent by the peer following the corresponding full EAP session. The rMSK is derived on-demand at both ends when an EAP-ER exchange is performed. The figure above shows the key hierarchy with the rRK, rIK and rMSK. 4.1. Rationale for using EMSK as the top level key For efficient re-authentication, the proposal is to reuse key material from an earlier EAP authentication. The MSK and the EMSK are the two keys derived during that process. The MSK is delivered to the authenticator and used differently by different lower layers. For instance, IKEv2 uses the MSK for entity authentication alone, while lower layers like 802.11 and 802.16 use it in the secure association protocol to derive TSKs. Also, different lower layers use different parts of the MSK to derive other keys from it. For example, IEEE 802.11 uses the first 256 bits of the MSK for TSK derivation and 802.11's Task Group r (TGr) uses the second 256 bits to derive PMKs-R1. IEEE 802.16 uses the first 320 bits of the MSK to derive TSKs. Such disparate uses of the MSK at the lower layers makes it infeasible to use the MSK for a lower layer agnostic EAP-ER purpose. The EMSK, on the other hand, is currently kept at the peer and server Narayanan & Dondeti Expires December 21, 2006 [Page 6] Internet-Draft EAP-ER June 2006 and is never provided to any other entity. Hence, using the EMSK as the top level key for performing EAP-ER provides the possibility of making EAP-ER truly lower layer agnostic. 4.2. Key Derivation 4.2.1. rRK Derivation and Properties The rRK is derived from the EMSK using the prf+ operation defined in RFC4306 [2] as follows. rRK = prf+ (K, S), where, K = EMSK and S = rRK Label The rRK Label is an IANA-assigned ascii string "EAP Re-authentication Root Key" assigned from the USRK Key Label name space in accordance with [1]. This document requests an IANA registration for the rRK label specified above. The PRF used is specified in the EAP Re-authentication Response. The default PRF used is HMAC-SHA-256. Along with the rRK, a unique rRK name is derived to identify the rRK. The rRK name is derived as follows. rRK_name = NDF-64( EAP Session-ID, rRK Label ) where prf-64 is the first 64 bits from the output of the name derivation function (NDF). The NDF is a hash function, currently specified as SHA-256. The EAP Session-ID is the session-id of the full EAP exchange used to derive the EMSK used to derive the rRK. It MUST be the most recent full EAP exchange that occurred between the peer and the server. The rRK has the following properties. o The length of the rRK MUST at least be equal to the length of the MSK derived by the corresponding EAP session. o The rRK is to be used only as a root key for re-authentication and never used to directly protect any data. o The rRK is only used for derivation of rIK and rMSK as specified in this document. Narayanan & Dondeti Expires December 21, 2006 [Page 7] Internet-Draft EAP-ER June 2006 o The rRK must remain on the peer and the server and MUST NOT be transported to any other entity. o The rRK is cryptographically separate from any other USRK derived from the EMSK. o The lifetime of the rRK is the same as that of the EMSK. The rRK is expired when the EMSK expires and removed from use at that time. o If a new EMSK is derived due to a full EAP exchange, a new rRK from that EMSK must be derived for the purpose of subsequent EAP-ER exchanges. The new rRK MUST replace an existing rRK derived from a previous EMSK. 4.2.2. rIK Derivation and properties The re-authentication Integrity Key (rIK) is used for integrity protecting the EAP-ER exchange. This serves as the proof of possession of valid keying material from a previous full EAP exchange by the peer to the server. The rIK is derived from the rRK as follows. rIK = prf+ (rRK, "Re-authentication Integrity Key") The PRF used is the one specified in the EAP Re-authentication Response. The default PRF used is HMAC-SHA-256. The rIK name is derived as follows. rIK_name = prf-64 (rRK, "rIK Name") where prf-64 is the first 64 bits from the output of the PRF. The PRF used is HMAC-SHA-256. Unlike the rRK_name, the EAP session ID is not used to derive the rIK_name. This is done in order to avoid any collisions with USRK names. The key label used for USRKs is IANA registered, while the string "rIK Name" is not. The rIK has the following properties. o The length of the rIK depends on the MAC algorithm used in protecting the EAP-ER exchange. The MAC algorithm to be used is specified in the EAP Re-authentication Request by the peer. Narayanan & Dondeti Expires December 21, 2006 [Page 8] Internet-Draft EAP-ER June 2006 o The rIK is only used for integrity protection of the EAP-ER exchange as specified in this document. o The rIK MUST NOT be used to derive any other keys. o The rIK must remain on the peer and the server and MUST NOT be transported to any other entity. o The rIK is cryptographically separate from any other keys derived from the rRK. o The lifetime of the rIK is the same as that of the EMSK. The rIK is expired when the EMSK expires and removed from use at that time. o If a new rRK is derived, a new rIK from that rRK must be derived for the purpose of protecting subsequent EAP-ER exchanges. The new rIK MUST replace an existing rIK derived from a previous rRK. 4.2.3. rMSK Derivation and Properties The rMSK is derived at the peer and server and delivered to the authenticator. The rMSK is derived following an EAP-ER protocol exchange. The rMSK is derived from the rRK as follows. rMSK = prf+ (rRK, S), where S = PNonce || ASNonce || peer-id where || denotes concatenation. The PNonce is a nonce sent by the peer in the EAP Re-authentication Response message. The ASNonce is a nonce sent by the server in the EAP Re-authentication Information message. The peer-id is the ID of the peer exported by the EAP method executed in the corresponding EAP session. The PRF used is the one specified in the EAP Re-authentication Response. The default PRF used is HMAC-SHA-256. The rMSK name is derived as follows. rMSK_name = prf-64 (rRK, "rMSK Name") where prf-64 is the first 64 bits from the output of the PRF. The PRF used is HMAC-SHA-256. For the same reasons as in rIK_name, the rMSK name is also not Narayanan & Dondeti Expires December 21, 2006 [Page 9] Internet-Draft EAP-ER June 2006 derived from the EAP Session ID. The rMSK has the following properties. o The length of the rMSK MUST be the same as that of the MSK derived earlier in the EAP session at the time of the full EAP exchange. This is done so that lower layers can employ the secure association protocol with the rMSK as they do with the MSK. o The rRMSK is delivered to the authenticator and is used for the same purposes that an MSK is used at an authenticator. o The rMSK is cryptographically separate from any other keys derived from the rRK. o The lifetime of the rMSK is less than or equal to that of the rRK. It MUST NOT be greater than the lifetime of the rRK. o If a new rRK is derived, subsequent rMSKs must be derived from the new rRK. Previously delivered rMSKs may still be used until the expiry of the lifetime. o A given rMSK MUST NOT be shared by multiple authenticators. 5. Protocol Description The EAP re-authentication protocol results in a key shared between an EAP peer and a new/target EAP authenticator based on an EAP exchange between the EAP peer and the EAP server that occurred via a previous authenticator. Essentially, this protocol allows key material based on an earlier authentication to be delivered to a new authenticator without the execution of an EAP method. Further, this protocol finishes in a single roundtrip to the EAP server and satisfies the guidance for AAA key management of [6]. Next, it is independent of the lower layer and EAP methods. Finally, it is feasible to execute this protocol between a peer and a target authenticator via a current authenticator, on lower layers that allow it. 5.1. EAP ER Bootstrapping The first time the peer attaches to an authenticator, it performs a full EAP exchange, which results in the MSK being distributed to the authenticator. The MSK is then used by the authenticator to generate TSKs as needed. At the time of the initial EAP exchange, the peer and the server also derive an EMSK. From the EMSK, an rRK is derived. The rRK is only available to the peer and server and is never handed out to any other entity. Further, an rIK is derived Narayanan & Dondeti Expires December 21, 2006 [Page 10] Internet-Draft EAP-ER June 2006 from the rRK - the peer uses the rIK to provide proof of possession while performing an EAP-ER exchange at a later time. The rIK is also never handed out to any entity and is only available to the peer and server. At the time of the first EAP exchange, the peer receives the server-id (either from the EAP method or via an out-of-band mechanism from the server) to use in a subsequent exchange. The server caches the rRK and rIK for the peer, along with a key name (EAP session ID could potentially serve as the key name). For replay protection of EAP ER messages, a sequence number associated with the rIK is used. The sequence number is maintained by the EAP peer and the server, and initialized to zero when the rIK is generated. The peer increments the sequence number by one after it sends an EAP ER Re-authentication message. The server increments the sequence number when it receives and responds to the message. The retransmission and sequence number maintenance semantics are along the lines of the message-IDs and retransmission semantics of the IKEv2 protocol [2]. 5.2. Steps in the EAP ER protocol When a peer that has an active rRK and rIK identifies a new/target authenticator that supports EAP-ER, it may perform an advance EAP-ER exchange or when it attaches to the new authenticator supporting EAP-ER. The EAP-ER protocol has the following steps: In response to an EAP Request Identity from the new authenticator, the peer sends an EAP Re-authentication Response, including the peer-id, the server-id, and a freshly generated random nonce, called the PNonce, and the current value of the rIK sequence number; the message is integrity protected with the rIK. The authenticator routes the EAP Re-authentication Response message to the server indicated by the server-id. If AAA proxies are present, the proxy needs to parse the server-id to route the message to the correct server. The server uses the peer-id to lookup the rIK. It first verifies whether the sequence number is falls within a window of acceptable sequence numbers. If the window size is zero, the sequence number must be the expected sequence number. The server then proceeds to verify the integrity of the message using the rIK, thereby verifying proof of possession of that key by the peer. If the verifications fail, the server sends an EAP Failure message. Otherwise, it computes an rMSK from the rRK using the PNonce, a freshly generated random nonce, called the ASNonce and the peer-id as additional inputs to the key derivation. Narayanan & Dondeti Expires December 21, 2006 [Page 11] Internet-Draft EAP-ER June 2006 The server then sends an EAP Re-authentication Information message containing the sequence number, the ASNonce, and the rIK name; this message is also integrity protected with the rIK. The server transports the rMSK along with this message to the authenticator. The rMSK is transported in a manner similar to the MSK transport along with the EAP Success message in a regular EAP exchange. The peer looks up the sequence number to verify whether it is expecting a EAP Re-authentication Information message with that sequence number. It then looks up the rIK name and verifies the integrity of the message. This also verifies the proof of possession of the rIK of the server. If the verifications fail, the peer logs an error and stops the process; otherwise, it proceeds to the next step. The peer uses the ASnonce and other locally available parameters (the peer-id and PNonce ) to compute the rMSK. The lower layer secure association protocol can be triggered at this point. 5.3. New EAP Messages Two new EAP messages are defined for the purpose of EAP-ER: EAP Re- authentication Response and EAP Re-authentication Information. The packet format for these messages follows the EAP packet format defined in RFC3748 [3]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 1: EAP Re-authentication Packet Code 5 Re-authentication A new code value is defined for the purpose of EAP-ER. The code value of 5 is TBD based on IANA assignment. Identifier Narayanan & Dondeti Expires December 21, 2006 [Page 12] Internet-Draft EAP-ER June 2006 The Identifier field is one octet. The Identifier field MUST be the same if a Re-authentication packet is retransmitted due to a timeout while waiting for a response. Any new (non- retransmission) Requests MUST modify the Identifier field. The Identifier field of the Re-authentication Response MUST match that of the currently outstanding Request. An authenticator receiving a Re-authentication packet whose Identifier value does not match that of the currently outstanding Request MUST silently discard the packet. In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation. One way to achieve this is to start the Identifier at an initial value and increment it for each new Request. Initializing the first Identifier with a random number rather than starting from zero is recommended, since it makes sequence attacks somewhat more difficult. Since the Identifier space is unique to each session, authenticators are not restricted to only 256 simultaneous authentication conversations. Similarly, with re- authentication, an EAP conversation might continue over a long period of time, and is not limited to only 256 roundtrips. Type This field indicates the Type of EAP Re-authentication packet and is one octet in size. A single Type MUST be specified for each EAP Re-authentication packet. Two types are defined in this document - Response and Information. Type-Data The Type-Data field varies with the Type of Re-authentication packet. 5.3.1. EAP Re-authentication Response The EAP Re-authentication response packet contains the parameters shown in Figure Figure 2 : Narayanan & Dondeti Expires December 21, 2006 [Page 13] Internet-Draft EAP-ER June 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Peer-Id Len | Peer-Id ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server-Id Len | Server-Id ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SEQ | rIK name ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PNonce ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Crypto-Suite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: EAP Re-authentication Response Packet Peer-Id: There is a Peer-Id and the associated length field. The Peer-Id is the NAI of the peer, and is variable in length, not exceeding 256B. The Peer-Id can be used by the server to look up the rIK. Alternatively the rIK name can be used for this purpose also. The authenticator may use the Peer-Id to route the EAP packet. However, the preferred field for this purpose is the server-Id. Server-Id: Similar to the Peer-Id, there is a server-Id and the associated length field. EAP ER capable authenticators SHOULD use this field to route the EAP Re-authentication Response Packet. If local policy dictates otherwise, the packet may be routed based on the peer-Id. SEQ: A 16-octet sequence number is used for replay protection. The SEQ number field is initialized to zero. rIK name: This is a 64-octet field computed as specified in Section Section 4.2.2 and is used to identify the rIK with which the EAP ER messages are protected. PNonce: This is a fresh random nonce generated by the peer; it is to be used in rMSK derivation from the rRK. The nonce is variable in size. There is no nonce length as everything else is of either known size or associated with a length field. So, this field can be unambiguously parsed. Narayanan & Dondeti Expires December 21, 2006 [Page 14] Internet-Draft EAP-ER June 2006 Crypto Suite: This field indicates the integrity and if necessary the encryption algorithm used for EAP ER. Key lengths and output lengths are either indicated or are obvious from the crypto suite name. Authentication Tag: This field contains the integrity checksum over the EAP ER packet. The length of the field is indicated by the Crypto Suite. 5.3.1.1. Peer Operation When an EAP ER capable peer receives an EAP Request Identity message from an Authenticator, it checks to see if it has already authenticated to the network via another Authenticator. The peer can identify the network, for instance, through NAIs advertised by the Authenticator. If the peer has state from a previous authentication, and if it knows that the Authenticator is EAP ER capable, it sends an EAP re-authentication message instead of an EAP Response Identity message. The peer includes its identity and the identity of the server which holds state from the previous authentication, the current value of the rIK sequence number, the rIK name, and a freshly generated random nonce in the message. The nonce MUST be at least half-the-size of the rMSK. It then computes the integrity checksum over the EAP ER packet, excluding the Auth tag field itself, and includes the value in the Auth tag field. 5.3.1.2. Authenticator Operation An EAP ER capable Authenticator looks for the server ID in the EAP Re-authentication Response message to route the packet to the correct server. This is the RECOMMENDED mode of operation. The Authenticator's local policy may dictate that the message be routed based on the peer's NAI, also available in the EAP Re- authentication Response message. The Authenticator sends the message just as it forwards other EAP messages to the EAP server. 5.3.1.3. Server Operation The server uses the following steps in processing EAP Re- authentication messages: The server can use the peer-id or the rIK name to lookup the rIK. Narayanan & Dondeti Expires December 21, 2006 [Page 15] Internet-Draft EAP-ER June 2006 It first verifies whether the sequence number is falls within a window of acceptable sequence numbers. If the window size is zero, the sequence number must be the expected sequence number. The server then proceeds to verify the integrity of the message using the rIK, thereby verifying proof of possession of that key by the peer. If the verifications fail, the server sends an EAP Failure message. If the EAP Re-authentication message is valid, the EAP server computes an rMSK from the rRK using the PNonce, a freshly generated random nonce, called the ASNonce, and the peer-id as additional inputs to the key derivation. The server prepares an EAP Re-authentication Information message and sends it via AAA to the authenticator. The server includes the rMSK in the AAA message that carries the EAP Re-authentication Information message. 5.3.2. EAP Re-authentication Information The EAP Re-authentication Information packet contains the parameters shown in Figure Figure 3 : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | SEQ | rIK name... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASNonce ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Crypto-Suite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: EAP Re-authentication Information Packet The ASNonce is the only new field here, and hence that's described below: ASNonce: This is a fresh random nonce generated by the server; it is to be used in rMSK derivation from the rRK. The nonce is variable in size. There is no nonce length as everything else is of either known size or associated with a length field. So, this field can be unambiguously parsed. Narayanan & Dondeti Expires December 21, 2006 [Page 16] Internet-Draft EAP-ER June 2006 5.3.2.1. Authenticator Operation The Authenticator Operation is similar to that in processing an EAP success message. It extracts the rMSK just as it does an MSK from a AAA message containing an EAP success packet. 5.3.2.2. Peer Operation The peer uses the following steps in processing a EAP Re- authentication Information message: The peer checks to see if the sequence number in the received message is the same as the sequence number in the EAP Re- authentication Response it sent earlier. If the sequence number verification succeeds, it proceeds to the next step; otherwise, it logs an error. The peer uses the rIK name to lookup the appropriate rIK and verifies the integrity of the message. If the verification succeeds, it proceeds to the next step; otherwise, it logs an error. The peer then uses the ASNonce, the PNonce and other parameters to compute the rMSK. The lower layer secure association protocol can be triggered at this point. 6. Security Considerations This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in [6]. Cryptographic Algorithm Independence The EAP-ER protocol satisfies this requirement. The algorithm chosen by the peer for the PRF used in key derivaiton as well as for the MAC generation is indicated in the EAP Re- authentication Response message. If the chosen algorithms are unacceptable, the EAP server returns an EAP Failure message in response. Only when the specified algorithms are acceptable, the server proceeds with derivation of keys and verification of the proof of possession of relevant keying material by the peer. A full blown negotiation of algorithms cannot be provided in a single roundtrip protocol. Hence, while the protocol provides algorithm agility, it does not provide true negotiation. Narayanan & Dondeti Expires December 21, 2006 [Page 17] Internet-Draft EAP-ER June 2006 Strong, fresh session keys EAP-ER results in the derivation of strong, fresh keys that are unique for the given session. An rMSK is always derived on- demand when the peer requires a key with a new authenticator. Both the peer and the server contribute nonces that are used in the rMSK derivation. Further, the compromise of one rMSK does not result in the compromise of a different rMSK at any time. Limit key scope The scope of all the keys derived by EAP-ER are well defined. The rRK and rIK are never shared with any entity and always remain on the peer and the server. The rMSK is provided only to the authenticator through which the peer performs the EAP-ER exchange. No other authenticator is authorized to use that rMSK. Replay detection mechanism For replay protection of EAP ER messages, a sequence number associated with the rIK is used. The sequence number is maintained by the EAP peer and the server, and initialized to zero when the rIK is generated. The peer increments the sequence number by one after it sends an EAP ER Re- authentication message. The server increments the sequence number when it receives and responds to the message. Authenticate all parties The EAP-ER protocol provides mutual authentication of the peer and the server. Both parties need to possess the keying material resulted from a previous EAP exchange in order to successfully derive the required keys. Also, both the EAP Re- authentication Response and the EAP Re-authentication Information messages are integrity protected so that the peer and the server can verify each other. Keying material confidentiality The peer and the server derive the keys independently using parameters known to each entity. The rMSK is sent to the authenticator via the AAA protocol. It is RECOMMENDED that the AAA protocol be protected using IPsec or TLS so that the key can be sent encrypted to the authenticator. Narayanan & Dondeti Expires December 21, 2006 [Page 18] Internet-Draft EAP-ER June 2006 Confirm ciphersuite selection The same ciphersuite used as a result of the EAP session to which a particular EAP-ER exchange corresponds is used after the EAP-ER exchange as well. The EAP method executed during the full EAP exchange is responsible for confirming the ciphersuite selection. Prevent the Domino effect The compromise of one peer does not result in the compromise of keying material held by any other peer in the system. Also, the rMSK is meant for a single authenticator and is not shared with any other authenticator. Hence, the compromise of one authenticator does not lead to the compromise of sessions or keys held by any other authenticator in the system. Hence, the EAP-ER protocol allows prevention of the domino effect by appropriately defining key scopes. Bind key to its context All the keys derived for EAP-ER are bound to the appropriate context using appropriate key labels. Also, the rMSK is bound to the peer and server IDs. 7. IANA Considerations This document requires IANA registration of a new EAP Code: 5 Re- authentication. The new code value is defined for the purpose of EAP-ER. 8. Acknowledgments In writing this draft, we benefited from discussing the problem space and the protocol itself with a number of folks including, Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, and Jesse Walker. Note that this does not necessarily mean that they endorse the protocol or verified the correctness of it. 9. References 9.1. Normative References [1] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", Narayanan & Dondeti Expires December 21, 2006 [Page 19] Internet-Draft EAP-ER June 2006 draft-salowey-eap-emsk-deriv-00 (work in progress), May 2006. [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-13 (work in progress), May 2006. 9.2. Informative References [6] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-02 (work in progress), March 2006. Narayanan & Dondeti Expires December 21, 2006 [Page 20] Internet-Draft EAP-ER June 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 December 21, 2006 [Page 21] Internet-Draft EAP-ER June 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 December 21, 2006 [Page 22]