idnits 2.17.1 draft-ietf-hokey-rfc5296bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5296, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 contained in the message 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 there is a 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 not start an ERP exchange with the home ER server. -- The document date (October 29, 2011) is 4562 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Bootstrap' is mentioned on line 272, but not defined == Missing Reference: 'Optional' is mentioned on line 1876, but not defined == Missing Reference: 'CB-Info' is mentioned on line 1899, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-17) exists of draft-ietf-dime-erp-07 == Outdated reference: A later version (-11) exists of draft-nir-ipsecme-erx-01 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu, Ed. 3 Internet-Draft Huawei 4 Obsoletes: 5296 (if approved) Z. Cao 5 Intended status: Standards Track China Mobile 6 Expires: May 1, 2012 G. Zorn, Ed. 7 Network Zen 8 Y. Shi 9 H3C 10 B. He 11 CATR 12 October 29, 2011 14 EAP Extensions for EAP Re-authentication Protocol (ERP) 15 draft-ietf-hokey-rfc5296bis-05 17 Abstract 19 The Extensible Authentication Protocol (EAP) is a generic framework 20 supporting multiple types of authentication methods. In systems 21 where EAP is used for authentication, it is desirable to avoid 22 repeating the entire EAP exchange with another authenticator. This 23 document specifies extensions to EAP and the EAP keying hierarchy to 24 support an EAP method-independent protocol for efficient re- 25 authentication between the peer and an EAP re-authentication server 26 through any authenticator. The re-authentication server may be in 27 the home network or in the local network to which the peer is 28 connecting. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 1, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 9 67 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10 68 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 70 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 71 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 72 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 73 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 75 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 76 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 77 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 78 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 79 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 80 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 81 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 82 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 83 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 84 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 85 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26 86 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 87 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 88 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 89 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 90 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 91 7. AAA Transport of ERP Messages . . . . . . . . . . . . . . . . 34 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 97 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 98 A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 99 A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 100 Appendix B. Sample ERP Exchange . . . . . . . . . . . . . . . . . 41 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 103 1. Introduction 105 The Extensible Authentication Protocol (EAP) is a an authentication 106 framework that supports multiple authentication methods. The primary 107 purpose is network access authentication, and a key-generating method 108 is used when the lower layer wants to enforce access control. The 109 EAP keying hierarchy defines two keys to be derived by all key- 110 generating EAP methods: the Master Session Key (MSK) and the Extended 111 MSK (EMSK). In the most common deployment scenario, an EAP peer and 112 an EAP server authenticate each other through a third party known as 113 the EAP authenticator. The EAP authenticator or an entity controlled 114 by the EAP authenticator enforces access control. After successful 115 authentication, the EAP server transports the MSK to the EAP 116 authenticator; the EAP authenticator and the EAP peer establish 117 transient session keys (TSKs) using the MSK as the authentication 118 key, key derivation key, or a key transport key, and use the TSK for 119 per-packet access enforcement. 121 When a peer moves from one authenticator to another, it is desirable 122 to avoid a full EAP authentication to support fast handovers. The 123 full EAP exchange with another run of the EAP method can take several 124 round trips and significant time to complete, causing increased 125 handover times. Some EAP methods specify the use of state from the 126 initial authentication to optimize re-authentications by reducing the 127 computational overhead (e.g., EAP-AKA [RFC4187]), but method-specific 128 re-authentication takes at least 2 round trips with the original EAP 129 server in most cases. It is also important to note that several 130 methods do not offer support for re-authentication. 132 Key sharing across authenticators is sometimes used as a practical 133 solution to lower handover times. In that case, however, the 134 compromise of one authenticator results in the compromise of keying 135 material established via other authenticators. Other solutions for 136 fast re-authentication exist in the literature: for example, see 137 Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP 138 re-authentication problem statement in detail [RFC5169]. 140 In conclusion, to achieve low latency handovers, there is a need for 141 a method-independent re-authentication protocol that completes in 142 less than 2 round trips, preferably with a local server. 144 This document specifies EAP Re-authentication Extensions (ERXs) for 145 efficient re-authentication using EAP. The protocol that uses these 146 extensions is itself referred to as the EAP Re-authentication 147 Protocol (ERP). It supports EAP method-independent re-authentication 148 for a peer that has valid, unexpired key material from a previously 149 performed EAP authentication. The protocol and the key hierarchy 150 required for EAP re-authentication are described in this document. 152 Note that to support ERP, lower-layer specifications may need to be 153 revised to allow carrying EAP messages that have a code value higher 154 than 4 and to accommodate the peer-initiated nature of ERP. 155 Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must 156 be updated to carry ERP messages; work is in progress on this project 157 [I-D.nir-ipsecme-erx]. 159 2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 This document uses the basic EAP terminology [RFC3748] and EMSK 166 keying hierarchy terminology [RFC5295]. In addition, this document 167 uses the following terms: 169 ER Peer - An EAP peer that supports the EAP Re-authentication 170 Protocol. All references to "peer" in this document imply an ER 171 peer, unless specifically noted otherwise. 173 ER Authenticator - An entity that supports the authenticator 174 functionality for EAP re-authentication described in this 175 document. All references to "authenticator" in this document 176 imply an ER authenticator, unless specifically noted otherwise. 178 ER Server - An entity that performs the server portion of ERP 179 described here. This entity may or may not be an EAP server. All 180 references to "server" in this document imply an ER server, unless 181 specifically noted otherwise. An ER server is a logical entity; 182 it may not necessarily be co-located with, or physically part of, 183 a full EAP server. 185 ERX - EAP re-authentication extensions. 187 ERP - EAP Re-authentication Protocol that uses the re- 188 authentication extensions. 190 rRK - re-authentication Root Key, derived from the EMSK or DSRK. 192 rIK - re-authentication Integrity Key, derived from the rRK. 194 rMSK - re-authentication MSK. This is a per-authenticator key, 195 derived from the rRK. 197 keyName-NAI - ERP messages are integrity protected with the rIK or 198 the DS-rIK. The use of rIK or DS-rIK for integrity protection of 199 ERP messages is indicated by the EMSKname [RFC5295]; the protocol, 200 which is ERP; and the realm, which indicates the domain name of 201 the ER server. The EMSKname is copied into the username part of 202 the NAI. 204 Domain - Refers to a "key management domain" as defined in 205 [RFC5295]. For simplicity, it is referred to as "domain" in this 206 document. The terms "home domain" and "local domain" are used to 207 differentiate between the originating key management domain that 208 performs the full EAP exchange with the peer and the local domain 209 to which a peer may be attached at a given time. 211 3. ERP Description 213 ERP allows a peer and server to mutually verify proof of possession 214 of keying material from an earlier EAP method run and to establish a 215 security association between the peer and the authenticator. The 216 authenticator acts as a pass-through entity for the Re-authentication 217 Protocol in a manner similar to that of an EAP authenticator 218 described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange 219 between the peer and the server; it is independent of the lower layer 220 and the EAP method used during the full EAP exchange. The ER server 221 may be in the home domain or in the same (visited) domain as the peer 222 and the authenticator (i.e., the local domain). 224 Figure 2 shows the protocol exchange. The first time the peer 225 attaches to any network, it performs a full EAP exchange (shown in 226 Figure 1) with the EAP server; as a result, an MSK is distributed to 227 the EAP authenticator. The MSK is then used by the authenticator and 228 the peer to establish TSKs as needed. At the time of the initial EAP 229 exchange, the peer and the server also derive an EMSK, which is used 230 to derive a re-authentication Root Key (rRK). More precisely, a re- 231 authentication Root Key is derived from the EMSK or from a Domain- 232 Specific Root Key (DSRK), which is itself derived from the EMSK. The 233 rRK is only available to the peer and the ER server and is never 234 handed out to any other entity. Further, a re-authentication 235 Integrity Key (rIK) is derived from the rRK; the peer and the ER 236 server use the rIK to provide proof of possession while performing an 237 ERP exchange. The rIK is also never handed out to any entity and is 238 only available to the peer and server. 240 EAP Peer EAP Authenticator EAP Server 241 ======== ================= ========== 243 <--- EAP-Request/ ------ 244 Identity 246 ----- EAP Response/ ---> 247 Identity ---AAA(EAP Response/Identity)--> 249 <--- EAP Method -------> <------ AAA(EAP Method --------> 250 exchange exchange) 252 <----AAA(MSK, EAP-Success)------ 254 <---EAP-Success--------- 256 Figure 1: EAP Authentication 258 Peer ER Authenticator ER Server 259 ==== ============= ====== 261 <-- EAP-Initiate/ ----- 262 Re-auth-Start 263 [<-- EAP-Request/ ------ 264 Identity] 266 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 267 Re-auth/ Re-auth/ 268 [Bootstrap] [Bootstrap]) 270 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 271 Re-auth/ Re-auth/ 272 [Bootstrap] [Bootstrap]) 274 Note: [] brackets indicate optionality. 276 Figure 2: ERP Exchange 278 Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this 279 document for the purpose of EAP re-authentication. When the peer 280 identifies a target authenticator that supports EAP re- 281 authentication, it performs an ERP exchange, as shown in Figure 2; 282 the exchange itself may happen when the peer attaches to a new 283 authenticator supporting EAP re-authentication, or prior to 284 attachment. The peer initiates ERP by itself; it may also do so in 285 response to an EAP-Initiate/Re-auth-Start message from the new 286 authenticator. The EAP-Initiate/Re-auth-Start message allows the 287 authenticator to trigger the ERP exchange. The EAP-Finish message 288 also can be used by the authenticator to announce the local domain 289 name. 291 It is plausible that the authenticator does not know whether the peer 292 supports ERP and whether the peer has performed a full EAP 293 authentication through another authenticator. The authenticator MAY 294 initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start 295 message, and if there is no response, send the EAP-Request/Identity 296 message. Note that this avoids having two EAP messages in flight at 297 the same time [RFC3748]. The authenticator may send the EAP- 298 Initiate/Re-auth-Start message and wait for a short, locally 299 configured amount of time. This message indicates to the peer that 300 the authenticator supports ERP. In response to this trigger from the 301 authenticator, the peer can initiate the ERP exchange by sending an 302 EAP-Initiate/Re-auth message. If there is no response from the peer 303 after the necessary number of retransmissions (see Section 6), the 304 authenticator MUST initiate EAP by sending an EAP-Request message, 305 typically the EAP-Request/Identity message. Note that the 306 authenticator may receive an EAP-Initiate/Re-auth message after it 307 has sent an EAP-Request/Identity message. If the authenticator 308 supports ERP, it MUST proceed with the ERP exchange. When the EAP- 309 Request/Identity times out, the authenticator MUST NOT close the 310 connection if an ERP exchange is in progress or has already succeeded 311 in establishing a re-authentication MSK. 313 If the authenticator does not support ERP, it will silently discard 314 EAP-Initiate/Re-auth messages (Section 5.3.2) since the EAP code of 315 those packets is greater than 4 ([RFC3748], Section 4). An ERP- 316 capable peer will exhaust the EAP-Initiate/Re-auth message 317 retransmissions and fall back to EAP authentication by responding to 318 EAP Request/Identity messages from the authenticator. If the peer 319 does not support ERP or if it does not have unexpired key material 320 from a previous EAP authentication, it drops EAP-Initiate/ 321 Re-auth-Start messages. If there is no response to the EAP-Initiate/ 322 Re-auth-Start message, the authenticator SHALL send an EAP Request 323 message (typically EAP Request/Identity) to start EAP authentication. 324 From this point onward, RFC 3748 rules apply. Note that this may 325 introduce some delay in starting EAP. In some lower layers, the 326 delay can be minimized or even avoided by the peer initiating EAP by 327 sending messages such as EAPoL-Start [IEEE_802.1X]. 329 The peer sends an EAP-Initiate/Re-auth message that contains the 330 keyName-NAI to identify the ER server's domain and the rIK used to 331 protect the message, and a sequence number for replay protection. 332 The EAP-Initiate/Re-auth message is integrity protected with the rIK. 333 The authenticator uses the realm in the keyName-NAI [RFC4282] field 334 to send the message to the appropriate ER server. The server uses 335 the keyName to look up the rIK. The server, after verifying proof of 336 possession of the rIK, and freshness of the message, derives a re- 337 authentication MSK (rMSK) from the rRK using the sequence number as 338 an input to the key derivation. The server then updates the expected 339 sequence number to the received sequence number plus one. 341 In response to the EAP-Initiate/Re-auth message, the server sends an 342 EAP-Finish/Re-auth message; this message is integrity protected with 343 the rIK. The server transports the rMSK along with this message to 344 the authenticator. The rMSK is transported in a manner similar to 345 that of the MSK along with the EAP-Success message in a full EAP 346 exchange. Hoeper, et al.[RFC5749] discuss an additional key 347 distribution protocol that can be used to transport the rRK from an 348 EAP server to one of many different ER servers that share a trust 349 relationship with the EAP server. 351 The peer MAY request the rMSK lifetime from the server. If so, the 352 ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message. 354 In an ERP bootstrap exchange, the peer MAY ask the server for the rRK 355 lifetime. If so, the ER server sends the rRK lifetime in the EAP- 356 Finish/Re-auth message. 358 The peer verifies the sequence number and the integrity of the 359 message. It then uses the sequence number in the EAP-Finish/Re-auth 360 message to compute the rMSK. The lower-layer security association 361 protocol is ready to be triggered after this point. 363 The ER server is located either in the home domain or in the visited 364 domain. When the ER server is in the home domain and there is no 365 local ER server in the visited domain, the peer and the server use 366 the rIK and rRK derived from the EMSK; and when the ER server is in 367 the local domain, they use the DS-rIK and DS-rRK corresponding to the 368 local domain. The domain of the ER server is identified by the realm 369 portion of the keyname-NAI in ERP messages. 371 3.1. ERP With the Home ER Server 373 If the peer is in the home domain or there is no local server in the 374 same domain as the peer, it SHOULD initiate an ERP bootstrap exchange 375 with the home ER server to obtain the domain name. 377 The defined ER extensions allow executing the ERP with an ER server 378 in the home domain. The home ER server may be co-located with a home 379 AAA server. ERP with the Home ER Server is similar to the ERP 380 exchange described in Figure 2. 382 Peer ER Authenticator Home ER Server 383 ==== ============= ====== 385 <-- EAP-Initiate/ ----- 386 Re-auth-Start 387 [<-- EAP-Request/ ------ 388 Identity] 390 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 391 Re-auth/ Re-auth/ 392 Bootstrap Bootstrap) 394 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 395 Re-auth/ Re-auth/ 396 Bootstrap Bootstrap) 398 Figure 3: ER Explicit Bootstrapping Exchange/ERP with the Home ER 399 Sever 401 3.2. ERP with a Local ER Server 403 The defined ER extensions allow the execution of ERP with an ER 404 server in the local domain (access network) if the peer moves out of 405 home domain and a local ER server is present in the visited domain. 406 The local ER server may be co-located with a local AAA server. The 407 peer may learn about the presence of a local ER server in the network 408 and the local domain name (or ER server name) either via a lower 409 layer advertisement or by means of ERP exchange. The peer uses the 410 domain name and the EMSK to compute the DSRK and from that key, the 411 DS-rRK; the peer also uses the domain name in the realm portion of 412 the keyName-NAI for using ERP in the local domain. Figure 4 shows 413 the ER Implicit bootstrapping exchange through local ER 414 Server;Figure 5shows ERP with a local ER server. 416 Peer EAP Authenticator Local AAA Agent Home EAP Server 417 /ER Authenticator /Local ER Server 418 ==== ================= =============== =============== 420 <-- EAP-Request/ -- 421 Identity 423 -- EAP Response/--> 424 Identity --AAA(EAP Response/--> 425 Identity, --AAA(EAP Response/ --> 426 [domain name]) Identity, 427 [DSRK Request, 428 domain name]) 430 <------------------------ EAP Method exchange------------------> 432 <---AAA(MSK, DSRK, ---- 433 EMSKname, 434 EAP-Success) 436 <--- AAA(MSK, ----- 437 EAP-Success) 439 <---EAP-Success----- 441 Figure 4: Implicit Bootstrapping ERP Exchange, Initial EAP Exchange 443 Peer ER Authenticator Local ER Server 444 ==== ================ =============== 446 <-- EAP-Initiate/ -------- 447 Re-auth-Start 448 [<-- EAP-Request/ --------- 449 Identity] 451 ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> 452 Re-auth Re-auth) 454 <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- 455 Re-auth Re-auth) 456 Figure 5: Local ERP Exchange 458 As shown in Figure 4, the local ER server may be present in the path 459 of the full EAP exchange (e.g., this may be one of the AAA entities, 460 such as AAA proxies, in the path between the EAP authenticator and 461 the home EAP server of the peer). In that case, the local ER server 462 requests the DSRK by sending the domain name to the home EAP server 463 by means of an AAA message. In response, the home EAP server 464 computes the DSRK by following the procedure specified in [RFC5295] 465 and sends the DSRK and the key name, EMSKname, to the ER server in 466 the claimed domain (i.e., the local ER Server). The local domain is 467 responsible for announcing that same domain name to the peer via a 468 lower layer (for example, through DHCP-based local domain name 469 discovery [I-D.ietf-hokey-ldn-discovery], or through the EAP- 470 Initiate/Re-auth-Start message with the local ER server. 472 After receiving the DSRK and the EMSKname, the local ER server 473 computes the DS-rRK and the DS-rIK from the DSRK as defined in 474 Sections 4.1 and 4.3 below. After receiving the domain name, the 475 peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys 476 are referred to by a keyName-NAI formed as follows: the username part 477 of the NAI is the EMSKname, the realm portion of the NAI is the 478 domain name. Both parties also maintain a sequence number 479 (initialized to zero) corresponding to the specific keyName-NAI. 481 If the peer subsequently attaches to an authenticator within the 482 local domain, it may perform an ERP exchange with the local ER server 483 to obtain a rMSK for the new authenticator. The ERP with the local 484 ER Server is similar to ERP exchange illustrated in Figure 2. 486 4. ER Key Hierarchy 488 Each time the peer re-authenticates to the network, the peer and the 489 authenticator establish an rMSK. The rMSK serves the same purposes 490 that an MSK, which is the result of full EAP authentication, serves. 491 To prove possession of the rRK, we specify the derivation of another 492 key, the rIK. These keys are derived from the rRK. Together they 493 constitute the ER key hierarchy. 495 The rRK is derived from either the EMSK or a DSRK as specified in 496 Section 4.1. For the purpose of rRK derivation, this document 497 specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- 498 Specific USRK (DSUSRK) [RFC5295] for re-authentication. The USRK 499 designated for re-authentication is the re-authentication root key 500 (rRK). A DSUSRK designated for re-authentication is the DS-rRK 501 available to a local ER server in a particular domain. For 502 simplicity, the keys are referred to without the DS label in the rest 503 of the document. However, the scope of the various keys is limited 504 to just the respective domains for which they are derived, in the 505 case of the domain specific keys. Based on the ER server with which 506 the peer performs the ERP exchange, it knows the corresponding keys 507 that must be used. 509 The rRK is used to derive an rIK, and rMSKs for one or more 510 authenticators. The figure below shows the key hierarchy with the 511 rRK, rIK, and rMSKs. 513 rRK 514 | 515 +--------+--------+ 516 | | | 517 rIK rMSK1 ...rMSKn 519 Figure 6: Re-authentication Key Hierarchy 521 The derivations in this document are from RFC 5295. Key derivations 522 and field encodings, where unspecified, default to that document. 524 4.1. rRK Derivation 526 The rRK may be derived from the EMSK or DSRK. This section provides 527 the relevant key derivations for that purpose. 529 The rRK is derived as specified in RFC 5295. 531 rRK = KDF (K, S), where 533 K = EMSK or K = DSRK and 535 S = rRK Label | "\0" | length 537 The rRK Label is an IANA-assigned 8-bit ASCII string: 539 EAP Re-authentication Root Key@ietf.org 541 assigned from the "USRK key labels" name space in accordance with the 542 policy stated in RFC 5295. 544 The KDF and algorithm agility for the KDF are as defined in RFC 5295. 546 An rRK derived from the DSRK is referred to as a DS-rRK in the rest 547 of the document. All the key derivation and properties specified in 548 this section remain the same. 550 4.2. rRK Properties 552 The rRK has the following properties. These properties apply to the 553 rRK regardless of the parent key used to derive it. 555 o The length of the rRK MUST be equal to the length of the parent 556 key used to derive it. 558 o The rRK is to be used only as a root key for re-authentication and 559 never used to directly protect any data. 561 o The rRK is only used for the derivation of the rIK and rMSK as 562 specified in this document. 564 o The rRK MUST remain on the peer and the server that derived it and 565 MUST NOT be transported to any other entity. 567 o The lifetime of the rRK is never greater than that of its parent 568 key. The rRK is expired when the parent key expires and MUST be 569 removed from use at that time. 571 4.3. rIK Derivation 573 The re-authentication Integrity Key (rIK) is used for integrity 574 protecting the ERP exchange. This serves as the proof of possession 575 of valid keying material from a previous full EAP exchange by the 576 peer to the server. 578 The rIK is derived as follows. 580 rIK = KDF (K, S), where 582 K = rRK and 584 S = rIK Label | "\0" | cryptosuite | length 586 The rIK Label is the 8-bit ASCII string: 588 Re-authentication Integrity Key@ietf.org 590 The length field refers to the length of the rIK in octets encoded as 591 specified in RFC 5295. 593 The cryptosuite and length of the rIK are part of the input to the 594 key derivation function to ensure cryptographic separation of keys if 595 different rIKs of different lengths (for example, for use with 596 different Message Authentication Code (MAC) algorithms) are derived 597 from the same rRK. The cryptosuite is encoded as an 8-bit number; 598 see Section 5.3.2 for the cryptosuite specification. 600 The rIK is referred to by the EMSKname-NAI within the context of ERP 601 messages. The username part of EMSKname-NAI is the EMSKname; the 602 realm is the domain name of the ER server. In case of ERP with the 603 home ER server, the peer uses the realm from its original NAI; in 604 case of a local ER server, the peer uses the domain name received at 605 the lower layer or through an ERP bootstrapping exchange. 607 A rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of 608 the document. All of the key derivation and properties specified in 609 this section remain the same. 611 4.4. rIK Properties 613 The rIK has the following properties. 615 o The length of the rIK MUST be equal to the length of the rRK. 617 o The rIK is only used for authentication of the ERP exchange as 618 specified in this document. 620 o The rIK MUST NOT be used to derive any other keys. 622 o The rIK must remain on the peer and the server and MUST NOT be 623 transported to any other entity. 625 o The rIK is cryptographically separate from any other keys derived 626 from the rRK. 628 o The lifetime of the rIK is never greater than that of its parent 629 key. The rIK MUST be expired when the EMSK expires and MUST be 630 removed from use at that time. 632 4.5. rIK Usage 634 The rIK is the key the possession of which is demonstrated by the 635 peer and the ERP server to the other party. The peer demonstrates 636 possession of the rIK by computing the integrity checksum over the 637 EAP-Initiate/Re-auth message. When the peer uses the rIK for the 638 first time, it can choose the integrity algorithm to use with the 639 rIK. The peer and the server MUST use the same integrity algorithm 640 with a given rIK for all ERP messages protected with that key. The 641 peer and the server store the algorithm information after the first 642 use, and they employ the same algorithm for all subsequent uses of 643 that rIK. 645 If the server's policy does not allow the use of the cryptosuite 646 selected by the peer, the server SHALL reject the EAP-Initiate/ 647 Re-auth message and SHOULD send a list of acceptable cryptosuites in 648 the EAP-Finish/Re-auth message. 650 The rIK length may be different from the key length required by an 651 integrity algorithm. In case of hash-based MAC algorithms, the key 652 is first hashed to the required key length using the HMAC algorithm 653 RFC 2104 [RFC2104]. In case of cipher-based MAC algorithms, if the 654 required key length is less than 32 octets, the rIK is hashed using 655 HMAC-SHA256 and the first k octets of the output are used, where k is 656 the key length required by the algorithm. If the required key length 657 is more than 32 octets, the first k octets of the rIK are used by the 658 cipher-based MAC algorithm. 660 4.6. rMSK Derivation 662 The rMSK is derived at the peer and server and delivered to the 663 authenticator. The rMSK is derived following an EAP Re-auth Protocol 664 exchange. 666 The rMSK is derived as follows. 668 rMSK = KDF (K, S), where 670 K = rRK and 672 S = rMSK label | "\0" | SEQ | length 674 The rMSK label is the 8-bit ASCII string: 676 Re-authentication Master Session Key@ietf.org 678 The length field refers to the length of the rMSK in octets. The 679 length field is encoded as specified in RFC 5295. 681 SEQ is the sequence number sent by the peer in the EAP-Initiate/ 682 Re-auth message. This field is encoded as a 16-bit number in network 683 byte order (see Section 5.3.2). 685 An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest 686 of the document. The key derivation and properties specified in this 687 section remain the same. 689 4.7. rMSK Properties 691 The rMSK has the following properties: 693 o The length of the rMSK MUST be equal to the length of the rRK. 695 o The rMSK is delivered to the authenticator and is used for the 696 same purposes that an MSK is used at an authenticator. 698 o The rMSK is cryptographically separate from any other keys derived 699 from the rRK. 701 o The lifetime of the rMSK is less than or equal to that of the rRK. 702 It MUST NOT be greater than the lifetime of the rRK. 704 o If a new rRK is derived, subsequent rMSKs MUST be derived from the 705 new rRK. Previously delivered rMSKs MAY still be used until the 706 expiry of the lifetime. 708 o A given rMSK MUST NOT be shared by multiple authenticators. 710 5. Protocol Details 712 5.1. ERP Bootstrapping 714 We identify two types of bootstrapping for ERP: explicit and 715 implicit. In implicit bootstrapping, the ER-capable authenticator or 716 local ER server MUST verify whether it has valid rMSK or rRK 717 corresponding to the peer. If ER capable authenticator or the local 718 ER server has the key materials corresponding to the peer, it MUST be 719 able to respond directly in the same way as the home AAA server does 720 without forwarding the DSRK request to the home domain; if not, the 721 ER-capable authenticator or local ER server SHOULD include its domain 722 name in the AAA message encapsulating the first EAP Response message 723 sent by the peer and request the DSRK from the home EAP server during 724 the initial EAP exchange. If such EAP exchange is successful, the 725 home EAP server sends the DSRK for the specified local AAA client or 726 agent (derived using the EMSK and the domain name as specified in RFC 727 5295), EMSKname, and DSRK lifetime along with the EAP-Success 728 message. The local AAA client or agent MUST extract the DSRK, 729 EMSKname, and DSRK lifetime (if present) before forwarding the EAP- 730 Success message to the peer. Note that the MSK (also present with 731 the EAP Success message) is extracted by the EAP authenticator as 732 usual. The peer learns the domain name through the EAP-Initiate/ 733 Re-auth-Start message or by means of lower-layer announcement (for 734 example, DHCP [I-D.ietf-hokey-ldn-discovery]). When the domain name 735 is available to the peer during or after the full EAP authentication, 736 it attempts to use ERP when it associates with a new authenticator. 738 If the peer knows there is no local ER server presented in the 739 visited domain, it SHOULD initiate Explicit ERP bootstrapping (ERP 740 exchange with the bootstrap flag turned on) with the home ER server 741 to obtain the rRK. The peer MAY also initiate bootstrapping to fetch 742 information such as the rRK lifetime from the AAA server. 744 The following steps describe the ERP Explicit Bootstrapping process: 746 o The peer sends the EAP-Initiate/Re-auth message with the 747 bootstrapping flag set (1). The bootstrap message is always sent 748 to the home ER server, and the keyname-NAI attribute in the 749 bootstrap message is constructed as follows: the username portion 750 of the NAI contains the EMSKname, and the realm portion contains 751 the home domain name. 753 o In addition, the message MUST contain a sequence number for replay 754 protection, a cryptosuite, and an integrity checksum. The 755 cryptosuite indicates the authentication algorithm. The integrity 756 checksum indicates that the message originated at the claimed 757 entity, the peer indicated by the Peer-ID, or the rIKname. 759 o The peer MAY additionally set the lifetime flag to request the key 760 lifetimes. 762 o Upon receipt of the EAP-Initiate/Re-auth message from a peer, the 763 ERP-capable authenticator verifies whether it has the local domain 764 name and valid key materials corresponding to the peer. If it 765 knows the local domain name and has valid key material 766 corresponding to the peer, it MUST be able to respond directly in 767 the same way as the home ER does with local domain name included. 768 If not, it copies the contents of the keyName-NAI into the 769 appropriate AAA attribute and may include its domain name in the 770 AAA message encapsulating the EAP-Initiate/Re-auth message sent by 771 the peer. 773 o Upon receipt of an EAP-Initiate/Re-auth message, the home ER 774 server verifies whether the message is fresh or is a replay by 775 evaluating whether the received sequence number is equal to or 776 greater than the expected sequence number for that rIK. The home 777 ER server then verifies that the cryptosuite used by the peer is 778 acceptable. Next, it verifies the integrity of the message by 779 looking up the rIK and checking integrity checksum contained in 780 the Authentication Tag field. If any of the checks fail, the home 781 ER server sends an EAP-Finish/Re-auth message with the Result flag 782 set to '1'. Please refer to Section 5.2.2 for details on failure 783 handling. This error MUST NOT have any correlation to any EAP- 784 Success message that may have been received by the EAP 785 authenticator and the peer earlier. If the EAP-Initiate/Re-auth 786 message is well-formed and valid, the server prepares the EAP- 787 Finish/Re-auth message. The bootstrap flag MUST be set to 788 indicate that this is a bootstrapping exchange. The message 789 contains the following fields: 791 * A sequence number for replay protection. 793 * The same keyName-NAI as in the EAP-Initiate/Re-auth message. 795 * If the lifetime flag was set in the EAP-Initiate/Re-auth 796 message, the ER server SHOULD include the rRK lifetime and the 797 rMSK lifetime in the EAP-Finish/Re-auth message. The server 798 may have a local policy for the network to maintain and enforce 799 lifetime unilaterally. In such cases, the server need not 800 respond to the peer's request for the lifetime. 802 * If the bootstrap flag is set, the ER server MUST include the 803 domain name to which the DSRK is being sent along with the EAP- 804 Finish/Re-auth message. 806 * If the ER server verifies the authorization of a local ER 807 server, it MAY include the Authorization Indication TLV to 808 indicate to the peer that the server that received the DSRK and 809 that is advertising the domain included in the domain name TLV 810 is authorized. 812 * An authentication tag MUST be included to prove that the EAP- 813 Finish/Re-auth message originates at a server that possesses 814 the rIK corresponding to the EMSKname-NAI. 816 o If the home ER server gets involved in ERP exchange and the ERP 817 exchange is successful, the home ER server SHOULD request the DSRK 818 from the home EAP server; the home EAP server MUST provide the 819 DSRK for the home ER server (derived using the EMSK and the domain 820 name as specified in RFC 5295), EMSKname, and DSRK lifetime for 821 inclusion in the AAA message. The home ER server SHOULD obtain 822 them before sending the EAP-Finish/Re-auth message. 824 o In addition, the rMSK is sent along with the EAP-Finish/Re-auth 825 message in a AAA attribute (for an example, see Bournelle, et 826 al.[I-D.ietf-dime-erp]. 828 o The authenticator receives the rMSK. 830 o When the peer receives an EAP-Finish/Re-auth message with the 831 bootstrap flag set, if a local domain name is present, it MUST use 832 that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- 833 NAI, and initialize the replay counter for the DS-rIK. If not, 834 the peer SHOULD derive the domain-specific keys using the domain 835 name it learned via the lower layer or from the EAP-Initiate/ 836 Re-auth-Start message. If the peer does not know the domain name, 837 it must assume that there is no local ER server available. 839 o The peer MAY also verify the Authorization Indication TLV. 841 o The procedures for encapsulating ERP and obtaining relevant keys 842 using Diameter are specified in [I-D.ietf-dime-erp]. 844 Since the ER bootstrapping exchange is typically done immediately 845 following the full EAP exchange, it is feasible that the process is 846 completed through the same entity that served as the EAP 847 authenticator for the full EAP exchange. In this case, the lower 848 layer may already have established TSKs based on the MSK received 849 earlier. The lower layer may then choose to ignore the rMSK that was 850 received with the ER bootstrapping exchange. Alternatively, the 851 lower layer may choose to establish a new TSK using the rMSK. In 852 either case, the authenticator and the peer know which key is used 853 based on whether or not a TSK establishment exchange is initiated. 854 The bootstrapping exchange may also be carried out via a new 855 authenticator, in which case, the rMSK received SHOULD trigger a 856 lower layer TSK establishment exchange. 858 5.2. Steps in ERP 860 When a peer that has an active rRK and rIK associates with a new 861 authenticator that supports ERP, it may perform an ERP exchange with 862 that authenticator. ERP is typically a peer-initiated exchange, 863 consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth 864 message. The ERP exchange may be performed with a local ER server 865 (when one is present) or with the original EAP server. 867 It is plausible for the network to trigger the EAP re-authentication 868 process, however. An ERP-capable authenticator SHOULD send an EAP- 869 Initiate/Re-auth-Start message to indicate support for ERP. The peer 870 may or may not wait for these messages to arrive to initiate the EAP- 871 Initiate/Re-auth message. 873 The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- 874 capable authenticator. The authenticator may retransmit it a few 875 times until it receives an EAP-Initiate/Re-auth message in response 876 from the peer. The EAP-Initiate/Re-auth message from the peer may 877 have originated before the peer receives either an EAP-Request/ 878 Identity or an EAP-Initiate/Re-auth-Start message from the 879 authenticator. Hence, the Identifier value in the EAP-Initiate/ 880 Re-auth message is independent of the Identifier value in the EAP- 881 Initiate/Re-auth-Start or the EAP-Request/Identity messages. 883 Operational Considerations at the Peer: 885 ERP requires that the peer maintain retransmission timers for 886 reliable transport of EAP re-authentication messages. The 887 reliability considerations of Section 4.3 of RFC 3748 apply with the 888 peer as the retransmitting entity. 890 The EAP Re-auth Protocol has the following steps: 892 The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start 893 message to trigger the ERP exchange. 895 The peer sends an EAP-Initiate/Re-auth message. At a minimum, the 896 message SHALL include the following fields: 898 a 16-bit sequence number for replay protection 900 keyName-NAI as a TLV attribute to identify the rIK used to 901 integrity protect the message. 903 cryptosuite to indicate the authentication algorithm used to 904 compute the integrity checksum. 906 Authentication Tag computed over the message. 908 When the peer is performing ERP with a local ER server, it MUST 909 use the corresponding DS-rIK it shares with the local ER server. 910 The peer SHOULD set the lifetime flag to request the key lifetimes 911 from the server. The peer can use the rRK lifetime to know when 912 to trigger an EAP method exchange and the rMSK lifetime to know 913 when to trigger another ERP exchange. 915 The authenticator copies the contents of the value field of the 916 keyName-NAI TLV into an appropriate attribute (e.g, User-Name 917 [RFC2865]) in the AAA message to the ER server. 919 The ER server uses the keyName-NAI to look up the rIK. It MUST 920 first verify whether the sequence number is equal to or greater 921 than the expected sequence number. If the ER server supports a 922 sequence number window size greater than 1, it MUST verify whether 923 the sequence number falls within the window and has not been 924 received before. The ER server MUST then verify that the 925 cryptosuite used by the peer is acceptable. The ER server then 926 proceeds to verify the integrity of the message using the rIK, 927 thereby verifying proof of possession of that key by the peer. If 928 any of these verifications fail, the ER server MUST send an EAP- 929 Finish/Re-auth message with the Result flag set to '1' (Failure). 930 Please refer to Section 5.2.2 for details on failure handling. 931 Otherwise, it MUST compute an rMSK from the rRK using the sequence 932 number as the additional input to the key derivation. 934 In response to a well-formed EAP Re-auth/Initiate message, the ER 935 server MUST send an EAP-Finish/Re-auth message with the following 936 contents: 938 a 16-bit sequence number for replay protection, which MUST be 939 the same as the received sequence number. The local copy of 940 the sequence number MUST be incremented by 1. If the ER server 941 supports multiple simultaneous ERP exchanges, it MUST instead 942 update the sequence number window. 944 keyName-NAI as a TLV attribute to identify the rIK used to 945 integrity protect the message. 947 cryptosuite to indicate the authentication algorithm used to 948 compute the integrity checksum. 950 Authentication Tag over the message. 952 If the lifetime flag was set in the EAP-Initiate/Re-auth 953 message, the ER server SHOULD include the rRK lifetime and the 954 rMSK lifetime. 956 The ER server causes the rMSK along with this message to to be 957 transported to the authenticator. The rMSK is transported in a 958 manner similar to the MSK and the EAP-Success message in a regular 959 EAP exchange. 961 The peer looks up the sequence number to verify whether it is 962 expecting an EAP-Finish/Re-auth message with that sequence number 963 protected by the keyName-NAI. It then verifies the integrity of 964 the message. If the verifications fail, the peer logs an error 965 and stops the process; otherwise, it proceeds to the next step. 967 The peer uses the sequence number to compute the rMSK. 969 The lower-layer security association protocol can be triggered at 970 this point. 972 5.2.1. Multiple Simultaneous Runs of ERP 974 When a peer is within the range of multiple authenticators, it may 975 choose to run ERP via all of them simultaneously to the same ER 976 server. In that case, it is plausible that the ERP messages may 977 arrive out of order, resulting in the ER server rejecting legitimate 978 EAP-Initiate/Re-auth messages. 980 To facilitate such operation, an ER server MAY allow multiple 981 simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth 982 messages with SEQ number values within a window of allowed values. 983 Recall that the SEQ number allows replay protection. Replay window 984 maintenance mechanisms are a local matter. 986 5.2.2. ERP Failure Handling 988 If the processing of the EAP-Initiate/Re-auth message results in a 989 failure, the ER server MUST send an EAP-Finish Re-auth message with 990 the Result flag set to '1'. If the server has a valid rIK for the 991 peer, it MUST integrity protect the EAP-Finish/Re-auth failure 992 message. If the failure is due to an unacceptable cryptosuite, the 993 server SHOULD send a list of acceptable cryptosuites (in a TLV of 994 Type 5) along with the EAP-Finish/Re-auth message. In this case, the 995 server MUST indicate the cryptosuite used to protect the EAP-Finish/ 996 Re-auth message in the cryptosuite. The rIK used with the EAP- 997 Finish/Re-auth message in this case MUST be computed as specified in 998 Section 4.3 using the new cryptosuite. If the server does not have a 999 valid rIK for the peer, the EAP-Finish/Re-auth message indicating a 1000 failure will be unauthenticated; the server MAY include a list of 1001 acceptable cryptosuites in the message. 1003 The peer, upon receiving an EAP-Finish/Re-auth message with the 1004 Result flag set to '1', MUST verify the sequence number and, if 1005 possible, the Authentication Tag to determine the validity of the 1006 message. If the peer supports the cryptosuite, it MUST verify the 1007 integrity of the received EAP-Finish/Re-auth message. If the EAP- 1008 Finish message contains a TLV of Type 5, the peer SHOULD retry the 1009 ERP exchange with a cryptosuite picked from the list included by the 1010 server. The peer MUST use the appropriate rIK for the subsequent ERP 1011 exchange, by computing it with the corresponding cryptosuite, as 1012 specified in Section 4.3. If the PRF in the chosen cryptosuite is 1013 different from the PRF originally used by the peer, it MUST derive a 1014 new DSRK (if required), rRK, and rIK before proceeding with the 1015 subsequent ERP exchange. 1017 If the peer cannot verify the integrity of the received message, it 1018 MAY choose to retry the ERP exchange with one of the cryptosuites in 1019 the List of cryptosuites TLV, after a failure has been clearly 1020 determined following the procedure in the next paragraph. 1022 If the replay or integrity checks fail, the failure message may have 1023 been sent by an attacker. It may also mean that the server and peer 1024 do not support the same cryptosuites; however, the peer cannot 1025 determine if that is the case. Hence, the peer SHOULD continue the 1026 ERP exchange per the retransmission timers before declaring a 1027 failure. 1029 When the peer runs explicit bootstrapping (ERP with the bootstrapping 1030 flag on), there may not be a local ER server available to send a DSRK 1031 Request and the domain name. In that case, the server cannot send 1032 the DSRK and MUST NOT include the domain name TLV. When the peer 1033 receives a response in the bootstrapping exchange without a domain 1034 name TLV, it assumes that there is no local ER server. The home ER 1035 server sends an rMSK to the ER authenticator, however, and the peer 1036 SHALL run the TSK establishment protocol as usual. 1038 5.3. New EAP Packets 1040 Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate 1041 and EAP-Finish. The packet format for these messages follows the EAP 1042 packet format defined in Aboba. et al. [RFC3748]. 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Code | Identifier | Length | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Type | Type-Data ... 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1052 Figure 7: EAP Packet 1054 Code 1056 Two new code values are defined for the purpose of ERP: 1058 5 Initiate 1060 6 Finish 1062 Identifier 1064 The Identifier field is one octet. The Identifier field MUST 1065 be the same if an EAP-Initiate packet is retransmitted due to a 1066 timeout while waiting for a EAP-Finish message. Any new (non- 1067 retransmission) EAP-Initiate message MUST use a new Identifier 1068 field. 1070 The Identifier field of the EAP-Finish message MUST match that 1071 of the currently outstanding EAP-Initiate message. A peer or 1072 authenticator receiving a EAP-Finish message whose Identifier 1073 value does not match that of the currently outstanding EAP- 1074 Initiate message MUST silently discard the packet. 1076 In order to avoid confusion between new EAP-Initiate messages 1077 and retransmissions, the peer must choose an Identifier value 1078 that is different from the previous EAP-Initiate message, 1079 especially if that exchange has not finished. It is 1080 RECOMMENDED that the authenticator clear EAP Re-auth state 1081 after 300 seconds. 1083 Type 1085 This field indicates that this is an ERP exchange. Two type 1086 values are defined in this document for this purpose -- Re- 1087 auth-Start (Type 1) and Re-auth (Type 2). 1089 Type-Data 1091 The Type-Data field varies with the Type of re-authentication 1092 packet. 1094 5.3.1. EAP-Initiate/Re-auth-Start Packet 1096 The EAP-Initiate/Re-auth-Start packet contains the fields shown in 1097 Figure 8. 1099 0 1 2 3 1100 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 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | Code | Identifier | Length | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Type | Reserved | 1 or more TVs or TLVs ~ 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 Figure 8: EAP-Initiate/Re-auth-Start Packet 1109 Type = 1. 1111 Reserved, MUST be zero. Set to zero on transmission and ignored 1112 on reception. 1114 One or more TVs or TLVs are used to convey information to the 1115 peer; for instance, the authenticator may send the domain name to 1116 the peer. 1118 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1119 and a value with type-specific length. In the TLV payloads, there 1120 is a 1-octet type payload and a 1-octet length payload. The 1121 length field indicates the length of the value expressed in number 1122 of octets. 1124 Domain-Name: This is a TLV payload. The Type is 4. The domain 1125 name is to be used as the realm in an NAI [RFC4282]. The 1126 Domain-Name TLV SHOULD be present in an EAP-Initiate/ 1127 Re-auth-Start message. 1129 In addition, channel binding information MAY be included; see 1130 Section 5.5 for discussion. See Figure 12 for parameter 1131 specification. 1133 5.3.1.1. Authenticator Operation 1135 In order to minimize ERP failure times, the authenticator SHOULD send 1136 the EAP-Initiate/Re-auth-Start message to indicate support for ERP to 1137 the peer and to initiate ERP if the peer has already performed full 1138 EAP authentication and has unexpired key material. The authenticator 1139 SHOULD include the Domain-Name TLV to allow the peer to learn it 1140 without requiring either lower-layer support or the ERP bootstrapping 1141 exchange. 1143 The authenticator MAY include channel binding information so so that 1144 the server can verify whether the authenticator is claiming the same 1145 identity to both parties. 1147 The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start 1148 message a few times for reliable transport. 1150 5.3.1.2. Peer Operation 1152 The peer SHOULD send the EAP-Initiate/Re-auth message in response to 1153 the EAP-Initiate/Re-auth-Start message from the authenticator. If 1154 the peer does not recognize the EAP-Initiate code value or if the 1155 peer has already sent the EAP-Initiate/Re-auth message to begin the 1156 ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start 1157 message. 1159 If the EAP-Initiate/Re-auth-Start message contains the domain name, 1160 and if the peer does not already have the domain information, the 1161 peer SHOULD use the domain name contained in the message to compute 1162 the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/ 1163 Re-auth message to start an ERP exchange with the local ER server. 1164 If there is a local ER server between the peer and the home ER server 1165 and the peer has already initiated an ERP exchange with the local ER 1166 server, it SHOULD not start an ERP exchange with the home ER server. 1168 5.3.2. EAP-Initiate/Re-auth Packet 1170 The EAP-Initiate/Re-auth packet contains the parameters shown in 1171 Figure 9. 1173 0 1 2 3 1174 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 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Code | Identifier | Length | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Type |R|B|L| Reserved| SEQ | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | 1 or more TVs or TLVs ~ 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | cryptosuite | Authentication Tag ~ 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 Figure 9: EAP-Initiate/Re-auth Packet 1187 Type = 2. 1189 Flags 1191 'R' - The R flag is set to 0 and ignored upon reception. 1193 'B' - The B flag is used as the bootstrapping flag. If the 1194 flag is turned on, the message is a bootstrap message. 1196 'L' - The L flag is used to request the key lifetimes from the 1197 server. 1199 The remaining 5 bits are set to 0 on transmission and ignored 1200 on reception. 1202 SEQ: A 16-bit sequence number is used for replay protection. The 1203 SEQ number field is initialized to 0 every time a new rRK is 1204 derived. 1206 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1207 and a value with type-specific length. In the TLV payloads, there 1208 is a 1-octet type payload and a 1-octet length payload. The 1209 length field indicates the length of the value expressed in number 1210 of octets. 1212 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1213 The NAI is variable in length, not exceeding 253 octets. The 1214 EMSKname is in the username part of the NAI and is encoded in 1215 hexadecimal values. The EMSKname is 64 bits in length and so 1216 the username portion takes up 16 octets. If the rIK is derived 1217 from the EMSK, the realm part of the NAI is the home domain 1218 name, and if the rIK is derived from a DSRK, the realm part of 1219 the NAI is the domain name used in the derivation of the DSRK. 1220 The NAI syntax follows [RFC4282]. Exactly one keyName-NAI 1221 attribute SHALL be present in an EAP-Initiate/Re-auth packet. 1223 In addition, channel binding information MAY be included; see 1224 Section 5.5 for discussion. See Figure 12 for parameter 1225 specification. 1227 Cryptosuite: This field indicates the integrity algorithm used for 1228 ERP. Key lengths and output lengths are either indicated or are 1229 obvious from the cryptosuite name. We specify some cryptosuites 1230 below: 1232 * 0 RESERVED 1234 * 1 HMAC-SHA256-64 1236 * 2 HMAC-SHA256-128 1238 * 3 HMAC-SHA256-256 1240 HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled in 1241 the default configuration. 1243 Authentication Tag: This field contains the integrity checksum 1244 over the ERP packet, excluding the authentication tag field 1245 itself. The length of the field is indicated by the Cryptosuite. 1247 5.3.3. EAP-Finish/Re-auth Packet 1249 The EAP-Finish/Re-auth packet contains the parameters shown in 1250 Figure 10. 1252 0 1 2 3 1253 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 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Code | Identifier | Length | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Type |R|B|L| Reserved | SEQ ~ 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | 1 or more TVs or TLVs ~ 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | cryptosuite | Authentication Tag ~ 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 Figure 10: EAP-Finish/Re-auth Packet 1266 Type = 2. 1268 Flags 1270 'R' - The R flag is used as the Result flag. When set to 0, it 1271 indicates success, and when set to '1', it indicates a failure. 1273 'B' - The B flag is used as the bootstrapping flag. If the 1274 flag is turned on, the message is a bootstrap message. 1276 'L' - The L flag is used to indicate the presence of the rRK 1277 lifetime TLV. 1279 The remaining 5 bits are set to 0 on transmission and ignored 1280 on reception. 1282 SEQ: A 16-bit sequence number is used for replay protection. The 1283 SEQ number field is initialized to 0 every time a new rRK is 1284 derived. 1286 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1287 and a value with type-specific length. In the TLV payloads, there 1288 is a 1-octet type payload and a 1-octet length payload. The 1289 length field indicates the length of the value expressed in number 1290 of octets. 1292 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1293 The NAI is variable in length, not exceeding 253 octets. 1294 EMSKname is in the username part of the NAI and is encoded in 1295 hexadecimal values. The EMSKname is 64 bits in length and so 1296 the username portion takes up 16 octets. If the rIK is derived 1297 from the EMSK, the realm part of the NAI is the home domain 1298 name, and if the rIK is derived from a DSRK, the realm part of 1299 the NAI is the domain name used in the derivation of the DSRK. 1300 The NAI syntax follows [RFC4282]. Exactly one instance of the 1301 keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth 1302 message. 1304 rRK Lifetime: This is a TV payload. The Type is 2. The value 1305 field is a 32-bit field and contains the lifetime of the rRK in 1306 seconds. If the 'L' flag is set, the rRK Lifetime attribute 1307 SHOULD be present. 1309 rMSK Lifetime: This is a TV payload. The Type is 3. The value 1310 field is a 32-bit field and contains the lifetime of the rMSK 1311 in seconds. If the 'L' flag is set, the rMSK Lifetime 1312 attribute SHOULD be present. 1314 Domain-Name: This is a TLV payload. The Type is 4. The domain 1315 name is to be used as the realm in an NAI [RFC4282]. Domain- 1316 Name attribute MUST be present in an EAP-Finish/Re-auth message 1317 if the bootstrapping flag is set and if the local ER server 1318 sent a DSRK request. 1320 List of cryptosuites: This is a TLV payload. The Type is 5. 1321 The value field contains a list of cryptosuites, each of size 1 1322 octet. The cryptosuite values are as specified in Figure 9. 1323 The server SHOULD include this attribute if the cryptosuite 1324 used in the EAP-Initiate/Re-auth message was not acceptable and 1325 the message is being rejected. The server MAY include this 1326 attribute in other cases. The server MAY use this attribute to 1327 signal to the peer about its cryptographic algorithm 1328 capabilities. 1330 Authorization Indication: This is a TLV payload. The Type is 1331 6. This attribute MAY be included in the EAP-Finish/Re-auth 1332 message when a DSRK is delivered to a local ER server and if 1333 the home EAP server can verify the authorization of the local 1334 ER server to advertise the domain name included in the domain 1335 TLV in the same message. The value field in the TLV contains 1336 an authentication tag computed over the entire packet, starting 1337 from the first bit of the code field to the last bit of the 1338 cryptosuite field, with the value field of the Authorization 1339 Indication TLV filled with all 0s for the computation. The key 1340 used for the computation MUST be derived from the EMSK with key 1341 label "DSRK Delivery Authorized Key@ietf.org" and optional data 1342 containing an ASCII string representing the key management 1343 domain that the DSRK is being derived for. 1345 In addition, channel binding information MAY be included: see 1346 Section 5.5 for discussion. See Figure 12 for parameter 1347 specification. The server sends this information so that the 1348 peer can verify the information seen at the lower layer, if 1349 channel binding is to be supported. 1351 Cryptosuite: This field indicates the integrity algorithm and the 1352 PRF used for ERP. Key lengths and output lengths are either 1353 indicated or are obvious from the cryptosuite name. 1355 Authentication Tag: This field contains the integrity checksum 1356 over the ERP packet, excluding the authentication tag field 1357 itself. The length of the field is indicated by the Cryptosuite. 1359 5.3.4. TV and TLV Attributes 1361 The TV attributes that may be present in the EAP-Initiate or EAP- 1362 Finish messages are of the following format: 1364 0 1 2 3 1365 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 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Type | Value ... 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 Figure 11: TV Attribute Format 1372 The TLV attributes that may be present in the EAP-Initiate or EAP- 1373 Finish messages are of the following format: 1375 0 1 2 3 1376 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 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Type | Length | Value ... 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 Figure 12: TLV Attribute Format 1383 The following Types are defined in this document: 1385 '1' - keyName-NAI: This is a TLV payload. 1387 '2' - rRK Lifetime: This is a TV payload. 1389 '3' - rMSK Lifetime: This is a TV payload. 1391 '4' - domain name: This is a TLV payload. 1393 '5' - cryptosuite list: This is a TLV payload. 1395 '6' - Authorization Indication: This is a TLV payload. 1397 The TLV type range of 128-191 is reserved to carry channel binding 1398 information in the EAP-Initiate and Finish/Re-auth messages. 1399 Below are the current assignments (all of them are TLVs): 1401 '128' - Called-Station-Id [RFC2865] 1403 '129' - Calling-Station-Id [RFC2865] 1404 '130' - NAS-Identifier [RFC2865] 1406 '131' - NAS-IP-Address [RFC2865] 1408 '132' - NAS-IPv6-Address [RFC3162] 1410 The length field indicates the length of the value part of the 1411 attribute in octets. 1413 5.4. Replay Protection 1415 For replay protection, ERP uses sequence numbers. The sequence 1416 number is maintained on a per rIK basis and is initialized to zero in 1417 both directions. In the first EAP-Initiate/Re-auth message, the peer 1418 uses a sequence number value of zero or higher. Note that the when 1419 the sequence number wraps back to zero, the rIK MUST be changed by 1420 running a full EAP authentication. The server expects a sequence 1421 number of zero or higher. When the server receives an EAP-Initiate/ 1422 Re-auth message, it uses the same sequence number in the EAP-Finish/ 1423 Re-auth message. The server then sets the expected sequence number 1424 to the received sequence number plus 1. The server MUST accept 1425 sequence numbers greater than or equal to the expected sequence 1426 number. 1428 If the peer sends an EAP-Initiate/Re-auth message, but does not 1429 receive a response, it retransmits the request (with no changes to 1430 the message itself) a pre-configured number of times before giving 1431 up. However, it is plausible that the server itself may have 1432 responded to the message and the response was lost in transit. Thus, 1433 the peer MUST increment the sequence number and use the new sequence 1434 number to send subsequent EAP re-authentication messages. The peer 1435 SHOULD increment the sequence number by 1; however, it may choose to 1436 increment by a larger number. If the sequence number wraps back to 1437 zero, the peer MUST run full EAP authentication. 1439 5.5. Channel Binding 1441 ERP provides a protected facility to carry channel binding (CB) 1442 information, according to the guidelines provided by Aboba, et al. 1443 (see Section 7.15 of [RFC3748]). The TLV type range of 128-191 is 1444 reserved to carry CB information in the EAP-Initiate/Re-auth and EAP- 1445 Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id, NAS- 1446 Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples of 1447 channel binding information listed in RFC 3748, and they are assigned 1448 values 128-132. Additional values are IANA managed based on IETF 1449 Consensus [RFC5226]. 1451 The authenticator MAY provide CB information to the peer via the EAP- 1452 Initiate/Re-auth-Start message. The peer sends the information to 1453 the server in the EAP-Initiate/Re-auth message; the server verifies 1454 whether the authenticator identity available via AAA attributes is 1455 the same as the identity provided to the peer. 1457 If the peer does not include the CB information in the EAP-Initiate/ 1458 Re-auth message, and if the local ER server's policy requires channel 1459 binding support, it SHALL send the CB attributes for the peer's 1460 verification. The peer attempts to verify the CB information if the 1461 authenticator has sent the CB parameters, and it proceeds with the 1462 lower-layer security association establishment if the attributes 1463 match. Otherwise, the peer SHALL NOT proceed with the lower-layer 1464 security association establishment. 1466 6. Lower-Layer Considerations 1468 The authenticator is responsible for retransmission of EAP-Initiate/ 1469 Re-auth-Start messages. The authenticator MAY retransmit the message 1470 a few times or until it receives an EAP-Initiate/Re-auth message from 1471 the peer. The authenticator might not know if the peer supports ERP; 1472 in those cases, the peer could be silently discarding the EAP- 1473 Initiate/Re-auth-Start packets. Thus, retransmission of these 1474 packets should be kept to a minimum. The exact number is up to each 1475 lower layer. 1477 The Identifier value in the EAP-Initiate/Re-auth packet is 1478 independent of the Identifier value in the EAP-Initiate/Re-auth-Start 1479 packet. 1481 The peer is responsible for retransmission of EAP-Initiate/Re-auth 1482 messages. 1484 Retransmitted packets MUST be sent with the same Identifier value in 1485 order to distinguish them from new packets. By default, where the 1486 EAP-Initiate message is sent over an unreliable lower layer, the 1487 retransmission timer SHOULD be dynamically estimated. A maximum of 1488 3-5 retransmissions is suggested [RFC3748]. Where the EAP-Initiate 1489 message is sent over a reliable lower layer, the retransmission timer 1490 SHOULD be set to an infinite value, so that retransmissions do not 1491 occur at the EAP layer. Please refer to RFC 3748 for additional 1492 guidance on setting timers. 1494 The Identifier value in the EAP-Finish/Re-auth packet is the same as 1495 the Identifier value in the EAP-Initiate/Re-auth packet. 1497 If an authenticator receives a valid duplicate EAP-Initiate/Re-auth 1498 message for which it has already sent an EAP-Finish/Re-auth message, 1499 it MUST resend the EAP-Finish/Re-auth message without reprocessing 1500 the EAP-Initiate/Re-auth message. To facilitate this, the 1501 authenticator SHALL store a copy of the EAP-Finish/Re-auth message 1502 for a finite amount of time. The actual value of time is a local 1503 matter; this specification recommends a value of 100 milliseconds. 1505 The lower layer may provide facilities for exchanging information 1506 between the peer and the authenticator about support for ERP, for the 1507 authenticator to send the domain name information and channel binding 1508 information to the peer 1510 Note that to support ERP, lower-layer specifications may need to be 1511 revised. Specifically, RFC 5996 must be updated to include EAP code 1512 values higher than 4 in order to use ERP with Internet Key Exchange 1513 Protocol version 2 (IKEv2). IKEv2 may also be updated to support 1514 peer-initiated ERP for optimized operation. Other lower layers may 1515 need similar revisions. 1517 Our analysis indicates that some EAP implementations are not RFC 3748 1518 compliant in that instead of silently dropping EAP packets with code 1519 values higher than 4, they may consider it an error. To accommodate 1520 such non-compliant EAP implementations, additional guidance has been 1521 provided below. Furthermore, it may not be easy to upgrade all the 1522 peers in some cases. In such cases, authenticators may be configured 1523 to not send EAP-Initiate/Re-auth-Start; peers may learn whether an 1524 authenticator supports ERP via configuration or from advertisements 1525 at the lower layer. 1527 In order to accommodate implementations that are not compliant to RFC 1528 3748, such lower layers SHOULD ensure that both parties support ERP; 1529 this is trivial for instance when using a lower layer that is known 1530 to always support ERP. For lower layers where ERP support is not 1531 guaranteed, ERP support may be indicated through signaling (e.g., 1532 piggy-backed on a beacon) or through negotiation. Alternatively, 1533 clients may recognize environments where ERP is available based on 1534 pre-configuration. Other similar mechanisms may also be used. When 1535 ERP support cannot be verified, lower layers may mandate falling back 1536 to full EAP authentication to accommodate EAP implementations that 1537 are not compliant to RFC 3748. 1539 7. AAA Transport of ERP Messages 1541 AAA Transport of ERP messages is specified by Hoeper, et al. 1542 [RFC5749] and Bournelle, et al. [I-D.ietf-dime-erp]. 1544 8. Security Considerations 1546 This section provides an analysis of the protocol in accordance with 1547 the AAA key management guidelines described by Housley & Aboba 1548 [RFC4962]. 1550 Cryptographic algorithm independence 1552 The EAP Re-auth Protocol satisfies this requirement. The 1553 algorithm chosen by the peer for the MAC generation is 1554 indicated in the EAP-Initiate/Re-auth message. If the chosen 1555 algorithm is unacceptable, the EAP server returns an EAP- 1556 Finish/Re-auth message with Failure indication. Algorithm 1557 agility for the KDF is specified in Salowey, et al. [RFC5295]. 1558 Only when the algorithms used are deemed acceptable does the 1559 server proceed with the derivation of keys and verification of 1560 the proof of possession of relevant keying material presented 1561 by the peer. A full-blown negotiation of algorithms cannot be 1562 provided in a single round trip protocol. Hence, while the 1563 protocol provides algorithm agility, it does not provide true 1564 negotiation. 1566 Strong, fresh session keys 1568 ERP results in the derivation of strong, fresh keys that are 1569 unique for the given session. An rMSK is always derived on- 1570 demand when the peer requires a key with a new authenticator. 1571 The derivation ensures that the compromise of one rMSK does not 1572 result in the compromise of another rMSK at any time. 1574 Limit key scope 1576 The scope of all the keys derived by ERP is well defined. The 1577 rRK and rIK are never shared with any entity and always remain 1578 on the peer and the server. The rMSK is provided only to the 1579 authenticator through which the peer performs the ERP exchange. 1580 No other authenticator is authorized to use that rMSK. 1582 Replay detection mechanism 1584 For replay protection of ERP messages, a sequence number 1585 associated with the rIK is used. The sequence number is 1586 maintained by the peer and the server, and initialized to zero 1587 when the rIK is generated. The peer increments the sequence 1588 number by one after it sends an ERP message. The server sets 1589 the expected sequence number to the received sequence number 1590 plus one after verifying the validity of the received message 1591 and responds to the message. 1593 Authenticate all parties 1595 The EAP Re-auth Protocol provides mutual authentication of the 1596 peer and the server. Both parties need to possess the keying 1597 material that resulted from a previous EAP exchange in order to 1598 successfully derive the required keys. Also, both the EAP re- 1599 authentication Response and the EAP re-authentication 1600 Information messages are integrity protected so that the peer 1601 and the server can verify each other. When the ERP exchange is 1602 executed with a local ER server, the peer and the local server 1603 mutually authenticate each other via that exchange in the same 1604 manner. The peer and the authenticator authenticate each other 1605 in the secure association protocol executed by the lower layer, 1606 just as in the case of a regular EAP exchange. 1608 Peer and authenticator authorization 1610 The peer and authenticator demonstrate possession of the same 1611 key material without disclosing it, as part of the lower-layer 1612 secure association protocol. Channel binding with ERP may be 1613 used to verify consistency of the identities exchanged, when 1614 the identities used in the lower layer differ from that 1615 exchanged within the AAA protocol. 1617 Keying material confidentiality 1619 The peer and the server derive the keys independently using 1620 parameters known to each entity. The AAA server sends the DSRK 1621 of a domain to the corresponding local ER server via the AAA 1622 protocol. Likewise, the ER server sends the rMSK to the 1623 authenticator via the AAA protocol. 1625 Note that compromise of the DSRK results in compromise of all 1626 keys derived from it. Moreover, there is no forward secrecy 1627 within ERP. Thus, compromise of an DSRK retroactively 1628 compromises all ERP keys. 1630 It is RECOMMENDED that the AAA protocol be protected using 1631 IPsec or TLS so that the keys are protected in transit. Note, 1632 however, that keys may be exposed to AAA proxies along the way 1633 and compromise of any of those proxies may result in compromise 1634 of keys being transported through them. 1636 The home EAP server MUST NOT hand out a given DSRK to a local 1637 domain server more than once, unless it can verify that the 1638 entity receiving the DSRK after the first time is the same as 1639 that received the DSRK originally. If the home EAP server 1640 verifies authorization of a local domain server, it MAY hand 1641 out the DSRK to that domain more than once. In this case, the 1642 home EAP server includes the Authorization Indication TLV to 1643 assure the peer that DSRK delivery is secure. 1645 Confirm cryptosuite selection 1647 Crypto algorithms for integrity and key derivation in the 1648 context of ERP MAY be the same as that used by the EAP method. 1649 In that case, the EAP method is responsible for confirming the 1650 cryptosuite selection. Furthermore, the cryptosuite is 1651 included in the ERP exchange by the peer and confirmed by the 1652 server. The protocol allows the server to reject the 1653 cryptosuite selected by the peer and provide alternatives. 1654 When a suitable rIK is not available for the peer, the 1655 alternatives may be sent in an unprotected fashion. The peer 1656 is allowed to retry the exchange using one of the allowed 1657 cryptosuites. However, in this case, any en route 1658 modifications to the list sent by the server will go 1659 undetected. If the server does have an rIK available for the 1660 peer, the list will be provided in a protected manner and this 1661 issue does not apply. 1663 Uniquely named keys 1665 All keys produced within the ERP context can be referred to 1666 uniquely as specified in this document. Also, the key names do 1667 not reveal any part of the keying material. 1669 Prevent the domino effect 1671 The compromise of one peer does not result in the compromise of 1672 keying material held by any other peer in the system. Also, 1673 the rMSK is meant for a single authenticator and is not shared 1674 with any other authenticator. Hence, the compromise of one 1675 authenticator does not lead to the compromise of sessions or 1676 keys held by any other authenticator in the system. Hence, the 1677 EAP Re-auth Protocol allows prevention of the domino effect by 1678 appropriately defining key scope. 1680 However, if keys are transported using hop-by-hop protection, 1681 compromise of a proxy may result in compromise of key material, 1682 e.g., the DSRK being sent to a local ER server. 1684 Bind key to its context 1686 All the keys derived for ERP are bound to the appropriate 1687 context using appropriate key labels. Lifetime of a child key 1688 is less than or equal to that of its parent key as specified in 1689 RFC 4962 [RFC4962]. The key usage, lifetime and the parties 1690 that have access to the keys are specified. 1692 Confidentiality of identity 1694 Deployments where privacy is a concern may find the use of 1695 rIKname-NAI to route ERP messages serves their privacy 1696 requirements. Note that it is plausible to associate multiple 1697 runs of ERP messages since the rIKname is not changed as part 1698 of the ERP protocol. There was no consensus for that 1699 requirement at the time of development of this specification. 1700 If the rIKname is not used and the Peer-ID is used instead, the 1701 ERP exchange will reveal the Peer-ID over the wire. 1703 Authorization restriction 1705 All the keys derived are limited in lifetime by that of the 1706 parent key or by server policy. Any domain-specific keys are 1707 further restricted for use only in the domain for which the 1708 keys are derived. All the keys specified in this document are 1709 meant for use in ERP only. Other restrictions on the use of 1710 session keys may be imposed by the specific lower layer but are 1711 out of scope for this specification. 1713 Prevent DoS attack 1715 A denial-of-service (DoS) attack on the peer may be possible 1716 when using the EAP Initiate/Re-auth message. An attacker may 1717 send a bogus EAP-Initiate/Re-auth message, which may be carried 1718 by the authenticator in a AAA request to the server; in 1719 response, the server may send an EAP-Finish/Re-auth with 1720 Failure indication in a AAA reply. Note that such attacks may 1721 be possible with the EAPoL-Start capability of IEEE 802.11 and 1722 other similar facilities in other link layers and where the 1723 peer can initiate EAP authentication. An attacker may use such 1724 messages to start an EAP method run, which fails and may result 1725 in the server sending a rejection message, thus resulting in 1726 the link-layer connections being terminated. 1728 To prevent such DoS attacks, an ERP failure should not result 1729 in deletion of any authorization state established by a full 1730 EAP exchange. Alternatively, the lower layers and AAA 1731 protocols may define mechanisms to allow two link-layer 1732 security associations (SAs) derived from different EAP keying 1733 materials for the same peer to exist so that smooth migration 1734 from the current link layer SA to the new one is possible 1735 during rekey. These mechanisms prevent the link layer 1736 connections from being terminated when a re-authentication 1737 procedure fails due to a bogus EAP-Initiate/Re-auth message. 1739 Keying materials Transport 1741 When a DSRK is sent from the home EAP server to a local domain 1742 server or when a rMSK is sent from an ER server to an 1743 authenticator, in the absence of end-to-end security between 1744 the entity that is sending the key and the entity receiving the 1745 key, it is plausible for other entities to get access to keys 1746 being sent to an ER server in another domain. This mode of key 1747 transport is similar to that of MSK transport in the context of 1748 EAP authentication. We further observe that ERP is for access 1749 authentication and does not support end-to-end data security. 1750 In typical implementations, the traffic is in the clear beyond 1751 the access control enforcement point (the authenticator or an 1752 entity delegated by the authenticator for access control 1753 enforcement). The model works as long as entities in the 1754 middle of the network do not use keys intended for other 1755 parties to steal service from an access network. If that is 1756 not achievable, key delivery must be protected in an end-to-end 1757 manner. 1759 9. IANA Considerations 1761 This document has no IANA actions. 1763 10. References 1765 10.1. Normative References 1767 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1768 Hashing for Message Authentication", RFC 2104, 1769 February 1997. 1771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1772 Requirement Levels", BCP 14, RFC 2119, March 1997. 1774 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1775 Levkowetz, "Extensible Authentication Protocol (EAP)", 1776 RFC 3748, June 2004. 1778 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1779 Network Access Identifier", RFC 4282, December 2005. 1781 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 1782 "Specification for the Derivation of Root Keys from an 1783 Extended Master Session Key (EMSK)", RFC 5295, 1784 August 2008. 1786 10.2. Informative References 1788 [I-D.ietf-dime-erp] 1789 Bournelle, J., Morand, L., Decugis, S., Wu, W., and G. 1790 Zorn, "Diameter support for EAP Re-authentication Protocol 1791 (ERP)", draft-ietf-dime-erp-07 (work in progress), 1792 September 2011. 1794 [I-D.ietf-hokey-ldn-discovery] 1795 Zorn, G., Wu, W., and Y. Wang, "The ERP Local Domain Name 1796 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-10 (work in 1797 progress), April 2011. 1799 [I-D.nir-ipsecme-erx] 1800 Nir, Y. and W. Wu, "An IKEv2 Extension for Supporting 1801 ERP", draft-nir-ipsecme-erx-01 (work in progress), 1802 July 2011. 1804 [IEEE_802.1X] 1805 Institute of Electrical and Electronics Engineers, "IEEE 1806 Standards for Local and Metropolitan Area Networks: Port 1807 based Network Access Control, IEEE Std 802.1X-2004", 1808 December 2004. 1810 [MSKHierarchy] 1811 Lopez, R., Skarmeta, A., Bournelle, J., Laurent- 1812 Maknavicus, M., and J. Combes, "Improved EAP keying 1813 framework for a secure mobility access service", 1814 IWCMC '06, Proceedings of the 2006 International 1815 Conference on Wireless Communications and 1816 Mobile Computing, New York, NY, USA, 2006. 1818 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1819 "Remote Authentication Dial In User Service (RADIUS)", 1820 RFC 2865, June 2000. 1822 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1823 RFC 3162, August 2001. 1825 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1826 Protocol Method for 3rd Generation Authentication and Key 1827 Agreement (EAP-AKA)", RFC 4187, January 2006. 1829 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1830 Authorization, and Accounting (AAA) Key Management", 1831 BCP 132, RFC 4962, July 2007. 1833 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 1834 "Handover Key Management and Re-Authentication Problem 1835 Statement", RFC 5169, March 2008. 1837 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1838 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1839 May 2008. 1841 [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of 1842 EAP-Based Keys for Handover and Re-Authentication", 1843 RFC 5749, March 2010. 1845 [RFC5996] Kaufman, C., Hoffman , P., Nir, Y., and P. Eronen, 1846 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1847 RFC 5996, September 2010. 1849 Appendix A. Acknowledgments 1851 A.1. RFC 5296 1853 In writing this document, we benefited from discussing the problem 1854 space and the protocol itself with a number of folks including 1855 Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, 1856 Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, 1857 Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi 1858 Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of 1859 the HOKEY working group. The credit for the idea to use EAP- 1860 Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- 1861 layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin 1862 Hoeper suggested the use of the windowing technique to handle 1863 multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for 1864 the suggestion to use hexadecimal encoding for rIKname when sent as 1865 part of keyName-NAI field. Thanks to Bernard Aboba for suggestions 1866 in clarifying the EAP lock-step operation, and Joe Salowey and Glen 1867 Zorn for help in specifying AAA transport of ERP messages. Thanks to 1868 Sam Hartman for the DSRK Authorization Indication mechanism. 1870 A.2. RFC 5296bis 1872 Thanks to Yaron Sheffer and Yoav Nir for useful comments. 1874 Appendix B. Sample ERP Exchange 1875 0. Authenticator --> Peer: 1876 EAP-Initiate/Re-auth-Start [Optional] 1878 1. Peer --> Authenticator: 1879 EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, 1880 Auth-tag*) 1882 1a. Authenticator --> Re-auth-Server: 1883 AAA-Request 1884 { 1885 Authenticator-Id, 1886 EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, 1887 Auth-tag*) 1888 } 1890 2. ER-Server --> Authenticator: 1891 AAA-Response 1892 { 1893 rMSK, 1894 EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], 1895 Auth-tag*) 1896 } 1898 2b. Authenticator --> Peer: 1899 EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], 1900 Auth-tag*) 1902 * Auth-tag computation is over the entire EAP Initiate/Finish message; 1903 the code values for Initiate and Finish are different and thus 1904 reflection attacks are mitigated. 1906 Authors' Addresses 1908 Qin Wu (editor) 1909 Huawei Technologies Co., Ltd. 1910 101 Software Avenue, Yuhua District 1911 Nanjing, JiangSu 210012 1912 China 1914 Email: Sunseawq@huawei.com 1915 Zhen Cao 1916 China Mobile 1917 53A Xibianmennei Ave., Xuanwu District 1918 Beijing, Beijing 100053 1919 P.R. China 1921 Email: caozhen@chinamobile.com 1923 Glen Zorn (editor) 1924 Network Zen 1925 227/358 Thanon Sanphawut 1926 Bang Na, Bangkok 10260 1927 Thailand 1929 Phone: +66 (0) 87-0404617 1930 Email: glenzorn@gmail.com 1932 Yang Shi 1933 H3C Tech. Co., Ltd 1934 Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District 1935 Beijing 100085 1936 China 1938 Email: young@h3c.com 1940 Baohong He 1941 China 1943 Email: hebaohong@catr.cn