idnits 2.17.1 draft-ietf-hokey-rfc5296bis-07.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 (May 17, 2012) is 4361 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 299, but not defined == Missing Reference: 'Optional' is mentioned on line 1948, but not defined == Missing Reference: 'CB-Info' is mentioned on line 1971, 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-09 == Outdated reference: A later version (-11) exists of draft-nir-ipsecme-erx-03 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Cao 3 Internet-Draft China Mobile 4 Obsoletes: 5296 (if approved) B. He 5 Intended status: Standards Track CATR 6 Expires: November 18, 2012 Y. Shi 7 Q. Wu, Ed. 8 Huawei 9 G. Zorn, Ed. 10 Network Zen 11 May 17, 2012 13 EAP Extensions for EAP Re-authentication Protocol (ERP) 14 draft-ietf-hokey-rfc5296bis-07 16 Abstract 18 The Extensible Authentication Protocol (EAP) is a generic framework 19 supporting multiple types of authentication methods. In systems 20 where EAP is used for authentication, it is desirable to avoid 21 repeating the entire EAP exchange with another authenticator. This 22 document specifies extensions to EAP and the EAP keying hierarchy to 23 support an EAP method-independent protocol for efficient re- 24 authentication between the peer and an EAP re-authentication server 25 through any authenticator. The re-authentication server may be in 26 the home network or in the local network to which the peer is 27 connecting. 29 This memo obsoletes RFC 5296. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 18, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Changes from RFC 5296 . . . . . . . . . . . . . . . . . . 5 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 10 69 3.2. ERP With a Local ER Server . . . . . . . . . . . . . . . . 11 70 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 13 71 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 72 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 15 73 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 15 74 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 16 75 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 17 77 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 17 78 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 18 79 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 18 80 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 21 81 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 23 82 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 24 83 5.3. EAP Codes . . . . . . . . . . . . . . . . . . . . . . . . 25 84 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 26 85 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 27 86 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 27 87 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 27 88 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 29 89 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 32 90 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 33 91 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33 92 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 34 93 7. AAA Transport of ERP Messages . . . . . . . . . . . . . . . . 35 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 96 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 99 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 100 12.2. Informative References . . . . . . . . . . . . . . . . . . 42 101 Appendix A. RFC 5296 Acknowledgments . . . . . . . . . . . . . . 43 102 Appendix B. Sample ERP Exchange . . . . . . . . . . . . . . . . . 43 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 105 1. Introduction 107 The Extensible Authentication Protocol (EAP) is a an authentication 108 framework that supports multiple authentication methods. The primary 109 purpose is network access authentication, and a key-generating method 110 is used when the lower layer wants to enforce access control. The 111 EAP keying hierarchy defines two keys to be derived by all key- 112 generating EAP methods: the Master Session Key (MSK) and the Extended 113 MSK (EMSK). In the most common deployment scenario, an EAP peer and 114 an EAP server authenticate each other through a third party known as 115 the EAP authenticator. The EAP authenticator or an entity controlled 116 by the EAP authenticator enforces access control. After successful 117 authentication, the EAP server transports the MSK to the EAP 118 authenticator; the EAP authenticator and the EAP peer establish 119 transient session keys (TSKs) using the MSK as the authentication 120 key, key derivation key, or a key transport key, and use the TSK for 121 per-packet access enforcement. 123 When a peer moves from one authenticator to another, it is desirable 124 to avoid a full EAP authentication to support fast handovers. The 125 full EAP exchange with another run of the EAP method can take several 126 round trips and significant time to complete, causing increased 127 handover times. Some EAP methods specify the use of state from the 128 initial authentication to optimize re-authentications by reducing the 129 computational overhead (e.g., EAP-AKA [RFC4187]), but method-specific 130 re-authentication takes at least 2 round trips with the original EAP 131 server in most cases. It is also important to note that several 132 methods do not offer support for re-authentication. 134 Key sharing across authenticators is sometimes used as a practical 135 solution to lower handover times. In that case, however, the 136 compromise of one authenticator results in the compromise of keying 137 material established via other authenticators. Other solutions for 138 fast re-authentication exist in the literature: for example, see 139 Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP 140 re-authentication problem statement in detail [RFC5169]. 142 In conclusion, to achieve low latency handovers, there is a need for 143 a method-independent re-authentication protocol that completes in 144 less than 2 round trips, preferably with a local server. 146 This document specifies EAP Re-authentication Extensions (ERXs) for 147 efficient re-authentication using EAP. The protocol that uses these 148 extensions is itself referred to as the EAP Re-authentication 149 Protocol (ERP). It supports EAP method-independent re-authentication 150 for a peer that has valid, unexpired key material from a previously 151 performed EAP authentication. The protocol and the key hierarchy 152 required for EAP re-authentication are described in this document. 154 Note that to support ERP, lower-layer specifications may need to be 155 revised to allow carrying EAP messages that have a code value higher 156 than 4 and to accommodate the peer-initiated nature of ERP. 157 Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must 158 be updated to carry ERP messages; work is in progress on this project 159 [I-D.nir-ipsecme-erx]. 161 1.1. Changes from RFC 5296 163 This document obsoletes RFC 5296 but is fully backward compatible 164 with that document. The changes introduced in this document focus on 165 fixing issues that have surfaced since the publication of the 166 original ERP specification [RFC5296]. An overview of some the major 167 changes is given below. 169 o Co-location of the home ER and EAP servers is no longer required 170 (see the "ER Server entry in Section 2). 172 o The behavior of the authenticator and local ER server during the 173 bootstrapping process has been clarified (Section 5.1); in 174 particular, the authenticator and/or local ER server is now 175 required to check for current possesion of the root keys. 177 o The authenticator is now recommended, rather than just allowed, to 178 initiate the ERP conversation by means of the EAP-Initiate/ 179 Re-auth-Start message (Section 5.3.1.1). 181 In addition, many editorial changes have been made to improve the 182 clarity of the document and to eliminate perceived abmbiguities. A 183 comprehensive list of changes is not given here for practical 184 reasons. 186 2. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 This document uses the basic EAP terminology [RFC3748] and EMSK 193 keying hierarchy terminology [RFC5295]. In addition, this document 194 uses the following terms: 196 ER Peer - An EAP peer that supports the EAP Re-authentication 197 Protocol. All references to "peer" in this document imply an ER 198 peer, unless specifically noted otherwise. 200 ER Authenticator - An entity that supports the authenticator 201 functionality for EAP re-authentication described in this 202 document. All references to "authenticator" in this document 203 imply an ER authenticator, unless specifically noted otherwise. 205 ER Server - An entity that performs the server portion of ERP 206 described here. This entity may or may not be an EAP server. All 207 references to "server" in this document imply an ER server, unless 208 specifically noted otherwise. An ER server is a logical entity; 209 it may not necessarily be co-located with, or physically part of, 210 a full EAP server. 212 ERX - EAP re-authentication extensions. 214 ERP - EAP Re-authentication Protocol that uses the re- 215 authentication extensions. 217 rRK - re-authentication Root Key, derived from the EMSK or DSRK. 219 rIK - re-authentication Integrity Key, derived from the rRK. 221 rMSK - re-authentication MSK. This is a per-authenticator key, 222 derived from the rRK. 224 keyName-NAI - ERP messages are integrity protected with the rIK or 225 the DS-rIK. The use of rIK or DS-rIK for integrity protection of 226 ERP messages is indicated by the EMSKname [RFC5295]; the protocol, 227 which is ERP; and the realm, which indicates the domain name of 228 the ER server. The EMSKname is copied into the username part of 229 the NAI. 231 Domain - Refers to a "key management domain" as defined in 232 [RFC5295]. For simplicity, it is referred to as "domain" in this 233 document. The terms "home domain" and "local domain" are used to 234 differentiate between the originating key management domain that 235 performs the full EAP exchange with the peer and the local domain 236 to which a peer may be attached at a given time. 238 3. ERP Description 240 ERP allows a peer and server to mutually verify proof of possession 241 of keying material from an earlier EAP method run and to establish a 242 security association between the peer and the authenticator. The 243 authenticator acts as a pass-through entity for the Re-authentication 244 Protocol in a manner similar to that of an EAP authenticator 245 described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange 246 between the peer and the server; it is independent of the lower layer 247 and the EAP method used during the full EAP exchange. The ER server 248 may be in the home domain or in the same (visited) domain as the peer 249 and the authenticator (i.e., the local domain). 251 Figure 2 shows the protocol exchange. The first time the peer 252 attaches to any network, it performs a full EAP exchange (shown in 253 Figure 1) with the EAP server; as a result, an MSK is distributed to 254 the EAP authenticator. The MSK is then used by the authenticator and 255 the peer to establish TSKs as needed. At the time of the initial EAP 256 exchange, the peer and the server also derive an EMSK, which is used 257 to derive a re-authentication Root Key (rRK). More precisely, a re- 258 authentication Root Key is derived from the EMSK or from a Domain- 259 Specific Root Key (DSRK), which is itself derived from the EMSK. The 260 rRK is only available to the peer and the ER server and is never 261 handed out to any other entity. Further, a re-authentication 262 Integrity Key (rIK) is derived from the rRK; the peer and the ER 263 server use the rIK to provide proof of possession while performing an 264 ERP exchange. The rIK is also never handed out to any entity and is 265 only available to the peer and server. 267 EAP Peer EAP Authenticator EAP Server 268 ======== ================= ========== 270 <--- EAP-Request/ ------ 271 Identity 273 ----- EAP Response/ ---> 274 Identity ---AAA(EAP Response/Identity)--> 276 <--- EAP Method -------> <------ AAA(EAP Method --------> 277 exchange exchange) 279 <----AAA(MSK, EAP-Success)------ 281 <---EAP-Success--------- 283 Figure 1: EAP Authentication 285 Peer ER Authenticator ER Server 286 ==== ============= ====== 288 <-- EAP-Initiate/ ----- 289 Re-auth-Start 290 [<-- EAP-Request/ ------ 291 Identity] 293 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 294 Re-auth/ Re-auth/ 295 [Bootstrap] [Bootstrap]) 297 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 298 Re-auth/ Re-auth/ 299 [Bootstrap] [Bootstrap]) 301 Note: [] brackets indicate optionality. 303 Figure 2: ERP Exchange 305 Two EAP codes, EAP-Initiate and EAP-Finish, are specified in this 306 document for the purpose of EAP re-authentication. When the peer 307 identifies a target authenticator that supports EAP re- 308 authentication, it performs an ERP exchange, as shown in Figure 2; 309 the exchange itself may happen when the peer attaches to a new 310 authenticator supporting EAP re-authentication, or prior to 311 attachment. The peer initiates ERP by itself; it may also do so in 312 response to an EAP-Initiate/Re-auth-Start message from the new 313 authenticator. The EAP-Initiate/Re-auth-Start message allows the 314 authenticator to trigger the ERP exchange. The EAP-Finish message 315 also can be used by the authenticator to announce the local domain 316 name. 318 It is plausible that the authenticator does not know whether the peer 319 supports ERP and whether the peer has performed a full EAP 320 authentication through another authenticator. The authenticator MAY 321 initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start 322 message, and if there is no response, send the EAP-Request/Identity 323 message. Note that this avoids having two EAP messages in flight at 324 the same time [RFC3748]. The authenticator may send the EAP- 325 Initiate/Re-auth-Start message and wait for a short, locally 326 configured amount of time. This message indicates to the peer that 327 the authenticator supports ERP. In response to this trigger from the 328 authenticator, the peer can initiate the ERP exchange by sending an 329 EAP-Initiate/Re-auth message. If there is no response from the peer 330 after the necessary number of retransmissions (see Section 6), the 331 authenticator MUST initiate EAP by sending an EAP-Request message, 332 typically the EAP-Request/Identity message. Note that the 333 authenticator may receive an EAP-Initiate/Re-auth message after it 334 has sent an EAP-Request/Identity message. If the authenticator 335 supports ERP, it MUST proceed with the ERP exchange. When the EAP- 336 Request/Identity times out, the authenticator MUST NOT close the 337 connection if an ERP exchange is in progress or has already succeeded 338 in establishing a re-authentication MSK. 340 If the authenticator does not support ERP, it will silently discard 341 EAP-Initiate/Re-auth messages (Section 5.3.2) since the EAP code of 342 those packets is greater than 4 ([RFC3748], Section 4). An ERP- 343 capable peer will exhaust the EAP-Initiate/Re-auth message 344 retransmissions and fall back to EAP authentication by responding to 345 EAP Request/Identity messages from the authenticator. If the peer 346 does not support ERP or if it does not have unexpired key material 347 from a previous EAP authentication, it drops EAP-Initiate/ 348 Re-auth-Start messages. If there is no response to the EAP-Initiate/ 349 Re-auth-Start message, the authenticator SHALL send an EAP Request 350 message (typically EAP Request/Identity) to start EAP authentication. 351 From this point onward, RFC 3748 rules apply. Note that this may 352 introduce some delay in starting EAP. In some lower layers, the 353 delay can be minimized or even avoided by the peer initiating EAP by 354 sending messages such as EAPoL-Start [IEEE_802.1X]. 356 The peer sends an EAP-Initiate/Re-auth message that contains the 357 keyName-NAI to identify the ER server's domain and the rIK used to 358 protect the message, and a sequence number for replay protection. 359 The EAP-Initiate/Re-auth message is integrity protected with the rIK. 360 The authenticator uses the realm in the keyName-NAI [RFC4282] field 361 to send the message to the appropriate ER server. The server uses 362 the keyName to look up the rIK. The server, after verifying proof of 363 possession of the rIK, and freshness of the message, derives a re- 364 authentication MSK (rMSK) from the rRK using the sequence number as 365 an input to the key derivation. The server then updates the expected 366 sequence number to the received sequence number plus one. 368 In response to the EAP-Initiate/Re-auth message, the server sends an 369 EAP-Finish/Re-auth message; this message is integrity protected with 370 the rIK. The server transports the rMSK along with this message to 371 the authenticator. The rMSK is transported in a manner similar to 372 that of the MSK along with the EAP-Success message in a full EAP 373 exchange. Hoeper, et al. [RFC5749] discuss an additional key 374 distribution protocol that can be used to transport the rRK from an 375 EAP server to one of many different ER servers that share a trust 376 relationship with the EAP server. 378 The peer MAY request the rMSK lifetime from the server. If so, the 379 ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message. 381 In an ERP bootstrap exchange, the peer MAY ask the server for the rRK 382 lifetime. If so, the ER server sends the rRK lifetime in the EAP- 383 Finish/Re-auth message. 385 The peer verifies the sequence number and the integrity of the 386 message. It then uses the sequence number in the EAP-Finish/Re-auth 387 message to compute the rMSK. The lower-layer security association 388 protocol is ready to be triggered after this point. 390 The ER server is located either in the home domain or in the visited 391 domain. When the ER server is in the home domain and there is no 392 local ER server in the visited domain, the peer and the server use 393 the rIK and rRK derived from the EMSK; and when the ER server is in 394 the local domain, they use the DS-rIK and DS-rRK corresponding to the 395 local domain. The domain of the ER server is identified by the realm 396 portion of the keyname-NAI in ERP messages. 398 3.1. ERP With the Home ER Server 400 If the peer is in the home domain or there is no local server in the 401 same domain as the peer, it SHOULD initiate an ERP bootstrap exchange 402 with the home ER server to obtain the domain name. 404 The defined ER extensions allow executing the ERP with an ER server 405 in the home domain. The home ER server may be co-located with a home 406 AAA server. ERP with the Home ER Server is similar to the ERP 407 exchange described in Figure 2. 409 Peer ER Authenticator Home ER Server 410 ==== ============= ====== 412 <-- EAP-Initiate/ ----- 413 Re-auth-Start 414 [<-- EAP-Request/ ------ 415 Identity] 417 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 418 Re-auth/ Re-auth/ 419 Bootstrap Bootstrap) 421 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 422 Re-auth/ Re-auth/ 423 Bootstrap Bootstrap) 425 Figure 3: ER Explicit Bootstrapping Exchange/ERP with the Home ER 426 Sever 428 3.2. ERP With a Local ER Server 430 The defined ER extensions allow the execution of ERP with an ER 431 server in the local domain (access network) if the peer moves out of 432 the home domain and a local ER server is present in the visited 433 domain. The local ER server may be co-located with a local AAA 434 server. The peer may learn about the presence of a local ER server 435 in the network and the local domain name (or ER server name) either 436 via a lower layer advertisement or by means of an ERP exchange. The 437 peer uses the domain name and the EMSK to compute the DSRK and from 438 that key, the DS-rRK; the peer also uses the domain name in the realm 439 portion of the keyName-NAI for using ERP in the local domain. 440 Figure 4 shows the ER Implicit bootstrapping exchange through local 441 ER Server;Figure 5shows ERP with a local ER server. 443 Peer EAP Authenticator Local AAA Agent Home EAP Server 444 /ER Authenticator /Local ER Server 445 ==== ================= =============== =============== 447 <-- EAP-Request/ -- 448 Identity 450 -- EAP Response/--> 451 Identity --AAA(EAP Response/--> 452 Identity, --AAA(EAP Response/ --> 453 [domain name]) Identity, 454 [DSRK Request, 455 domain name]) 457 <------------------------ EAP Method exchange------------------> 459 <---AAA(MSK, DSRK, ---- 460 EMSKname, 461 EAP-Success) 463 <--- AAA(MSK, ----- 464 EAP-Success) 466 <---EAP-Success----- 468 Figure 4: Implicit Bootstrapping ERP Exchange, Initial EAP Exchange 470 Peer ER Authenticator Local ER Server 471 ==== ================ =============== 473 <-- EAP-Initiate/ -------- 474 Re-auth-Start 475 [<-- EAP-Request/ --------- 476 Identity] 478 ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> 479 Re-auth Re-auth) 481 <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- 482 Re-auth Re-auth) 483 Figure 5: Local ERP Exchange 485 As shown in Figure 4, the local ER server may be present in the path 486 of the full EAP exchange (e.g., this may be one of the AAA entities, 487 such as AAA proxies, in the path between the EAP authenticator and 488 the home EAP server of the peer). In that case, the local ER server 489 requests the DSRK by sending the domain name to the home EAP server 490 by means of an AAA message. In response, the home EAP server 491 computes the DSRK by following the procedure specified in [RFC5295] 492 and sends the DSRK and the key name, EMSKname, to the ER server in 493 the claimed domain (i.e., the local ER Server). The local domain is 494 responsible for announcing that same domain name to the peer via a 495 lower layer (for example, through DHCP-based local domain name 496 discovery [RFC6440], or through the EAP-Initiate/Re-auth-Start 497 message with the local ER server. 499 After receiving the DSRK and the EMSKname, the local ER server 500 computes the DS-rRK and the DS-rIK from the DSRK as defined in 501 Sections 4.1 and 4.3 below. After receiving the domain name, the 502 peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys 503 are referred to by a keyName-NAI formed as follows: the username part 504 of the NAI is the EMSKname, the realm portion of the NAI is the 505 domain name. Both parties also maintain a sequence number 506 (initialized to zero) corresponding to the specific keyName-NAI. 508 If the peer subsequently attaches to an authenticator within the 509 local domain, it may perform an ERP exchange with the local ER server 510 to obtain a rMSK for the new authenticator. The ERP with the local 511 ER Server is similar to the ERP exchange illustrated in Figure 2. 513 4. ER Key Hierarchy 515 Each time the peer re-authenticates to the network, the peer and the 516 authenticator establish an rMSK. The rMSK serves the same purposes 517 that an MSK, which is the result of full EAP authentication, serves. 518 To prove possession of the rRK, we specify the derivation of another 519 key, the rIK. These keys are derived from the rRK. Together they 520 constitute the ER key hierarchy. 522 The rRK is derived from either the EMSK or a DSRK as specified in 523 Section 4.1. For the purpose of rRK derivation, this document 524 specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- 525 Specific USRK (DSUSRK) [RFC5295] for re-authentication. The USRK 526 designated for re-authentication is the re-authentication root key 527 (rRK). A DSUSRK designated for re-authentication is the DS-rRK 528 available to a local ER server in a particular domain. For 529 simplicity, the keys are referred to without the DS label in the rest 530 of the document. However, the scope of the various keys is limited 531 to just the respective domains for which they are derived, in the 532 case of the domain specific keys. Based on the ER server with which 533 the peer performs the ERP exchange, it knows the corresponding keys 534 that must be used. 536 The rRK is used to derive an rIK, and rMSKs for one or more 537 authenticators. The figure below shows the key hierarchy with the 538 rRK, rIK, and rMSKs. 540 rRK 541 | 542 +--------+--------+ 543 | | | 544 rIK rMSK1 ...rMSKn 546 Figure 6: Re-authentication Key Hierarchy 548 The derivations in this document are from RFC 5295. Key derivations 549 and field encodings, where unspecified, default to that document. 551 4.1. rRK Derivation 553 The rRK may be derived from the EMSK or DSRK. This section provides 554 the relevant key derivations for that purpose. 556 The rRK is derived as specified in RFC 5295. 558 rRK = KDF (K, S), where 560 K = EMSK or K = DSRK and 562 S = rRK Label | "\0" | length 564 The rRK Label is an IANA-assigned 8-bit ASCII string: 566 EAP Re-authentication Root Key@ietf.org 568 assigned from the "USRK key labels" name space in accordance with the 569 policy stated in RFC 5295. 571 The KDF and algorithm agility for the KDF are as defined in RFC 5295. 573 An rRK derived from the DSRK is referred to as a DS-rRK in the rest 574 of the document. All the key derivation and properties specified in 575 this section remain the same. 577 4.2. rRK Properties 579 The rRK has the following properties. These properties apply to the 580 rRK regardless of the parent key used to derive it. 582 o The length of the rRK MUST be equal to the length of the parent 583 key used to derive it. 585 o The rRK is to be used only as a root key for re-authentication and 586 never used to directly protect any data. 588 o The rRK is only used for the derivation of the rIK and rMSK as 589 specified in this document. 591 o The rRK MUST remain on the peer and the server that derived it and 592 MUST NOT be transported to any other entity. 594 o The lifetime of the rRK is never greater than that of its parent 595 key. The rRK is expired when the parent key expires and MUST be 596 removed from use at that time. 598 4.3. rIK Derivation 600 The re-authentication Integrity Key (rIK) is used for integrity 601 protecting the ERP exchange. This serves as the proof of possession 602 of valid keying material from a previous full EAP exchange by the 603 peer to the server. 605 The rIK is derived as follows. 607 rIK = KDF (K, S), where 609 K = rRK and 611 S = rIK Label | "\0" | cryptosuite | length 613 The rIK Label is the 8-bit ASCII string: 615 Re-authentication Integrity Key@ietf.org 617 The length field refers to the length of the rIK in octets encoded as 618 specified in RFC 5295. 620 The cryptosuite and length of the rIK are part of the input to the 621 key derivation function to ensure cryptographic separation of keys if 622 different rIKs of different lengths (for example, for use with 623 different Message Authentication Code (MAC) algorithms) are derived 624 from the same rRK. The cryptosuite is encoded as an 8-bit number; 625 see Section 5.3.2 for the cryptosuite specification. 627 The rIK is referred to by the EMSKname-NAI within the context of ERP 628 messages. The username part of EMSKname-NAI is the EMSKname; the 629 realm is the domain name of the ER server. In case of ERP with the 630 home ER server, the peer uses the realm from its original NAI; in 631 case of a local ER server, the peer uses the domain name received at 632 the lower layer or through an ERP bootstrapping exchange. 634 A rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of 635 the document. All of the key derivation and properties specified in 636 this section remain the same. 638 4.4. rIK Properties 640 The rIK has the following properties. 642 o The length of the rIK MUST be equal to the length of the rRK. 644 o The rIK is only used for authentication of the ERP exchange as 645 specified in this document. 647 o The rIK MUST NOT be used to derive any other keys. 649 o The rIK must remain on the peer and the server and MUST NOT be 650 transported to any other entity. 652 o The rIK is cryptographically separate from any other keys derived 653 from the rRK. 655 o The lifetime of the rIK is never greater than that of its parent 656 key. The rIK MUST be expired when the EMSK expires and MUST be 657 removed from use at that time. 659 4.5. rIK Usage 661 The rIK is the key the possession of which is demonstrated by the 662 peer and the ERP server to the other party. The peer demonstrates 663 possession of the rIK by computing the integrity checksum over the 664 EAP-Initiate/Re-auth message. When the peer uses the rIK for the 665 first time, it can choose the integrity algorithm to use with the 666 rIK. The peer and the server MUST use the same integrity algorithm 667 with a given rIK for all ERP messages protected with that key. The 668 peer and the server store the algorithm information after the first 669 use, and they employ the same algorithm for all subsequent uses of 670 that rIK. 672 If the server's policy does not allow the use of the cryptosuite 673 selected by the peer, the server SHALL reject the EAP-Initiate/ 674 Re-auth message and SHOULD send a list of acceptable cryptosuites in 675 the EAP-Finish/Re-auth message. 677 The rIK length may be different from the key length required by an 678 integrity algorithm. In case of hash-based MAC algorithms, the key 679 is first hashed to the required key length using the HMAC algorithm 680 [RFC2104]. In the case of cipher-based MAC algorithms, if the 681 required key length is less than 32 octets, the rIK is hashed using 682 HMAC-SHA256 and the first k octets of the output are used, where k is 683 the key length required by the algorithm. If the required key length 684 is more than 32 octets, the first k octets of the rIK are used by the 685 cipher-based MAC algorithm. 687 4.6. rMSK Derivation 689 The rMSK is derived at the peer and server and delivered to the 690 authenticator. The rMSK is derived following an EAP Re-auth Protocol 691 exchange. 693 The rMSK is derived as follows. 695 rMSK = KDF (K, S), where 697 K = rRK and 699 S = rMSK label | "\0" | SEQ | length 701 The rMSK label is the 8-bit ASCII string: 703 Re-authentication Master Session Key@ietf.org 705 The length field refers to the length of the rMSK in octets. The 706 length field is encoded as specified in RFC 5295. 708 SEQ is the sequence number sent by the peer in the EAP-Initiate/ 709 Re-auth message. This field is encoded as a 16-bit number in network 710 byte order (see Section 5.3.2). 712 An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest 713 of the document. The key derivation and properties specified in this 714 section remain the same. 716 4.7. rMSK Properties 718 The rMSK has the following properties: 720 o The length of the rMSK MUST be equal to the length of the rRK. 722 o The rMSK is delivered to the authenticator and is used for the 723 same purposes that an MSK is used at an authenticator. 725 o The rMSK is cryptographically separate from any other keys derived 726 from the rRK. 728 o The lifetime of the rMSK is less than or equal to that of the rRK. 729 It MUST NOT be greater than the lifetime of the rRK. 731 o If a new rRK is derived, subsequent rMSKs MUST be derived from the 732 new rRK. Previously delivered rMSKs MAY still be used until the 733 expiry of the lifetime. 735 o A given rMSK MUST NOT be shared by multiple authenticators. 737 5. Protocol Details 739 5.1. ERP Bootstrapping 741 We identify two types of bootstrapping for ERP: explicit and 742 implicit. In implicit bootstrapping, the ER-capable authenticator or 743 local ER server MUST verify whether it has a valid rMSK or rRK 744 corresponding to the peer. If the ER capable authenticator or the 745 local ER server has the key materials corresponding to the peer, it 746 MUST be able to respond directly in the same way as the home AAA 747 server does without forwarding the DSRK request to the home domain; 748 if not, the ER-capable authenticator or local ER server SHOULD 749 include its domain name in the AAA message encapsulating the first 750 EAP Response message sent by the peer and request the DSRK from the 751 home EAP server during the initial EAP exchange. If such EAP 752 exchange is successful, the home EAP server sends the DSRK for the 753 specified local AAA client or agent (derived using the EMSK and the 754 domain name as specified in RFC 5295), EMSKname, and DSRK lifetime 755 along with the EAP-Success message. The local AAA client or agent 756 MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) 757 before forwarding the EAP-Success message to the peer. Note that the 758 MSK (also present with the EAP Success message) is extracted by the 759 EAP authenticator as usual. The peer learns the domain name through 760 the EAP-Initiate/Re-auth-Start message or by means of lower-layer 761 announcement (for example, DHCP [RFC6440]). When the domain name is 762 available to the peer during or after the full EAP authentication, it 763 attempts to use ERP when it associates with a new authenticator. 765 If the peer knows there is no local ER server presented in the 766 visited domain, it SHOULD initiate Explicit ERP bootstrapping (ERP 767 exchange with the bootstrap flag turned on) with the home ER server 768 to obtain the rRK. The peer MAY also initiate bootstrapping to fetch 769 information such as the rRK lifetime from the AAA server. 771 The following steps describe the ERP Explicit Bootstrapping process: 773 o The peer sends the EAP-Initiate/Re-auth message with the 774 bootstrapping flag set (1). The bootstrap message is always sent 775 to the home ER server, and the keyname-NAI attribute in the 776 bootstrap message is constructed as follows: the username portion 777 of the NAI contains the EMSKname, and the realm portion contains 778 the home domain name. 780 o In addition, the message MUST contain a sequence number for replay 781 protection, a cryptosuite, and an integrity checksum. The 782 cryptosuite indicates the authentication algorithm. The integrity 783 checksum indicates that the message originated at the claimed 784 entity, the peer indicated by the Peer-ID, or the rIKname. 786 o The peer MAY additionally set the lifetime flag to request the key 787 lifetimes. 789 o Upon receipt of the EAP-Initiate/Re-auth message from a peer, the 790 ERP-capable authenticator verifies whether it has the local domain 791 name and valid key materials corresponding to the peer. If it 792 knows the local domain name and has valid key material 793 corresponding to the peer, it MUST be able to respond directly in 794 the same way as the home ER does with local domain name included. 795 If not, it copies the contents of the keyName-NAI into the 796 appropriate AAA attribute and may include its domain name in the 797 AAA message encapsulating the EAP-Initiate/Re-auth message sent by 798 the peer. 800 o Upon receipt of an EAP-Initiate/Re-auth message, the home ER 801 server verifies whether the message is fresh or is a replay by 802 evaluating whether the received sequence number is equal to or 803 greater than the expected sequence number for that rIK. The home 804 ER server then verifies that the cryptosuite used by the peer is 805 acceptable. Next, it verifies the integrity of the message by 806 looking up the rIK and checking integrity checksum contained in 807 the Authentication Tag field. If any of the checks fail, the home 808 ER server sends an EAP-Finish/Re-auth message with the Result flag 809 set to '1'. Please refer to Section 5.2.2 for details on failure 810 handling. This error MUST NOT have any correlation to any EAP- 811 Success message that may have been received by the EAP 812 authenticator and the peer earlier. If the EAP-Initiate/Re-auth 813 message is well-formed and valid, the server prepares the EAP- 814 Finish/Re-auth message. The bootstrap flag MUST be set to 815 indicate that this is a bootstrapping exchange. The message 816 contains the following fields: 818 * A sequence number for replay protection. 820 * The same keyName-NAI as in the EAP-Initiate/Re-auth message. 822 * If the lifetime flag was set in the EAP-Initiate/Re-auth 823 message, the ER server SHOULD include the rRK lifetime and the 824 rMSK lifetime in the EAP-Finish/Re-auth message. The server 825 may have a local policy for the network to maintain and enforce 826 lifetime unilaterally. In such cases, the server need not 827 respond to the peer's request for the lifetime. 829 * If the bootstrap flag is set, the ER server MUST include the 830 domain name to which the DSRK is being sent along with the EAP- 831 Finish/Re-auth message. 833 * If the ER server verifies the authorization of a local ER 834 server, it MAY include the Authorization Indication TLV to 835 indicate to the peer that the server that received the DSRK and 836 that is advertising the domain included in the domain name TLV 837 is authorized. 839 * An authentication tag MUST be included to prove that the EAP- 840 Finish/Re-auth message originates at a server that possesses 841 the rIK corresponding to the EMSKname-NAI. 843 o If the home ER server is involved in the ERP exchange and the ERP 844 exchange is successful, the home ER server SHOULD request the DSRK 845 from the home EAP server; the home EAP server MUST provide the 846 DSRK for the home ER server (derived using the EMSK and the domain 847 name as specified in RFC 5295), EMSKname, and DSRK lifetime for 848 inclusion in the AAA message. The home ER server SHOULD obtain 849 them before sending the EAP-Finish/Re-auth message. 851 o In addition, the rMSK is sent along with the EAP-Finish/Re-auth 852 message in a AAA attribute (for an example, see Bournelle, et 853 al. [I-D.ietf-dime-erp]. 855 o The authenticator receives the rMSK. 857 o When the peer receives an EAP-Finish/Re-auth message with the 858 bootstrap flag set, if a local domain name is present, it MUST use 859 that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- 860 NAI, and initialize the replay counter for the DS-rIK. If not, 861 the peer SHOULD derive the domain-specific keys using the domain 862 name it learned via the lower layer or from the EAP-Initiate/ 863 Re-auth-Start message. If the peer does not know the domain name, 864 it must assume that there is no local ER server available. 866 o The peer MAY also verify the Authorization Indication TLV. 868 o The procedures for encapsulating ERP and obtaining relevant keys 869 using Diameter are specified in [I-D.ietf-dime-erp]. 871 Since the ER bootstrapping exchange is typically done immediately 872 following the full EAP exchange, it is feasible that the process is 873 completed through the same entity that served as the EAP 874 authenticator for the full EAP exchange. In this case, the lower 875 layer may already have established TSKs based on the MSK received 876 earlier. The lower layer may then choose to ignore the rMSK that was 877 received with the ER bootstrapping exchange. Alternatively, the 878 lower layer may choose to establish a new TSK using the rMSK. In 879 either case, the authenticator and the peer know which key is used 880 based on whether or not a TSK establishment exchange is initiated. 881 The bootstrapping exchange may also be carried out via a new 882 authenticator, in which case, the rMSK received SHOULD trigger a 883 lower layer TSK establishment exchange. 885 5.2. Steps in ERP 887 When a peer that has an active rRK and rIK associates with a new 888 authenticator that supports ERP, it may perform an ERP exchange with 889 that authenticator. ERP is typically a peer-initiated exchange, 890 consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth 891 message. The ERP exchange may be performed with a local ER server 892 (when one is present) or with the original EAP server. 894 It is plausible for the network to trigger the EAP re-authentication 895 process, however. An ERP-capable authenticator SHOULD send an EAP- 896 Initiate/Re-auth-Start message to indicate support for ERP. The peer 897 may or may not wait for these messages to arrive to initiate the EAP- 898 Initiate/Re-auth message. 900 The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- 901 capable authenticator. The authenticator may retransmit it a few 902 times until it receives an EAP-Initiate/Re-auth message in response 903 from the peer. The EAP-Initiate/Re-auth message from the peer may 904 have originated before the peer receives either an EAP-Request/ 905 Identity or an EAP-Initiate/Re-auth-Start message from the 906 authenticator. Hence, the Identifier value in the EAP-Initiate/ 907 Re-auth message is independent of the Identifier value in the EAP- 908 Initiate/Re-auth-Start or the EAP-Request/Identity messages. 910 Operational Considerations at the Peer: 912 ERP requires that the peer maintain retransmission timers for 913 reliable transport of EAP re-authentication messages. The 914 reliability considerations of Section 4.3 of RFC 3748 apply with the 915 peer as the retransmitting entity. 917 The EAP Re-auth Protocol has the following steps: 919 The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start 920 message to trigger the ERP exchange. 922 The peer sends an EAP-Initiate/Re-auth message. At a minimum, the 923 message SHALL include the following fields: 925 a 16-bit sequence number for replay protection 927 keyName-NAI as a TLV attribute to identify the rIK used to 928 integrity protect the message. 930 cryptosuite to indicate the authentication algorithm used to 931 compute the integrity checksum. 933 Authentication Tag computed over the message. 935 When the peer is performing ERP with a local ER server, it MUST 936 use the corresponding DS-rIK it shares with the local ER server. 937 The peer SHOULD set the lifetime flag to request the key lifetimes 938 from the server. The peer can use the rRK lifetime to know when 939 to trigger an EAP method exchange and the rMSK lifetime to know 940 when to trigger another ERP exchange. 942 The authenticator copies the contents of the value field of the 943 keyName-NAI TLV into an appropriate attribute (e.g, User-Name 944 [RFC2865]) in the AAA message to the ER server. 946 The ER server uses the keyName-NAI to look up the rIK. It MUST 947 first verify whether the sequence number is equal to or greater 948 than the expected sequence number. If the ER server supports a 949 sequence number window size greater than 1, it MUST verify whether 950 the sequence number falls within the window and has not been 951 received before. The ER server MUST then verify that the 952 cryptosuite used by the peer is acceptable. The ER server then 953 proceeds to verify the integrity of the message using the rIK, 954 thereby verifying proof of possession of that key by the peer. If 955 any of these verifications fail, the ER server MUST send an EAP- 956 Finish/Re-auth message with the Result flag set to '1' (Failure). 957 Please refer to Section 5.2.2 for details on failure handling. 958 Otherwise, it MUST compute an rMSK from the rRK using the sequence 959 number as the additional input to the key derivation. 961 In response to a well-formed EAP Re-auth/Initiate message, the ER 962 server MUST send an EAP-Finish/Re-auth message with the following 963 contents: 965 a 16-bit sequence number for replay protection, which MUST be 966 the same as the received sequence number. The local copy of 967 the sequence number MUST be incremented by 1. If the ER server 968 supports multiple simultaneous ERP exchanges, it MUST instead 969 update the sequence number window. 971 keyName-NAI as a TLV attribute to identify the rIK used to 972 integrity protect the message. 974 cryptosuite to indicate the authentication algorithm used to 975 compute the integrity checksum. 977 Authentication Tag over the message. 979 If the lifetime flag was set in the EAP-Initiate/Re-auth 980 message, the ER server SHOULD include the rRK lifetime and the 981 rMSK lifetime. 983 The ER server causes the rMSK along with this message to to be 984 transported to the authenticator. The rMSK is transported in a 985 manner similar to the MSK and the EAP-Success message in a regular 986 EAP exchange. 988 The peer looks up the sequence number to verify whether it is 989 expecting an EAP-Finish/Re-auth message with that sequence number 990 protected by the keyName-NAI. It then verifies the integrity of 991 the message. If the verifications fail, the peer logs an error 992 and stops the process; otherwise, it proceeds to the next step. 994 The peer uses the sequence number to compute the rMSK. 996 The lower-layer security association protocol can be triggered at 997 this point. 999 5.2.1. Multiple Simultaneous Runs of ERP 1001 When a peer is within the range of multiple authenticators, it may 1002 choose to run ERP via all of them simultaneously to the same ER 1003 server. In that case, it is plausible that the ERP messages may 1004 arrive out of order, resulting in the ER server rejecting legitimate 1005 EAP-Initiate/Re-auth messages. 1007 To facilitate such operation, an ER server MAY allow multiple 1008 simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth 1009 messages with SEQ number values within a window of allowed values. 1010 Recall that the SEQ number allows replay protection. Replay window 1011 maintenance mechanisms are a local matter. 1013 5.2.2. ERP Failure Handling 1015 If the processing of the EAP-Initiate/Re-auth message results in a 1016 failure, the ER server MUST send an EAP-Finish Re-auth message with 1017 the Result flag set to '1'. If the server has a valid rIK for the 1018 peer, it MUST integrity protect the EAP-Finish/Re-auth failure 1019 message. If the failure is due to an unacceptable cryptosuite, the 1020 server SHOULD send a list of acceptable cryptosuites (in a TLV of 1021 Type 5) along with the EAP-Finish/Re-auth message. In this case, the 1022 server MUST indicate the cryptosuite used to protect the EAP-Finish/ 1023 Re-auth message in the cryptosuite. The rIK used with the EAP- 1024 Finish/Re-auth message in this case MUST be computed as specified in 1025 Section 4.3 using the new cryptosuite. If the server does not have a 1026 valid rIK for the peer, the EAP-Finish/Re-auth message indicating a 1027 failure will be unauthenticated; the server MAY include a list of 1028 acceptable cryptosuites in the message. 1030 The peer, upon receiving an EAP-Finish/Re-auth message with the 1031 Result flag set to '1', MUST verify the sequence number and, if 1032 possible, the Authentication Tag to determine the validity of the 1033 message. If the peer supports the cryptosuite, it MUST verify the 1034 integrity of the received EAP-Finish/Re-auth message. If the EAP- 1035 Finish message contains a TLV of Type 5, the peer SHOULD retry the 1036 ERP exchange with a cryptosuite picked from the list included by the 1037 server. The peer MUST use the appropriate rIK for the subsequent ERP 1038 exchange, by computing it with the corresponding cryptosuite, as 1039 specified in Section 4.3. If the PRF in the chosen cryptosuite is 1040 different from the PRF originally used by the peer, it MUST derive a 1041 new DSRK (if required), rRK, and rIK before proceeding with the 1042 subsequent ERP exchange. 1044 If the peer cannot verify the integrity of the received message, it 1045 MAY choose to retry the ERP exchange with one of the cryptosuites in 1046 the List of cryptosuites TLV, after a failure has been clearly 1047 determined following the procedure in the next paragraph. 1049 If the replay or integrity checks fail, the failure message may have 1050 been sent by an attacker. It may also mean that the server and peer 1051 do not support the same cryptosuites; however, the peer cannot 1052 determine if that is the case. Hence, the peer SHOULD continue the 1053 ERP exchange per the retransmission timers before declaring a 1054 failure. 1056 When the peer runs explicit bootstrapping (ERP with the bootstrapping 1057 flag on), there may not be a local ER server available to send a DSRK 1058 Request and the domain name. In that case, the server cannot send 1059 the DSRK and MUST NOT include the domain name TLV. When the peer 1060 receives a response in the bootstrapping exchange without a domain 1061 name TLV, it assumes that there is no local ER server. The home ER 1062 server sends an rMSK to the ER authenticator, however, and the peer 1063 SHALL run the TSK establishment protocol as usual. 1065 5.3. EAP Codes 1067 Two EAP Codes are defined for the purpose of ERP: EAP-Initiate and 1068 EAP-Finish. The packet format for these messages follows the EAP 1069 packet format defined in Aboba, et al. [RFC3748]. 1071 0 1 2 3 1072 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 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Code | Identifier | Length | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Type | Type-Data ... 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1079 Figure 7: EAP Packet 1081 Code 1083 Two code values are defined for the purpose of ERP: 1085 5 Initiate 1087 6 Finish 1089 Identifier 1091 The Identifier field is one octet. The Identifier field MUST 1092 be the same if an EAP-Initiate packet is retransmitted due to a 1093 timeout while waiting for a EAP-Finish message. Any new (non- 1094 retransmission) EAP-Initiate message MUST use a new Identifier 1095 field. 1097 The Identifier field of the EAP-Finish message MUST match that 1098 of the currently outstanding EAP-Initiate message. A peer or 1099 authenticator receiving a EAP-Finish message whose Identifier 1100 value does not match that of the currently outstanding EAP- 1101 Initiate message MUST silently discard the packet. 1103 In order to avoid confusion between new EAP-Initiate messages 1104 and retransmissions, the peer must choose an Identifier value 1105 that is different from the previous EAP-Initiate message, 1106 especially if that exchange has not finished. It is 1107 RECOMMENDED that the authenticator clear EAP Re-auth state 1108 after 300 seconds. 1110 Type 1112 This field indicates that this is an ERP exchange. Two type 1113 values are defined in this document for this purpose -- Re- 1114 auth-Start (Type 1) and Re-auth (Type 2). 1116 Type-Data 1118 The Type-Data field varies with the Type of re-authentication 1119 packet. 1121 5.3.1. EAP-Initiate/Re-auth-Start Packet 1123 The EAP-Initiate/Re-auth-Start packet contains the fields shown in 1124 Figure 8. 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Code | Identifier | Length | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Type | Reserved | 1 or more TVs or TLVs ~ 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 Figure 8: EAP-Initiate/Re-auth-Start Packet 1136 Type = 1. 1138 Reserved, MUST be zero. Set to zero on transmission and ignored 1139 on reception. 1141 One or more TVs or TLVs are used to convey information to the 1142 peer; for instance, the authenticator may send the domain name to 1143 the peer. 1145 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1146 and a value with type-specific length. In the TLV payloads, there 1147 is a 1-octet type payload and a 1-octet length payload. The 1148 length field indicates the length of the value expressed in number 1149 of octets. 1151 Domain-Name: This is a TLV payload. The Type is 4. The domain 1152 name is to be used as the realm in an NAI [RFC4282]. The 1153 Domain-Name TLV SHOULD be present in an EAP-Initiate/ 1154 Re-auth-Start message. 1156 In addition, channel binding information MAY be included; see 1157 Section 5.5 for discussion. See Figure 12 for parameter 1158 specification. 1160 5.3.1.1. Authenticator Operation 1162 In order to minimize ERP failure times, the authenticator SHOULD send 1163 the EAP-Initiate/Re-auth-Start message to indicate support for ERP to 1164 the peer and to initiate ERP if the peer has already performed full 1165 EAP authentication and has unexpired key material. The authenticator 1166 SHOULD include the Domain-Name TLV to allow the peer to learn it 1167 without requiring either lower-layer support or the ERP bootstrapping 1168 exchange. 1170 The authenticator MAY include channel binding information so so that 1171 the server can verify whether the authenticator is claiming the same 1172 identity to both parties. 1174 The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start 1175 message a few times for reliable transport. 1177 5.3.1.2. Peer Operation 1179 The peer SHOULD send the EAP-Initiate/Re-auth message in response to 1180 the EAP-Initiate/Re-auth-Start message from the authenticator. If 1181 the peer does not recognize the EAP-Initiate code value or if the 1182 peer has already sent the EAP-Initiate/Re-auth message to begin the 1183 ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start 1184 message. 1186 If the EAP-Initiate/Re-auth-Start message contains the domain name, 1187 and if the peer does not already have the domain information, the 1188 peer SHOULD use the domain name contained in the message to compute 1189 the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/ 1190 Re-auth message to start an ERP exchange with the local ER server. 1191 If there is a local ER server between the peer and the home ER server 1192 and the peer has already initiated an ERP exchange with the local ER 1193 server, it SHOULD NOT start an ERP exchange with the home ER server. 1195 5.3.2. EAP-Initiate/Re-auth Packet 1197 The EAP-Initiate/Re-auth packet contains the parameters shown in 1198 Figure 9. 1200 0 1 2 3 1201 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 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Code | Identifier | Length | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Type |R|B|L| Reserved| SEQ | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | 1 or more TVs or TLVs ~ 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | cryptosuite | Authentication Tag ~ 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Figure 9: EAP-Initiate/Re-auth Packet 1214 Type = 2. 1216 Flags 1218 'R' - The R flag is set to 0 and ignored upon reception. 1220 'B' - The B flag is used as the bootstrapping flag. If the 1221 flag is turned on, the message is a bootstrap message. 1223 'L' - The L flag is used to request the key lifetimes from the 1224 server. 1226 The remaining 5 bits are set to 0 on transmission and ignored 1227 on reception. 1229 SEQ: An unsigned 16-bit sequence number is used for replay 1230 protection. The SEQ number field is initialized to 0 every time a 1231 new rRK is derived. The field is encoded in network byte order. 1233 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1234 and a value with type-specific length. In the TLV payloads, there 1235 is a 1-octet type payload and a 1-octet length payload. The 1236 length field indicates the length of the value expressed in number 1237 of octets. 1239 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1240 The NAI is variable in length, not exceeding 253 octets. The 1241 EMSKname is in the username part of the NAI and is encoded in 1242 hexadecimal values. The EMSKname is 64 bits in length and so 1243 the username portion takes up 16 octets. If the rIK is derived 1244 from the EMSK, the realm part of the NAI is the home domain 1245 name, and if the rIK is derived from a DSRK, the realm part of 1246 the NAI is the domain name used in the derivation of the DSRK. 1247 The NAI syntax is specified in Aboba, et al. [RFC4282]. 1249 Exactly one keyName-NAI attribute SHALL be present in an EAP- 1250 Initiate/Re-auth packet. 1252 In addition, channel binding information MAY be included; see 1253 Section 5.5 for discussion. See Figure 12 for parameter 1254 specification. 1256 Cryptosuite: This field indicates the integrity algorithm used for 1257 ERP. Key lengths and output lengths are either indicated or are 1258 obvious from the cryptosuite name. We specify some cryptosuites 1259 below: 1261 * 0 RESERVED 1263 * 1 HMAC-SHA256-64 1265 * 2 HMAC-SHA256-128 1267 * 3 HMAC-SHA256-256 1269 HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled in 1270 the default configuration. 1272 Authentication Tag: This field contains the integrity checksum 1273 over the ERP packet, excluding the authentication tag field 1274 itself. The length of the field is indicated by the Cryptosuite. 1276 5.3.3. EAP-Finish/Re-auth Packet 1278 The EAP-Finish/Re-auth packet contains the parameters shown in 1279 Figure 10. 1281 0 1 2 3 1282 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 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | Code | Identifier | Length | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Type |R|B|L| Reserved | SEQ ~ 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | 1 or more TVs or TLVs ~ 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Cryptosuite | Authentication Tag ~ 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 Figure 10: EAP-Finish/Re-auth Packet 1295 Type = 2. 1297 Flags 1299 'R' - The R flag is used as the Result flag. When set to 0, it 1300 indicates success, and when set to '1', it indicates a failure. 1302 'B' - The B flag is used as the bootstrapping flag. If the 1303 flag is turned on, the message is a bootstrap message. 1305 'L' - The L flag is used to indicate the presence of the rRK 1306 lifetime TLV. 1308 The remaining 5 bits are set to 0 on transmission and ignored 1309 on reception. 1311 SEQ: An unsigned 16-bit sequence number is used for replay 1312 protection. The SEQ number field is initialized to 0 every time a 1313 new rRK is derived. The field is encoded in network byte order. 1315 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1316 and a value with type-specific length. In the TLV payloads, there 1317 is a 1-octet type payload and a 1-octet length payload. The 1318 length field indicates the length of the value expressed in number 1319 of octets. 1321 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1322 The NAI is variable in length, not exceeding 253 octets. 1323 EMSKname is in the username part of the NAI and is encoded in 1324 hexadecimal values. The EMSKname is 64 bits in length and so 1325 the username portion takes up 16 octets. If the rIK is derived 1326 from the EMSK, the realm part of the NAI is the home domain 1327 name, and if the rIK is derived from a DSRK, the realm part of 1328 the NAI is the domain name used in the derivation of the DSRK. 1329 The NAI syntax follows [RFC4282]. Exactly one instance of the 1330 keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth 1331 message. 1333 rRK Lifetime: This is a TV payload. The Type is 2. The value 1334 field contains an unsigned 32-bit integer in network byte order 1335 representing the lifetime of the rRK in seconds. If the 'L' 1336 flag is set, the rRK Lifetime attribute SHOULD be present. 1338 rMSK Lifetime: This is a TV payload. The Type is 3. The value 1339 field contains an unsigned 32-bit integer in network byte order 1340 representing the lifetime of the rMSK in seconds. If the 'L' 1341 flag is set, the rMSK Lifetime attribute SHOULD be present. 1343 Domain-Name: This is a TLV payload. The Type is 4. The domain 1344 name is to be used as the realm in an NAI [RFC4282]. Domain- 1345 Name attribute MUST be present in an EAP-Finish/Re-auth message 1346 if the bootstrapping flag is set and if the local ER server 1347 sent a DSRK request. 1349 List of cryptosuites: This is a TLV payload. The Type is 5. 1350 The value field contains a list of cryptosuites, each of size 1 1351 octet. The cryptosuite values are as specified in Figure 9. 1352 The server SHOULD include this attribute if the cryptosuite 1353 used in the EAP-Initiate/Re-auth message was not acceptable and 1354 the message is being rejected. The server MAY include this 1355 attribute in other cases. The server MAY use this attribute to 1356 signal to the peer about its cryptographic algorithm 1357 capabilities. 1359 Authorization Indication: This is a TLV payload. The Type is 1360 6. This attribute MAY be included in the EAP-Finish/Re-auth 1361 message when a DSRK is delivered to a local ER server and if 1362 the home EAP server can verify the authorization of the local 1363 ER server to advertise the domain name included in the domain 1364 TLV in the same message. The value field in the TLV contains 1365 an authentication tag computed over the entire packet, starting 1366 from the first bit of the code field to the last bit of the 1367 cryptosuite field, with the value field of the Authorization 1368 Indication TLV filled with all 0s for the computation. The key 1369 used for the computation MUST be derived from the EMSK with key 1370 label "DSRK Delivery Authorized Key@ietf.org" and optional data 1371 containing an ASCII string representing the key management 1372 domain that the DSRK is being derived for. 1374 In addition, channel binding information MAY be included: see 1375 Section 5.5 for discussion. See Figure 12 for parameter 1376 specification. The server sends this information so that the 1377 peer can verify the information seen at the lower layer, if 1378 channel binding is to be supported. 1380 Cryptosuite: This field indicates the integrity algorithm and the 1381 PRF used for ERP. Key lengths and output lengths are either 1382 indicated or are obvious from the cryptosuite name. 1384 Authentication Tag: This field contains the integrity checksum 1385 over the ERP packet, excluding the authentication tag field 1386 itself. The length of the field is indicated by the Cryptosuite. 1388 5.3.4. TV and TLV Attributes 1390 The TV attributes that may be present in the EAP-Initiate or EAP- 1391 Finish messages are of the following format: 1393 0 1 2 3 1394 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 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Type | Value ... 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 Figure 11: TV Attribute Format 1401 The TLV attributes that may be present in the EAP-Initiate or EAP- 1402 Finish messages are of the following format: 1404 0 1 2 3 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Type | Length | Value ... 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 Figure 12: TLV Attribute Format 1412 The following Types are defined in this document: 1414 '1' - keyName-NAI: This is a TLV payload. 1416 '2' - rRK Lifetime: This is a TV payload. 1418 '3' - rMSK Lifetime: This is a TV payload. 1420 '4' - domain name: This is a TLV payload. 1422 '5' - cryptosuite list: This is a TLV payload. 1424 '6' - Authorization Indication: This is a TLV payload. 1426 The TLV type range of 128-191 is reserved to carry channel binding 1427 information in the EAP-Initiate and Finish/Re-auth messages. 1428 Below are the current assignments (all of them are TLVs): 1430 '128' - Called-Station-Id [RFC2865] 1432 '129' - Calling-Station-Id [RFC2865] 1433 '130' - NAS-Identifier [RFC2865] 1435 '131' - NAS-IP-Address [RFC2865] 1437 '132' - NAS-IPv6-Address [RFC3162] 1439 The length field indicates the length of the value part of the 1440 attribute in octets. 1442 5.4. Replay Protection 1444 For replay protection, ERP uses sequence numbers. The sequence 1445 number is maintained on a per rIK basis and is initialized to zero in 1446 both directions. In the first EAP-Initiate/Re-auth message, the peer 1447 uses a sequence number value of zero or higher. Note that the when 1448 the sequence number wraps back to zero, the rIK MUST be changed by 1449 running a full EAP authentication. The server expects a sequence 1450 number of zero or higher. When the server receives an EAP-Initiate/ 1451 Re-auth message, it uses the same sequence number in the EAP-Finish/ 1452 Re-auth message. The server then sets the expected sequence number 1453 to the received sequence number plus 1. The server MUST accept 1454 sequence numbers greater than or equal to the expected sequence 1455 number. 1457 If the peer sends an EAP-Initiate/Re-auth message, but does not 1458 receive a response, it retransmits the request (with no changes to 1459 the message itself) a pre-configured number of times before giving 1460 up. However, it is plausible that the server itself may have 1461 responded to the message and the response was lost in transit. Thus, 1462 the peer MUST increment the sequence number and use the new sequence 1463 number to send subsequent EAP re-authentication messages. The peer 1464 SHOULD increment the sequence number by 1; however, it may choose to 1465 increment by a larger number. If the sequence number wraps back to 1466 zero, the peer MUST run full EAP authentication. 1468 5.5. Channel Binding 1470 ERP provides a protected facility to carry channel binding (CB) 1471 information, according to the guidelines provided by Aboba, et 1472 al. (see Section 7.15 of [RFC3748]). The TLV type range of 128-191 1473 is reserved to carry CB information in the EAP-Initiate/Re-auth and 1474 EAP-Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id, 1475 NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address are some 1476 examples of channel binding information listed in RFC 3748, and they 1477 are assigned values 128-132. Additional values are IANA managed 1478 based on IETF Consensus [RFC5226]. 1480 The authenticator MAY provide CB information to the peer via the EAP- 1481 Initiate/Re-auth-Start message. The peer sends the information to 1482 the server in the EAP-Initiate/Re-auth message; the server verifies 1483 whether the authenticator identity available via AAA attributes is 1484 the same as the identity provided to the peer. 1486 If the peer does not include the CB information in the EAP-Initiate/ 1487 Re-auth message, and if the local ER server's policy requires channel 1488 binding support, it SHALL send the CB attributes for the peer's 1489 verification. The peer attempts to verify the CB information if the 1490 authenticator has sent the CB parameters, and it proceeds with the 1491 lower-layer security association establishment if the attributes 1492 match. Otherwise, the peer SHALL NOT proceed with the lower-layer 1493 security association establishment. 1495 6. Lower-Layer Considerations 1497 The authenticator is responsible for retransmission of EAP-Initiate/ 1498 Re-auth-Start messages. The authenticator MAY retransmit the message 1499 a few times or until it receives an EAP-Initiate/Re-auth message from 1500 the peer. The authenticator might not know if the peer supports ERP; 1501 in those cases, the peer could be silently discarding the EAP- 1502 Initiate/Re-auth-Start packets. Thus, retransmission of these 1503 packets should be kept to a minimum. The exact number is up to each 1504 lower layer. 1506 The Identifier value in the EAP-Initiate/Re-auth packet is 1507 independent of the Identifier value in the EAP-Initiate/Re-auth-Start 1508 packet. 1510 The peer is responsible for retransmission of EAP-Initiate/Re-auth 1511 messages. 1513 Retransmitted packets MUST be sent with the same Identifier value in 1514 order to distinguish them from new packets. By default, where the 1515 EAP-Initiate message is sent over an unreliable lower layer, the 1516 retransmission timer SHOULD be dynamically estimated. A maximum of 1517 3-5 retransmissions is suggested [RFC3748]. Where the EAP-Initiate 1518 message is sent over a reliable lower layer, the retransmission timer 1519 SHOULD be set to an infinite value, so that retransmissions do not 1520 occur at the EAP layer. Please refer to RFC 3748 for additional 1521 guidance on setting timers. 1523 The Identifier value in the EAP-Finish/Re-auth packet is the same as 1524 the Identifier value in the EAP-Initiate/Re-auth packet. 1526 If an authenticator receives a valid duplicate EAP-Initiate/Re-auth 1527 message for which it has already sent an EAP-Finish/Re-auth message, 1528 it MUST resend the EAP-Finish/Re-auth message without reprocessing 1529 the EAP-Initiate/Re-auth message. To facilitate this, the 1530 authenticator SHALL store a copy of the EAP-Finish/Re-auth message 1531 for a finite amount of time. The actual value of time is a local 1532 matter; this specification recommends a value of 100 milliseconds. 1534 The lower layer may provide facilities for exchanging information 1535 between the peer and the authenticator about support for ERP, for the 1536 authenticator to send the domain name information and channel binding 1537 information to the peer 1539 Note that to support ERP, lower-layer specifications may need to be 1540 revised. Specifically, RFC 5996 must be updated to include EAP code 1541 values higher than 4 in order to use ERP with Internet Key Exchange 1542 Protocol version 2 (IKEv2). IKEv2 may also be updated to support 1543 peer-initiated ERP for optimized operation. Other lower layers may 1544 need similar revisions. 1546 Our analysis indicates that some EAP implementations are not RFC 3748 1547 compliant in that instead of silently dropping EAP packets with code 1548 values higher than 4, they may consider it an error. To accommodate 1549 such non-compliant EAP implementations, additional guidance has been 1550 provided below. Furthermore, it may not be easy to upgrade all the 1551 peers in some cases. In such cases, authenticators may be configured 1552 to not send EAP-Initiate/Re-auth-Start; peers may learn whether an 1553 authenticator supports ERP via configuration or from advertisements 1554 at the lower layer. 1556 In order to accommodate implementations that are not compliant to RFC 1557 3748, such lower layers SHOULD ensure that both parties support ERP; 1558 this is trivial for instance when using a lower layer that is known 1559 to always support ERP. For lower layers where ERP support is not 1560 guaranteed, ERP support may be indicated through signaling (e.g., 1561 piggy-backed on a beacon) or through negotiation. Alternatively, 1562 clients may recognize environments where ERP is available based on 1563 pre-configuration. Other similar mechanisms may also be used. When 1564 ERP support cannot be verified, lower layers may mandate falling back 1565 to full EAP authentication to accommodate EAP implementations that 1566 are not compliant to RFC 3748. 1568 7. AAA Transport of ERP Messages 1570 AAA Transport of ERP messages is specified by Hoeper, et 1571 al. [RFC5749] and Bournelle, et al. [I-D.ietf-dime-erp]. 1573 8. Security Considerations 1575 This section provides an analysis of the protocol in accordance with 1576 the AAA key management guidelines described by Housley & Aboba 1577 [RFC4962]. 1579 Cryptographic algorithm independence 1581 The EAP Re-auth Protocol satisfies this requirement. The 1582 algorithm chosen by the peer for the MAC generation is 1583 indicated in the EAP-Initiate/Re-auth message. If the chosen 1584 algorithm is unacceptable, the EAP server returns an EAP- 1585 Finish/Re-auth message with Failure indication. Algorithm 1586 agility for the KDF is specified in Salowey, et al. [RFC5295]. 1587 Only when the algorithms used are deemed acceptable does the 1588 server proceed with the derivation of keys and verification of 1589 the proof of possession of relevant keying material presented 1590 by the peer. A full-blown negotiation of algorithms cannot be 1591 provided in a single round trip protocol. Hence, while the 1592 protocol provides algorithm agility, it does not provide true 1593 negotiation. 1595 Strong, fresh session keys 1597 ERP results in the derivation of strong, fresh keys that are 1598 unique for the given session. An rMSK is always derived on- 1599 demand when the peer requires a key with a new authenticator. 1600 The derivation ensures that the compromise of one rMSK does not 1601 result in the compromise of another rMSK at any time. 1603 Limit key scope 1605 The scope of all the keys derived by ERP is well defined. The 1606 rRK and rIK are never shared with any entity and always remain 1607 on the peer and the server. The rMSK is provided only to the 1608 authenticator through which the peer performs the ERP exchange. 1609 No other authenticator is authorized to use that rMSK. 1611 Replay detection mechanism 1613 For replay protection of ERP messages, a sequence number 1614 associated with the rIK is used. The sequence number is 1615 maintained by the peer and the server, and initialized to zero 1616 when the rIK is generated. The peer increments the sequence 1617 number by one after it sends an ERP message. The server sets 1618 the expected sequence number to the received sequence number 1619 plus one after verifying the validity of the received message 1620 and responds to the message. 1622 Authenticate all parties 1624 The EAP Re-auth Protocol provides mutual authentication of the 1625 peer and the server. Both parties need to possess the keying 1626 material that resulted from a previous EAP exchange in order to 1627 successfully derive the required keys. Also, both the EAP re- 1628 authentication Response and the EAP re-authentication 1629 Information messages are integrity protected so that the peer 1630 and the server can verify each other. When the ERP exchange is 1631 executed with a local ER server, the peer and the local server 1632 mutually authenticate each other via that exchange in the same 1633 manner. The peer and the authenticator authenticate each other 1634 in the secure association protocol executed by the lower layer, 1635 just as in the case of a regular EAP exchange. 1637 Peer and authenticator authorization 1639 The peer and authenticator demonstrate possession of the same 1640 key material without disclosing it, as part of the lower-layer 1641 secure association protocol. Channel binding with ERP may be 1642 used to verify consistency of the identities exchanged, when 1643 the identities used in the lower layer differ from that 1644 exchanged within the AAA protocol. 1646 Keying material confidentiality 1648 The peer and the server derive the keys independently using 1649 parameters known to each entity. The AAA server sends the DSRK 1650 of a domain to the corresponding local ER server via the AAA 1651 protocol. Likewise, the ER server sends the rMSK to the 1652 authenticator via the AAA protocol. 1654 Note that compromise of the DSRK results in compromise of all 1655 keys derived from it. Moreover, there is no forward secrecy 1656 within ERP. Thus, compromise of an DSRK retroactively 1657 compromises all ERP keys. 1659 It is RECOMMENDED that the AAA protocol be protected using 1660 IPsec or TLS so that the keys are protected in transit. Note, 1661 however, that keys may be exposed to AAA proxies along the way 1662 and compromise of any of those proxies may result in compromise 1663 of keys being transported through them. 1665 The home EAP server MUST NOT hand out a given DSRK to a local 1666 domain server more than once, unless it can verify that the 1667 entity receiving the DSRK after the first time is the same as 1668 that received the DSRK originally. If the home EAP server 1669 verifies authorization of a local domain server, it MAY hand 1670 out the DSRK to that domain more than once. In this case, the 1671 home EAP server includes the Authorization Indication TLV to 1672 assure the peer that DSRK delivery is secure. 1674 Confirm cryptosuite selection 1676 Crypto algorithms for integrity and key derivation in the 1677 context of ERP MAY be the same as that used by the EAP method. 1678 In that case, the EAP method is responsible for confirming the 1679 cryptosuite selection. Furthermore, the cryptosuite is 1680 included in the ERP exchange by the peer and confirmed by the 1681 server. The protocol allows the server to reject the 1682 cryptosuite selected by the peer and provide alternatives. 1683 When a suitable rIK is not available for the peer, the 1684 alternatives may be sent in an unprotected fashion. The peer 1685 is allowed to retry the exchange using one of the allowed 1686 cryptosuites. However, in this case, any en route 1687 modifications to the list sent by the server will go 1688 undetected. If the server does have an rIK available for the 1689 peer, the list will be provided in a protected manner and this 1690 issue does not apply. 1692 Uniquely named keys 1694 All keys produced within the ERP context can be referred to 1695 uniquely as specified in this document. Also, the key names do 1696 not reveal any part of the keying material. 1698 Prevent the domino effect 1700 The compromise of one peer does not result in the compromise of 1701 keying material held by any other peer in the system. Also, 1702 the rMSK is meant for a single authenticator and is not shared 1703 with any other authenticator. Hence, the compromise of one 1704 authenticator does not lead to the compromise of sessions or 1705 keys held by any other authenticator in the system. Hence, the 1706 EAP Re-auth Protocol allows prevention of the domino effect by 1707 appropriately defining key scope. 1709 However, if keys are transported using hop-by-hop protection, 1710 compromise of a proxy may result in compromise of key material, 1711 e.g., the DSRK being sent to a local ER server. 1713 Bind key to its context 1715 All the keys derived for ERP are bound to the appropriate 1716 context using appropriate key labels. Lifetime of a child key 1717 is less than or equal to that of its parent key as specified in 1718 RFC 4962 [RFC4962]. The key usage, lifetime and the parties 1719 that have access to the keys are specified. 1721 Confidentiality of identity 1723 Deployments where privacy is a concern may find the use of 1724 rIKname-NAI to route ERP messages serves their privacy 1725 requirements. Note that it is plausible to associate multiple 1726 runs of ERP messages since the rIKname is not changed as part 1727 of the ERP protocol. There was no consensus for that 1728 requirement at the time of development of this specification. 1729 If the rIKname is not used and the Peer-ID is used instead, the 1730 ERP exchange will reveal the Peer-ID over the wire. 1732 Authorization restriction 1734 All the keys derived are limited in lifetime by that of the 1735 parent key or by server policy. Any domain-specific keys are 1736 further restricted for use only in the domain for which the 1737 keys are derived. All the keys specified in this document are 1738 meant for use in ERP only. Other restrictions on the use of 1739 session keys may be imposed by the specific lower layer but are 1740 out of scope for this specification. 1742 Prevent DoS attack 1744 A denial-of-service (DoS) attack on the peer may be possible 1745 when using the EAP Initiate/Re-auth message. An attacker may 1746 send a bogus EAP-Initiate/Re-auth message, which may be carried 1747 by the authenticator in a AAA request to the server; in 1748 response, the server may send an EAP-Finish/Re-auth with 1749 Failure indication in a AAA reply. Note that such attacks may 1750 be possible with the EAPoL-Start capability of IEEE 802.11 and 1751 other similar facilities in other link layers and where the 1752 peer can initiate EAP authentication. An attacker may use such 1753 messages to start an EAP method run, which fails and may result 1754 in the server sending a rejection message, thus resulting in 1755 the link-layer connections being terminated. 1757 To prevent such DoS attacks, an ERP failure should not result 1758 in deletion of any authorization state established by a full 1759 EAP exchange. Alternatively, the lower layers and AAA 1760 protocols may define mechanisms to allow two link-layer 1761 security associations (SAs) derived from different EAP keying 1762 materials for the same peer to exist so that smooth migration 1763 from the current link layer SA to the new one is possible 1764 during rekey. These mechanisms prevent the link layer 1765 connections from being terminated when a re-authentication 1766 procedure fails due to a bogus EAP-Initiate/Re-auth message. 1768 Keying materials Transport 1770 When a DSRK is sent from the home EAP server to a local domain 1771 server or when a rMSK is sent from an ER server to an 1772 authenticator, in the absence of end-to-end security between 1773 the entity that is sending the key and the entity receiving the 1774 key, it is plausible for other entities to get access to keys 1775 being sent to an ER server in another domain. This mode of key 1776 transport is similar to that of MSK transport in the context of 1777 EAP authentication. We further observe that ERP is for access 1778 authentication and does not support end-to-end data security. 1779 In typical implementations, the traffic is in the clear beyond 1780 the access control enforcement point (the authenticator or an 1781 entity delegated by the authenticator for access control 1782 enforcement). The model works as long as entities in the 1783 middle of the network do not use keys intended for other 1784 parties to steal service from an access network. If that is 1785 not achievable, key delivery must be protected in an end-to-end 1786 manner. 1788 9. IANA Considerations 1790 This document replaces and obsoletes RFC 5296, and IANA is asked to 1791 change all registered references to that document to point instead to 1792 this document. [RFC Editor note: please remove the previous 1793 paragraph on publication.] 1795 The previous version of this document performed the following IANA 1796 [IANA] actions: 1798 1. It registered Packet Codes "Initiate" and "Finish" in the EAP 1799 Registry. Those are documented throughout this document as "EAP- 1800 Initiate" and "EAP-Finish". 1802 2. It created a Message Types table in the EAP Registry, and 1803 registered several items in that table. Those are documented 1804 throughout this document as "Re-auth-start" and "Re-auth". 1806 3. It created an EAP Initiate and Finish Attributes table in the EAP 1807 registry, and registered several items in that table. Those are 1808 documented in this document in Section 5.3.4. 1810 4. It created a Re-authentication Cryptosuites table in the EAP 1811 registry, and registered several items in that table. Those are 1812 documented in this document at the end of Section 5.3.2. 1814 5. It registered two items in the USRK Key Labels registry: 1816 * Re-auth usage label "EAP Re-authentication Root Key@ietf.org", 1817 documented in this document in Section 4.1. 1819 * DSRK-authorized delivery key "DSRK Delivery Authorized 1820 Key@ietf.org", documented in this document in the description 1821 of "Authorization Indication" in Section 5.3.3. 1823 10. Contributors 1825 Barry Leiba contributed all of the text in Section 9 and, as 1826 Applications Area Director, insisted upon its inclusion as a 1827 condition of publication. 1829 11. Acknowledgements 1831 This document is largely based upon RFC 5296; thanks to all who 1832 partipated in that effort (see Appendix A). In addition, thanks to 1833 Yaron Sheffer, Sebastien Decugis, Ralph Droms, Stephen Farrel, 1834 Charlie Kaufman and Yoav Nir for (mostly) useful comments and review. 1836 12. References 1838 12.1. Normative References 1840 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1841 Hashing for Message Authentication", RFC 2104, 1842 February 1997. 1844 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1845 Requirement Levels", BCP 14, RFC 2119, March 1997. 1847 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1848 Levkowetz, "Extensible Authentication Protocol (EAP)", 1849 RFC 3748, June 2004. 1851 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1852 Network Access Identifier", RFC 4282, December 2005. 1854 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 1855 "Specification for the Derivation of Root Keys from an 1856 Extended Master Session Key (EMSK)", RFC 5295, 1857 August 2008. 1859 12.2. Informative References 1861 [I-D.ietf-dime-erp] 1862 Decugis, S., Morand, L., Wu, W., Bournelle, J., and G. 1863 Zorn, "Diameter Support for the EAP Re-authentication 1864 Protocol (ERP)", draft-ietf-dime-erp-09 (work in 1865 progress), February 2012. 1867 [I-D.nir-ipsecme-erx] 1868 Nir, Y. and W. Wu, "An IKEv2 Extension for Supporting 1869 ERP", draft-nir-ipsecme-erx-03 (work in progress), 1870 April 2012. 1872 [IANA] "Internet Assigned Numbers Authority", 1873 . 1875 [IEEE_802.1X] 1876 Institute of Electrical and Electronics Engineers, "IEEE 1877 Standards for Local and Metropolitan Area Networks: Port 1878 based Network Access Control, IEEE Std 802.1X-2004", 1879 December 2004. 1881 [MSKHierarchy] 1882 Lopez, R., Skarmeta, A., Bournelle, J., Laurent- 1883 Maknavicus, M., and J. Combes, "Improved EAP keying 1884 framework for a secure mobility access service", 1885 IWCMC '06, Proceedings of the 2006 International 1886 Conference on Wireless Communications and Mobile 1887 Computing, New York, NY, USA, 2006. 1889 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1890 "Remote Authentication Dial In User Service (RADIUS)", 1891 RFC 2865, June 2000. 1893 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1894 RFC 3162, August 2001. 1896 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1897 Protocol Method for 3rd Generation Authentication and Key 1898 Agreement (EAP-AKA)", RFC 4187, January 2006. 1900 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1901 Authorization, and Accounting (AAA) Key Management", 1902 BCP 132, RFC 4962, July 2007. 1904 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 1905 "Handover Key Management and Re-Authentication Problem 1906 Statement", RFC 5169, March 2008. 1908 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1909 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1910 May 2008. 1912 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 1913 authentication Protocol (ERP)", RFC 5296, August 2008. 1915 [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of 1916 EAP-Based Keys for Handover and Re-Authentication", 1917 RFC 5749, March 2010. 1919 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1920 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1921 RFC 5996, September 2010. 1923 [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication 1924 Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, 1925 December 2011. 1927 Appendix A. RFC 5296 Acknowledgments 1929 In writing this document, we benefited from discussing the problem 1930 space and the protocol itself with a number of folks including 1931 Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, 1932 Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, 1933 Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi 1934 Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of 1935 the HOKEY working group. The credit for the idea to use EAP- 1936 Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- 1937 layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin 1938 Hoeper suggested the use of the windowing technique to handle 1939 multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for 1940 the suggestion to use hexadecimal encoding for rIKname when sent as 1941 part of keyName-NAI field. Thanks to Bernard Aboba for suggestions 1942 in clarifying the EAP lock-step operation, and Joe Salowey and Glen 1943 Zorn for help in specifying AAA transport of ERP messages. Thanks to 1944 Sam Hartman for the DSRK Authorization Indication mechanism. 1946 Appendix B. Sample ERP Exchange 1947 0. Authenticator --> Peer: 1948 EAP-Initiate/Re-auth-Start [Optional] 1950 1. Peer --> Authenticator: 1951 EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, 1952 Auth-tag*) 1954 1a. Authenticator --> Re-auth-Server: 1955 AAA-Request 1956 { 1957 Authenticator-Id, 1958 EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, 1959 Auth-tag*) 1960 } 1962 2. ER-Server --> Authenticator: 1963 AAA-Response 1964 { 1965 rMSK, 1966 EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], 1967 Auth-tag*) 1968 } 1970 2b. Authenticator --> Peer: 1971 EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], 1972 Auth-tag*) 1974 * Auth-tag computation is over the entire EAP Initiate/Finish message; 1975 the code values for Initiate and Finish are different and thus 1976 reflection attacks are mitigated. 1978 Authors' Addresses 1980 Zhen Cao 1981 China Mobile 1982 53A Xibianmennei Ave., Xuanwu District 1983 Beijing, Beijing 100053 1984 P.R. China 1986 Email: caozhen@chinamobile.com 1987 Baohong He 1988 China Academy of Telecommunication Research 1989 China 1991 Email: hebaohong@catr.cn 1993 Yang Shi 1994 Huawei Technologies Co., Ltd. 1995 156, Beiqing Road, Zhongguancun, Haidian District 1996 Beijing 1997 P.R. China 1999 Phone: +86 10 60614043 2000 Email: shiyang1@huawei.com 2002 Qin Wu (editor) 2003 Huawei Technologies Co., Ltd. 2004 101 Software Avenue, Yuhua District 2005 Nanjing, JiangSu 210012 2006 China 2008 Email: Sunseawq@huawei.com 2010 Glen Zorn (editor) 2011 Network Zen 2012 227/358 Thanon Sanphawut 2013 Bang Na, Bangkok 10260 2014 Thailand 2016 Phone: +66 (0) 87-0404617 2017 Email: glenzorn@gmail.com