idnits 2.17.1 draft-ietf-hokey-rfc5296bis-03.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 (May 31, 2011) is 4714 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 409, 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-06 == 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) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 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: December 2, 2011 Y. Shi 7 H3C 8 B. He 9 CATR 10 May 31, 2011 12 EAP Extensions for EAP Re-authentication Protocol (ERP) 13 draft-ietf-hokey-rfc5296bis-03 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 December 2, 2011. 44 Copyright Notice 46 Copyright (c) 2011 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 . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . 27 95 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 27 96 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 29 97 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 98 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 99 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33 100 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 101 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 35 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 105 10.1. Normative References . . . . . . . . . . . . . . . . . . . 40 106 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 107 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 108 A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 42 109 A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 42 110 A.3. Change Log . . . . . . . . . . . . . . . . . . . . . . . . 42 111 A.3.1. draft-ietf-hokey-rfc5296bis-02 . . . . . . . . . . . . 42 112 A.3.2. draft-ietf-hokey-rfc5296bis-03 . . . . . . . . . . . . 42 113 Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 43 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 116 1. Introduction 118 The Extensible Authentication Protocol (EAP) is a an authentication 119 framework that supports multiple authentication methods. The primary 120 purpose is network access authentication, and a key-generating method 121 is used when the lower layer wants to enforce access control. The 122 EAP keying hierarchy defines two keys to be derived by all key- 123 generating EAP methods: the Master Session Key (MSK) and the Extended 124 MSK (EMSK). In the most common deployment scenario, an EAP peer and 125 an EAP server authenticate each other through a third party known as 126 the EAP authenticator. The EAP authenticator or an entity controlled 127 by the EAP authenticator enforces access control. After successful 128 authentication, the EAP server transports the MSK to the EAP 129 authenticator; the EAP authenticator and the EAP peer establish 130 transient session keys (TSKs) using the MSK as the authentication 131 key, key derivation key, or a key transport key, and use the TSK for 132 per-packet access enforcement. 134 When a peer moves from one authenticator to another, it is desirable 135 to avoid a full EAP authentication to support fast handovers. The 136 full EAP exchange with another run of the EAP method can take several 137 round trips and significant time to complete, causing delays in 138 handover times. Some EAP methods specify the use of state from the 139 initial authentication to optimize re-authentications by reducing the 140 computational overhead, but method-specific re-authentication takes 141 at least 2 round trips with the original EAP server in most cases 142 (e.g., [RFC4187]). It is also important to note that several methods 143 do not offer support for re-authentication. 145 Key sharing across authenticators is sometimes used as a practical 146 solution to lower handover times. In that case, compromise of an 147 authenticator results in compromise of keying material established 148 via other authenticators. Other solutions for fast re-authentication 149 exist in the literature [MSKHierarchy]. 151 In conclusion, to achieve low latency handovers, there is a need for 152 a method-independent re-authentication protocol that completes in 153 less than 2 round trips, preferably with a local server. The EAP re- 154 authentication problem statement is described in detail in [RFC5169]. 156 This document specifies EAP Re-authentication Extensions (ERXs) for 157 efficient re-authentication using EAP. The protocol that uses these 158 extensions is itself referred to as the EAP Re-authentication 159 Protocol (ERP). It supports EAP method-independent re-authentication 160 for a peer that has valid, unexpired key material from a previously 161 performed EAP authentication. The protocol and the key hierarchy 162 required for EAP re-authentication are described in this document. 164 Note that to support ERP, lower-layer specifications may need to be 165 revised to allow carrying EAP messages that have a code value higher 166 than 4 and to accommodate the peer-initiated nature of ERP. 167 Specifically, the IEEE802.1x specification [IEEE_802.1X] must be 168 revised and RFC 5996 [RFC5996] must be updated to carry ERP messages. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 This document uses the basic EAP terminology [RFC3748] and EMSK 177 keying hierarchy terminology [RFC5295]. In addition, this document 178 uses the following terms: 180 ER Peer - An EAP peer that supports the EAP Re-authentication 181 Protocol. All references to "peer" in this document imply an ER 182 peer, unless specifically noted otherwise. 184 ER Authenticator - An entity that supports the authenticator 185 functionality for EAP re-authentication described in this 186 document. All references to "authenticator" in this document 187 imply an ER authenticator, unless specifically noted otherwise. 189 ER Server - An entity that performs the server portion of ERP 190 described here. This entity may or may not be an EAP server. All 191 references to "server" in this document imply an ER server, unless 192 specifically noted otherwise. An ER server is a logical entity; 193 it may not necessarily be co-located with, or physically part of, 194 a full EAP server. 196 ERX - EAP re-authentication extensions. 198 ERP - EAP Re-authentication Protocol that uses the re- 199 authentication extensions. 201 rRK - re-authentication Root Key, derived from the EMSK or DSRK. 203 rIK - re-authentication Integrity Key, derived from the rRK. 205 rMSK - re-authentication MSK. This is a per-authenticator key, 206 derived from the rRK. 208 keyName-NAI - ERP messages are integrity protected with the rIK or 209 the DS-rIK. The use of rIK or DS-rIK for integrity protection of 210 ERP messages is indicated by the EMSKname [RFC5295]; the protocol, 211 which is ERP; and the realm, which indicates the domain name of 212 the ER server. The EMSKname is copied into the username part of 213 the NAI. 215 Domain - Refers to a "key management domain" as defined in 216 [RFC5295]. For simplicity, it is referred to as "domain" in this 217 document. The terms "home domain" and "local domain" are used to 218 differentiate between the originating key management domain that 219 performs the full EAP exchange with the peer and the local domain 220 to which a peer may be attached at a given time. 222 3. ERP Description 224 ERP allows a peer and server to mutually verify proof of possession 225 of keying material from an earlier EAP method run and to establish a 226 security association between the peer and the authenticator. The 227 authenticator acts as a pass-through entity for the Re-authentication 228 Protocol in a manner similar to that of an EAP authenticator 229 described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange 230 between the peer and the server; it is independent of the lower layer 231 and the EAP method used during the full EAP exchange. The ER server 232 may be in the home domain or in the same (visited) domain as the peer 233 and the authenticator (i.e.,local domain). 235 Figure 2 shows the protocol exchange. The first time the peer 236 attaches to any network, it performs a full EAP exchange (shown in 237 Figure 1) with the EAP server; as a result, an MSK is distributed to 238 the EAP authenticator. The MSK is then used by the authenticator and 239 the peer to establish TSKs as needed. At the time of the initial EAP 240 exchange, the peer and the server also derive an EMSK, which is used 241 to derive a re-authentication Root Key (rRK). More precisely, a re- 242 authentication Root Key is derived from the EMSK or from a Domain- 243 Specific Root Key (DSRK), which is itself derived from the EMSK. The 244 rRK is only available to the peer and the ER server and is never 245 handed out to any other entity. Further, a re-authentication 246 Integrity Key (rIK) is derived from the rRK; the peer and the ER 247 server use the rIK to provide proof of possession while performing an 248 ERP exchange. The rIK is also never handed out to any entity and is 249 only available to the peer and server. 251 EAP Peer EAP Authenticator EAP Server 252 ======== ================= ========== 254 <--- EAP-Request/ ------ 255 Identity 257 ----- EAP Response/ ---> 258 Identity ---AAA(EAP Response/Identity)--> 260 <--- EAP Method -------> <------ AAA(EAP Method --------> 261 exchange exchange) 263 <----AAA(MSK, EAP-Success)------ 265 <---EAP-Success--------- 267 Figure 1: EAP Authentication 269 Peer ER Authenticator ER Server 270 ==== ============= ====== 272 <-- EAP-Initiate/ ----- 273 Re-auth-Start 274 [<-- EAP-Request/ ------ 275 Identity] 277 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 278 Re-auth/ Re-auth/ 279 [Bootstrap] [Bootstrap]) 281 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 282 Re-auth/ Re-auth/ 283 [Bootstrap] [Bootstrap]) 285 Note: [] brackets indicate optionality. 287 Figure 2: ERP Exchange 289 Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this 290 document for the purpose of EAP re-authentication. When the peer 291 identifies a target authenticator that supports EAP re- 292 authentication, it performs an ERP exchange, as shown in Figure 2; 293 the exchange itself may happen when the peer attaches to a new 294 authenticator supporting EAP re-authentication, or prior to 295 attachment. The peer initiates ERP by itself; it may also do so in 296 response to an EAP-Initiate/Re-auth-Start message from the new 297 authenticator. The EAP-Initiate/Re-auth-Start message allows the 298 authenticator to trigger the ERP exchange. The EAP-Finish message 299 also can be used by the authenticator to announce local domain name. 301 It is plausible that the authenticator does not know whether the peer 302 supports ERP and whether the peer has performed a full EAP 303 authentication through another authenticator. The authenticator MAY 304 initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start 305 message, and if there is no response, it will send the EAP-Request/ 306 Identity message. Note that this avoids having two EAP messages in 307 flight at the same time [RFC3748]. The authenticator may send the 308 EAP-Initiate/Re-auth-Start message and wait for a short, locally 309 configured amount of time. If the peer does not already know, this 310 message indicates to the peer that the authenticator supports ERP. 311 In response to this trigger from the authenticator, the peer can 312 initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. 313 If there is no response from the peer after the necessary 314 retransmissions (see Section 6), the authenticator MUST initiate EAP 315 by sending an EAP-Request message, typically the EAP-Request/Identity 316 message. Note that the authenticator may receive an EAP-Initiate/ 317 Re-auth message after it has sent an EAP-Request/Identity message. 318 If the authenticator supports ERP, it MUST proceed with the ERP 319 exchange. When the EAP-Request/Identity times out, the authenticator 320 MUST NOT close the connection if an ERP exchange is in progress or 321 has already succeeded in establishing a re-authentication MSK. 323 If the authenticator does not support ERP, it drops EAP-Initiate/ 324 Re-auth messages [RFC3748] as the EAP code of those packets is 325 greater than 4. An ERP-capable peer will exhaust the EAP-Initiate/ 326 Re-auth message retransmissions and fall back to EAP authentication 327 by responding to EAP Request/Identity messages from the 328 authenticator. If the peer does not support ERP or if it does not 329 have unexpired key material from a previous EAP authentication, it 330 drops EAP-Initiate/Re-auth-Start messages. If there is no response 331 to the EAP-Initiate/Re-auth-Start message, the authenticator SHALL 332 send an EAP Request message (typically EAP Request/Identity) to start 333 EAP authentication. From this stage onwards, RFC 3748 rules apply. 334 Note that this may introduce some delay in starting EAP. In some 335 lower layers, the delay can be minimized or even avoided by the peer 336 initiating EAP by sending messages such as EAPoL-Start in the IEEE 337 802.1X specification [IEEE_802.1X]. 339 The peer sends an EAP-Initiate/Re-auth message that contains the 340 keyName-NAI to identify the ER server's domain and the rIK used to 341 protect the message, and a sequence number for replay protection. 343 The EAP-Initiate/Re-auth message is integrity protected with the rIK. 344 The authenticator uses the realm in the keyName-NAI [RFC4282] field 345 to send the message to the appropriate ER server. The server uses 346 the keyName to look up the rIK. The server, after verifying proof of 347 possession of the rIK, and freshness of the message, derives a re- 348 authentication MSK (rMSK) from the rRK using the sequence number as 349 an input to the key derivation. The server updates the expected 350 sequence number to the received sequence number plus one. 352 In response to the EAP-Initiate/Re-auth message, the server sends an 353 EAP-Finish/Re-auth message; this message is integrity protected with 354 the rIK. The server transports the rMSK along with this message to 355 the authenticator. The rMSK is transported in a manner similar to 356 that of the MSK along with the EAP-Success message in a full EAP 357 exchange. Ongoing work in [RFC5749] describes an additional key 358 distribution protocol that can be used to transport the rRK from an 359 EAP server to one of many different ER servers that share a trust 360 relationship with the EAP server. 362 The peer MAY request the server for the rMSK lifetime. If so, the ER 363 server sends the rMSK lifetime in the EAP-Finish/Re-auth message. 365 In an ERP bootstrap exchange, the peer MAY request the server for the 366 rRK lifetime. If so, the ER server sends the rRK lifetime in the 367 EAP-Finish/Re-auth message. 369 The peer verifies the replay protection and the integrity of the 370 message. It then uses the sequence number in the EAP-Finish/Re-auth 371 message to compute the rMSK. The lower-layer security association 372 protocol is ready to be triggered after this point. 374 When the ER server is in the home domain, the peer and the server use 375 the rIK and rRK derived from the EMSK; and when the ER server is in 376 the local domain, they use the DS-rIK and DS-rRK corresponding to the 377 local domain. The domain of the ER server is identified by the realm 378 portion of the keyname-NAI in ERP messages. 380 3.1. ERP With the Home ER Server 382 If the peer is in the home domain and does not know the domain name ( 383 did not receive the domain name through the EAP-Initiate/ 384 Re-auth-Start message or via the lower-layer announcement, due to a 385 missed announcement or lack of support for domain name announcements 386 in a specific lower layer) or there is no the local server in the 387 same domain as the peer, it SHOULD initiate ERP bootstrap exchange 388 with the home ER server to obtain the domain name. 390 The defined ER extensions allow executing the ERP with an ER server 391 in the home domain. The home ER server may be co- located with a 392 home AAA server. The ERP with the Home ER Server is the similar as 393 ERP exchange described in Figure 2. 395 Peer ER Authenticator Home ER Server 396 ==== ============= ====== 398 <-- EAP-Initiate/ ----- 399 Re-auth-Start 400 [<-- EAP-Request/ ------ 401 Identity] 403 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 404 Re-auth/ Re-auth/ 405 [Bootstrap] [Bootstrap]) 407 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 408 Re-auth/ Re-auth/ 409 [Bootstrap] [Bootstrap]) 411 Note: [] brackets indicate optionality. 413 Figure 3: ER ExplicitBootstrapping Exchange/ERP with the Home ER 414 Sever 416 3.2. ERP with a Local ER Server 418 The defined ER extensions allow executing the ERP with an ER server 419 in the local domain (access network) if the peer moves out of home 420 domain. The local ER server may be co-located with a local AAA 421 server. The peer may learn about the presence of a local ER server 422 in the network and the local domain name (or ER server name) either 423 via the lower layer or by means of ERP exchange. The peer uses the 424 domain name and the EMSK to compute the DSRK and from that key, the 425 DS-rRK; the peer also uses the domain name in the realm portion of 426 the keyName-NAI for using ERP in the local domain. Figure 4 shows 427 the ER Implicit bootstrapping exchange through local ER 428 Server;Figure 5shows ERP with a local ER server. 430 Peer EAP Authenticator Local AAA Agent Home EAP Server 431 /ER Authenticator /Local ER Server 432 ==== ================= =============== =============== 434 <-- EAP-Request/ -- 435 Identity 437 -- EAP Response/--> 438 Identity --AAA(EAP Response/--> 439 Identity, --AAA(EAP Response/ --> 440 [domain name]) Identity, 441 [DSRK Request, 442 domain name]) 444 <------------------------ EAP Method exchange------------------> 446 <---AAA(MSK, DSRK, ---- 447 EMSKname, 448 EAP-Success) 450 <--- AAA(MSK, ----- 451 EAP-Success) 453 <---EAP-Success----- 455 Figure 4: Local ERP Exchange, Initial EAP Exchange 457 Peer ER Authenticator Local ER Server 458 ==== ================ =============== 460 <-- EAP-Initiate/ -------- 461 Re-auth-Start 462 [<-- EAP-Request/ --------- 463 Identity] 465 ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> 466 Re-auth Re-auth) 468 <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- 469 Re-auth Re-auth) 470 Figure 5: Local ERP Exchange 472 As shown in Figure 4, the local ER server may be present in the path 473 of the full EAP exchange (e.g., this may be one of the AAA entities, 474 such as AAA proxies, in the path between the EAP authenticator and 475 the home EAP server of the peer). In that case, the local ER server 476 requests the DSRK by sending the domain name to the home EAP server 477 through AAA message. In response, the home EAP server computes the 478 DSRK by following the procedure specified in [RFC5295] and sends the 479 DSRK and the key name, EMSKname, to the ER server in the claimed 480 domain (i.e., local ER Server). The local domain is responsible for 481 announcing that same domain name via the lower layer to the peer, 482 e.g., DHCP based local domain name discovery specified in 483 [I-D.ietf-hokey-ldn-discovery], or through the EAP-Initiate/ 484 Re-auth-Start message during subsequent ERP with local ER server. 486 After receiving the DSRK and the EMSKname, the local ER server 487 computes the DS-rRK and the DS-rIK from the DSRK as defined in 488 Sections 4.1 and 4.3 below. After receiving the domain name, the 489 peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys 490 are referred to by a keyName-NAI formed as follows: the username part 491 of the NAI is the EMSKname, the realm portion of the NAI is the 492 domain name. Both parties also maintain a sequence number 493 (initialized to zero) corresponding to the specific keyName-NAI. 495 Subsequently, when the peer attaches to an authenticator within the 496 local domain, it may perform an ERP exchange with the local ER server 497 to obtain an rMSK for the new authenticator. The ERP with the local 498 ER Server is the similar as ERP exchange described in Figure 2. 500 4. ER Key Hierarchy 502 Each time the peer re-authenticates to the network, the peer and the 503 authenticator establish an rMSK. The rMSK serves the same purposes 504 that an MSK, which is the result of full EAP authentication, serves. 505 To prove possession of the rRK, we specify the derivation of another 506 key, the rIK. These keys are derived from the rRK. Together they 507 constitute the ER key hierarchy. 509 The rRK is derived from either the EMSK or a DSRK as specified in 510 Section 4.1. For the purpose of rRK derivation, this document 511 specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- 512 Specific USRK (DSUSRK) in accordance with [RFC5295] for re- 513 authentication. The USRK designated for re-authentication is the re- 514 authentication root key (rRK). A DSUSRK designated for re- 515 authentication is the DS-rRK available to a local ER server in a 516 particular domain. For simplicity, the keys are referred to without 517 the DS label in the rest of the document. However, the scope of the 518 various keys is limited to just the respective domains they are 519 derived for, in the case of the domain specific keys. Based on the 520 ER server with which the peer performs the ERP exchange, it knows the 521 corresponding keys that must be used. 523 The rRK is used to derive an rIK, and rMSKs for one or more 524 authenticators. The figure below shows the key hierarchy with the 525 rRK, rIK, and rMSKs. 527 rRK 528 | 529 +--------+--------+ 530 | | | 531 rIK rMSK1 ...rMSKn 533 Figure 6: Re-authentication Key Hierarchy 535 The derivations in this document are according to [RFC5295]. Key 536 derivations and field encodings, where unspecified, default to that 537 document. 539 4.1. rRK Derivation 541 The rRK may be derived from the EMSK or DSRK. This section provides 542 the relevant key derivations for that purpose. 544 The rRK is derived as specified in [RFC5295]. 546 rRK = KDF (K, S), where 548 K = EMSK or K = DSRK and 550 S = rRK Label | "\0" | length 552 The rRK Label is an IANA-assigned 8-bit ASCII string: 554 EAP Re-authentication Root Key@ietf.org 556 assigned from the "USRK key labels" name space in accordance with 557 [RFC5295]. 559 The KDF and algorithm agility for the KDF are as defined in 560 [RFC5295]. 562 An rRK derived from the DSRK is referred to as a DS-rRK in the rest 563 of the document. All the key derivation and properties specified in 564 this section remain the same. 566 4.2. rRK Properties 568 The rRK has the following properties. These properties apply to the 569 rRK regardless of the parent key used to derive it. 571 o The length of the rRK MUST be equal to the length of the parent 572 key used to derive it. 574 o The rRK is to be used only as a root key for re-authentication and 575 never used to directly protect any data. 577 o The rRK is only used for derivation of rIK and rMSK as specified 578 in this document. 580 o The rRK MUST remain on the peer and the server that derived it and 581 MUST NOT be transported to any other entity. 583 o The lifetime of the rRK is never greater than that of its parent 584 key. The rRK is expired when the parent key expires and MUST be 585 removed from use at that time. 587 4.3. rIK Derivation 589 The re-authentication Integrity Key (rIK) is used for integrity 590 protecting the ERP exchange. This serves as the proof of possession 591 of valid keying material from a previous full EAP exchange by the 592 peer to the server. 594 The rIK is derived as follows. 596 rIK = KDF (K, S), where 598 K = rRK and 600 S = rIK Label | "\0" | cryptosuite | length 602 The rIK Label is the 8-bit ASCII string: 604 Re-authentication Integrity Key@ietf.org 606 The length field refers to the length of the rIK in octets encoded as 607 specified in [RFC5295]. 609 The cryptosuite and length of the rIK are part of the input to the 610 key derivation function to ensure cryptographic separation of keys if 611 different rIKs of different lengths for use with different Message 612 Authentication Code (MAC) algorithms are derived from the same rRK. 613 The cryptosuite is encoded as an 8-bit number; see Section 5.3.2 for 614 the cryptosuite specification. 616 The rIK is referred to by EMSKname-NAI within the context of ERP 617 messages. The username part of EMSKname-NAI is the EMSKname; the 618 realm is the domain name of the ER server. In case of ERP with the 619 home ER server, the peer uses the realm from its original NAI; in 620 case of a local ER server, the peer uses the domain name received at 621 the lower layer or through an ERP bootstrapping exchange. 623 An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest 624 of the document. All the key derivation and properties specified in 625 this section remain the same. 627 4.4. rIK Properties 629 The rIK has the following properties. 631 o The length of the rIK MUST be equal to the length of the rRK. 633 o The rIK is only used for authentication of the ERP exchange as 634 specified in this document. 636 o The rIK MUST NOT be used to derive any other keys. 638 o The rIK must remain on the peer and the server and MUST NOT be 639 transported to any other entity. 641 o The rIK is cryptographically separate from any other keys derived 642 from the rRK. 644 o The lifetime of the rIK is never greater than that of its parent 645 key. The rIK MUST be expired when the EMSK expires and MUST be 646 removed from use at that time. 648 4.5. rIK Usage 650 The rIK is the key whose possession is demonstrated by the peer and 651 the ERP server to the other party. The peer demonstrates possession 652 of the rIK by computing the integrity checksum over the EAP-Initiate/ 653 Re-auth message. When the peer uses the rIK for the first time, it 654 can choose the integrity algorithm to use with the rIK. The peer and 655 the server MUST use the same integrity algorithm with a given rIK for 656 all ERP messages protected with that key. The peer and the server 657 store the algorithm information after the first use, and they employ 658 the same algorithm for all subsequent uses of that rIK. 660 If the server's policy does not allow the use of the cryptosuite 661 selected by the peer, the server SHALL reject the EAP-Initiate/ 662 Re-auth message and SHOULD send a list of acceptable cryptosuites in 663 the EAP-Finish/Re-auth message. 665 The rIK length may be different from the key length required by an 666 integrity algorithm. In case of hash-based MAC algorithms, the key 667 is first hashed to the required key length as specified in [RFC2104]. 668 In case of cipher-based MAC algorithms, if the required key length is 669 less than 32 octets, the rIK is hashed using HMAC-SHA256 and the 670 first k octets of the output are used, where k is the key length 671 required by the algorithm. If the required key length is more than 672 32 octets, the first k octets of the rIK are used by the cipher-based 673 MAC algorithm. 675 4.6. rMSK Derivation 677 The rMSK is derived at the peer and server and delivered to the 678 authenticator. The rMSK is derived following an EAP Re-auth Protocol 679 exchange. 681 The rMSK is derived as follows. 683 rMSK = KDF (K, S), where 685 K = rRK and 687 S = rMSK label | "\0" | SEQ | length 689 The rMSK label is the 8-bit ASCII string: 691 Re-authentication Master Session Key@ietf.org 693 The length field refers to the length of the rMSK in octets. The 694 length field is encoded as specified in [RFC5295]. 696 SEQ is the sequence number sent by the peer in the EAP-Initiate/ 697 Re-auth message. This field is encoded as a 16-bit number in network 698 byte order (see Section 5.3.2). 700 An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest 701 of the document. All the key derivation and properties specified in 702 this section remain the same. 704 4.7. rMSK Properties 706 The rMSK has the following properties: 708 o The length of the rMSK MUST be equal to the length of the rRK. 710 o The rMSK is delivered to the authenticator and is used for the 711 same purposes that an MSK is used at an authenticator. 713 o The rMSK is cryptographically separate from any other keys derived 714 from the rRK. 716 o The lifetime of the rMSK is less than or equal to that of the rRK. 717 It MUST NOT be greater than the lifetime of the rRK. 719 o If a new rRK is derived, subsequent rMSKs MUST be derived from the 720 new rRK. Previously delivered rMSKs MAY still be used until the 721 expiry of the lifetime. 723 o A given rMSK MUST NOT be shared by multiple authenticators. 725 5. Protocol Details 727 5.1. ERP Bootstrapping 729 We identify two types of bootstrapping for ERP: explicit and implicit 730 bootstrapping. In implicit bootstrapping, the local AAA client or 731 Agent MUST verify whether it has valid rMSK or rRK corresponding to 732 the peer. If the local AAA client or Agent has the key materials 733 corresponding to the peer, it MUST be able to respond directly in the 734 same way as the home AAA server does without forwarding the ERP 735 message to the home domain, if the local AAA client or Agent does not 736 have the keying material(e.g., rMSK or rRK) corresponding to the 737 peer, the local AAA client or agent supporting EAP re-authentication 738 SHOULD include its domain name and SHOULD request the DSRK from the 739 home AAA server during the initial EAP exchange, in the AAA message 740 encapsulating the first EAP Response message sent by the peer. If 741 such EAP exchange is successful, the home EAP server sends the DSRK 742 for the specified local AAA client or agent (derived using the EMSK 743 and the domain name as specified in [RFC5295]), EMSKname, and DSRK 744 lifetime along with the EAP-Success message. The local AAA client or 745 agent MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) 746 before forwarding the EAP-Success message to the peer, as specified 747 in [I-D.ietf-dime-erp]. Note that the MSK (also present along with 748 the EAP Success message) is extracted by the EAP authenticator as 749 usual. The peer learns the domain name through the EAP-Initiate/ 750 Re-auth-Start message, lower-layer announcements 751 [I-D.ietf-hokey-ldn-discovery] . When the domain name is available 752 to the peer during or after the full EAP authentication, it attempts 753 to use ERP when it associates with a new authenticator. 755 If the peer does not know the domain name (did not receive the domain 756 name through the EAP-Initiate/Re-auth-Start message or via the lower- 757 layer announcement, due to a missed announcement or lack of support 758 for domain name announcements in a specific lower layer), it SHOULD 759 initiate Explicit ERP bootstrapping (ERP exchange with the bootstrap 760 flag turned on) with the ER server to obtain the local domain name. 761 The peer MAY also initiate bootstrapping to fetch information such as 762 the rRK lifetime from the AAA server. 764 The following steps describe the ERP Explicit Bootstrapping process: 766 o The peer sends the EAP-Initiate/Re-auth message with the 767 bootstrapping flag turned on. The bootstrap message is always 768 sent to the ER server, and the keyname-NAI attribute in the 769 bootstrap message is constructed as follows: the username portion 770 of the NAI contains the EMSKname, and the realm portion contains 771 the home domain name. 773 o In addition, the message MUST contain a sequence number for replay 774 protection, a cryptosuite, and an integrity checksum. The 775 cryptosuite indicates the authentication algorithm. The integrity 776 checksum indicates that the message originated at the claimed 777 entity, the peer indicated by the Peer-ID, or the rIKname. 779 o The peer MAY additionally set the lifetime flag to request the key 780 lifetimes. 782 o Upon receipt of the EAP-Initiate/ Re-auth message from a peer, the 783 ERP-capable authenticator verifies whether it has local domain 784 name and valid key materials corresponding to the peer. If it 785 knows local domain name and valid key material corresponding to 786 the peer, it MUST be able to respond directly in the same way as 787 the home ER does with local domain name included. If not, it 788 copies the contents of the keyName-NAI into the User-Name 789 attribute of RADIUS [RFC2865] and may include its domain name in 790 the AAA message encapsulating the EAP-Initiate/Re-auth message 791 sent by the peer. The rest of the process is similar to that 792 described in [RFC3579]. 794 o If a local ER server is present, the local ER server MUST verify 795 whether it has DSRK corresponding to the peer. If the local ER 796 server has the valid key materials corresponding to the peer, it 797 MUST be able to respond directly in the same way as the home ER 798 server does described in the following step without forwarding the 799 ERP message to the home domain, even if this message contains the 800 'B' (bootstrapping) flag. Otherwise, the local ER server MUST 801 include the DSRK request and its domain name in the AAA message 802 encapsulating the EAP-Initiate/Re-auth message sent by the peer. 804 o Upon receipt of an EAP-Initiate/Re-auth message, the home ER 805 server verifies whether the message is fresh or is a replay by 806 evaluating whether the received sequence number is equal to or 807 greater than the expected sequence number for that rIK. The home 808 ER server then verifies to ensure that the cryptosuite used by the 809 peer is acceptable. Next, it verifies the origin authentication 810 of the message by looking up the rIK. If any of the checks fail, 811 the home ER server sends an EAP-Finish/Re-auth message with the 812 Result flag set to '1'. Please refer to Section 5.2.2 for details 813 on failure handling. This error MUST NOT have any correlation to 814 any EAP-Success message that may have been received by the EAP 815 authenticator and the peer earlier. If the EAP-Initiate/Re-auth 816 message is well-formed and valid, the server prepares the EAP- 817 Finish/Re-auth message. The bootstrap flag MUST be set to 818 indicate that this is a bootstrapping exchange. The message 819 contains the following fields: 821 * A sequence number for replay protection. 823 * The same keyName-NAI as in the EAP-Initiate/Re-auth message. 825 * If the lifetime flag was set in the EAP-Initiate/Re-auth 826 message, the ER server SHOULD include the rRK lifetime and the 827 rMSK lifetime in the EAP-Finish/Re-auth message. The server 828 may have a local policy for the network to maintain and enforce 829 lifetime unilaterally. In such cases, the server need not 830 respond to the peer's request for the lifetime. 832 * If the bootstrap flag is set, the ER server MUST include the 833 domain name to which the DSRK is being sent along with the EAP- 834 Finish/Re-auth message. 836 * If the ER server verifies the authorization of a local ER 837 server, it MAY include the Authorization Indication TLV to 838 indicate to the peer that the server (that received the DSRK 839 and that is advertising the domain included in the domain name 840 TLV) is authorized. 842 * An authentication tag MUST be included to prove that the EAP- 843 Finish/Re-auth message originates at a server that possesses 844 the rIK corresponding to the EMSKname-NAI. 846 o If the home ER server gets involved in ERP exchange and the ERP 847 exchange is successful, the home ER server SHOULD request the DSRK 848 from the home EAP server during this ERP Explicit Bootstrapping as 849 specified in [I-D.ietf-dime-local-keytran], the home EAP server 850 MUST include the DSRK for the local ER server (derived using the 851 EMSK and the domain name as specified in [RFC5295]), EMSKname, and 852 DSRK lifetime along with the EAP-Finish/Re-auth message. 854 o In addition, the rMSK is sent along with the EAP-Finish/Re-auth 855 message, in a AAA attribute [I-D.ietf-dime-erp]. 857 o The local ER server MUST extract the DSRK, EMSKname, and DSRK 858 lifetime (if present) before forwarding the EAP-Success message to 859 the peer, as specified in [I-D.ietf-dime-erp]. 861 o The authenticator receives the rMSK. 863 o When the peer receives an EAP-Finish/Re-auth message with the 864 bootstrap flag set, if a local domain name is present, it MUST use 865 that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- 866 NAI, and initialize the replay counter for the DS-rIK. If not, 867 the peer SHOULD derive the domain-specific keys using the domain 868 name it learned via the lower layer or from the EAP-Initiate/ 869 Re-auth-Start message. If the peer does not know the domain name, 870 it must assume that there is no local ER server available. 872 o The peer MAY also verify the Authorization Indication TLV. 874 o The procedures for encapsulating the ERP and obtaining relevant 875 keys using Diameter are specified in [I-D.ietf-dime-erp]. 877 Since the ER bootstrapping exchange is typically done immediately 878 following the full EAP exchange, it is feasible that the process is 879 completed through the same entity that served as the EAP 880 authenticator for the full EAP exchange. In this case, the lower 881 layer may already have established TSKs based on the MSK received 882 earlier. The lower layer may then choose to ignore the rMSK that was 883 received with the ER bootstrapping exchange. Alternatively, the 884 lower layer may choose to establish a new TSK using the rMSK. In 885 either case, the authenticator and the peer know which key is used 886 based on whether or not a TSK establishment exchange is initiated. 887 The bootstrapping exchange may also be carried out via a new 888 authenticator, in which case, the rMSK received SHOULD trigger a 889 lower layer TSK establishment exchange. 891 5.2. Steps in ERP 893 When a peer that has an active rRK and rIK associates with a new 894 authenticator that supports ERP, it may perform an ERP exchange with 895 that authenticator. ERP is typically a peer-initiated exchange, 896 consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth 897 message. The ERP exchange may be performed with a local ER server 898 (when one is present) or with the original EAP server. 900 It is plausible for the network to trigger the EAP re-authentication 901 process, however. An ERP-capable authenticator SHOULD send an EAP- 902 Initiate/Re-auth-Start message to indicate support for ERP. The peer 903 may or may not wait for these messages to arrive to initiate the EAP- 904 Initiate/Re-auth message. 906 The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- 907 capable authenticator. The authenticator may retransmit it a few 908 times until it receives an EAP-Initiate/Re-auth message in response 909 from the peer. The EAP-Initiate/Re-auth message from the peer may 910 have originated before the peer receives either an EAP-Request/ 911 Identity or an EAP-Initiate/Re-auth-Start message from the 912 authenticator. Hence, the Identifier value in the EAP-Initiate/ 913 Re-auth message is independent of the Identifier value in the EAP- 914 Initiate/Re-auth-Start or the EAP-Request/Identity messages. 916 Operational Considerations at the Peer: 918 ERP requires that the peer maintain retransmission timers for 919 reliable transport of EAP re-authentication messages. The 920 reliability considerations of Section 4.3 of RFC 3748 apply with the 921 peer as the retransmitting entity. 923 The EAP Re-auth Protocol has the following steps: 925 The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start 926 message to trigger the ERP exchange. 928 The peer sends an EAP-Initiate/Re-auth message. At a minimum, the 929 message SHALL include the following fields: 931 a 16-bit sequence number for replay protection 933 keyName-NAI as a TLV attribute to identify the rIK used to 934 integrity protect the message. 936 cryptosuite to indicate the authentication algorithm used to 937 compute the integrity checksum. 939 authentication tag over the message. 941 When the peer is performing ERP with a local ER server, it MUST 942 use the corresponding DS-rIK it shares with the local ER server. 943 The peer SHOULD set the lifetime flag to request the key lifetimes 944 from the server. The peer can use the rRK lifetime to know when 945 to trigger an EAP method exchange and the rMSK lifetime to know 946 when to trigger another ERP exchange. 948 The authenticator copies the contents of the value field of the 949 keyName-NAI TLV into the User-Name RADIUS attribute in the AAA 950 message to the ER server. 952 The ER server uses the keyName-NAI to look up the rIK. It MUST 953 first verify whether the sequence number is equal to or greater 954 than the expected sequence number. If the ER server supports a 955 sequence number window size greater than 1, it MUST verify whether 956 the sequence number falls within the window and has not been 957 received before. The ER server MUST then verify to ensure that 958 the cryptosuite used by the peer is acceptable. The ER server 959 then proceeds to verify the integrity of the message using the 960 rIK, thereby verifying proof of possession of that key by the 961 peer. If any of these verifications fail, the ER server MUST send 962 an EAP-Finish/Re-auth message with the Result flag set to '1' 963 (Failure). Please refer to Section 5.2.2 for details on failure 964 handling. Otherwise, it MUST compute an rMSK from the rRK using 965 the sequence number as the additional input to the key derivation. 967 In response to a well-formed EAP Re-auth/Initiate message, the ER 968 server MUST send an EAP-Finish/Re-auth message with the following 969 considerations: 971 a 16-bit sequence number for replay protection, which MUST be 972 the same as the received sequence number. The local copy of 973 the sequence number MUST be incremented by 1. If the ER server 974 supports multiple simultaneous ERP exchanges, it MUST instead 975 update the sequence number window. 977 keyName-NAI as a TLV attribute to identify the rIK used to 978 integrity protect the message. 980 cryptosuite to indicate the authentication algorithm used to 981 compute the integrity checksum. 983 authentication tag over the message. 985 If the lifetime flag was set in the EAP-Initiate/Re-auth 986 message, the ER server SHOULD include the rRK lifetime and the 987 rMSK lifetime. 989 The ER server transports the rMSK along with this message to the 990 authenticator. The rMSK is transported in a manner similar to the 991 MSK transport along with the EAP-Success message in a regular EAP 992 exchange. 994 The peer looks up the sequence number to verify whether it is 995 expecting an EAP-Finish/Re-auth message with that sequence number 996 protected by the keyName-NAI. It then verifies the integrity of 997 the message. If the verifications fail, the peer logs an error 998 and stops the process; otherwise, it proceeds to the next step. 1000 The peer uses the sequence number to compute the rMSK. 1002 The lower-layer security association protocol can be triggered at 1003 this point. 1005 5.2.1. Multiple Simultaneous Runs of ERP 1007 When a peer is within the range of multiple authenticators, it may 1008 choose to run ERP via all of them simultaneously to the same ER 1009 server. In that case, it is plausible that the ERP messages may 1010 arrive out of order, resulting in the ER server rejecting legitimate 1011 EAP-Initiate/Re-auth messages. 1013 To facilitate such operation, an ER server MAY allow multiple 1014 simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth 1015 messages with SEQ number values within a window of allowed values. 1016 Recall that the SEQ number allows replay protection. Replay window 1017 maintenance mechanisms are a local matter. 1019 5.2.2. ERP Failure Handling 1021 If the processing of the EAP-Initiate/Re-auth message results in a 1022 failure, the ER server MUST send an EAP-Finish Re-auth message with 1023 the Result flag set to '1'. If the server has a valid rIK for the 1024 peer, it MUST integrity protect the EAP-Finish/Re-auth failure 1025 message. If the failure is due to an unacceptable cryptosuite, the 1026 server SHOULD send a list of acceptable cryptosuites (in a TLV of 1027 Type 5) along with the EAP-Finish/Re-auth message. In this case, the 1028 server MUST indicate the cryptosuite used to protect the EAP-Finish/ 1029 Re-auth message in the cryptosuite. The rIK used with the EAP- 1030 Finish/Re-auth message in this case MUST be computed as specified in 1031 Section 4.3 using the new cryptosuite. If the server does not have a 1032 valid rIK for the peer, the EAP-Finish/Re-auth message indicating a 1033 failure will be unauthenticated; the server MAY include a list of 1034 acceptable cryptosuites in the message. 1036 The peer, upon receiving an EAP-Finish/Re-auth message with the 1037 Result flag set to '1', MUST verify the sequence number and the 1038 Authentication Tag to determine the validity of the message. If the 1039 peer supports the cryptosuite, it MUST verify the integrity of the 1040 received EAP-Finish/Re-auth message. If the EAP-Finish message 1041 contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with 1042 a cryptosuite picked from the list included by the server. The peer 1043 MUST use the appropriate rIK for the subsequent ERP exchange, by 1044 computing it with the corresponding cryptosuite, as specified in 1045 Section 4.3. If the PRF in the chosen cryptosuite is different from 1046 the PRF originally used by the peer, it MUST derive a new DSRK (if 1047 required), rRK, and rIK before proceeding with the subsequent ERP 1048 exchange. 1050 If the peer cannot verify the integrity of the received message, it 1051 MAY choose to retry the ERP exchange with one of the cryptosuites in 1052 the TLV of Type 5, after a failure has been clearly determined 1053 following the procedure in the next paragraph. 1055 If the replay or integrity checks fail, the failure message may have 1056 been sent by an attacker. It may also imply that the server and peer 1057 do not support the same cryptosuites; however, the peer cannot 1058 determine if that is the case. Hence, the peer SHOULD continue the 1059 ERP exchange per the retransmission timers before declaring a 1060 failure. 1062 When the peer runs explicit bootstrapping (ERP with the bootstrapping 1063 flag on), there may not be a local ER server available to send a DSRK 1064 Request and the domain name. In that case, the server cannot send 1065 the DSRK and MUST NOT include the domain name TLV. When the peer 1066 receives a response in the bootstrapping exchange without a domain 1067 name TLV, it assumes that there is no local ER server. The home ER 1068 server sends an rMSK to the ER authenticator, however, and the peer 1069 SHALL run the TSK establishment protocol as usual. 1071 5.3. New EAP Packets 1073 Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate 1074 and EAP-Finish. The packet format for these messages follows the EAP 1075 packet format defined in RFC 3748 [RFC3748]. 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Code | Identifier | Length | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Type | Type-Data ... 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1085 Figure 7: EAP Packet 1087 Code 1089 5 Initiate 1090 6 Finish 1092 Two new code values are defined for the purpose of ERP. 1094 Identifier 1096 The Identifier field is one octet. The Identifier field MUST 1097 be the same if an EAP-Initiate packet is retransmitted due to a 1098 timeout while waiting for a Finish message. Any new (non- 1099 retransmission) Initiate message MUST use a new Identifier 1100 field. 1102 The Identifier field of the Finish message MUST match that of 1103 the currently outstanding Initiate message. A peer or 1104 authenticator receiving a Finish message whose Identifier value 1105 does not match that of the currently outstanding Initiate 1106 message MUST silently discard the packet. 1108 In order to avoid confusion between new EAP-Initiate messages 1109 and retransmissions, the peer must choose an Identifier value 1110 that is different from the previous EAP-Initiate message, 1111 especially if that exchange has not finished. It is 1112 RECOMMENDED that the authenticator clear EAP Re-auth state 1113 after 300 seconds. 1115 Type 1117 This field indicates that this is an ERP exchange. Two type 1118 values are defined in this document for this purpose -- Re- 1119 auth-Start (assigned Type 1) and Re-auth (assigned Type 2). 1121 Type-Data 1123 The Type-Data field varies with the Type of re-authentication 1124 packet. 1126 5.3.1. EAP-Initiate/Re-auth-Start Packet 1128 The EAP-Initiate/Re-auth-Start packet contains the parameters shown 1129 in Figure 8. 1131 0 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Code | Identifier | Length | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Type | Reserved | 1 or more TVs or TLVs ~ 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 Figure 8: EAP-Initiate/Re-auth-Start Packet 1141 Type = 1. 1143 Reserved, MUST be zero. Set to zero on transmission and ignored 1144 on reception. 1146 One or more TVs or TLVs are used to convey information to the 1147 peer; for instance, the authenticator may send the domain name to 1148 the peer. 1150 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1151 and a value with type-specific length. In the TLV payloads, there 1152 is a 1-octet type payload and a 1-octet length payload. The 1153 length field indicates the length of the value expressed in number 1154 of octets. 1156 Domain-Name: This is a TLV payload. The Type is 4. The domain 1157 name is to be used as the realm in an NAI [RFC4282]. The 1158 Domain-Name attribute SHOULD be present in an EAP-Initiate/ 1159 Re-auth-Start message. 1161 In addition, channel binding information MAY be included; see 1162 Section 5.5 for discussion. See Figure 12 for parameter 1163 specification. 1165 5.3.1.1. Authenticator Operation 1167 In order to minimize ERP failure times, the authenticator SHOULD send 1168 the EAP-Initiate/Re-auth-Start message to indicate support for ERP to 1169 the peer and to initiate ERP if the peer has already performed full 1170 EAP authentication and has unexpired key material. The authenticator 1171 SHOULD include the domain name TLV to allow the peer to learn it 1172 without lower-layer support or the ERP bootstrapping exchange. 1174 The authenticator MAY include channel binding information so that the 1175 peer can send the information to the server in the EAP-Initiate/ 1176 Re-auth message so that the server can verify whether the 1177 authenticator is claiming the same identity to both parties. 1179 The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start 1180 message a few times for reliable transport. 1182 5.3.1.2. Peer Operation 1184 The peer SHOULD send the EAP-Initiate/Re-auth message in response to 1185 the EAP-Initiate/Re-auth-Start message from the authenticator. If 1186 the peer does not recognize the Initiate code value, it silently 1187 discards the message. If the peer has already sent the EAP-Initiate/ 1188 Re-auth message to begin the ERP exchange, it silently discards the 1189 message. 1191 If the EAP-Initiate/Re-auth-Start message contains the domain name, 1192 and if the peer does not already have the domain information, the 1193 peer SHOULD use the domain name to compute the DSRK and use the 1194 corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start 1195 an ERP exchange with the local ER server. If there are the local ER 1196 server between the peer and the home ER server and the peer has 1197 already initiated an ERP exchange with the local ER server, it SHOULD 1198 choose to not start an ERP exchange with the home ER server. 1200 5.3.2. EAP-Initiate/Re-auth Packet 1202 The EAP-Initiate/Re-auth packet contains the parameters shown in 1203 Figure 9. 1205 0 1 2 3 1206 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 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Code | Identifier | Length | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Type |R|B|L| Reserved| SEQ | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | 1 or more TVs or TLVs ~ 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | cryptosuite | Authentication Tag ~ 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 Figure 9: EAP-Initiate/Re-auth Packet 1219 Type = 2. 1221 Flags 1223 'R' - The R flag is set to 0 and ignored upon reception. 1225 'B' - The B flag is used as the bootstrapping flag. If the 1226 flag is turned on, the message is a bootstrap message. 1228 'L' - The L flag is used to request the key lifetimes from the 1229 server. 1231 The rest of the 5 bits are set to 0 and ignored on reception. 1233 SEQ: A 16-bit sequence number is used for replay protection. The 1234 SEQ number field is initialized to 0 every time a new rRK is 1235 derived. 1237 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1238 and a value with type-specific length. In the TLV payloads, there 1239 is a 1-octet type payload and a 1-octet length payload. The 1240 length field indicates the length of the value expressed in number 1241 of octets. 1243 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1244 The NAI is variable in length, not exceeding 253 octets. The 1245 EMSKname is in the username part of the NAI and is encoded in 1246 hexadecimal values. The EMSKname is 64 bits in length and so 1247 the username portion takes up 128 octets. If the rIK is 1248 derived from the EMSK, the realm part of the NAI is the home 1249 domain name, and if the rIK is derived from a DSRK, the realm 1250 part of the NAI is the domain name used in the derivation of 1251 the DSRK. The NAI syntax follows [RFC4282]. Exactly one 1252 keyName-NAI attribute SHALL be present in an EAP-Initiate/ 1253 Re-auth packet. 1255 In addition, channel binding information MAY be included; see 1256 Section 5.5 for discussion. See Figure 12 for parameter 1257 specification. 1259 Cryptosuite: This field indicates the integrity algorithm used for 1260 ERP. Key lengths and output lengths are either indicated or are 1261 obvious from the cryptosuite name. We specify some cryptosuites 1262 below: 1264 * 0 RESERVED 1266 * 1 HMAC-SHA256-64 1268 * 2 HMAC-SHA256-128 1270 * 3 HMAC-SHA256-256 1272 HMAC-SHA256-128 is mandatory to implement and should be enabled in 1273 the default configuration. 1275 Authentication Tag: This field contains the integrity checksum 1276 over the ERP packet, excluding the authentication tag field 1277 itself. The length of the field is indicated by the Cryptosuite. 1279 5.3.3. EAP-Finish/Re-auth Packet 1281 The EAP-Finish/Re-auth packet contains the parameters shown in 1282 Figure 10. 1284 0 1 2 3 1285 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 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Code | Identifier | Length | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Type |R|B|L| Reserved | SEQ ~ 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | 1 or more TVs or TLVs ~ 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | cryptosuite | Authentication Tag ~ 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 Figure 10: EAP-Finish/Re-auth Packet 1298 Type = 2. 1300 Flags 1302 'R' - The R flag is used as the Result flag. When set to 0, it 1303 indicates success, and when set to '1', it indicates a failure. 1305 'B' - The B flag is used as the bootstrapping flag. If the 1306 flag is turned on, the message is a bootstrap message. 1308 'L' - The L flag is used to indicate the presence of the rRK 1309 lifetime TLV. 1311 The rest of the 5 bits are set to 0 and ignored on reception. 1313 SEQ: A 16-bit sequence number is used for replay protection. The 1314 SEQ number field is initialized to 0 every time a new rRK is 1315 derived. 1317 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1318 and a value with type-specific length. In the TLV payloads, there 1319 is a 1-octet type payload and a 1-octet length payload. The 1320 length field indicates the length of the value expressed in number 1321 of octets. 1323 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1324 The NAI is variable in length, not exceeding 253 octets. 1325 EMSKname is in the username part of the NAI and is encoded in 1326 hexadecimal values. The EMSKname is 64 bits in length and so 1327 the username portion takes up 16 octets. If the rIK is derived 1328 from the EMSK, the realm part of the NAI is the home domain 1329 name, and if the rIK is derived from a DSRK, the realm part of 1330 the NAI is the domain name used in the derivation of the DSRK. 1331 The NAI syntax follows [RFC4282]. Exactly one instance of the 1332 keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth 1333 message. 1335 rRK Lifetime: This is a TV payload. The Type is 2. The value 1336 field is a 32-bit field and contains the lifetime of the rRK in 1337 seconds. If the 'L' flag is set, the rRK Lifetime attribute 1338 SHOULD be present. 1340 rMSK Lifetime: This is a TV payload. The Type is 3. The value 1341 field is a 32-bit field and contains the lifetime of the rMSK 1342 in seconds. If the 'L' flag is set, the rMSK Lifetime 1343 attribute SHOULD be present. 1345 Domain-Name: This is a TLV payload. The Type is 4. The domain 1346 name is to be used as the realm in an NAI [RFC4282]. Domain- 1347 Name attribute MUST be present in an EAP-Finish/Re-auth message 1348 if the bootstrapping flag is set and if the local ER server 1349 sent a DSRK request. 1351 List of cryptosuites: This is a TLV payload. The Type is 5. 1352 The value field contains a list of cryptosuites, each of size 1 1353 octet. The cryptosuite values are as specified in Figure 9. 1354 The server SHOULD include this attribute if the cryptosuite 1355 used in the EAP-Initiate/Re-auth message was not acceptable and 1356 the message is being rejected. The server MAY include this 1357 attribute in other cases. The server MAY use this attribute to 1358 signal to the peer about its cryptographic algorithm 1359 capabilities. 1361 Authorization Indication: This is a TLV payload. The Type is 1362 6. This attribute MAY be included in the EAP-Finish/Re-auth 1363 message when a DSRK is delivered to a local ER server and if 1364 the home EAP server can verify the authorization of the local 1365 ER server to advertise the domain name included in the domain 1366 TLV in the same message. The value field in the TLV contains 1367 an authentication tag computed over the entire packet, starting 1368 from the first bit of the code field to the last bit of the 1369 cryptosuite field, with the value field of the Authorization 1370 Indication TLV filled with all 0s for the computation. The key 1371 used for the computation MUST be derived from the EMSK with key 1372 label "DSRK Delivery Authorized Key@ietf.org" and optional data 1373 containing an ASCII string representing the key management 1374 domain that the DSRK is being derived for. 1376 In addition, channel binding information MAY be included: see 1377 Section 5.5 for discussion. See Figure 12 for parameter 1378 specification. The server sends this information so that the 1379 peer can verify the information seen at the lower layer, if 1380 channel binding is to be supported. 1382 Cryptosuite: This field indicates the integrity algorithm and the 1383 PRF used for ERP. Key lengths and output lengths are either 1384 indicated or are obvious from the cryptosuite name. 1386 Authentication Tag: This field contains the integrity checksum 1387 over the ERP packet, excluding the authentication tag field 1388 itself. The length of the field is indicated by the Cryptosuite. 1390 5.3.4. TV and TLV Attributes 1392 The TV attributes that may be present in the EAP-Initiate or EAP- 1393 Finish messages are of the following format: 1395 0 1 2 3 1396 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 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Type | Value ... 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 Figure 11: TV Attribute Format 1403 The TLV attributes that may be present in the EAP-Initiate or EAP- 1404 Finish messages are of the following format: 1406 0 1 2 3 1407 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 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Type | Length | Value ... 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 Figure 12: TLV Attribute Format 1414 The following Types are defined in this document: 1416 '1' - keyName-NAI: This is a TLV payload. 1418 '2' - rRK Lifetime: This is a TV payload. 1420 '3' - rMSK Lifetime: This is a TV payload. 1422 '4' - domain name: This is a TLV payload. 1424 '5' - cryptosuite list: This is a TLV payload. 1426 '6' - Authorization Indication: This is a TLV payload. 1428 The TLV type range of 128-191 is reserved to carry channel binding 1429 information in the EAP-Initiate and Finish/Re-auth messages. 1430 Below are the current assignments (all of them are TLVs): 1432 '128' - Called-Station-Id [RFC2865] 1434 '129' - Calling-Station-Id [RFC2865] 1436 '130' - NAS-Identifier [RFC2865] 1438 '131' - NAS-IP-Address [RFC2865] 1440 '132' - NAS-IPv6-Address [RFC3162] 1442 The length field indicates the length of the value part of the 1443 attribute in octets. 1445 5.4. Replay Protection 1447 For replay protection, ERP uses sequence numbers. The sequence 1448 number is maintained per rIK and is initialized to zero in both 1449 directions. In the first EAP-Initiate/Re-auth message, the peer uses 1450 the sequence number zero or higher. Note that the when the sequence 1451 number rotates, the rIK MUST be changed by running EAP 1452 authentication. The server expects a sequence number of zero or 1453 higher. When the server receives an EAP-Initiate/Re-auth message, it 1454 uses the same sequence number in the EAP-Finish/Re-auth message. The 1455 server then sets the expected sequence number to the received 1456 sequence number plus 1. The server accepts sequence numbers greater 1457 than or equal to the expected sequence number. 1459 If the peer sends an EAP-Initiate/Re-auth message, but does not 1460 receive a response, it retransmits the request (with no changes to 1461 the message itself) a pre-configured number of times before giving 1462 up. However, it is plausible that the server itself may have 1463 responded to the message and it was lost in transit. Thus, the peer 1464 MUST increment the sequence number and use the new sequence number to 1465 send subsequent EAP re-authentication messages. The peer SHOULD 1466 increment the sequence number by 1; however, it may choose to 1467 increment by a larger number. When the sequence number rotates, the 1468 peer MUST run full EAP authentication. 1470 5.5. Channel Binding 1472 ERP provides a protected facility to carry channel binding (CB) 1473 information, according to the guidelines in Section 7.15 of 1474 [RFC3748]. The TLV type range of 128-191 is reserved to carry CB 1475 information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth 1476 messages. Called-Station-Id, Calling-Station-Id, NAS-Identifier, 1477 NAS-IP-Address, and NAS-IPv6-Address are some examples of channel 1478 binding information listed in RFC 3748, and they are assigned values 1479 128-132. Additional values are IANA managed based on IETF Consensus 1480 [RFC5226]. 1482 The authenticator MAY provide CB information to the peer via the EAP- 1483 Initiate/Re-auth-Start message. The peer sends the information to 1484 the server in the EAP-Initiate/Re-auth message; the server verifies 1485 whether the authenticator identity available via AAA attributes is 1486 the same as the identity provided to the peer. 1488 If the peer does not include the CB information in the EAP-Initiate/ 1489 Re-auth message, and if the local ER server's policy requires channel 1490 binding support, it SHALL send the CB attributes for the peer's 1491 verification. The peer attempts to verify the CB information if the 1492 authenticator has sent the CB parameters, and it proceeds with the 1493 lower-layer security association establishment if the attributes 1494 match. Otherwise, the peer SHALL NOT proceed with the lower-layer 1495 security association establishment. 1497 6. Lower-Layer Considerations 1499 The authenticator is responsible for retransmission of EAP-Initiate/ 1500 Re-auth-Start messages. The authenticator MAY retransmit the message 1501 a few times or until it receives an EAP-Initiate/Re-auth message from 1502 the peer. The authenticator may not know whether the peer supports 1503 ERP; in those cases, the peer may be silently dropping the EAP- 1504 Initiate/Re-auth-Start packets. Thus, retransmission of these 1505 packets should be kept to a minimum. The exact number is up to each 1506 lower layer. 1508 The Identifier value in the EAP-Initiate/Re-auth packet is 1509 independent of the Identifier value in the EAP-Initiate/Re-auth-Start 1510 packet. 1512 The peer is responsible for retransmission of EAP-Initiate/Re-auth 1513 messages. 1515 Retransmitted packets MUST be sent with the same Identifier value in 1516 order to distinguish them from new packets. By default, where the 1517 EAP-Initiate message is sent over an unreliable lower layer, the 1518 retransmission timer SHOULD be dynamically estimated. A maximum of 1519 3-5 retransmissions is suggested (this is based on the recommendation 1520 of [RFC3748]). Where the EAP-Initiate message is sent over a 1521 reliable lower layer, the retransmission timer SHOULD be set to an 1522 infinite value, so that retransmissions do not occur at the EAP 1523 layer. Please refer to RFC 3748 [RFC3748] for additional guidance on 1524 setting timers. 1526 The Identifier value in the EAP-Finish/Re-auth packet is the same as 1527 the Identifier value in the EAP-Initiate/Re-auth packet. 1529 If an authenticator receives a valid duplicate EAP-Initiate/Re-auth 1530 message for which it has already sent an EAP-Finish/Re-auth message, 1531 it MUST resend the EAP-Finish/Re-auth message without reprocessing 1532 the EAP-Initiate/Re-auth message. To facilitate this, the 1533 authenticator SHALL store a copy of the EAP-Finish/Re-auth message 1534 for a finite amount of time. The actual value of time is a local 1535 matter; this specification recommends a value of 100 milliseconds. 1537 The lower layer may provide facilities for exchanging information 1538 between the peer and the authenticator about support for ERP, for the 1539 authenticator to send the domain name information and channel binding 1540 information to the peer 1542 Note that to support ERP, lower-layer specifications may need to be 1543 revised. Specifically, the IEEE802.1x specification must be revised 1544 to allow carrying EAP messages of the new codes defined in this 1545 document in order to support ERP. Similarly, RFC 5996 must be 1546 updated to include EAP code values higher than 4 in order to use ERP 1547 with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may 1548 also be updated to support peer-initiated ERP for optimized 1549 operation. Other lower layers may need similar revisions. 1551 Our analysis indicates that some EAP implementations are not RFC 3748 1552 compliant in that instead of silently dropping EAP packets with code 1553 values higher than 4, they may consider it an error. To accommodate 1554 such non-compliant EAP implementations, additional guidance has been 1555 provided below. Furthermore, it may not be easy to upgrade all the 1556 peers in some cases. In such cases, authenticators may be configured 1557 to not send EAP-Initiate/Re-auth-Start; peers may learn whether an 1558 authenticator supports ERP via configuration, from advertisements at 1559 the lower layer. 1561 In order to accommodate implementations that are not compliant to RFC 1562 3748, such lower layers SHOULD ensure that both parties support ERP; 1563 this is trivial for an instance when using a lower layer that is 1564 known to always support ERP. For lower layers where ERP support is 1565 not guaranteed, ERP support may be indicated through signaling (e.g., 1566 piggy-backed on a beacon) or through negotiation. Alternatively, 1567 clients may recognize environments where ERP is available based on 1568 pre-configuration. Other similar mechanisms may also be used. When 1569 ERP support cannot be verified, lower layers may mandate falling back 1570 to full EAP authentication to accommodate EAP implementations that 1571 are not compliant to RFC 3748. 1573 7. Transport of ERP Messages 1575 AAA Transport of ERP messages is specified in [RFC5749] and 1576 [I-D.ietf-dime-erp]. 1578 8. Security Considerations 1580 This section provides an analysis of the protocol in accordance with 1581 the AAA key management requirements specified in [RFC4962]. 1583 Cryptographic algorithm independence 1585 The EAP Re-auth Protocol satisfies this requirement. The 1586 algorithm chosen by the peer for the MAC generation is 1587 indicated in the EAP-Initiate/Re-auth message. If the chosen 1588 algorithm is unacceptable, the EAP server returns an EAP- 1589 Finish/Re-auth message with Failure indication. Algorithm 1590 agility for the KDF is specified in [RFC5295]. Only when the 1591 algorithms used are acceptable, the server proceeds with 1592 derivation of keys and verification of the proof of possession 1593 of relevant keying material by the peer. A full-blown 1594 negotiation of algorithms cannot be provided in a single round 1595 trip protocol. Hence, while the protocol provides algorithm 1596 agility, it does not provide true negotiation. 1598 Strong, fresh session keys 1600 ERP results in the derivation of strong, fresh keys that are 1601 unique for the given session. An rMSK is always derived on- 1602 demand when the peer requires a key with a new authenticator. 1603 The derivation ensures that the compromise of one rMSK does not 1604 result in the compromise of a different rMSK at any time. 1606 Limit key scope 1608 The scope of all the keys derived by ERP is well defined. The 1609 rRK and rIK are never shared with any entity and always remain 1610 on the peer and the server. The rMSK is provided only to the 1611 authenticator through which the peer performs the ERP exchange. 1612 No other authenticator is authorized to use that rMSK. 1614 Replay detection mechanism 1616 For replay protection of ERP messages, a sequence number 1617 associated with the rIK is used. The sequence number is 1618 maintained by the peer and the server, and initialized to zero 1619 when the rIK is generated. The peer increments the sequence 1620 number by one after it sends an ERP message. The server sets 1621 the expected sequence number to the received sequence number 1622 plus one after verifying the validity of the received message 1623 and responds to the message. 1625 Authenticate all parties 1627 The EAP Re-auth Protocol provides mutual authentication of the 1628 peer and the server. Both parties need to possess the keying 1629 material that resulted from a previous EAP exchange in order to 1630 successfully derive the required keys. Also, both the EAP re- 1631 authentication Response and the EAP re-authentication 1632 Information messages are integrity protected so that the peer 1633 and the server can verify each other. When the ERP exchange is 1634 executed with a local ER server, the peer and the local server 1635 mutually authenticate each other via that exchange in the same 1636 manner. The peer and the authenticator authenticate each other 1637 in the secure association protocol executed by the lower layer, 1638 just as in the case of a regular EAP exchange. 1640 Peer and authenticator authorization 1642 The peer and authenticator demonstrate possession of the same 1643 key material without disclosing it, as part of the lower-layer 1644 secure association protocol. Channel binding with ERP may be 1645 used to verify consistency of the identities exchanged, when 1646 the identities used in the lower layer differ from that 1647 exchanged within the AAA protocol. 1649 Keying material confidentiality 1651 The peer and the server derive the keys independently using 1652 parameters known to each entity. The AAA server sends the DSRK 1653 of a domain to the corresponding local ER server via the AAA 1654 protocol. Likewise, the ER server sends the rMSK to the 1655 authenticator via the AAA protocol. 1657 Note that compromise of the DSRK results in compromise of all 1658 keys derived from it. Moreover, there is no forward secrecy 1659 within ERP. Thus, compromise of an DSRK retroactively 1660 compromises all ERP keys. 1662 It is RECOMMENDED that the AAA protocol be protected using 1663 IPsec or TLS so that the keys are protected in transit. Note, 1664 however, that keys may be exposed to AAA proxies along the way 1665 and compromise of any of those proxies may result in compromise 1666 of keys being transported through them. 1668 The home EAP server MUST NOT hand out a given DSRK to a local 1669 domain server more than once, unless it can verify that the 1670 entity receiving the DSRK after the first time is the same as 1671 that received the DSRK originally. If the home EAP server 1672 verifies authorization of a local domain server, it MAY hand 1673 out the DSRK to that domain more than once. In this case, the 1674 home EAP server includes the Authorization Indication TLV to 1675 assure the peer that DSRK delivery is secure. 1677 Confirm cryptosuite selection 1679 Crypto algorithms for integrity and key derivation in the 1680 context of ERP MAY be the same as that used by the EAP method. 1681 In that case, the EAP method is responsible for confirming the 1682 cryptosuite selection. Furthermore, the cryptosuite is 1683 included in the ERP exchange by the peer and confirmed by the 1684 server. The protocol allows the server to reject the 1685 cryptosuite selected by the peer and provide alternatives. 1686 When a suitable rIK is not available for the peer, the 1687 alternatives may be sent in an unprotected fashion. The peer 1688 is allowed to retry the exchange using one of the allowed 1689 cryptosuites. However, in this case, any en route 1690 modifications to the list sent by the server will go 1691 undetected. If the server does have an rIK available for the 1692 peer, the list will be provided in a protected manner and this 1693 issue does not apply. 1695 Uniquely named keys 1697 All keys produced within the ERP context can be referred to 1698 uniquely as specified in this document. Also, the key names do 1699 not reveal any part of the keying material. 1701 Prevent the domino effect 1703 The compromise of one peer does not result in the compromise of 1704 keying material held by any other peer in the system. Also, 1705 the rMSK is meant for a single authenticator and is not shared 1706 with any other authenticator. Hence, the compromise of one 1707 authenticator does not lead to the compromise of sessions or 1708 keys held by any other authenticator in the system. Hence, the 1709 EAP Re-auth Protocol allows prevention of the domino effect by 1710 appropriately defining key scope. 1712 However, if keys are transported using hop-by-hop protection, 1713 compromise of a proxy may result in compromise of key material, 1714 i.e., the DSRK being sent to a local ER server. 1716 Bind key to its context 1718 All the keys derived for ERP are bound to the appropriate 1719 context using appropriate key labels. Lifetime of a child key 1720 is less than or equal to that of its parent key as specified in 1721 RFC 4962 [RFC4962]. The key usage, lifetime and the parties 1722 that have access to the keys are specified. 1724 Confidentiality of identity 1726 Deployments where privacy is a concern may find the use of 1727 rIKname-NAI to route ERP messages serves their privacy 1728 requirements. Note that it is plausible to associate multiple 1729 runs of ERP messages since the rIKname is not changed as part 1730 of the ERP protocol. There was no consensus for that 1731 requirement at the time of development of this specification. 1732 If the rIKname is not used and the Peer-ID is used instead, the 1733 ERP exchange will reveal the Peer-ID over the wire. 1735 Authorization restriction 1737 All the keys derived are limited in lifetime by that of the 1738 parent key or by server policy. Any domain-specific keys are 1739 further restricted for use only in the domain for which the 1740 keys are derived. All the keys specified in this document are 1741 meant for use in ERP only. Any other restrictions of session 1742 keys may be imposed by the specific lower layer and are out of 1743 scope for this specification. 1745 Prevent DoS attack 1747 A denial-of-service (DoS) attack on the peer may be possible 1748 when using the EAP Initiate/Re-auth message. An attacker may 1749 send a bogus EAP-Initiate/Re-auth message, which may be carried 1750 by the authenticator in a RADIUS-Access-Request to the server; 1751 in response, the server may send an EAP-Finish/Re-auth with 1752 Failure indication in a RADIUS Access-Reject message. Note 1753 that such attacks may be plausible with the EAPoL-Start 1754 capability of IEEE 802.11 and other similar facilities in other 1755 link layers and where the peer can initiate EAP authentication. 1756 An attacker may use such messages to start an EAP method run, 1757 which fails and may result in the server sending a RADIUS 1758 Access-Reject message, thus resulting in the link-layer 1759 connections being terminated. 1761 To prevent such DoS attacks, an ERP failure should not result 1762 in deletion of any authorization state established by a full 1763 EAP exchange. Alternatively, the lower layers and AAA 1764 protocols may define mechanisms to allow two link-layer 1765 security associations (SAs) derived from different EAP keying 1766 materials for the same peer to exist so that smooth migration 1767 from the current link layer SA to the new one is possible 1768 during rekey. These mechanisms prevent the link layer 1769 connections from being terminated when a re-authentication 1770 procedure fails due to the bogus EAP-Initiate/Re-auth message. 1772 Keying materials Transport 1774 When a DSRK is sent from a home EAP server to a local domain 1775 server or when a rMSK is sent from an ER server to an 1776 authenticator, in the absence of end-to-end security between 1777 the entity that is sending the key and the entity receiving the 1778 key, it is plausible for other entities to get access to keys 1779 being sent to an ER server in another domain. This mode of key 1780 transport is similar to that of MSK transport in the context of 1781 EAP authentication. We further observe that ERP is for access 1782 authentication and does not support end-to-end data security. 1783 In typical implementations, the traffic is in the clear beyond 1784 the access control enforcement point (the authenticator or an 1785 entity delegated by the authenticator for access control 1786 enforcement). The model works as long as entities in the 1787 middle of the network do not use keys intended for other 1788 parties to steal service from an access network. If that is 1789 not achievable, key delivery must be protected in an end-to-end 1790 manner. 1792 9. IANA Considerations 1794 This document has no IANA actions; all values referenced in this 1795 document were previously assigned in RFC 5296 [RFC5296]. 1797 10. References 1799 10.1. Normative References 1801 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1802 Hashing for Message Authentication", RFC 2104, 1803 February 1997. 1805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1806 Requirement Levels", BCP 14, RFC 2119, March 1997. 1808 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1809 Levkowetz, "Extensible Authentication Protocol (EAP)", 1810 RFC 3748, June 2004. 1812 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1813 Network Access Identifier", RFC 4282, December 2005. 1815 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 1816 "Specification for the Derivation of Root Keys from an 1817 Extended Master Session Key (EMSK)", RFC 5295, 1818 August 2008. 1820 10.2. Informative References 1822 [I-D.ietf-dime-erp] 1823 Bournelle, J., Morand, L., Decugis, S., Wu, W., and G. 1824 Zorn, "Diameter support for EAP Re-authentication Protocol 1825 (ERP)", draft-ietf-dime-erp-06 (work in progress), 1826 May 2011. 1828 [I-D.ietf-dime-local-keytran] 1829 , Q. and G. , "Diameter Attribute-Value Pairs for 1830 Cryptographic Key Transport", 1831 draft-ietf-dime-local-keytran-07 (work in progress), 1832 July 2010. 1834 [I-D.ietf-hokey-ldn-discovery] 1835 Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name 1836 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in 1837 progress), September 2010. 1839 [IEEE_802.1X] 1840 Institute of Electrical and Electronics Engineers, "IEEE 1841 Standards for Local and Metropolitan Area Networks: Port 1842 based Network Access Control, IEEE Std 802.1X-2004", 1843 December 2004. 1845 [MSKHierarchy] 1846 Lopez, R., Skarmeta, A., Bournelle, J., Laurent- 1847 Maknavicus, M., and J. Combes, "Improved EAP keying 1848 framework for a secure mobility access service", 1849 IWCMC '06, Proceedings of the 2006 International 1850 Conference on Wireless Communications and 1851 Mobile Computing, New York, NY, USA, 2006. 1853 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1854 "Remote Authentication Dial In User Service (RADIUS)", 1855 RFC 2865, June 2000. 1857 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1858 RFC 3162, August 2001. 1860 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1861 Dial In User Service) Support For Extensible 1862 Authentication Protocol (EAP)", RFC 3579, September 2003. 1864 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1865 Protocol Method for 3rd Generation Authentication and Key 1866 Agreement (EAP-AKA)", RFC 4187, January 2006. 1868 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1869 Authorization, and Accounting (AAA) Key Management", 1870 BCP 132, RFC 4962, July 2007. 1872 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 1873 "Handover Key Management and Re-Authentication Problem 1874 Statement", RFC 5169, March 2008. 1876 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1877 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1878 May 2008. 1880 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 1881 authentication Protocol (ERP)", RFC 5296, August 2008. 1883 [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of 1884 EAP-Based Keys for Handover and Re-Authentication", 1885 RFC 5749, March 2010. 1887 [RFC5996] Kaufman, C., Hoffman , P., Nir, Y., and P. Eronen, 1888 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1889 RFC 5996, September 2010. 1891 Appendix A. Acknowledgments 1893 A.1. RFC 5296 1895 In writing this document, we benefited from discussing the problem 1896 space and the protocol itself with a number of folks including 1897 Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, 1898 Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, 1899 Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi 1900 Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of 1901 the HOKEY working group. The credit for the idea to use EAP- 1902 Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- 1903 layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin 1904 Hoeper suggested the use of the windowing technique to handle 1905 multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for 1906 the suggestion to use hexadecimal encoding for rIKname when sent as 1907 part of keyName-NAI field. Thanks to Bernard Aboba for suggestions 1908 in clarifying the EAP lock-step operation, and Joe Salowey and Glen 1909 Zorn for help in specifying AAA transport of ERP messages. Thanks to 1910 Sam Hartman for the DSRK Authorization Indication mechanism. 1912 A.2. RFC 5296bis 1914 Glen Zorn wrote the initial draft for this document and provided 1915 useful reviews. Many thanks to him. 1917 A.3. Change Log 1919 A.3.1. draft-ietf-hokey-rfc5296bis-02 1921 The following are the major changes compared to previous version: 1923 o Change using MAY in section 5.3.1.1 to using SHOULD 1925 o Mandate sending the EAP-Initiate/Re-auth-Start message instead of 1926 optional 1928 o Update obsolete reference RFC4306 into RFC5996 1930 o Allow local server respond to the peer directly without forwarding 1931 the ERP message to the home domain 1933 A.3.2. draft-ietf-hokey-rfc5296bis-03 1935 The following are the major changes compared to previous version: 1937 o Add explanation texts to clarify why SHOULD is used instead of 1938 MAY. 1940 o Additional texts to optimize implicit bootstrapping in section 1941 5.1. 1943 o Additional texts to optimize explicit bootstrapping in section 1944 5.1. 1946 o Add two new bullets with text in section 8 unmodified. 1948 Appendix B. Example ERP Exchange 1950 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] 1952 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, 1953 cryptosuite,Auth-tag*) 1955 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, 1956 EAP Initiate/Re-auth(SEQ,keyName-NAI, 1957 cryptosuite,Auth-tag*) 1959 2. ER-Server --> Authenticator: AAA-Response{rMSK, 1960 EAP-Finish/Re-auth(SEQ,keyName-NAI, 1961 cryptosuite,[CB-Info],Auth-tag*) 1963 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, 1964 cryptosuite,[CB-Info],Auth-tag*) 1966 * Auth-tag computation is over the entire EAP Initiate/Finish message; 1967 the code values for Initiate and Finish are different and thus 1968 reflection attacks are mitigated. 1970 Authors' Addresses 1972 Qin Wu (editor) 1973 Huawei Technologies Co., Ltd. 1974 101 Software Avenue, Yuhua District 1975 Nanjing, JiangSu 210012 1976 China 1978 Email: Sunseawq@huawei.com 1979 Zhen Cao 1980 China Mobile 1981 53A Xibianmennei Ave., Xuanwu District 1982 Beijing, Beijing 100053 1983 P.R. China 1985 Email: caozhen@chinamobile.com 1987 Yang Shi 1988 H3C Tech. Co., Ltd 1989 Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District 1990 Beijing 100085 1991 China 1993 Email: young@h3c.com 1995 Baohong He 1996 China 1998 Email: hebaohong@catr.cn