--- 1/draft-ietf-hokey-rfc5296bis-00.txt 2010-10-20 12:16:23.000000000 +0200 +++ 2/draft-ietf-hokey-rfc5296bis-01.txt 2010-10-20 12:16:23.000000000 +0200 @@ -1,21 +1,23 @@ -Network Working Group G. Zorn, Ed. -Internet-Draft Network Zen -Obsoletes: 5296 (if approved) Q. Wu -Intended status: Standards Track Huawei -Expires: March 17, 2011 Z. Cao - China Mobile - September 13, 2010 +Network Working Group Q. Wu, Ed. +Internet-Draft Huawei +Obsoletes: 5296 (if approved) Z. Cao +Intended status: Standards Track China Mobile +Expires: April 23, 2011 Y. Shi + H3C + B. He + CATR + October 20, 2010 EAP Extensions for EAP Re-authentication Protocol (ERP) - draft-ietf-hokey-rfc5296bis-00 + draft-ietf-hokey-rfc5296bis-01 Abstract The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any @@ -30,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on March 17, 2011. + This Internet-Draft will expire on April 23, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,56 +66,56 @@ outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 7 - 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 9 - 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 12 - 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 13 - 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 - 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 14 - 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 15 + 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 9 + 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10 + 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 + 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 + 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 + 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 + 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 - 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 16 - 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 19 - 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 21 - 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 22 - 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 23 - 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 24 - 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 25 - 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 25 - 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25 - 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 27 - 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 30 - 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 31 - 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31 - 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 32 - 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 33 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 39 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 - A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 40 - A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 40 - Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 40 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 + 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 + 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 + 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 + 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 + 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 + 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 + 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 + 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 + 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26 + 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 + 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 + 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 + 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 + 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 + 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 34 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 + A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 + A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 + Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction The Extensible Authentication Protocol (EAP) is a an authentication framework that supports multiple authentication methods. The primary purpose is network access authentication, and a key-generating method is used when the lower layer wants to enforce access control. The EAP keying hierarchy defines two keys to be derived by all key- generating EAP methods: the Master Session Key (MSK) and the Extended MSK (EMSK). In the most common deployment scenario, an EAP peer and @@ -143,21 +145,21 @@ via other authenticators. Other solutions for fast re-authentication exist in the literature [MSKHierarchy]. In conclusion, to achieve low latency handovers, there is a need for a method-independent re-authentication protocol that completes in less than 2 round trips, preferably with a local server. The EAP re- authentication problem statement is described in detail in [RFC5169]. This document specifies EAP Re-authentication Extensions (ERXs) for efficient re-authentication using EAP. The protocol that uses these - extensions itself is referred to as the EAP Re-authentication + extensions is itself referred to as the EAP Re-authentication Protocol (ERP). It 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 re-authentication are described in this document. Note that to support ERP, lower-layer specifications may need to be revised to allow carrying EAP messages that have a code value higher than 4 and to accommodate the peer-initiated nature of ERP. Specifically, the IEEE802.1x specification must be revised and RFC 4306 must be updated to carry ERP messages. @@ -178,23 +180,22 @@ ER Authenticator - An entity that supports the authenticator functionality for EAP re-authentication 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. All references to "server" in this document imply an ER server, unless specifically noted otherwise. An ER server is a logical entity; - the home ER server is located on the same backend authentication - server as the EAP server in the home domain. The local ER server - may not necessarily be a full EAP server. + it may not necessarily be co-located with, or physically part of, + a full EAP server. ERX - EAP re-authentication extensions. ERP - EAP Re-authentication Protocol that uses the re- authentication extensions. rRK - re-authentication Root Key, derived from the EMSK or DSRK. rIK - re-authentication Integrity Key, derived from the rRK. @@ -219,65 +220,57 @@ ERP allows a peer and server to mutually verify proof of possession of keying material from an earlier EAP method run and to establish a security association between the peer and the authenticator. The authenticator acts as a pass-through entity for the Re-authentication Protocol in a manner similar to that of an EAP authenticator described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange between the peer and the server; it is independent of the lower layer and the EAP method used during the full EAP exchange. The ER server may be in the home domain or in the same (visited) domain as the peer - and the authenticator. + and the authenticator (i.e.,local domain). Figure 2 shows the protocol exchange. The first time the peer attaches to any network, it performs a full EAP exchange (shown in Figure 1) with the EAP server; as a result, an MSK is distributed to the EAP authenticator. The MSK is then used by the authenticator and the peer to establish TSKs as needed. At the time of the initial EAP exchange, the peer and the server also derive an EMSK, which is used to derive a re-authentication Root Key (rRK). More precisely, a re- authentication Root Key is derived from the EMSK or from a Domain- - Specific Root Key (DSRK), which itself is derived from the EMSK. The + Specific Root Key (DSRK), which is itself derived from the EMSK. 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 and the ER server use the rIK to provide proof of possession while performing an ERP exchange. The rIK is also never handed out to any entity and is only available to the peer and server. - When the ER server is in the home domain, the peer and the server use - the rIK and rRK derived from the EMSK; and when the ER server is not - in the home domain, they use the DS-rIK and DS-rRK corresponding to - the local domain. The domain of the ER server is identified by the - realm portion of the keyname-NAI in ERP messages. - -3.1. ERP With the Home ER Server - EAP Peer EAP Authenticator EAP Server ======== ================= ========== <--- EAP-Request/ ------ Identity ----- EAP Response/ ---> Identity ---AAA(EAP Response/Identity)--> <--- EAP Method -------> <------ AAA(EAP Method --------> exchange exchange) <----AAA(MSK, EAP-Success)------ <---EAP-Success--------- Figure 1: EAP Authentication - Peer Authenticator Server + Peer ER Authenticator ER Server ==== ============= ====== [<-- EAP-Initiate/ ----- Re-auth-Start] [<-- EAP-Request/ ------ Identity] ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> Re-auth/ Re-auth/ [Bootstrap] [Bootstrap]) @@ -292,21 +285,22 @@ Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this document for the purpose of EAP re-authentication. When the peer identifies a target authenticator that supports EAP re- authentication, it performs an ERP exchange, as shown in Figure 2; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP re-authentication, or prior to attachment. The peer initiates ERP by itself; it may also do so in response to an EAP-Initiate/Re-auth-Start message from the new authenticator. The EAP-Initiate/Re-auth-Start message allows the - authenticator to trigger the ERP exchange. + authenticator to trigger the ERP exchange. The EAP-Finish message + also can be used by the authenticator to announce local domain name. It is plausible that the authenticator does not know whether the peer supports ERP and whether the peer has performed a full EAP authentication through another authenticator. The authenticator MAY initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start message, and if there is no response, it will send the EAP-Request/ Identity message. Note that this avoids having two EAP messages in flight at the same time [RFC3748]. The authenticator may send the EAP-Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. If the peer does not already know, this @@ -366,106 +361,145 @@ In an ERP bootstrap exchange, the peer MAY request the server for the rRK lifetime. If so, the ER server sends the rRK lifetime in the EAP-Finish/Re-auth message. The peer verifies the replay protection and the integrity of the message. It then uses the sequence number in the EAP-Finish/Re-auth message to compute the rMSK. The lower-layer security association protocol is ready to be triggered after this point. + When the ER server is in the home domain, the peer and the server use + the rIK and rRK derived from the EMSK; and when the ER server is in + the local domain, they use the DS-rIK and DS-rRK corresponding to the + local domain. The domain of the ER server is identified by the realm + portion of the keyname-NAI in ERP messages. + +3.1. ERP With the Home ER Server + + If the peer is in the home domain and does not know the domain name ( + did not receive the domain name through the EAP-Initiate/ + Re-auth-Start message or via the lower-layer announcement, due to a + missed announcement or lack of support for domain name announcements + in a specific lower layer) or there is no the local server in the + same domain as the peer, it SHOULD initiate ERP bootstrap exchange + with the home ER server to obtain the domain name. + + The defined ER extensions allow executing the ERP with an ER server + in the home domain. The home ER server may be co- located with a + home AAA server. The ERP with the Home ER Server is the similar as + ERP exchange described in Figure 2. + + Peer ER Authenticator Home ER Server + ==== ============= ====== + + [<-- EAP-Initiate/ ----- + Re-auth-Start] + [<-- EAP-Request/ ------ + Identity] + + ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> + Re-auth/ Re-auth/ + [Bootstrap] [Bootstrap]) + + <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- + Re-auth/ Re-auth/ + [Bootstrap] [Bootstrap]) + + Note: [] brackets indicate optionality. + + Figure 3: ER ExplicitBootstrapping Exchange/ERP with the Home ER + Sever + 3.2. ERP with a Local ER Server The defined ER extensions allow executing the ERP with an ER server - in the local domain (access network). The local ER server may be co- - located with a local AAA server. The peer may learn about the - presence of a local ER server in the network and the local domain - name (or ER server name) either via the lower layer or by means of - ERP bootstrapping. The peer uses the domain name and the EMSK to - compute the DSRK and from that key, the DS-rRK; the peer also uses - the domain name in the realm portion of the keyName-NAI for using ERP - in the local domain. Figure 3 shows the full EAP and subsequent - local ERP exchange; Figure 4 shows it with a local ER server. + in the local domain (access network) if the peer moves out of home + domain. The local ER server may be co-located with a local AAA + server. The peer may learn about the presence of a local ER server + in the network and the local domain name (or ER server name) either + via the lower layer or by means of ERP exchange. The peer uses the + domain name and the EMSK to compute the DSRK and from that key, the + DS-rRK; the peer also uses the domain name in the realm portion of + the keyName-NAI for using ERP in the local domain. Figure 4 shows + the ER Implicit bootstrapping exchange through local ER + Server;Figure 5shows ERP with a local ER server. - Peer EAP Authenticator Local ER Server Home EAP Server + Peer EAP Authenticator Local AAA Agent Home EAP Server + /ER Authenticator /Local ER Server ==== ================= =============== =============== <-- EAP-Request/ -- Identity -- EAP Response/--> Identity --AAA(EAP Response/--> - Identity) --AAA(EAP Response/ --> - Identity, + Identity, --AAA(EAP Response/ --> + [domain name]) Identity, [DSRK Request, domain name]) <------------------------ EAP Method exchange------------------> <---AAA(MSK, DSRK, ---- EMSKname, EAP-Success) <--- AAA(MSK, ----- EAP-Success) <---EAP-Success----- - Figure 3: Local ERP Exchange, Initial EAP Exchange + Figure 4: Local ERP Exchange, Initial EAP Exchange Peer ER Authenticator Local ER Server ==== ================ =============== [<-- EAP-Initiate/ -------- Re-auth-Start] [<-- EAP-Request/ --------- Identity] ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> Re-auth Re-auth) <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- Re-auth Re-auth) - Figure 4: Local ERP Exchange + Figure 5: Local ERP Exchange As shown in Figure 4, 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, - such as AAA proxies, in the path between the authenticator and the - home EAP server of the peer). In that case, the ER server requests - the DSRK by sending the domain name to the EAP server. In response, - the EAP server computes the DSRK by following the procedure specified - in [RFC5295] and sends the DSRK and the key name, EMSKname, to the ER - server in the claimed domain. The local domain is responsible for - announcing that same domain name via the lower layer to the peer. - - If the peer does not know the domain name (did not receive the domain - name via the lower-layer announcement, due to a missed announcement - or lack of support for domain name announcements in a specific lower - layer), it SHOULD initiate ERP bootstrap exchange with the home ER - server to obtain the domain name. The local ER server SHALL request - the home AAA server for the DSRK by sending the domain name in the - AAA message that carries the EAP-Initiate/Re-auth bootstrap message. - The local ER server MUST be in the path from the peer to the home ER - server. If it is not, it cannot request the DSRK. + such as AAA proxies, in the path between the EAP authenticator and + the home EAP server of the peer). In that case, the local ER server + requests the DSRK by sending the domain name to the home EAP server + through AAA message. In response, the home EAP server computes the + DSRK by following the procedure specified in [RFC5295] and sends the + DSRK and the key name, EMSKname, to the ER server in the claimed + domain (i.e., local ER Server). The local domain is responsible for + announcing that same domain name via the lower layer to the peer, + e.g., DHCP based local domain name discovery specified in + [I-D.ietf-hokey-ldn-discovery], or through the EAP-Initiate/ + Re-auth-Start message during subsequent ERP with local ER server. After receiving the DSRK and the EMSKname, the local ER server computes the DS-rRK and the DS-rIK from the DSRK as defined in Sections 4.1 and 4.3 below. After receiving the domain name, the peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys are referred to by a keyName-NAI formed as follows: the username part of the NAI is the EMSKname, the realm portion of the NAI is the domain name. Both parties also maintain a sequence number (initialized to zero) corresponding to the specific keyName-NAI. Subsequently, when the peer attaches to an authenticator within the local domain, it may perform an ERP exchange with the local ER server - to obtain an rMSK for the new authenticator. + to obtain an rMSK for the new authenticator. The ERP with the local + ER Server is the similar as ERP exchange described in Figure 2. 4. ER Key Hierarchy Each time the peer re-authenticates to the network, the peer and the authenticator establish an rMSK. The rMSK serves the same purposes that an MSK, which is the result of full EAP authentication, serves. To prove possession of the rRK, we specify the derivation of another key, the rIK. These keys are derived from the rRK. Together they constitute the ER key hierarchy. @@ -486,21 +520,21 @@ The rRK is used to derive an rIK, and rMSKs for one or more authenticators. The figure below shows the key hierarchy with the rRK, rIK, and rMSKs. rRK | +--------+--------+ | | | rIK rMSK1 ...rMSKn - Figure 5: Re-authentication Key Hierarchy + Figure 6: Re-authentication Key Hierarchy The derivations in this document are according to [RFC5295]. Key derivations and field encodings, where unspecified, default to that document. 4.1. rRK Derivation The rRK may be derived from the EMSK or DSRK. This section provides the relevant key derivations for that purpose. @@ -684,73 +717,73 @@ 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 Details 5.1. ERP Bootstrapping We identify two types of bootstrapping for ERP: explicit and implicit - bootstrapping. In implicit bootstrapping, the local ER server SHOULD - include its domain name and SHOULD request the DSRK from the home AAA - server during the initial EAP exchange, in the AAA message - encapsulating the first EAP Response message sent by the peer. If - the EAP exchange is successful, the server sends the DSRK for the - local ER server (derived using the EMSK and the domain name as - specified in [RFC5295]), EMSKname, and DSRK lifetime along with the - EAP-Success message. The local ER server MUST extract the DSRK, - EMSKname, and DSRK lifetime (if present) before forwarding the EAP- - Success message to the peer, as specified in [I-D.ietf-dime-erp]. - Note that the MSK (also present along with the EAP Success message) - is extracted by the EAP authenticator as usual. The peer learns the - domain name through the EAP-Initiate/Re-auth-Start message or via - lower-layer announcements. When the domain name is available to the - peer during or after the full EAP authentication, it attempts to use - ERP when it associates with a new authenticator. + bootstrapping. In implicit bootstrapping, the local AAA client or + agent supporting EAP re-authentication SHOULD include its domain name + and SHOULD request the DSRK from the home AAA server during the + initial EAP exchange, in the AAA message encapsulating the first EAP + Response message sent by the peer. If such EAP exchange is + successful, the home EAP server sends the DSRK for the specified + local AAA client or agent (derived using the EMSK and the domain name + as specified in [RFC5295]), EMSKname, and DSRK lifetime along with + the EAP-Success message. The local AAA client or agent MUST extract + the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding + the EAP-Success message to the peer, as specified in + [I-D.ietf-dime-erp]. Note that the MSK (also present along with the + EAP Success message) is extracted by the EAP authenticator as usual. + The peer learns the domain name through the EAP-Initiate/ + Re-auth-Start message, lower-layer announcements + [I-D.ietf-hokey-ldn-discovery] or via ER Explicit bootstrapping + exchange. When the domain name is available to the peer during or + after the full EAP authentication, it attempts to use ERP when it + associates with a new authenticator. If the peer does not know the domain name (did not receive the domain - name via the lower-layer announcement, due to a missed announcement - or lack of support for domain name announcements in a specific lower - layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with - the bootstrap flag turned on) with the home ER server to obtain the - domain name. The local ER server behavior is the same as described - above. The peer MAY also initiate bootstrapping to fetch information - such as the rRK lifetime from the AAA server. + name through the EAP-Initiate/Re-auth-Start message or via the lower- + layer announcement, due to a missed announcement or lack of support + for domain name announcements in a specific lower layer), it SHOULD + initiate Explicit ER bootstrap exchange (ERP exchange with the + bootstrap flag turned on) with the ER server in the same (visited) + domain as the peer to obtain the local domain name. The peer MAY + also initiate bootstrapping to fetch information such as the rRK + lifetime from the AAA server. The following steps describe the ERP explicit bootstrapping process: o The peer sends the EAP-Initiate/Re-auth message with the bootstrapping flag turned on. The bootstrap message is always - sent to the home AAA server, and the keyname-NAI attribute in the + sent to the ER server, and the keyname-NAI attribute in the bootstrap message is constructed as follows: the username portion of the NAI contains the EMSKname, and the realm portion contains the home domain name. o In addition, the message MUST contain a sequence number for replay protection, a cryptosuite, and an integrity checksum. The cryptosuite indicates the authentication algorithm. The integrity checksum indicates that the message originated at the claimed entity, the peer indicated by the Peer-ID, or the rIKname. o The peer MAY additionally set the lifetime flag to request the key lifetimes. o When an ERP-capable authenticator receives the EAP-Initiate/ Re-auth message from a peer, it copies the contents of the keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The rest of the process is similar to that described in [RFC3579]. - o If 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. - o Upon receipt of an EAP-Initiate/Re-auth message, the server verifies whether the message is fresh or is a replay by evaluating whether the received sequence number is equal to or greater than the expected sequence number for that rIK. The server then verifies to ensure that the cryptosuite used by the peer is acceptable. 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 Result flag set to '1'. Please refer to Section 5.2.2 for details on failure handling. This error MUST NOT have any correlation to any EAP- @@ -765,46 +798,47 @@ * The same keyName-NAI as in the EAP-Initiate/Re-auth message. * If the lifetime flag was set in the EAP-Initiate/Re-auth message, the ER server SHOULD include the rRK lifetime and the rMSK lifetime in the EAP-Finish/Re-auth message. The server may have a local policy for the network to maintain and enforce lifetime unilaterally. In such cases, the server need not respond to the peer's request for the lifetime. - * If the bootstrap flag is set and a DSRK request is received, - the server MUST include the domain name to which the DSRK is - being sent. + * If the bootstrap flag is set, the ER server MUST include the + domain name to which the DSRK is being sent along with the EAP- + Finish/Re-auth message. - * If the home ER server verifies the authorization of a local - domain server, it MAY include the Authorization Indication TLV - to indicate to the peer that the server (that received the DSRK + * If the ER server verifies the authorization of a local domain + server, it MAY include the Authorization Indication TLV to + indicate to the peer that the server (that received the DSRK and that is advertising the domain included in the domain name TLV) is authorized. * An authentication tag MUST be included to prove that the EAP- Finish/Re-auth message originates at a server that possesses the rIK corresponding to the EMSKname-NAI. - o If the ERP exchange is successful, and the local ER server sent a - DSRK request, the home ER server MUST include the DSRK for the - local ER server (derived using the EMSK and the domain name as - specified in [RFC5295]), EMSKname, and DSRK lifetime along with - the EAP-Finish/Re-auth message. + o If the ERP exchange is successful, the ER server SHOULD request + the DSRK from the home EAP server during the initial EAP exchange + as specified in [I-D.ietf-dime-local-keytran], the home EAP server + MUST include the DSRK for the local ER server (derived using the + EMSK and the domain name as specified in [RFC5295]), EMSKname, and + DSRK lifetime along with the EAP-Finish/Re-auth message. o In addition, the rMSK is sent along with the EAP-Finish/Re-auth message, in a AAA attribute [I-D.ietf-dime-erp]. - o The local ER server MUST extract the DSRK, EMSKname, and DSRK - lifetime (if present), before forwarding the EAP-Finish/Re-auth - message to the peer, as specified in [I-D.ietf-dime-erp]. + o The ER server MUST extract the DSRK, EMSKname, and DSRK lifetime + (if present) before forwarding the EAP-Success message to the + peer, as specified in [I-D.ietf-dime-erp]. o The authenticator receives the rMSK. o When the peer receives an EAP-Finish/Re-auth message with the bootstrap flag set, if a local domain name is present, it MUST use that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- NAI, and initialize the replay counter for the DS-rIK. If not, the peer SHOULD derive the domain-specific keys using the domain name it learned via the lower layer or from the EAP-Initiate/ Re-auth-Start message. If the peer does not know the domain name, @@ -1013,21 +1047,21 @@ packet format defined in RFC 3748 [RFC3748]. 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 6: EAP Packet + Figure 7: EAP Packet Code 5 Initiate 6 Finish Two new code values are defined for the purpose of ERP. Identifier @@ -1058,31 +1092,31 @@ auth-Start (assigned Type 1) and Re-auth (assigned Type 2). Type-Data The Type-Data field varies with the Type of re-authentication packet. 5.3.1. EAP-Initiate/Re-auth-Start Packet The EAP-Initiate/Re-auth-Start packet contains the parameters shown - in Figure 7. + in Figure 8. 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 | Reserved | 1 or more TVs or TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 7: EAP-Initiate/Re-auth-Start Packet + Figure 8: EAP-Initiate/Re-auth-Start Packet Type = 1. Reserved, MUST be zero. Set to zero on transmission and ignored on reception. One or more TVs or TLVs are used to convey information to the peer; for instance, the authenticator may send the domain name to the peer. @@ -1091,21 +1125,21 @@ 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. Domain-Name: This is a TLV payload. The Type is 4. The domain name is to be used as the realm in an NAI [RFC4282]. The Domain-Name attribute SHOULD be present in an EAP-Initiate/ Re-auth-Start message. In addition, channel binding information MAY be included; see - Section 5.5 for discussion. See Figure 11 for parameter + Section 5.5 for discussion. See Figure 12 for parameter specification. 5.3.1.1. Authenticator Operation The authenticator MAY send the EAP-Initiate/Re-auth-Start message to indicate support for ERP to the peer and to initiate ERP if the peer has already performed full EAP authentication and has unexpired key material. The authenticator SHOULD include the domain name TLV to allow the peer to learn it without lower-layer support or the ERP bootstrapping exchange. @@ -1124,42 +1158,43 @@ the EAP-Initiate/Re-auth-Start message from the authenticator. If the peer does not recognize the Initiate code value, it silently discards the message. If the peer has already sent the EAP-Initiate/ Re-auth message to begin the ERP exchange, it silently discards the message. If the EAP-Initiate/Re-auth-Start message contains the domain name, and if the peer does not already have the domain information, the peer SHOULD use the domain name to compute the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start - an ERP exchange with the local ER server. If the peer has already - initiated an ERP exchange with the home ER server, it MAY choose to - not start an ERP exchange with the local ER server. + an ERP exchange with the local ER server. If there are the local ER + server between the peer and the home ER server and the peer has + already initiated an ERP exchange with the local ER server, it SHOULD + choose to not start an ERP exchange with the home ER server. 5.3.2. EAP-Initiate/Re-auth Packet The EAP-Initiate/Re-auth packet contains the parameters shown in - Figure 8. + Figure 9. 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cryptosuite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 8: EAP-Initiate/Re-auth Packet + Figure 9: EAP-Initiate/Re-auth Packet Type = 2. Flags 'R' - The R flag is set to 0 and ignored upon reception. 'B' - The B flag is used as the bootstrapping flag. If the flag is turned on, the message is a bootstrap message. @@ -1184,21 +1219,21 @@ hexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 128 octets. If the rIK is derived from the EMSK, the realm part of the NAI is the home domain name, and if the rIK is derived from a DSRK, the realm part of the NAI is the domain name used in the derivation of the DSRK. The NAI syntax follows [RFC4282]. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/ Re-auth packet. In addition, channel binding information MAY be included; see - Section 5.5 for discussion. See Figure 11 for parameter + Section 5.5 for discussion. See Figure 12 for parameter specification. Cryptosuite: This field indicates the integrity algorithm used for ERP. Key lengths and output lengths are either indicated or are obvious from the cryptosuite name. We specify some cryptosuites below: * 0 RESERVED * 1 HMAC-SHA256-64 @@ -1210,35 +1245,35 @@ HMAC-SHA256-128 is mandatory to implement and should be enabled in the default configuration. Authentication Tag: This field contains the integrity checksum over the ERP packet, excluding the authentication tag field itself. The length of the field is indicated by the Cryptosuite. 5.3.3. EAP-Finish/Re-auth Packet The EAP-Finish/Re-auth packet contains the parameters shown in - Figure 9. + Figure 10. 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cryptosuite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 9: EAP-Finish/Re-auth Packet + Figure 10: EAP-Finish/Re-auth Packet Type = 2. 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. 'B' - The B flag is used as the bootstrapping flag. If the flag is turned on, the message is a bootstrap message. @@ -1281,45 +1316,45 @@ attribute SHOULD be present. Domain-Name: This is a TLV payload. The Type is 4. The domain name is to be used as the realm in an NAI [RFC4282]. Domain- Name attribute MUST be present in an EAP-Finish/Re-auth message if the bootstrapping flag is set and if the local ER server sent a DSRK request. List of cryptosuites: This is a TLV payload. The Type is 5. The value field contains a list of cryptosuites, each of size 1 - octet. The cryptosuite values are as specified in Figure 8. + octet. The cryptosuite values are as specified in Figure 9. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal to the peer about its cryptographic algorithm capabilities. Authorization Indication: This is a TLV payload. The Type is 6. This attribute MAY be included in the EAP-Finish/Re-auth message when a DSRK is delivered to a local ER server and if - the home ER server can verify the authorization of the local ER - server to advertise the domain name included in the domain TLV - in the same message. The value field in the TLV contains an - authentication tag computed over the entire packet, starting + the home EAP server can verify the authorization of the local + ER server to advertise the domain name included in the domain + TLV in the same message. The value field in the TLV contains + an authentication tag computed over the entire packet, starting from the first bit of the code field to the last bit of the cryptosuite field, with the value field of the Authorization Indication TLV filled with all 0s for the computation. The key used for the computation MUST be derived from the EMSK with key label "DSRK Delivery Authorized Key@ietf.org" and optional data containing an ASCII string representing the key management domain that the DSRK is being derived for. In addition, channel binding information MAY be included: see - Section 5.5 for discussion. See Figure 11 for parameter + Section 5.5 for discussion. See Figure 12 for parameter specification. The server sends this information so that the peer can verify the information seen at the lower layer, if channel binding is to be supported. Cryptosuite: This field indicates the integrity algorithm and the PRF used for ERP. Key lengths and output lengths are either indicated or are obvious from the cryptosuite name. Authentication Tag: This field contains the integrity checksum over the ERP packet, excluding the authentication tag field @@ -1329,32 +1364,32 @@ 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 10: TV Attribute Format + Figure 11: TV Attribute Format 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 11: TLV Attribute Format + Figure 12: TLV Attribute Format The following Types are defined in this document: '1' - keyName-NAI: This is a TLV payload. '2' - rRK Lifetime: This is a TV payload. '3' - rMSK Lifetime: This is a TV payload. '4' - domain name: This is a TLV payload. @@ -1595,27 +1630,27 @@ keys derived from it. Moreover, there is no forward secrecy within ERP. Thus, compromise of an DSRK retroactively compromises all ERP keys. It is RECOMMENDED that the AAA protocol be protected using IPsec or TLS so that the keys are protected in transit. Note, however, that keys may be exposed to AAA proxies along the way and compromise of any of those proxies may result in compromise of keys being transported through them. - The home ER server MUST NOT hand out a given DSRK to a local + The home EAP server MUST NOT hand out a given DSRK to a local domain server more than once, unless it can verify that the entity receiving the DSRK after the first time is the same as - that received the DSRK originally. If the home ER server + that received the DSRK originally. If the home EAP server verifies authorization of a local domain server, it MAY hand out the DSRK to that domain more than once. In this case, the - home ER server includes the Authorization Indication TLV to + home EAP server includes the Authorization Indication TLV to assure the peer that DSRK delivery is secure. Confirm cryptosuite selection Crypto algorithms for integrity and key derivation in the context of ERP MAY be the same as that used by the EAP method. In that case, the EAP method is responsible for confirming the cryptosuite selection. Furthermore, the cryptosuite is included in the ERP exchange by the peer and confirmed by the server. The protocol allows the server to reject the @@ -1695,22 +1730,22 @@ To prevent such DoS attacks, an ERP failure should not result in deletion of any authorization state established by a full EAP exchange. Alternatively, the lower layers and AAA protocols may define mechanisms to allow two link-layer security associations (SAs) derived from different EAP keying materials for the same peer to exist so that smooth migration from the current link layer SA to the new one is possible during rekey. These mechanisms prevent the link layer connections from being terminated when a re-authentication procedure fails due to the bogus EAP-Initiate/Re-auth message. - When a DSRK is sent from a home ER server to a local domain server or - when a rMSK is sent from an ER server to an authenticator, in the + When a DSRK is sent from a home EAP server to a local domain server + or when a rMSK is sent from an ER server to an authenticator, in the absence of end-to-end security between the entity that is sending the key and the entity receiving the key, it is plausible for other entities to get access to keys being sent to an ER server in another domain. This mode of key transport is similar to that of MSK transport in the context of EAP authentication. We further observe that ERP is for access authentication and does not support end-to-end data security. In typical implementations, the traffic is in the clear beyond the access control enforcement point (the authenticator or an entity delegated by the authenticator for access control enforcement). The model works as long as entities in the middle of @@ -1746,20 +1781,31 @@ Extended Master Session Key (EMSK)", RFC 5295, August 2008. 10.2. Informative References [I-D.ietf-dime-erp] Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter Support for the EAP Re-authentication Protocol (ERP)", draft-ietf-dime-erp-04 (work in progress), September 2010. + [I-D.ietf-dime-local-keytran] + , Q. and G. , "Diameter Attribute-Value Pairs for + Cryptographic Key Transport", + draft-ietf-dime-local-keytran-07 (work in progress), + July 2010. + + [I-D.ietf-hokey-ldn-discovery] + Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name + DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in + progress), September 2010. + [IEEE_802.1X] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004", December 2004. [MSKHierarchy] Lopez, R., Skarmeta, A., Bournelle, J., Laurent- Maknavicus, M., and J. Combes, "Improved EAP keying framework for a secure mobility access service", @@ -1817,23 +1863,25 @@ Hoeper suggested the use of the windowing technique to handle multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for the suggestion to use hexadecimal encoding for rIKname when sent as part of keyName-NAI field. Thanks to Bernard Aboba for suggestions in clarifying the EAP lock-step operation, and Joe Salowey and Glen Zorn for help in specifying AAA transport of ERP messages. Thanks to Sam Hartman for the DSRK Authorization Indication mechanism. A.2. RFC 5296bis - TBC + Glen Zorn wrote the initial draft for this document and provided + useful reviews. Many thanks to him. Appendix B. Example ERP Exchange + 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,Auth-tag*) 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, EAP Initiate/Re-auth(SEQ,keyName-NAI, cryptosuite,Auth-tag*) 2. ER-Server --> Authenticator: AAA-Response{rMSK, @@ -1842,33 +1890,37 @@ 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, cryptosuite,[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. Authors' Addresses - Glen Zorn (editor) - Network Zen - 1463 East Republican Street - #358 - Seattle, Washington 98112 - US - - Email: gwz@net-zen.net - - Qin Wu + Qin Wu (editor) Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, JiangSu 210012 China Email: Sunseawq@huawei.com + Zhen Cao China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China Email: caozhen@chinamobile.com + Yang Shi + H3C Tech. Co., Ltd + Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District + Beijing 100085 + China + + Email: young@h3c.com + + Baohong He + China + + Email: hebaohong@catr.cn