idnits 2.17.1 draft-ietf-hokey-rfc5296bis-00.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 (September 13, 2010) is 4946 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 287, 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 -- 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 (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn, Ed. 3 Internet-Draft Network Zen 4 Obsoletes: 5296 (if approved) Q. Wu 5 Intended status: Standards Track Huawei 6 Expires: March 17, 2011 Z. Cao 7 China Mobile 8 September 13, 2010 10 EAP Extensions for EAP Re-authentication Protocol (ERP) 11 draft-ietf-hokey-rfc5296bis-00 13 Abstract 15 The Extensible Authentication Protocol (EAP) is a generic framework 16 supporting multiple types of authentication methods. In systems 17 where EAP is used for authentication, it is desirable to not repeat 18 the entire EAP exchange with another authenticator. This document 19 specifies extensions to EAP and the EAP keying hierarchy to support 20 an EAP method-independent protocol for efficient re-authentication 21 between the peer and an EAP re-authentication server through any 22 authenticator. The re-authentication server may be in the home 23 network or in the local network to which the peer is connecting. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 17, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 7 75 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 9 76 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 12 78 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 13 79 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 80 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 14 81 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 15 83 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 84 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 16 85 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 16 86 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 19 87 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 21 88 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 22 89 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 23 90 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 24 91 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 25 92 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 25 93 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25 94 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 27 95 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 30 96 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 31 97 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31 98 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 32 99 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 33 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 39 105 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 106 A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 40 107 A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 40 108 Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 40 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 111 1. Introduction 113 The Extensible Authentication Protocol (EAP) is a an authentication 114 framework that supports multiple authentication methods. The primary 115 purpose is network access authentication, and a key-generating method 116 is used when the lower layer wants to enforce access control. The 117 EAP keying hierarchy defines two keys to be derived by all key- 118 generating EAP methods: the Master Session Key (MSK) and the Extended 119 MSK (EMSK). In the most common deployment scenario, an EAP peer and 120 an EAP server authenticate each other through a third party known as 121 the EAP authenticator. The EAP authenticator or an entity controlled 122 by the EAP authenticator enforces access control. After successful 123 authentication, the EAP server transports the MSK to the EAP 124 authenticator; the EAP authenticator and the EAP peer establish 125 transient session keys (TSKs) using the MSK as the authentication 126 key, key derivation key, or a key transport key, and use the TSK for 127 per-packet access enforcement. 129 When a peer moves from one authenticator to another, it is desirable 130 to avoid a full EAP authentication to support fast handovers. The 131 full EAP exchange with another run of the EAP method can take several 132 round trips and significant time to complete, causing delays in 133 handover times. Some EAP methods specify the use of state from the 134 initial authentication to optimize re-authentications by reducing the 135 computational overhead, but method-specific re-authentication takes 136 at least 2 round trips with the original EAP server in most cases 137 (e.g., [RFC4187]). It is also important to note that several methods 138 do not offer support for re-authentication. 140 Key sharing across authenticators is sometimes used as a practical 141 solution to lower handover times. In that case, compromise of an 142 authenticator results in compromise of keying material established 143 via other authenticators. Other solutions for fast re-authentication 144 exist in the literature [MSKHierarchy]. 146 In conclusion, to achieve low latency handovers, there is a need for 147 a method-independent re-authentication protocol that completes in 148 less than 2 round trips, preferably with a local server. The EAP re- 149 authentication problem statement is described in detail in [RFC5169]. 151 This document specifies EAP Re-authentication Extensions (ERXs) for 152 efficient re-authentication using EAP. The protocol that uses these 153 extensions itself is referred to as the EAP Re-authentication 154 Protocol (ERP). It supports EAP method-independent re-authentication 155 for a peer that has valid, unexpired key material from a previously 156 performed EAP authentication. The protocol and the key hierarchy 157 required for EAP re-authentication are described in this document. 159 Note that to support ERP, lower-layer specifications may need to be 160 revised to allow carrying EAP messages that have a code value higher 161 than 4 and to accommodate the peer-initiated nature of ERP. 162 Specifically, the IEEE802.1x specification must be revised and RFC 163 4306 must be updated to carry ERP messages. 165 2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 This document uses the basic EAP terminology [RFC3748] and EMSK 172 keying hierarchy terminology [RFC5295]. In addition, this document 173 uses the following terms: 175 ER Peer - An EAP peer that supports the EAP Re-authentication 176 Protocol. All references to "peer" in this document imply an ER 177 peer, unless specifically noted otherwise. 179 ER Authenticator - An entity that supports the authenticator 180 functionality for EAP re-authentication described in this 181 document. All references to "authenticator" in this document 182 imply an ER authenticator, unless specifically noted otherwise. 184 ER Server - An entity that performs the server portion of ERP 185 described here. This entity may or may not be an EAP server. All 186 references to "server" in this document imply an ER server, unless 187 specifically noted otherwise. An ER server is a logical entity; 188 the home ER server is located on the same backend authentication 189 server as the EAP server in the home domain. The local ER server 190 may not necessarily be a full EAP server. 192 ERX - EAP re-authentication extensions. 194 ERP - EAP Re-authentication Protocol that uses the re- 195 authentication extensions. 197 rRK - re-authentication Root Key, derived from the EMSK or DSRK. 199 rIK - re-authentication Integrity Key, derived from the rRK. 201 rMSK - re-authentication MSK. This is a per-authenticator key, 202 derived from the rRK. 204 keyName-NAI - ERP messages are integrity protected with the rIK or 205 the DS-rIK. The use of rIK or DS-rIK for integrity protection of 206 ERP messages is indicated by the EMSKname [RFC5295]; the protocol, 207 which is ERP; and the realm, which indicates the domain name of 208 the ER server. The EMSKname is copied into the username part of 209 the NAI. 211 Domain - Refers to a "key management domain" as defined in 212 [RFC5295]. For simplicity, it is referred to as "domain" in this 213 document. The terms "home domain" and "local domain" are used to 214 differentiate between the originating key management domain that 215 performs the full EAP exchange with the peer and the local domain 216 to which a peer may be attached at a given time. 218 3. ERP Description 220 ERP allows a peer and server to mutually verify proof of possession 221 of keying material from an earlier EAP method run and to establish a 222 security association between the peer and the authenticator. The 223 authenticator acts as a pass-through entity for the Re-authentication 224 Protocol in a manner similar to that of an EAP authenticator 225 described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange 226 between the peer and the server; it is independent of the lower layer 227 and the EAP method used during the full EAP exchange. The ER server 228 may be in the home domain or in the same (visited) domain as the peer 229 and the authenticator. 231 Figure 2 shows the protocol exchange. The first time the peer 232 attaches to any network, it performs a full EAP exchange (shown in 233 Figure 1) with the EAP server; as a result, an MSK is distributed to 234 the EAP authenticator. The MSK is then used by the authenticator and 235 the peer to establish TSKs as needed. At the time of the initial EAP 236 exchange, the peer and the server also derive an EMSK, which is used 237 to derive a re-authentication Root Key (rRK). More precisely, a re- 238 authentication Root Key is derived from the EMSK or from a Domain- 239 Specific Root Key (DSRK), which itself is derived from the EMSK. The 240 rRK is only available to the peer and the ER server and is never 241 handed out to any other entity. Further, a re-authentication 242 Integrity Key (rIK) is derived from the rRK; the peer and the ER 243 server use the rIK to provide proof of possession while performing an 244 ERP exchange. The rIK is also never handed out to any entity and is 245 only available to the peer and server. 247 When the ER server is in the home domain, the peer and the server use 248 the rIK and rRK derived from the EMSK; and when the ER server is not 249 in the home domain, they use the DS-rIK and DS-rRK corresponding to 250 the local domain. The domain of the ER server is identified by the 251 realm portion of the keyname-NAI in ERP messages. 253 3.1. ERP With the Home ER Server 255 EAP Peer EAP Authenticator EAP Server 256 ======== ================= ========== 258 <--- EAP-Request/ ------ 259 Identity 261 ----- EAP Response/ ---> 262 Identity ---AAA(EAP Response/Identity)--> 264 <--- EAP Method -------> <------ AAA(EAP Method --------> 265 exchange exchange) 267 <----AAA(MSK, EAP-Success)------ 269 <---EAP-Success--------- 271 Figure 1: EAP Authentication 273 Peer Authenticator Server 274 ==== ============= ====== 276 [<-- EAP-Initiate/ ----- 277 Re-auth-Start] 278 [<-- EAP-Request/ ------ 279 Identity] 281 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 282 Re-auth/ Re-auth/ 283 [Bootstrap] [Bootstrap]) 285 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 286 Re-auth/ Re-auth/ 287 [Bootstrap] [Bootstrap]) 289 Note: [] brackets indicate optionality. 291 Figure 2: ERP Exchange 293 Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this 294 document for the purpose of EAP re-authentication. When the peer 295 identifies a target authenticator that supports EAP re- 296 authentication, it performs an ERP exchange, as shown in Figure 2; 297 the exchange itself may happen when the peer attaches to a new 298 authenticator supporting EAP re-authentication, or prior to 299 attachment. The peer initiates ERP by itself; it may also do so in 300 response to an EAP-Initiate/Re-auth-Start message from the new 301 authenticator. The EAP-Initiate/Re-auth-Start message allows the 302 authenticator to trigger the ERP exchange. 304 It is plausible that the authenticator does not know whether the peer 305 supports ERP and whether the peer has performed a full EAP 306 authentication through another authenticator. The authenticator MAY 307 initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start 308 message, and if there is no response, it will send the EAP-Request/ 309 Identity message. Note that this avoids having two EAP messages in 310 flight at the same time [RFC3748]. The authenticator may send the 311 EAP-Initiate/Re-auth-Start message and wait for a short, locally 312 configured amount of time. If the peer does not already know, this 313 message indicates to the peer that the authenticator supports ERP. 314 In response to this trigger from the authenticator, the peer can 315 initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. 316 If there is no response from the peer after the necessary 317 retransmissions (see Section 6), the authenticator MUST initiate EAP 318 by sending an EAP-Request message, typically the EAP-Request/Identity 319 message. Note that the authenticator may receive an EAP-Initiate/ 320 Re-auth message after it has sent an EAP-Request/Identity message. 321 If the authenticator supports ERP, it MUST proceed with the ERP 322 exchange. When the EAP-Request/Identity times out, the authenticator 323 MUST NOT close the connection if an ERP exchange is in progress or 324 has already succeeded in establishing a re-authentication MSK. 326 If the authenticator does not support ERP, it drops EAP-Initiate/ 327 Re-auth messages [RFC3748] as the EAP code of those packets is 328 greater than 4. An ERP-capable peer will exhaust the EAP-Initiate/ 329 Re-auth message retransmissions and fall back to EAP authentication 330 by responding to EAP Request/Identity messages from the 331 authenticator. If the peer does not support ERP or if it does not 332 have unexpired key material from a previous EAP authentication, it 333 drops EAP-Initiate/Re-auth-Start messages. If there is no response 334 to the EAP-Initiate/Re-auth-Start message, the authenticator SHALL 335 send an EAP Request message (typically EAP Request/Identity) to start 336 EAP authentication. From this stage onwards, RFC 3748 rules apply. 337 Note that this may introduce some delay in starting EAP. In some 338 lower layers, the delay can be minimized or even avoided by the peer 339 initiating EAP by sending messages such as EAPoL-Start in the IEEE 340 802.1X specification [IEEE_802.1X]. 342 The peer sends an EAP-Initiate/Re-auth message that contains the 343 keyName-NAI to identify the ER server's domain and the rIK used to 344 protect the message, and a sequence number for replay protection. 345 The EAP-Initiate/Re-auth message is integrity protected with the rIK. 346 The authenticator uses the realm in the keyName-NAI [RFC4282] field 347 to send the message to the appropriate ER server. The server uses 348 the keyName to look up the rIK. The server, after verifying proof of 349 possession of the rIK, and freshness of the message, derives a re- 350 authentication MSK (rMSK) from the rRK using the sequence number as 351 an input to the key derivation. The server updates the expected 352 sequence number to the received sequence number plus one. 354 In response to the EAP-Initiate/Re-auth message, the server sends an 355 EAP-Finish/Re-auth message; this message is integrity protected with 356 the rIK. The server transports the rMSK along with this message to 357 the authenticator. The rMSK is transported in a manner similar to 358 that of the MSK along with the EAP-Success message in a full EAP 359 exchange. Ongoing work in [RFC5749] describes an additional key 360 distribution protocol that can be used to transport the rRK from an 361 EAP server to one of many different ER servers that share a trust 362 relationship with the EAP server. 364 The peer MAY request the server for the rMSK lifetime. If so, the ER 365 server sends the rMSK lifetime in the EAP-Finish/Re-auth message. 367 In an ERP bootstrap exchange, the peer MAY request the server for the 368 rRK lifetime. If so, the ER server sends the rRK lifetime in the 369 EAP-Finish/Re-auth message. 371 The peer verifies the replay protection and the integrity of the 372 message. It then uses the sequence number in the EAP-Finish/Re-auth 373 message to compute the rMSK. The lower-layer security association 374 protocol is ready to be triggered after this point. 376 3.2. ERP with a Local ER Server 378 The defined ER extensions allow executing the ERP with an ER server 379 in the local domain (access network). The local ER server may be co- 380 located with a local AAA server. The peer may learn about the 381 presence of a local ER server in the network and the local domain 382 name (or ER server name) either via the lower layer or by means of 383 ERP bootstrapping. The peer uses the domain name and the EMSK to 384 compute the DSRK and from that key, the DS-rRK; the peer also uses 385 the domain name in the realm portion of the keyName-NAI for using ERP 386 in the local domain. Figure 3 shows the full EAP and subsequent 387 local ERP exchange; Figure 4 shows it with a local ER server. 389 Peer EAP Authenticator Local ER Server Home EAP Server 390 ==== ================= =============== =============== 392 <-- EAP-Request/ -- 393 Identity 395 -- EAP Response/--> 396 Identity --AAA(EAP Response/--> 397 Identity) --AAA(EAP Response/ --> 398 Identity, 399 [DSRK Request, 400 domain name]) 402 <------------------------ EAP Method exchange------------------> 404 <---AAA(MSK, DSRK, ---- 405 EMSKname, 406 EAP-Success) 408 <--- AAA(MSK, ----- 409 EAP-Success) 411 <---EAP-Success----- 413 Figure 3: Local ERP Exchange, Initial EAP Exchange 415 Peer ER Authenticator Local ER Server 416 ==== ================ =============== 418 [<-- EAP-Initiate/ -------- 419 Re-auth-Start] 420 [<-- EAP-Request/ --------- 421 Identity] 423 ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> 424 Re-auth Re-auth) 426 <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- 427 Re-auth Re-auth) 428 Figure 4: Local ERP Exchange 430 As shown in Figure 4, the local ER server may be present in the path 431 of the full EAP exchange (e.g., this may be one of the AAA entities, 432 such as AAA proxies, in the path between the authenticator and the 433 home EAP server of the peer). In that case, the ER server requests 434 the DSRK by sending the domain name to the EAP server. In response, 435 the EAP server computes the DSRK by following the procedure specified 436 in [RFC5295] and sends the DSRK and the key name, EMSKname, to the ER 437 server in the claimed domain. The local domain is responsible for 438 announcing that same domain name via the lower layer to the peer. 440 If the peer does not know the domain name (did not receive the domain 441 name via the lower-layer announcement, due to a missed announcement 442 or lack of support for domain name announcements in a specific lower 443 layer), it SHOULD initiate ERP bootstrap exchange with the home ER 444 server to obtain the domain name. The local ER server SHALL request 445 the home AAA server for the DSRK by sending the domain name in the 446 AAA message that carries the EAP-Initiate/Re-auth bootstrap message. 447 The local ER server MUST be in the path from the peer to the home ER 448 server. If it is not, it cannot request the DSRK. 450 After receiving the DSRK and the EMSKname, the local ER server 451 computes the DS-rRK and the DS-rIK from the DSRK as defined in 452 Sections 4.1 and 4.3 below. After receiving the domain name, the 453 peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys 454 are referred to by a keyName-NAI formed as follows: the username part 455 of the NAI is the EMSKname, the realm portion of the NAI is the 456 domain name. Both parties also maintain a sequence number 457 (initialized to zero) corresponding to the specific keyName-NAI. 459 Subsequently, when the peer attaches to an authenticator within the 460 local domain, it may perform an ERP exchange with the local ER server 461 to obtain an rMSK for the new authenticator. 463 4. ER Key Hierarchy 465 Each time the peer re-authenticates to the network, the peer and the 466 authenticator establish an rMSK. The rMSK serves the same purposes 467 that an MSK, which is the result of full EAP authentication, serves. 468 To prove possession of the rRK, we specify the derivation of another 469 key, the rIK. These keys are derived from the rRK. Together they 470 constitute the ER key hierarchy. 472 The rRK is derived from either the EMSK or a DSRK as specified in 473 Section 4.1. For the purpose of rRK derivation, this document 474 specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- 475 Specific USRK (DSUSRK) in accordance with [RFC5295] for re- 476 authentication. The USRK designated for re-authentication is the re- 477 authentication root key (rRK). A DSUSRK designated for re- 478 authentication is the DS-rRK available to a local ER server in a 479 particular domain. For simplicity, the keys are referred to without 480 the DS label in the rest of the document. However, the scope of the 481 various keys is limited to just the respective domains they are 482 derived for, in the case of the domain specific keys. Based on the 483 ER server with which the peer performs the ERP exchange, it knows the 484 corresponding keys that must be used. 486 The rRK is used to derive an rIK, and rMSKs for one or more 487 authenticators. The figure below shows the key hierarchy with the 488 rRK, rIK, and rMSKs. 490 rRK 491 | 492 +--------+--------+ 493 | | | 494 rIK rMSK1 ...rMSKn 496 Figure 5: Re-authentication Key Hierarchy 498 The derivations in this document are according to [RFC5295]. Key 499 derivations and field encodings, where unspecified, default to that 500 document. 502 4.1. rRK Derivation 504 The rRK may be derived from the EMSK or DSRK. This section provides 505 the relevant key derivations for that purpose. 507 The rRK is derived as specified in [RFC5295]. 509 rRK = KDF (K, S), where 511 K = EMSK or K = DSRK and 513 S = rRK Label | "\0" | length 515 The rRK Label is an IANA-assigned 8-bit ASCII string: 517 EAP Re-authentication Root Key@ietf.org 519 assigned from the "USRK key labels" name space in accordance with 520 [RFC5295]. 522 The KDF and algorithm agility for the KDF are as defined in 524 [RFC5295]. 526 An rRK derived from the DSRK is referred to as a DS-rRK in the rest 527 of the document. All the key derivation and properties specified in 528 this section remain the same. 530 4.2. rRK Properties 532 The rRK has the following properties. These properties apply to the 533 rRK regardless of the parent key used to derive it. 535 o The length of the rRK MUST be equal to the length of the parent 536 key used to derive it. 538 o The rRK is to be used only as a root key for re-authentication and 539 never used to directly protect any data. 541 o The rRK is only used for derivation of rIK and rMSK as specified 542 in this document. 544 o The rRK MUST remain on the peer and the server that derived it and 545 MUST NOT be transported to any other entity. 547 o The lifetime of the rRK is never greater than that of its parent 548 key. The rRK is expired when the parent key expires and MUST be 549 removed from use at that time. 551 4.3. rIK Derivation 553 The re-authentication Integrity Key (rIK) is used for integrity 554 protecting the ERP exchange. This serves as the proof of possession 555 of valid keying material from a previous full EAP exchange by the 556 peer to the server. 558 The rIK is derived as follows. 560 rIK = KDF (K, S), where 562 K = rRK and 564 S = rIK Label | "\0" | cryptosuite | length 566 The rIK Label is the 8-bit ASCII string: 568 Re-authentication Integrity Key@ietf.org 570 The length field refers to the length of the rIK in octets encoded as 571 specified in [RFC5295]. 573 The cryptosuite and length of the rIK are part of the input to the 574 key derivation function to ensure cryptographic separation of keys if 575 different rIKs of different lengths for use with different Message 576 Authentication Code (MAC) algorithms are derived from the same rRK. 577 The cryptosuite is encoded as an 8-bit number; see Section 5.3.2 for 578 the cryptosuite specification. 580 The rIK is referred to by EMSKname-NAI within the context of ERP 581 messages. The username part of EMSKname-NAI is the EMSKname; the 582 realm is the domain name of the ER server. In case of ERP with the 583 home ER server, the peer uses the realm from its original NAI; in 584 case of a local ER server, the peer uses the domain name received at 585 the lower layer or through an ERP bootstrapping exchange. 587 An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest 588 of the document. All the key derivation and properties specified in 589 this section remain the same. 591 4.4. rIK Properties 593 The rIK has the following properties. 595 o The length of the rIK MUST be equal to the length of the rRK. 597 o The rIK is only used for authentication of the ERP exchange as 598 specified in this document. 600 o The rIK MUST NOT be used to derive any other keys. 602 o The rIK must remain on the peer and the server and MUST NOT be 603 transported to any other entity. 605 o The rIK is cryptographically separate from any other keys derived 606 from the rRK. 608 o The lifetime of the rIK is never greater than that of its parent 609 key. The rIK MUST be expired when the EMSK expires and MUST be 610 removed from use at that time. 612 4.5. rIK Usage 614 The rIK is the key whose possession is demonstrated by the peer and 615 the ERP server to the other party. The peer demonstrates possession 616 of the rIK by computing the integrity checksum over the EAP-Initiate/ 617 Re-auth message. When the peer uses the rIK for the first time, it 618 can choose the integrity algorithm to use with the rIK. The peer and 619 the server MUST use the same integrity algorithm with a given rIK for 620 all ERP messages protected with that key. The peer and the server 621 store the algorithm information after the first use, and they employ 622 the same algorithm for all subsequent uses of that rIK. 624 If the server's policy does not allow the use of the cryptosuite 625 selected by the peer, the server SHALL reject the EAP-Initiate/ 626 Re-auth message and SHOULD send a list of acceptable cryptosuites in 627 the EAP-Finish/Re-auth message. 629 The rIK length may be different from the key length required by an 630 integrity algorithm. In case of hash-based MAC algorithms, the key 631 is first hashed to the required key length as specified in [RFC2104]. 632 In case of cipher-based MAC algorithms, if the required key length is 633 less than 32 octets, the rIK is hashed using HMAC-SHA256 and the 634 first k octets of the output are used, where k is the key length 635 required by the algorithm. If the required key length is more than 636 32 octets, the first k octets of the rIK are used by the cipher-based 637 MAC algorithm. 639 4.6. rMSK Derivation 641 The rMSK is derived at the peer and server and delivered to the 642 authenticator. The rMSK is derived following an EAP Re-auth Protocol 643 exchange. 645 The rMSK is derived as follows. 647 rMSK = KDF (K, S), where 649 K = rRK and 651 S = rMSK label | "\0" | SEQ | length 653 The rMSK label is the 8-bit ASCII string: 655 Re-authentication Master Session Key@ietf.org 657 The length field refers to the length of the rMSK in octets. The 658 length field is encoded as specified in [RFC5295]. 660 SEQ is the sequence number sent by the peer in the EAP-Initiate/ 661 Re-auth message. This field is encoded as a 16-bit number in network 662 byte order (see Section 5.3.2). 664 An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest 665 of the document. All the key derivation and properties specified in 666 this section remain the same. 668 4.7. rMSK Properties 670 The rMSK has the following properties: 672 o The length of the rMSK MUST be equal to the length of the rRK. 674 o The rMSK is delivered to the authenticator and is used for the 675 same purposes that an MSK is used at an authenticator. 677 o The rMSK is cryptographically separate from any other keys derived 678 from the rRK. 680 o The lifetime of the rMSK is less than or equal to that of the rRK. 681 It MUST NOT be greater than the lifetime of the rRK. 683 o If a new rRK is derived, subsequent rMSKs MUST be derived from the 684 new rRK. Previously delivered rMSKs MAY still be used until the 685 expiry of the lifetime. 687 o A given rMSK MUST NOT be shared by multiple authenticators. 689 5. Protocol Details 691 5.1. ERP Bootstrapping 693 We identify two types of bootstrapping for ERP: explicit and implicit 694 bootstrapping. In implicit bootstrapping, the local ER server SHOULD 695 include its domain name and SHOULD request the DSRK from the home AAA 696 server during the initial EAP exchange, in the AAA message 697 encapsulating the first EAP Response message sent by the peer. If 698 the EAP exchange is successful, the server sends the DSRK for the 699 local ER server (derived using the EMSK and the domain name as 700 specified in [RFC5295]), EMSKname, and DSRK lifetime along with the 701 EAP-Success message. The local ER server MUST extract the DSRK, 702 EMSKname, and DSRK lifetime (if present) before forwarding the EAP- 703 Success message to the peer, as specified in [I-D.ietf-dime-erp]. 704 Note that the MSK (also present along with the EAP Success message) 705 is extracted by the EAP authenticator as usual. The peer learns the 706 domain name through the EAP-Initiate/Re-auth-Start message or via 707 lower-layer announcements. When the domain name is available to the 708 peer during or after the full EAP authentication, it attempts to use 709 ERP when it associates with a new authenticator. 711 If the peer does not know the domain name (did not receive the domain 712 name via the lower-layer announcement, due to a missed announcement 713 or lack of support for domain name announcements in a specific lower 714 layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with 715 the bootstrap flag turned on) with the home ER server to obtain the 716 domain name. The local ER server behavior is the same as described 717 above. The peer MAY also initiate bootstrapping to fetch information 718 such as the rRK lifetime from the AAA server. 720 The following steps describe the ERP explicit bootstrapping process: 722 o The peer sends the EAP-Initiate/Re-auth message with the 723 bootstrapping flag turned on. The bootstrap message is always 724 sent to the home AAA server, and the keyname-NAI attribute in the 725 bootstrap message is constructed as follows: the username portion 726 of the NAI contains the EMSKname, and the realm portion contains 727 the home domain name. 729 o In addition, the message MUST contain a sequence number for replay 730 protection, a cryptosuite, and an integrity checksum. The 731 cryptosuite indicates the authentication algorithm. The integrity 732 checksum indicates that the message originated at the claimed 733 entity, the peer indicated by the Peer-ID, or the rIKname. 735 o The peer MAY additionally set the lifetime flag to request the key 736 lifetimes. 738 o When an ERP-capable authenticator receives the EAP-Initiate/ 739 Re-auth message from a peer, it copies the contents of the 740 keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The 741 rest of the process is similar to that described in [RFC3579]. 743 o If a local ER server is present, the local ER server MUST include 744 the DSRK request and its domain name in the AAA message 745 encapsulating the EAP-Initiate/Re-auth message sent by the peer. 747 o Upon receipt of an EAP-Initiate/Re-auth message, the server 748 verifies whether the message is fresh or is a replay by evaluating 749 whether the received sequence number is equal to or greater than 750 the expected sequence number for that rIK. The server then 751 verifies to ensure that the cryptosuite used by the peer is 752 acceptable. Next, it verifies the origin authentication of the 753 message by looking up the rIK. If any of the checks fail, the 754 server sends an EAP-Finish/Re-auth message with the Result flag 755 set to '1'. Please refer to Section 5.2.2 for details on failure 756 handling. This error MUST NOT have any correlation to any EAP- 757 Success message that may have been received by the EAP 758 authenticator and the peer earlier. If the EAP-Initiate/Re-auth 759 message is well-formed and valid, the server prepares the EAP- 760 Finish/Re-auth message. The bootstrap flag MUST be set to 761 indicate that this is a bootstrapping exchange. The message 762 contains the following fields: 764 * A sequence number for replay protection. 766 * The same keyName-NAI as in the EAP-Initiate/Re-auth message. 768 * If the lifetime flag was set in the EAP-Initiate/Re-auth 769 message, the ER server SHOULD include the rRK lifetime and the 770 rMSK lifetime in the EAP-Finish/Re-auth message. The server 771 may have a local policy for the network to maintain and enforce 772 lifetime unilaterally. In such cases, the server need not 773 respond to the peer's request for the lifetime. 775 * If the bootstrap flag is set and a DSRK request is received, 776 the server MUST include the domain name to which the DSRK is 777 being sent. 779 * If the home ER server verifies the authorization of a local 780 domain server, it MAY include the Authorization Indication TLV 781 to indicate to the peer that the server (that received the DSRK 782 and that is advertising the domain included in the domain name 783 TLV) is authorized. 785 * An authentication tag MUST be included to prove that the EAP- 786 Finish/Re-auth message originates at a server that possesses 787 the rIK corresponding to the EMSKname-NAI. 789 o If the ERP exchange is successful, and the local ER server sent a 790 DSRK request, the home ER server MUST include the DSRK for the 791 local ER server (derived using the EMSK and the domain name as 792 specified in [RFC5295]), EMSKname, and DSRK lifetime along with 793 the EAP-Finish/Re-auth message. 795 o In addition, the rMSK is sent along with the EAP-Finish/Re-auth 796 message, in a AAA attribute [I-D.ietf-dime-erp]. 798 o The local ER server MUST extract the DSRK, EMSKname, and DSRK 799 lifetime (if present), before forwarding the EAP-Finish/Re-auth 800 message to the peer, as specified in [I-D.ietf-dime-erp]. 802 o The authenticator receives the rMSK. 804 o When the peer receives an EAP-Finish/Re-auth message with the 805 bootstrap flag set, if a local domain name is present, it MUST use 806 that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- 807 NAI, and initialize the replay counter for the DS-rIK. If not, 808 the peer SHOULD derive the domain-specific keys using the domain 809 name it learned via the lower layer or from the EAP-Initiate/ 810 Re-auth-Start message. If the peer does not know the domain name, 811 it must assume that there is no local ER server available. 813 o The peer MAY also verify the Authorization Indication TLV. 815 o The procedures for encapsulating the ERP and obtaining relevant 816 keys using Diameter are specified in [I-D.ietf-dime-erp]. 818 Since the ER bootstrapping exchange is typically done immediately 819 following the full EAP exchange, it is feasible that the process is 820 completed through the same entity that served as the EAP 821 authenticator for the full EAP exchange. In this case, the lower 822 layer may already have established TSKs based on the MSK received 823 earlier. The lower layer may then choose to ignore the rMSK that was 824 received with the ER bootstrapping exchange. Alternatively, the 825 lower layer may choose to establish a new TSK using the rMSK. In 826 either case, the authenticator and the peer know which key is used 827 based on whether or not a TSK establishment exchange is initiated. 828 The bootstrapping exchange may also be carried out via a new 829 authenticator, in which case, the rMSK received SHOULD trigger a 830 lower layer TSK establishment exchange. 832 5.2. Steps in ERP 834 When a peer that has an active rRK and rIK associates with a new 835 authenticator that supports ERP, it may perform an ERP exchange with 836 that authenticator. ERP is typically a peer-initiated exchange, 837 consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth 838 message. The ERP exchange may be performed with a local ER server 839 (when one is present) or with the original EAP server. 841 It is plausible for the network to trigger the EAP re-authentication 842 process, however. An ERP-capable authenticator SHOULD send an EAP- 843 Initiate/Re-auth-Start message to indicate support for ERP. The peer 844 may or may not wait for these messages to arrive to initiate the EAP- 845 Initiate/Re-auth message. 847 The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- 848 capable authenticator. The authenticator may retransmit it a few 849 times until it receives an EAP-Initiate/Re-auth message in response 850 from the peer. The EAP-Initiate/Re-auth message from the peer may 851 have originated before the peer receives either an EAP-Request/ 852 Identity or an EAP-Initiate/Re-auth-Start message from the 853 authenticator. Hence, the Identifier value in the EAP-Initiate/ 854 Re-auth message is independent of the Identifier value in the EAP- 855 Initiate/Re-auth-Start or the EAP-Request/Identity messages. 857 Operational Considerations at the Peer: 859 ERP requires that the peer maintain retransmission timers for 860 reliable transport of EAP re-authentication messages. The 861 reliability considerations of Section 4.3 of RFC 3748 apply with the 862 peer as the retransmitting entity. 864 The EAP Re-auth Protocol has the following steps: 866 The peer sends an EAP-Initiate/Re-auth message. At a minimum, the 867 message SHALL include the following fields: 869 a 16-bit sequence number for replay protection 871 keyName-NAI as a TLV attribute to identify the rIK used to 872 integrity protect the message. 874 cryptosuite to indicate the authentication algorithm used to 875 compute the integrity checksum. 877 authentication tag over the message. 879 When the peer is performing ERP with a local ER server, it MUST 880 use the corresponding DS-rIK it shares with the local ER server. 881 The peer SHOULD set the lifetime flag to request the key lifetimes 882 from the server. The peer can use the rRK lifetime to know when 883 to trigger an EAP method exchange and the rMSK lifetime to know 884 when to trigger another ERP exchange. 886 The authenticator copies the contents of the value field of the 887 keyName-NAI TLV into the User-Name RADIUS attribute in the AAA 888 message to the ER server. 890 The server uses the keyName-NAI to look up the rIK. It MUST first 891 verify whether the sequence number is equal to or greater than the 892 expected sequence number. If the server supports a sequence 893 number window size greater than 1, it MUST verify whether the 894 sequence number falls within the window and has not been received 895 before. The server MUST then verify to ensure that the 896 cryptosuite used by the peer is acceptable. The server then 897 proceeds to verify the integrity of the message using the rIK, 898 thereby verifying proof of possession of that key by the peer. If 899 any of these verifications fail, the server MUST send an EAP- 900 Finish/Re-auth message with the Result flag set to '1' (Failure). 901 Please refer to Section 5.2.2 for details on failure handling. 902 Otherwise, it MUST compute an rMSK from the rRK using the sequence 903 number as the additional input to the key derivation. 905 In response to a well-formed EAP Re-auth/Initiate message, the 906 server MUST send an EAP-Finish/Re-auth message with the following 907 considerations: 909 a 16-bit sequence number for replay protection, which MUST be 910 the same as the received sequence number. The local copy of 911 the sequence number MUST be incremented by 1. If the server 912 supports multiple simultaneous ERP exchanges, it MUST instead 913 update the sequence number window. 915 keyName-NAI as a TLV attribute to identify the rIK used to 916 integrity protect the message. 918 cryptosuite to indicate the authentication algorithm used to 919 compute the integrity checksum. 921 authentication tag over the message. 923 If the lifetime flag was set in the EAP-Initiate/Re-auth 924 message, the ER server SHOULD include the rRK lifetime and the 925 rMSK lifetime. 927 The server transports the rMSK along with this message to the 928 authenticator. The rMSK is transported in a manner similar to the 929 MSK transport along with the EAP-Success message in a regular EAP 930 exchange. 932 The peer looks up the sequence number to verify whether it is 933 expecting an EAP-Finish/Re-auth message with that sequence number 934 protected by the keyName-NAI. It then verifies the integrity of 935 the message. If the verifications fail, the peer logs an error 936 and stops the process; otherwise, it proceeds to the next step. 938 The peer uses the sequence number to compute the rMSK. 940 The lower-layer security association protocol can be triggered at 941 this point. 943 5.2.1. Multiple Simultaneous Runs of ERP 945 When a peer is within the range of multiple authenticators, it may 946 choose to run ERP via all of them simultaneously to the same ER 947 server. In that case, it is plausible that the ERP messages may 948 arrive out of order, resulting in the ER server rejecting legitimate 949 EAP-Initiate/Re-auth messages. 951 To facilitate such operation, an ER server MAY allow multiple 952 simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth 953 messages with SEQ number values within a window of allowed values. 954 Recall that the SEQ number allows replay protection. Replay window 955 maintenance mechanisms are a local matter. 957 5.2.2. ERP Failure Handling 959 If the processing of the EAP-Initiate/Re-auth message results in a 960 failure, the ER server MUST send an EAP-Finish Re-auth message with 961 the Result flag set to '1'. If the server has a valid rIK for the 962 peer, it MUST integrity protect the EAP-Finish/Re-auth failure 963 message. If the failure is due to an unacceptable cryptosuite, the 964 server SHOULD send a list of acceptable cryptosuites (in a TLV of 965 Type 5) along with the EAP-Finish/Re-auth message. In this case, the 966 server MUST indicate the cryptosuite used to protect the EAP-Finish/ 967 Re-auth message in the cryptosuite. The rIK used with the EAP- 968 Finish/Re-auth message in this case MUST be computed as specified in 969 Section 4.3 using the new cryptosuite. If the server does not have a 970 valid rIK for the peer, the EAP-Finish/Re-auth message indicating a 971 failure will be unauthenticated; the server MAY include a list of 972 acceptable cryptosuites in the message. 974 The peer, upon receiving an EAP-Finish/Re-auth message with the 975 Result flag set to '1', MUST verify the sequence number and the 976 Authentication Tag to determine the validity of the message. If the 977 peer supports the cryptosuite, it MUST verify the integrity of the 978 received EAP-Finish/Re-auth message. If the EAP-Finish message 979 contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with 980 a cryptosuite picked from the list included by the server. The peer 981 MUST use the appropriate rIK for the subsequent ERP exchange, by 982 computing it with the corresponding cryptosuite, as specified in 983 Section 4.3. If the PRF in the chosen cryptosuite is different from 984 the PRF originally used by the peer, it MUST derive a new DSRK (if 985 required), rRK, and rIK before proceeding with the subsequent ERP 986 exchange. 988 If the peer cannot verify the integrity of the received message, it 989 MAY choose to retry the ERP exchange with one of the cryptosuites in 990 the TLV of Type 5, after a failure has been clearly determined 991 following the procedure in the next paragraph. 993 If the replay or integrity checks fail, the failure message may have 994 been sent by an attacker. It may also imply that the server and peer 995 do not support the same cryptosuites; however, the peer cannot 996 determine if that is the case. Hence, the peer SHOULD continue the 997 ERP exchange per the retransmission timers before declaring a 998 failure. 1000 When the peer runs explicit bootstrapping (ERP with the bootstrapping 1001 flag on), there may not be a local ER server available to send a DSRK 1002 Request and the domain name. In that case, the server cannot send 1003 the DSRK and MUST NOT include the domain name TLV. When the peer 1004 receives a response in the bootstrapping exchange without a domain 1005 name TLV, it assumes that there is no local ER server. The home ER 1006 server sends an rMSK to the ER authenticator, however, and the peer 1007 SHALL run the TSK establishment protocol as usual. 1009 5.3. New EAP Packets 1011 Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate 1012 and EAP-Finish. The packet format for these messages follows the EAP 1013 packet format defined in RFC 3748 [RFC3748]. 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Code | Identifier | Length | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Type | Type-Data ... 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1023 Figure 6: EAP Packet 1025 Code 1027 5 Initiate 1029 6 Finish 1031 Two new code values are defined for the purpose of ERP. 1033 Identifier 1035 The Identifier field is one octet. The Identifier field MUST 1036 be the same if an EAP-Initiate packet is retransmitted due to a 1037 timeout while waiting for a Finish message. Any new (non- 1038 retransmission) Initiate message MUST use a new Identifier 1039 field. 1041 The Identifier field of the Finish message MUST match that of 1042 the currently outstanding Initiate message. A peer or 1043 authenticator receiving a Finish message whose Identifier value 1044 does not match that of the currently outstanding Initiate 1045 message MUST silently discard the packet. 1047 In order to avoid confusion between new EAP-Initiate messages 1048 and retransmissions, the peer must choose an Identifier value 1049 that is different from the previous EAP-Initiate message, 1050 especially if that exchange has not finished. It is 1051 RECOMMENDED that the authenticator clear EAP Re-auth state 1052 after 300 seconds. 1054 Type 1056 This field indicates that this is an ERP exchange. Two type 1057 values are defined in this document for this purpose -- Re- 1058 auth-Start (assigned Type 1) and Re-auth (assigned Type 2). 1060 Type-Data 1062 The Type-Data field varies with the Type of re-authentication 1063 packet. 1065 5.3.1. EAP-Initiate/Re-auth-Start Packet 1067 The EAP-Initiate/Re-auth-Start packet contains the parameters shown 1068 in Figure 7. 1070 0 1 2 3 1071 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 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Code | Identifier | Length | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Type | Reserved | 1 or more TVs or TLVs ~ 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 Figure 7: EAP-Initiate/Re-auth-Start Packet 1080 Type = 1. 1082 Reserved, MUST be zero. Set to zero on transmission and ignored 1083 on reception. 1085 One or more TVs or TLVs are used to convey information to the 1086 peer; for instance, the authenticator may send the domain name to 1087 the peer. 1089 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1090 and a value with type-specific length. In the TLV payloads, there 1091 is a 1-octet type payload and a 1-octet length payload. The 1092 length field indicates the length of the value expressed in number 1093 of octets. 1095 Domain-Name: This is a TLV payload. The Type is 4. The domain 1096 name is to be used as the realm in an NAI [RFC4282]. The 1097 Domain-Name attribute SHOULD be present in an EAP-Initiate/ 1098 Re-auth-Start message. 1100 In addition, channel binding information MAY be included; see 1101 Section 5.5 for discussion. See Figure 11 for parameter 1102 specification. 1104 5.3.1.1. Authenticator Operation 1106 The authenticator MAY send the EAP-Initiate/Re-auth-Start message to 1107 indicate support for ERP to the peer and to initiate ERP if the peer 1108 has already performed full EAP authentication and has unexpired key 1109 material. The authenticator SHOULD include the domain name TLV to 1110 allow the peer to learn it without lower-layer support or the ERP 1111 bootstrapping exchange. 1113 The authenticator MAY include channel binding information so that the 1114 peer can send the information to the server in the EAP-Initiate/ 1115 Re-auth message so that the server can verify whether the 1116 authenticator is claiming the same identity to both parties. 1118 The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start 1119 message a few times for reliable transport. 1121 5.3.1.2. Peer Operation 1123 The peer SHOULD send the EAP-Initiate/Re-auth message in response to 1124 the EAP-Initiate/Re-auth-Start message from the authenticator. If 1125 the peer does not recognize the Initiate code value, it silently 1126 discards the message. If the peer has already sent the EAP-Initiate/ 1127 Re-auth message to begin the ERP exchange, it silently discards the 1128 message. 1130 If the EAP-Initiate/Re-auth-Start message contains the domain name, 1131 and if the peer does not already have the domain information, the 1132 peer SHOULD use the domain name to compute the DSRK and use the 1133 corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start 1134 an ERP exchange with the local ER server. If the peer has already 1135 initiated an ERP exchange with the home ER server, it MAY choose to 1136 not start an ERP exchange with the local ER server. 1138 5.3.2. EAP-Initiate/Re-auth Packet 1140 The EAP-Initiate/Re-auth packet contains the parameters shown in 1141 Figure 8. 1143 0 1 2 3 1144 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 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Code | Identifier | Length | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Type |R|B|L| Reserved| SEQ | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | 1 or more TVs or TLVs ~ 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | cryptosuite | Authentication Tag ~ 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 Figure 8: EAP-Initiate/Re-auth Packet 1157 Type = 2. 1159 Flags 1161 'R' - The R flag is set to 0 and ignored upon reception. 1163 'B' - The B flag is used as the bootstrapping flag. If the 1164 flag is turned on, the message is a bootstrap message. 1166 'L' - The L flag is used to request the key lifetimes from the 1167 server. 1169 The rest of the 5 bits are set to 0 and ignored on reception. 1171 SEQ: A 16-bit sequence number is used for replay protection. The 1172 SEQ number field is initialized to 0 every time a new rRK is 1173 derived. 1175 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1176 and a value with type-specific length. In the TLV payloads, there 1177 is a 1-octet type payload and a 1-octet length payload. The 1178 length field indicates the length of the value expressed in number 1179 of octets. 1181 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1182 The NAI is variable in length, not exceeding 253 octets. The 1183 EMSKname is in the username part of the NAI and is encoded in 1184 hexadecimal values. The EMSKname is 64 bits in length and so 1185 the username portion takes up 128 octets. If the rIK is 1186 derived from the EMSK, the realm part of the NAI is the home 1187 domain name, and if the rIK is derived from a DSRK, the realm 1188 part of the NAI is the domain name used in the derivation of 1189 the DSRK. The NAI syntax follows [RFC4282]. Exactly one 1190 keyName-NAI attribute SHALL be present in an EAP-Initiate/ 1191 Re-auth packet. 1193 In addition, channel binding information MAY be included; see 1194 Section 5.5 for discussion. See Figure 11 for parameter 1195 specification. 1197 Cryptosuite: This field indicates the integrity algorithm used for 1198 ERP. Key lengths and output lengths are either indicated or are 1199 obvious from the cryptosuite name. We specify some cryptosuites 1200 below: 1202 * 0 RESERVED 1204 * 1 HMAC-SHA256-64 1206 * 2 HMAC-SHA256-128 1208 * 3 HMAC-SHA256-256 1210 HMAC-SHA256-128 is mandatory to implement and should be enabled in 1211 the default configuration. 1213 Authentication Tag: This field contains the integrity checksum 1214 over the ERP packet, excluding the authentication tag field 1215 itself. The length of the field is indicated by the Cryptosuite. 1217 5.3.3. EAP-Finish/Re-auth Packet 1219 The EAP-Finish/Re-auth packet contains the parameters shown in 1220 Figure 9. 1222 0 1 2 3 1223 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 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | Code | Identifier | Length | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | Type |R|B|L| Reserved | SEQ ~ 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | 1 or more TVs or TLVs ~ 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | cryptosuite | Authentication Tag ~ 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 Figure 9: EAP-Finish/Re-auth Packet 1236 Type = 2. 1238 Flags 1240 'R' - The R flag is used as the Result flag. When set to 0, it 1241 indicates success, and when set to '1', it indicates a failure. 1243 'B' - The B flag is used as the bootstrapping flag. If the 1244 flag is turned on, the message is a bootstrap message. 1246 'L' - The L flag is used to indicate the presence of the rRK 1247 lifetime TLV. 1249 The rest of the 5 bits are set to 0 and ignored on reception. 1251 SEQ: A 16-bit sequence number is used for replay protection. The 1252 SEQ number field is initialized to 0 every time a new rRK is 1253 derived. 1255 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1256 and a value with type-specific length. In the TLV payloads, there 1257 is a 1-octet type payload and a 1-octet length payload. The 1258 length field indicates the length of the value expressed in number 1259 of octets. 1261 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1262 The NAI is variable in length, not exceeding 253 octets. 1263 EMSKname is in the username part of the NAI and is encoded in 1264 hexadecimal values. The EMSKname is 64 bits in length and so 1265 the username portion takes up 16 octets. If the rIK is derived 1266 from the EMSK, the realm part of the NAI is the home domain 1267 name, and if the rIK is derived from a DSRK, the realm part of 1268 the NAI is the domain name used in the derivation of the DSRK. 1269 The NAI syntax follows [RFC4282]. Exactly one instance of the 1270 keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth 1271 message. 1273 rRK Lifetime: This is a TV payload. The Type is 2. The value 1274 field is a 32-bit field and contains the lifetime of the rRK in 1275 seconds. If the 'L' flag is set, the rRK Lifetime attribute 1276 SHOULD be present. 1278 rMSK Lifetime: This is a TV payload. The Type is 3. The value 1279 field is a 32-bit field and contains the lifetime of the rMSK 1280 in seconds. If the 'L' flag is set, the rMSK Lifetime 1281 attribute SHOULD be present. 1283 Domain-Name: This is a TLV payload. The Type is 4. The domain 1284 name is to be used as the realm in an NAI [RFC4282]. Domain- 1285 Name attribute MUST be present in an EAP-Finish/Re-auth message 1286 if the bootstrapping flag is set and if the local ER server 1287 sent a DSRK request. 1289 List of cryptosuites: This is a TLV payload. The Type is 5. 1290 The value field contains a list of cryptosuites, each of size 1 1291 octet. The cryptosuite values are as specified in Figure 8. 1292 The server SHOULD include this attribute if the cryptosuite 1293 used in the EAP-Initiate/Re-auth message was not acceptable and 1294 the message is being rejected. The server MAY include this 1295 attribute in other cases. The server MAY use this attribute to 1296 signal to the peer about its cryptographic algorithm 1297 capabilities. 1299 Authorization Indication: This is a TLV payload. The Type is 1300 6. This attribute MAY be included in the EAP-Finish/Re-auth 1301 message when a DSRK is delivered to a local ER server and if 1302 the home ER server can verify the authorization of the local ER 1303 server to advertise the domain name included in the domain TLV 1304 in the same message. The value field in the TLV contains an 1305 authentication tag computed over the entire packet, starting 1306 from the first bit of the code field to the last bit of the 1307 cryptosuite field, with the value field of the Authorization 1308 Indication TLV filled with all 0s for the computation. The key 1309 used for the computation MUST be derived from the EMSK with key 1310 label "DSRK Delivery Authorized Key@ietf.org" and optional data 1311 containing an ASCII string representing the key management 1312 domain that the DSRK is being derived for. 1314 In addition, channel binding information MAY be included: see 1315 Section 5.5 for discussion. See Figure 11 for parameter 1316 specification. The server sends this information so that the 1317 peer can verify the information seen at the lower layer, if 1318 channel binding is to be supported. 1320 Cryptosuite: This field indicates the integrity algorithm and the 1321 PRF used for ERP. Key lengths and output lengths are either 1322 indicated or are obvious from the cryptosuite name. 1324 Authentication Tag: This field contains the integrity checksum 1325 over the ERP packet, excluding the authentication tag field 1326 itself. The length of the field is indicated by the Cryptosuite. 1328 5.3.4. TV and TLV Attributes 1330 The TV attributes that may be present in the EAP-Initiate or EAP- 1331 Finish messages are of the following format: 1333 0 1 2 3 1334 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 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Type | Value ... 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 Figure 10: TV Attribute Format 1341 The TLV attributes that may be present in the EAP-Initiate or EAP- 1342 Finish messages are of the following format: 1344 0 1 2 3 1345 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 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Type | Length | Value ... 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 Figure 11: TLV Attribute Format 1352 The following Types are defined in this document: 1354 '1' - keyName-NAI: This is a TLV payload. 1356 '2' - rRK Lifetime: This is a TV payload. 1358 '3' - rMSK Lifetime: This is a TV payload. 1360 '4' - domain name: This is a TLV payload. 1362 '5' - cryptosuite list: This is a TLV payload. 1364 '6' - Authorization Indication: This is a TLV payload. 1366 The TLV type range of 128-191 is reserved to carry channel binding 1367 information in the EAP-Initiate and Finish/Re-auth messages. 1368 Below are the current assignments (all of them are TLVs): 1370 '128' - Called-Station-Id [RFC2865] 1372 '129' - Calling-Station-Id [RFC2865] 1373 '130' - NAS-Identifier [RFC2865] 1375 '131' - NAS-IP-Address [RFC2865] 1377 '132' - NAS-IPv6-Address [RFC3162] 1379 The length field indicates the length of the value part of the 1380 attribute in octets. 1382 5.4. Replay Protection 1384 For replay protection, ERP uses sequence numbers. The sequence 1385 number is maintained per rIK and is initialized to zero in both 1386 directions. In the first EAP-Initiate/Re-auth message, the peer uses 1387 the sequence number zero or higher. Note that the when the sequence 1388 number rotates, the rIK MUST be changed by running EAP 1389 authentication. The server expects a sequence number of zero or 1390 higher. When the server receives an EAP-Initiate/Re-auth message, it 1391 uses the same sequence number in the EAP-Finish/Re-auth message. The 1392 server then sets the expected sequence number to the received 1393 sequence number plus 1. The server accepts sequence numbers greater 1394 than or equal to the expected sequence number. 1396 If the peer sends an EAP-Initiate/Re-auth message, but does not 1397 receive a response, it retransmits the request (with no changes to 1398 the message itself) a pre-configured number of times before giving 1399 up. However, it is plausible that the server itself may have 1400 responded to the message and it was lost in transit. Thus, the peer 1401 MUST increment the sequence number and use the new sequence number to 1402 send subsequent EAP re-authentication messages. The peer SHOULD 1403 increment the sequence number by 1; however, it may choose to 1404 increment by a larger number. When the sequence number rotates, the 1405 peer MUST run full EAP authentication. 1407 5.5. Channel Binding 1409 ERP provides a protected facility to carry channel binding (CB) 1410 information, according to the guidelines in Section 7.15 of 1411 [RFC3748]. The TLV type range of 128-191 is reserved to carry CB 1412 information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth 1413 messages. Called-Station-Id, Calling-Station-Id, NAS-Identifier, 1414 NAS-IP-Address, and NAS-IPv6-Address are some examples of channel 1415 binding information listed in RFC 3748, and they are assigned values 1416 128-132. Additional values are IANA managed based on IETF Consensus 1417 [RFC5226]. 1419 The authenticator MAY provide CB information to the peer via the EAP- 1420 Initiate/Re-auth-Start message. The peer sends the information to 1421 the server in the EAP-Initiate/Re-auth message; the server verifies 1422 whether the authenticator identity available via AAA attributes is 1423 the same as the identity provided to the peer. 1425 If the peer does not include the CB information in the EAP-Initiate/ 1426 Re-auth message, and if the local ER server's policy requires channel 1427 binding support, it SHALL send the CB attributes for the peer's 1428 verification. The peer attempts to verify the CB information if the 1429 authenticator has sent the CB parameters, and it proceeds with the 1430 lower-layer security association establishment if the attributes 1431 match. Otherwise, the peer SHALL NOT proceed with the lower-layer 1432 security association establishment. 1434 6. Lower-Layer Considerations 1436 The authenticator is responsible for retransmission of EAP-Initiate/ 1437 Re-auth-Start messages. The authenticator MAY retransmit the message 1438 a few times or until it receives an EAP-Initiate/Re-auth message from 1439 the peer. The authenticator may not know whether the peer supports 1440 ERP; in those cases, the peer may be silently dropping the EAP- 1441 Initiate/Re-auth-Start packets. Thus, retransmission of these 1442 packets should be kept to a minimum. The exact number is up to each 1443 lower layer. 1445 The Identifier value in the EAP-Initiate/Re-auth packet is 1446 independent of the Identifier value in the EAP-Initiate/Re-auth-Start 1447 packet. 1449 The peer is responsible for retransmission of EAP-Initiate/Re-auth 1450 messages. 1452 Retransmitted packets MUST be sent with the same Identifier value in 1453 order to distinguish them from new packets. By default, where the 1454 EAP-Initiate message is sent over an unreliable lower layer, the 1455 retransmission timer SHOULD be dynamically estimated. A maximum of 1456 3-5 retransmissions is suggested (this is based on the recommendation 1457 of [RFC3748]). Where the EAP-Initiate message is sent over a 1458 reliable lower layer, the retransmission timer SHOULD be set to an 1459 infinite value, so that retransmissions do not occur at the EAP 1460 layer. Please refer to RFC 3748 [RFC3748] for additional guidance on 1461 setting timers. 1463 The Identifier value in the EAP-Finish/Re-auth packet is the same as 1464 the Identifier value in the EAP-Initiate/Re-auth packet. 1466 If an authenticator receives a valid duplicate EAP-Initiate/Re-auth 1467 message for which it has already sent an EAP-Finish/Re-auth message, 1468 it MUST resend the EAP-Finish/Re-auth message without reprocessing 1469 the EAP-Initiate/Re-auth message. To facilitate this, the 1470 authenticator SHALL store a copy of the EAP-Finish/Re-auth message 1471 for a finite amount of time. The actual value of time is a local 1472 matter; this specification recommends a value of 100 milliseconds. 1474 The lower layer may provide facilities for exchanging information 1475 between the peer and the authenticator about support for ERP, for the 1476 authenticator to send the domain name information and channel binding 1477 information to the peer 1479 Note that to support ERP, lower-layer specifications may need to be 1480 revised. Specifically, the IEEE802.1x specification must be revised 1481 to allow carrying EAP messages of the new codes defined in this 1482 document in order to support ERP. Similarly, RFC 4306 must be 1483 updated to include EAP code values higher than 4 in order to use ERP 1484 with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may 1485 also be updated to support peer-initiated ERP for optimized 1486 operation. Other lower layers may need similar revisions. 1488 Our analysis indicates that some EAP implementations are not RFC 3748 1489 compliant in that instead of silently dropping EAP packets with code 1490 values higher than 4, they may consider it an error. To accommodate 1491 such non-compliant EAP implementations, additional guidance has been 1492 provided below. Furthermore, it may not be easy to upgrade all the 1493 peers in some cases. In such cases, authenticators may be configured 1494 to not send EAP-Initiate/Re-auth-Start; peers may learn whether an 1495 authenticator supports ERP via configuration, from advertisements at 1496 the lower layer. 1498 In order to accommodate implementations that are not compliant to RFC 1499 3748, such lower layers SHOULD ensure that both parties support ERP; 1500 this is trivial for an instance when using a lower layer that is 1501 known to always support ERP. For lower layers where ERP support is 1502 not guaranteed, ERP support may be indicated through signaling (e.g., 1503 piggy-backed on a beacon) or through negotiation. Alternatively, 1504 clients may recognize environments where ERP is available based on 1505 pre-configuration. Other similar mechanisms may also be used. When 1506 ERP support cannot be verified, lower layers may mandate falling back 1507 to full EAP authentication to accommodate EAP implementations that 1508 are not compliant to RFC 3748. 1510 7. Transport of ERP Messages 1512 AAA Transport of ERP messages is specified in [RFC5749] and 1513 [I-D.ietf-dime-erp]. 1515 8. Security Considerations 1517 This section provides an analysis of the protocol in accordance with 1518 the AAA key management requirements specified in [RFC4962]. 1520 Cryptographic algorithm independence 1522 The EAP Re-auth Protocol satisfies this requirement. The 1523 algorithm chosen by the peer for the MAC generation is 1524 indicated in the EAP-Initiate/Re-auth message. If the chosen 1525 algorithm is unacceptable, the EAP server returns an EAP- 1526 Finish/Re-auth message with Failure indication. Algorithm 1527 agility for the KDF is specified in [RFC5295]. Only when the 1528 algorithms used are acceptable, the server proceeds with 1529 derivation of keys and verification of the proof of possession 1530 of relevant keying material by the peer. A full-blown 1531 negotiation of algorithms cannot be provided in a single round 1532 trip protocol. Hence, while the protocol provides algorithm 1533 agility, it does not provide true negotiation. 1535 Strong, fresh session keys 1537 ERP results in the derivation of strong, fresh keys that are 1538 unique for the given session. An rMSK is always derived on- 1539 demand when the peer requires a key with a new authenticator. 1540 The derivation ensures that the compromise of one rMSK does not 1541 result in the compromise of a different rMSK at any time. 1543 Limit key scope 1545 The scope of all the keys derived by ERP is well defined. The 1546 rRK and rIK are never shared with any entity and always remain 1547 on the peer and the server. The rMSK is provided only to the 1548 authenticator through which the peer performs the ERP exchange. 1549 No other authenticator is authorized to use that rMSK. 1551 Replay detection mechanism 1553 For replay protection of ERP messages, a sequence number 1554 associated with the rIK is used. The sequence number is 1555 maintained by the peer and the server, and initialized to zero 1556 when the rIK is generated. The peer increments the sequence 1557 number by one after it sends an ERP message. The server sets 1558 the expected sequence number to the received sequence number 1559 plus one after verifying the validity of the received message 1560 and responds to the message. 1562 Authenticate all parties 1564 The EAP Re-auth Protocol provides mutual authentication of the 1565 peer and the server. Both parties need to possess the keying 1566 material that resulted from a previous EAP exchange in order to 1567 successfully derive the required keys. Also, both the EAP re- 1568 authentication Response and the EAP re-authentication 1569 Information messages are integrity protected so that the peer 1570 and the server can verify each other. When the ERP exchange is 1571 executed with a local ER server, the peer and the local server 1572 mutually authenticate each other via that exchange in the same 1573 manner. The peer and the authenticator authenticate each other 1574 in the secure association protocol executed by the lower layer, 1575 just as in the case of a regular EAP exchange. 1577 Peer and authenticator authorization 1579 The peer and authenticator demonstrate possession of the same 1580 key material without disclosing it, as part of the lower-layer 1581 secure association protocol. Channel binding with ERP may be 1582 used to verify consistency of the identities exchanged, when 1583 the identities used in the lower layer differ from that 1584 exchanged within the AAA protocol. 1586 Keying material confidentiality 1588 The peer and the server derive the keys independently using 1589 parameters known to each entity. The AAA server sends the DSRK 1590 of a domain to the corresponding local ER server via the AAA 1591 protocol. Likewise, the ER server sends the rMSK to the 1592 authenticator via the AAA protocol. 1594 Note that compromise of the DSRK results in compromise of all 1595 keys derived from it. Moreover, there is no forward secrecy 1596 within ERP. Thus, compromise of an DSRK retroactively 1597 compromises all ERP keys. 1599 It is RECOMMENDED that the AAA protocol be protected using 1600 IPsec or TLS so that the keys are protected in transit. Note, 1601 however, that keys may be exposed to AAA proxies along the way 1602 and compromise of any of those proxies may result in compromise 1603 of keys being transported through them. 1605 The home ER server MUST NOT hand out a given DSRK to a local 1606 domain server more than once, unless it can verify that the 1607 entity receiving the DSRK after the first time is the same as 1608 that received the DSRK originally. If the home ER server 1609 verifies authorization of a local domain server, it MAY hand 1610 out the DSRK to that domain more than once. In this case, the 1611 home ER server includes the Authorization Indication TLV to 1612 assure the peer that DSRK delivery is secure. 1614 Confirm cryptosuite selection 1616 Crypto algorithms for integrity and key derivation in the 1617 context of ERP MAY be the same as that used by the EAP method. 1618 In that case, the EAP method is responsible for confirming the 1619 cryptosuite selection. Furthermore, the cryptosuite is 1620 included in the ERP exchange by the peer and confirmed by the 1621 server. The protocol allows the server to reject the 1622 cryptosuite selected by the peer and provide alternatives. 1623 When a suitable rIK is not available for the peer, the 1624 alternatives may be sent in an unprotected fashion. The peer 1625 is allowed to retry the exchange using one of the allowed 1626 cryptosuites. However, in this case, any en route 1627 modifications to the list sent by the server will go 1628 undetected. If the server does have an rIK available for the 1629 peer, the list will be provided in a protected manner and this 1630 issue does not apply. 1632 Uniquely named keys 1634 All keys produced within the ERP context can be referred to 1635 uniquely as specified in this document. Also, the key names do 1636 not reveal any part of the keying material. 1638 Prevent the domino effect 1640 The compromise of one peer does not result in the compromise of 1641 keying material held by any other peer in the system. Also, 1642 the rMSK is meant for a single authenticator and is not shared 1643 with any other authenticator. Hence, the compromise of one 1644 authenticator does not lead to the compromise of sessions or 1645 keys held by any other authenticator in the system. Hence, the 1646 EAP Re-auth Protocol allows prevention of the domino effect by 1647 appropriately defining key scope. 1649 However, if keys are transported using hop-by-hop protection, 1650 compromise of a proxy may result in compromise of key material, 1651 i.e., the DSRK being sent to a local ER server. 1653 Bind key to its context 1655 All the keys derived for ERP are bound to the appropriate 1656 context using appropriate key labels. Lifetime of a child key 1657 is less than or equal to that of its parent key as specified in 1658 RFC 4962 [RFC4962]. The key usage, lifetime and the parties 1659 that have access to the keys are specified. 1661 Confidentiality of identity 1663 Deployments where privacy is a concern may find the use of 1664 rIKname-NAI to route ERP messages serves their privacy 1665 requirements. Note that it is plausible to associate multiple 1666 runs of ERP messages since the rIKname is not changed as part 1667 of the ERP protocol. There was no consensus for that 1668 requirement at the time of development of this specification. 1669 If the rIKname is not used and the Peer-ID is used instead, the 1670 ERP exchange will reveal the Peer-ID over the wire. 1672 Authorization restriction 1674 All the keys derived are limited in lifetime by that of the 1675 parent key or by server policy. Any domain-specific keys are 1676 further restricted for use only in the domain for which the 1677 keys are derived. All the keys specified in this document are 1678 meant for use in ERP only. Any other restrictions of session 1679 keys may be imposed by the specific lower layer and are out of 1680 scope for this specification. 1682 A denial-of-service (DoS) attack on the peer may be possible when 1683 using the EAP Initiate/Re-auth message. An attacker may send a bogus 1684 EAP-Initiate/Re-auth message, which may be carried by the 1685 authenticator in a RADIUS-Access-Request to the server; in response, 1686 the server may send an EAP-Finish/Re-auth with Failure indication in 1687 a RADIUS Access-Reject message. Note that such attacks may be 1688 plausible with the EAPoL-Start capability of IEEE 802.11 and other 1689 similar facilities in other link layers and where the peer can 1690 initiate EAP authentication. An attacker may use such messages to 1691 start an EAP method run, which fails and may result in the server 1692 sending a RADIUS Access-Reject message, thus resulting in the link- 1693 layer connections being terminated. 1695 To prevent such DoS attacks, an ERP failure should not result in 1696 deletion of any authorization state established by a full EAP 1697 exchange. Alternatively, the lower layers and AAA protocols may 1698 define mechanisms to allow two link-layer security associations (SAs) 1699 derived from different EAP keying materials for the same peer to 1700 exist so that smooth migration from the current link layer SA to the 1701 new one is possible during rekey. These mechanisms prevent the link 1702 layer connections from being terminated when a re-authentication 1703 procedure fails due to the bogus EAP-Initiate/Re-auth message. 1705 When a DSRK is sent from a home ER server to a local domain server or 1706 when a rMSK is sent from an ER server to an authenticator, in the 1707 absence of end-to-end security between the entity that is sending the 1708 key and the entity receiving the key, it is plausible for other 1709 entities to get access to keys being sent to an ER server in another 1710 domain. This mode of key transport is similar to that of MSK 1711 transport in the context of EAP authentication. We further observe 1712 that ERP is for access authentication and does not support end-to-end 1713 data security. In typical implementations, the traffic is in the 1714 clear beyond the access control enforcement point (the authenticator 1715 or an entity delegated by the authenticator for access control 1716 enforcement). The model works as long as entities in the middle of 1717 the network do not use keys intended for other parties to steal 1718 service from an access network. If that is not achievable, key 1719 delivery must be protected in an end-to-end manner. 1721 9. IANA Considerations 1723 This document has no IANA actions; all values referenced in this 1724 document were previously assigned in RFC 5296 [RFC5296]. 1726 10. References 1728 10.1. Normative References 1730 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1731 Hashing for Message Authentication", RFC 2104, 1732 February 1997. 1734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1735 Requirement Levels", BCP 14, RFC 2119, March 1997. 1737 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1738 Levkowetz, "Extensible Authentication Protocol (EAP)", 1739 RFC 3748, June 2004. 1741 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1742 Network Access Identifier", RFC 4282, December 2005. 1744 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 1745 "Specification for the Derivation of Root Keys from an 1746 Extended Master Session Key (EMSK)", RFC 5295, 1747 August 2008. 1749 10.2. Informative References 1751 [I-D.ietf-dime-erp] 1752 Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter 1753 Support for the EAP Re-authentication Protocol (ERP)", 1754 draft-ietf-dime-erp-04 (work in progress), September 2010. 1756 [IEEE_802.1X] 1757 Institute of Electrical and Electronics Engineers, "IEEE 1758 Standards for Local and Metropolitan Area Networks: Port 1759 based Network Access Control, IEEE Std 802.1X-2004", 1760 December 2004. 1762 [MSKHierarchy] 1763 Lopez, R., Skarmeta, A., Bournelle, J., Laurent- 1764 Maknavicus, M., and J. Combes, "Improved EAP keying 1765 framework for a secure mobility access service", 1766 IWCMC '06, Proceedings of the 2006 International 1767 Conference on Wireless Communications and 1768 Mobile Computing, New York, NY, USA, 2006. 1770 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1771 "Remote Authentication Dial In User Service (RADIUS)", 1772 RFC 2865, June 2000. 1774 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1775 RFC 3162, August 2001. 1777 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1778 Dial In User Service) Support For Extensible 1779 Authentication Protocol (EAP)", RFC 3579, September 2003. 1781 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1782 Protocol Method for 3rd Generation Authentication and Key 1783 Agreement (EAP-AKA)", RFC 4187, January 2006. 1785 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1786 Authorization, and Accounting (AAA) Key Management", 1787 BCP 132, RFC 4962, July 2007. 1789 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 1790 "Handover Key Management and Re-Authentication Problem 1791 Statement", RFC 5169, March 2008. 1793 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1794 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1795 May 2008. 1797 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 1798 authentication Protocol (ERP)", RFC 5296, August 2008. 1800 [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of 1801 EAP-Based Keys for Handover and Re-Authentication", 1802 RFC 5749, March 2010. 1804 Appendix A. Acknowledgments 1806 A.1. RFC 5296 1808 In writing this document, we benefited from discussing the problem 1809 space and the protocol itself with a number of folks including 1810 Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, 1811 Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, 1812 Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi 1813 Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of 1814 the HOKEY working group. The credit for the idea to use EAP- 1815 Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- 1816 layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin 1817 Hoeper suggested the use of the windowing technique to handle 1818 multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for 1819 the suggestion to use hexadecimal encoding for rIKname when sent as 1820 part of keyName-NAI field. Thanks to Bernard Aboba for suggestions 1821 in clarifying the EAP lock-step operation, and Joe Salowey and Glen 1822 Zorn for help in specifying AAA transport of ERP messages. Thanks to 1823 Sam Hartman for the DSRK Authorization Indication mechanism. 1825 A.2. RFC 5296bis 1827 TBC 1829 Appendix B. Example ERP Exchange 1830 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] 1832 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, 1833 cryptosuite,Auth-tag*) 1835 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, 1836 EAP Initiate/Re-auth(SEQ,keyName-NAI, 1837 cryptosuite,Auth-tag*) 1839 2. ER-Server --> Authenticator: AAA-Response{rMSK, 1840 EAP-Finish/Re-auth(SEQ,keyName-NAI, 1841 cryptosuite,[CB-Info],Auth-tag*) 1843 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, 1844 cryptosuite,[CB-Info],Auth-tag*) 1846 * Auth-tag computation is over the entire EAP Initiate/Finish message; 1847 the code values for Initiate and Finish are different and thus 1848 reflection attacks are mitigated. 1850 Authors' Addresses 1852 Glen Zorn (editor) 1853 Network Zen 1854 1463 East Republican Street 1855 #358 1856 Seattle, Washington 98112 1857 US 1859 Email: gwz@net-zen.net 1861 Qin Wu 1862 Huawei Technologies Co., Ltd. 1863 101 Software Avenue, Yuhua District 1864 Nanjing, JiangSu 210012 1865 China 1867 Email: Sunseawq@huawei.com 1868 Zhen Cao 1869 China Mobile 1870 53A Xibianmennei Ave., Xuanwu District 1871 Beijing, Beijing 100053 1872 P.R. China 1874 Email: caozhen@chinamobile.com