idnits 2.17.1 draft-ietf-hokey-erp-aak-06.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 (October 18, 2011) is 4573 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 5296 (Obsoleted by RFC 6696) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 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: April 20, 2012 Y. Wang 6 Q. Wu 7 Huawei Technologies Co., Ltd. 8 G. Zorn, Ed. 9 Network Zen 10 October 18, 2011 12 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory 13 Keying (ERP/AAK) 14 draft-ietf-hokey-erp-aak-06 16 Abstract 18 The Extensible Authentication Protocol (EAP) is a generic framework 19 supporting multiple types of authentication methods. 21 The EAP Re-authentication Protocol (ERP) specifies extensions to EAP 22 and the EAP keying hierarchy to support an EAP method-independent 23 protocol for efficient re-authentication between the peer and an EAP 24 re-authentication server through any authenticator. 26 Authenticated Anticipatory Keying (AAK) is a method by which 27 cryptographic keying material may be established upon one or more 28 candidate attachment points (CAPs) prior to handover. AAK uses the 29 AAA infrastructure for key transport. 31 This document specifies the extensions necessary to enable AAK 32 support in ERP. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 20, 2012. 50 Copyright Notice 52 Copyright (c) 2011 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 Overview . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 5 73 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6 74 5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6 75 5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7 76 5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 8 77 5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 10 78 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11 79 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 The Extensible Authentication Protocol (EAP) [RFC3748] is a generic 90 framework supporting multiple types of authentication methods. In 91 systems where EAP is used for authentication, it is desirable to not 92 repeat the entire EAP exchange with another authenticator. The EAP 93 Re-authentication Protocol (ERP) [RFC5296] specifies extensions to 94 EAP and the EAP keying hierarchy to support an EAP method-independent 95 protocol for efficient re-authentication between the peer and an EAP 96 re-authentication server through any authenticator. The re- 97 authentication server may be in the home network or in the local 98 network to which the peer is connecting. 100 Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by 101 which cryptographic keying materials may be established prior to 102 handover upon one or more candidate attachment points (CAPs). AAK 103 utilizes the AAA infrastructure for key transport. 105 This document specifies the extensions necessary to enable AAK 106 support in ERP. 108 2. Terminology 110 2.1. Standards Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2.2. Acronyms 118 The following acronyms are used in this document; see the references 119 for more details. 121 AAA Authentication, Authorization and Accounting [RFC3588] 123 CAP Candidate Attachment Point [RFC5836] 125 EA Abbreviation for "ERP/AAK"; used in figures 127 MH Mobile Host 129 SAP Serving Attachment Point [RFC5836] 131 3. ERP/AAK Overview 133 ERP/AAK is intended to allow the establishment of cryptographic 134 keying materials on a single Candidate Attachment Points prior to the 135 arrival of the MH at the Candidate Access Network (CAN). 137 It is assumed that the peer has previously completed full EAP 138 authentication and the peer or SAP knows the identities of 139 neighboring attachment points. Figure 1 shows the general protocol 140 exchange by which the keying material is established on the CAP. 141 This document only discusses the case of distributing the key to a 142 single CAP. 144 +------+ +-----+ +-----+ +-----------+ 145 | Peer | | SAP | | CAP | | EA Server | 146 +--+---+ +--+--+ +--+--+ +-----+-----+ 147 | | | | 148 1. | [EAP-Initiate/ | | | 149 | Re-auth-start | | | 150 | (E-flag) | | | 151 |<---------------| | | 152 | | | | 153 2. | EAP-Initiate/ | | | 154 | Re-auth | | | 155 | (E-flag) | | | 156 |--------------->| | | 157 3. | | AAA(EAP-Initiate/Re-auth(E-flag))| 158 | |--------------------------------->| 159 | | | +---------+---------+ 160 | | | | CA authorized & | 161 4. | | | | authenticated; | 162 | | | | EA keying | 163 | | | | materials derived | 164 | | | +---------+---------+ 165 5. | | | | 166 | | | AAA(pMSK) | 167 | | |<----------------->| 168 | | | | 169 6. | | AAA (EAP-Finish/Re-auth(E-flag)) | 170 | |<---------------------------------| 171 7. | EAP-Finish/ | | | 172 | Re-auth(E-flag)| | | 173 |<---------------| | | 174 | | | | 176 Figure 1: ERP/AAK Operation 178 ERP/AAK re-uses the packet format defined by ERP, but specifies a new 179 flag to differentiate EAP early-authentication from EAP re- 180 authentication. The peer initiates ERP/AAK itself, or does so in 181 response to an EAP-Initiate/Re-Auth-Start message from the SAP. In 182 this document, SAP support for ERP/AAK is assumed. If either the 183 peer or the SAP does not support ERP/AAK, it should fall back to full 184 EAP authentication. 186 The SAP may send the identity of a candidate attachment point to the 187 peer in the EAP-Initiate/Re-auth-Start message. If the EAP-Initiate/ 188 Re-auth-Start packet is not supported by the peer, it is silently 189 discarded. 191 The peer sends an early-authentication request message (EAP-Initiate/ 192 Re-auth with the 'E' flag set) containing the keyName-NAI, the CAP- 193 Identifier, rIK and sequence number. The realm in the keyName-NAI 194 field is used to locate the peer's ERP/AAK server. The CAP- 195 Identifier is used to identify the CAP. The rIK is used to protect 196 the message. The sequence number is used for replay protection. 198 The SAP encapsulates the early-authentication message into a AAA 199 message and sends it to the peer's ERP/AAK server in the realm 200 indicated in the keyName-NAI field. 202 Upon receiving the message, the ERP/AAK server first checks its 203 integrity and freshness, then verifies the identity of the peer by 204 checking the username portion of the KeyName-NAI. Next, the server 205 authenticates and authorizes the CAP specified in the CAP-Identifier 206 TLV. If any of the checks fail, the server sends an early- 207 authentication finish message (EAP-Finish/Re-auth with E-flag set) 208 with the Result flag set to '1'. 210 The ERP/AAK server transports the pMSK to the authenticated and 211 authorized CAP via AAA as described in Section 7. 213 Finally, the ERP/AAK server sends the early-authentication finish 214 message (EAP-Finish/Re-auth with E-flag set) containing the identity 215 of the authorized CAP to the peer via the SAP. 217 4. ERP/AAK Key Hierarchy 219 As an optimization of ERP, ERP/AAK uses a key hierarchy similar to 220 that of ERP. The EMSK is used to derive the ERP/AAK pre-established 221 Root Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key 222 (pIK) and the pre-established Master Session Key (pMSK) are derived 223 from the pRK. The pMSK is established for the CAP when the peer 224 early authenticates to the network. The pIK is established for the 225 peer to re-authenticate the network after handover. The hierarchy 226 relationship is illustrated in Figure 2, below. 228 DSRK EMSK 229 | | 230 +---+---+---+---+ 231 | | | 232 pRK rRK ... 234 Figure 2 236 The EMSK and DSRK both can be used to derive the pRK. In general, 237 the pRK is derived from the EMSK in case of the peer moving in the 238 home AAA realm and derived from the DRSK in case of the peer moving 239 in a visited realm. The DSRK is delivered from the EAP server to the 240 ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. If the 241 peer has previously been authenticated by means of ERP or ERP/AAK, 242 the DSRK SHOULD be directly re-used. 244 pRK 245 | 246 +--------+--------+ 247 | | | 248 pIK pMSK ... 250 Figure 3 252 The pRK is used to derive the pIK and pMSK for the CAP. 254 5. Packet and TLV Extension 256 This section describes the packet and TLV extensions for the ERP/AAK 257 exchange. 259 5.1. EAP-Initiate/Re-auth-Start Packet Extension 261 Figure 4 shows the changed parameters contained in the EAP-Initiate/ 262 Re-auth-Start packet defined in RFC 5296 [RFC5296]. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Code | Identifier | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type |E| Reserved | 1 or more TVs or TLVs ~ 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 4 274 Flags 275 'E' - The E flag is used to indicate early-authentication. 277 Reserved: MUST be set to 0. 279 TVs and TLVs 281 CAP-Identifier: Carried in a TLV payload. The format is identical to 282 that of a DiameterIdentity [RFC3588]. It is used by the SAP to 283 advertise the identity of the CAP to the peer. Exactly one CAP- 284 Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start 285 packet if the SAP has performed CAP discovery. 287 If the EAP-Initiate/Re-auth-Start packet is not supported by the 288 peer, it is discarded silently. 290 5.2. EAP-Initiate/Re-auth Packet Extension 292 Figure 5 illustrates the changed parameters contained in the EAP- 293 Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Code | Identifier | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type |R|x|L|E|Resved | SEQ | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | 1 or more TVs or TLVs ~ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Cryptosuite | Authentication Tag ~ 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 5 309 Flags 311 'x' - The x flag is reserved. It MUST be set to 0. 313 'E' - The E flag is used to indicate early-authentication. 315 The rest of the 4 bits (Resved) MUST be set to 0 and ignored on 316 reception. 318 SEQ 320 A 16-bit sequence number is used for replay protection. 322 TVs and TLVs 323 keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a 324 TLV payload. The Type is 1. The NAI is variable in length, not 325 exceeding 253 octets. The username part of the NAI is the EMSKname 326 used to identify the peer. The realm part of the NAI is the peer's 327 home domain name or the domain to which the peer is currently 328 attached. Exactly one keyName-NAI attribute SHALL be present in an 329 EAP-Initiate/Re-auth packet. 331 CAP-Identifier: Carried in a TLV payload. It is used to indicate the 332 FQDN of a CAP. 334 Sequence number: Carried in a TV payload. The Type is TBD (less than 335 128). It is used in the derivation of the pMSK for each CAP. Each 336 CAP-Identifier in the packet MUST be associated with a unique 337 sequence number. 339 Cryptosuite 341 This field indicates the integrity algorithm used for ERP/AAK. Key 342 lengths and output lengths are either indicated or obvious from the 343 cryptosuite name. We specify some cryptosuites below: 345 0 RESERVED 347 1 HMAC-SHA256-64 349 2 HMAC-SHA256-128 351 3 HMAC-SHA256-256 353 HMAC-SHA256-128 is mandatory to implement and should be enabled in 354 the default configuration. 356 Authentication Tag 358 This field contains the integrity checksum over the ERP/AAK packet, 359 excluding the authentication tag field itself. The length of the 360 field is indicated by the Cryptosuite. 362 If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is 363 discarded silently. 365 5.3. EAP-Finish/Re-auth extension 367 Figure 6 shows the changed parameters contained in the EAP-Finish/ 368 Re-auth packet defined in [RFC5296]. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Code | Identifier | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type |R|x|L|E|Resved | SEQ | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | 1 or more TVs or TLVs ~ 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Cryptosuite | Authentication Tag ~ 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 6 384 Flags 386 'x' - The x flag is reserved. It MUST be set to 0. 388 'E' - The E flag is used to indicate early-authentication. 390 The rest of the 4 bits (Resved) MUST be set to 0 and ignored on 391 reception. 393 SEQ 395 A 16-bit sequence number is used for replay protection. 397 TVs and TLVs 399 keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a 400 TLV payload. The Type is 1. The NAI is variable in length, not 401 exceeding 253 octets. The realm part of the NAI is the home domain 402 name. Exactly one keyName-NAI attribute SHALL be present in an EAP- 403 Finish/Re-auth packet. 405 ERP/AAK-Key: Carried in a TLV payload for the key container. The 406 type is TBD. Exactly one ERP/AAK-key SHALL be present in an EAP- 407 Finish/Re-auth packet. 409 ERP/AAK-Key ::= 410 { sub-TLV: CAP-Identifier } 411 { sub-TLV: pMSK-lifetime } 412 { sub-TLV: pRK-lifetime } 413 { sub-TLV: Cryptosuites } 415 CAP-Identifier 416 Carried in a sub-TLV payload. It is used to indicate the 417 identifier of the candidate authenticator. There exactly one 418 instance of the CAP-Identifier TLV MUST be present in the ERP/ 419 AAK-Key TLV. 421 pMSK-lifetime 422 Carried in a sub-TLV payload. The Type is TBD. The value field 423 is a 32-bit field and contains the lifetime of the pMSK in 424 seconds. If the 'L' flag is set, the pMSK Lifetime attribute 425 SHOULD be present. 427 pRK-lifetime 428 Carried in a sub-TLV payload. The Type is TBD. The value field 429 is a 32-bit field and contains the lifetime of the pRK in seconds. 430 If the 'L' flag is set, the pRK Lifetime attribute SHOULD be 431 present. 433 List of Cryptosuites 434 Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value 435 field contains a list of cryptosuites, each 1 octet in length. 436 The allowed cryptosuite values are as specified in Section 5.2, 437 above. The server SHOULD include this attribute if the 438 cryptosuite used in the EAP-Initiate/Re-auth message was not 439 acceptable and the message is being rejected. The server MAY 440 include this attribute in other cases. The server MAY use this 441 attribute to signal to the peer about its cryptographic algorithm 442 capabilities. 444 Cryptosuite 446 This field indicates the integrity algorithm and PRF used for ERP/ 447 AAK. Key lengths and output lengths are either indicated or obvious 448 from the cryptosuite name. 450 Authentication Tag 452 This field contains the integrity checksum over the ERP/AAK packet, 453 excluding the authentication tag field itself. The length of the 454 field is indicated by the Cryptosuite. 456 5.4. TV and TLV Attributes 458 With the exception of the rRK Lifetime and rMSK Lifetime TV payloads, 459 the attributes specified in Section 5.3.4 of [RFC5296] also apply to 460 this document. In this document, new attributes which may be present 461 in the EAP-Initiate and EAP-Finish messages are defined as below: 463 o Sequence number: This is a TV payload. The type is TBD. 465 o ERP/AAK-Key: This is a TLV payload. The type is TBD. 467 o pRK Lifetime: This is a TV payload. The type is TBD. 469 o pMSK Lifetime: This is a TV payload. The type is TBD. 471 o List of Cryptosuites: This is a TLV payload. The type is TBD. 473 6. Lower Layer Considerations 475 Similar to ERP, some lower layer specifications may need to be 476 revised to support ERP/AAK; refer to of Section 6 [RFC5296] for 477 additional guidance. 479 7. AAA Transport Considerations 481 AAA transport of ERP/AAK messages is the same as AAA transport of the 482 ERP message [RFC5296]. In addition, the document requires AAA 483 transport of the ERP/AAK keying materials delivered by the ERP/AAK 484 server to the CAP. Hence, a new Diameter ERP/AAK application message 485 should be specified to transport the keying materials. 487 8. Security Considerations 489 This section provides an analysis of the protocol in accordance with 490 the AAA key management requirements specified in RFC 4962 [RFC4962]. 492 o Cryptographic algorithm independence: ERP-AAK satisfies this 493 requirement. The algorithm chosen by the peer is indicated in the 494 EAP-Initiate/Re-auth message. If the chosen algorithm is 495 unacceptable, the EAP server returns an EAP- Finish/Re-auth 496 message with Failure indication. 498 o Strong, fresh session keys: ERP-AAK results in the derivation of 499 strong, fresh keys that are unique for the given CAP. An pMSK is 500 always derived on-demand when the peer requires a key with a new 501 CAP. The derivation ensures that the compromise of one pMSK does 502 not result in the compromise of a different pMSK at any time. 504 o Limit key scope: The scope of all the keys derived by ERP-AAK is 505 well defined. The pRK is used to derive the pIK and pMSK for the 506 CAP. Different sequence numbers for each CAP MUST be used to 507 derive a unique pMSK. 509 o Replay detection mechanism: For replay protection of ERP-AAK 510 messages, a sequence number associated with the pMSK is used. 512 o Authenticate all parties: The EAP Re-auth Protocol provides mutual 513 authentication of the peer and the server. The peer and SAP are 514 authenticated via ERP. The CAP is authenticated and trusted by 515 the SAP. 517 o Peer and authenticator authorization: The peer and authenticator 518 demonstrate possession of the same key material without disclosing 519 it, as part of the lower layer secure authentication protocol. 521 o Keying material confidentiality: The peer and the server derive 522 the keys independently using parameters known to each entity. 524 o Uniquely named keys: All keys produced within the ERP context can 525 be referred to uniquely as specified in this document. 527 o Prevent the domino effect: Different sequence numbers for each CAP 528 MUST be used to derive the unique pMSK. So the compromise of one 529 pMSK does not hurt any other CAP. 531 o Bind key to its context: the pMSK are bound to the context in 532 which the sequence numbers are transmitted. 534 o Confidentiality of identity: this is the same as with the ERP 535 protocol [RFC5296]. 537 o Authorization restriction: All the keys derived are limited in 538 lifetime by that of the parent key or by server policy. Any 539 domain-specific keys are further restricted to be used only in the 540 domain for which the keys are derived. Any other restrictions of 541 session keys may be imposed by the specific lower layer and are 542 out of scope for this specification. 544 9. IANA Considerations 546 IANA is requested to assign four TLV type values from the registry of 547 EAP Initiate and Finish Attributes maintained at 548 http://www.iana.org/assignments/eap-numbers/eap-numbers.xml. 549 New TLV types: 551 o Sequence number 553 o ERP/AAK-Key 555 o pRK Lifetime 557 o pMSK Lifetime 559 10. Acknowledgement 561 In writing this document, we have received reviews from many experts 562 in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and 563 Semyon Mizikovsky. We apologize if we miss some of those who have 564 helped us. 566 11. References 568 11.1. Normative References 570 [RFC2119] Bradner, S., "Key words for use in 571 RFCs to Indicate Requirement Levels", 572 BCP 14, RFC 2119, March 1997. 574 [RFC5296] Narayanan, V. and L. Dondeti, "EAP 575 Extensions for EAP Re-authentication 576 Protocol (ERP)", RFC 5296, 577 August 2008. 579 11.2. Informative References 581 [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, 582 "Diameter Attribute-Value Pairs for 583 Cryptographic Key Transport", 584 draft-ietf-dime-local-keytran-14 (work 585 in progress), August 2011. 587 [RFC3588] Calhoun, P., Loughney, J., Guttman, 588 E., Zorn, G., and J. Arkko, "Diameter 589 Base Protocol", RFC 3588, 590 September 2003. 592 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 593 Carlson, J., and H. Levkowetz, 594 "Extensible Authentication Protocol 595 (EAP)", RFC 3748, June 2004. 597 [RFC4962] Housley, R. and B. Aboba, "Guidance 598 for Authentication, Authorization, and 599 Accounting (AAA) Key Management", 600 BCP 132, RFC 4962, July 2007. 602 [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, 603 "Extensible Authentication Protocol 604 (EAP) Early Authentication Problem 605 Statement", RFC 5836, April 2010. 607 Authors' Addresses 609 Zhen Cao 610 China Mobile 611 53A Xibianmennei Ave., Xuanwu District 612 Beijing, Beijing 100053 613 P.R. China 615 EMail: zehn.cao@gmail.com 617 Hui Deng 618 China Mobile 619 53A Xibianmennei Ave., Xuanwu District 620 Beijing, Beijing 100053 621 P.R. China 623 EMail: denghui02@gmail.com 625 Yungui Wang 626 Huawei Technologies Co., Ltd. 627 Floor 10, HuiHong Mansion, No.91 BaiXia Rd. 628 Nanjing, Jiangsu 210001 629 P.R. China 631 Phone: +86 25 84565893 632 EMail: w52006@huawei.com 634 Qin Wu 635 Huawei Technologies Co., Ltd. 636 Floor 12, HuiHong Mansion, No.91 BaiXia Rd. 637 Nanjing, Jiangsu 210001 638 P.R. China 640 Phone: +86 25 84565892 641 EMail: bill.wu@huawei.com 642 Glen Zorn (editor) 643 Network Zen 644 227/358 Thanon Sanphawut 645 Bang Na, Bangkok 10260 646 Thailand 648 Phone: +66 (0) 87-040-4617 649 EMail: glenzorn@gmail.com