--- 1/draft-ietf-hokey-rfc5296bis-06.txt 2012-05-28 12:14:45.073427706 +0200 +++ 2/draft-ietf-hokey-rfc5296bis-07.txt 2012-05-28 12:14:45.153425289 +0200 @@ -1,25 +1,24 @@ -Network Working Group Q. Wu, Ed. -Internet-Draft Huawei -Obsoletes: 5296 (if approved) Z. Cao -Intended status: Standards Track China Mobile -Expires: May 18, 2012 G. Zorn, Ed. +Network Working Group Z. Cao +Internet-Draft China Mobile +Obsoletes: 5296 (if approved) B. He +Intended status: Standards Track CATR +Expires: November 18, 2012 Y. Shi + Q. Wu, Ed. + Huawei + G. Zorn, Ed. Network Zen - Y. Shi - H3C - B. He - CATR - November 15, 2011 + May 17, 2012 EAP Extensions for EAP Re-authentication Protocol (ERP) - draft-ietf-hokey-rfc5296bis-06 + draft-ietf-hokey-rfc5296bis-07 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 avoid repeating 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 @@ -37,78 +36,78 @@ 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 May 18, 2012. + This Internet-Draft will expire on November 18, 2012. Copyright Notice - - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Changes from RFC 5296 . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 - 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 . . . . . . . . . . . . . . . . . . . . . . . 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. AAA 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. Sample ERP Exchange . . . . . . . . . . . . . . . . . 41 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 + 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 10 + 3.2. ERP With a Local ER Server . . . . . . . . . . . . . . . . 11 + 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 15 + 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 15 + 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 16 + 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 17 + 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 17 + 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 18 + 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 23 + 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 24 + 5.3. EAP Codes . . . . . . . . . . . . . . . . . . . . . . . . 25 + 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 26 + 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 27 + 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 27 + 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 27 + 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 29 + 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 32 + 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 33 + 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33 + 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 34 + 7. AAA Transport of ERP Messages . . . . . . . . . . . . . . . . 35 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 42 + Appendix A. RFC 5296 Acknowledgments . . . . . . . . . . . . . . 43 + Appendix B. Sample ERP Exchange . . . . . . . . . . . . . . . . . 43 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 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 @@ -152,20 +151,45 @@ 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 Internet Key Exchange (IKE) protocol [RFC5996] must be updated to carry ERP messages; work is in progress on this project [I-D.nir-ipsecme-erx]. +1.1. Changes from RFC 5296 + + This document obsoletes RFC 5296 but is fully backward compatible + with that document. The changes introduced in this document focus on + fixing issues that have surfaced since the publication of the + original ERP specification [RFC5296]. An overview of some the major + changes is given below. + + o Co-location of the home ER and EAP servers is no longer required + (see the "ER Server entry in Section 2). + + o The behavior of the authenticator and local ER server during the + bootstrapping process has been clarified (Section 5.1); in + particular, the authenticator and/or local ER server is now + required to check for current possesion of the root keys. + + o The authenticator is now recommended, rather than just allowed, to + initiate the ERP conversation by means of the EAP-Initiate/ + Re-auth-Start message (Section 5.3.1.1). + + In addition, many editorial changes have been made to improve the + clarity of the document and to eliminate perceived abmbiguities. A + comprehensive list of changes is not given here for practical + reasons. + 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 [RFC2119]. This document uses the basic EAP terminology [RFC3748] and EMSK keying hierarchy terminology [RFC5295]. In addition, this document uses the following terms: @@ -271,21 +295,21 @@ [Bootstrap] [Bootstrap]) <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- Re-auth/ Re-auth/ [Bootstrap] [Bootstrap]) Note: [] brackets indicate optionality. Figure 2: ERP Exchange - Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this + Two 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. The EAP-Finish message also can be used by the authenticator to announce the local domain @@ -394,34 +418,34 @@ Re-auth/ Re-auth/ Bootstrap Bootstrap) <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- Re-auth/ Re-auth/ Bootstrap Bootstrap) Figure 3: ER Explicit Bootstrapping Exchange/ERP with the Home ER Sever -3.2. ERP with a Local ER Server +3.2. ERP With a Local ER Server The defined ER extensions allow the execution of ERP with an ER server in the local domain (access network) if the peer moves out of - home domain and a local ER server is present in the visited 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 a lower - layer advertisement 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. + the home domain and a local ER server is present in the visited + 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 a lower layer advertisement or by means of an 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 AAA Agent Home EAP Server /ER Authenticator /Local ER Server ==== ================= =============== =============== <-- EAP-Request/ -- Identity -- EAP Response/--> Identity --AAA(EAP Response/--> @@ -462,36 +486,36 @@ of the full EAP exchange (e.g., this may be one of the AAA entities, 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 by means of an 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., the local ER Server). The local domain is responsible for announcing that same domain name to the peer via a lower layer (for example, through DHCP-based local domain name - discovery [I-D.ietf-hokey-ldn-discovery], or through the EAP- - Initiate/Re-auth-Start message with the local ER server. + discovery [RFC6440], or through the EAP-Initiate/Re-auth-Start + message with the 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. If the peer subsequently attaches to an authenticator within the local domain, it may perform an ERP exchange with the local ER server to obtain a rMSK for the new authenticator. The ERP with the local - ER Server is similar to ERP exchange illustrated in Figure 2. + ER Server is similar to the ERP exchange illustrated 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. @@ -646,21 +670,21 @@ that rIK. If the server's policy does not allow the use of the cryptosuite selected by the peer, the server SHALL reject the EAP-Initiate/ Re-auth message and SHOULD send a list of acceptable cryptosuites in the EAP-Finish/Re-auth message. The rIK length may be different from the key length required by an integrity algorithm. In case of hash-based MAC algorithms, the key is first hashed to the required key length using the HMAC algorithm - RFC 2104 [RFC2104]. In case of cipher-based MAC algorithms, if the + [RFC2104]. In the case of cipher-based MAC algorithms, if the required key length is less than 32 octets, the rIK is hashed using HMAC-SHA256 and the first k octets of the output are used, where k is the key length required by the algorithm. If the required key length is more than 32 octets, the first k octets of the rIK are used by the cipher-based MAC algorithm. 4.6. rMSK Derivation The rMSK is derived at the peer and server and delivered to the authenticator. The rMSK is derived following an EAP Re-auth Protocol @@ -709,41 +733,41 @@ 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. In implicit bootstrapping, the ER-capable authenticator or - local ER server MUST verify whether it has valid rMSK or rRK - corresponding to the peer. If ER capable authenticator or the local - ER server has the key materials corresponding to the peer, it MUST be - able to respond directly in the same way as the home AAA server does - without forwarding the DSRK request to the home domain; if not, the - ER-capable authenticator or local ER server SHOULD include its domain - name in the AAA message encapsulating the first EAP Response message - sent by the peer and request the DSRK from the home EAP server during - the initial EAP exchange. 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 RFC - 5295), 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. Note that the MSK (also present 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 by means of lower-layer announcement (for - example, DHCP [I-D.ietf-hokey-ldn-discovery]). 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. + local ER server MUST verify whether it has a valid rMSK or rRK + corresponding to the peer. If the ER capable authenticator or the + local ER server has the key materials corresponding to the peer, it + MUST be able to respond directly in the same way as the home AAA + server does without forwarding the DSRK request to the home domain; + if not, the ER-capable authenticator or local ER server SHOULD + include its domain name in the AAA message encapsulating the first + EAP Response message sent by the peer and request the DSRK from the + home EAP server during the initial EAP exchange. 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 RFC 5295), 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. Note that the + MSK (also present 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 by means of lower-layer + announcement (for example, DHCP [RFC6440]). 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 knows there is no local ER server presented in the visited domain, it SHOULD initiate Explicit ERP bootstrapping (ERP exchange with the bootstrap flag turned on) with the home ER server to obtain the rRK. 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 @@ -809,21 +833,21 @@ * If the ER server verifies the authorization of a local ER 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 home ER server gets involved in ERP exchange and the ERP + o If the home ER server is involved in the ERP exchange and the ERP exchange is successful, the home ER server SHOULD request the DSRK from the home EAP server; the home EAP server MUST provide the DSRK for the home ER server (derived using the EMSK and the domain name as specified in RFC 5295), EMSKname, and DSRK lifetime for inclusion in the AAA message. The home ER server SHOULD obtain them before sending 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 (for an example, see Bournelle, et al.[I-D.ietf-dime-erp]. @@ -1031,39 +1055,39 @@ When the peer runs explicit bootstrapping (ERP with the bootstrapping flag on), there may not be a local ER server available to send a DSRK Request and the domain name. In that case, the server cannot send the DSRK and MUST NOT include the domain name TLV. When the peer receives a response in the bootstrapping exchange without a domain name TLV, it assumes that there is no local ER server. The home ER server sends an rMSK to the ER authenticator, however, and the peer SHALL run the TSK establishment protocol as usual. -5.3. New EAP Packets +5.3. EAP Codes - Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate - and EAP-Finish. The packet format for these messages follows the EAP - packet format defined in Aboba. et al. [RFC3748]. + Two EAP Codes are defined for the purpose of ERP: EAP-Initiate and + EAP-Finish. The packet format for these messages follows the EAP + packet format defined in Aboba, et al. [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 7: EAP Packet Code - Two new code values are defined for the purpose of ERP: + Two code values are defined for the purpose of ERP: 5 Initiate 6 Finish Identifier The Identifier field is one octet. The Identifier field MUST be the same if an EAP-Initiate packet is retransmitted due to a timeout while waiting for a EAP-Finish message. Any new (non- @@ -1195,40 +1219,42 @@ '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 key lifetimes from the server. The remaining 5 bits are set to 0 on transmission and ignored on reception. - SEQ: A 16-bit sequence number is used for replay protection. The - SEQ number field is initialized to 0 every time a new rRK is - derived. + SEQ: An unsigned 16-bit sequence number is used for replay + protection. The SEQ number field is initialized to 0 every time a + new rRK is derived. The field is encoded in network byte order. 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. keyName-NAI: This is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 16 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. + The NAI syntax is specified in Aboba, et al. [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 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: @@ -1254,72 +1280,72 @@ 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 ~ + | Cryptosuite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 'L' - The L flag is used to indicate the presence of the rRK lifetime TLV. The remaining 5 bits are set to 0 on transmission and ignored on reception. - SEQ: A 16-bit sequence number is used for replay protection. The - SEQ number field is initialized to 0 every time a new rRK is - derived. + SEQ: An unsigned 16-bit sequence number is used for replay + protection. The SEQ number field is initialized to 0 every time a + new rRK is derived. The field is encoded in network byte order. 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. keyName-NAI: This is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 16 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 instance of the keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth message. rRK Lifetime: This is a TV payload. The Type is 2. The value - field is a 32-bit field and contains the lifetime of the rRK in - seconds. If the 'L' flag is set, the rRK Lifetime attribute - SHOULD be present. + field contains an unsigned 32-bit integer in network byte order + representing the lifetime of the rRK in seconds. If the 'L' + flag is set, the rRK Lifetime attribute SHOULD be present. rMSK Lifetime: This is a TV payload. The Type is 3. The value - field is a 32-bit field and contains the lifetime of the rMSK - in seconds. If the 'L' flag is set, the rMSK Lifetime - attribute SHOULD be present. + field contains an unsigned 32-bit integer in network byte order + representing the lifetime of the rMSK in seconds. If the 'L' + flag is set, the rMSK Lifetime 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 9. @@ -1435,28 +1461,28 @@ responded to the message and the response 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. The peer SHOULD increment the sequence number by 1; however, it may choose to increment by a larger number. If the sequence number wraps back to zero, the peer MUST run full EAP authentication. 5.5. Channel Binding ERP provides a protected facility to carry channel binding (CB) - information, according to the guidelines provided by Aboba, et al. - (see Section 7.15 of [RFC3748]). The TLV type range of 128-191 is - reserved to carry CB information in the EAP-Initiate/Re-auth and EAP- - Finish/Re-auth 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. Additional values are IANA managed based on IETF - Consensus [RFC5226]. + information, according to the guidelines provided by Aboba, et + al. (see Section 7.15 of [RFC3748]). The TLV type range of 128-191 + is reserved to carry CB information in the EAP-Initiate/Re-auth and + EAP-Finish/Re-auth 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. Additional values are IANA managed + based on IETF Consensus [RFC5226]. The authenticator MAY provide CB information to the peer via the EAP- Initiate/Re-auth-Start message. The peer sends the information to the server in the EAP-Initiate/Re-auth message; the server verifies whether the authenticator identity available via AAA attributes is the same as the identity provided to the peer. If the peer does not include the CB information in the EAP-Initiate/ Re-auth message, and if the local ER server's policy requires channel binding support, it SHALL send the CB attributes for the peer's @@ -1534,22 +1560,22 @@ guaranteed, ERP support may be indicated through signaling (e.g., piggy-backed on a beacon) or through negotiation. Alternatively, clients may recognize environments where ERP is available based on pre-configuration. Other similar mechanisms may also be used. When ERP support cannot be verified, lower layers may mandate falling back to full EAP authentication to accommodate EAP implementations that are not compliant to RFC 3748. 7. AAA Transport of ERP Messages - AAA Transport of ERP messages is specified by Hoeper, et al. - [RFC5749] and Bournelle, et al. [I-D.ietf-dime-erp]. + AAA Transport of ERP messages is specified by Hoeper, et + al. [RFC5749] and Bournelle, et al. [I-D.ietf-dime-erp]. 8. Security Considerations This section provides an analysis of the protocol in accordance with the AAA key management guidelines described by Housley & Aboba [RFC4962]. Cryptographic algorithm independence The EAP Re-auth Protocol satisfies this requirement. The @@ -1754,76 +1780,118 @@ 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 the network do not use keys intended for other parties to steal service from an access network. If that is not achievable, key delivery must be protected in an end-to-end manner. 9. IANA Considerations - This document has no IANA actions. + This document replaces and obsoletes RFC 5296, and IANA is asked to + change all registered references to that document to point instead to + this document. [RFC Editor note: please remove the previous + paragraph on publication.] -10. References + The previous version of this document performed the following IANA + [IANA] actions: -10.1. Normative References + 1. It registered Packet Codes "Initiate" and "Finish" in the EAP + Registry. Those are documented throughout this document as "EAP- + Initiate" and "EAP-Finish". + + 2. It created a Message Types table in the EAP Registry, and + registered several items in that table. Those are documented + throughout this document as "Re-auth-start" and "Re-auth". + + 3. It created an EAP Initiate and Finish Attributes table in the EAP + registry, and registered several items in that table. Those are + documented in this document in Section 5.3.4. + + 4. It created a Re-authentication Cryptosuites table in the EAP + registry, and registered several items in that table. Those are + documented in this document at the end of Section 5.3.2. + + 5. It registered two items in the USRK Key Labels registry: + + * Re-auth usage label "EAP Re-authentication Root Key@ietf.org", + documented in this document in Section 4.1. + + * DSRK-authorized delivery key "DSRK Delivery Authorized + Key@ietf.org", documented in this document in the description + of "Authorization Indication" in Section 5.3.3. + +10. Contributors + + Barry Leiba contributed all of the text in Section 9 and, as + Applications Area Director, insisted upon its inclusion as a + condition of publication. + +11. Acknowledgements + + This document is largely based upon RFC 5296; thanks to all who + partipated in that effort (see Appendix A). In addition, thanks to + Yaron Sheffer, Sebastien Decugis, Ralph Droms, Stephen Farrel, + Charlie Kaufman and Yoav Nir for (mostly) useful comments and review. + +12. References + +12.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008. -10.2. Informative References +12.2. Informative References [I-D.ietf-dime-erp] - Bournelle, J., Morand, L., Decugis, S., Wu, W., and G. - Zorn, "Diameter support for EAP Re-authentication Protocol - (ERP)", draft-ietf-dime-erp-07 (work in progress), - September 2011. - - [I-D.ietf-hokey-ldn-discovery] - Zorn, G., Wu, W., and Y. Wang, "The ERP Local Domain Name - DHCPv6 Option", draft-ietf-hokey-ldn-discovery-10 (work in - progress), April 2011. + Decugis, S., Morand, L., Wu, W., Bournelle, J., and G. + Zorn, "Diameter Support for the EAP Re-authentication + Protocol (ERP)", draft-ietf-dime-erp-09 (work in + progress), February 2012. [I-D.nir-ipsecme-erx] Nir, Y. and W. Wu, "An IKEv2 Extension for Supporting - ERP", draft-nir-ipsecme-erx-01 (work in progress), - July 2011. + ERP", draft-nir-ipsecme-erx-03 (work in progress), + April 2012. + + [IANA] "Internet Assigned Numbers Authority", + . [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", IWCMC '06, Proceedings of the 2006 International - Conference on Wireless Communications and - Mobile Computing, New York, NY, USA, 2006. + Conference on Wireless Communications and Mobile + Computing, New York, NY, USA, 2006. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key @@ -1834,53 +1902,54 @@ BCP 132, RFC 4962, July 2007. [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. + [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- + authentication Protocol (ERP)", RFC 5296, August 2008. + [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of EAP-Based Keys for Handover and Re-Authentication", RFC 5749, March 2010. [RFC5996] Kaufman, C., Hoffman , P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. -Appendix A. Acknowledgments + [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication + Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, + December 2011. -A.1. RFC 5296 +Appendix A. RFC 5296 Acknowledgments In writing this document, 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, Kedar Gaonkar, Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of the HOKEY working group. The credit for the idea to use EAP- Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin 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 - - Thanks to Yaron Sheffer and Yoav Nir for useful comments. - Appendix B. Sample ERP Exchange 0. Authenticator --> Peer: EAP-Initiate/Re-auth-Start [Optional] 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, Auth-tag*) 1a. Authenticator --> Re-auth-Server: AAA-Request @@ -1901,46 +1970,48 @@ 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 - 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 + Baohong He + China Academy of Telecommunication Research + China + + Email: hebaohong@catr.cn + + Yang Shi + Huawei Technologies Co., Ltd. + 156, Beiqing Road, Zhongguancun, Haidian District + Beijing + P.R. China + + Phone: +86 10 60614043 + Email: shiyang1@huawei.com + + Qin Wu (editor) + Huawei Technologies Co., Ltd. + 101 Software Avenue, Yuhua District + Nanjing, JiangSu 210012 + China + + Email: Sunseawq@huawei.com Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 87-0404617 Email: glenzorn@gmail.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