idnits 2.17.1 draft-ietf-hokey-rfc5296bis-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 15, 2011) is 4545 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 275, but not defined == Missing Reference: 'Optional' is mentioned on line 1879, but not defined == Missing Reference: 'CB-Info' is mentioned on line 1902, 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 (~~), 6 warnings (==), 3 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 18, 2012 G. Zorn, Ed. 7 Network Zen 8 Y. Shi 9 H3C 10 B. He 11 CATR 12 November 15, 2011 14 EAP Extensions for EAP Re-authentication Protocol (ERP) 15 draft-ietf-hokey-rfc5296bis-06 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 This memo obsoletes RFC 5296. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 18, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 9 70 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10 71 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 73 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 74 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 75 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 76 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 77 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 78 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 79 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 80 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 81 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 82 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 83 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 84 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 85 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 86 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 87 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 88 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26 89 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 90 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 91 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 92 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 93 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 94 7. AAA Transport of ERP Messages . . . . . . . . . . . . . . . . 34 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 100 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 101 A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 102 A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 103 Appendix B. Sample ERP Exchange . . . . . . . . . . . . . . . . . 41 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 106 1. Introduction 108 The Extensible Authentication Protocol (EAP) is a an authentication 109 framework that supports multiple authentication methods. The primary 110 purpose is network access authentication, and a key-generating method 111 is used when the lower layer wants to enforce access control. The 112 EAP keying hierarchy defines two keys to be derived by all key- 113 generating EAP methods: the Master Session Key (MSK) and the Extended 114 MSK (EMSK). In the most common deployment scenario, an EAP peer and 115 an EAP server authenticate each other through a third party known as 116 the EAP authenticator. The EAP authenticator or an entity controlled 117 by the EAP authenticator enforces access control. After successful 118 authentication, the EAP server transports the MSK to the EAP 119 authenticator; the EAP authenticator and the EAP peer establish 120 transient session keys (TSKs) using the MSK as the authentication 121 key, key derivation key, or a key transport key, and use the TSK for 122 per-packet access enforcement. 124 When a peer moves from one authenticator to another, it is desirable 125 to avoid a full EAP authentication to support fast handovers. The 126 full EAP exchange with another run of the EAP method can take several 127 round trips and significant time to complete, causing increased 128 handover times. Some EAP methods specify the use of state from the 129 initial authentication to optimize re-authentications by reducing the 130 computational overhead (e.g., EAP-AKA [RFC4187]), but method-specific 131 re-authentication takes at least 2 round trips with the original EAP 132 server in most cases. It is also important to note that several 133 methods do not offer support for re-authentication. 135 Key sharing across authenticators is sometimes used as a practical 136 solution to lower handover times. In that case, however, the 137 compromise of one authenticator results in the compromise of keying 138 material established via other authenticators. Other solutions for 139 fast re-authentication exist in the literature: for example, see 140 Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP 141 re-authentication problem statement in detail [RFC5169]. 143 In conclusion, to achieve low latency handovers, there is a need for 144 a method-independent re-authentication protocol that completes in 145 less than 2 round trips, preferably with a local server. 147 This document specifies EAP Re-authentication Extensions (ERXs) for 148 efficient re-authentication using EAP. The protocol that uses these 149 extensions is itself referred to as the EAP Re-authentication 150 Protocol (ERP). It supports EAP method-independent re-authentication 151 for a peer that has valid, unexpired key material from a previously 152 performed EAP authentication. The protocol and the key hierarchy 153 required for EAP re-authentication are described in this document. 155 Note that to support ERP, lower-layer specifications may need to be 156 revised to allow carrying EAP messages that have a code value higher 157 than 4 and to accommodate the peer-initiated nature of ERP. 158 Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must 159 be updated to carry ERP messages; work is in progress on this project 160 [I-D.nir-ipsecme-erx]. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 This document uses the basic EAP terminology [RFC3748] and EMSK 169 keying hierarchy terminology [RFC5295]. In addition, this document 170 uses the following terms: 172 ER Peer - An EAP peer that supports the EAP Re-authentication 173 Protocol. All references to "peer" in this document imply an ER 174 peer, unless specifically noted otherwise. 176 ER Authenticator - An entity that supports the authenticator 177 functionality for EAP re-authentication described in this 178 document. All references to "authenticator" in this document 179 imply an ER authenticator, unless specifically noted otherwise. 181 ER Server - An entity that performs the server portion of ERP 182 described here. This entity may or may not be an EAP server. All 183 references to "server" in this document imply an ER server, unless 184 specifically noted otherwise. An ER server is a logical entity; 185 it may not necessarily be co-located with, or physically part of, 186 a full EAP server. 188 ERX - EAP re-authentication extensions. 190 ERP - EAP Re-authentication Protocol that uses the re- 191 authentication extensions. 193 rRK - re-authentication Root Key, derived from the EMSK or DSRK. 195 rIK - re-authentication Integrity Key, derived from the rRK. 197 rMSK - re-authentication MSK. This is a per-authenticator key, 198 derived from the rRK. 200 keyName-NAI - ERP messages are integrity protected with the rIK or 201 the DS-rIK. The use of rIK or DS-rIK for integrity protection of 202 ERP messages is indicated by the EMSKname [RFC5295]; the protocol, 203 which is ERP; and the realm, which indicates the domain name of 204 the ER server. The EMSKname is copied into the username part of 205 the NAI. 207 Domain - Refers to a "key management domain" as defined in 208 [RFC5295]. For simplicity, it is referred to as "domain" in this 209 document. The terms "home domain" and "local domain" are used to 210 differentiate between the originating key management domain that 211 performs the full EAP exchange with the peer and the local domain 212 to which a peer may be attached at a given time. 214 3. ERP Description 216 ERP allows a peer and server to mutually verify proof of possession 217 of keying material from an earlier EAP method run and to establish a 218 security association between the peer and the authenticator. The 219 authenticator acts as a pass-through entity for the Re-authentication 220 Protocol in a manner similar to that of an EAP authenticator 221 described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange 222 between the peer and the server; it is independent of the lower layer 223 and the EAP method used during the full EAP exchange. The ER server 224 may be in the home domain or in the same (visited) domain as the peer 225 and the authenticator (i.e., the local domain). 227 Figure 2 shows the protocol exchange. The first time the peer 228 attaches to any network, it performs a full EAP exchange (shown in 229 Figure 1) with the EAP server; as a result, an MSK is distributed to 230 the EAP authenticator. The MSK is then used by the authenticator and 231 the peer to establish TSKs as needed. At the time of the initial EAP 232 exchange, the peer and the server also derive an EMSK, which is used 233 to derive a re-authentication Root Key (rRK). More precisely, a re- 234 authentication Root Key is derived from the EMSK or from a Domain- 235 Specific Root Key (DSRK), which is itself derived from the EMSK. The 236 rRK is only available to the peer and the ER server and is never 237 handed out to any other entity. Further, a re-authentication 238 Integrity Key (rIK) is derived from the rRK; the peer and the ER 239 server use the rIK to provide proof of possession while performing an 240 ERP exchange. The rIK is also never handed out to any entity and is 241 only available to the peer and server. 243 EAP Peer EAP Authenticator EAP Server 244 ======== ================= ========== 246 <--- EAP-Request/ ------ 247 Identity 249 ----- EAP Response/ ---> 250 Identity ---AAA(EAP Response/Identity)--> 252 <--- EAP Method -------> <------ AAA(EAP Method --------> 253 exchange exchange) 255 <----AAA(MSK, EAP-Success)------ 257 <---EAP-Success--------- 259 Figure 1: EAP Authentication 261 Peer ER Authenticator ER Server 262 ==== ============= ====== 264 <-- EAP-Initiate/ ----- 265 Re-auth-Start 266 [<-- EAP-Request/ ------ 267 Identity] 269 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 270 Re-auth/ Re-auth/ 271 [Bootstrap] [Bootstrap]) 273 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 274 Re-auth/ Re-auth/ 275 [Bootstrap] [Bootstrap]) 277 Note: [] brackets indicate optionality. 279 Figure 2: ERP Exchange 281 Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this 282 document for the purpose of EAP re-authentication. When the peer 283 identifies a target authenticator that supports EAP re- 284 authentication, it performs an ERP exchange, as shown in Figure 2; 285 the exchange itself may happen when the peer attaches to a new 286 authenticator supporting EAP re-authentication, or prior to 287 attachment. The peer initiates ERP by itself; it may also do so in 288 response to an EAP-Initiate/Re-auth-Start message from the new 289 authenticator. The EAP-Initiate/Re-auth-Start message allows the 290 authenticator to trigger the ERP exchange. The EAP-Finish message 291 also can be used by the authenticator to announce the local domain 292 name. 294 It is plausible that the authenticator does not know whether the peer 295 supports ERP and whether the peer has performed a full EAP 296 authentication through another authenticator. The authenticator MAY 297 initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start 298 message, and if there is no response, send the EAP-Request/Identity 299 message. Note that this avoids having two EAP messages in flight at 300 the same time [RFC3748]. The authenticator may send the EAP- 301 Initiate/Re-auth-Start message and wait for a short, locally 302 configured amount of time. This message indicates to the peer that 303 the authenticator supports ERP. In response to this trigger from the 304 authenticator, the peer can initiate the ERP exchange by sending an 305 EAP-Initiate/Re-auth message. If there is no response from the peer 306 after the necessary number of retransmissions (see Section 6), the 307 authenticator MUST initiate EAP by sending an EAP-Request message, 308 typically the EAP-Request/Identity message. Note that the 309 authenticator may receive an EAP-Initiate/Re-auth message after it 310 has sent an EAP-Request/Identity message. If the authenticator 311 supports ERP, it MUST proceed with the ERP exchange. When the EAP- 312 Request/Identity times out, the authenticator MUST NOT close the 313 connection if an ERP exchange is in progress or has already succeeded 314 in establishing a re-authentication MSK. 316 If the authenticator does not support ERP, it will silently discard 317 EAP-Initiate/Re-auth messages (Section 5.3.2) since the EAP code of 318 those packets is greater than 4 ([RFC3748], Section 4). An ERP- 319 capable peer will exhaust the EAP-Initiate/Re-auth message 320 retransmissions and fall back to EAP authentication by responding to 321 EAP Request/Identity messages from the authenticator. If the peer 322 does not support ERP or if it does not have unexpired key material 323 from a previous EAP authentication, it drops EAP-Initiate/ 324 Re-auth-Start messages. If there is no response to the EAP-Initiate/ 325 Re-auth-Start message, the authenticator SHALL send an EAP Request 326 message (typically EAP Request/Identity) to start EAP authentication. 327 From this point onward, RFC 3748 rules apply. Note that this may 328 introduce some delay in starting EAP. In some lower layers, the 329 delay can be minimized or even avoided by the peer initiating EAP by 330 sending messages such as EAPoL-Start [IEEE_802.1X]. 332 The peer sends an EAP-Initiate/Re-auth message that contains the 333 keyName-NAI to identify the ER server's domain and the rIK used to 334 protect the message, and a sequence number for replay protection. 335 The EAP-Initiate/Re-auth message is integrity protected with the rIK. 336 The authenticator uses the realm in the keyName-NAI [RFC4282] field 337 to send the message to the appropriate ER server. The server uses 338 the keyName to look up the rIK. The server, after verifying proof of 339 possession of the rIK, and freshness of the message, derives a re- 340 authentication MSK (rMSK) from the rRK using the sequence number as 341 an input to the key derivation. The server then updates the expected 342 sequence number to the received sequence number plus one. 344 In response to the EAP-Initiate/Re-auth message, the server sends an 345 EAP-Finish/Re-auth message; this message is integrity protected with 346 the rIK. The server transports the rMSK along with this message to 347 the authenticator. The rMSK is transported in a manner similar to 348 that of the MSK along with the EAP-Success message in a full EAP 349 exchange. Hoeper, et al.[RFC5749] discuss an additional key 350 distribution protocol that can be used to transport the rRK from an 351 EAP server to one of many different ER servers that share a trust 352 relationship with the EAP server. 354 The peer MAY request the rMSK lifetime from the server. If so, the 355 ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message. 357 In an ERP bootstrap exchange, the peer MAY ask the server for the rRK 358 lifetime. If so, the ER server sends the rRK lifetime in the EAP- 359 Finish/Re-auth message. 361 The peer verifies the sequence number and the integrity of the 362 message. It then uses the sequence number in the EAP-Finish/Re-auth 363 message to compute the rMSK. The lower-layer security association 364 protocol is ready to be triggered after this point. 366 The ER server is located either in the home domain or in the visited 367 domain. When the ER server is in the home domain and there is no 368 local ER server in the visited domain, the peer and the server use 369 the rIK and rRK derived from the EMSK; and when the ER server is in 370 the local domain, they use the DS-rIK and DS-rRK corresponding to the 371 local domain. The domain of the ER server is identified by the realm 372 portion of the keyname-NAI in ERP messages. 374 3.1. ERP With the Home ER Server 376 If the peer is in the home domain or there is no local server in the 377 same domain as the peer, it SHOULD initiate an ERP bootstrap exchange 378 with the home ER server to obtain the domain name. 380 The defined ER extensions allow executing the ERP with an ER server 381 in the home domain. The home ER server may be co-located with a home 382 AAA server. ERP with the Home ER Server is similar to the ERP 383 exchange described in Figure 2. 385 Peer ER Authenticator Home ER Server 386 ==== ============= ====== 388 <-- EAP-Initiate/ ----- 389 Re-auth-Start 390 [<-- EAP-Request/ ------ 391 Identity] 393 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 394 Re-auth/ Re-auth/ 395 Bootstrap Bootstrap) 397 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 398 Re-auth/ Re-auth/ 399 Bootstrap Bootstrap) 401 Figure 3: ER Explicit Bootstrapping Exchange/ERP with the Home ER 402 Sever 404 3.2. ERP with a Local ER Server 406 The defined ER extensions allow the execution of ERP with an ER 407 server in the local domain (access network) if the peer moves out of 408 home domain and a local ER server is present in the visited domain. 409 The local ER server may be co-located with a local AAA server. The 410 peer may learn about the presence of a local ER server in the network 411 and the local domain name (or ER server name) either via a lower 412 layer advertisement or by means of ERP exchange. The peer uses the 413 domain name and the EMSK to compute the DSRK and from that key, the 414 DS-rRK; the peer also uses the domain name in the realm portion of 415 the keyName-NAI for using ERP in the local domain. Figure 4 shows 416 the ER Implicit bootstrapping exchange through local ER 417 Server;Figure 5shows ERP with a local ER server. 419 Peer EAP Authenticator Local AAA Agent Home EAP Server 420 /ER Authenticator /Local ER Server 421 ==== ================= =============== =============== 423 <-- EAP-Request/ -- 424 Identity 426 -- EAP Response/--> 427 Identity --AAA(EAP Response/--> 428 Identity, --AAA(EAP Response/ --> 429 [domain name]) Identity, 430 [DSRK Request, 431 domain name]) 433 <------------------------ EAP Method exchange------------------> 435 <---AAA(MSK, DSRK, ---- 436 EMSKname, 437 EAP-Success) 439 <--- AAA(MSK, ----- 440 EAP-Success) 442 <---EAP-Success----- 444 Figure 4: Implicit Bootstrapping ERP Exchange, Initial EAP Exchange 446 Peer ER Authenticator Local ER Server 447 ==== ================ =============== 449 <-- EAP-Initiate/ -------- 450 Re-auth-Start 451 [<-- EAP-Request/ --------- 452 Identity] 454 ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> 455 Re-auth Re-auth) 457 <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- 458 Re-auth Re-auth) 459 Figure 5: Local ERP Exchange 461 As shown in Figure 4, the local ER server may be present in the path 462 of the full EAP exchange (e.g., this may be one of the AAA entities, 463 such as AAA proxies, in the path between the EAP authenticator and 464 the home EAP server of the peer). In that case, the local ER server 465 requests the DSRK by sending the domain name to the home EAP server 466 by means of an AAA message. In response, the home EAP server 467 computes the DSRK by following the procedure specified in [RFC5295] 468 and sends the DSRK and the key name, EMSKname, to the ER server in 469 the claimed domain (i.e., the local ER Server). The local domain is 470 responsible for announcing that same domain name to the peer via a 471 lower layer (for example, through DHCP-based local domain name 472 discovery [I-D.ietf-hokey-ldn-discovery], or through the EAP- 473 Initiate/Re-auth-Start message with the local ER server. 475 After receiving the DSRK and the EMSKname, the local ER server 476 computes the DS-rRK and the DS-rIK from the DSRK as defined in 477 Sections 4.1 and 4.3 below. After receiving the domain name, the 478 peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys 479 are referred to by a keyName-NAI formed as follows: the username part 480 of the NAI is the EMSKname, the realm portion of the NAI is the 481 domain name. Both parties also maintain a sequence number 482 (initialized to zero) corresponding to the specific keyName-NAI. 484 If the peer subsequently attaches to an authenticator within the 485 local domain, it may perform an ERP exchange with the local ER server 486 to obtain a rMSK for the new authenticator. The ERP with the local 487 ER Server is similar to ERP exchange illustrated in Figure 2. 489 4. ER Key Hierarchy 491 Each time the peer re-authenticates to the network, the peer and the 492 authenticator establish an rMSK. The rMSK serves the same purposes 493 that an MSK, which is the result of full EAP authentication, serves. 494 To prove possession of the rRK, we specify the derivation of another 495 key, the rIK. These keys are derived from the rRK. Together they 496 constitute the ER key hierarchy. 498 The rRK is derived from either the EMSK or a DSRK as specified in 499 Section 4.1. For the purpose of rRK derivation, this document 500 specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- 501 Specific USRK (DSUSRK) [RFC5295] for re-authentication. The USRK 502 designated for re-authentication is the re-authentication root key 503 (rRK). A DSUSRK designated for re-authentication is the DS-rRK 504 available to a local ER server in a particular domain. For 505 simplicity, the keys are referred to without the DS label in the rest 506 of the document. However, the scope of the various keys is limited 507 to just the respective domains for which they are derived, in the 508 case of the domain specific keys. Based on the ER server with which 509 the peer performs the ERP exchange, it knows the corresponding keys 510 that must be used. 512 The rRK is used to derive an rIK, and rMSKs for one or more 513 authenticators. The figure below shows the key hierarchy with the 514 rRK, rIK, and rMSKs. 516 rRK 517 | 518 +--------+--------+ 519 | | | 520 rIK rMSK1 ...rMSKn 522 Figure 6: Re-authentication Key Hierarchy 524 The derivations in this document are from RFC 5295. Key derivations 525 and field encodings, where unspecified, default to that document. 527 4.1. rRK Derivation 529 The rRK may be derived from the EMSK or DSRK. This section provides 530 the relevant key derivations for that purpose. 532 The rRK is derived as specified in RFC 5295. 534 rRK = KDF (K, S), where 536 K = EMSK or K = DSRK and 538 S = rRK Label | "\0" | length 540 The rRK Label is an IANA-assigned 8-bit ASCII string: 542 EAP Re-authentication Root Key@ietf.org 544 assigned from the "USRK key labels" name space in accordance with the 545 policy stated in RFC 5295. 547 The KDF and algorithm agility for the KDF are as defined in RFC 5295. 549 An rRK derived from the DSRK is referred to as a DS-rRK in the rest 550 of the document. All the key derivation and properties specified in 551 this section remain the same. 553 4.2. rRK Properties 555 The rRK has the following properties. These properties apply to the 556 rRK regardless of the parent key used to derive it. 558 o The length of the rRK MUST be equal to the length of the parent 559 key used to derive it. 561 o The rRK is to be used only as a root key for re-authentication and 562 never used to directly protect any data. 564 o The rRK is only used for the derivation of the rIK and rMSK as 565 specified in this document. 567 o The rRK MUST remain on the peer and the server that derived it and 568 MUST NOT be transported to any other entity. 570 o The lifetime of the rRK is never greater than that of its parent 571 key. The rRK is expired when the parent key expires and MUST be 572 removed from use at that time. 574 4.3. rIK Derivation 576 The re-authentication Integrity Key (rIK) is used for integrity 577 protecting the ERP exchange. This serves as the proof of possession 578 of valid keying material from a previous full EAP exchange by the 579 peer to the server. 581 The rIK is derived as follows. 583 rIK = KDF (K, S), where 585 K = rRK and 587 S = rIK Label | "\0" | cryptosuite | length 589 The rIK Label is the 8-bit ASCII string: 591 Re-authentication Integrity Key@ietf.org 593 The length field refers to the length of the rIK in octets encoded as 594 specified in RFC 5295. 596 The cryptosuite and length of the rIK are part of the input to the 597 key derivation function to ensure cryptographic separation of keys if 598 different rIKs of different lengths (for example, for use with 599 different Message Authentication Code (MAC) algorithms) are derived 600 from the same rRK. The cryptosuite is encoded as an 8-bit number; 601 see Section 5.3.2 for the cryptosuite specification. 603 The rIK is referred to by the EMSKname-NAI within the context of ERP 604 messages. The username part of EMSKname-NAI is the EMSKname; the 605 realm is the domain name of the ER server. In case of ERP with the 606 home ER server, the peer uses the realm from its original NAI; in 607 case of a local ER server, the peer uses the domain name received at 608 the lower layer or through an ERP bootstrapping exchange. 610 A rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of 611 the document. All of the key derivation and properties specified in 612 this section remain the same. 614 4.4. rIK Properties 616 The rIK has the following properties. 618 o The length of the rIK MUST be equal to the length of the rRK. 620 o The rIK is only used for authentication of the ERP exchange as 621 specified in this document. 623 o The rIK MUST NOT be used to derive any other keys. 625 o The rIK must remain on the peer and the server and MUST NOT be 626 transported to any other entity. 628 o The rIK is cryptographically separate from any other keys derived 629 from the rRK. 631 o The lifetime of the rIK is never greater than that of its parent 632 key. The rIK MUST be expired when the EMSK expires and MUST be 633 removed from use at that time. 635 4.5. rIK Usage 637 The rIK is the key the possession of which is demonstrated by the 638 peer and the ERP server to the other party. The peer demonstrates 639 possession of the rIK by computing the integrity checksum over the 640 EAP-Initiate/Re-auth message. When the peer uses the rIK for the 641 first time, it can choose the integrity algorithm to use with the 642 rIK. The peer and the server MUST use the same integrity algorithm 643 with a given rIK for all ERP messages protected with that key. The 644 peer and the server store the algorithm information after the first 645 use, and they employ the same algorithm for all subsequent uses of 646 that rIK. 648 If the server's policy does not allow the use of the cryptosuite 649 selected by the peer, the server SHALL reject the EAP-Initiate/ 650 Re-auth message and SHOULD send a list of acceptable cryptosuites in 651 the EAP-Finish/Re-auth message. 653 The rIK length may be different from the key length required by an 654 integrity algorithm. In case of hash-based MAC algorithms, the key 655 is first hashed to the required key length using the HMAC algorithm 656 RFC 2104 [RFC2104]. In case of cipher-based MAC algorithms, if the 657 required key length is less than 32 octets, the rIK is hashed using 658 HMAC-SHA256 and the first k octets of the output are used, where k is 659 the key length required by the algorithm. If the required key length 660 is more than 32 octets, the first k octets of the rIK are used by the 661 cipher-based MAC algorithm. 663 4.6. rMSK Derivation 665 The rMSK is derived at the peer and server and delivered to the 666 authenticator. The rMSK is derived following an EAP Re-auth Protocol 667 exchange. 669 The rMSK is derived as follows. 671 rMSK = KDF (K, S), where 673 K = rRK and 675 S = rMSK label | "\0" | SEQ | length 677 The rMSK label is the 8-bit ASCII string: 679 Re-authentication Master Session Key@ietf.org 681 The length field refers to the length of the rMSK in octets. The 682 length field is encoded as specified in RFC 5295. 684 SEQ is the sequence number sent by the peer in the EAP-Initiate/ 685 Re-auth message. This field is encoded as a 16-bit number in network 686 byte order (see Section 5.3.2). 688 An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest 689 of the document. The key derivation and properties specified in this 690 section remain the same. 692 4.7. rMSK Properties 694 The rMSK has the following properties: 696 o The length of the rMSK MUST be equal to the length of the rRK. 698 o The rMSK is delivered to the authenticator and is used for the 699 same purposes that an MSK is used at an authenticator. 701 o The rMSK is cryptographically separate from any other keys derived 702 from the rRK. 704 o The lifetime of the rMSK is less than or equal to that of the rRK. 705 It MUST NOT be greater than the lifetime of the rRK. 707 o If a new rRK is derived, subsequent rMSKs MUST be derived from the 708 new rRK. Previously delivered rMSKs MAY still be used until the 709 expiry of the lifetime. 711 o A given rMSK MUST NOT be shared by multiple authenticators. 713 5. Protocol Details 715 5.1. ERP Bootstrapping 717 We identify two types of bootstrapping for ERP: explicit and 718 implicit. In implicit bootstrapping, the ER-capable authenticator or 719 local ER server MUST verify whether it has valid rMSK or rRK 720 corresponding to the peer. If ER capable authenticator or the local 721 ER server has the key materials corresponding to the peer, it MUST be 722 able to respond directly in the same way as the home AAA server does 723 without forwarding the DSRK request to the home domain; if not, the 724 ER-capable authenticator or local ER server SHOULD include its domain 725 name in the AAA message encapsulating the first EAP Response message 726 sent by the peer and request the DSRK from the home EAP server during 727 the initial EAP exchange. If such EAP exchange is successful, the 728 home EAP server sends the DSRK for the specified local AAA client or 729 agent (derived using the EMSK and the domain name as specified in RFC 730 5295), EMSKname, and DSRK lifetime along with the EAP-Success 731 message. The local AAA client or agent MUST extract the DSRK, 732 EMSKname, and DSRK lifetime (if present) before forwarding the EAP- 733 Success message to the peer. Note that the MSK (also present with 734 the EAP Success message) is extracted by the EAP authenticator as 735 usual. The peer learns the domain name through the EAP-Initiate/ 736 Re-auth-Start message or by means of lower-layer announcement (for 737 example, DHCP [I-D.ietf-hokey-ldn-discovery]). When the domain name 738 is available to the peer during or after the full EAP authentication, 739 it attempts to use ERP when it associates with a new authenticator. 741 If the peer knows there is no local ER server presented in the 742 visited domain, it SHOULD initiate Explicit ERP bootstrapping (ERP 743 exchange with the bootstrap flag turned on) with the home ER server 744 to obtain the rRK. The peer MAY also initiate bootstrapping to fetch 745 information such as the rRK lifetime from the AAA server. 747 The following steps describe the ERP Explicit Bootstrapping process: 749 o The peer sends the EAP-Initiate/Re-auth message with the 750 bootstrapping flag set (1). The bootstrap message is always sent 751 to the home ER server, and the keyname-NAI attribute in the 752 bootstrap message is constructed as follows: the username portion 753 of the NAI contains the EMSKname, and the realm portion contains 754 the home domain name. 756 o In addition, the message MUST contain a sequence number for replay 757 protection, a cryptosuite, and an integrity checksum. The 758 cryptosuite indicates the authentication algorithm. The integrity 759 checksum indicates that the message originated at the claimed 760 entity, the peer indicated by the Peer-ID, or the rIKname. 762 o The peer MAY additionally set the lifetime flag to request the key 763 lifetimes. 765 o Upon receipt of the EAP-Initiate/Re-auth message from a peer, the 766 ERP-capable authenticator verifies whether it has the local domain 767 name and valid key materials corresponding to the peer. If it 768 knows the local domain name and has valid key material 769 corresponding to the peer, it MUST be able to respond directly in 770 the same way as the home ER does with local domain name included. 771 If not, it copies the contents of the keyName-NAI into the 772 appropriate AAA attribute and may include its domain name in the 773 AAA message encapsulating the EAP-Initiate/Re-auth message sent by 774 the peer. 776 o Upon receipt of an EAP-Initiate/Re-auth message, the home ER 777 server verifies whether the message is fresh or is a replay by 778 evaluating whether the received sequence number is equal to or 779 greater than the expected sequence number for that rIK. The home 780 ER server then verifies that the cryptosuite used by the peer is 781 acceptable. Next, it verifies the integrity of the message by 782 looking up the rIK and checking integrity checksum contained in 783 the Authentication Tag field. If any of the checks fail, the home 784 ER server sends an EAP-Finish/Re-auth message with the Result flag 785 set to '1'. Please refer to Section 5.2.2 for details on failure 786 handling. This error MUST NOT have any correlation to any EAP- 787 Success message that may have been received by the EAP 788 authenticator and the peer earlier. If the EAP-Initiate/Re-auth 789 message is well-formed and valid, the server prepares the EAP- 790 Finish/Re-auth message. The bootstrap flag MUST be set to 791 indicate that this is a bootstrapping exchange. The message 792 contains the following fields: 794 * A sequence number for replay protection. 796 * The same keyName-NAI as in the EAP-Initiate/Re-auth message. 798 * If the lifetime flag was set in the EAP-Initiate/Re-auth 799 message, the ER server SHOULD include the rRK lifetime and the 800 rMSK lifetime in the EAP-Finish/Re-auth message. The server 801 may have a local policy for the network to maintain and enforce 802 lifetime unilaterally. In such cases, the server need not 803 respond to the peer's request for the lifetime. 805 * If the bootstrap flag is set, the ER server MUST include the 806 domain name to which the DSRK is being sent along with the EAP- 807 Finish/Re-auth message. 809 * If the ER server verifies the authorization of a local ER 810 server, it MAY include the Authorization Indication TLV to 811 indicate to the peer that the server that received the DSRK and 812 that is advertising the domain included in the domain name TLV 813 is authorized. 815 * An authentication tag MUST be included to prove that the EAP- 816 Finish/Re-auth message originates at a server that possesses 817 the rIK corresponding to the EMSKname-NAI. 819 o If the home ER server gets involved in ERP exchange and the ERP 820 exchange is successful, the home ER server SHOULD request the DSRK 821 from the home EAP server; the home EAP server MUST provide the 822 DSRK for the home ER server (derived using the EMSK and the domain 823 name as specified in RFC 5295), EMSKname, and DSRK lifetime for 824 inclusion in the AAA message. The home ER server SHOULD obtain 825 them before sending the EAP-Finish/Re-auth message. 827 o In addition, the rMSK is sent along with the EAP-Finish/Re-auth 828 message in a AAA attribute (for an example, see Bournelle, et 829 al.[I-D.ietf-dime-erp]. 831 o The authenticator receives the rMSK. 833 o When the peer receives an EAP-Finish/Re-auth message with the 834 bootstrap flag set, if a local domain name is present, it MUST use 835 that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- 836 NAI, and initialize the replay counter for the DS-rIK. If not, 837 the peer SHOULD derive the domain-specific keys using the domain 838 name it learned via the lower layer or from the EAP-Initiate/ 839 Re-auth-Start message. If the peer does not know the domain name, 840 it must assume that there is no local ER server available. 842 o The peer MAY also verify the Authorization Indication TLV. 844 o The procedures for encapsulating ERP and obtaining relevant keys 845 using Diameter are specified in [I-D.ietf-dime-erp]. 847 Since the ER bootstrapping exchange is typically done immediately 848 following the full EAP exchange, it is feasible that the process is 849 completed through the same entity that served as the EAP 850 authenticator for the full EAP exchange. In this case, the lower 851 layer may already have established TSKs based on the MSK received 852 earlier. The lower layer may then choose to ignore the rMSK that was 853 received with the ER bootstrapping exchange. Alternatively, the 854 lower layer may choose to establish a new TSK using the rMSK. In 855 either case, the authenticator and the peer know which key is used 856 based on whether or not a TSK establishment exchange is initiated. 857 The bootstrapping exchange may also be carried out via a new 858 authenticator, in which case, the rMSK received SHOULD trigger a 859 lower layer TSK establishment exchange. 861 5.2. Steps in ERP 863 When a peer that has an active rRK and rIK associates with a new 864 authenticator that supports ERP, it may perform an ERP exchange with 865 that authenticator. ERP is typically a peer-initiated exchange, 866 consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth 867 message. The ERP exchange may be performed with a local ER server 868 (when one is present) or with the original EAP server. 870 It is plausible for the network to trigger the EAP re-authentication 871 process, however. An ERP-capable authenticator SHOULD send an EAP- 872 Initiate/Re-auth-Start message to indicate support for ERP. The peer 873 may or may not wait for these messages to arrive to initiate the EAP- 874 Initiate/Re-auth message. 876 The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- 877 capable authenticator. The authenticator may retransmit it a few 878 times until it receives an EAP-Initiate/Re-auth message in response 879 from the peer. The EAP-Initiate/Re-auth message from the peer may 880 have originated before the peer receives either an EAP-Request/ 881 Identity or an EAP-Initiate/Re-auth-Start message from the 882 authenticator. Hence, the Identifier value in the EAP-Initiate/ 883 Re-auth message is independent of the Identifier value in the EAP- 884 Initiate/Re-auth-Start or the EAP-Request/Identity messages. 886 Operational Considerations at the Peer: 888 ERP requires that the peer maintain retransmission timers for 889 reliable transport of EAP re-authentication messages. The 890 reliability considerations of Section 4.3 of RFC 3748 apply with the 891 peer as the retransmitting entity. 893 The EAP Re-auth Protocol has the following steps: 895 The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start 896 message to trigger the ERP exchange. 898 The peer sends an EAP-Initiate/Re-auth message. At a minimum, the 899 message SHALL include the following fields: 901 a 16-bit sequence number for replay protection 903 keyName-NAI as a TLV attribute to identify the rIK used to 904 integrity protect the message. 906 cryptosuite to indicate the authentication algorithm used to 907 compute the integrity checksum. 909 Authentication Tag computed over the message. 911 When the peer is performing ERP with a local ER server, it MUST 912 use the corresponding DS-rIK it shares with the local ER server. 913 The peer SHOULD set the lifetime flag to request the key lifetimes 914 from the server. The peer can use the rRK lifetime to know when 915 to trigger an EAP method exchange and the rMSK lifetime to know 916 when to trigger another ERP exchange. 918 The authenticator copies the contents of the value field of the 919 keyName-NAI TLV into an appropriate attribute (e.g, User-Name 920 [RFC2865]) in the AAA message to the ER server. 922 The ER server uses the keyName-NAI to look up the rIK. It MUST 923 first verify whether the sequence number is equal to or greater 924 than the expected sequence number. If the ER server supports a 925 sequence number window size greater than 1, it MUST verify whether 926 the sequence number falls within the window and has not been 927 received before. The ER server MUST then verify that the 928 cryptosuite used by the peer is acceptable. The ER server then 929 proceeds to verify the integrity of the message using the rIK, 930 thereby verifying proof of possession of that key by the peer. If 931 any of these verifications fail, the ER server MUST send an EAP- 932 Finish/Re-auth message with the Result flag set to '1' (Failure). 933 Please refer to Section 5.2.2 for details on failure handling. 934 Otherwise, it MUST compute an rMSK from the rRK using the sequence 935 number as the additional input to the key derivation. 937 In response to a well-formed EAP Re-auth/Initiate message, the ER 938 server MUST send an EAP-Finish/Re-auth message with the following 939 contents: 941 a 16-bit sequence number for replay protection, which MUST be 942 the same as the received sequence number. The local copy of 943 the sequence number MUST be incremented by 1. If the ER server 944 supports multiple simultaneous ERP exchanges, it MUST instead 945 update the sequence number window. 947 keyName-NAI as a TLV attribute to identify the rIK used to 948 integrity protect the message. 950 cryptosuite to indicate the authentication algorithm used to 951 compute the integrity checksum. 953 Authentication Tag over the message. 955 If the lifetime flag was set in the EAP-Initiate/Re-auth 956 message, the ER server SHOULD include the rRK lifetime and the 957 rMSK lifetime. 959 The ER server causes the rMSK along with this message to to be 960 transported to the authenticator. The rMSK is transported in a 961 manner similar to the MSK and the EAP-Success message in a regular 962 EAP exchange. 964 The peer looks up the sequence number to verify whether it is 965 expecting an EAP-Finish/Re-auth message with that sequence number 966 protected by the keyName-NAI. It then verifies the integrity of 967 the message. If the verifications fail, the peer logs an error 968 and stops the process; otherwise, it proceeds to the next step. 970 The peer uses the sequence number to compute the rMSK. 972 The lower-layer security association protocol can be triggered at 973 this point. 975 5.2.1. Multiple Simultaneous Runs of ERP 977 When a peer is within the range of multiple authenticators, it may 978 choose to run ERP via all of them simultaneously to the same ER 979 server. In that case, it is plausible that the ERP messages may 980 arrive out of order, resulting in the ER server rejecting legitimate 981 EAP-Initiate/Re-auth messages. 983 To facilitate such operation, an ER server MAY allow multiple 984 simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth 985 messages with SEQ number values within a window of allowed values. 986 Recall that the SEQ number allows replay protection. Replay window 987 maintenance mechanisms are a local matter. 989 5.2.2. ERP Failure Handling 991 If the processing of the EAP-Initiate/Re-auth message results in a 992 failure, the ER server MUST send an EAP-Finish Re-auth message with 993 the Result flag set to '1'. If the server has a valid rIK for the 994 peer, it MUST integrity protect the EAP-Finish/Re-auth failure 995 message. If the failure is due to an unacceptable cryptosuite, the 996 server SHOULD send a list of acceptable cryptosuites (in a TLV of 997 Type 5) along with the EAP-Finish/Re-auth message. In this case, the 998 server MUST indicate the cryptosuite used to protect the EAP-Finish/ 999 Re-auth message in the cryptosuite. The rIK used with the EAP- 1000 Finish/Re-auth message in this case MUST be computed as specified in 1001 Section 4.3 using the new cryptosuite. If the server does not have a 1002 valid rIK for the peer, the EAP-Finish/Re-auth message indicating a 1003 failure will be unauthenticated; the server MAY include a list of 1004 acceptable cryptosuites in the message. 1006 The peer, upon receiving an EAP-Finish/Re-auth message with the 1007 Result flag set to '1', MUST verify the sequence number and, if 1008 possible, the Authentication Tag to determine the validity of the 1009 message. If the peer supports the cryptosuite, it MUST verify the 1010 integrity of the received EAP-Finish/Re-auth message. If the EAP- 1011 Finish message contains a TLV of Type 5, the peer SHOULD retry the 1012 ERP exchange with a cryptosuite picked from the list included by the 1013 server. The peer MUST use the appropriate rIK for the subsequent ERP 1014 exchange, by computing it with the corresponding cryptosuite, as 1015 specified in Section 4.3. If the PRF in the chosen cryptosuite is 1016 different from the PRF originally used by the peer, it MUST derive a 1017 new DSRK (if required), rRK, and rIK before proceeding with the 1018 subsequent ERP exchange. 1020 If the peer cannot verify the integrity of the received message, it 1021 MAY choose to retry the ERP exchange with one of the cryptosuites in 1022 the List of cryptosuites TLV, after a failure has been clearly 1023 determined following the procedure in the next paragraph. 1025 If the replay or integrity checks fail, the failure message may have 1026 been sent by an attacker. It may also mean that the server and peer 1027 do not support the same cryptosuites; however, the peer cannot 1028 determine if that is the case. Hence, the peer SHOULD continue the 1029 ERP exchange per the retransmission timers before declaring a 1030 failure. 1032 When the peer runs explicit bootstrapping (ERP with the bootstrapping 1033 flag on), there may not be a local ER server available to send a DSRK 1034 Request and the domain name. In that case, the server cannot send 1035 the DSRK and MUST NOT include the domain name TLV. When the peer 1036 receives a response in the bootstrapping exchange without a domain 1037 name TLV, it assumes that there is no local ER server. The home ER 1038 server sends an rMSK to the ER authenticator, however, and the peer 1039 SHALL run the TSK establishment protocol as usual. 1041 5.3. New EAP Packets 1043 Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate 1044 and EAP-Finish. The packet format for these messages follows the EAP 1045 packet format defined in Aboba. et al. [RFC3748]. 1047 0 1 2 3 1048 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 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Code | Identifier | Length | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Type | Type-Data ... 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1055 Figure 7: EAP Packet 1057 Code 1059 Two new code values are defined for the purpose of ERP: 1061 5 Initiate 1063 6 Finish 1065 Identifier 1067 The Identifier field is one octet. The Identifier field MUST 1068 be the same if an EAP-Initiate packet is retransmitted due to a 1069 timeout while waiting for a EAP-Finish message. Any new (non- 1070 retransmission) EAP-Initiate message MUST use a new Identifier 1071 field. 1073 The Identifier field of the EAP-Finish message MUST match that 1074 of the currently outstanding EAP-Initiate message. A peer or 1075 authenticator receiving a EAP-Finish message whose Identifier 1076 value does not match that of the currently outstanding EAP- 1077 Initiate message MUST silently discard the packet. 1079 In order to avoid confusion between new EAP-Initiate messages 1080 and retransmissions, the peer must choose an Identifier value 1081 that is different from the previous EAP-Initiate message, 1082 especially if that exchange has not finished. It is 1083 RECOMMENDED that the authenticator clear EAP Re-auth state 1084 after 300 seconds. 1086 Type 1088 This field indicates that this is an ERP exchange. Two type 1089 values are defined in this document for this purpose -- Re- 1090 auth-Start (Type 1) and Re-auth (Type 2). 1092 Type-Data 1094 The Type-Data field varies with the Type of re-authentication 1095 packet. 1097 5.3.1. EAP-Initiate/Re-auth-Start Packet 1099 The EAP-Initiate/Re-auth-Start packet contains the fields shown in 1100 Figure 8. 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Code | Identifier | Length | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Type | Reserved | 1 or more TVs or TLVs ~ 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Figure 8: EAP-Initiate/Re-auth-Start Packet 1112 Type = 1. 1114 Reserved, MUST be zero. Set to zero on transmission and ignored 1115 on reception. 1117 One or more TVs or TLVs are used to convey information to the 1118 peer; for instance, the authenticator may send the domain name to 1119 the peer. 1121 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1122 and a value with type-specific length. In the TLV payloads, there 1123 is a 1-octet type payload and a 1-octet length payload. The 1124 length field indicates the length of the value expressed in number 1125 of octets. 1127 Domain-Name: This is a TLV payload. The Type is 4. The domain 1128 name is to be used as the realm in an NAI [RFC4282]. The 1129 Domain-Name TLV SHOULD be present in an EAP-Initiate/ 1130 Re-auth-Start message. 1132 In addition, channel binding information MAY be included; see 1133 Section 5.5 for discussion. See Figure 12 for parameter 1134 specification. 1136 5.3.1.1. Authenticator Operation 1138 In order to minimize ERP failure times, the authenticator SHOULD send 1139 the EAP-Initiate/Re-auth-Start message to indicate support for ERP to 1140 the peer and to initiate ERP if the peer has already performed full 1141 EAP authentication and has unexpired key material. The authenticator 1142 SHOULD include the Domain-Name TLV to allow the peer to learn it 1143 without requiring either lower-layer support or the ERP bootstrapping 1144 exchange. 1146 The authenticator MAY include channel binding information so so that 1147 the server can verify whether the authenticator is claiming the same 1148 identity to both parties. 1150 The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start 1151 message a few times for reliable transport. 1153 5.3.1.2. Peer Operation 1155 The peer SHOULD send the EAP-Initiate/Re-auth message in response to 1156 the EAP-Initiate/Re-auth-Start message from the authenticator. If 1157 the peer does not recognize the EAP-Initiate code value or if the 1158 peer has already sent the EAP-Initiate/Re-auth message to begin the 1159 ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start 1160 message. 1162 If the EAP-Initiate/Re-auth-Start message contains the domain name, 1163 and if the peer does not already have the domain information, the 1164 peer SHOULD use the domain name contained in the message to compute 1165 the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/ 1166 Re-auth message to start an ERP exchange with the local ER server. 1167 If there is a local ER server between the peer and the home ER server 1168 and the peer has already initiated an ERP exchange with the local ER 1169 server, it SHOULD NOT start an ERP exchange with the home ER server. 1171 5.3.2. EAP-Initiate/Re-auth Packet 1173 The EAP-Initiate/Re-auth packet contains the parameters shown in 1174 Figure 9. 1176 0 1 2 3 1177 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 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Code | Identifier | Length | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Type |R|B|L| Reserved| SEQ | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | 1 or more TVs or TLVs ~ 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | cryptosuite | Authentication Tag ~ 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 Figure 9: EAP-Initiate/Re-auth Packet 1190 Type = 2. 1192 Flags 1194 'R' - The R flag is set to 0 and ignored upon reception. 1196 'B' - The B flag is used as the bootstrapping flag. If the 1197 flag is turned on, the message is a bootstrap message. 1199 'L' - The L flag is used to request the key lifetimes from the 1200 server. 1202 The remaining 5 bits are set to 0 on transmission and ignored 1203 on reception. 1205 SEQ: A 16-bit sequence number is used for replay protection. The 1206 SEQ number field is initialized to 0 every time a new rRK is 1207 derived. 1209 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1210 and a value with type-specific length. In the TLV payloads, there 1211 is a 1-octet type payload and a 1-octet length payload. The 1212 length field indicates the length of the value expressed in number 1213 of octets. 1215 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1216 The NAI is variable in length, not exceeding 253 octets. The 1217 EMSKname is in the username part of the NAI and is encoded in 1218 hexadecimal values. The EMSKname is 64 bits in length and so 1219 the username portion takes up 16 octets. If the rIK is derived 1220 from the EMSK, the realm part of the NAI is the home domain 1221 name, and if the rIK is derived from a DSRK, the realm part of 1222 the NAI is the domain name used in the derivation of the DSRK. 1223 The NAI syntax follows [RFC4282]. Exactly one keyName-NAI 1224 attribute SHALL be present in an EAP-Initiate/Re-auth packet. 1226 In addition, channel binding information MAY be included; see 1227 Section 5.5 for discussion. See Figure 12 for parameter 1228 specification. 1230 Cryptosuite: This field indicates the integrity algorithm used for 1231 ERP. Key lengths and output lengths are either indicated or are 1232 obvious from the cryptosuite name. We specify some cryptosuites 1233 below: 1235 * 0 RESERVED 1237 * 1 HMAC-SHA256-64 1239 * 2 HMAC-SHA256-128 1241 * 3 HMAC-SHA256-256 1243 HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled in 1244 the default configuration. 1246 Authentication Tag: This field contains the integrity checksum 1247 over the ERP packet, excluding the authentication tag field 1248 itself. The length of the field is indicated by the Cryptosuite. 1250 5.3.3. EAP-Finish/Re-auth Packet 1252 The EAP-Finish/Re-auth packet contains the parameters shown in 1253 Figure 10. 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Code | Identifier | Length | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Type |R|B|L| Reserved | SEQ ~ 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | 1 or more TVs or TLVs ~ 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | cryptosuite | Authentication Tag ~ 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 Figure 10: EAP-Finish/Re-auth Packet 1269 Type = 2. 1271 Flags 1273 'R' - The R flag is used as the Result flag. When set to 0, it 1274 indicates success, and when set to '1', it indicates a failure. 1276 'B' - The B flag is used as the bootstrapping flag. If the 1277 flag is turned on, the message is a bootstrap message. 1279 'L' - The L flag is used to indicate the presence of the rRK 1280 lifetime TLV. 1282 The remaining 5 bits are set to 0 on transmission and ignored 1283 on reception. 1285 SEQ: A 16-bit sequence number is used for replay protection. The 1286 SEQ number field is initialized to 0 every time a new rRK is 1287 derived. 1289 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1290 and a value with type-specific length. In the TLV payloads, there 1291 is a 1-octet type payload and a 1-octet length payload. The 1292 length field indicates the length of the value expressed in number 1293 of octets. 1295 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1296 The NAI is variable in length, not exceeding 253 octets. 1297 EMSKname is in the username part of the NAI and is encoded in 1298 hexadecimal values. The EMSKname is 64 bits in length and so 1299 the username portion takes up 16 octets. If the rIK is derived 1300 from the EMSK, the realm part of the NAI is the home domain 1301 name, and if the rIK is derived from a DSRK, the realm part of 1302 the NAI is the domain name used in the derivation of the DSRK. 1303 The NAI syntax follows [RFC4282]. Exactly one instance of the 1304 keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth 1305 message. 1307 rRK Lifetime: This is a TV payload. The Type is 2. The value 1308 field is a 32-bit field and contains the lifetime of the rRK in 1309 seconds. If the 'L' flag is set, the rRK Lifetime attribute 1310 SHOULD be present. 1312 rMSK Lifetime: This is a TV payload. The Type is 3. The value 1313 field is a 32-bit field and contains the lifetime of the rMSK 1314 in seconds. If the 'L' flag is set, the rMSK Lifetime 1315 attribute SHOULD be present. 1317 Domain-Name: This is a TLV payload. The Type is 4. The domain 1318 name is to be used as the realm in an NAI [RFC4282]. Domain- 1319 Name attribute MUST be present in an EAP-Finish/Re-auth message 1320 if the bootstrapping flag is set and if the local ER server 1321 sent a DSRK request. 1323 List of cryptosuites: This is a TLV payload. The Type is 5. 1324 The value field contains a list of cryptosuites, each of size 1 1325 octet. The cryptosuite values are as specified in Figure 9. 1326 The server SHOULD include this attribute if the cryptosuite 1327 used in the EAP-Initiate/Re-auth message was not acceptable and 1328 the message is being rejected. The server MAY include this 1329 attribute in other cases. The server MAY use this attribute to 1330 signal to the peer about its cryptographic algorithm 1331 capabilities. 1333 Authorization Indication: This is a TLV payload. The Type is 1334 6. This attribute MAY be included in the EAP-Finish/Re-auth 1335 message when a DSRK is delivered to a local ER server and if 1336 the home EAP server can verify the authorization of the local 1337 ER server to advertise the domain name included in the domain 1338 TLV in the same message. The value field in the TLV contains 1339 an authentication tag computed over the entire packet, starting 1340 from the first bit of the code field to the last bit of the 1341 cryptosuite field, with the value field of the Authorization 1342 Indication TLV filled with all 0s for the computation. The key 1343 used for the computation MUST be derived from the EMSK with key 1344 label "DSRK Delivery Authorized Key@ietf.org" and optional data 1345 containing an ASCII string representing the key management 1346 domain that the DSRK is being derived for. 1348 In addition, channel binding information MAY be included: see 1349 Section 5.5 for discussion. See Figure 12 for parameter 1350 specification. The server sends this information so that the 1351 peer can verify the information seen at the lower layer, if 1352 channel binding is to be supported. 1354 Cryptosuite: This field indicates the integrity algorithm and the 1355 PRF used for ERP. Key lengths and output lengths are either 1356 indicated or are obvious from the cryptosuite name. 1358 Authentication Tag: This field contains the integrity checksum 1359 over the ERP packet, excluding the authentication tag field 1360 itself. The length of the field is indicated by the Cryptosuite. 1362 5.3.4. TV and TLV Attributes 1364 The TV attributes that may be present in the EAP-Initiate or EAP- 1365 Finish messages are of the following format: 1367 0 1 2 3 1368 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 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Type | Value ... 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 Figure 11: TV Attribute Format 1375 The TLV attributes that may be present in the EAP-Initiate or EAP- 1376 Finish messages are of the following format: 1378 0 1 2 3 1379 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 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Type | Length | Value ... 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 Figure 12: TLV Attribute Format 1386 The following Types are defined in this document: 1388 '1' - keyName-NAI: This is a TLV payload. 1390 '2' - rRK Lifetime: This is a TV payload. 1392 '3' - rMSK Lifetime: This is a TV payload. 1394 '4' - domain name: This is a TLV payload. 1396 '5' - cryptosuite list: This is a TLV payload. 1398 '6' - Authorization Indication: This is a TLV payload. 1400 The TLV type range of 128-191 is reserved to carry channel binding 1401 information in the EAP-Initiate and Finish/Re-auth messages. 1402 Below are the current assignments (all of them are TLVs): 1404 '128' - Called-Station-Id [RFC2865] 1406 '129' - Calling-Station-Id [RFC2865] 1407 '130' - NAS-Identifier [RFC2865] 1409 '131' - NAS-IP-Address [RFC2865] 1411 '132' - NAS-IPv6-Address [RFC3162] 1413 The length field indicates the length of the value part of the 1414 attribute in octets. 1416 5.4. Replay Protection 1418 For replay protection, ERP uses sequence numbers. The sequence 1419 number is maintained on a per rIK basis and is initialized to zero in 1420 both directions. In the first EAP-Initiate/Re-auth message, the peer 1421 uses a sequence number value of zero or higher. Note that the when 1422 the sequence number wraps back to zero, the rIK MUST be changed by 1423 running a full EAP authentication. The server expects a sequence 1424 number of zero or higher. When the server receives an EAP-Initiate/ 1425 Re-auth message, it uses the same sequence number in the EAP-Finish/ 1426 Re-auth message. The server then sets the expected sequence number 1427 to the received sequence number plus 1. The server MUST accept 1428 sequence numbers greater than or equal to the expected sequence 1429 number. 1431 If the peer sends an EAP-Initiate/Re-auth message, but does not 1432 receive a response, it retransmits the request (with no changes to 1433 the message itself) a pre-configured number of times before giving 1434 up. However, it is plausible that the server itself may have 1435 responded to the message and the response was lost in transit. Thus, 1436 the peer MUST increment the sequence number and use the new sequence 1437 number to send subsequent EAP re-authentication messages. The peer 1438 SHOULD increment the sequence number by 1; however, it may choose to 1439 increment by a larger number. If the sequence number wraps back to 1440 zero, the peer MUST run full EAP authentication. 1442 5.5. Channel Binding 1444 ERP provides a protected facility to carry channel binding (CB) 1445 information, according to the guidelines provided by Aboba, et al. 1446 (see Section 7.15 of [RFC3748]). The TLV type range of 128-191 is 1447 reserved to carry CB information in the EAP-Initiate/Re-auth and EAP- 1448 Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id, NAS- 1449 Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples of 1450 channel binding information listed in RFC 3748, and they are assigned 1451 values 128-132. Additional values are IANA managed based on IETF 1452 Consensus [RFC5226]. 1454 The authenticator MAY provide CB information to the peer via the EAP- 1455 Initiate/Re-auth-Start message. The peer sends the information to 1456 the server in the EAP-Initiate/Re-auth message; the server verifies 1457 whether the authenticator identity available via AAA attributes is 1458 the same as the identity provided to the peer. 1460 If the peer does not include the CB information in the EAP-Initiate/ 1461 Re-auth message, and if the local ER server's policy requires channel 1462 binding support, it SHALL send the CB attributes for the peer's 1463 verification. The peer attempts to verify the CB information if the 1464 authenticator has sent the CB parameters, and it proceeds with the 1465 lower-layer security association establishment if the attributes 1466 match. Otherwise, the peer SHALL NOT proceed with the lower-layer 1467 security association establishment. 1469 6. Lower-Layer Considerations 1471 The authenticator is responsible for retransmission of EAP-Initiate/ 1472 Re-auth-Start messages. The authenticator MAY retransmit the message 1473 a few times or until it receives an EAP-Initiate/Re-auth message from 1474 the peer. The authenticator might not know if the peer supports ERP; 1475 in those cases, the peer could be silently discarding the EAP- 1476 Initiate/Re-auth-Start packets. Thus, retransmission of these 1477 packets should be kept to a minimum. The exact number is up to each 1478 lower layer. 1480 The Identifier value in the EAP-Initiate/Re-auth packet is 1481 independent of the Identifier value in the EAP-Initiate/Re-auth-Start 1482 packet. 1484 The peer is responsible for retransmission of EAP-Initiate/Re-auth 1485 messages. 1487 Retransmitted packets MUST be sent with the same Identifier value in 1488 order to distinguish them from new packets. By default, where the 1489 EAP-Initiate message is sent over an unreliable lower layer, the 1490 retransmission timer SHOULD be dynamically estimated. A maximum of 1491 3-5 retransmissions is suggested [RFC3748]. Where the EAP-Initiate 1492 message is sent over a reliable lower layer, the retransmission timer 1493 SHOULD be set to an infinite value, so that retransmissions do not 1494 occur at the EAP layer. Please refer to RFC 3748 for additional 1495 guidance on setting timers. 1497 The Identifier value in the EAP-Finish/Re-auth packet is the same as 1498 the Identifier value in the EAP-Initiate/Re-auth packet. 1500 If an authenticator receives a valid duplicate EAP-Initiate/Re-auth 1501 message for which it has already sent an EAP-Finish/Re-auth message, 1502 it MUST resend the EAP-Finish/Re-auth message without reprocessing 1503 the EAP-Initiate/Re-auth message. To facilitate this, the 1504 authenticator SHALL store a copy of the EAP-Finish/Re-auth message 1505 for a finite amount of time. The actual value of time is a local 1506 matter; this specification recommends a value of 100 milliseconds. 1508 The lower layer may provide facilities for exchanging information 1509 between the peer and the authenticator about support for ERP, for the 1510 authenticator to send the domain name information and channel binding 1511 information to the peer 1513 Note that to support ERP, lower-layer specifications may need to be 1514 revised. Specifically, RFC 5996 must be updated to include EAP code 1515 values higher than 4 in order to use ERP with Internet Key Exchange 1516 Protocol version 2 (IKEv2). IKEv2 may also be updated to support 1517 peer-initiated ERP for optimized operation. Other lower layers may 1518 need similar revisions. 1520 Our analysis indicates that some EAP implementations are not RFC 3748 1521 compliant in that instead of silently dropping EAP packets with code 1522 values higher than 4, they may consider it an error. To accommodate 1523 such non-compliant EAP implementations, additional guidance has been 1524 provided below. Furthermore, it may not be easy to upgrade all the 1525 peers in some cases. In such cases, authenticators may be configured 1526 to not send EAP-Initiate/Re-auth-Start; peers may learn whether an 1527 authenticator supports ERP via configuration or from advertisements 1528 at the lower layer. 1530 In order to accommodate implementations that are not compliant to RFC 1531 3748, such lower layers SHOULD ensure that both parties support ERP; 1532 this is trivial for instance when using a lower layer that is known 1533 to always support ERP. For lower layers where ERP support is not 1534 guaranteed, ERP support may be indicated through signaling (e.g., 1535 piggy-backed on a beacon) or through negotiation. Alternatively, 1536 clients may recognize environments where ERP is available based on 1537 pre-configuration. Other similar mechanisms may also be used. When 1538 ERP support cannot be verified, lower layers may mandate falling back 1539 to full EAP authentication to accommodate EAP implementations that 1540 are not compliant to RFC 3748. 1542 7. AAA Transport of ERP Messages 1544 AAA Transport of ERP messages is specified by Hoeper, et al. 1545 [RFC5749] and Bournelle, et al. [I-D.ietf-dime-erp]. 1547 8. Security Considerations 1549 This section provides an analysis of the protocol in accordance with 1550 the AAA key management guidelines described by Housley & Aboba 1551 [RFC4962]. 1553 Cryptographic algorithm independence 1555 The EAP Re-auth Protocol satisfies this requirement. The 1556 algorithm chosen by the peer for the MAC generation is 1557 indicated in the EAP-Initiate/Re-auth message. If the chosen 1558 algorithm is unacceptable, the EAP server returns an EAP- 1559 Finish/Re-auth message with Failure indication. Algorithm 1560 agility for the KDF is specified in Salowey, et al. [RFC5295]. 1561 Only when the algorithms used are deemed acceptable does the 1562 server proceed with the derivation of keys and verification of 1563 the proof of possession of relevant keying material presented 1564 by the peer. A full-blown negotiation of algorithms cannot be 1565 provided in a single round trip protocol. Hence, while the 1566 protocol provides algorithm agility, it does not provide true 1567 negotiation. 1569 Strong, fresh session keys 1571 ERP results in the derivation of strong, fresh keys that are 1572 unique for the given session. An rMSK is always derived on- 1573 demand when the peer requires a key with a new authenticator. 1574 The derivation ensures that the compromise of one rMSK does not 1575 result in the compromise of another rMSK at any time. 1577 Limit key scope 1579 The scope of all the keys derived by ERP is well defined. The 1580 rRK and rIK are never shared with any entity and always remain 1581 on the peer and the server. The rMSK is provided only to the 1582 authenticator through which the peer performs the ERP exchange. 1583 No other authenticator is authorized to use that rMSK. 1585 Replay detection mechanism 1587 For replay protection of ERP messages, a sequence number 1588 associated with the rIK is used. The sequence number is 1589 maintained by the peer and the server, and initialized to zero 1590 when the rIK is generated. The peer increments the sequence 1591 number by one after it sends an ERP message. The server sets 1592 the expected sequence number to the received sequence number 1593 plus one after verifying the validity of the received message 1594 and responds to the message. 1596 Authenticate all parties 1598 The EAP Re-auth Protocol provides mutual authentication of the 1599 peer and the server. Both parties need to possess the keying 1600 material that resulted from a previous EAP exchange in order to 1601 successfully derive the required keys. Also, both the EAP re- 1602 authentication Response and the EAP re-authentication 1603 Information messages are integrity protected so that the peer 1604 and the server can verify each other. When the ERP exchange is 1605 executed with a local ER server, the peer and the local server 1606 mutually authenticate each other via that exchange in the same 1607 manner. The peer and the authenticator authenticate each other 1608 in the secure association protocol executed by the lower layer, 1609 just as in the case of a regular EAP exchange. 1611 Peer and authenticator authorization 1613 The peer and authenticator demonstrate possession of the same 1614 key material without disclosing it, as part of the lower-layer 1615 secure association protocol. Channel binding with ERP may be 1616 used to verify consistency of the identities exchanged, when 1617 the identities used in the lower layer differ from that 1618 exchanged within the AAA protocol. 1620 Keying material confidentiality 1622 The peer and the server derive the keys independently using 1623 parameters known to each entity. The AAA server sends the DSRK 1624 of a domain to the corresponding local ER server via the AAA 1625 protocol. Likewise, the ER server sends the rMSK to the 1626 authenticator via the AAA protocol. 1628 Note that compromise of the DSRK results in compromise of all 1629 keys derived from it. Moreover, there is no forward secrecy 1630 within ERP. Thus, compromise of an DSRK retroactively 1631 compromises all ERP keys. 1633 It is RECOMMENDED that the AAA protocol be protected using 1634 IPsec or TLS so that the keys are protected in transit. Note, 1635 however, that keys may be exposed to AAA proxies along the way 1636 and compromise of any of those proxies may result in compromise 1637 of keys being transported through them. 1639 The home EAP server MUST NOT hand out a given DSRK to a local 1640 domain server more than once, unless it can verify that the 1641 entity receiving the DSRK after the first time is the same as 1642 that received the DSRK originally. If the home EAP server 1643 verifies authorization of a local domain server, it MAY hand 1644 out the DSRK to that domain more than once. In this case, the 1645 home EAP server includes the Authorization Indication TLV to 1646 assure the peer that DSRK delivery is secure. 1648 Confirm cryptosuite selection 1650 Crypto algorithms for integrity and key derivation in the 1651 context of ERP MAY be the same as that used by the EAP method. 1652 In that case, the EAP method is responsible for confirming the 1653 cryptosuite selection. Furthermore, the cryptosuite is 1654 included in the ERP exchange by the peer and confirmed by the 1655 server. The protocol allows the server to reject the 1656 cryptosuite selected by the peer and provide alternatives. 1657 When a suitable rIK is not available for the peer, the 1658 alternatives may be sent in an unprotected fashion. The peer 1659 is allowed to retry the exchange using one of the allowed 1660 cryptosuites. However, in this case, any en route 1661 modifications to the list sent by the server will go 1662 undetected. If the server does have an rIK available for the 1663 peer, the list will be provided in a protected manner and this 1664 issue does not apply. 1666 Uniquely named keys 1668 All keys produced within the ERP context can be referred to 1669 uniquely as specified in this document. Also, the key names do 1670 not reveal any part of the keying material. 1672 Prevent the domino effect 1674 The compromise of one peer does not result in the compromise of 1675 keying material held by any other peer in the system. Also, 1676 the rMSK is meant for a single authenticator and is not shared 1677 with any other authenticator. Hence, the compromise of one 1678 authenticator does not lead to the compromise of sessions or 1679 keys held by any other authenticator in the system. Hence, the 1680 EAP Re-auth Protocol allows prevention of the domino effect by 1681 appropriately defining key scope. 1683 However, if keys are transported using hop-by-hop protection, 1684 compromise of a proxy may result in compromise of key material, 1685 e.g., the DSRK being sent to a local ER server. 1687 Bind key to its context 1689 All the keys derived for ERP are bound to the appropriate 1690 context using appropriate key labels. Lifetime of a child key 1691 is less than or equal to that of its parent key as specified in 1692 RFC 4962 [RFC4962]. The key usage, lifetime and the parties 1693 that have access to the keys are specified. 1695 Confidentiality of identity 1697 Deployments where privacy is a concern may find the use of 1698 rIKname-NAI to route ERP messages serves their privacy 1699 requirements. Note that it is plausible to associate multiple 1700 runs of ERP messages since the rIKname is not changed as part 1701 of the ERP protocol. There was no consensus for that 1702 requirement at the time of development of this specification. 1703 If the rIKname is not used and the Peer-ID is used instead, the 1704 ERP exchange will reveal the Peer-ID over the wire. 1706 Authorization restriction 1708 All the keys derived are limited in lifetime by that of the 1709 parent key or by server policy. Any domain-specific keys are 1710 further restricted for use only in the domain for which the 1711 keys are derived. All the keys specified in this document are 1712 meant for use in ERP only. Other restrictions on the use of 1713 session keys may be imposed by the specific lower layer but are 1714 out of scope for this specification. 1716 Prevent DoS attack 1718 A denial-of-service (DoS) attack on the peer may be possible 1719 when using the EAP Initiate/Re-auth message. An attacker may 1720 send a bogus EAP-Initiate/Re-auth message, which may be carried 1721 by the authenticator in a AAA request to the server; in 1722 response, the server may send an EAP-Finish/Re-auth with 1723 Failure indication in a AAA reply. Note that such attacks may 1724 be possible with the EAPoL-Start capability of IEEE 802.11 and 1725 other similar facilities in other link layers and where the 1726 peer can initiate EAP authentication. An attacker may use such 1727 messages to start an EAP method run, which fails and may result 1728 in the server sending a rejection message, thus resulting in 1729 the link-layer connections being terminated. 1731 To prevent such DoS attacks, an ERP failure should not result 1732 in deletion of any authorization state established by a full 1733 EAP exchange. Alternatively, the lower layers and AAA 1734 protocols may define mechanisms to allow two link-layer 1735 security associations (SAs) derived from different EAP keying 1736 materials for the same peer to exist so that smooth migration 1737 from the current link layer SA to the new one is possible 1738 during rekey. These mechanisms prevent the link layer 1739 connections from being terminated when a re-authentication 1740 procedure fails due to a bogus EAP-Initiate/Re-auth message. 1742 Keying materials Transport 1744 When a DSRK is sent from the home EAP server to a local domain 1745 server or when a rMSK is sent from an ER server to an 1746 authenticator, in the absence of end-to-end security between 1747 the entity that is sending the key and the entity receiving the 1748 key, it is plausible for other entities to get access to keys 1749 being sent to an ER server in another domain. This mode of key 1750 transport is similar to that of MSK transport in the context of 1751 EAP authentication. We further observe that ERP is for access 1752 authentication and does not support end-to-end data security. 1753 In typical implementations, the traffic is in the clear beyond 1754 the access control enforcement point (the authenticator or an 1755 entity delegated by the authenticator for access control 1756 enforcement). The model works as long as entities in the 1757 middle of the network do not use keys intended for other 1758 parties to steal service from an access network. If that is 1759 not achievable, key delivery must be protected in an end-to-end 1760 manner. 1762 9. IANA Considerations 1764 This document has no IANA actions. 1766 10. References 1768 10.1. Normative References 1770 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1771 Hashing for Message Authentication", RFC 2104, 1772 February 1997. 1774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1775 Requirement Levels", BCP 14, RFC 2119, March 1997. 1777 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1778 Levkowetz, "Extensible Authentication Protocol (EAP)", 1779 RFC 3748, June 2004. 1781 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1782 Network Access Identifier", RFC 4282, December 2005. 1784 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 1785 "Specification for the Derivation of Root Keys from an 1786 Extended Master Session Key (EMSK)", RFC 5295, 1787 August 2008. 1789 10.2. Informative References 1791 [I-D.ietf-dime-erp] 1792 Bournelle, J., Morand, L., Decugis, S., Wu, W., and G. 1793 Zorn, "Diameter support for EAP Re-authentication Protocol 1794 (ERP)", draft-ietf-dime-erp-07 (work in progress), 1795 September 2011. 1797 [I-D.ietf-hokey-ldn-discovery] 1798 Zorn, G., Wu, W., and Y. Wang, "The ERP Local Domain Name 1799 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-10 (work in 1800 progress), April 2011. 1802 [I-D.nir-ipsecme-erx] 1803 Nir, Y. and W. Wu, "An IKEv2 Extension for Supporting 1804 ERP", draft-nir-ipsecme-erx-01 (work in progress), 1805 July 2011. 1807 [IEEE_802.1X] 1808 Institute of Electrical and Electronics Engineers, "IEEE 1809 Standards for Local and Metropolitan Area Networks: Port 1810 based Network Access Control, IEEE Std 802.1X-2004", 1811 December 2004. 1813 [MSKHierarchy] 1814 Lopez, R., Skarmeta, A., Bournelle, J., Laurent- 1815 Maknavicus, M., and J. Combes, "Improved EAP keying 1816 framework for a secure mobility access service", 1817 IWCMC '06, Proceedings of the 2006 International 1818 Conference on Wireless Communications and 1819 Mobile Computing, New York, NY, USA, 2006. 1821 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1822 "Remote Authentication Dial In User Service (RADIUS)", 1823 RFC 2865, June 2000. 1825 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1826 RFC 3162, August 2001. 1828 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1829 Protocol Method for 3rd Generation Authentication and Key 1830 Agreement (EAP-AKA)", RFC 4187, January 2006. 1832 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1833 Authorization, and Accounting (AAA) Key Management", 1834 BCP 132, RFC 4962, July 2007. 1836 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 1837 "Handover Key Management and Re-Authentication Problem 1838 Statement", RFC 5169, March 2008. 1840 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1841 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1842 May 2008. 1844 [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of 1845 EAP-Based Keys for Handover and Re-Authentication", 1846 RFC 5749, March 2010. 1848 [RFC5996] Kaufman, C., Hoffman , P., Nir, Y., and P. Eronen, 1849 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1850 RFC 5996, September 2010. 1852 Appendix A. Acknowledgments 1854 A.1. RFC 5296 1856 In writing this document, we benefited from discussing the problem 1857 space and the protocol itself with a number of folks including 1858 Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, 1859 Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, 1860 Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi 1861 Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of 1862 the HOKEY working group. The credit for the idea to use EAP- 1863 Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- 1864 layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin 1865 Hoeper suggested the use of the windowing technique to handle 1866 multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for 1867 the suggestion to use hexadecimal encoding for rIKname when sent as 1868 part of keyName-NAI field. Thanks to Bernard Aboba for suggestions 1869 in clarifying the EAP lock-step operation, and Joe Salowey and Glen 1870 Zorn for help in specifying AAA transport of ERP messages. Thanks to 1871 Sam Hartman for the DSRK Authorization Indication mechanism. 1873 A.2. RFC 5296bis 1875 Thanks to Yaron Sheffer and Yoav Nir for useful comments. 1877 Appendix B. Sample ERP Exchange 1878 0. Authenticator --> Peer: 1879 EAP-Initiate/Re-auth-Start [Optional] 1881 1. Peer --> Authenticator: 1882 EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, 1883 Auth-tag*) 1885 1a. Authenticator --> Re-auth-Server: 1886 AAA-Request 1887 { 1888 Authenticator-Id, 1889 EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, 1890 Auth-tag*) 1891 } 1893 2. ER-Server --> Authenticator: 1894 AAA-Response 1895 { 1896 rMSK, 1897 EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], 1898 Auth-tag*) 1899 } 1901 2b. Authenticator --> Peer: 1902 EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], 1903 Auth-tag*) 1905 * Auth-tag computation is over the entire EAP Initiate/Finish message; 1906 the code values for Initiate and Finish are different and thus 1907 reflection attacks are mitigated. 1909 Authors' Addresses 1911 Qin Wu (editor) 1912 Huawei Technologies Co., Ltd. 1913 101 Software Avenue, Yuhua District 1914 Nanjing, JiangSu 210012 1915 China 1917 Email: Sunseawq@huawei.com 1918 Zhen Cao 1919 China Mobile 1920 53A Xibianmennei Ave., Xuanwu District 1921 Beijing, Beijing 100053 1922 P.R. China 1924 Email: caozhen@chinamobile.com 1926 Glen Zorn (editor) 1927 Network Zen 1928 227/358 Thanon Sanphawut 1929 Bang Na, Bangkok 10260 1930 Thailand 1932 Phone: +66 (0) 87-0404617 1933 Email: glenzorn@gmail.com 1935 Yang Shi 1936 H3C Tech. Co., Ltd 1937 Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District 1938 Beijing 100085 1939 China 1941 Email: young@h3c.com 1943 Baohong He 1944 China 1946 Email: hebaohong@catr.cn