idnits 2.17.1 draft-ietf-hokey-rfc5296bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5296, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2010) is 4937 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 406, 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-04 == Outdated reference: A later version (-14) exists of draft-ietf-dime-local-keytran-07 == Outdated reference: A later version (-10) exists of draft-ietf-hokey-ldn-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) 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 Q. Wu, Ed. 3 Internet-Draft Huawei 4 Obsoletes: 5296 (if approved) Z. Cao 5 Intended status: Standards Track China Mobile 6 Expires: April 23, 2011 Y. Shi 7 H3C 8 B. He 9 CATR 10 October 20, 2010 12 EAP Extensions for EAP Re-authentication Protocol (ERP) 13 draft-ietf-hokey-rfc5296bis-01 15 Abstract 17 The Extensible Authentication Protocol (EAP) is a generic framework 18 supporting multiple types of authentication methods. In systems 19 where EAP is used for authentication, it is desirable to not repeat 20 the entire EAP exchange with another authenticator. This document 21 specifies extensions to EAP and the EAP keying hierarchy to support 22 an EAP method-independent protocol for efficient re-authentication 23 between the peer and an EAP re-authentication server through any 24 authenticator. The re-authentication server may be in the home 25 network or in the local network to which the peer is connecting. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 23, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 9 77 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10 78 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 80 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 81 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 82 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 83 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 84 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 85 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 86 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 87 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 88 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 89 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 90 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 91 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 92 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 93 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 94 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 95 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26 96 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 97 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 98 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 99 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 100 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 101 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 34 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 105 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 106 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 107 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 108 A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 109 A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 110 Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 113 1. Introduction 115 The Extensible Authentication Protocol (EAP) is a an authentication 116 framework that supports multiple authentication methods. The primary 117 purpose is network access authentication, and a key-generating method 118 is used when the lower layer wants to enforce access control. The 119 EAP keying hierarchy defines two keys to be derived by all key- 120 generating EAP methods: the Master Session Key (MSK) and the Extended 121 MSK (EMSK). In the most common deployment scenario, an EAP peer and 122 an EAP server authenticate each other through a third party known as 123 the EAP authenticator. The EAP authenticator or an entity controlled 124 by the EAP authenticator enforces access control. After successful 125 authentication, the EAP server transports the MSK to the EAP 126 authenticator; the EAP authenticator and the EAP peer establish 127 transient session keys (TSKs) using the MSK as the authentication 128 key, key derivation key, or a key transport key, and use the TSK for 129 per-packet access enforcement. 131 When a peer moves from one authenticator to another, it is desirable 132 to avoid a full EAP authentication to support fast handovers. The 133 full EAP exchange with another run of the EAP method can take several 134 round trips and significant time to complete, causing delays in 135 handover times. Some EAP methods specify the use of state from the 136 initial authentication to optimize re-authentications by reducing the 137 computational overhead, but method-specific re-authentication takes 138 at least 2 round trips with the original EAP server in most cases 139 (e.g., [RFC4187]). It is also important to note that several methods 140 do not offer support for re-authentication. 142 Key sharing across authenticators is sometimes used as a practical 143 solution to lower handover times. In that case, compromise of an 144 authenticator results in compromise of keying material established 145 via other authenticators. Other solutions for fast re-authentication 146 exist in the literature [MSKHierarchy]. 148 In conclusion, to achieve low latency handovers, there is a need for 149 a method-independent re-authentication protocol that completes in 150 less than 2 round trips, preferably with a local server. The EAP re- 151 authentication problem statement is described in detail in [RFC5169]. 153 This document specifies EAP Re-authentication Extensions (ERXs) for 154 efficient re-authentication using EAP. The protocol that uses these 155 extensions is itself referred to as the EAP Re-authentication 156 Protocol (ERP). It supports EAP method-independent re-authentication 157 for a peer that has valid, unexpired key material from a previously 158 performed EAP authentication. The protocol and the key hierarchy 159 required for EAP re-authentication are described in this document. 161 Note that to support ERP, lower-layer specifications may need to be 162 revised to allow carrying EAP messages that have a code value higher 163 than 4 and to accommodate the peer-initiated nature of ERP. 164 Specifically, the IEEE802.1x specification must be revised and RFC 165 4306 must be updated to carry ERP messages. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 This document uses the basic EAP terminology [RFC3748] and EMSK 174 keying hierarchy terminology [RFC5295]. In addition, this document 175 uses the following terms: 177 ER Peer - An EAP peer that supports the EAP Re-authentication 178 Protocol. All references to "peer" in this document imply an ER 179 peer, unless specifically noted otherwise. 181 ER Authenticator - An entity that supports the authenticator 182 functionality for EAP re-authentication described in this 183 document. All references to "authenticator" in this document 184 imply an ER authenticator, unless specifically noted otherwise. 186 ER Server - An entity that performs the server portion of ERP 187 described here. This entity may or may not be an EAP server. All 188 references to "server" in this document imply an ER server, unless 189 specifically noted otherwise. An ER server is a logical entity; 190 it may not necessarily be co-located with, or physically part of, 191 a full EAP server. 193 ERX - EAP re-authentication extensions. 195 ERP - EAP Re-authentication Protocol that uses the re- 196 authentication extensions. 198 rRK - re-authentication Root Key, derived from the EMSK or DSRK. 200 rIK - re-authentication Integrity Key, derived from the rRK. 202 rMSK - re-authentication MSK. This is a per-authenticator key, 203 derived from the rRK. 205 keyName-NAI - ERP messages are integrity protected with the rIK or 206 the DS-rIK. The use of rIK or DS-rIK for integrity protection of 207 ERP messages is indicated by the EMSKname [RFC5295]; the protocol, 208 which is ERP; and the realm, which indicates the domain name of 209 the ER server. The EMSKname is copied into the username part of 210 the NAI. 212 Domain - Refers to a "key management domain" as defined in 213 [RFC5295]. For simplicity, it is referred to as "domain" in this 214 document. The terms "home domain" and "local domain" are used to 215 differentiate between the originating key management domain that 216 performs the full EAP exchange with the peer and the local domain 217 to which a peer may be attached at a given time. 219 3. ERP Description 221 ERP allows a peer and server to mutually verify proof of possession 222 of keying material from an earlier EAP method run and to establish a 223 security association between the peer and the authenticator. The 224 authenticator acts as a pass-through entity for the Re-authentication 225 Protocol in a manner similar to that of an EAP authenticator 226 described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange 227 between the peer and the server; it is independent of the lower layer 228 and the EAP method used during the full EAP exchange. The ER server 229 may be in the home domain or in the same (visited) domain as the peer 230 and the authenticator (i.e.,local domain). 232 Figure 2 shows the protocol exchange. The first time the peer 233 attaches to any network, it performs a full EAP exchange (shown in 234 Figure 1) with the EAP server; as a result, an MSK is distributed to 235 the EAP authenticator. The MSK is then used by the authenticator and 236 the peer to establish TSKs as needed. At the time of the initial EAP 237 exchange, the peer and the server also derive an EMSK, which is used 238 to derive a re-authentication Root Key (rRK). More precisely, a re- 239 authentication Root Key is derived from the EMSK or from a Domain- 240 Specific Root Key (DSRK), which is itself derived from the EMSK. The 241 rRK is only available to the peer and the ER server and is never 242 handed out to any other entity. Further, a re-authentication 243 Integrity Key (rIK) is derived from the rRK; the peer and the ER 244 server use the rIK to provide proof of possession while performing an 245 ERP exchange. The rIK is also never handed out to any entity and is 246 only available to the peer and server. 248 EAP Peer EAP Authenticator EAP Server 249 ======== ================= ========== 251 <--- EAP-Request/ ------ 252 Identity 254 ----- EAP Response/ ---> 255 Identity ---AAA(EAP Response/Identity)--> 257 <--- EAP Method -------> <------ AAA(EAP Method --------> 258 exchange exchange) 260 <----AAA(MSK, EAP-Success)------ 262 <---EAP-Success--------- 264 Figure 1: EAP Authentication 266 Peer ER Authenticator ER Server 267 ==== ============= ====== 269 [<-- EAP-Initiate/ ----- 270 Re-auth-Start] 271 [<-- EAP-Request/ ------ 272 Identity] 274 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 275 Re-auth/ Re-auth/ 276 [Bootstrap] [Bootstrap]) 278 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 279 Re-auth/ Re-auth/ 280 [Bootstrap] [Bootstrap]) 282 Note: [] brackets indicate optionality. 284 Figure 2: ERP Exchange 286 Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this 287 document for the purpose of EAP re-authentication. When the peer 288 identifies a target authenticator that supports EAP re- 289 authentication, it performs an ERP exchange, as shown in Figure 2; 290 the exchange itself may happen when the peer attaches to a new 291 authenticator supporting EAP re-authentication, or prior to 292 attachment. The peer initiates ERP by itself; it may also do so in 293 response to an EAP-Initiate/Re-auth-Start message from the new 294 authenticator. The EAP-Initiate/Re-auth-Start message allows the 295 authenticator to trigger the ERP exchange. The EAP-Finish message 296 also can be used by the authenticator to announce local domain name. 298 It is plausible that the authenticator does not know whether the peer 299 supports ERP and whether the peer has performed a full EAP 300 authentication through another authenticator. The authenticator MAY 301 initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start 302 message, and if there is no response, it will send the EAP-Request/ 303 Identity message. Note that this avoids having two EAP messages in 304 flight at the same time [RFC3748]. The authenticator may send the 305 EAP-Initiate/Re-auth-Start message and wait for a short, locally 306 configured amount of time. If the peer does not already know, this 307 message indicates to the peer that the authenticator supports ERP. 308 In response to this trigger from the authenticator, the peer can 309 initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. 310 If there is no response from the peer after the necessary 311 retransmissions (see Section 6), the authenticator MUST initiate EAP 312 by sending an EAP-Request message, typically the EAP-Request/Identity 313 message. Note that the authenticator may receive an EAP-Initiate/ 314 Re-auth message after it has sent an EAP-Request/Identity message. 315 If the authenticator supports ERP, it MUST proceed with the ERP 316 exchange. When the EAP-Request/Identity times out, the authenticator 317 MUST NOT close the connection if an ERP exchange is in progress or 318 has already succeeded in establishing a re-authentication MSK. 320 If the authenticator does not support ERP, it drops EAP-Initiate/ 321 Re-auth messages [RFC3748] as the EAP code of those packets is 322 greater than 4. An ERP-capable peer will exhaust the EAP-Initiate/ 323 Re-auth message retransmissions and fall back to EAP authentication 324 by responding to EAP Request/Identity messages from the 325 authenticator. If the peer does not support ERP or if it does not 326 have unexpired key material from a previous EAP authentication, it 327 drops EAP-Initiate/Re-auth-Start messages. If there is no response 328 to the EAP-Initiate/Re-auth-Start message, the authenticator SHALL 329 send an EAP Request message (typically EAP Request/Identity) to start 330 EAP authentication. From this stage onwards, RFC 3748 rules apply. 331 Note that this may introduce some delay in starting EAP. In some 332 lower layers, the delay can be minimized or even avoided by the peer 333 initiating EAP by sending messages such as EAPoL-Start in the IEEE 334 802.1X specification [IEEE_802.1X]. 336 The peer sends an EAP-Initiate/Re-auth message that contains the 337 keyName-NAI to identify the ER server's domain and the rIK used to 338 protect the message, and a sequence number for replay protection. 340 The EAP-Initiate/Re-auth message is integrity protected with the rIK. 341 The authenticator uses the realm in the keyName-NAI [RFC4282] field 342 to send the message to the appropriate ER server. The server uses 343 the keyName to look up the rIK. The server, after verifying proof of 344 possession of the rIK, and freshness of the message, derives a re- 345 authentication MSK (rMSK) from the rRK using the sequence number as 346 an input to the key derivation. The server updates the expected 347 sequence number to the received sequence number plus one. 349 In response to the EAP-Initiate/Re-auth message, the server sends an 350 EAP-Finish/Re-auth message; this message is integrity protected with 351 the rIK. The server transports the rMSK along with this message to 352 the authenticator. The rMSK is transported in a manner similar to 353 that of the MSK along with the EAP-Success message in a full EAP 354 exchange. Ongoing work in [RFC5749] describes an additional key 355 distribution protocol that can be used to transport the rRK from an 356 EAP server to one of many different ER servers that share a trust 357 relationship with the EAP server. 359 The peer MAY request the server for the rMSK lifetime. If so, the ER 360 server sends the rMSK lifetime in the EAP-Finish/Re-auth message. 362 In an ERP bootstrap exchange, the peer MAY request the server for the 363 rRK lifetime. If so, the ER server sends the rRK lifetime in the 364 EAP-Finish/Re-auth message. 366 The peer verifies the replay protection and the integrity of the 367 message. It then uses the sequence number in the EAP-Finish/Re-auth 368 message to compute the rMSK. The lower-layer security association 369 protocol is ready to be triggered after this point. 371 When the ER server is in the home domain, the peer and the server use 372 the rIK and rRK derived from the EMSK; and when the ER server is in 373 the local domain, they use the DS-rIK and DS-rRK corresponding to the 374 local domain. The domain of the ER server is identified by the realm 375 portion of the keyname-NAI in ERP messages. 377 3.1. ERP With the Home ER Server 379 If the peer is in the home domain and does not know the domain name ( 380 did not receive the domain name through the EAP-Initiate/ 381 Re-auth-Start message or via the lower-layer announcement, due to a 382 missed announcement or lack of support for domain name announcements 383 in a specific lower layer) or there is no the local server in the 384 same domain as the peer, it SHOULD initiate ERP bootstrap exchange 385 with the home ER server to obtain the domain name. 387 The defined ER extensions allow executing the ERP with an ER server 388 in the home domain. The home ER server may be co- located with a 389 home AAA server. The ERP with the Home ER Server is the similar as 390 ERP exchange described in Figure 2. 392 Peer ER Authenticator Home ER Server 393 ==== ============= ====== 395 [<-- EAP-Initiate/ ----- 396 Re-auth-Start] 397 [<-- EAP-Request/ ------ 398 Identity] 400 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 401 Re-auth/ Re-auth/ 402 [Bootstrap] [Bootstrap]) 404 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 405 Re-auth/ Re-auth/ 406 [Bootstrap] [Bootstrap]) 408 Note: [] brackets indicate optionality. 410 Figure 3: ER ExplicitBootstrapping Exchange/ERP with the Home ER 411 Sever 413 3.2. ERP with a Local ER Server 415 The defined ER extensions allow executing the ERP with an ER server 416 in the local domain (access network) if the peer moves out of home 417 domain. The local ER server may be co-located with a local AAA 418 server. The peer may learn about the presence of a local ER server 419 in the network and the local domain name (or ER server name) either 420 via the lower layer or by means of ERP exchange. The peer uses the 421 domain name and the EMSK to compute the DSRK and from that key, the 422 DS-rRK; the peer also uses the domain name in the realm portion of 423 the keyName-NAI for using ERP in the local domain. Figure 4 shows 424 the ER Implicit bootstrapping exchange through local ER 425 Server;Figure 5shows ERP with a local ER server. 427 Peer EAP Authenticator Local AAA Agent Home EAP Server 428 /ER Authenticator /Local ER Server 429 ==== ================= =============== =============== 431 <-- EAP-Request/ -- 432 Identity 434 -- EAP Response/--> 435 Identity --AAA(EAP Response/--> 436 Identity, --AAA(EAP Response/ --> 437 [domain name]) Identity, 438 [DSRK Request, 439 domain name]) 441 <------------------------ EAP Method exchange------------------> 443 <---AAA(MSK, DSRK, ---- 444 EMSKname, 445 EAP-Success) 447 <--- AAA(MSK, ----- 448 EAP-Success) 450 <---EAP-Success----- 452 Figure 4: Local ERP Exchange, Initial EAP Exchange 454 Peer ER Authenticator Local ER Server 455 ==== ================ =============== 457 [<-- EAP-Initiate/ -------- 458 Re-auth-Start] 459 [<-- EAP-Request/ --------- 460 Identity] 462 ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> 463 Re-auth Re-auth) 465 <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- 466 Re-auth Re-auth) 467 Figure 5: Local ERP Exchange 469 As shown in Figure 4, the local ER server may be present in the path 470 of the full EAP exchange (e.g., this may be one of the AAA entities, 471 such as AAA proxies, in the path between the EAP authenticator and 472 the home EAP server of the peer). In that case, the local ER server 473 requests the DSRK by sending the domain name to the home EAP server 474 through AAA message. In response, the home EAP server computes the 475 DSRK by following the procedure specified in [RFC5295] and sends the 476 DSRK and the key name, EMSKname, to the ER server in the claimed 477 domain (i.e., local ER Server). The local domain is responsible for 478 announcing that same domain name via the lower layer to the peer, 479 e.g., DHCP based local domain name discovery specified in 480 [I-D.ietf-hokey-ldn-discovery], or through the EAP-Initiate/ 481 Re-auth-Start message during subsequent ERP with local ER server. 483 After receiving the DSRK and the EMSKname, the local ER server 484 computes the DS-rRK and the DS-rIK from the DSRK as defined in 485 Sections 4.1 and 4.3 below. After receiving the domain name, the 486 peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys 487 are referred to by a keyName-NAI formed as follows: the username part 488 of the NAI is the EMSKname, the realm portion of the NAI is the 489 domain name. Both parties also maintain a sequence number 490 (initialized to zero) corresponding to the specific keyName-NAI. 492 Subsequently, when the peer attaches to an authenticator within the 493 local domain, it may perform an ERP exchange with the local ER server 494 to obtain an rMSK for the new authenticator. The ERP with the local 495 ER Server is the similar as ERP exchange described in Figure 2. 497 4. ER Key Hierarchy 499 Each time the peer re-authenticates to the network, the peer and the 500 authenticator establish an rMSK. The rMSK serves the same purposes 501 that an MSK, which is the result of full EAP authentication, serves. 502 To prove possession of the rRK, we specify the derivation of another 503 key, the rIK. These keys are derived from the rRK. Together they 504 constitute the ER key hierarchy. 506 The rRK is derived from either the EMSK or a DSRK as specified in 507 Section 4.1. For the purpose of rRK derivation, this document 508 specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- 509 Specific USRK (DSUSRK) in accordance with [RFC5295] for re- 510 authentication. The USRK designated for re-authentication is the re- 511 authentication root key (rRK). A DSUSRK designated for re- 512 authentication is the DS-rRK available to a local ER server in a 513 particular domain. For simplicity, the keys are referred to without 514 the DS label in the rest of the document. However, the scope of the 515 various keys is limited to just the respective domains they are 516 derived for, in the case of the domain specific keys. Based on the 517 ER server with which the peer performs the ERP exchange, it knows the 518 corresponding keys that must be used. 520 The rRK is used to derive an rIK, and rMSKs for one or more 521 authenticators. The figure below shows the key hierarchy with the 522 rRK, rIK, and rMSKs. 524 rRK 525 | 526 +--------+--------+ 527 | | | 528 rIK rMSK1 ...rMSKn 530 Figure 6: Re-authentication Key Hierarchy 532 The derivations in this document are according to [RFC5295]. Key 533 derivations and field encodings, where unspecified, default to that 534 document. 536 4.1. rRK Derivation 538 The rRK may be derived from the EMSK or DSRK. This section provides 539 the relevant key derivations for that purpose. 541 The rRK is derived as specified in [RFC5295]. 543 rRK = KDF (K, S), where 545 K = EMSK or K = DSRK and 547 S = rRK Label | "\0" | length 549 The rRK Label is an IANA-assigned 8-bit ASCII string: 551 EAP Re-authentication Root Key@ietf.org 553 assigned from the "USRK key labels" name space in accordance with 554 [RFC5295]. 556 The KDF and algorithm agility for the KDF are as defined in 557 [RFC5295]. 559 An rRK derived from the DSRK is referred to as a DS-rRK in the rest 560 of the document. All the key derivation and properties specified in 561 this section remain the same. 563 4.2. rRK Properties 565 The rRK has the following properties. These properties apply to the 566 rRK regardless of the parent key used to derive it. 568 o The length of the rRK MUST be equal to the length of the parent 569 key used to derive it. 571 o The rRK is to be used only as a root key for re-authentication and 572 never used to directly protect any data. 574 o The rRK is only used for derivation of rIK and rMSK as specified 575 in this document. 577 o The rRK MUST remain on the peer and the server that derived it and 578 MUST NOT be transported to any other entity. 580 o The lifetime of the rRK is never greater than that of its parent 581 key. The rRK is expired when the parent key expires and MUST be 582 removed from use at that time. 584 4.3. rIK Derivation 586 The re-authentication Integrity Key (rIK) is used for integrity 587 protecting the ERP exchange. This serves as the proof of possession 588 of valid keying material from a previous full EAP exchange by the 589 peer to the server. 591 The rIK is derived as follows. 593 rIK = KDF (K, S), where 595 K = rRK and 597 S = rIK Label | "\0" | cryptosuite | length 599 The rIK Label is the 8-bit ASCII string: 601 Re-authentication Integrity Key@ietf.org 603 The length field refers to the length of the rIK in octets encoded as 604 specified in [RFC5295]. 606 The cryptosuite and length of the rIK are part of the input to the 607 key derivation function to ensure cryptographic separation of keys if 608 different rIKs of different lengths for use with different Message 609 Authentication Code (MAC) algorithms are derived from the same rRK. 610 The cryptosuite is encoded as an 8-bit number; see Section 5.3.2 for 611 the cryptosuite specification. 613 The rIK is referred to by EMSKname-NAI within the context of ERP 614 messages. The username part of EMSKname-NAI is the EMSKname; the 615 realm is the domain name of the ER server. In case of ERP with the 616 home ER server, the peer uses the realm from its original NAI; in 617 case of a local ER server, the peer uses the domain name received at 618 the lower layer or through an ERP bootstrapping exchange. 620 An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest 621 of the document. All the key derivation and properties specified in 622 this section remain the same. 624 4.4. rIK Properties 626 The rIK has the following properties. 628 o The length of the rIK MUST be equal to the length of the rRK. 630 o The rIK is only used for authentication of the ERP exchange as 631 specified in this document. 633 o The rIK MUST NOT be used to derive any other keys. 635 o The rIK must remain on the peer and the server and MUST NOT be 636 transported to any other entity. 638 o The rIK is cryptographically separate from any other keys derived 639 from the rRK. 641 o The lifetime of the rIK is never greater than that of its parent 642 key. The rIK MUST be expired when the EMSK expires and MUST be 643 removed from use at that time. 645 4.5. rIK Usage 647 The rIK is the key whose possession is demonstrated by the peer and 648 the ERP server to the other party. The peer demonstrates possession 649 of the rIK by computing the integrity checksum over the EAP-Initiate/ 650 Re-auth message. When the peer uses the rIK for the first time, it 651 can choose the integrity algorithm to use with the rIK. The peer and 652 the server MUST use the same integrity algorithm with a given rIK for 653 all ERP messages protected with that key. The peer and the server 654 store the algorithm information after the first use, and they employ 655 the same algorithm for all subsequent uses of that rIK. 657 If the server's policy does not allow the use of the cryptosuite 658 selected by the peer, the server SHALL reject the EAP-Initiate/ 659 Re-auth message and SHOULD send a list of acceptable cryptosuites in 660 the EAP-Finish/Re-auth message. 662 The rIK length may be different from the key length required by an 663 integrity algorithm. In case of hash-based MAC algorithms, the key 664 is first hashed to the required key length as specified in [RFC2104]. 665 In case of cipher-based MAC algorithms, if the required key length is 666 less than 32 octets, the rIK is hashed using HMAC-SHA256 and the 667 first k octets of the output are used, where k is the key length 668 required by the algorithm. If the required key length is more than 669 32 octets, the first k octets of the rIK are used by the cipher-based 670 MAC algorithm. 672 4.6. rMSK Derivation 674 The rMSK is derived at the peer and server and delivered to the 675 authenticator. The rMSK is derived following an EAP Re-auth Protocol 676 exchange. 678 The rMSK is derived as follows. 680 rMSK = KDF (K, S), where 682 K = rRK and 684 S = rMSK label | "\0" | SEQ | length 686 The rMSK label is the 8-bit ASCII string: 688 Re-authentication Master Session Key@ietf.org 690 The length field refers to the length of the rMSK in octets. The 691 length field is encoded as specified in [RFC5295]. 693 SEQ is the sequence number sent by the peer in the EAP-Initiate/ 694 Re-auth message. This field is encoded as a 16-bit number in network 695 byte order (see Section 5.3.2). 697 An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest 698 of the document. All the key derivation and properties specified in 699 this section remain the same. 701 4.7. rMSK Properties 703 The rMSK has the following properties: 705 o The length of the rMSK MUST be equal to the length of the rRK. 707 o The rMSK is delivered to the authenticator and is used for the 708 same purposes that an MSK is used at an authenticator. 710 o The rMSK is cryptographically separate from any other keys derived 711 from the rRK. 713 o The lifetime of the rMSK is less than or equal to that of the rRK. 714 It MUST NOT be greater than the lifetime of the rRK. 716 o If a new rRK is derived, subsequent rMSKs MUST be derived from the 717 new rRK. Previously delivered rMSKs MAY still be used until the 718 expiry of the lifetime. 720 o A given rMSK MUST NOT be shared by multiple authenticators. 722 5. Protocol Details 724 5.1. ERP Bootstrapping 726 We identify two types of bootstrapping for ERP: explicit and implicit 727 bootstrapping. In implicit bootstrapping, the local AAA client or 728 agent supporting EAP re-authentication SHOULD include its domain name 729 and SHOULD request the DSRK from the home AAA server during the 730 initial EAP exchange, in the AAA message encapsulating the first EAP 731 Response message sent by the peer. If such EAP exchange is 732 successful, the home EAP server sends the DSRK for the specified 733 local AAA client or agent (derived using the EMSK and the domain name 734 as specified in [RFC5295]), EMSKname, and DSRK lifetime along with 735 the EAP-Success message. The local AAA client or agent MUST extract 736 the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding 737 the EAP-Success message to the peer, as specified in 738 [I-D.ietf-dime-erp]. Note that the MSK (also present along with the 739 EAP Success message) is extracted by the EAP authenticator as usual. 740 The peer learns the domain name through the EAP-Initiate/ 741 Re-auth-Start message, lower-layer announcements 742 [I-D.ietf-hokey-ldn-discovery] or via ER Explicit bootstrapping 743 exchange. When the domain name is available to the peer during or 744 after the full EAP authentication, it attempts to use ERP when it 745 associates with a new authenticator. 747 If the peer does not know the domain name (did not receive the domain 748 name through the EAP-Initiate/Re-auth-Start message or via the lower- 749 layer announcement, due to a missed announcement or lack of support 750 for domain name announcements in a specific lower layer), it SHOULD 751 initiate Explicit ER bootstrap exchange (ERP exchange with the 752 bootstrap flag turned on) with the ER server in the same (visited) 753 domain as the peer to obtain the local domain name. The peer MAY 754 also initiate bootstrapping to fetch information such as the rRK 755 lifetime from the AAA server. 757 The following steps describe the ERP explicit bootstrapping process: 759 o The peer sends the EAP-Initiate/Re-auth message with the 760 bootstrapping flag turned on. The bootstrap message is always 761 sent to the ER server, and the keyname-NAI attribute in the 762 bootstrap message is constructed as follows: the username portion 763 of the NAI contains the EMSKname, and the realm portion contains 764 the home domain name. 766 o In addition, the message MUST contain a sequence number for replay 767 protection, a cryptosuite, and an integrity checksum. The 768 cryptosuite indicates the authentication algorithm. The integrity 769 checksum indicates that the message originated at the claimed 770 entity, the peer indicated by the Peer-ID, or the rIKname. 772 o The peer MAY additionally set the lifetime flag to request the key 773 lifetimes. 775 o When an ERP-capable authenticator receives the EAP-Initiate/ 776 Re-auth message from a peer, it copies the contents of the 777 keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The 778 rest of the process is similar to that described in [RFC3579]. 780 o Upon receipt of an EAP-Initiate/Re-auth message, the server 781 verifies whether the message is fresh or is a replay by evaluating 782 whether the received sequence number is equal to or greater than 783 the expected sequence number for that rIK. The server then 784 verifies to ensure that the cryptosuite used by the peer is 785 acceptable. Next, it verifies the origin authentication of the 786 message by looking up the rIK. If any of the checks fail, the 787 server sends an EAP-Finish/Re-auth message with the Result flag 788 set to '1'. Please refer to Section 5.2.2 for details on failure 789 handling. This error MUST NOT have any correlation to any EAP- 790 Success message that may have been received by the EAP 791 authenticator and the peer earlier. If the EAP-Initiate/Re-auth 792 message is well-formed and valid, the server prepares the EAP- 793 Finish/Re-auth message. The bootstrap flag MUST be set to 794 indicate that this is a bootstrapping exchange. The message 795 contains the following fields: 797 * A sequence number for replay protection. 799 * The same keyName-NAI as in the EAP-Initiate/Re-auth message. 801 * If the lifetime flag was set in the EAP-Initiate/Re-auth 802 message, the ER server SHOULD include the rRK lifetime and the 803 rMSK lifetime in the EAP-Finish/Re-auth message. The server 804 may have a local policy for the network to maintain and enforce 805 lifetime unilaterally. In such cases, the server need not 806 respond to the peer's request for the lifetime. 808 * If the bootstrap flag is set, the ER server MUST include the 809 domain name to which the DSRK is being sent along with the EAP- 810 Finish/Re-auth message. 812 * If the ER server verifies the authorization of a local domain 813 server, it MAY include the Authorization Indication TLV to 814 indicate to the peer that the server (that received the DSRK 815 and that is advertising the domain included in the domain name 816 TLV) is authorized. 818 * An authentication tag MUST be included to prove that the EAP- 819 Finish/Re-auth message originates at a server that possesses 820 the rIK corresponding to the EMSKname-NAI. 822 o If the ERP exchange is successful, the ER server SHOULD request 823 the DSRK from the home EAP server during the initial EAP exchange 824 as specified in [I-D.ietf-dime-local-keytran], the home EAP server 825 MUST include the DSRK for the local ER server (derived using the 826 EMSK and the domain name as specified in [RFC5295]), EMSKname, and 827 DSRK lifetime along with the EAP-Finish/Re-auth message. 829 o In addition, the rMSK is sent along with the EAP-Finish/Re-auth 830 message, in a AAA attribute [I-D.ietf-dime-erp]. 832 o The ER server MUST extract the DSRK, EMSKname, and DSRK lifetime 833 (if present) before forwarding the EAP-Success message to the 834 peer, as specified in [I-D.ietf-dime-erp]. 836 o The authenticator receives the rMSK. 838 o When the peer receives an EAP-Finish/Re-auth message with the 839 bootstrap flag set, if a local domain name is present, it MUST use 840 that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- 841 NAI, and initialize the replay counter for the DS-rIK. If not, 842 the peer SHOULD derive the domain-specific keys using the domain 843 name it learned via the lower layer or from the EAP-Initiate/ 844 Re-auth-Start message. If the peer does not know the domain name, 845 it must assume that there is no local ER server available. 847 o The peer MAY also verify the Authorization Indication TLV. 849 o The procedures for encapsulating the ERP and obtaining relevant 850 keys using Diameter are specified in [I-D.ietf-dime-erp]. 852 Since the ER bootstrapping exchange is typically done immediately 853 following the full EAP exchange, it is feasible that the process is 854 completed through the same entity that served as the EAP 855 authenticator for the full EAP exchange. In this case, the lower 856 layer may already have established TSKs based on the MSK received 857 earlier. The lower layer may then choose to ignore the rMSK that was 858 received with the ER bootstrapping exchange. Alternatively, the 859 lower layer may choose to establish a new TSK using the rMSK. In 860 either case, the authenticator and the peer know which key is used 861 based on whether or not a TSK establishment exchange is initiated. 862 The bootstrapping exchange may also be carried out via a new 863 authenticator, in which case, the rMSK received SHOULD trigger a 864 lower layer TSK establishment exchange. 866 5.2. Steps in ERP 868 When a peer that has an active rRK and rIK associates with a new 869 authenticator that supports ERP, it may perform an ERP exchange with 870 that authenticator. ERP is typically a peer-initiated exchange, 871 consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth 872 message. The ERP exchange may be performed with a local ER server 873 (when one is present) or with the original EAP server. 875 It is plausible for the network to trigger the EAP re-authentication 876 process, however. An ERP-capable authenticator SHOULD send an EAP- 877 Initiate/Re-auth-Start message to indicate support for ERP. The peer 878 may or may not wait for these messages to arrive to initiate the EAP- 879 Initiate/Re-auth message. 881 The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- 882 capable authenticator. The authenticator may retransmit it a few 883 times until it receives an EAP-Initiate/Re-auth message in response 884 from the peer. The EAP-Initiate/Re-auth message from the peer may 885 have originated before the peer receives either an EAP-Request/ 886 Identity or an EAP-Initiate/Re-auth-Start message from the 887 authenticator. Hence, the Identifier value in the EAP-Initiate/ 888 Re-auth message is independent of the Identifier value in the EAP- 889 Initiate/Re-auth-Start or the EAP-Request/Identity messages. 891 Operational Considerations at the Peer: 893 ERP requires that the peer maintain retransmission timers for 894 reliable transport of EAP re-authentication messages. The 895 reliability considerations of Section 4.3 of RFC 3748 apply with the 896 peer as the retransmitting entity. 898 The EAP Re-auth Protocol has the following steps: 900 The peer sends an EAP-Initiate/Re-auth message. At a minimum, the 901 message SHALL include the following fields: 903 a 16-bit sequence number for replay protection 905 keyName-NAI as a TLV attribute to identify the rIK used to 906 integrity protect the message. 908 cryptosuite to indicate the authentication algorithm used to 909 compute the integrity checksum. 911 authentication tag over the message. 913 When the peer is performing ERP with a local ER server, it MUST 914 use the corresponding DS-rIK it shares with the local ER server. 915 The peer SHOULD set the lifetime flag to request the key lifetimes 916 from the server. The peer can use the rRK lifetime to know when 917 to trigger an EAP method exchange and the rMSK lifetime to know 918 when to trigger another ERP exchange. 920 The authenticator copies the contents of the value field of the 921 keyName-NAI TLV into the User-Name RADIUS attribute in the AAA 922 message to the ER server. 924 The server uses the keyName-NAI to look up the rIK. It MUST first 925 verify whether the sequence number is equal to or greater than the 926 expected sequence number. If the server supports a sequence 927 number window size greater than 1, it MUST verify whether the 928 sequence number falls within the window and has not been received 929 before. The server MUST then verify to ensure that the 930 cryptosuite used by the peer is acceptable. The server then 931 proceeds to verify the integrity of the message using the rIK, 932 thereby verifying proof of possession of that key by the peer. If 933 any of these verifications fail, the server MUST send an EAP- 934 Finish/Re-auth message with the Result flag set to '1' (Failure). 935 Please refer to Section 5.2.2 for details on failure handling. 936 Otherwise, it MUST compute an rMSK from the rRK using the sequence 937 number as the additional input to the key derivation. 939 In response to a well-formed EAP Re-auth/Initiate message, the 940 server MUST send an EAP-Finish/Re-auth message with the following 941 considerations: 943 a 16-bit sequence number for replay protection, which MUST be 944 the same as the received sequence number. The local copy of 945 the sequence number MUST be incremented by 1. If the server 946 supports multiple simultaneous ERP exchanges, it MUST instead 947 update the sequence number window. 949 keyName-NAI as a TLV attribute to identify the rIK used to 950 integrity protect the message. 952 cryptosuite to indicate the authentication algorithm used to 953 compute the integrity checksum. 955 authentication tag over the message. 957 If the lifetime flag was set in the EAP-Initiate/Re-auth 958 message, the ER server SHOULD include the rRK lifetime and the 959 rMSK lifetime. 961 The server transports the rMSK along with this message to the 962 authenticator. The rMSK is transported in a manner similar to the 963 MSK transport along with the EAP-Success message in a regular EAP 964 exchange. 966 The peer looks up the sequence number to verify whether it is 967 expecting an EAP-Finish/Re-auth message with that sequence number 968 protected by the keyName-NAI. It then verifies the integrity of 969 the message. If the verifications fail, the peer logs an error 970 and stops the process; otherwise, it proceeds to the next step. 972 The peer uses the sequence number to compute the rMSK. 974 The lower-layer security association protocol can be triggered at 975 this point. 977 5.2.1. Multiple Simultaneous Runs of ERP 979 When a peer is within the range of multiple authenticators, it may 980 choose to run ERP via all of them simultaneously to the same ER 981 server. In that case, it is plausible that the ERP messages may 982 arrive out of order, resulting in the ER server rejecting legitimate 983 EAP-Initiate/Re-auth messages. 985 To facilitate such operation, an ER server MAY allow multiple 986 simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth 987 messages with SEQ number values within a window of allowed values. 988 Recall that the SEQ number allows replay protection. Replay window 989 maintenance mechanisms are a local matter. 991 5.2.2. ERP Failure Handling 993 If the processing of the EAP-Initiate/Re-auth message results in a 994 failure, the ER server MUST send an EAP-Finish Re-auth message with 995 the Result flag set to '1'. If the server has a valid rIK for the 996 peer, it MUST integrity protect the EAP-Finish/Re-auth failure 997 message. If the failure is due to an unacceptable cryptosuite, the 998 server SHOULD send a list of acceptable cryptosuites (in a TLV of 999 Type 5) along with the EAP-Finish/Re-auth message. In this case, the 1000 server MUST indicate the cryptosuite used to protect the EAP-Finish/ 1001 Re-auth message in the cryptosuite. The rIK used with the EAP- 1002 Finish/Re-auth message in this case MUST be computed as specified in 1003 Section 4.3 using the new cryptosuite. If the server does not have a 1004 valid rIK for the peer, the EAP-Finish/Re-auth message indicating a 1005 failure will be unauthenticated; the server MAY include a list of 1006 acceptable cryptosuites in the message. 1008 The peer, upon receiving an EAP-Finish/Re-auth message with the 1009 Result flag set to '1', MUST verify the sequence number and the 1010 Authentication Tag to determine the validity of the message. If the 1011 peer supports the cryptosuite, it MUST verify the integrity of the 1012 received EAP-Finish/Re-auth message. If the EAP-Finish message 1013 contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with 1014 a cryptosuite picked from the list included by the server. The peer 1015 MUST use the appropriate rIK for the subsequent ERP exchange, by 1016 computing it with the corresponding cryptosuite, as specified in 1017 Section 4.3. If the PRF in the chosen cryptosuite is different from 1018 the PRF originally used by the peer, it MUST derive a new DSRK (if 1019 required), rRK, and rIK before proceeding with the subsequent ERP 1020 exchange. 1022 If the peer cannot verify the integrity of the received message, it 1023 MAY choose to retry the ERP exchange with one of the cryptosuites in 1024 the TLV of Type 5, after a failure has been clearly determined 1025 following the procedure in the next paragraph. 1027 If the replay or integrity checks fail, the failure message may have 1028 been sent by an attacker. It may also imply that the server and peer 1029 do not support the same cryptosuites; however, the peer cannot 1030 determine if that is the case. Hence, the peer SHOULD continue the 1031 ERP exchange per the retransmission timers before declaring a 1032 failure. 1034 When the peer runs explicit bootstrapping (ERP with the bootstrapping 1035 flag on), there may not be a local ER server available to send a DSRK 1036 Request and the domain name. In that case, the server cannot send 1037 the DSRK and MUST NOT include the domain name TLV. When the peer 1038 receives a response in the bootstrapping exchange without a domain 1039 name TLV, it assumes that there is no local ER server. The home ER 1040 server sends an rMSK to the ER authenticator, however, and the peer 1041 SHALL run the TSK establishment protocol as usual. 1043 5.3. New EAP Packets 1045 Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate 1046 and EAP-Finish. The packet format for these messages follows the EAP 1047 packet format defined in RFC 3748 [RFC3748]. 1049 0 1 2 3 1050 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 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Code | Identifier | Length | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Type | Type-Data ... 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1057 Figure 7: EAP Packet 1059 Code 1061 5 Initiate 1063 6 Finish 1065 Two new code values are defined for the purpose of ERP. 1067 Identifier 1069 The Identifier field is one octet. The Identifier field MUST 1070 be the same if an EAP-Initiate packet is retransmitted due to a 1071 timeout while waiting for a Finish message. Any new (non- 1072 retransmission) Initiate message MUST use a new Identifier 1073 field. 1075 The Identifier field of the Finish message MUST match that of 1076 the currently outstanding Initiate message. A peer or 1077 authenticator receiving a Finish message whose Identifier value 1078 does not match that of the currently outstanding Initiate 1079 message MUST silently discard the packet. 1081 In order to avoid confusion between new EAP-Initiate messages 1082 and retransmissions, the peer must choose an Identifier value 1083 that is different from the previous EAP-Initiate message, 1084 especially if that exchange has not finished. It is 1085 RECOMMENDED that the authenticator clear EAP Re-auth state 1086 after 300 seconds. 1088 Type 1090 This field indicates that this is an ERP exchange. Two type 1091 values are defined in this document for this purpose -- Re- 1092 auth-Start (assigned Type 1) and Re-auth (assigned Type 2). 1094 Type-Data 1096 The Type-Data field varies with the Type of re-authentication 1097 packet. 1099 5.3.1. EAP-Initiate/Re-auth-Start Packet 1101 The EAP-Initiate/Re-auth-Start packet contains the parameters shown 1102 in Figure 8. 1104 0 1 2 3 1105 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 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Code | Identifier | Length | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Type | Reserved | 1 or more TVs or TLVs ~ 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 Figure 8: EAP-Initiate/Re-auth-Start Packet 1114 Type = 1. 1116 Reserved, MUST be zero. Set to zero on transmission and ignored 1117 on reception. 1119 One or more TVs or TLVs are used to convey information to the 1120 peer; for instance, the authenticator may send the domain name to 1121 the peer. 1123 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1124 and a value with type-specific length. In the TLV payloads, there 1125 is a 1-octet type payload and a 1-octet length payload. The 1126 length field indicates the length of the value expressed in number 1127 of octets. 1129 Domain-Name: This is a TLV payload. The Type is 4. The domain 1130 name is to be used as the realm in an NAI [RFC4282]. The 1131 Domain-Name attribute SHOULD be present in an EAP-Initiate/ 1132 Re-auth-Start message. 1134 In addition, channel binding information MAY be included; see 1135 Section 5.5 for discussion. See Figure 12 for parameter 1136 specification. 1138 5.3.1.1. Authenticator Operation 1140 The authenticator MAY send the EAP-Initiate/Re-auth-Start message to 1141 indicate support for ERP to the peer and to initiate ERP if the peer 1142 has already performed full EAP authentication and has unexpired key 1143 material. The authenticator SHOULD include the domain name TLV to 1144 allow the peer to learn it without lower-layer support or the ERP 1145 bootstrapping exchange. 1147 The authenticator MAY include channel binding information so that the 1148 peer can send the information to the server in the EAP-Initiate/ 1149 Re-auth message so that the server can verify whether the 1150 authenticator is claiming the same identity to both parties. 1152 The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start 1153 message a few times for reliable transport. 1155 5.3.1.2. Peer Operation 1157 The peer SHOULD send the EAP-Initiate/Re-auth message in response to 1158 the EAP-Initiate/Re-auth-Start message from the authenticator. If 1159 the peer does not recognize the Initiate code value, it silently 1160 discards the message. If the peer has already sent the EAP-Initiate/ 1161 Re-auth message to begin the ERP exchange, it silently discards the 1162 message. 1164 If the EAP-Initiate/Re-auth-Start message contains the domain name, 1165 and if the peer does not already have the domain information, the 1166 peer SHOULD use the domain name to compute the DSRK and use the 1167 corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start 1168 an ERP exchange with the local ER server. If there are the local ER 1169 server between the peer and the home ER server and the peer has 1170 already initiated an ERP exchange with the local ER server, it SHOULD 1171 choose to not start an ERP exchange with the home ER server. 1173 5.3.2. EAP-Initiate/Re-auth Packet 1175 The EAP-Initiate/Re-auth packet contains the parameters shown in 1176 Figure 9. 1178 0 1 2 3 1179 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 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Code | Identifier | Length | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Type |R|B|L| Reserved| SEQ | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | 1 or more TVs or TLVs ~ 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | cryptosuite | Authentication Tag ~ 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 Figure 9: EAP-Initiate/Re-auth Packet 1192 Type = 2. 1194 Flags 1196 'R' - The R flag is set to 0 and ignored upon reception. 1198 'B' - The B flag is used as the bootstrapping flag. If the 1199 flag is turned on, the message is a bootstrap message. 1201 'L' - The L flag is used to request the key lifetimes from the 1202 server. 1204 The rest of the 5 bits are set to 0 and ignored on reception. 1206 SEQ: A 16-bit sequence number is used for replay protection. The 1207 SEQ number field is initialized to 0 every time a new rRK is 1208 derived. 1210 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1211 and a value with type-specific length. In the TLV payloads, there 1212 is a 1-octet type payload and a 1-octet length payload. The 1213 length field indicates the length of the value expressed in number 1214 of octets. 1216 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1217 The NAI is variable in length, not exceeding 253 octets. The 1218 EMSKname is in the username part of the NAI and is encoded in 1219 hexadecimal values. The EMSKname is 64 bits in length and so 1220 the username portion takes up 128 octets. If the rIK is 1221 derived from the EMSK, the realm part of the NAI is the home 1222 domain name, and if the rIK is derived from a DSRK, the realm 1223 part of the NAI is the domain name used in the derivation of 1224 the DSRK. The NAI syntax follows [RFC4282]. Exactly one 1225 keyName-NAI attribute SHALL be present in an EAP-Initiate/ 1226 Re-auth packet. 1228 In addition, channel binding information MAY be included; see 1229 Section 5.5 for discussion. See Figure 12 for parameter 1230 specification. 1232 Cryptosuite: This field indicates the integrity algorithm used for 1233 ERP. Key lengths and output lengths are either indicated or are 1234 obvious from the cryptosuite name. We specify some cryptosuites 1235 below: 1237 * 0 RESERVED 1239 * 1 HMAC-SHA256-64 1241 * 2 HMAC-SHA256-128 1243 * 3 HMAC-SHA256-256 1245 HMAC-SHA256-128 is mandatory to implement and should be enabled in 1246 the default configuration. 1248 Authentication Tag: This field contains the integrity checksum 1249 over the ERP packet, excluding the authentication tag field 1250 itself. The length of the field is indicated by the Cryptosuite. 1252 5.3.3. EAP-Finish/Re-auth Packet 1254 The EAP-Finish/Re-auth packet contains the parameters shown in 1255 Figure 10. 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Code | Identifier | Length | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Type |R|B|L| Reserved | SEQ ~ 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | 1 or more TVs or TLVs ~ 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | cryptosuite | Authentication Tag ~ 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 Figure 10: EAP-Finish/Re-auth Packet 1271 Type = 2. 1273 Flags 1275 'R' - The R flag is used as the Result flag. When set to 0, it 1276 indicates success, and when set to '1', it indicates a failure. 1278 'B' - The B flag is used as the bootstrapping flag. If the 1279 flag is turned on, the message is a bootstrap message. 1281 'L' - The L flag is used to indicate the presence of the rRK 1282 lifetime TLV. 1284 The rest of the 5 bits are set to 0 and ignored on reception. 1286 SEQ: A 16-bit sequence number is used for replay protection. The 1287 SEQ number field is initialized to 0 every time a new rRK is 1288 derived. 1290 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1291 and a value with type-specific length. In the TLV payloads, there 1292 is a 1-octet type payload and a 1-octet length payload. The 1293 length field indicates the length of the value expressed in number 1294 of octets. 1296 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1297 The NAI is variable in length, not exceeding 253 octets. 1298 EMSKname is in the username part of the NAI and is encoded in 1299 hexadecimal values. The EMSKname is 64 bits in length and so 1300 the username portion takes up 16 octets. If the rIK is derived 1301 from the EMSK, the realm part of the NAI is the home domain 1302 name, and if the rIK is derived from a DSRK, the realm part of 1303 the NAI is the domain name used in the derivation of the DSRK. 1304 The NAI syntax follows [RFC4282]. Exactly one instance of the 1305 keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth 1306 message. 1308 rRK Lifetime: This is a TV payload. The Type is 2. The value 1309 field is a 32-bit field and contains the lifetime of the rRK in 1310 seconds. If the 'L' flag is set, the rRK Lifetime attribute 1311 SHOULD be present. 1313 rMSK Lifetime: This is a TV payload. The Type is 3. The value 1314 field is a 32-bit field and contains the lifetime of the rMSK 1315 in seconds. If the 'L' flag is set, the rMSK Lifetime 1316 attribute SHOULD be present. 1318 Domain-Name: This is a TLV payload. The Type is 4. The domain 1319 name is to be used as the realm in an NAI [RFC4282]. Domain- 1320 Name attribute MUST be present in an EAP-Finish/Re-auth message 1321 if the bootstrapping flag is set and if the local ER server 1322 sent a DSRK request. 1324 List of cryptosuites: This is a TLV payload. The Type is 5. 1325 The value field contains a list of cryptosuites, each of size 1 1326 octet. The cryptosuite values are as specified in Figure 9. 1327 The server SHOULD include this attribute if the cryptosuite 1328 used in the EAP-Initiate/Re-auth message was not acceptable and 1329 the message is being rejected. The server MAY include this 1330 attribute in other cases. The server MAY use this attribute to 1331 signal to the peer about its cryptographic algorithm 1332 capabilities. 1334 Authorization Indication: This is a TLV payload. The Type is 1335 6. This attribute MAY be included in the EAP-Finish/Re-auth 1336 message when a DSRK is delivered to a local ER server and if 1337 the home EAP server can verify the authorization of the local 1338 ER server to advertise the domain name included in the domain 1339 TLV in the same message. The value field in the TLV contains 1340 an authentication tag computed over the entire packet, starting 1341 from the first bit of the code field to the last bit of the 1342 cryptosuite field, with the value field of the Authorization 1343 Indication TLV filled with all 0s for the computation. The key 1344 used for the computation MUST be derived from the EMSK with key 1345 label "DSRK Delivery Authorized Key@ietf.org" and optional data 1346 containing an ASCII string representing the key management 1347 domain that the DSRK is being derived for. 1349 In addition, channel binding information MAY be included: see 1350 Section 5.5 for discussion. See Figure 12 for parameter 1351 specification. The server sends this information so that the 1352 peer can verify the information seen at the lower layer, if 1353 channel binding is to be supported. 1355 Cryptosuite: This field indicates the integrity algorithm and the 1356 PRF used for ERP. Key lengths and output lengths are either 1357 indicated or are obvious from the cryptosuite name. 1359 Authentication Tag: This field contains the integrity checksum 1360 over the ERP packet, excluding the authentication tag field 1361 itself. The length of the field is indicated by the Cryptosuite. 1363 5.3.4. TV and TLV Attributes 1365 The TV attributes that may be present in the EAP-Initiate or EAP- 1366 Finish messages are of the following format: 1368 0 1 2 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Type | Value ... 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 Figure 11: TV Attribute Format 1376 The TLV attributes that may be present in the EAP-Initiate or EAP- 1377 Finish messages are of the following format: 1379 0 1 2 3 1380 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 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | Type | Length | Value ... 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 Figure 12: TLV Attribute Format 1387 The following Types are defined in this document: 1389 '1' - keyName-NAI: This is a TLV payload. 1391 '2' - rRK Lifetime: This is a TV payload. 1393 '3' - rMSK Lifetime: This is a TV payload. 1395 '4' - domain name: This is a TLV payload. 1397 '5' - cryptosuite list: This is a TLV payload. 1399 '6' - Authorization Indication: This is a TLV payload. 1401 The TLV type range of 128-191 is reserved to carry channel binding 1402 information in the EAP-Initiate and Finish/Re-auth messages. 1403 Below are the current assignments (all of them are TLVs): 1405 '128' - Called-Station-Id [RFC2865] 1407 '129' - Calling-Station-Id [RFC2865] 1408 '130' - NAS-Identifier [RFC2865] 1410 '131' - NAS-IP-Address [RFC2865] 1412 '132' - NAS-IPv6-Address [RFC3162] 1414 The length field indicates the length of the value part of the 1415 attribute in octets. 1417 5.4. Replay Protection 1419 For replay protection, ERP uses sequence numbers. The sequence 1420 number is maintained per rIK and is initialized to zero in both 1421 directions. In the first EAP-Initiate/Re-auth message, the peer uses 1422 the sequence number zero or higher. Note that the when the sequence 1423 number rotates, the rIK MUST be changed by running EAP 1424 authentication. The server expects a sequence number of zero or 1425 higher. When the server receives an EAP-Initiate/Re-auth message, it 1426 uses the same sequence number in the EAP-Finish/Re-auth message. The 1427 server then sets the expected sequence number to the received 1428 sequence number plus 1. The server accepts sequence numbers greater 1429 than or equal to the expected sequence number. 1431 If the peer sends an EAP-Initiate/Re-auth message, but does not 1432 receive a response, it retransmits the request (with no changes to 1433 the message itself) a pre-configured number of times before giving 1434 up. However, it is plausible that the server itself may have 1435 responded to the message and it was lost in transit. Thus, the peer 1436 MUST increment the sequence number and use the new sequence number to 1437 send subsequent EAP re-authentication messages. The peer SHOULD 1438 increment the sequence number by 1; however, it may choose to 1439 increment by a larger number. When the sequence number rotates, the 1440 peer MUST run full EAP authentication. 1442 5.5. Channel Binding 1444 ERP provides a protected facility to carry channel binding (CB) 1445 information, according to the guidelines in Section 7.15 of 1446 [RFC3748]. The TLV type range of 128-191 is reserved to carry CB 1447 information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth 1448 messages. Called-Station-Id, Calling-Station-Id, NAS-Identifier, 1449 NAS-IP-Address, and NAS-IPv6-Address are some examples of channel 1450 binding information listed in RFC 3748, and they are assigned values 1451 128-132. Additional values are IANA managed based on IETF Consensus 1452 [RFC5226]. 1454 The authenticator MAY provide CB information to the peer via the EAP- 1455 Initiate/Re-auth-Start message. The peer sends the information to 1456 the server in the EAP-Initiate/Re-auth message; the server verifies 1457 whether the authenticator identity available via AAA attributes is 1458 the same as the identity provided to the peer. 1460 If the peer does not include the CB information in the EAP-Initiate/ 1461 Re-auth message, and if the local ER server's policy requires channel 1462 binding support, it SHALL send the CB attributes for the peer's 1463 verification. The peer attempts to verify the CB information if the 1464 authenticator has sent the CB parameters, and it proceeds with the 1465 lower-layer security association establishment if the attributes 1466 match. Otherwise, the peer SHALL NOT proceed with the lower-layer 1467 security association establishment. 1469 6. Lower-Layer Considerations 1471 The authenticator is responsible for retransmission of EAP-Initiate/ 1472 Re-auth-Start messages. The authenticator MAY retransmit the message 1473 a few times or until it receives an EAP-Initiate/Re-auth message from 1474 the peer. The authenticator may not know whether the peer supports 1475 ERP; in those cases, the peer may be silently dropping the EAP- 1476 Initiate/Re-auth-Start packets. Thus, retransmission of these 1477 packets should be kept to a minimum. The exact number is up to each 1478 lower layer. 1480 The Identifier value in the EAP-Initiate/Re-auth packet is 1481 independent of the Identifier value in the EAP-Initiate/Re-auth-Start 1482 packet. 1484 The peer is responsible for retransmission of EAP-Initiate/Re-auth 1485 messages. 1487 Retransmitted packets MUST be sent with the same Identifier value in 1488 order to distinguish them from new packets. By default, where the 1489 EAP-Initiate message is sent over an unreliable lower layer, the 1490 retransmission timer SHOULD be dynamically estimated. A maximum of 1491 3-5 retransmissions is suggested (this is based on the recommendation 1492 of [RFC3748]). Where the EAP-Initiate message is sent over a 1493 reliable lower layer, the retransmission timer SHOULD be set to an 1494 infinite value, so that retransmissions do not occur at the EAP 1495 layer. Please refer to RFC 3748 [RFC3748] for additional guidance on 1496 setting timers. 1498 The Identifier value in the EAP-Finish/Re-auth packet is the same as 1499 the Identifier value in the EAP-Initiate/Re-auth packet. 1501 If an authenticator receives a valid duplicate EAP-Initiate/Re-auth 1502 message for which it has already sent an EAP-Finish/Re-auth message, 1503 it MUST resend the EAP-Finish/Re-auth message without reprocessing 1504 the EAP-Initiate/Re-auth message. To facilitate this, the 1505 authenticator SHALL store a copy of the EAP-Finish/Re-auth message 1506 for a finite amount of time. The actual value of time is a local 1507 matter; this specification recommends a value of 100 milliseconds. 1509 The lower layer may provide facilities for exchanging information 1510 between the peer and the authenticator about support for ERP, for the 1511 authenticator to send the domain name information and channel binding 1512 information to the peer 1514 Note that to support ERP, lower-layer specifications may need to be 1515 revised. Specifically, the IEEE802.1x specification must be revised 1516 to allow carrying EAP messages of the new codes defined in this 1517 document in order to support ERP. Similarly, RFC 4306 must be 1518 updated to include EAP code values higher than 4 in order to use ERP 1519 with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may 1520 also be updated to support peer-initiated ERP for optimized 1521 operation. Other lower layers may need similar revisions. 1523 Our analysis indicates that some EAP implementations are not RFC 3748 1524 compliant in that instead of silently dropping EAP packets with code 1525 values higher than 4, they may consider it an error. To accommodate 1526 such non-compliant EAP implementations, additional guidance has been 1527 provided below. Furthermore, it may not be easy to upgrade all the 1528 peers in some cases. In such cases, authenticators may be configured 1529 to not send EAP-Initiate/Re-auth-Start; peers may learn whether an 1530 authenticator supports ERP via configuration, from advertisements at 1531 the lower layer. 1533 In order to accommodate implementations that are not compliant to RFC 1534 3748, such lower layers SHOULD ensure that both parties support ERP; 1535 this is trivial for an instance when using a lower layer that is 1536 known to always support ERP. For lower layers where ERP support is 1537 not guaranteed, ERP support may be indicated through signaling (e.g., 1538 piggy-backed on a beacon) or through negotiation. Alternatively, 1539 clients may recognize environments where ERP is available based on 1540 pre-configuration. Other similar mechanisms may also be used. When 1541 ERP support cannot be verified, lower layers may mandate falling back 1542 to full EAP authentication to accommodate EAP implementations that 1543 are not compliant to RFC 3748. 1545 7. Transport of ERP Messages 1547 AAA Transport of ERP messages is specified in [RFC5749] and 1548 [I-D.ietf-dime-erp]. 1550 8. Security Considerations 1552 This section provides an analysis of the protocol in accordance with 1553 the AAA key management requirements specified in [RFC4962]. 1555 Cryptographic algorithm independence 1557 The EAP Re-auth Protocol satisfies this requirement. The 1558 algorithm chosen by the peer for the MAC generation is 1559 indicated in the EAP-Initiate/Re-auth message. If the chosen 1560 algorithm is unacceptable, the EAP server returns an EAP- 1561 Finish/Re-auth message with Failure indication. Algorithm 1562 agility for the KDF is specified in [RFC5295]. Only when the 1563 algorithms used are acceptable, the server proceeds with 1564 derivation of keys and verification of the proof of possession 1565 of relevant keying material by the peer. A full-blown 1566 negotiation of algorithms cannot be provided in a single round 1567 trip protocol. Hence, while the protocol provides algorithm 1568 agility, it does not provide true negotiation. 1570 Strong, fresh session keys 1572 ERP results in the derivation of strong, fresh keys that are 1573 unique for the given session. An rMSK is always derived on- 1574 demand when the peer requires a key with a new authenticator. 1575 The derivation ensures that the compromise of one rMSK does not 1576 result in the compromise of a different rMSK at any time. 1578 Limit key scope 1580 The scope of all the keys derived by ERP is well defined. The 1581 rRK and rIK are never shared with any entity and always remain 1582 on the peer and the server. The rMSK is provided only to the 1583 authenticator through which the peer performs the ERP exchange. 1584 No other authenticator is authorized to use that rMSK. 1586 Replay detection mechanism 1588 For replay protection of ERP messages, a sequence number 1589 associated with the rIK is used. The sequence number is 1590 maintained by the peer and the server, and initialized to zero 1591 when the rIK is generated. The peer increments the sequence 1592 number by one after it sends an ERP message. The server sets 1593 the expected sequence number to the received sequence number 1594 plus one after verifying the validity of the received message 1595 and responds to the message. 1597 Authenticate all parties 1599 The EAP Re-auth Protocol provides mutual authentication of the 1600 peer and the server. Both parties need to possess the keying 1601 material that resulted from a previous EAP exchange in order to 1602 successfully derive the required keys. Also, both the EAP re- 1603 authentication Response and the EAP re-authentication 1604 Information messages are integrity protected so that the peer 1605 and the server can verify each other. When the ERP exchange is 1606 executed with a local ER server, the peer and the local server 1607 mutually authenticate each other via that exchange in the same 1608 manner. The peer and the authenticator authenticate each other 1609 in the secure association protocol executed by the lower layer, 1610 just as in the case of a regular EAP exchange. 1612 Peer and authenticator authorization 1614 The peer and authenticator demonstrate possession of the same 1615 key material without disclosing it, as part of the lower-layer 1616 secure association protocol. Channel binding with ERP may be 1617 used to verify consistency of the identities exchanged, when 1618 the identities used in the lower layer differ from that 1619 exchanged within the AAA protocol. 1621 Keying material confidentiality 1623 The peer and the server derive the keys independently using 1624 parameters known to each entity. The AAA server sends the DSRK 1625 of a domain to the corresponding local ER server via the AAA 1626 protocol. Likewise, the ER server sends the rMSK to the 1627 authenticator via the AAA protocol. 1629 Note that compromise of the DSRK results in compromise of all 1630 keys derived from it. Moreover, there is no forward secrecy 1631 within ERP. Thus, compromise of an DSRK retroactively 1632 compromises all ERP keys. 1634 It is RECOMMENDED that the AAA protocol be protected using 1635 IPsec or TLS so that the keys are protected in transit. Note, 1636 however, that keys may be exposed to AAA proxies along the way 1637 and compromise of any of those proxies may result in compromise 1638 of keys being transported through them. 1640 The home EAP server MUST NOT hand out a given DSRK to a local 1641 domain server more than once, unless it can verify that the 1642 entity receiving the DSRK after the first time is the same as 1643 that received the DSRK originally. If the home EAP server 1644 verifies authorization of a local domain server, it MAY hand 1645 out the DSRK to that domain more than once. In this case, the 1646 home EAP server includes the Authorization Indication TLV to 1647 assure the peer that DSRK delivery is secure. 1649 Confirm cryptosuite selection 1651 Crypto algorithms for integrity and key derivation in the 1652 context of ERP MAY be the same as that used by the EAP method. 1653 In that case, the EAP method is responsible for confirming the 1654 cryptosuite selection. Furthermore, the cryptosuite is 1655 included in the ERP exchange by the peer and confirmed by the 1656 server. The protocol allows the server to reject the 1657 cryptosuite selected by the peer and provide alternatives. 1658 When a suitable rIK is not available for the peer, the 1659 alternatives may be sent in an unprotected fashion. The peer 1660 is allowed to retry the exchange using one of the allowed 1661 cryptosuites. However, in this case, any en route 1662 modifications to the list sent by the server will go 1663 undetected. If the server does have an rIK available for the 1664 peer, the list will be provided in a protected manner and this 1665 issue does not apply. 1667 Uniquely named keys 1669 All keys produced within the ERP context can be referred to 1670 uniquely as specified in this document. Also, the key names do 1671 not reveal any part of the keying material. 1673 Prevent the domino effect 1675 The compromise of one peer does not result in the compromise of 1676 keying material held by any other peer in the system. Also, 1677 the rMSK is meant for a single authenticator and is not shared 1678 with any other authenticator. Hence, the compromise of one 1679 authenticator does not lead to the compromise of sessions or 1680 keys held by any other authenticator in the system. Hence, the 1681 EAP Re-auth Protocol allows prevention of the domino effect by 1682 appropriately defining key scope. 1684 However, if keys are transported using hop-by-hop protection, 1685 compromise of a proxy may result in compromise of key material, 1686 i.e., the DSRK being sent to a local ER server. 1688 Bind key to its context 1690 All the keys derived for ERP are bound to the appropriate 1691 context using appropriate key labels. Lifetime of a child key 1692 is less than or equal to that of its parent key as specified in 1693 RFC 4962 [RFC4962]. The key usage, lifetime and the parties 1694 that have access to the keys are specified. 1696 Confidentiality of identity 1698 Deployments where privacy is a concern may find the use of 1699 rIKname-NAI to route ERP messages serves their privacy 1700 requirements. Note that it is plausible to associate multiple 1701 runs of ERP messages since the rIKname is not changed as part 1702 of the ERP protocol. There was no consensus for that 1703 requirement at the time of development of this specification. 1704 If the rIKname is not used and the Peer-ID is used instead, the 1705 ERP exchange will reveal the Peer-ID over the wire. 1707 Authorization restriction 1709 All the keys derived are limited in lifetime by that of the 1710 parent key or by server policy. Any domain-specific keys are 1711 further restricted for use only in the domain for which the 1712 keys are derived. All the keys specified in this document are 1713 meant for use in ERP only. Any other restrictions of session 1714 keys may be imposed by the specific lower layer and are out of 1715 scope for this specification. 1717 A denial-of-service (DoS) attack on the peer may be possible when 1718 using the EAP Initiate/Re-auth message. An attacker may send a bogus 1719 EAP-Initiate/Re-auth message, which may be carried by the 1720 authenticator in a RADIUS-Access-Request to the server; in response, 1721 the server may send an EAP-Finish/Re-auth with Failure indication in 1722 a RADIUS Access-Reject message. Note that such attacks may be 1723 plausible with the EAPoL-Start capability of IEEE 802.11 and other 1724 similar facilities in other link layers and where the peer can 1725 initiate EAP authentication. An attacker may use such messages to 1726 start an EAP method run, which fails and may result in the server 1727 sending a RADIUS Access-Reject message, thus resulting in the link- 1728 layer connections being terminated. 1730 To prevent such DoS attacks, an ERP failure should not result in 1731 deletion of any authorization state established by a full EAP 1732 exchange. Alternatively, the lower layers and AAA protocols may 1733 define mechanisms to allow two link-layer security associations (SAs) 1734 derived from different EAP keying materials for the same peer to 1735 exist so that smooth migration from the current link layer SA to the 1736 new one is possible during rekey. These mechanisms prevent the link 1737 layer connections from being terminated when a re-authentication 1738 procedure fails due to the bogus EAP-Initiate/Re-auth message. 1740 When a DSRK is sent from a home EAP server to a local domain server 1741 or when a rMSK is sent from an ER server to an authenticator, in the 1742 absence of end-to-end security between the entity that is sending the 1743 key and the entity receiving the key, it is plausible for other 1744 entities to get access to keys being sent to an ER server in another 1745 domain. This mode of key transport is similar to that of MSK 1746 transport in the context of EAP authentication. We further observe 1747 that ERP is for access authentication and does not support end-to-end 1748 data security. In typical implementations, the traffic is in the 1749 clear beyond the access control enforcement point (the authenticator 1750 or an entity delegated by the authenticator for access control 1751 enforcement). The model works as long as entities in the middle of 1752 the network do not use keys intended for other parties to steal 1753 service from an access network. If that is not achievable, key 1754 delivery must be protected in an end-to-end manner. 1756 9. IANA Considerations 1758 This document has no IANA actions; all values referenced in this 1759 document were previously assigned in RFC 5296 [RFC5296]. 1761 10. References 1763 10.1. Normative References 1765 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1766 Hashing for Message Authentication", RFC 2104, 1767 February 1997. 1769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1770 Requirement Levels", BCP 14, RFC 2119, March 1997. 1772 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1773 Levkowetz, "Extensible Authentication Protocol (EAP)", 1774 RFC 3748, June 2004. 1776 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1777 Network Access Identifier", RFC 4282, December 2005. 1779 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 1780 "Specification for the Derivation of Root Keys from an 1781 Extended Master Session Key (EMSK)", RFC 5295, 1782 August 2008. 1784 10.2. Informative References 1786 [I-D.ietf-dime-erp] 1787 Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter 1788 Support for the EAP Re-authentication Protocol (ERP)", 1789 draft-ietf-dime-erp-04 (work in progress), September 2010. 1791 [I-D.ietf-dime-local-keytran] 1792 , Q. and G. , "Diameter Attribute-Value Pairs for 1793 Cryptographic Key Transport", 1794 draft-ietf-dime-local-keytran-07 (work in progress), 1795 July 2010. 1797 [I-D.ietf-hokey-ldn-discovery] 1798 Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name 1799 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in 1800 progress), September 2010. 1802 [IEEE_802.1X] 1803 Institute of Electrical and Electronics Engineers, "IEEE 1804 Standards for Local and Metropolitan Area Networks: Port 1805 based Network Access Control, IEEE Std 802.1X-2004", 1806 December 2004. 1808 [MSKHierarchy] 1809 Lopez, R., Skarmeta, A., Bournelle, J., Laurent- 1810 Maknavicus, M., and J. Combes, "Improved EAP keying 1811 framework for a secure mobility access service", 1812 IWCMC '06, Proceedings of the 2006 International 1813 Conference on Wireless Communications and 1814 Mobile Computing, New York, NY, USA, 2006. 1816 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1817 "Remote Authentication Dial In User Service (RADIUS)", 1818 RFC 2865, June 2000. 1820 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1821 RFC 3162, August 2001. 1823 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1824 Dial In User Service) Support For Extensible 1825 Authentication Protocol (EAP)", RFC 3579, September 2003. 1827 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1828 Protocol Method for 3rd Generation Authentication and Key 1829 Agreement (EAP-AKA)", RFC 4187, January 2006. 1831 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1832 Authorization, and Accounting (AAA) Key Management", 1833 BCP 132, RFC 4962, July 2007. 1835 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 1836 "Handover Key Management and Re-Authentication Problem 1837 Statement", RFC 5169, March 2008. 1839 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1840 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1841 May 2008. 1843 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 1844 authentication Protocol (ERP)", RFC 5296, August 2008. 1846 [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of 1847 EAP-Based Keys for Handover and Re-Authentication", 1848 RFC 5749, March 2010. 1850 Appendix A. Acknowledgments 1852 A.1. RFC 5296 1854 In writing this document, we benefited from discussing the problem 1855 space and the protocol itself with a number of folks including 1856 Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, 1857 Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, 1858 Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi 1859 Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of 1860 the HOKEY working group. The credit for the idea to use EAP- 1861 Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- 1862 layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin 1863 Hoeper suggested the use of the windowing technique to handle 1864 multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for 1865 the suggestion to use hexadecimal encoding for rIKname when sent as 1866 part of keyName-NAI field. Thanks to Bernard Aboba for suggestions 1867 in clarifying the EAP lock-step operation, and Joe Salowey and Glen 1868 Zorn for help in specifying AAA transport of ERP messages. Thanks to 1869 Sam Hartman for the DSRK Authorization Indication mechanism. 1871 A.2. RFC 5296bis 1873 Glen Zorn wrote the initial draft for this document and provided 1874 useful reviews. Many thanks to him. 1876 Appendix B. Example ERP Exchange 1878 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] 1880 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, 1881 cryptosuite,Auth-tag*) 1883 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, 1884 EAP Initiate/Re-auth(SEQ,keyName-NAI, 1885 cryptosuite,Auth-tag*) 1887 2. ER-Server --> Authenticator: AAA-Response{rMSK, 1888 EAP-Finish/Re-auth(SEQ,keyName-NAI, 1889 cryptosuite,[CB-Info],Auth-tag*) 1891 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, 1892 cryptosuite,[CB-Info],Auth-tag*) 1894 * Auth-tag computation is over the entire EAP Initiate/Finish message; 1895 the code values for Initiate and Finish are different and thus 1896 reflection attacks are mitigated. 1898 Authors' Addresses 1900 Qin Wu (editor) 1901 Huawei Technologies Co., Ltd. 1902 101 Software Avenue, Yuhua District 1903 Nanjing, JiangSu 210012 1904 China 1906 Email: Sunseawq@huawei.com 1908 Zhen Cao 1909 China Mobile 1910 53A Xibianmennei Ave., Xuanwu District 1911 Beijing, Beijing 100053 1912 P.R. China 1914 Email: caozhen@chinamobile.com 1915 Yang Shi 1916 H3C Tech. Co., Ltd 1917 Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District 1918 Beijing 100085 1919 China 1921 Email: young@h3c.com 1923 Baohong He 1924 China 1926 Email: hebaohong@catr.cn