Network Working Group V. Narayanan Internet-Draft L. Dondeti Intended status: Standards Track QUALCOMM, Inc. Expires: November 5, 2007 May 4, 2007 EAP Re-authentication Extensions draft-ietf-hokey-erx-01 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 November 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The extensible authentication protocol (EAP) is a generic framework supporting multiple types of authentication methods. In the most common deployment scenario, a peer and server authenticate each other through an authenticator; the server sends the master session key (MSK) 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. This document Narayanan & Dondeti Expires November 5, 2007 [Page 1] Internet-Draft ERX May 2007 specifies, EAP Reauthentication Extensions (ERX), extensions to EAP and EAP keying hierarchy to support a EAP method-independent protocol for efficient Re-authentication between the peer and the server through an authenticator. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ERP Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. ERP with a Local ER Server . . . . . . . . . . . . . . . . 7 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Key Derivations and Properties . . . . . . . . . . . . . . 9 4.1.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . 9 4.1.2. rRK Properties . . . . . . . . . . . . . . . . . . . . 10 4.1.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . 11 4.1.4. rIK Properties . . . . . . . . . . . . . . . . . . . . 11 4.1.5. rMSK Derivation . . . . . . . . . . . . . . . . . . . 12 4.1.6. rMSK Properties . . . . . . . . . . . . . . . . . . . 12 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 13 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ERP Bootstrapping with a Local ER Server . . . . . . . 16 5.2. EAP Reauth Protocol . . . . . . . . . . . . . . . . . . . 16 5.2.1. Failure Handling . . . . . . . . . . . . . . . . . . . 18 5.3. New EAP Messages . . . . . . . . . . . . . . . . . . . . . 19 5.3.1. EAP Initiate Re-auth Packet . . . . . . . . . . . . . 20 5.3.2. EAP Finish Re-auth Packet . . . . . . . . . . . . . . 23 5.3.3. TV and TLV Attributes . . . . . . . . . . . . . . . . 25 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 26 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Narayanan & Dondeti Expires November 5, 2007 [Page 2] Internet-Draft ERX May 2007 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 to enforce access control: 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, a peer and a 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 for per-packet access enforcement. 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 optimize Re- authentications by reducing the computational overhead, but method- specific Re-authentication takes at least 2 roundtrips in most cases (e.g., [7]). It is also important to note that many methods do not offer support for Re-authentication. Thus, 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 for faster re-authentication 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); it receives the MSK from the EAP server as usual. 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 (the Extended Service Set, ESS in 802.11) and this model works well. A full EAP authentication is 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 November 5, 2007 [Page 3] Internet-Draft ERX May 2007 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 each 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. Neither option is desirable. 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 EAP sessions than for instance in case of 802.11r based systems. In conclusion, 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. The EAP Re-authentication problem statement is described in detail elsewhere [8]. This document specified EAP Reauthentication Extensions (ERX) for efficient re-authentication using EAP. The EAP Reauthentication Protocol (ERP) based on ERX supports EAP method independent 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 Reauthentication is described in this document. This document only specifies native EAP-based transport for this protocol and hence, requires support for the protocol on the authenticators as well. However, the protocol specified in this document can be transported in an EAP method-like fashion (using EAP Request/Response messages) to allow the operation over legacy authenticators that do not support the new ERP messages. The details of such a transport is outside the scope of this document. 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 [1]. This document uses terminology defined in [2] and in [3]. In addition, this document uses the following terms: Narayanan & Dondeti Expires November 5, 2007 [Page 4] Internet-Draft ERX May 2007 ER peer - An EAP peer that supports the EAP Reauth protocol ER Authenticator - An EAP authenticator that also supports the authenticator functionality for EAP Reauthentication described in this document. All references to "authenticator" in this document imply an ER authenticator, unless specifically noted otherwise. ER Server - An entity that performs the server portion of ERP described here. This entity may or may not be an EAP server. rRK - Re-authentication root Key, derived from the EMSK or as specified in [TBD]. rIK - Re-authentication Integrity Key, derived from the rRK. rMSK - Re-authentication MSK. This is a per-authenticator key, derived from the rRK. 3. ERP Overview Figure 1 shows the protocol exchange. 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 derive a Re-authentication Root Key (rRK). As noted below, the rRK may be derived from the EMSK or from a Domain Specific Root Key (DSRK). The rRK is only available to the peer and the ER 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 ERP 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 may obtain a server-id (either from the EAP method or via an out-of-band mechanism from the server) for use in a subsequent exchange. The EAP Reauth protocol supports explicit bootstrapping using which a server ID can be obtained by the peer at the end of a successful full EAP exchange. Alternatively, the peer may simply use a key name to identify the full EAP session. Particularly, when the ER state is duplicated among the different backend entities, a server ID is not required. The server caches the rRK and rIK for the peer, along with a key name. Narayanan & Dondeti Expires November 5, 2007 [Page 5] Internet-Draft ERX May 2007 Peer Authenticator Server ==== ============= ====== <-- EAP Request/ ----- Identity --- EAP Response/ ---> Identity --EAP Response/Identity-> <------------ EAP Method exchange-------------> <---MSK, EAP Success---- <---EAP Success---- Peer Authenticator Server ==== ============= ====== [<-- EAP Request/ ----- Identity] --- EAP Initiate/ ---> --EAP Initiate/ ---> Reauth/ Reauth/ [Bootstrap] [Bootstrap] <-- EAP Finish/ ---- <---rMSK,EAP Finish/-- Reauth/ Reauth/ [Bootstrap] [Bootstrap] Figure 1: ERP Exchange When the peer subsequently identifies a target authenticator that supports EAP Reauthentication, it performs an ERP exchange, as shown in the figure above as well; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP Reauthentication, or prior to attachment. The peer may initiate ERP by itself, or in response to an EAP Request Identity from the new authenticator. ERX adds two new messages to EAP: EAP Initiate and EAP Finish messages. The peer sends an EAP Initiate Re-auth message; it includes peer-id and the server-id and/or a temporary NAI based on the rIK name, and a sequence number for replay protection. The EAP Initiate Re-auth message is integrity protected with the rIK. The authenticator routes this message to the server indicated by the server-id. If a server-id is not present, the message may be routed Narayanan & Dondeti Expires November 5, 2007 [Page 6] Internet-Draft ERX May 2007 based on the peer-id or the temporary NAI or both. The server uses the peer-id and/or the rIK name to lookup the rIK. If a server-id is present, the Authenticator MUST use that identity in the AAA message so that AAA proxies route the message to the correct server. If the server-id is not present, the Authenticator uses NAI-based routing. The server, after verifying proof of possession of the rIK, and freshness of the message, derives a Re-authentication MSK (rMSK) from the rRK, using the sequence number and the peer-id as additional inputs. In response to the EAP Initiate Re-auth message, the server sends an EAP Finish Re-auth message; 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 that of the MSK along with the EAP Success message in a full EAP exchange. In an ERP bootstrap exchange, the peer may request the rRK lifetime to be sent to it. If so, the ER server sends the lifetime along with the EAP Finish Re-auth message. The peer verifies the replay protection and the origin of the message. It then uses the sequence number in the EAP Finish Re-auth message, and other parameters (locally available to the peer and hence not transported) to compute the rMSK. The lower layer TSK generation mechanism is ready to be triggered after this point. 3.1. ERP with a Local ER Server The defined ER extensions allow executing the ERP with a local ER server that may be topologically closer to the authenticator. The local ER server may be collocated with a local AAA server. The peer may learn about the presence of a local ER server in the network and the local domain (or ER server) name either via the lower layer or by means of ERP bootstrapping. Figure 2 shows the full EAP and subsequent local ERP exchange with a local ER server. Narayanan & Dondeti Expires November 5, 2007 [Page 7] Internet-Draft ERX May 2007 Peer Authenticator Local Server Home Server ==== ============= ========== =========== <-- EAP Request/ ----- Identity --- EAP Response/ ---> Identity --EAP Response/--> Identity --EAP Response/Identity-> [DSRK Req, Domain name] <------------------------ EAP Method exchange------------------> <---MSK, DSRK, EAP Success-- <---MSK, EAP Success-- <---EAP Success--- Peer Authenticator Local Server ==== ============= ============ [<-- EAP Request/ ----- Identity] --- EAP Initiate/ ---> --EAP Initiate/ ---> Reauth/ Reauth/ <-- EAP Finish/ ---- <---rMSK,EAP Finish/-- Reauth/ Reauth/ Figure 2: Local ERP Exchange As shown in Figure 2, the local ER server may be present in the path of the full EAP exchange (e.g., this may be one of the AAA entities in the path between the authenticator and the home EAP server of the peer). In that case, at the end of a full authentication exchange, the DSRK may be provided to the local ER server. Alternatively, the DSRK can be obtained at the time of an ERP bootstrap exchange with the home server. The local ER server then computes a DS-rRK and a DS-rIK (and the appropriate key names) from the DSRK as defined in Section 4.1.1 and Section 4.1.3 below. The peer also derives the DSRK, followed by the DS-rRK and the DS-rIK (and the appropriate key names) following the EAP or ERP bootstrap exchange. Narayanan & Dondeti Expires November 5, 2007 [Page 8] Internet-Draft ERX May 2007 Subsequently, when the peer attaches to an authenticator within the local ER domain, it may perform an ERP exchange with the local ER server to obtain an rMSK for the new authenticator. 4. ER Key Hierarchy We define a key hierarchy for ER, rooted at the rRK, and derived as a result of a full EAP exchange. The rRK may be derived from an EMSK or DSRK as specified in this document. For the purpose of rRK derivation, this document derives a Usage Specific Root Key (USRK) or a Domain Specific USRK (DS-USRK) in accordance with [3] for Reauthentication. The USRK designated for Re-authentication is the Re-authentication root key (rRK). A DS-USRK deisgnated for Re- authentication is the DS-rRK available to a local ER server in a particular domain. For simplicity, the keys are referred to without the DS label in the rest of the document. However, the scope of the various keys are limited to just the respective domains they are derived for, in the case of the domain specific keys. Based on the ER server with which the peer performs the ERP exchange, it knows the corresponding keys that must be used. The rRK is used to derive a rIK and one or more rMSKs. The figure below shows the key hierarchy with the rRK, rIK and rMSKs. rRK | +--------+--------+ | | | rIK rMSK1 ...rMSKn Figure 3: Re-authentication Key Hierarchy 4.1. Key Derivations and Properties 4.1.1. rRK Derivation The rRK may be derived from the EMSK or DSRK. This section provides the relevant key derivations for that purpose. The rRK is derived using the prf+ operation defined in RFC4306 [4] as follows. rRK = prf+ (K, S), where, Narayanan & Dondeti Expires November 5, 2007 [Page 9] Internet-Draft ERX May 2007 K = EMSK or K = DSRK and S = rRK Label The rRK Label is an IANA-assigned ASCII string "EAP Re-authentication Root Key" assigned from the Key Label name space in accordance with [3]. This document specifies IANA registration for the rRK label above. The PRF used MAY be the same as that used by the EAP method - using the PRF from the EAP method provides algorithm agility. Otherwise, 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 = prf-64 (rRK, "rRK Name") where prf-64 is the first 64 bits from the output of the PRF. The PRF is the same as that used in the derivation of the rRK. 4.1.2. rRK Properties The rRK has the following properties. These properties apply to the rRK regardless of the parent key used to derive it. o The length of the rRK MUST at least be equal to the length of the MSK or DSRK 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. o The rRK must remain on the peer and the server that derived it and MUST NOT be transported to any other entity. o The rRK is cryptographically separate from any other key derived from its parent key. o The lifetime of the rRK is never greater than that of its parent key. The rRK is expired when the parent key expires and removed from use at that time. Narayanan & Dondeti Expires November 5, 2007 [Page 10] Internet-Draft ERX May 2007 4.1.3. rIK Derivation The Re-authentication Integrity Key (rIK) is used for integrity protecting the ERP 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 MAY be the same as that used by the EAP method - using the PRF from the EAP method provides algorithm agility. Otherwise, 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 is the same as that used in the derivation of the rIK. 4.1.4. rIK Properties The rIK has the following properties. o The length of the rIK depends on the MAC algorithm used in protecting the ERP exchange. The MAC algorithm used may be specified in the ERP message sent by the peer. The default MAC algorithm is HMAC-SHA-256. o The rIK is only used for authentication of the ERP 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 never greater than that of its parent key. The rIK is expired when the EMSK expires and removed from use at that time. Narayanan & Dondeti Expires November 5, 2007 [Page 11] Internet-Draft ERX May 2007 4.1.5. rMSK Derivation The rMSK is derived at the peer and server and delivered to the authenticator. The rMSK is derived following an EAP Reauth protocol exchange. The rMSK is derived from the rRK as follows. rMSK = prf+ (rRK, SEQ), where The SEQ is the sequence number sent by the peer in the EAP Initiate Re-auth message. The PRF may be specified in the EAP Re-auth message. 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 may be specified in the EAP Re-auth message. 4.1.6. rMSK Properties 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 so that lower layers can treat the rMSK the same as they do the MSK. o The rMSK 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. Narayanan & Dondeti Expires November 5, 2007 [Page 12] Internet-Draft ERX May 2007 5. Protocol Description The EAP Reauth protocol results in a key shared between a peer and an authenticator based on a prior full EAP exchange between the peer and the EAP server. Essentially, this protocol allows key material based on an earlier authentication to be delivered to an authenticator without another execution of an EAP method. Further, this protocol finishes in a single roundtrip from the peer to the server and satisfies the guidance for AAA key management of [9]. Next, it is independent of the lower layer, and the EAP method used during the full EAP exchange. 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. ERP 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 as defined by specific lower layers. At the time of the initial EAP exchange, the peer and the server also derive an EMSK. Next, the peer and the server derive the rRK and the rIK as soon as the EMSK is available with the anticipation that ERP may be used by the peer if it plans to move to a new authenticator. The rIK name is also derived to serve as the index to the rIK to process ERP messages. We identify two types of bootstrapping for ERP: explicit and implicit bootstrapping. There are at least two scenarios to consider for Re- authentication. When the Re-auth messages are routed to the target domain, they may or may not be routed to the server that holds the rRK and the rIK. This is not an issue when there is a single ER server in the domain or when the state is synchronized across all servers in the domain. In that case, the peer does not need to know the identity of the server that holds the Re-authentication keys. There is also the case of the peer knowing the server id through other means, say via the EAP method or through out of band mechanisms. In those cases, ER bootstrapping is implicit. The peer initiates an ERP exchange only when it moves from one authenticator to another. The peer may initiate an explicit ER bootstrapping exchange if the server id is not available or if it is not known that the server id is valid or when it is not known that the server state is synchronized. In this case, the peer initiates the EAP Re-auth exchange, with the bootstrapping flag turned on, immediately after the full EAP authentication finishes. The following steps summarize the process: Narayanan & Dondeti Expires November 5, 2007 [Page 13] Internet-Draft ERX May 2007 o The peer sends the EAP Initiate Re-auth message with the bootstrapping flag turned on. It is recommended that the authenticator hold on to the state (e.g., called station id in RADIUS) that allows all messages of a full EAP conversation to be routed to the same server. The EAP Initiate Re-auth message contains one or more TLVs containing identification information to assist the authenticator further in routing the message to the appropriate server -- in this case to the server that holds the EMSK, rRK and rIK. * It is mandatory to send the rIKname either by itself, or as part of an NAI. The authenticator may use the NAI to route the EAP Re-auth Bootstrap Initiate message. * When the rIKname is not in the form of an NAI, the peer-id may be included. The peer-id may be in the form of a pseudonym for identity privacy. o In addition to the identities, the message contains a sequence number for replay protection, a crypto-suite, and an integrity checksum. The crypto-suite indicates the PRF and the authentication algorithm. The integrity checksum indicates that the message originated at the claimed entity, the peer indicated by the peer-id, or the rIK holder. o The peer may additionally set the lifetime flag to request that the rRK lifetime be sent to it. o When an ERP capable authenticator receives EAP Initiate Re-auth message from a peer, it looks for local EAP forwarding state corresponding to the peer's lower layer address and forwards the message accordingly. This forwarding is similar to that of messages of an EAP conversation. It is RECOMMENDED that an ERP capable authenticator store that forwarding information for a finite amount of time after the EAP Success message has been sent to the peer. * In the absence of forwarding state, the authenticator parses the message for the server-id. If that is present, the message is forwarded via AAA to that server. * If a server-id is not present, the authenticator parses the EAP Initiate Re-auth message to locate the rIKname, and if the rIKname is in the NAI form, uses that domain name to forward the message. * Otherwise, it finds the peer-id and uses the realm portion of the peer-id to route the EAP message to the appropriate server. Narayanan & Dondeti Expires November 5, 2007 [Page 14] Internet-Draft ERX May 2007 o Upon receipt of an EAP Initiate Re-auth message, the server verifies whether the message is fresh or a replay by evaluating whether the received sequence number is equal to or greater than the expected sequence number for that rIK. Next, it verifies the origin authentication of the message by looking up the rIK. If any of the checks fail, the server sends an EAP Finish Re-auth message with the relevant error value. This error MUST NOT have any correlation on any EAP Success message that may have been received by the authenticator and the peer earlier. If the message is well-formed and valid, the server prepares the EAP Finish Re-auth message. The bootstrap flag is set to indicate that this is a bootstrapping exchange. The message contains the following fields: * one or more server identities so that the peer can reach a server for Re-authentication through authenticators other than the initial authenticator. It is plausible that no server-id TLVs exist in the EAP Finish Re-auth message. In that case, it is assumed that server side state is replicated in all the servers in the corresponding domain. * A sequence number for replay protection. * The rIKname so that the peer can correctly identify the rIK to verify the integrity and origin authentication of the Finish message. * If the lifetime flag was set in the EAP Initiate Re-auth message, the ER server SHOULD include the rRK lifetime in the EAP Finish Re-auth message. * An authentication tag to prove that the EAP Finish Re-auth message originates at a server that possesses the relevant rIK. * An rMSK sent along with the EAP Finish Re-auth message, in a AAA attribute. Since the ER bootstrapping exchange is typically done immediately following the full EAP exchange, it is feasible that the process is completed through the same entity that served as the EAP authenticator for the full EAP exchange. In this case, the lower layer may already have derived the TSKs based on the MSK received earlier. The lower layer may then choose to ignore the rMSK that was received with the ER bootstrapping exchange. This must be negotiated at the lower layer to ensure appropriate action at the peer and authenticator. However, the bootstrapping exchange may be carried out via a new authenticator, in which case, the rMSK received must be used to derive TSKs for the lower layer. Narayanan & Dondeti Expires November 5, 2007 [Page 15] Internet-Draft ERX May 2007 5.1.1. ERP Bootstrapping with a Local ER Server When a local ER server is present, it may be in the path of the full EAP exchange performed by the peer. In this case, the local ER server SHOULD include a request for DSRK and its domain or server name along with the AAA message encapsulating the first EAP Response message sent by the peer. If the EAP exchange is successful, the server sends a DSRK (for the local ER server) along with the EAP Success message. The local ER server MUST extract the DSRK, if present, before forwarding the EAP Success message to the peer. Note that the MSK (also present along with the EAP Success message) is still extracted by the authenticator as per [2]. If the peer performs an ERP bootstrapping exchange when a local ER server is present, the local ER server MUST include the DSRK request and its domain name in the AAA message encapsulating the EAP Initiate Re-auth message sent by the peer. If the exchange is successful, the home ER server MUST include a DSRK along with the EAP Finish Re-auth message. The local ER server MUST extract the DSRK, if present, before forwarding the EAP Finish Re-auth message to the peer. When the server receives an EAP Initiate Re-auth message with the bootstrap flag set along with a DSRK request, it SHOULD return the domain or local ER server ID to which the DSRK was sent, in the EAP Finish Re-auth message. The other processing rules for the ERP bootstrapping exchange apply as well. When the peer receives an EAP Finish Re-auth message with the bootstrap flag set, if a local domain or server ID is present, it MUST use that to derive the appropriate DSRK, DS-rRK and DS-rIK. If not, the peer SHOULD derive the domain specific keys using the domain name it learnt via the lower layer. If the peer has no available domain name, it must assume that there is no local ER server available. The AAA attributes required to carry the DSRK request, local domain name and the DSRK itself along with the encapsulated EAP messages are TBD. 5.2. EAP Reauth Protocol When a peer that has an active rRK and rIK identifies a new/target authenticator that supports ERX, it may perform an ERP exchange either in advance or when it attaches to the new authenticator supporting ERX. ERP is typically a peer-initiated exchange, consisting of an EAP Initiate Re-auth and an EAP Finish Re-auth message. The ERP exchange may be performed with a local ER server (when one is present) or with the original EAP server. Narayanan & Dondeti Expires November 5, 2007 [Page 16] Internet-Draft ERX May 2007 It is plausible for the network to trigger the EAP Re-authentication process however. When an ERP capable authenticator sends an EAP Request Identity the peer may in response initiate the EAP Re- authentication exchange. Notes on authenticator state machine: The authenticator state machine needs to be modified to consider the EAP Re-authentication exchange as a "response" to the EAP Request Identity and transfer the state machine to follow the EAP Re- authentication exchange and determine Success or Failure of the exchange based on whether the EAP Finish Re-auth message is a Success or Failure. The authenticator MUST consider that it has received a response to the EAP Request Identity and cancel the corresponding retransmission timer. Notes on Operational Considerations at the Peer: ERP requires that the peer maintain retransmission timers for reliable transport of EAP Re-authentication messages. The reliability considerations of Section 4.3 of RFC 3748 apply with the peer as the retransmitting entity. The EAP Reauth protocol has the following steps: The peer sends an EAP Initiate Re-auth message including one or more identity TLVs: the rIKname, and optionally the peer-id and/or the server-id; also included are the peer's rIK sequence number, and a crypto-suite indicating the cryptographic algorithms used. The message is integrity protected with the rIK. When the peer is performing ERP with a local ER server, it MUST use the corresponding DS-rIK it shares with the local ER server. The peer MUST set the lifetime flag to request the rRK lifetime from the server. It may learn this to know when to trigger an EAP method exchange. The authenticator routes the EAP Initiate Re-auth message to the server indicated by the server-id. If the server-id is not present, the peer-id MUST be used to route the message if that is present. If neither the server-id nor the peer-id are present, the rIKname MUST be in the form of an NAI and that is used to forward the message via AAA. The server uses the rIKname to lookup the rIK. It first verifies whether the sequence number is equal to or greater than 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, Narayanan & Dondeti Expires November 5, 2007 [Page 17] Internet-Draft ERX May 2007 the server sends an EAP Finish Re-auth message with the Result flag set to '1' (Failure). Please see Section 5.2.1 for failure handling. Otherwise, it computes an rMSK from the rRK using the sequence number as the additional input to the key derivation. The server then sends an EAP Finish Re-auth message containing the rIK sequence number and the rIK name. The sequence number MUST be same as the received sequence number. The local copy of the sequence number is incremented by 1. The EAP Finish Re-auth message is also integrity protected with the rIK. The server may include the server-id with this message. If the lifetime flag was set in the EAP Initiate Re-auth message, the ER server SHOULD include the rRK lifetime in the EAP Finish Re-auth message. 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 Finish Re-auth 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 at 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 sequence number to compute the rMSK. The lower layer TSK generation processes can be triggered at this point. 5.2.1. Failure Handling If the processing of the EAP Initiate Re-auth message results in a failure, the ER server MUST send an EAP Finish Re-auth message with the Result flag set to '1'. If the server has a valid rIK for the peer, it MUST integrity protect the EAP Finish Re-auth failure message. The peer, upon receiving an EAP Finish Re-auth message with the Result flag set to '1', MUST verify the sequence number and the Authentication Tag to determine the validity of the message. If the replay and integrity checks are successful, the peer MUST assume failure of the exchange and terminate the ER state machine. If the replay and/or integrity checks fail, it may mean that the server did not have the rIK for the peer or that the failure message was sent by Narayanan & Dondeti Expires November 5, 2007 [Page 18] Internet-Draft ERX May 2007 an attacker. Hence, in this case, the peer SHOULD continue the ERP exchange per the retransmission timers before declaring a failure. More detailed failure processing will be specified in later versions of the document. 5.3. New EAP Messages Two new EAP messages are defined for the purpose of ERP: EAP Initiate Re-auth and EAP Finish Re-auth. The packet format for these messages follows the EAP packet format defined in RFC3748 [2]. 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 4: EAP Re-authentication Packet Code 5 Initiate 6 Finish Two new code values are defined for the purpose of ERP. The code values itself are TBD based on IANA assignment. Identifier The Identifier field is one octet. The Identifier field MUST be the same if a Initiate Re-auth packet is retransmitted due to a timeout while waiting for a Finish message. Any new (non- retransmission) Initiate message MUST use a new Identifier field. The Identifier field of the Finish Re-auth message MUST match that of the currently outstanding Initiate Re-auth message. A Peer or Authenticator receiving a Finish Re-auth message whose Identifier value does not match that of the currently outstanding Initiate Re-auth message MUST silently discard the packet. Narayanan & Dondeti Expires November 5, 2007 [Page 19] Internet-Draft ERX May 2007 In order to avoid confusion between new EAP Initiate Re-auth messages and retransmissions, the peer must choose a an Identifier value that is different from the previous Initiate message, especially if that exchange has not finished. It is RECOMMENDED that the authenticator clear EAP Re-auth state after 300 seconds. Type This field indicates that this is an ERP exchange. One type is defined in this document for this purpose - Re-auth (assigned Type 1). Type-Data The Type-Data field varies with the Type of Re-authentication packet. 5.3.1. EAP Initiate Re-auth Packet The EAP Re-authentication response packet contains the parameters shown in Figure 5 : 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 |R|B|L| Reserved| SEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TVs or TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Crypto-Suite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: EAP Initiate Re-auth Packet Flags 'R' - The R flag is set to 0 and ignored upon reception. Narayanan & Dondeti Expires November 5, 2007 [Page 20] Internet-Draft ERX May 2007 'B' - The B flag is used as the bootstrapping flag. If the flag is turned on, the message is a bootstrap message. 'L' - The L flag is used to request the rRK lifetime from the server. The rest of the 5 bits are set to 0 and ignored on reception. SEQ: A 16-bit sequence number is used for replay protection. The SEQ number field is initialized to zero every time a new rRK is derived. TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets. rIK name: This is carried in a TV payload. The Type is 1 and the value is a 64-bit field computed as specified in Section Section 4.1.3 and is used to identify the rIK with which the ERP messages are protected. rIK name as NAI: This is carried in a TLV payload. The Type is 2. The NAI is variable in length, not exceeding 256 octets. Peer-Id: This is a TLV payload. The Type is 3. The Peer-Id is the NAI of the peer, and is variable in length, not exceeding 256 octets. 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: This is a TLV payload. The Type is 4. The Server-Id is the FQDN of the server; it is variable in length, not exceeding 256 octets. Other types of server IDs such as IP addresses may be considered in future revisions of the draft. ER capable authenticators SHOULD use this field to route the EAP Initiate Re-auth Packet. If local policy dictates otherwise, the packet may be routed based on the peer-Id. Authenticator Identifier: This is a TLV payload. The Type is TBD (see Section 5.5 for additional discussion). The server sends the Authenticator Identifier so that the peer can verify the identity seen at the lower layer, if channel binding is to be supported. Narayanan & Dondeti Expires November 5, 2007 [Page 21] Internet-Draft ERX May 2007 Crypto Suite: This field indicates the integrity and if necessary the encryption algorithm used for ERP. 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 ERP packet. The length of the field is indicated by the Crypto Suite. 5.3.1.1. Peer Operation When an ER capable peer receives an EAP Request Identity message from an Authenticator, it checks to see if it has valid EAP state from a previous EAP authentication. If the peer has state from a previous authentication, and if it knows that the Authenticator is ER capable, it sends an EAP Initiate Re-auth message instead of an EAP Response Identity message. The peer may, upon attachment to an authenticator send an EAP Initiate Re-auth message in an unsolicited manner. 5.3.1.2. Authenticator Operation An ER capable Authenticator looks for the server ID in the EAP Initiate Re-auth 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 Initiate Re-auth message. The appropriate domain may be available as part of the rIKName. 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 uses the rIKname to lookup the rIK. It first verifies whether the sequence number is equal to or greater than 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 Finish Re-auth message with a Failure indication. Otherwise, it computes an rMSK from the rRK using the sequence number. Narayanan & Dondeti Expires November 5, 2007 [Page 22] Internet-Draft ERX May 2007 The server then sends an EAP Finish Re-auth message containing the rIK sequence number, and the rIK name; this message is also integrity protected with the rIK. The server may include one or more server-ids with this message. The server-id is for the peer to use to send future ERP messages. 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. 5.3.2. EAP Finish Re-auth Packet The EAP Finish Re-auth packet contains the parameters shown in Figure 6 : 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 |R|B|L| Reserved | SEQ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TVs or TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Crypto-Suite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: EAP Finish Re-auth Packet Flags 'R' - The R flag is used as the Result flag - when set to 0, it indicates success and when set to '1', it indicates a failure. When it is a failure, the Result Code attribute SHOULD be present in the message. Further rules on failure handling is described in Section 5.2.1. 'B' - The B flag is used as the bootstrapping flag. If the flag is turned on, the message is a bootstrap message. Narayanan & Dondeti Expires November 5, 2007 [Page 23] Internet-Draft ERX May 2007 'L' - The L flag is used to indicate the presence of the rRK lifetime TLV. The rest of the 5 bits are set to 0 and ignored on reception. SEQ: A 16-bit sequence number is used for replay protection. The SEQ number field is initialized to zero every time a new rRK is derived. TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets. rIK name: This is carried in a TV payload. The Type is 1 and the value is a 64-bit field computed as specified in Section Section 4.1.3 and is used to identify the rIK with which the ERP messages are protected. rIK name as NAI: This is carried in a TLV payload. The Type is 2. The NAI is variable in length, not exceeding 256 octets. Peer-Id: This is a TLV payload. The Type is 3. The Peer-Id is the NAI of the peer, and is variable in length, not exceeding 256 octets. 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: This is a TLV payload. The Type is 4. The Server-Id is the FQDN of the server; it is variable in length, not exceeding 256 octets. Other types of server IDs such as IP addresses may be considered in future revisions of the draft. ER capable authenticators SHOULD use this field to route the EAP Initiate Re-auth Packet. If local policy dictates otherwise, the packet may be routed based on the peer-Id. Authenticator Identifier: This is a TLV payload. The Type is TBD (see Section 5.5 for additional discussion). The server sends the Authenticator Identifier so that the peer can verify the identity seen at the lower layer, if channel binding is to be supported. Crypto Suite: This field indicates the integrity and if necessary the encryption algorithm used for ERP. Key lengths and output lengths are either indicated or are obvious from the crypto suite name. Narayanan & Dondeti Expires November 5, 2007 [Page 24] Internet-Draft ERX May 2007 Authentication Tag: This field contains the integrity checksum over the ERP packet. The length of the field is indicated by the Crypto Suite. 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 an EAP Finish Re-auth message: The peer first checks if the identifier in the EAP Finish Re-auth message is the expected value. The peer then checks to see if the sequence number in the received message is the same as the sequence number in the EAP Initiate Re- auth message; otherwise it logs an error. Next, it 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 sequence number and the peer-id to compute the rMSK. The lower layer TSK derivation process can be triggered at this point. 5.3.3. TV and TLV Attributes The TV attributes that may be present in the EAP Initiate or EAP Finish messages are of the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: TV Attribute Format Narayanan & Dondeti Expires November 5, 2007 [Page 25] Internet-Draft ERX May 2007 The TLV attributes that may be present in the EAP Initiate or EAP Finish messages are of the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: TLV Attribute Format The following Types are defined in this document: '1' - rIK name: TV Payload '2' - rIK name as NAI: This is a TLV payload '3' - Peer-Id: This is a TLV payload '4' - Server-Id: This is a TLV payload The TLV type range of 128-191 is reserved to carry channel binding information in the EAP Initiate and Reauth messages. Below are the current assignments (all of them are TLVs): '128' - Called-Station-Id '129' - Calling-Station-Id '130' - NAS-Identifier '131' - NAS-IP-Address '132' - NAS-IPv6-Address 5.4. Replay Protection For replay protection, ERP uses sequence numbers. The sequence number is initialized to zero in both directions. In the first EAP Initiate Re-auth message, the peer uses the sequence number zero or higher. Note that the when the sequence number rotates, the rIK must be changed. The server expects a sequence number of zero or higher. When the server receives an EAP Initiate Re-auth message, it uses the same sequence number in the EAP Finish Re-auth message. It increments the expected sequence number by 1. Narayanan & Dondeti Expires November 5, 2007 [Page 26] Internet-Draft ERX May 2007 If the peer sends an EAP Initiate Re-auth message, but does not receive a response, it retransmits the request (with no changes to the message itself) a pre-configured number of times before giving up. However, it is plausible that the server itself may have responded to the message and it was lost in transit. Thus the peer MUST increment the sequence number and use the new sequence number to send subsequent EAP Re-authentication messages. 5.5. Channel Binding ERP provides a protected facility to carry channel binding (CB) information, according to the guidelines in Section 7.15 of [2]. The TLV type range of 128-191 is reserved to carry CB information in the EAP Initiate and Finish Reauth messages. Called-Station-Id, Calling- Station-Id, NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples of channel binding information listed in RFC 3748 and they are assigned values 128-132. Other values may be added in future versions of this draft and the rest are IANA managed based on IETF Consensus [5]. 6. Security Considerations This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in [9]. Cryptographic Algorithm Independence The EAP Reauth protocol satisfies this requirement. The algorithm chosen by the peer for the PRF used in key derivation 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. Strong, fresh session keys ERP 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 Narayanan & Dondeti Expires November 5, 2007 [Page 27] Internet-Draft ERX May 2007 not result in the compromise of a different rMSK at any time. Limit key scope The scope of all the keys derived by ERP 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 ERP exchange. No other authenticator is authorized to use that rMSK. Replay detection mechanism For replay protection of ERP messages, a sequence number associated with the rIK is used. The sequence number is maintained by the 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 ERP message. The server increments the sequence number when it receives and responds to the message. Authenticate all parties The EAP Reauth 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. Confirm ciphersuite selection The same ciphersuite used as a result of the EAP session to which a particular ERP exchange corresponds is used after the ERP exchange as well. The EAP method executed during the full EAP exchange is responsible for confirming the ciphersuite selection. Narayanan & Dondeti Expires November 5, 2007 [Page 28] Internet-Draft ERX May 2007 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 Reauth protocol allows prevention of the domino effect by appropriately defining key scopes. Bind key to its context All the keys derived for ERP 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 two new EAP Codes: 5 (Initiate) and 6 (Finish). These values are in accordance with [2]. This document also requires IANA registration of a new Type related to Initiate and Finish: 1 (Re-auth). Additional type values are IANA managed and assigned based on IETF Consensus. Next, a number of type values corresponding to the TLVs within EAP Initiate and Finish messages. Those are as follows: o rIK name: TV Payload. The Type is 1 o rIK name as NAI: This is a TLV payload. The Type is 2. o Peer-Id: This is a TLV payload. The Type is 3. o Server-Id: This is a TLV payload. The Type is 4. o The TLV type range of 128-191 is reserved to carry CB information in the EAP Initiate and Reauth messages. Below are the current assignments (all of them are TLVs): * Called-Station-Id: 128 * Calling-Station-Id: 129 * NAS-Identifier: 130 Narayanan & Dondeti Expires November 5, 2007 [Page 29] Internet-Draft ERX May 2007 * NAS-IP-Address: 131 * NAS-IPv6-Address: 132 Other values may be added in future versions of this draft and the rest are IANA managed based on IETF Consensus. o 192-255 is reserved for Experimental/Private use. Further, this document registers a USRK label with a value "EAP Re- authentication Root Key" in accordance with [3]. 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, Jesse Walker, Charles Clancy, Michaela Vanderveen and other participants of the HOKEY working group. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [3] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-00 (work in progress), January 2007. [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-06 (work in progress), March 2007. [6] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-18 (work in Narayanan & Dondeti Expires November 5, 2007 [Page 30] Internet-Draft ERX May 2007 progress), February 2007. 9.2. Informative References [7] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP- AKA)", RFC 4187, January 2006. [8] Clancy, C., "Handover Key Management and Re-authentication Problem Statement", draft-ietf-hokey-reauth-ps-01 (work in progress), January 2007. [9] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-09 (work in progress), February 2007. Appendix A. Example ERP Exchange 0. Authenticator --> Peer: [EAP Request/Identity()] 1. Peer --> Authenticator: EAP Initiate/Re-auth( SEQ, rIKname, [peer-Id],[ER-server-Id], Crypto-suite, Auth-tag*) 1a. Authenticator --> Reauth-Server: AAA-Request{Authenticator-Id, EAP Initiate/Re-auth(SEQ, rIKname, [peer-Id], [ER-server-Id],Crypto-suite, Auth-tag*) 2. ER-Server --> Authenticator: AAA-Response{rMSK, EAP Finish/Re-auth(SEQ, rIKname,[peer-Id], [ER-server-Id],Crypto-suite,[CB-Info], Auth-tag*) 2b. Authenticator --> Peer : EAP Finish/Re-auth(SEQ, rIKname,[peer-Id], [ER-server-Id],Crypto-suite,[CB-Info], Auth-tag*) * Auth-tag computation is over the entire EAP Initiate/Finish message; the code values for Initiate and Finish are different and thus reflection attacks are mitigated. Figure 9: ERP Exchange Narayanan & Dondeti Expires November 5, 2007 [Page 31] Internet-Draft ERX May 2007 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 November 5, 2007 [Page 32] Internet-Draft ERX May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Narayanan & Dondeti Expires November 5, 2007 [Page 33]