idnits 2.17.1 draft-ietf-hokey-erx-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1951. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1839 has weird spacing: '...ver and re-au...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 29, 2008) is 5865 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) -- Looks like a reference, but probably isn't: 'Bootstrap' on line 261 == Outdated reference: A later version (-07) exists of draft-ietf-hokey-emsk-hierarchy-04 ** Obsolete normative reference: RFC 4282 (ref. '4') (Obsoleted by RFC 7542) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') == Outdated reference: A later version (-13) exists of draft-ietf-hokey-key-mgm-03 == Outdated reference: A later version (-02) exists of draft-dondeti-dime-erp-diameter-01 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '17') (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Narayanan 3 Internet-Draft L. Dondeti 4 Intended status: Standards Track Qualcomm, Inc. 5 Expires: September 30, 2008 March 29, 2008 7 EAP Extensions for EAP Re-authentication Protocol (ERP) 8 draft-ietf-hokey-erx-14 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 30, 2008. 35 Abstract 37 The Extensible Authentication Protocol (EAP) is a generic framework 38 supporting multiple types of authentication methods. In systems 39 where EAP is used for authentication, it is desirable to not repeat 40 the entire EAP exchange with another authenticator. This document 41 specifies extensions to EAP and EAP keying hierarchy to support an 42 EAP method-independent protocol for efficient re-authentication 43 between the peer and an EAP re-authentication server through any 44 authenticator. The re-authentication server may be in the home 45 network or in the local network that the peer is connecting to. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 6 53 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 8 54 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 10 55 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 11 56 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 12 57 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 12 58 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 13 59 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 13 60 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 14 61 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 15 62 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 15 63 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 15 64 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 18 65 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 20 66 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 21 67 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 22 68 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 23 69 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 24 70 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 26 71 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 29 72 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30 73 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30 74 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 31 75 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 32 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 40 82 Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 41 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 84 Intellectual Property and Copyright Statements . . . . . . . . . . 43 86 1. Introduction 88 The Extensible Authentication Protocol (EAP) is a an authentication 89 framework which supports multiple authentication methods. The 90 primary purpose is network access authentication, and a key- 91 generating method is used when the lower layer wants to enforce 92 access control. The EAP keying hierarchy defines two keys to be 93 derived by all key generating EAP methods: the Master Session Key 94 (MSK) and the Extended MSK (EMSK). In the most common deployment 95 scenario, an EAP peer and an EAP server authenticate each other 96 through a third party known as the EAP authenticator. The EAP 97 authenticator or an entity controlled by the EAP authenticator 98 enforces access control. After successful authentication, the EAP 99 server transports the MSK to the EAP authenticator; the EAP 100 authenticator and the EAP peer establish transient session keys (TSK) 101 using the MSK as the authentication key, key derivation key or a key 102 transport key, and use the TSK for per-packet access enforcement. 104 When a peer moves from one authenticator to another, it is desirable 105 to avoid a full EAP authentication to support fast handovers. The 106 full EAP exchange with another run of the EAP method can take several 107 round trips and significant time to complete, causing delays in 108 handover times. Some EAP methods specify the use of state from the 109 initial authentication to optimize re-authentications by reducing the 110 computational overhead, but method-specific re-authentication takes 111 at least 2 round trips with the original EAP server in most cases 112 (e.g., [6]). It is also important to note that several methods do 113 not offer support for re-authentication. 115 Key sharing across authenticators is sometimes used as a practical 116 solution to lower handover times. In that case, compromise of an 117 authenticator results in compromise of keying material established 118 via other authenticators. Other solutions for fast re-authentication 119 exist in the literature [7] [8]. 121 In conclusion, to achieve low latency handovers, there is a need for 122 a method-independent re-authentication protocol that completes in 123 less than 2 round trips, preferably with a local server. The EAP re- 124 authentication problem statement is described in detail in [9]. 126 This document specifies EAP Re-authentication Extensions (ERX) for 127 efficient re-authentication using EAP. The protocol that uses these 128 extensions itself is referred to as the EAP re-authentication 129 Protocol (ERP). It supports EAP method independent re-authentication 130 for a peer that has valid, unexpired key material from a previously 131 performed EAP authentication. The protocol and the key hierarchy 132 required for EAP re-authentication is described in this document. 134 Note that to support ERP, lower layer specifications may need to be 135 revised to allow carrying EAP messages that have a code value higher 136 than 4 and to accommodate the peer-initiated nature of ERP. 137 Specifically, the IEEE802.1x specification must be revised and RFC 138 4306 must be updated to carry ERP messages. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [1]. 146 This document uses the basic EAP terminology [2] and EMSK keying 147 hierarchy terminology [3]. In addition, this document uses the 148 following terms: 150 ER peer - An EAP peer that supports the EAP re-authentication 151 protocol. All references to "peer" in this document imply an ER 152 peer, unless specifically noted otherwise. 154 ER Authenticator - An entity that supports the authenticator 155 functionality for EAP re-authentication described in this 156 document. All references to "authenticator" in this document 157 imply an ER authenticator, unless specifically noted otherwise. 159 ER Server - An entity that performs the server portion of ERP 160 described here. This entity may or may not be an EAP server. All 161 references to "server" in this document imply an ER server, unless 162 specifically noted otherwise. ER server is a logical entity; the 163 home ER server is located on the same backend authentication 164 server as the EAP server in the home domain. The local ER server 165 may not necessarily be a full EAP server. 167 ERX - EAP re-authentication extensions. 169 ERP - EAP re-authentication Protocol that uses the re- 170 authentication extensions. 172 rRK - re-authentication root Key, derived from the EMSK or DSRK. 174 rIK - re-authentication Integrity Key, derived from the rRK. 176 rMSK - re-authentication MSK. This is a per-authenticator key, 177 derived from the rRK. 179 keyName-NAI - ERP messages are integrity protected with the rIK or 180 the DS-rIK. The use of rIK or DS-rIK for integrity protection of 181 ERP messages is indicated by the EMSKname [3], the protocol, which 182 is ERP, and the realm, which indicates the domainname of the ER 183 server. The EMSKname is copied into the username part of the NAI. 185 Domain - Refers to a "key management domain" as defined in [3]. 186 For simplicity, it is referred to as "domain" in this document. 187 The terms "home domain" and "local domain" are used to 188 differentiate between the originating key management domain that 189 performs the full EAP exchange with the peer and the local domain 190 to which a peer may be attached to at a given time. 192 3. ERP Description 194 ERP allows a peer and server to mutually verify proof of possession 195 of keying material from an earlier EAP method run and establish a 196 security association between the peer and the authenticator. The 197 authenticator acts as a pass-through entity for the Re-authentication 198 protocol in a manner similar to that of an EAP authenticator 199 described in RFC 3748 [2]. ERP is a single round-trip exchange 200 between the peer and the server; it is independent of the lower layer 201 and the EAP method used during the full EAP exchange. The ER server 202 may be in the home domain or in the same (visited) domain as the peer 203 and the authenticator. 205 Figure 2 shows the protocol exchange. The first time the peer 206 attaches to any network, it performs a full EAP exchange (shown in 207 Figure 1) with the EAP server; as a result an MSK is distributed to 208 the EAP authenticator. The MSK is then used by the authenticator and 209 the peer to establish TSKs as needed. At the time of the initial EAP 210 exchange, the peer and the server also derive an EMSK, which is used 211 to derive a re-authentication Root Key (rRK). More precisely, a re- 212 authentication Root Key is derived from the EMSK or from a Domain 213 Specific Root Key (DSRK), which itself is derived from the EMSK. The 214 rRK is only available to the peer and the ER server and is never 215 handed out to any other entity. Further, a re-authentication 216 Integrity Key (rIK) is derived from the rRK; the peer and the ER 217 server use the rIK to provide proof of possession while performing an 218 ERP exchange. The rIK is also never handed out to any entity and is 219 only available to the peer and server. 221 When the ER server is in the home domain, the peer and the server use 222 the rIK and rRK derived from the EMSK and when the ER server is not 223 in the home domain, they use the DS-rIK and DS-rRK corresponding to 224 the local domain. The domain of the ER server is identified by the 225 realm portion of the keyname-NAI in ERP messages. 227 3.1. ERP With the Home ER Server 229 EAP Peer EAP Authenticator EAP Server 230 ======== ================= ========== 232 <--- EAP-Request/ ------ 233 Identity 235 ----- EAP Response/ ---> 236 Identity ---AAA(EAP Response/Identity)--> 238 <--- EAP Method -------> <------ AAA(EAP Method --------> 239 exchange exchange) 241 <----AAA(MSK, EAP-Success)------ 243 <---EAP-Success--------- 245 Figure 1: EAP Authentication 247 Peer Authenticator Server 248 ==== ============= ====== 250 [<-- EAP-Initiate/ ----- 251 Re-auth-Start] 252 [<-- EAP-Request/ ------ 253 Identity] 255 ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> 256 Re-auth/ Re-auth/ 257 [Bootstrap] [Bootstrap]) 259 <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- 260 Re-auth/ Re-auth/ 261 [Bootstrap] [Bootstrap]) 263 Note: [] brackets indicate optionality. 265 Figure 2: ERP Exchange 267 Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this 268 document for the purpose of EAP re-authentication. When the peer 269 identifies a target authenticator that supports EAP re- 270 authentication, it performs an ERP exchange, as shown in Figure 2; 271 the exchange itself may happen when the peer attaches to a new 272 authenticator supporting EAP re-authentication, or prior to 273 attachment. The peer initiates ERP by itself; it may also do so in 274 response to an EAP-Initiate/Re-auth-Start message from the new 275 authenticator. The EAP-Initiate/Re-auth-Start message allows the 276 authenticator to trigger the ERP exchange. 278 It is plausible that the authenticator does not know whether the peer 279 supports ERP and whether the peer has performed a full EAP 280 authentication through another authenticator. The authenticator MAY 281 initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start 282 message, and if there is no response, sends the EAP-Request/Identity 283 message. Note that this avoids having two EAP messages in flight at 284 the same time [2]. The authenticator may send the EAP-Initiate/ 285 Re-auth-Start message and wait for a short, locally configured, 286 amount of time. If the peer does not already know, this message 287 indicates to the peer that the authenticator supports ERP. In 288 response to this trigger from the authenticator, the peer can 289 initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. 290 If there is no response from the peer after the necessary 291 retransmissions (see Section 6), the authenticator MUST initiate EAP 292 by sending EAP-Request message, typically EAP-Request/Identity 293 message. Note that the authenticator may receive an EAP-Initiate/ 294 Re-auth message after it has sent an EAP-Request/Identity message. 295 If the authenticator supports ERP, it MUST proceed with the ERP 296 exchange. When the EAP-Request/Identity times out, the authenticator 297 MUST NOT close connection if an ERP exchange is in progress or has 298 already succeeded in establishing a reauthentication MSK. 300 If the authenticator does not support ERP, it drops EAP-Initiate/ 301 Re-auth messages [2] as the EAP code of those packets is greater than 302 4. ERP capable peer will exhaust EAP-Initiate/Re-auth message 303 retransmissions and fall back to EAP authentication by responding to 304 EAP Request/Identity messages from the authenticator. If the peer 305 does not support ERP or if it does not have unexpired key material 306 from a previous EAP authentication, it drops EAP-Initiate/ 307 Re-auth-Start messages. If there is no response to EAP-Initiate/ 308 Re-auth-Start message, the authenticator SHALL send EAP Request 309 (typically EAP Request/Identity) message to start EAP authentication. 310 From this stage onwards, RFC 3748 rules apply. Note that this may 311 introduce some delay in starting EAP. In some lower layers, the 312 delay can be minimized or even avoided by the peer initiating EAP by 313 sending messages such as EAPoL-Start in the IEEE 802.1X specification 314 [10]. 316 The peer sends an EAP-Initiate/Re-auth message that contains the 317 keyName-NAI to identify the ER server's domain and the rIK used to 318 protect the message, and a sequence number for replay protection. 319 The EAP-Initiate/Re-auth message is integrity protected with the rIK. 320 The authenticator uses the realm in the keyName-NAI [4] field to send 321 the message to the appropriate ER server. The server uses the 322 keyName to lookup the rIK. The server, after verifying proof of 323 possession of the rIK, and freshness of the message, derives a re- 324 authentication MSK (rMSK) from the rRK using the sequence number as 325 an input to the key derivation. The server updates the expected 326 sequence number to the received sequence number plus one. 328 In response to the EAP-Initiate/Re-auth message, the server sends an 329 EAP-Finish/Re-auth message; this message is integrity protected with 330 the rIK. The server transports the rMSK along with this message to 331 the authenticator. The rMSK is transported in a manner similar to 332 that of the MSK along with the EAP-Success message in a full EAP 333 exchange. Ongoing work in [11] describes an additional key 334 distribution protocol that can be used to transport the rRK from an 335 EAP server to one of many different ER servers that share a trust 336 relationship with the EAP server. 338 The peer MAY request the server for the rMSK lifetime. If so, the ER 339 server sends the rMSK lifetime in the EAP-Finish/Re-auth message. 341 In an ERP bootstrap exchange, the peer MAY request the server for the 342 rRK lifetime. If so, the ER server sends the rRK lifetime in the 343 EAP-Finish/Re-auth message. 345 The peer verifies the replay protection and the integrity of the 346 message. It then uses the sequence number in the EAP-Finish/Re-auth 347 message to compute the rMSK. The lower-layer security association 348 protocol is ready to be triggered after this point. 350 3.2. ERP with a Local ER Server 352 The defined ER extensions allow executing the ERP with an ER server 353 in the local domain (access network). The local ER server may be co- 354 located with a local AAA server. The peer may learn about the 355 presence of a local ER server in the network and the local domain (or 356 ER server) name either via the lower layer or by means of ERP 357 bootstrapping. The peer uses the domain name and the EMSK to compute 358 the DSRK and from that key, the DS-rRK; the peer also uses the domain 359 name in the realm portion of the keyName-NAI for using ERP in the 360 local domain. Figure 3 shows the full EAP and subsequent local ERP 361 exchange Figure 4 with a local ER server. 363 Peer EAP Authenticator Local ER Server Home EAP Server 364 ==== ================= =============== =============== 366 <-- EAP-Request/ -- 367 Identity 369 -- EAP Response/--> 370 Identity --AAA(EAP Response/--> 371 Identity) --AAA(EAP Response/ --> 372 Identity, 373 [DSRK Request, 374 domain name]) 376 <------------------------ EAP Method exchange------------------> 378 <---AAA(MSK, DSRK, ---- 379 EMSKname, 380 EAP-Success) 382 <--- AAA(MSK, ----- 383 EAP-Success) 385 <---EAP-Success----- 387 Figure 3: Local ERP Exchange, Initial EAP Exchange 389 Peer ER Authenticator Local ER Server 390 ==== ================ =============== 392 [<-- EAP-Initiate/ -------- 393 Re-auth-Start] 394 [<-- EAP-Request/ --------- 395 Identity] 397 ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> 398 Re-auth Re-auth) 400 <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- 401 Re-auth Re-auth) 402 Figure 4: Local ERP Exchange 404 As shown in Figure 4, the local ER server may be present in the path 405 of the full EAP exchange (e.g., this may be one of the AAA entities, 406 such as AAA proxies, in the path between the authenticator and the 407 home EAP server of the peer). In that case, the ER server requests 408 the DSRK by sending the domain name to the EAP server. In response, 409 the EAP server computes the DSRK by following the procedure specified 410 in [3] and sends the DSRK and the key name, EMSKname, to the ER 411 server in the claimed domain. The local domain is responsible for 412 announcing that same domain name via the lower layer to the peer. 414 If the peer does not know the domain name (did not receive the domain 415 name via the lower layer announcement, due to a missed announcement 416 or lack of support for domain name announcements in a specific lower 417 layer), it SHOULD initiate ERP bootstrap exchange with the home ER 418 server to obtain the domain name. The local ER server SHALL request 419 the home AAA server for the DSRK by sending the domain name in the 420 AAA message that carries the EAP-Initiate/Reauth bootstrap message. 421 The local ER server MUST be in the path from the peer to the home ER 422 server. If it is not, it cannot request the DSRK. 424 After receiving the DSRK and the EMSKname, the local ER server 425 computes the DS-rRK and the DS-rIK from the DSRK as defined in 426 Section 4.1 and Section 4.3 below. After receiving the domain name, 427 the peer also derives the DSRK, the DS-rRK and the DS-rIK. These 428 keys are referred to by a keyName-NAI formed as follows: the username 429 part of the NAI is the EMSKname, the realm portion of the NAI is the 430 domain name. Both parties also maintain a sequence number 431 (initialized to zero) corresponding to the specific keyName-NAI. 433 Subsequently, when the peer attaches to an authenticator within the 434 local domain, it may perform an ERP exchange with the local ER server 435 to obtain an rMSK for the new authenticator. 437 4. ER Key Hierarchy 439 Each time the peer re-authenticates to the network, the peer and the 440 authenticator establish an rMSK. The rMSK serves the same purposes 441 that an MSK, which is the result of full EAP authentication, serves. 442 To prove possession of the rRK, we specify the derivation of another 443 key, the rIK. These keys are derived from the rRK. Together they 444 constitute the ER key hierarchy. 446 The rRK is derived from either the EMSK or a DSRK as specified in 447 Section 4.1. For the purpose of rRK derivation, this document 448 specifies derivation of a Usage Specific Root Key (USRK) or a Domain 449 Specific USRK (DS-USRK) in accordance with [3] for re-authentication. 450 The USRK designated for re-authentication is the re-authentication 451 root key (rRK). A DS-USRK designated for re-authentication is the 452 DS-rRK available to a local ER server in a particular domain. For 453 simplicity, the keys are referred to without the DS label in the rest 454 of the document. However, the scope of the various keys is limited 455 to just the respective domains they are derived for, in the case of 456 the domain specific keys. Based on the ER server with which the peer 457 performs the ERP exchange, it knows the corresponding keys that must 458 be used. 460 The rRK is used to derive a rIK, and rMSKs for one or more 461 authenticators. The figure below shows the key hierarchy with the 462 rRK, rIK and rMSKs. 464 rRK 465 | 466 +--------+--------+ 467 | | | 468 rIK rMSK1 ...rMSKn 470 Figure 5: Re-authentication Key Hierarchy 472 The derivations in this document are according to [3]. Key 473 derivations, field encodings, where unspecified, default to that 474 document. 476 4.1. rRK Derivation 478 The rRK may be derived from the EMSK or DSRK. This section provides 479 the relevant key derivations for that purpose. 481 The rRK is derived as specified in [3]. 483 rRK = KDF (K, S), where, 485 K = EMSK or K = DSRK and 487 S = rRK Label | "\0" | length 489 The rRK Label is an IANA-assigned 8-bit ASCII string: 491 EAP Re-authentication Root Key@ietf.org 493 assigned from the "USRK key labels" name space in accordance with 494 [3]. 496 The KDF and algorithm agility for the KDF is as defined in [3]. 498 An rRK derived from the DSRK is referred to as a DS-rRK in the rest 499 of the document. All the key derivation and properties specified in 500 this section remain the same. 502 4.2. rRK Properties 504 The rRK has the following properties. These properties apply to the 505 rRK regardless of the parent key used to derive it. 507 o The length of the rRK MUST be equal to the length of the parent 508 key used to derive it. 510 o The rRK is to be used only as a root key for re-authentication and 511 never used to directly protect any data. 513 o The rRK is only used for derivation of rIK and rMSK as specified 514 in this document. 516 o The rRK MUST remain on the peer and the server that derived it and 517 MUST NOT be transported to any other entity. 519 o The lifetime of the rRK is never greater than that of its parent 520 key. The rRK is expired when the parent key expires and MUST be 521 removed from use at that time. 523 4.3. rIK Derivation 525 The re-authentication Integrity Key (rIK) is used for integrity 526 protecting the ERP exchange. This serves as the proof of possession 527 of valid keying material from a previous full EAP exchange by the 528 peer to the server. 530 The rIK is derived as follows. 532 rIK = KDF (K, S ) where, 534 K = rRK and 536 S = rIK Label | "\0" | cryptosuite | length 538 The rIK Label is the 8-bit ASCII string: 540 Re-authentication Integrity Key@ietf.org 542 The length field refers to the length of the rIK in octets encoded as 543 specified in [3]. 545 The cryptosuite and length of the rIK are part of the input to the 546 key derivation function to ensure cryptographic separation of keys if 547 different rIKs of different lengths for use with different MAC 548 algorithms are derived from the same rRK. The cryptosuite is encoded 549 as an 8-bit number: See Section 5.3.2 for cryptosuite specification. 551 The rIK is referred to by EMSKname-NAI within the context of ERP 552 messages. The username part of EMSKname-NAI is the EMSKname; the 553 realm is the domain name of the ER server. In case of ERP with the 554 home ER server, the peer uses the realm from its original NAI; in 555 case of a local ER server, the peer uses the domain name received at 556 the lower layer or through a ERP bootstrapping exchange. 558 An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest 559 of the document. All the key derivation and properties specified in 560 this section remain the same. 562 4.4. rIK Properties 564 The rIK has the following properties. 566 o The length of the rIK MUST be equal to the length of the rRK. 568 o The rIK is only used for authentication of the ERP exchange as 569 specified in this document. 571 o The rIK MUST NOT be used to derive any other keys. 573 o The rIK must remain on the peer and the server and MUST NOT be 574 transported to any other entity. 576 o The rIK is cryptographically separate from any other keys derived 577 from the rRK. 579 o The lifetime of the rIK is never greater than that of its parent 580 key. The rIK MUST be expired when the EMSK expires and MUST be 581 removed from use at that time. 583 4.5. rIK Usage 585 The rIK is the key whose possession is demonstrated by the peer and 586 the ERP server to the other party. The peer demonstrates possession 587 of the rIK by computing the integrity checksum over the EAP-Initiate/ 588 Re-auth message. When the peer uses the rIK for the first time, it 589 can choose the integrity algorithm to use with the rIK. The peer and 590 the server MUST use the same integrity algorithm with a given rIK for 591 all ERP messages protected with that key. The peer and the server 592 store the algorithm information after the first use and the same 593 algorithm for all subsequent uses of that rIK. 595 If the server's policy does not allow the use of the cryptosuite 596 selected by the peer, the server SHALL reject the EAP-Initiate/ 597 Re-auth message and SHOULD send a list of acceptable cryptosuites in 598 the EAP-Finish/Re-auth message. 600 The rIK length may be different from the key length required by an 601 integrity algorithm. In case of hash-based MAC algorithms, the key 602 is first hashed to the required key length as specified in [5]. In 603 case of cipher-based MAC algorithms, if the required key length is 604 less than 32 octets, the rIK is hashed using HMAC-SHA256 and the 605 first k octets of the output are used where k is the key length 606 required by the algorithm. If the required key length is more than 607 32 octets, the first k octets of the rIK are used by the cipher-based 608 MAC algorithm. 610 4.6. rMSK Derivation 612 The rMSK is derived at the peer and server and delivered to the 613 authenticator. The rMSK is derived following an EAP Re-auth protocol 614 exchange. 616 The rMSK is derived as follows. 618 rMSK = KDF (K, S ) where, 620 K = rRK and 622 S = rMSK label | "\0" | SEQ | length 624 The rMSK label is the 8-bit ASCII string: 626 Re-authentication Master Session Key@ietf.org 628 The length field refers to the length of the rMSK in octets. The 629 length field is encoded as specified in [3]. 631 SEQ is the sequence number sent by the peer in the EAP-Initiate/ 632 Re-auth message. This field is encoded as a 16-bit number in the 633 network byte order (see Section 5.3.2). 635 An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest 636 of the document. All the key derivation and properties specified in 637 this section remain the same. 639 4.7. rMSK Properties 641 The rMSK has the following properties: 643 o The length of the rMSK MUST be equal to the length of the rRK. 645 o The rMSK is delivered to the authenticator and is used for the 646 same purposes that an MSK is used at an authenticator. 648 o The rMSK is cryptographically separate from any other keys derived 649 from the rRK. 651 o The lifetime of the rMSK is less than or equal to that of the rRK. 652 It MUST NOT be greater than the lifetime of the rRK. 654 o If a new rRK is derived, subsequent rMSKs MUST be derived from the 655 new rRK. Previously delivered rMSKs MAY still be used until the 656 expiry of the lifetime. 658 o A given rMSK MUST NOT be shared by multiple authenticators. 660 5. Protocol Details 662 5.1. ERP Bootstrapping 664 We identify two types of bootstrapping for ERP: explicit and implicit 665 bootstrapping. In implicit bootstrapping, the local ER server SHOULD 666 include its domain name and request the DSRK from the home AAA server 667 during the initial EAP exchange, in the AAA message encapsulating the 668 first EAP Response message sent by the peer. If the EAP exchange is 669 successful, the server sends the DSRK for the local ER server 670 (derived using the EMSK and the domain name as specified in [3]), 671 EMSKname and DSRK lifetime along with the EAP-Success message. The 672 local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime if 673 present, before forwarding the EAP-Success message to the peer, as 674 specified in [12]. Note that the MSK (also present along with the 675 EAP Success message) is extracted by the EAP authenticator as usual. 676 The peer learns the domain name through EAP-Initiate/Re-auth-Start 677 message or via lower layer announcements. When the domain name is 678 available to the peer during or after the full EAP authentication, it 679 attempts to use ERP when it associates with a new authenticator. 681 If the peer does not know the domain name (did not receive the domain 682 name via the lower layer announcement, due to a missed announcement 683 or lack of support for domain name announcements in a specific lower 684 layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with 685 the bootstrap flag turned on) with the home ER server to obtain the 686 domain name. The local ER server behavior is the same as described 687 above. The peer MAY also initiate bootstrapping to fetch information 688 such as the rRK lifetime from the AAA server. 690 The following steps describe the ERP explicit bootstrapping process: 692 o The peer sends the EAP-Initiate/Re-auth message with the 693 bootstrapping flag turned on. The bootstrap message is always 694 sent to the home AAA server and the keyname-NAI attribute in the 695 bootstrap message is constructed as follows: the username portion 696 of the NAI contains the EMSKname and the realm portion contains 697 the home domain name. 699 o In addition, the message MUST contain a sequence number for replay 700 protection, a cryptosuite, and an integrity checksum. The 701 cryptosuite indicates the authentication algorithm. The integrity 702 checksum indicates that the message originated at the claimed 703 entity, the peer indicated by the Peer-ID, or the rIKname. 705 o The peer MAY additionally set the lifetime flag to request the key 706 lifetimes. 708 o When an ERP-capable authenticator receives EAP-Initiate/Re-auth 709 message from a peer, it copies the contents of the keyName-NAI 710 into the User-Name attribute of RADIUS [13]. The rest of the 711 process is similar to that described in [14] and described in 712 [12]. 714 o If a local ER server is present, the local ER server MUST include 715 the DSRK request and its domain name in the AAA message 716 encapsulating the EAP-Initiate/Re-auth message sent by the peer. 718 o Upon receipt of an EAP-Initiate/Re-auth message, the server 719 verifies whether the message is fresh or a replay by evaluating 720 whether the received sequence number is equal to or greater than 721 the expected sequence number for that rIK. The server then 722 verifies to ensure that the cryptosuite used by the peer is 723 acceptable. Next, it verifies the origin authentication of the 724 message by looking up the rIK. If any of the checks fail, the 725 server sends an EAP-Finish/Re-auth message with the Result flag 726 set to '1'. Please refer to Section 5.2.2 for details on failure 727 handling. This error MUST NOT have any correlation to any EAP- 728 Success message that may have been received by the EAP 729 authenticator and the peer earlier. If the EAP-Initiate/Re-auth 730 message is well-formed and valid, the server prepares the EAP- 731 Finish/Re-auth message. The bootstrap flag MUST be set to 732 indicate that this is a bootstrapping exchange. The message 733 contains the following fields: 735 * A sequence number for replay protection. 737 * The same keyName-NAI as in the EAP-Initiate/Re-auth message. 739 * If the lifetime flag was set in the EAP-Initiate/Re-auth 740 message, the ER server SHOULD include the rRK lifetime and the 741 rMSK lifetime in the EAP-Finish/Re-auth message. The server 742 may have a local policy for the network to maintain and enforce 743 lifetime unilaterally. In such cases, the server need not 744 respond to the peer's request for the lifetime. 746 * If the bootstrap flag is set and a DSRK request is received, 747 the server MUST include the domain name to which the DSRK is 748 being sent. 750 * If the home ER server verifies the authorization of a local 751 domain server, it MAY include the Authorization Indication TLV 752 to indicate to the peer that the server that received the DSRK 753 and advertising the domain included in the domain name TLV is 754 authorized. 756 * An authentication tag MUST be included to prove that the EAP- 757 Finish/Re-auth message originates at a server that possesses 758 the rIK corresponding to the EMSKname-NAI. 760 o If the ERP exchange is successful, and the local ER server sent a 761 DSRK request, the home ER server MUST include the DSRK for the 762 local ER server (derived using the EMSK and the domain name as 763 specified in [3]), EMSKname and DSRK lifetime along with the EAP- 764 Finish/Re-auth message. 766 o In addition, the rMSK is sent along with the EAP-Finish/Re-auth 767 message, in a AAA attribute [12]. 769 o The local ER server MUST extract the DSRK, EMSKname, and DSRK 770 lifetime if present, before forwarding the EAP-Finish/Re-auth 771 message to the peer, as specified in [12]. 773 o The authenticator receives the rMSK. 775 o When the peer receives an EAP-Finish/Re-auth message with the 776 bootstrap flag set, if a local domain name is present, it MUST use 777 that to derive the appropriate DSRK, DS-rRK, DS-rIK and keyName- 778 NAI, and initialize the replay counter for the DS-rIK. If not, 779 the peer SHOULD derive the domain-specific keys using the domain 780 name it learned via the lower layer or from the EAP-Initiate/ 781 Re-auth-Start message. If the peer does not know the domain name, 782 it must assume that there is no local ER server available. 784 o The peer MAY also verify the Authorization Indication TLV. 786 o The procedures for encapsulating ERP and obtaining relevant keys 787 using RADIUS and Diameter are specified in [12] and [15] 788 respectively. 790 Since the ER bootstrapping exchange is typically done immediately 791 following the full EAP exchange, it is feasible that the process is 792 completed through the same entity that served as the EAP 793 authenticator for the full EAP exchange. In this case, the lower 794 layer may already have established TSKs based on the MSK received 795 earlier. The lower layer may then choose to ignore the rMSK that was 796 received with the ER bootstrapping exchange. Alternatively, the 797 lower layer may choose to establish a new TSK using the rMSK. In 798 either case, the authenticator and the peer know which key is used 799 based on the initiation or lack there of a TSK establishment 800 exchange. The bootstrapping exchange may also be carried out via a 801 new authenticator, in which case, the rMSK received SHOULD trigger a 802 lower layer TSK establishment exchange. 804 5.2. Steps in ERP 806 When a peer that has an active rRK and rIK associates with a new 807 authenticator that supports ERP, it may perform an ERP exchange with 808 that authenticator. ERP is typically a peer-initiated exchange, 809 consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth 810 message. The ERP exchange may be performed with a local ER server 811 (when one is present) or with the original EAP server. 813 It is plausible for the network to trigger the EAP re-authentication 814 process however. An ERP-capable authenticator SHOULD send an EAP- 815 Initiate/Re-auth-Start message to indicate support for ERP. The peer 816 may or may not wait for these messages to arrive to initiate the EAP- 817 Initiate/Re-auth message. 819 The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- 820 capable authenticator. The authenticator may retransmit it a few 821 times until it receives an EAP-Initiate/Re-auth message in response 822 from the peer. The EAP-Initiate/Re-auth message from the peer may 823 have originated before the peer receives either an EAP-Request/ 824 Identity or an EAP-Initiate/Re-auth-Start message from the 825 authenticator. Hence the Identifier value in the EAP-Initiate/ 826 Re-auth message is independent of the Identifier value in the EAP- 827 Initiate/Re-auth-Start or the EAP-Request/Identity messages. 829 Operational Considerations at the Peer: 831 ERP requires that the peer maintain retransmission timers for 832 reliable transport of EAP re-authentication messages. The 833 reliability considerations of Section 4.3 of RFC 3748 apply with the 834 peer as the retransmitting entity. 836 The EAP Re-auth protocol has the following steps: 838 The peer sends an EAP-Initiate/Re-auth message. At a minimum, the 839 message SHALL include the following fields: 841 a 16-bit sequence number for replay protection 843 keyName-NAI as a TLV attribute to identify the rIK used to 844 integrity protect the message. 846 cryptosuite to indicate the authentication algorithm used to 847 compute the integrity checksum. 849 authentication tag over the message. 851 When the peer is performing ERP with a local ER server, it MUST 852 use the corresponding DS-rIK it shares with the local ER server. 853 The peer SHOULD set the lifetime flag to request the key lifetimes 854 from the server. The peer can use the rRK lifetime to know when 855 to trigger an EAP method exchange and the rMSK lifetime to know 856 when to trigger another ERP exchange. 858 The authenticator copies the contents of the value field of the 859 keyName-NAI TLV into the User-Name RADIUS attribute in the AAA 860 message to the ER server. 862 The server uses the keyName-NAI to lookup the rIK. It MUST first 863 verify whether the sequence number is equal to or greater than the 864 expected sequence number. If the server supports sequence number 865 window size greater than 1, it MUST verify whether the sequence 866 number falls within the window and has not been received before. 867 The server MUST then verify to ensure that the cryptosuite used by 868 the peer is acceptable. The server then proceeds to verify the 869 integrity of the message using the rIK, thereby verifying proof of 870 possession of that key by the peer. If any of these verifications 871 fail, the server MUST send an EAP-Finish/Re-auth message with the 872 Result flag set to '1' (Failure). Please refer to Section 5.2.2 873 for details on failure handling. Otherwise, it MUST compute an 874 rMSK from the rRK using the sequence number as the additional 875 input to the key derivation. 877 In response to a well-formed EAP Re-auth/Initiate message, the 878 server MUST send an EAP-Finish/Re-auth message with the following 879 considerations: 881 a 16-bit sequence number for replay protection, which MUST be 882 same as the received sequence number. The local copy of the 883 sequence number MUST be incremented by 1. If the server 884 supports multiple simultaneous ERP exchanges, it MUST instead 885 update the sequence number window. 887 keyName-NAI as a TLV attribute to identify the rIK used to 888 integrity protect the message. 890 cryptosuite to indicate the authentication algorithm used to 891 compute the integrity checksum. 893 authentication tag over the message. 895 If the lifetime flag was set in the EAP-Initiate/Re-auth 896 message, the ER server SHOULD include the rRK lifetime and the 897 rMSK lifetime. 899 The server transports the rMSK along with this message to the 900 authenticator. The rMSK is transported in a manner similar to the 901 MSK transport along with the EAP-Success message in a regular EAP 902 exchange. 904 The peer looks up the sequence number to verify whether it is 905 expecting an EAP-Finish/Re-auth message with that sequence number 906 protected by the keyName-NAI. It then verifies the integrity of 907 the message. If the verifications fail, the peer logs an error 908 and stops the process; otherwise, it proceeds to the next step. 910 The peer uses the sequence number to compute the rMSK. 912 The lower-layer security association protocol can be triggered at 913 this point. 915 5.2.1. Multiple Simultaneous Runs of ERP 917 When a peer is within the range of multiple authenticators, it may 918 choose to run ERP via all of them simultaneously to the same ER 919 server. In that case, it is plausible that the ERP messages may 920 arrive out of order, resulting in the ER server rejecting legitimate 921 EAP-Initiate/Re-auth messages. 923 To facilitate such operation, an ER server MAY allow multiple 924 simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth 925 messages with SEQ number values within a window of allowed values. 926 Recall that the SEQ number allows replay protection. Replay window 927 maintenance mechanisms are a local matter. 929 5.2.2. ERP Failure Handling 931 If the processing of the EAP-Initiate/Re-auth message results in a 932 failure, the ER server MUST send an EAP-Finish Re-auth message with 933 the Result flag set to '1'. If the server has a valid rIK for the 934 peer, it MUST integrity protect the EAP-Finish/Re-auth failure 935 message. If the failure is due to an unacceptable cryptosuite, the 936 server SHOULD send a list of acceptable cryptosuites (in a TLV of 937 Type 5) along with the EAP-Finish/Re-auth message. In this case, the 938 server MUST indicate the cryptosuite used to protect the EAP-Finish/ 939 Re-auth message in the cryptosuite. The rIK used with the EAP- 940 Finish/Re-auth message in this case MUST be computed as specified in 941 Section 4.3 using the new cryptosuite. If the server does not have a 942 valid rIK for the peer, the EAP-Finish/Re-auth message indicating a 943 failure will be unauthenticated; the server MAY include a list of 944 acceptable cryptosuites in the message. 946 The peer, upon receiving an EAP-Finish/Re-auth message with the 947 Result flag set to '1', MUST verify the sequence number and the 948 Authentication Tag to determine the validity of the message. If the 949 peer supports the cryptosuite, it MUST verify the integrity of the 950 received EAP-Finish/Re-auth message. If the EAP-Finish message 951 contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with 952 a cryptosuite picked from the list included by the server. The peer 953 MUST use the appropriate rIK for the subsequent ERP exchange, by 954 computing it with the corresponding cryptosuite, as specified in 955 Section 4.3. If the PRF in the chosen cryptosuite is different from 956 the PRF originally used by the peer, it MUST derive a new DSRK (if 957 required), rRK and rIK before proceeding with the subsequent ERP 958 exchange. 960 If the peer cannot verify the integrity of the received message, it 961 MAY choose to retry the ERP exchange with one of the cryptosuites in 962 the TLV of Type 5, after a failure has been clearly determined 963 following the procedure in the next paragraph. 965 If the replay or integrity checks fail, the failure message may have 966 been sent by an attacker. It may also imply that the server and peer 967 do not support the same cryptosuites; however, the peer cannot 968 determine if that is the case. Hence, the peer SHOULD continue the 969 ERP exchange per the retransmission timers before declaring a 970 failure. 972 When the peer runs explicit bootstrapping (ERP with the bootstrapping 973 flag on), there may not be a local ER server available to send a DSRK 974 Request and the domain name. In that case, the server cannot send 975 the DSRK and MUST NOT include the domain-name TLV. When the peer 976 receives a response in the bootstrapping exchange without a domain- 977 name TLV it assumes that there is no local ER server. The home ER 978 server sends an rMSK to the ER authenticator however and the peer 979 SHALL run the TSK establishment protocol as usual. 981 5.3. New EAP Packets 983 Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate 984 and EAP-Finish. The packet format for these messages follows the EAP 985 packet format defined in RFC3748 [2]. 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Code | Identifier | Length | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Type | Type-Data ... 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 995 Figure 6: EAP Packet 997 Code 999 5 Initiate 1001 6 Finish 1003 Two new code values are defined for the purpose of ERP. 1005 Identifier 1007 The Identifier field is one octet. The Identifier field MUST 1008 be the same if an EAP-Initiate packet is retransmitted due to a 1009 timeout while waiting for a Finish message. Any new (non- 1010 retransmission) Initiate message MUST use a new Identifier 1011 field. 1013 The Identifier field of the Finish message MUST match that of 1014 the currently outstanding Initiate message. A Peer or 1015 Authenticator receiving a Finish message whose Identifier value 1016 does not match that of the currently outstanding Initiate 1017 message MUST silently discard the packet. 1019 In order to avoid confusion between new EAP-Initiate messages 1020 and retransmissions, the peer must choose a an Identifier value 1021 that is different from the previous EAP-Initiate message, 1022 especially if that exchange has not finished. It is 1023 RECOMMENDED that the authenticator clear EAP Re-auth state 1024 after 300 seconds. 1026 Type 1028 This field indicates that this is an ERP exchange. Two type 1029 values are defined in this document for this purpose - Re-auth- 1030 Start (assigned Type 1), Re-auth (assigned Type 2). 1032 Type-Data 1034 The Type-Data field varies with the Type of re-authentication 1035 packet. 1037 5.3.1. EAP-Initiate/Re-auth-Start Packet 1039 The EAP-Initiate/Re-auth-Start packet contains the parameters shown 1040 in Figure 7 : 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Code | Identifier | Length | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Type | Reserved | 1 or more TVs or TLVs ~ 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Figure 7: EAP-Initiate/Re-auth-Start Packet 1052 Type = 1. 1054 Reserved, MUST be zero. Set to zero on transmission and ignored 1055 on reception. 1057 One or more TVs or TLVs are used to convey information to the 1058 peer; for instance the authenticator may send domain name to the 1059 peer. 1061 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1062 and a value with type-specific length. In the TLV payloads, there 1063 is a 1-octet type payload and a 1-octet length payload. The 1064 length field indicates the length of the value expressed in number 1065 of octets. 1067 Domain-Name: This is a TLV payload. The Type is 4. The domain 1068 name is to be used as the realm in an NAI [4]. Domain-Name 1069 attribute SHOULD be present in an EAP-Initiate/Re-auth-Start 1070 message. 1072 In addition channel binding information MAY be included: see 1073 Section 5.5 for additional discussion. See Figure 11 for 1074 parameter specification. 1076 5.3.1.1. Authenticator Operation 1078 The authenticator MAY send the EAP-Initiate/Re-auth-Start message to 1079 indicate support for ERP to the peer and to initiate ERP if the peer 1080 has already performed full EAP authentication and has unexpired key 1081 material. The authenticator SHOULD include the domain name TLV to 1082 allow the peer to learn it without lower-layer support or the ERP 1083 bootstrapping exchange. 1085 The authenticator MAY include channel binding information so that the 1086 peer can send the information to the server in the EAP-Initiate/ 1087 Re-auth message so that the server can verify whether the 1088 authenticator is claiming the same identity to both parties. 1090 The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start 1091 message a few times for reliable transport. 1093 5.3.1.2. Peer Operation 1095 The peer SHOULD send the EAP-Initiate/Re-auth message in response to 1096 the EAP-Initiate/Re-auth-Start message from the authenticator. If 1097 the peer does not recognize the Initiate code value, it silently 1098 discards the message. If the peer has already sent the EAP-Initiate/ 1099 Re-auth message to begin the ERP exchange, it silently discards the 1100 message. 1102 If the EAP-Initiate/Re-auth-Start message contains the domain name, 1103 and if the peer does not already have the domain information, the 1104 peer SHOULD use the domain name to compute the DSRK and use the 1105 corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start 1106 an ERP exchange with the local ER server. If the peer has already 1107 initiated ERP exchange with the home ER server, it MAY choose to not 1108 start an ERP exchange with the local ER server. 1110 5.3.2. EAP-Initiate/Re-auth Packet 1112 The EAP-Initiate/Re-auth packet contains the parameters shown in 1113 Figure 8 : 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Code | Identifier | Length | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Type |R|B|L| Reserved| SEQ | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | 1 or more TVs or TLVs ~ 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | cryptosuite | Authentication Tag ~ 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 8: EAP-Initiate/Re-auth Packet 1129 Type = 2. 1131 Flags 1133 'R' - The R flag is set to 0 and ignored upon reception. 1135 'B' - The B flag is used as the bootstrapping flag. If the 1136 flag is turned on, the message is a bootstrap message. 1138 'L' - The L flag is used to request the key lifetimes from the 1139 server. 1141 The rest of the 5 bits are set to 0 and ignored on reception. 1143 SEQ: A 16-bit sequence number is used for replay protection. The 1144 SEQ number field is initialized to zero every time a new rRK is 1145 derived. 1147 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1148 and a value with type-specific length. In the TLV payloads, there 1149 is a 1-octet type payload and a 1-octet length payload. The 1150 length field indicates the length of the value expressed in number 1151 of octets. 1153 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1154 The NAI is variable in length, not exceeding 253 octets. 1155 EMSKname is in the username part of the NAI and is encoded in 1156 hexadecimal values. The EMSKname is 64-bits in length and so 1157 the username portion takes up 128 octets. If the rIK is 1158 derived from the EMSK, the realm part of the NAI is the home 1159 domain name and if the rIK is derived from a DSRK, the realm 1160 part of the NAI is the domain name used in the derivation of 1161 the DSRK. The NAI syntax follows [4]. Exactly one keyName-NAI 1162 attribute SHALL be present in an EAP-Iniaite/Re-auth packet. 1164 In addition channel binding information MAY be included: see 1165 Section 5.5 for additional discussion. See Figure 11 for 1166 parameter specification. 1168 Cryptosuite: This field indicates the integrity algorithm used for 1169 ERP. Key lengths and output lengths are either indicated or are 1170 obvious from the cryptosuite name. We specify some cryptosuites 1171 below: 1173 * 0 RESERVED 1175 * 1 HMAC-SHA256-64 1177 * 2 HMAC-SHA256-128 1179 * 3 HMAC-SHA256-256 1181 HMAC-SHA256-128 is mandatory to implement and should be enabled in 1182 the default configuration. 1184 Authentication Tag: This field contains the integrity checksum 1185 over the ERP packet, excluding the authentication tag field 1186 itself. The length of the field is indicated by the Cryptosuite. 1188 5.3.3. EAP-Finish/Re-auth Packet 1190 The EAP-Finish/Re-auth packet contains the parameters shown in 1191 Figure 9 : 1193 0 1 2 3 1194 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 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Code | Identifier | Length | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Type |R|B|L| Reserved | SEQ ~ 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | 1 or more TVs or TLVs ~ 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | cryptosuite | Authentication Tag ~ 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 Figure 9: EAP-Finish/Re-auth Packet 1207 Type = 2. 1209 Flags 1211 'R' - The R flag is used as the Result flag - when set to 0, it 1212 indicates success and when set to '1', it indicates a failure. 1214 'B' - The B flag is used as the bootstrapping flag. If the 1215 flag is turned on, the message is a bootstrap message. 1217 'L' - The L flag is used to indicate the presence of the rRK 1218 lifetime TLV. 1220 The rest of the 5 bits are set to 0 and ignored on reception. 1222 SEQ: A 16-bit sequence number is used for replay protection. The 1223 SEQ number field is initialized to zero every time a new rRK is 1224 derived. 1226 TVs or TLVs: In the TV payloads, there is a 1-octet type payload 1227 and a value with type-specific length. In the TLV payloads, there 1228 is a 1-octet type payload and a 1-octet length payload. The 1229 length field indicates the length of the value expressed in number 1230 of octets. 1232 keyName-NAI: This is carried in a TLV payload. The Type is 1. 1233 The NAI is variable in length, not exceeding 253 octets. 1234 EMSKname is in the username part of the NAI and is encoded in 1235 hexadecimal values. The EMSKname is 64-bits in length and so 1236 the username portion takes up 16 octets. If the rIK is derived 1237 from the EMSK, the realm part of the NAI is the home domain 1238 name and if the rIK is derived from a DSRK, the realm part of 1239 the NAI is the domain name used in the derivation of the DSRK. 1240 The NAI syntax follows [4]. Exactly one instance of the 1241 keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth 1242 message. 1244 rRK Lifetime: This is a TV payload. The Type is 2. The value 1245 field is a 32-bit field and contains the lifetime of the rRK in 1246 seconds. If the 'L' flag is set, the rRK Lifetime attribute 1247 SHOULD be present. 1249 rMSK Lifetime: This is a TV payload. The Type is 3. The value 1250 field is a 32-bit field and contains the lifetime of the rMSK 1251 in seconds. If the 'L' flag is set, the rMSK Lifetime 1252 attribute SHOULD be present. 1254 Domain-Name: This is a TLV payload. The Type is 4. The domain 1255 name is to be used as the realm in an NAI [4]. Domain-Name 1256 attribute MUST be present in an EAP-Finish/Re-auth message if 1257 the bootstrapping flag is set and if the local ER server sent a 1258 DSRK request. 1260 List of cryptosuites: This is a TLV payload. The Type is 5. 1261 The value field contains a list of cryptosuites, each of size 1 1262 octet. The cryptosuite values are as specified in Figure 8. 1263 The server SHOULD include this attribute if the cryptosuite 1264 used in the EAP-Initiate/Re-auth message was not acceptable and 1265 the message is being rejected. The server MAY include this 1266 attribute in other cases. The server MAY use this attribute to 1267 signal to the peer about its cryptographic algorithm 1268 capabilities. 1270 Authorization Indication: This is a TLV payload. The Type is 1271 6. This attribute MAY be included in the EAP-Finish/Re-auth 1272 message when a DSRK is delivered to a local ER server and if 1273 the home ER server can verify the authorization of the local ER 1274 server to advertise the domain name included in the domain TLV 1275 in the same message. The value field in the TLV contains an 1276 authentication tag computed over the entire packet, starting 1277 from the first bit of the code field to the last bit of the 1278 crypto-suite field, with the value field of the Authorization 1279 Indication TLV filled with all 0s for the computation. The key 1280 used for the computation MUST be derived from the EMSK with key 1281 label "DSRK Delivery Authorized Key@ietf.org" and optional data 1282 containing an ASCII string representing the key management 1283 domain that the DSRK is being derived for. 1285 In addition channel binding information MAY be included: see 1286 Section 5.5 for additional discussion. See Figure 11 for 1287 parameter specification. The server sends this information so 1288 that the peer can verify the information seen at the lower 1289 layer, if channel binding is to be supported. 1291 Cryptosuite: This field indicates the integrity algorithm and the 1292 PRF used for ERP. Key lengths and output lengths are either 1293 indicated or are obvious from the cryptosuite name. 1295 Authentication Tag: This field contains the integrity checksum 1296 over the ERP packet, excluding the authentication tag field 1297 itself. The length of the field is indicated by the Cryptosuite. 1299 5.3.4. TV and TLV Attributes 1301 The TV attributes that may be present in the EAP-Initiate or EAP- 1302 Finish messages are of the following format: 1304 0 1 2 3 1305 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 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Type | Value ... 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 Figure 10: TV Attribute Format 1312 The TLV attributes that may be present in the EAP-Initiate or EAP- 1313 Finish messages are of the following format: 1315 0 1 2 3 1316 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 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Type | Length | Value ... 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 Figure 11: TLV Attribute Format 1323 The following Types are defined in this document: 1325 '1' - keyName-NAI: This is a TLV Payload 1327 '2' - rRK Lifetime: This is a TV payload 1329 '3' - rMSK Lifetime: This is a TV payload 1331 '4' - domain name: This is a TLV payload 1333 '5' - cryptosuite list: This is a TLV payload 1335 '6' - Authorization Indication: This is a TLV payload 1337 The TLV type range of 128-191 is reserved to carry channel binding 1338 information in the EAP-Initiate and Finish/Re-auth messages. 1339 Below are the current assignments (all of them are TLVs): 1341 '128' - Called-Station-Id [13] 1343 '129' - Calling-Station-Id [13] 1345 '130' - NAS-Identifier [13] 1347 '131' - NAS-IP-Address [13] 1349 '132' - NAS-IPv6-Address [16] 1351 The length field indicates the length of the value part of the 1352 attribute in octets. 1354 5.4. Replay Protection 1356 For replay protection, ERP uses sequence numbers. The sequence 1357 number is maintained per rIK and is initialized to zero in both 1358 directions. In the first EAP-Initiate/Re-auth message, the peer uses 1359 the sequence number zero or higher. Note that the when the sequence 1360 number rotates, the rIK MUST be changed by running EAP 1361 authentication. The server expects a sequence number of zero or 1362 higher. When the server receives an EAP-Initiate/Re-auth message, it 1363 uses the same sequence number in the EAP-Finish/Re-auth message. The 1364 server then sets the expected sequence number to the received 1365 sequence number plus 1. The server accepts sequence numbers greater 1366 than or equal to the expected sequence number. 1368 If the peer sends an EAP-Initiate/Re-auth message, but does not 1369 receive a response, it retransmits the request (with no changes to 1370 the message itself) a pre-configured number of times before giving 1371 up. However, it is plausible that the server itself may have 1372 responded to the message and it was lost in transit. Thus the peer 1373 MUST increment the sequence number and use the new sequence number to 1374 send subsequent EAP re-authentication messages. The peer SHOULD 1375 increment the sequence number by 1; however, it may choose to 1376 increment by a larger number. When the sequence number rotates, the 1377 peer MUST run full EAP authentication. 1379 5.5. Channel Binding 1381 ERP provides a protected facility to carry channel binding (CB) 1382 information, according to the guidelines in Section 7.15 of [2]. The 1383 TLV type range of 128-191 is reserved to carry CB information in the 1384 EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Called- 1385 Station-Id, Calling-Station-Id, NAS-Identifier, NAS-IP-Address, and 1386 NAS-IPv6-Address are some examples of channel binding information 1387 listed in RFC 3748 and they are assigned values 128-132. Additional 1388 values are IANA managed based on IETF Consensus [17]. 1390 The authenticator MAY provide CB information to the peer via the EAP- 1391 Initiate/Re-auth-Start message. The peer sends the information to 1392 the server in the EAP-Initiate/Re-auth message; the server verifies 1393 whether the authenticator identity available via AAA attributes is 1394 the same as the identity provided to the peer. 1396 If the peer does not include the CB information in the EAP-Initiate/ 1397 Re-auth message, and if the local ER server's policy requires channel 1398 binding support, it SHALL send the CB attributes for the peer's 1399 verification. The peer attempts to verify the CB information if the 1400 authenticator has sent the CB parameters and proceeds with the lower 1401 layer security association establishment if the attributes match. 1402 Otherwise, the peer SHALL NOT proceed with the lower layer security 1403 association establishment. 1405 6. Lower Layer Considerations 1407 The authenticator is responsible for retransmission of EAP-Initiate/ 1408 Re-auth-Start messages. The authenticator MAY retransmit the message 1409 a few times or until it receives an EAP-Initiate/Re-auth message from 1410 the peer. The authenticator may not know whether the peer supports 1411 ERP; in those cases, the peer may be silently dropping the EAP- 1412 Initiate/Re-auth-Start packets. Thus retransmission of these packets 1413 should be kept to a minimum. The exact number is up to each lower 1414 layer. 1416 The Identifier value in the EAP-Initiate/Re-auth packet is 1417 independent of the Identifier value in the EAP-Initiate/Re-auth-Start 1418 packet. 1420 The peer is responsible for retransmission of EAP-Initiate/Re-auth 1421 messages. 1423 Retransmitted packets MUST be sent with the same Identifier value in 1424 order to distinguish them from new packets. By default, where the 1425 EAP-Initiate message is sent over an unreliable lower layer, the 1426 retransmission timer SHOULD be dynamically estimated. A maximum of 1427 3-5 retransmissions is suggested (this is based on the recommendation 1428 of [2]). Where the EAP-Initiate message is sent over a reliable 1429 lower layer, the retransmission timer SHOULD be set to an infinite 1430 value, so that retransmissions do not occur at the EAP layer. Please 1431 refer to RFC3748 [2] for additional guidance on setting timers. 1433 The Identifier value in the EAP-Finish/Re-auth packet is the same as 1434 the Identifier value in the EAP-Initiate/Re-auth packet. 1436 If an authenticator receives a valid duplicate EAP-Initiate/Re-auth 1437 message for which it has already sent an EAP-Finish/Re-auth message, 1438 it MUST resend the EAP-Finish/Re-auth message without reprocessing 1439 the EAP-Initiate/Re-auth message. To facilitate this, the 1440 authenticator SHALL store a copy of the EAP-Finish/Re-auth message 1441 for a finite amount of time. The actual value of time is a local 1442 matter; this specification recommends a value of 100 milliseconds. 1444 The lower layer may provide facilities for exchanging information 1445 between the peer and the authenticator about support for ERP, for the 1446 authenticator to send the domain name information and channel binding 1447 information to the peer 1449 Note that to support ERP, lower layer specifications may need to be 1450 revised. Specifically, the IEEE802.1x specification must be revised 1451 to allow carrying EAP messages of the new codes defined in this 1452 document in order to support ERP. Similarly, RFC4306 must be updated 1453 to include EAP code values higher than 4 in order to use ERP with 1454 IKEv2. IKEv2 may also be updated to support peer-initiated ERP for 1455 optimized operation. Other lower layers may need similar revisions. 1457 Our analysis indicates that some EAP implementations are not RFC 3748 1458 compliant in that instead of silently dropping EAP packets with code 1459 values higher than 4, they may consider it an error. Furthermore, it 1460 may not be easy to upgrade all the peers in some cases. In such 1461 cases, authenticators may be configured to not send EAP-Initiate/ 1462 Re-auth-Start; peers may learn whether an authenticator supports ERP 1463 via configuration, from advertisements at the lower layer. 1465 In order to accommodate implementations that are not compliant to 1466 RFC3748, such lower layers need to ensure that both parties support 1467 ERP; this is trivial for an instance when using a lower layer that is 1468 known to always support ERP; otherwise, it can be negotiated. 1470 7. Transport of ERP Messages 1472 AAA Transport of ERP messages is specified in [11] and [12]. 1474 8. Security Considerations 1476 This section provides an analysis of the protocol in accordance with 1477 the AAA key management requirements specified in [18]. 1479 Cryptographic algorithm independence 1481 The EAP Re-auth protocol satisfies this requirement. The 1482 algorithm chosen by the peer for the MAC generation is 1483 indicated in the EAP-Initiate/Re-auth message. If the chosen 1484 algorithm is unacceptable, the EAP server returns an EAP- 1485 Finish/Re-auth message with Failure indication. Algorithm 1486 agility for the KDF is specified in [3]. Only when the 1487 algorithms used are acceptable, the server proceeds with 1488 derivation of keys and verification of the proof of possession 1489 of relevant keying material by the peer. A full blown 1490 negotiation of algorithms cannot be provided in a single round 1491 trip protocol. Hence, while the protocol provides algorithm 1492 agility, it does not provide true negotiation. 1494 Strong, fresh session keys 1496 ERP results in the derivation of strong, fresh keys that are 1497 unique for the given session. An rMSK is always derived on- 1498 demand when the peer requires a key with a new authenticator. 1499 The derivation ensures that the compromise of one rMSK does not 1500 result in the compromise of a different rMSK at any time. 1502 Limit key scope 1504 The scope of all the keys derived by ERP is well defined. The 1505 rRK and rIK are never shared with any entity and always remain 1506 on the peer and the server. The rMSK is provided only to the 1507 authenticator through which the peer performs the ERP exchange. 1508 No other authenticator is authorized to use that rMSK. 1510 Replay detection mechanism 1512 For replay protection of ERP messages, a sequence number 1513 associated with the rIK is used. The sequence number is 1514 maintained by the peer and the server, and initialized to zero 1515 when the rIK is generated. The peer increments the sequence 1516 number by one after it sends an ERP message. The server sets 1517 the expected sequence number to received sequence number plus 1518 one after verifying the validity of the received message and 1519 responds to the message. 1521 Authenticate all parties 1523 The EAP Re-auth protocol provides mutual authentication of the 1524 peer and the server. Both parties need to possess the keying 1525 material that resulted from a previous EAP exchange in order to 1526 successfully derive the required keys. Also, both the EAP re- 1527 authentication Response and the EAP re-authentication 1528 Information messages are integrity protected so that the peer 1529 and the server can verify each other. When the ERP exchange is 1530 executed with a local ER server, the peer and the local server 1531 mutually authenticate each other via that exchange in the same 1532 manner. The peer and the authenticator authenticate each other 1533 in the secure association protocol executed by the lower layer 1534 just as in the case of a regular EAP exchange. 1536 Peer and authenticator authorization 1538 The peer and authenticator demonstrate possession of the same 1539 key material without disclosing it, as part of the lower layer 1540 secure association protocol. Channel binding with ERP may be 1541 used to verify consistency of the identities exchanged, when 1542 the identities used in the lower layer differ from that 1543 exchanged within the AAA protocol. 1545 Keying material confidentiality 1547 The peer and the server derive the keys independently using 1548 parameters known to each entity. The AAA server sends the DSRK 1549 of a domain to the corresponding local ER server via the AAA 1550 protocol. Likewise, the ER server sends the rMSK to the 1551 authenticator via the AAA protocol. 1553 Note that compromise of the DSRK results in compromise of all 1554 keys derived from it. Moreover, there is no forward secrecy 1555 within ERP. Thus, compromise of an DSRK retroactively 1556 compromises all ERP keys. 1558 It is RECOMMENDED that the AAA protocol be protected using 1559 IPsec or TLS so that the keys are protected in transit. Note 1560 however that keys may be exposed to AAA proxies along the way 1561 and compromise of any of those proxies may result in compromise 1562 of keys being transported through them. 1564 The home ER server MUST NOT hand out a given DSRK to a local 1565 domain server more than once, unless it can verify that the 1566 entity receiving the DSRK after the first time is the same as 1567 that received the DSRK originally. If the home ER server 1568 verifies authorization of a local domain server, it MAY hand 1569 out the DSRK to that domain more than once. In this case, the 1570 home ER server includes the Authorization Indication TLV to 1571 assure the peer that DSRK delivery is secure. 1573 Confirm cryptosuite selection 1575 Crypto algorithms for integrity and key derivation in the 1576 context of ERP MAY be the same as that used by the EAP method. 1577 In that case, the EAP method is responsible for confirming the 1578 cryptosuite selection. Furthermore, the cryptosuite is 1579 included in the ERP exchange by the peer and confirmed by the 1580 server. The protocol allows the server to reject the 1581 cryptosuite selected by the peer and provide alternatives. 1582 When a suitable rIK is not available for the peer, the 1583 alternatives may be sent in an unprotected fashion. The peer 1584 is allowed to retry the exchange using one of the allowed 1585 cryptosuites. However, any enroute modifications of the list 1586 sent by the server in this case will go undetected. If the 1587 server does have an rIK available for the peer, the list will 1588 be provided in a protected manner and this issue does not 1589 apply. 1591 Uniquely named keys 1593 All keys produced within the ERP context can be referred to 1594 uniquely as specified in this document. Also, the key names do 1595 not reveal any part of the keying material. 1597 Prevent the domino effect 1599 The compromise of one peer does not result in the compromise of 1600 keying material held by any other peer in the system. Also, 1601 the rMSK is meant for a single authenticator and is not shared 1602 with any other authenticator. Hence, the compromise of one 1603 authenticator does not lead to the compromise of sessions or 1604 keys held by any other authenticator in the system. Hence, the 1605 EAP Re-auth protocol allows prevention of the domino effect by 1606 appropriately defining key scope. 1608 However, if keys are transported using hop-by-hop protection, 1609 compromise of a proxy may result in compromise of key material, 1610 DSRK, sent to a local ER server. 1612 Bind key to its context 1614 All the keys derived for ERP are bound to the appropriate 1615 context using appropriate key labels. Lifetime of a child key 1616 is less than or equal to that of its parent key as specified in 1617 RFC 4962 [18]. The key usage, lifetime and the parties that 1618 have access to the keys are specified. 1620 Confidentiality of identity 1622 Deployments where privacy is a concern may find the use of 1623 rIKname-NAI to route ERP messages serves their privacy 1624 requirements. Note that it is plausible to associate multiple 1625 runs of ERP messages since the rIKname is not changed as part 1626 of the ERP protocol. There was no consensus for that 1627 requirement at the time of development of this specification. 1628 If the rIKname is not used and the Peer-ID is used instead, the 1629 ERP exchange will reveal the Peer-ID over the wire. 1631 Authorization restriction 1633 All the keys derived are limited in lifetime by that of the 1634 parent key or by server policy. Any domain specific keys are 1635 further restricted for use only in the domain for which the 1636 keys are derived. All the keys specified in this document are 1637 meant for use in ERP only. Any other restrictions of session 1638 keys may be imposed by the specific lower layer and is out of 1639 scope for this specification. 1641 A denial of service attack on the peer may be possible when using the 1642 EAP Initiate/Re-auth message. An attacker may send a bogus EAP- 1643 Initiate/Re-auth message, which may be carried by the authenticator 1644 in a RADIUS-Access-Request to the server; in response to that the 1645 server may send an EAP-Finish/Re-auth with Failure indication in a 1646 RADIUS Access-Reject message. Note that such attacks may be 1647 plausible with the EAPoL-Start capability of IEEE 802.11 and other 1648 similar facilities in other link layers and where the peer can 1649 initiate EAP authentication; an attacker may use such messages to 1650 start an EAP method run, which fails and may result in the server 1651 sending a RADIUS Access-Reject message and thus resulting in the link 1652 layer connections being terminated. 1654 To prevent such DoS attacks, an ERP failure should not result in 1655 deletion of any authorization state established by a full EAP 1656 exchange. Alternatively, the lower layers and AAA protocols may 1657 define mechanisms to allow two link layer SAs derived from different 1658 EAP keying materials for the same peer to exist so that smooth 1659 migration from the current link layer SA to the new one is possible 1660 during rekey. These mechanisms prevent the link layer connections 1661 from being terminated when a re-authentication procedure fails due to 1662 the bogus EAP-Initiate/Re-auth message. 1664 When a DSRK is sent from a home ER server to a local domain server or 1665 when a rMSK is sent from an ER server to an authenticator, in the 1666 absence of end-to-end security between the entity that is sending the 1667 key and the entity receiving the key, it is plausible for other 1668 entities to get access to keys being sent to an ER server in another 1669 domain. This mode of key transport is similar to that of MSK 1670 transport in the context of EAP authentication. We further observe 1671 that ERP is for access authentication and does not support end-to-end 1672 data security. In typical implementations, the traffic is as such in 1673 the clear beyond the access control enforcement point, typically the 1674 authenticator or a delegate thereof. The model works as long as 1675 entities in the middle of the network do not use keys intended for 1676 other parties to steal service from an access network. If that is 1677 not achievable, key delivery must be protected in an end-to-end 1678 manner. 1680 9. IANA Considerations 1682 This document specifies IANA registration of two new 'Packet Codes' 1683 from the EAP registry: 1685 o 5 (Initiate) 1687 o 6 (Finish) 1689 These values are in accordance with [2]. 1691 This document also specifies creation of a new table, Message Types, 1692 in the EAP registry with the following assigned numbers: 1694 o 0 Reserved 1696 o 1 (Re-auth-Start, applies to Initiate Code only), 1698 o 2 (Re-auth, applies to Initiate and Finish Codes). 1700 o 3-191 IANA managed and assigned based on IETF Consensus [17], 1702 o 192-255 Experimental/Private use. 1704 . 1706 Next, we specify creation of a new table, EAP Initiate and Finish 1707 Attributes, associated with EAP Initiate and Finish messages in the 1708 EAP registry with the following assigned numbers. 1710 o 0: Reserved 1712 o keyName-NAI: This is a TLV payload. The Type is 1. 1714 o rRK Lifetime: This is a TV payload. The Type is 2. 1716 o rMSK Lifetime: This is a TV payload. The Type is 3. 1718 o Domain name: This is a TLV payload. The Type is 4. 1720 o Cryptosuite list: This is a TLV payload. The Type is 5. 1722 o Authorization Indication: This is a TLV payload. The Type is 6. 1724 o 7-127: Used to carry other non-channel binding related attributes. 1725 IANA managed and assigned based on IETF Consensus [17]. 1727 o The TLV type range of 128-191 is reserved to carry CB information 1728 in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. 1729 Below are the current assignments (all of them are TLVs): 1731 * Called-Station-Id: 128 1733 * Calling-Station-Id: 129 1735 * NAS-Identifier: 130 1737 * NAS-IP-Address: 131 1739 * NAS-IPv6-Address: 132 1741 133-191 Used to carry other channel binding related attributes. 1742 IANA managed and assigned based on IETF Consensus [17]. 1744 o 192-255 is reserved for Experimental/Private use. 1746 We specify creation of another registry 'Re-authentication 1747 Cryptosuites' with the following assigned numbers: 1749 o 0 Reserved 1751 o 1 HMAC-SHA256-64 1753 o 2 HMAC-SHA256-128 1755 o 3 HMAC-SHA256-256 1757 o 4-191 IANA managed and assigned based on IETF consensus [17] 1759 o 192-255 is reserved for Experimental/Private use. 1761 Further, this document registers a Re-auth usage label from the "USRK 1762 key labels" name space with a value 1764 EAP Re-authentication Root Key@ietf.org 1766 and DSRK authorized delivery key from the "USRK key labels" name 1767 space 1769 DSRK Delivery Authorized Key@ietf.org 1770 in accordance with [3]. 1772 10. Acknowledgments 1774 In writing this draft, we benefited from discussing the problem space 1775 and the protocol itself with a number of folks including, Bernard 1776 Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse 1777 Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Parag 1778 Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen 1779 Zorn, Alan DeKok, Katrin Hoeper and other participants of the HOKEY 1780 working group. The credit for the idea to use EAP-Initiate/ 1781 Re-auth-Start goes to Charles Clancy and the multiple link layer SAs 1782 idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin Hoeper 1783 suggested the use of windowing technique to handle multiple 1784 simultaneous ER exchanges. Many thanks to Pasi Eronen for the 1785 suggestion to use hexadecimal encoding for rIKname when sent as part 1786 of keyName-NAI field. Thanks to Bernard Aboba for suggestions in 1787 clarifying the EAP lock step operation and Joe Salowey and Glen Zorn 1788 for help in specifying AAA transport of ERP messages. Thanks to Sam 1789 Hartman for the DSRK Authorization Indication mechanism. 1791 11. References 1793 11.1. Normative References 1795 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1796 Levels", BCP 14, RFC 2119, March 1997. 1798 [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1799 Levkowetz, "Extensible Authentication Protocol (EAP)", 1800 RFC 3748, June 2004. 1802 [3] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 1803 "Specification for the Derivation of Root Keys from an Extended 1804 Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-04 1805 (work in progress), February 2008. 1807 [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 1808 Access Identifier", RFC 4282, December 2005. 1810 [5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1811 for Message Authentication", RFC 2104, February 1997. 1813 11.2. Informative References 1815 [6] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol 1816 Method for 3rd Generation Authentication and Key Agreement 1817 (EAP-AKA)", RFC 4187, January 2006. 1819 [7] Lopez, R., Skarmeta, A., Bournelle, J., Laurent-Maknavicus, M., 1820 and J. Combes, "Improved EAP keying framework for a secure 1821 mobility access service", IWCMC '06 Proceedings of the 2006 1822 international conference on Wireless communications and mobile 1823 computing, New York, NY, USA, 2006. 1825 [8] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to 1826 RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress), 1827 November 2003. 1829 [9] Clancy, C., Nakhjiri, M., Narayanan, V., and L. Dondeti, 1830 "Handover Key Management and Re-authentication Problem 1831 Statement", draft-ietf-hokey-reauth-ps-09 (work in progress), 1832 February 2008. 1834 [10] Institute of Electrical and Electronics Engineers, "IEEE 1835 Standards for Local and Metropolitan Area Networks: Port based 1836 Network Access Control, IEEE Std 802.1X-2004", Dec 2004. 1838 [11] Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management 1839 of EAP based keys for handover and re-authentication", 1840 draft-ietf-hokey-key-mgm-03 (work in progress), February 2008. 1842 [12] Gaonkar, K., Dondeti, L., Narayanan, V., and G. Zorn, "RADIUS 1843 Support for EAP Re-authentication Protocol", 1844 draft-gaonkar-radext-erp-attrs-03 (work in progress), 1845 February 2008. 1847 [13] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1848 Authentication Dial In User Service (RADIUS)", RFC 2865, 1849 June 2000. 1851 [14] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1852 In User Service) Support For Extensible Authentication Protocol 1853 (EAP)", RFC 3579, September 2003. 1855 [15] Dondeti, L. and H. Tschofenig, "Diameter Support for EAP Re- 1856 authentication Protocol", draft-dondeti-dime-erp-diameter-01 1857 (work in progress), November 2007. 1859 [16] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1860 RFC 3162, August 2001. 1862 [17] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1863 Considerations Section in RFCs", BCP 26, RFC 2434, 1864 October 1998. 1866 [18] Housley, R. and B. Aboba, "Guidance for Authentication, 1867 Authorization, and Accounting (AAA) Key Management", BCP 132, 1868 RFC 4962, July 2007. 1870 Appendix A. Example ERP Exchange 1872 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] 1874 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, 1875 cryptosuite,Auth-tag*) 1877 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, 1878 EAP Initiate/Re-auth(SEQ,keyName-NAI, 1879 cryptosuite,Auth-tag*) 1881 2. ER-Server --> Authenticator: AAA-Response{rMSK, 1882 EAP-Finish/Re-auth(SEQ,keyName-NAI, 1883 cryptosuite,[CB-Info],Auth-tag*) 1885 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, 1886 cryptosuite,[CB-Info],Auth-tag*) 1888 * Auth-tag computation is over the entire EAP Initiate/Finish message; 1889 the code values for Initiate and Finish are different and thus 1890 reflection attacks are mitigated. 1892 Figure 12: ERP Exchange 1894 Authors' Addresses 1896 Vidya Narayanan 1897 Qualcomm, Inc. 1898 5775 Morehouse Dr 1899 San Diego, CA 1900 USA 1902 Phone: +1 858-845-2483 1903 Email: vidyan@qualcomm.com 1904 Lakshminath Dondeti 1905 Qualcomm, Inc. 1906 5775 Morehouse Dr 1907 San Diego, CA 1908 USA 1910 Phone: +1 858-845-1267 1911 Email: ldondeti@qualcomm.com 1913 Full Copyright Statement 1915 Copyright (C) The IETF Trust (2008). 1917 This document is subject to the rights, licenses and restrictions 1918 contained in BCP 78, and except as set forth therein, the authors 1919 retain all their rights. 1921 This document and the information contained herein are provided on an 1922 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1923 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1924 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1925 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1926 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1927 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1929 Intellectual Property 1931 The IETF takes no position regarding the validity or scope of any 1932 Intellectual Property Rights or other rights that might be claimed to 1933 pertain to the implementation or use of the technology described in 1934 this document or the extent to which any license under such rights 1935 might or might not be available; nor does it represent that it has 1936 made any independent effort to identify any such rights. Information 1937 on the procedures with respect to rights in RFC documents can be 1938 found in BCP 78 and BCP 79. 1940 Copies of IPR disclosures made to the IETF Secretariat and any 1941 assurances of licenses to be made available, or the result of an 1942 attempt made to obtain a general license or permission for the use of 1943 such proprietary rights by implementers or users of this 1944 specification can be obtained from the IETF on-line IPR repository at 1945 http://www.ietf.org/ipr. 1947 The IETF invites any interested party to bring to its attention any 1948 copyrights, patents or patent applications, or other proprietary 1949 rights that may cover technology that may be required to implement 1950 this standard. Please address the information to the IETF at 1951 ietf-ipr@ietf.org.