idnits 2.17.1 draft-ietf-hokey-erp-aak-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2, 2012) is 4370 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5296 (Obsoleted by RFC 6696) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Cao 3 Internet-Draft H. Deng 4 Intended status: Standards Track China Mobile 5 Expires: November 3, 2012 Q. Wu 6 Huawei 7 G. Zorn, Ed. 8 Network Zen 9 May 2, 2012 11 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory 12 Keying (ERP/AAK) 13 draft-ietf-hokey-erp-aak-11 15 Abstract 17 The Extensible Authentication Protocol (EAP) is a generic framework 18 supporting multiple types of authentication methods. 20 The EAP Re-authentication Protocol (ERP) specifies extensions to EAP 21 and the EAP keying hierarchy to support an EAP method-independent 22 protocol for efficient re-authentication between the peer and an EAP 23 re-authentication server through any authenticator. 25 Authenticated Anticipatory Keying (AAK) is a method by which 26 cryptographic keying material may be established upon one or more 27 candidate attachment points (CAPs) prior to handover. AAK uses the 28 AAA infrastructure for key transport. 30 This document specifies the extensions necessary to enable AAK 31 support in ERP. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 3, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 70 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4 72 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8 74 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9 75 5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9 76 5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10 77 5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 12 78 5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14 79 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 15 80 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 The Extensible Authentication Protocol (EAP) [RFC3748] is a generic 91 framework supporting multiple types of authentication methods. In 92 systems where EAP is used for authentication, it is desirable to not 93 repeat the entire EAP exchange with another authenticator. The EAP 94 Re-authentication Protocol (ERP) [RFC5296] specifies extensions to 95 EAP and the EAP keying hierarchy to support an EAP method-independent 96 protocol for efficient re-authentication between the EAP re- 97 authentication peer and an EAP re-authentication server through any 98 authenticator. The re-authentication server may be in the home 99 network or in the local network to which the mobile host (i.e., the 100 EAP re-authentication peer) is connecting. 102 Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by 103 which cryptographic keying materials may be established prior to 104 handover upon one or more candidate attachment points (CAPs). AAK 105 utilizes the AAA infrastructure for key transport. 107 This document specifies the extensions necessary to enable AAK 108 support in ERP. 110 2. Terminology 112 2.1. Standards Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2.2. Acronyms 120 The following acronyms are used in this document; see the references 121 for more details. 123 AAA 124 Authentication, Authorization and Accounting [RFC3588] 126 CAP 127 Candidate Attachment Point [RFC5836] 129 EA 130 Abbreviation for "ERP/AAK" 132 EA Peer 133 An EAP peer that supports the ERP/AAK. Note that all references 134 to "peer" in this document imply an EA peer, unless specifically 135 noted otherwise. 137 SAP 138 Serving Attachment Point [RFC5836] 140 3. ERP/AAK Description 142 ERP/AAK is intended to allow the establishment of cryptographic 143 keying materials on a single Candidate Attachment Point prior to the 144 arrival of the peer at the Candidate Access Network (CAN) upon 145 request by the peer. 147 In this document, ERP/AAK support by the peer is assumed. Also it is 148 assumed that the peer has previously completed full EAP 149 authentication and that either the peer or SAP knows the identities 150 of neighboring attachment points. Note that the behavior of a peer 151 that does not support the ERP-AAK scheme defined in this 152 specification is out of the scope of this document. Figure 1 shows 153 the general protocol exchange by which the keying material is 154 established on the CAP. 156 +------+ +-----+ +-----+ +-----------+ 157 | Peer | | SAP | | CAP | | EA Server | 158 +--+---+ +--+--+ +--+--+ +-----+-----+ 159 | | | | 160 a. | [EAP-Initiate/ | | | 161 | Re-auth-start | | | 162 | (E-flag)] | | | 163 |<---------------| | | 164 | | | | 165 b. | EAP-Initiate/ | | | 166 | Re-auth | | | 167 | (E-flag) | | | 168 |--------------->| | | 169 c. | | AAA(EAP-Initiate/Re-auth(E-flag))| 170 | |--------------------------------->| 171 | | | +---------+---------+ 172 | | | | CA authorized & | 173 d. | | | | and EA Keying | 174 | | | | Distribution | 175 | | | +---------+---------+ 176 | | | | 177 | | | | 178 f. | | AAA (EAP-Finish/Re-auth(E-flag)) | 179 | |<---------------------------------| 180 g. | EAP-Finish/ | | | 181 | Re-auth(E-flag)| | | 182 |<---------------| | | 183 | | | | 185 Figure 1: ERP/AAK Exchange 187 +-----------+ +---------+ 188 | | | | 189 | EA Server | | CAP | 190 | | | | 191 +-----|-----+ +----|----+ 192 | | 193 | | 194 | AAA Request(pMSK) | 195 e.1|------------------------->| 196 | | 197 | | 198 | | 199 | AAA Response (Success) | 200 e.2|<-------------------------| 201 | | 202 | | 203 | | 205 Figure 2: Key Distribution for ERP/AAK 207 ERP/AAK re-uses the packet format defined by ERP, but specifies a new 208 flag to differentiate EAP early-authentication from EAP re- 209 authentication. The peer initiates ERP/AAK itself, or does so in 210 response to an EAP-Initiate/Re-Auth-Start message from the SAP. 212 In the latter case, the SAP MAY send the identity of one or more 213 Candidate Attachment Points to which the SAP is adjacent to the peer 214 in the EAP-Initiate/Re-auth-Start message (see a. in Figure 1). The 215 Peer SHOULD override the identity of CAP(s) carried in EAP-Initiate/ 216 Re-auth-Start message by sending EAP-Initiate/Re-auth with the 'E' 217 flag set if it knows to which CAP it will move. If the EAP-Initiate/ 218 Re-auth-Start packet is not supported by the peer, it MUST be 219 silently discarded. 221 If the peer initiates ERP/AAK, the peer MAY send an early- 222 authentication request message (EAP-Initiate/Re-auth with the 'E' 223 flag set) containing the keyName-NAI, the CAP-Identifier, rIK and 224 sequence number (see b. in Figure 1). The realm in the keyName-NAI 225 field is used to locate the peer's ERP/AAK server. The CAP- 226 Identifier is used to identify the CAP. The rIK is defined in 227 Narayanan & Dondeti [RFC5296] and used to protect the integrity of 228 the message. The sequence number is used for replay protection. 230 The SAP SHOULD verify the integrity of thus message at step b. If 231 this verification fails, the SAP MUST send an EAP-Finish/Re-auth 232 message with the Result flag set to '1' (Failure). If the 233 verification succeeds, the SAP SHOULD encapsulate the early- 234 authentication message into a AAA message and send it to the peer's 235 ERP/AAK server in the realm indicated in the keyName-NAI field (see 236 c. in Figure 1). 238 Upon receiving the message, the ERP/AAK server MUST first use the 239 keyName indicated in the keyName-NAI to look up the rIK and check the 240 integrity and freshness of the message. Then the ERP/AAK server MUST 241 verify the identity of the peer by checking the username portion of 242 the KeyName-NAI. If any of the checks fail, the server MUST send an 243 early- authentication finish message (EAP-Finish/Re-auth with E-flag 244 set) with the Result flag set to '1'. Next, the server MUST 245 authorize the CAP specified in the CAP-Identifier TLV. In the 246 success case, the server MUST derive a pMSK from the pRK for the CAP 247 carried in the the CAP-Identifier field using the sequence number 248 associated with CAP-Identifier as an input to the key derivation. 249 (see d. in Figure 1). 251 Then the ERP/AAK server MUST transport the pMSK to the authorized CAP 252 via AAA Section 7 as illustrated above (see e.1 and e.2 in Figure 2). 253 Note that key distribution in Figure 2 is one part of step d. in 254 Figure 1. 256 Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK 257 server SHOULD send the early-authentication finish message (EAP- 258 Finish/ Re-auth with E-flag set) containing the identity of the 259 authorized CAP to the peer via the SAP along with the lifetime of the 260 pMSK. If the peer also requests the rRK lifetime, the ERP/AAK server 261 SHOULD send the rRK lifetime in the EAP-Finish/Re-auth message. (see 262 f. and g. in Figure 1). 264 4. ERP/AAK Key Hierarchy 266 ERP/AAK uses a key hierarchy similar to that of ERP. The ERP/AAK 267 pre-established Root Key (pRK) is derived from either the EMSK or the 268 DSRK as specified below (see Section 4.1). In general, the pRK is 269 derived from the EMSK if the peer is located in the home AAA realm 270 and derived from the DRSK if the peer is in a visited realm. The 271 DSRK is delivered from the EAP server to the ERP/AAK server as 272 specified in [I-D.ietf-dime-local-keytran]. If the peer has 273 previously been authenticated by means of ERP or ERP/AAK, the DSRK 274 SHOULD be directly re-used. 276 DSRK EMSK 277 | | 278 +---+---+---+---+ 279 | 280 pRK ... 282 Figure 3: ERP/AAK Root Key Derivation 284 Similarly, the pre-established Master Session Key (pMSK) is derived 285 from the pRK. The pMSK is established for the CAP when the peer 286 early authenticates to the network. The hierarchy relationship is 287 illustrated Figure 4, 289 pRK 290 | 291 +--------+--------+ 292 | 293 pMSK ... 295 Figure 4: ERP/AAK Key Hierarchy 297 below. 299 4.1. Derivation of the pRK and pMSK 301 The rRK is derived as specified in [RFC5295]. 303 pRK = KDF (K, S), where 305 K = EMSK or K = DSRK and 307 S = pRK Label | "\0" | length 309 The pRK Label is an IANA-assigned 8-bit ASCII string: 311 EAP Early-Authentication Root Key@ietf.org 313 assigned from the "USRK key labels" name space in accordance with 314 Salowey, et al. [RFC5295]. The KDF and algorithm agility for the 315 KDF are also defined in RFC 5295. The KDF algorithm is indicated in 316 the cryptosuit field or list of cryptosuits TLV payload as specified 317 in the section 5.2 and section 5.3. 319 The pMSK uses the same PDF as pRK and is derived as follows: 321 pMSK = KDF (K, S), where 323 K = pRK and 325 S = pMSK label | "\0" | SEQ | length 327 The pMSK label is the 8-bit ASCII string: 329 EAP Early-Authentication Master Session Key@ietf.org 331 The length field refers to the length of the pMSK in octets encoded 332 as specified in RFC 5295. SEQ is sent by either the peer or the 333 server in the ERP/AAK message using the SEQ field or the Sequence 334 number TLV and encoded as an 16-bit number as specified in 335 Section 5.2 and Section 5.3. 337 5. Packet and TLV Extension 339 This section describes the packet and TLV extensions for the ERP/AAK 340 exchange. 342 5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension 344 Figure 5 shows the new parameters contained in the EAP-Initiate/ 345 Re-auth-Start packet defined in RFC 5296 [RFC5296]. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Code | Identifier | Length | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type |E| Reserved | 1 or more TVs or TLVs ~ 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 5 357 Flags 359 'E' - The E flag is used to indicate early-authentication. This 360 field MUST be set to '1' if early authentication is in use and MUST 361 be set to '0' otherwise. 363 The rest of the 7 bits (Reserved ) MUST be set to 0 and ignored on 364 reception. 366 TVs and TLVs 368 CAP-Identifier: Carried in a TLV payload. The format is identical to 369 that of a DiameterIdentity [RFC3588]. It is used by the SAP to 370 advertise the identity of the CAP to the peer. Exactly one CAP- 371 Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start 372 packet if the SAP has performed CAP discovery. 374 If the EAP-Initiate/Re-auth-Start packet is not supported by the 375 peer, it SHOULD be discarded silently. 377 5.2. EAP-Initiate/Re-auth Packet and TLV Extension 379 Figure 6 illustrates the new parameters contained in the EAP- 380 Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Code | Identifier | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type |R|x|L|E|Resved | SEQ | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | 1 or more TVs or TLVs ~ 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Cryptosuite | Authentication Tag ~ 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 6 396 Flags 398 'x' - The x flag is reserved. It MUST be ignored on receipt. 400 'L' - As defined in section 5.3.2 of [RFC5296], this bit is used to 401 request the key lifetimes from the server. 403 'E' - The E flag is used to indicate early-authentication. 405 The first bit(R) and final 4 bits (Resved) MUST be set to 0 and 406 ignored on reception. 408 SEQ 410 As defined in Section 5.3.2 of [RFC5296],this field is 16-bit 411 sequence number and used for replay protection. 413 TVs and TLVs 415 keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a 416 TLV payload. The Type is 1. The NAI is variable in length, not 417 exceeding 253 octets. The username part of the NAI is the EMSKname 418 used to identify the peer. The realm part of the NAI is the peer's 419 home domain name if the peer communicates with the home EA server or 420 the domain to which the peer is currently attached (i.e., local 421 domain name) if the peer communicates with a local EA server. The 422 SAP knows whether the KeyName-NAI carries the local domain name by 423 comparing the domain name carried in KeyName-NAI with the local 424 domain name which is associated with the SAP. Exactly one keyName- 425 NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet and 426 the realm part of it SHOULD follow the use of internationalized 427 domain names defined in RFC5890 [RFC5890]. 429 CAP-Identifier: Carried in a TLV payload.The Type is TBD (less than 430 128). This field is used to indicate the FQDN of a CAP. The value 431 field MUST be encoded as specified in Section 8 of RFC 3315 432 [RFC3315]. Exactly one instance of the CAP-Identifier TLV MUST be 433 present in the ERP/AAK-Key TLV. 435 Sequence number: The Type is TBD (less than 128). The value field is 436 a 16-bit field and used in the derivation of the pMSK for a CAP. 438 Cryptosuite 440 This field indicates the integrity algorithm used for ERP/AAK. Key 441 lengths and output lengths are either indicated or obvious from the 442 cryptosuite name, e.g., HMAC-SHA256-128 denotes HMAC computed using 443 the SHA-256 function [RFC4868] with 256-bit key length and the output 444 truncated to 128 bits [RFC2104]. We specify some cryptosuites below: 446 0-1 RESERVED 448 2 HMAC-SHA256-128 450 3 HMAC-SHA256-256 452 HMAC-SHA256-128 is REQUIRED to implement and SHOULD be enabled in the 453 default configuration. 455 Authentication Tag 457 This field contains an integrity checksum over the ERP/AAK packet 458 from the first bit of the Code field to the last bit of the 459 Cryptosuite field, excluding the Authentication Tag field itself. 460 The value field is calculated using the integrity algorithm indicated 461 in the Cryptosuite field and rIK specified in [RFC5296] as the secret 462 key. The length of the field is indicated by the Cryptosuite. 464 The peer uses the Authentication Tag to determine the validity of the 465 EAP-Finish/Re-auth message from the server. 467 If the message doesn't pass verification or the Authentication Tag is 468 not included in the message, the message SHOULD be discarded 469 silently. 471 If the EAP-Initiate/Re-auth packet is not supported by the SAP, it 472 SHOULD be discarded silently. The peer MUST maintain retransmission 473 timers for reliable transport of the EAP-Initiate/Re-auth message. 474 If there is no response to the EAP-Initiate/Re-auth message from the 475 server after the necessary number of retransmissions (see Section 6), 476 the peer MUST assume that ERP/AAK is not supported by the SAP. 478 5.3. EAP-Finish/Re-auth packet and TLV extension 480 Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth 481 packet defined in [RFC5296]. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Code | Identifier | Length | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type |R|x|L|E|Resved | SEQ | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | 1 or more TVs or TLVs ~ 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Cryptosuite | Authentication Tag ~ 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Figure 7 497 Flags 499 'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used to 500 used as the Result flag. This field MUST be set to '1' if indicates 501 success and MUST be set to '0' otherwise. 503 'x' - The x flag is reserved. It MUST be ignored on receipt. 505 'L' - As defined in section 5.3.3 of [RFC5296], this bit is used to 506 request the key lifetimes from the server. 508 'E' - The E flag is used to indicate early-authentication. 510 The final 4 bits (Resved) MUST be set to 0 and ignored on reception. 512 SEQ 514 As defined in Section 5.3.3 of [RFC5296], this field is a 16-bit 515 sequence number and used for replay protection. 517 TVs and TLVs 519 keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a 520 TLV payload. The Type is 1. The NAI is variable in length, not 521 exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be 522 present in an EAP-Finish/Re-auth packet. 524 ERP/AAK-Key: Carried in a TLV payload for the key container. The 525 type is TBD. Exactly one ERP/AAK-key SHALL only be present in an 526 EAP-Finish/Re-auth packet. 528 ERP/AAK-Key ::= 529 { sub-TLV: CAP-Identifier } 530 { sub-TLV: pMSK-lifetime } 531 { sub-TLV: pRK-lifetime } 532 { sub-TLV: Cryptosuites } 534 CAP-Identifier 535 Carried in a sub-TLV payload. The Type is TBD (less than 128). 536 This field is used to indicate the identifier of the candidate 537 authenticator. The value field MUST be encoded as specified in 538 Section 8 of RFC 3315 [RFC3315]. There at least one instance of 539 the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV. 541 pMSK-lifetime 542 Carried in a sub-TLV payload of the EAP-Finish/Re-auth message. 543 The Type is TBD. The value field is an unsigned 32-bit field and 544 contains the lifetime of the pMSK in seconds. This value is 545 calculated by the server after pRK-lifetime computation upon 546 receiving the EAP-Initiate/Re-auth message. The rIK SHOULD share 547 the same lifetime as the pMSK. If the 'L' flag is set, the pMSK- 548 Lifetime attribute MUST be present. 550 pRK-lifetime 551 Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The 552 Type is TBD. The value field is an unsigned 32-bit field and 553 contains the lifetime of the pRK in seconds. This value is 554 calculated by the server before pMSK-lifetime computation upon 555 receiving a EAP-Initiate/Re-auth message. If the 'L' flag is set, 556 the pRK-Lifetime attribute MUST be present. 558 List of Cryptosuites 559 Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value 560 field contains a list of cryptosuites (at least one cryptosuite 561 SHOULD be included), each 1 octet in length. The allowed 562 cryptosuite values are as specified in Section 5.2, above. The 563 server SHOULD include this attribute if the cryptosuite used in 564 the EAP-Initiate/Re-auth message was not acceptable and the 565 message is being rejected. The server MAY include this attribute 566 in other cases. The server MAY use this attribute to signal to 567 the peer about its cryptographic algorithm capabilities. 569 Cryptosuite 571 This field indicates the integrity algorithm and PRF used for ERP/ 572 AAK. HMAC-SHA256-128 is REQUIRED to implement and SHOULD be enabled 573 in the default configuration. Key lengths and output lengths are 574 either indicated or obvious from the cryptosuite name. 576 Authentication Tag 578 This field contains the integrity checksum over the ERP/AAK packet 579 from the first bit of the Code field to the last bit of the 580 Cryptosuite field excluding the Authentication Tag field itself. The 581 value field is calculated using the integrity algorithm indicated in 582 the Cryptosuite field and the rIK [RFC5296] as the integrity key. 583 The length of the field is indicated by the corresponding 584 Cryptosuite. 586 The peer uses the authentication tag to determine the validity of the 587 EAP-Finish/Re-auth message from a server. 589 If the message doesn't pass verification or the authentication tag is 590 not included in the message, the message SHOULD be discarded 591 silently. 593 If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is 594 discarded silently. The peer MUST maintain retransmission timers for 595 reliable transport of EAP-Initiate/Re-auth message. If there is no 596 response to the EAP-Initiate/Re-auth message from the server after 597 the necessary number of retransmissions (See Section 6), the peer 598 MUST assume that ERP/AAK is not supported by the SAP. 600 5.4. TV and TLV Attributes 602 With the exception of the rRK-Lifetime and rMSK-Lifetime TV payloads, 603 the attributes specified in Section 5.3.4 of [RFC5296] also apply to 604 this document. In this document, new attributes which may be present 605 in the EAP-Initiate and EAP-Finish messages are defined as below: 607 o Sequence number: This is a TV payload. The type is 7. 609 o ERP/AAK-Key: This is a TLV payload. The type is 8. 611 o pRK-Lifetime: This is a TV payload. The type is 9. 613 o pMSK-Lifetime: This is a TV payload. The type is 10. 615 o CAP-Identifier: This is a TLV payload. The type is 11. 617 6. Lower Layer Considerations 619 Similar to ERP, some lower layer specifications may need to be 620 revised to support ERP/AAK; refer to Section 6 of [RFC5296] for 621 additional guidance. 623 7. AAA Transport Considerations 625 The AAA transport of ERP/AAK messages is the same as that of the ERP 626 message [RFC5296]. In addition, this document requires AAA transport 627 of the ERP/AAK keying materials delivered by the ERP/AAK server to 628 the CAP. Hence, a new AAA message for the ERP/AAK application should 629 be specified to transport the keying materials. 631 8. Security Considerations 633 This section provides an analysis of the protocol in accordance with 634 the AAA key management requirements specified in RFC 4962 [RFC4962]. 636 o Cryptographic algorithm independence: ERP-AAK satisfies this 637 requirement. The algorithm chosen by the peer for calculating the 638 authentication tag is indicated in the EAP-Initiate/Re-auth 639 message. If the chosen algorithm is unacceptable, the EAP server 640 returns an EAP-Finish/Re-auth message with a Failure indication. 642 o Strong, fresh session keys: ERP-AAK results in the derivation of 643 strong, fresh keys that are unique for the given CAP. An pMSK is 644 always derived on-demand when the peer requires a key with a new 645 CAP. The derivation ensures that the compromise of one pMSK does 646 not result in the compromise of a different pMSK at any time. 648 o Limit key scope: The scope of all the keys derived by ERP-AAK is 649 well defined. The pRK is used to derive the pMSK for the CAP. 650 Different sequence numbers for each CAP MUST be used to derive a 651 unique pMSK. 653 o Replay detection mechanism: For replay protection a sequence 654 number associated with the pMSK is used.The peer increments the 655 sequence number by one after it sends an ERP/AAK message. The 656 server sets the expected sequence number to the received sequence 657 number plus one after verifying the validity of the received 658 message and responds to the message. 660 o Authenticate all parties: The EAP Re-auth Protocol provides mutual 661 authentication of the peer and the server. The peer and SAP are 662 authenticated via ERP. The CAP is authenticated and trusted by 663 the SAP. 665 o Peer and authenticator authorization: The peer and authenticator 666 demonstrate possession of the same keying material without 667 disclosing it, as part of the lower layer secure authentication 668 protocol. 670 o Keying material confidentiality: The peer and the server derive 671 the keys independently using parameters known to each entity. 673 o Uniquely named keys: All keys produced within the ERP context can 674 be referred to uniquely as specified in this document. 676 o Prevent the domino effect: Different sequence numbers for each CAP 677 MUST be used to derive the unique pMSK. So the compromise of one 678 pMSK does not hurt any other CAP. 680 o Bind key to its context: the pMSK are bound to the context in 681 which the sequence numbers are transmitted. 683 o Confidentiality of identity: this is the same as with the ERP 684 protocol [RFC5296]. 686 o Authorization restriction: All the keys derived are limited in 687 lifetime by that of the parent key or by server policy. Any 688 domain-specific keys are further restricted to be used only in the 689 domain for which the keys are derived. Any other restrictions of 690 session keys may be imposed by the specific lower layer and are 691 out of scope for this specification. 693 9. IANA Considerations 695 IANA is requested to assign five TLV type values from the registry of 696 EAP Initiate and Finish Attributes maintained at 697 http://www.iana.org/assignments/eap-numbers/eap-numbers.xml. 698 with the following numbers: 700 o Sequence number: This is a TV payload. The type is 7. 702 o ERP/AAK-Key: This is a TLV payload. The type is 8. 704 o pRK Lifetime: This is a TLV payload. The type is 9. 706 o pMSK Lifetime: This is a TLV payload. The type is 10. 708 o CAP-Identifier: This is a TLV payload. The type is 11. 710 This document reuses the crytosuites have already created for 'Re- 711 authentication Cryptosuites' in [RFC5296]. 713 Further, this document instructs IANA to add a new label in the User 714 Specific Root Keys (USRK) Key Labels of the Extended Master Session 715 Key (EMSK) Parameters registry, as follows: 717 EAP Early-Authentication Root Key@ietf.org 719 This document creates a new registry for the flags in the EAP 720 Initiate/Re-auth-Start message called the "EAP Initiate/Re-auth-Start 721 Flags" and assigns a new flag (E) as follows: 723 (E) 0x80 725 The rest of the values in the 8-bit field are reserved. New values 726 can be assigned by Standards Action or IESG approval. 728 This document also creates a new registry for the flags in the EAP 729 Initiate/Re-auth message called the "EAP Initiate/Re-auth Flags". 730 The following flag are reserved: 732 (R) 0x80 [RFC5296] 734 (B) 0x40 [RFC5296] 736 (L) 0x20 [RFC5296] 738 This document assigns a new flag (E) as follows: 740 (E) 0x10 742 The rest of the values in the 8-bit field are reserved. New values 743 can be assigned by Standards Action or IESG approval. 745 Further,this document creates a new registry for the flags in the EAP 746 Finish/Re-auth message called the "EAP Finish/Re-auth Flags". The 747 following values are reserved. 749 (R) 0x80 [RFC5296] 751 (B) 0x40 [RFC5296] 753 (L) 0x20 [RFC5296] 755 This document assigns a new flag (E) as follows: 757 (E) 0x10 759 The rest of the values in the 8-bit field are reserved. New values 760 can be assigned by Standards Action or IESG approval. 762 10. Acknowledgement 764 In writing this document, Yungui Wang contributed to early versions 765 of this document and we have received reviews from many experts in 766 the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon 767 Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia and 768 Sujing Zhou. We apologize if we miss some of those who have helped 769 us. 771 11. References 773 11.1. Normative References 775 [RFC2119] Bradner, S., "Key words for use in 776 RFCs to Indicate Requirement Levels", 777 BCP 14, RFC 2119, March 1997. 779 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., 780 Lemon, T., Perkins, C., and M. Carney, 781 "Dynamic Host Configuration Protocol 782 for IPv6 (DHCPv6)", RFC 3315, 783 July 2003. 785 [RFC5295] Salowey, J., Dondeti, L., Narayanan, 786 V., and M. Nakhjiri, "Specification 787 for the Derivation of Root Keys from 788 an Extended Master Session Key 789 (EMSK)", August 2008. 791 [RFC5296] Narayanan, V. and L. Dondeti, "EAP 792 Extensions for EAP Re-authentication 793 Protocol (ERP)", RFC 5296, 794 August 2008. 796 11.2. Informative References 798 [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, 799 "Diameter Attribute-Value Pairs for 800 Cryptographic Key Transport", 801 draft-ietf-dime-local-keytran-14 (work 802 in progress), August 2011. 804 [RFC2104] Krawczyk, H., Bellare, M., and R. 805 Canetti, "HMAC: Keyed-Hashing for 806 Message Authentication", RFC 2104, 807 February 1997. 809 [RFC3588] Calhoun, P., Loughney, J., Guttman, 810 E., Zorn, G., and J. Arkko, "Diameter 811 Base Protocol", RFC 3588, 812 September 2003. 814 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 815 Carlson, J., and H. Levkowetz, 816 "Extensible Authentication Protocol 817 (EAP)", RFC 3748, June 2004. 819 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC- 820 SHA-256, HMAC-SHA-384, and HMAC-SHA- 821 512 with IPsec", RFC 4868, May 2007. 823 [RFC4962] Housley, R. and B. Aboba, "Guidance 824 for Authentication, Authorization, and 825 Accounting (AAA) Key Management", 826 BCP 132, RFC 4962, July 2007. 828 [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, 829 "Extensible Authentication Protocol 830 (EAP) Early Authentication Problem 831 Statement", RFC 5836, April 2010. 833 [RFC5890] Klensin, J., "Internationalized Domain 834 Names for Applications (IDNA): 835 Definitions and Document Framework", 836 RFC 5890, August 2010. 838 Authors' Addresses 840 Zhen Cao 841 China Mobile 842 53A Xibianmennei Ave., Xuanwu District 843 Beijing, Beijing 100053 844 P.R. China 846 EMail: zehn.cao@gmail.com 848 Hui Deng 849 China Mobile 850 53A Xibianmennei Ave., Xuanwu District 851 Beijing, Beijing 100053 852 P.R. China 854 EMail: denghui02@gmail.com 855 Qin Wu 856 Huawei 857 Floor 12, HuiHong Mansion, No.91 BaiXia Rd. 858 Nanjing, Jiangsu 210001 859 P.R. China 861 Phone: +86 25 56623633 862 EMail: sunseawq@huawei.com 864 Glen Zorn (editor) 865 Network Zen 866 227/358 Thanon Sanphawut 867 Bang Na, Bangkok 10260 868 Thailand 870 Phone: +66 (0) 87-040-4617 871 EMail: glenzorn@gmail.com