idnits 2.17.1 draft-ietf-hokey-erp-aak-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 11, 2010) is 5099 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5296 (Obsoleted by RFC 6696) == Outdated reference: A later version (-14) exists of draft-ietf-dime-local-keytran-03 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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 12, 2010 Y. Wang 6 Q. Wu 7 Huawei Technologies Co., Ltd. 8 G. Zorn, Ed. 9 Network Zen 10 May 11, 2010 12 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory 13 Keying (ERP/AAK) 14 draft-ietf-hokey-erp-aak-02 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 prior to handover 28 upon one or more candidate attachment points (CAPs), AAK uses the AAA 29 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 November 12, 2010. 50 Copyright Notice 52 Copyright (c) 2010 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 . . . . . . . . . . . . . . . 9 77 5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 11 78 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11 79 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 The Extensible Authentication Protocol (EAP) [RFC3748] is a generic 89 framework supporting multiple types of authentication methods. In 90 systems where EAP is used for authentication, it is desirable to not 91 repeat the entire EAP exchange with another authenticator. The EAP 92 Re-authentication Protocol (ERP) [RFC5296] specifies extensions to 93 EAP and the EAP keying hierarchy to support an EAP method-independent 94 protocol for efficient re-authentication between the peer and an EAP 95 re-authentication server through any authenticator. The re- 96 authentication server may be in the home network or in the local 97 network to which the peer is connecting. 99 Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by 100 which cryptographic keying material may be established prior to 101 handover upon one or more candidate attachment points (CAPs). AAK 102 utilizes the AAA infrastructure for key transport. 104 This document specifies the extensions necessary to enable AAK 105 support in ERP. 107 2. Terminology 109 2.1. Standards Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119] 115 2.2. Acronyms 117 The following acronyms are used in this document; see the references 118 for more details. 120 AAA Authentication, Authorization and Accounting [RFC3588] 122 CAP Candidate Attachment Point [RFC5836] 124 EA Abbreviation for "ERP/AAK"; used in figures 126 MH Mobile Host 128 SAP Serving Attachment Point [RFC5836] 130 3. ERP/AAK Overview 132 ERP/AAK is intended to allow the establishment of cryptographic 133 keying materials on one or more Candidate Attachment Points prior to 134 the arrival of the MH at the Candidate Access Network (CAN). The 135 document also specifies a method by which the SAP may send the 136 identities of neighboring attachment points to the peer in the EAP- 137 Initiate/Re-auth-Start message. 139 It is assumed that the peer has previously completed full EAP 140 authentication. Figure 1 shows the general protocol exchange by 141 which the keying material is established on the CAP(s). 143 +------+ +-----+ +-----+ +-----+ +-----------+ 144 | Peer | | SAP | |CAP1 | |CAPx | | EA Server | 145 +--+---+ +--+--+ +--+--+ +--+--+ +-----+-----+ 146 | | | | | 147 1. | [EAP-Initiate/ | | | 148 | Re-auth-start | | | 149 | (E-flag) | | | | 150 |<----------| | | | 151 | | | | | 152 2. | EAP-Initiate/ | | | 153 | Re-auth | | | | 154 | (E-flag) | | | | 155 |---------->| | | | 156 3. | | AAA (EAP-Initiate/Re-auth(E-flag))| 157 | |---------------------------------->| 158 | | | | | 159 | | | | +---------+---------+ 160 | | | | | CA authorized & | 161 4. | | | | | authenticated; | 162 | | | | | EE keying | 163 | | | | | materials derived | 164 | | | | +---------+---------+ 165 | | | | | 166 5. | | | | AAA(pMSKx) | 167 | | |AAA(pMSK1)|<----------->| 168 | | |<---------------------->| 169 | | | | | 170 6. | | AAA (EAP-Finish/Re-auth(E-flag)) | 171 | |<----------------------------------| 172 | | | | | 173 7. | EAP-Finish/ | | | 174 | Re-auth(E-flag) | | | 175 |<----------| | | | 176 | | | | | 177 Figure 1: ERP/AAK Operation 179 ERP/AAK re-uses the packet format defined by ERP, but specifies a new 180 flag to differentiate EAP early-authentication from EAP re- 181 authentication. The peer initiates ERP/AAK itself, or does so in 182 response to an EAP-Initiate/Re-Auth-Start message from the SAP. In 183 this document, it is required that the SAP should support ERP/AAK. 184 If either the peer or the SAP does not support ERP/AAK, it should 185 fall back to full EAP authentication. 187 The peer sends an early-authentication request message (EAP-Initiate/ 188 Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS- 189 Identifier, rIK and sequence number. The realm in the keyName-NAI 190 field is used to locate the peer's ERP/AAK server. The NAS- 191 Identifier is used to identify the CAP(s). The rIK is used to 192 protect the message. The sequence number is used for replay 193 protection. To avoid the same pre-established Master Session Key 194 (pMSK) being derived for multiple CAPs, the sequence number MUST be 195 unique for each CAP. 197 The SAP encapsulates the early-authentication message into a AAA 198 message and sends it to the peer's ERP/AAK server in the realm 199 indicated in the keyName-NAI field. 201 Upon receiving the message, the ERP/AAK server first checks its 202 integrity and freshness, then authenticates and authorizes the CAP(s) 203 presented in the NAS-Identifier TLV(s). After the CAP(s) is 204 authenticated and authorized successfully, the ERP/AAK server derives 205 the pRK and the subsequent pMSK for each CAP. 207 The ERP/AAK server transports the pMSK to the authenticated and 208 authorized CAP(s) via AAA as described in Section 7. After the 209 keying materials are delivered, the ERP/AAK server should determine 210 each CA whether accepts the pMSK and whether the peer could be 211 attached to. 213 At last, the ERP/AAK server sends the early-authentication finish 214 message (EAP-Finish/Re-auth with E-flag) containing the determinate 215 CAP(s) to the peer via the SAP. 217 4. ERP/AAK Key Hierarchy 219 As an optimization of ERP, ERP/AAK uses key hierarchy similar to that 220 of ERP. The EMSK is used to derive the ERP/AAK pre-established Root 221 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(s) 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 the visited AAA realm. The DSRK is delivered from the EAP server 240 to the ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. 241 If the peer has previously 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(s). Different 253 sequence numbers for each CAP MUST be used to derive the unique 254 pMSK(s). 256 5. Packet and TLV Extension 258 This section describes the packet and TLV extensions for the ERP/AAK 259 exchange. 261 5.1. EAP-Initiate/Re-auth-Start Packet Extension 263 Figure 4 shows the changed parameters contained in the EAP-Initiate/ 264 Re-auth-Start packet defined in RFC 5296 [RFC5296]. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Code | Identifier | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type |E| Reserved | 1 or more TVs or TLVs ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 4 276 Flags 278 'E' - The E flag is used to indicate early-authentication. 280 Reserved: MUST be set to 0. 282 TVs and TLVs 284 NAS-Identifier: As defined in [RFC5296], it is carried in a TLV 285 payload. It is used by the SAP to advertise the identifier(s) of 286 CAP(s) to the peer. One or more NAS-Identifier TLVs MAY be included 287 in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP 288 discovery. 290 If the EAP-Initiate/Re-auth-Start packet is not supported by the 291 peer, it is discarded silently. 293 5.2. EAP-Initiate/Re-auth Packet Extension 295 Figure 5 illustrates the changed parameters contained in the EAP- 296 Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Code | Identifier | Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type |R|x|L|E|Resved | SEQ | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | 1 or more TVs or TLVs ~ 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Cryptosuite | Authentication Tag ~ 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 5 312 Flags 313 'x' - The x flag is reserved. It MUST be set to 0. 315 'E' - The E flag is used to indicate early-authentication. 317 The rest of the 4 bits (Resved) MUST be set to 0 and ignored on 318 reception. 320 SEQ 322 A 16-bit sequence number is used for replay protection. 324 TVs and TLVs 326 keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a 327 TLV payload. The Type is 1. The NAI is variable in length, not 328 exceeding 253 octets. The username part of the NAI is the EMSKname 329 used identify the peer. The realm part of the NAI is the peer's home 330 domain name or the domain to which the peer is currently attached. 331 Exactly one keyName-NAI attribute SHALL be present in an EAP- 332 Initiate/Re-auth packet. 334 NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a 335 TLV payload. It is used to indicate the identifier of a CAP. One or 336 more NAS-Identifier may be included in the EAP-Initiate/Re-auth 337 packet. 339 Sequence number: It is carried in a TV payload. The Type is TBD 340 (which is lower than 128). It is used in the derivation of the pMSK 341 for each CAP to avoid multiple CAP using the same pMSK. Each NAS- 342 Identifier in the packet MUST be associated with a unique sequence 343 number. 345 Cryptosuite 347 This field indicates the integrity algorithm used for ERP/AAK. Key 348 lengths and output lengths are either indicated or are obvious from 349 the cryptosuite name. We specify some cryptosuites below: 351 0 RESERVED 353 1 HMAC-SHA256-64 355 2 HMAC-SHA256-128 357 3 HMAC-SHA256-256 359 HMAC-SHA256-128 is mandatory to implement and should be enabled in 360 the default configuration. 362 Authentication Tag 364 This field contains the integrity checksum over the ERP/AAK packet, 365 excluding the authentication tag field itself. The length of the 366 field is indicated by the Cryptosuite. 368 If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is 369 discarded silently. 371 5.3. EAP-Finish/Re-auth extension 373 Figure 6 shows the changed parameters contained in the EAP-Finish/ 374 Re-auth packet defined in [RFC5296]. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Code | Identifier | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type |R|x|L|E|Resved | SEQ | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | 1 or more TVs or TLVs ~ 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Cryptosuite | Authentication Tag ~ 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 6 390 Flags 392 'x' - The x flag is reserved. It MUST be set to 0. 394 'E' - The E flag is used to indicate early-authentication. 396 The rest of the 4 bits (Resved) MUST be set to 0 and ignored on 397 reception. 399 SEQ 401 A 16-bit sequence number is used for replay protection. 403 TVs and TLVs 405 keyName-NAI: As defined in[RFC5296], this is carried in a TLV 406 payload. The Type is 1. The NAI is variable in length, not 407 exceeding 253 octets. The realm part of the NAI is the home domain 408 name. Exactly one keyName-NAI attribute SHALL be present in an EAP- 409 Finish/Re-auth packet. 411 ERP/AAK-Key: It is carried in a TLV payload for the key container. 412 The type is TBD. One or more than one ERP/AAK-key may be present in 413 an EAP-Finish/Re-auth packet. 415 ERP/AAK-Key ::= 416 { sub-TLV: NAS-Identifier } 417 { sub-TLV: pMSK-lifetime } 418 { sub-TLV: pRK-lifetime } 419 { sub-TLV: Cryptosuites } 421 NAS-Identifier: It is carried in a sub-TLV payload. It is used to 422 indicate the identifier of candidate authenticator. There exactly 423 one instance of the NAS-Identifier TLV MUST be present in the ERP/ 424 AAK-Key TLV. 426 pMSK-lifetime: It is carried in a sub-TLV payload. The Type is 427 TBD. The value field is a 32-bit field and contains the lifetime 428 of the pMSK in seconds. If the 'L' flag is set, the pMSK Lifetime 429 attribute SHOULD be present. 431 pRK-lifetime: It is carried in a sub-TLV payload. The Type is 432 TBD. The value field is a 32-bit field and contains the lifetime 433 of the pRK in seconds. If the 'L' flag is set, the pRK Lifetime 434 attribute SHOULD be present. 436 List of Cryptosuites: This is a sub-TLV payload. The Type is TBD. 437 The value field contains a list of cryptosuites, each 1 octet in 438 length. The allowed cryptosuite values are as specified in 439 Section 5.2, above. The server SHOULD include this attribute if 440 the cryptosuite used in the EAP-Initiate/Re-auth message was not 441 acceptable and the message is being rejected. The server MAY 442 include this attribute in other cases. The server MAY use this 443 attribute to signal to the peer about its cryptographic algorithm 444 capabilities. 446 Cryptosuite 448 This field indicates the integrity algorithm and PRF used for ERP/ 449 AAK. Key lengths and output lengths are either indicated or are 450 obvious from the cryptosuite name. 452 Authentication Tag 454 This field contains the integrity checksum over the ERP/AAK packet, 455 excluding the authentication tag field itself. The length of the 456 field is indicated by the Cryptosuite. 458 5.4. TV/TLV and sub-TLV Attributes 460 The TV and TLV attributes are the same specified as section 5.3.4 of 461 [RFC5296]. In this document, some new TLV(s) which may be present in 462 the EAP-Initiate or EAP-Finish messages are defined as below: 464 Sequence number - This is a TV payload. The type is TBD. 466 ERP/AAK-Key - This is a TLV payload. The type is TBD. 468 The format of sub-TLV attributes that may be present in the EAP- 469 Initiate or EAP-Finish messages is: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Type | Length | Value ... 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 The following types are defined in this document: 479 pRK Lifetime: This is a TV payload. The type of this sub-TLV is 480 TBD. 482 pMSK Lifetime: This is a TV payload. The type of this sub-TLV is 483 TBD. 485 List of Cryptosuites: This is a TLV payload. The type of this 486 sub-TLV is TBD. 488 6. Lower Layer Considerations 490 Similar to ERP, some lower layer specifications may need to be 491 revised to support ERP/AAK; refer to section 6 of [RFC5296] for 492 additional guidance. 494 7. AAA Transport Considerations 496 AAA transport of ERP/AAK messages is the same as AAA transport of the 497 ERP message [RFC5296]. In addition, the document requires AAA 498 transport of the ERP/AAK keying materials delivered by the ERP/AAK 499 server to the CAP. Hence, a new Diameter ERP/AAK application message 500 should be specified to transport the keying materials. 502 8. Security Considerations 504 TBD. 506 9. IANA Considerations 508 New TLV types: 510 NAS-Identifier 512 Sequence number 514 ERP/AAK-Key 516 New sub-TLV types: 518 NAS-Identifier 520 pRK Lifetime 522 pMSK Lifetime 524 List of Cryptosuites 526 10. References 528 10.1. Normative References 530 [RFC2119] Bradner, S., "Key words for use in 531 RFCs to Indicate Requirement Levels", 532 BCP 14, RFC 2119, March 1997. 534 [RFC5296] Narayanan, V. and L. Dondeti, "EAP 535 Extensions for EAP Re-authentication 536 Protocol (ERP)", RFC 5296, 537 August 2008. 539 10.2. Informative References 541 [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, 542 "Diameter Attribute-Value Pairs for 543 Cryptographic Key Transport", 544 draft-ietf-dime-local-keytran-03 (work 545 in progress), May 2010. 547 [RFC3588] Calhoun, P., Loughney, J., Guttman, 548 E., Zorn, G., and J. Arkko, "Diameter 549 Base Protocol", RFC 3588, 550 September 2003. 552 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 553 Carlson, J., and H. Levkowetz, 554 "Extensible Authentication Protocol 555 (EAP)", RFC 3748, June 2004. 557 [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, 558 "Extensible Authentication Protocol 559 (EAP) Early Authentication Problem 560 Statement", RFC 5836, April 2010. 562 Authors' Addresses 564 Zhen Cao 565 China Mobile 566 53A Xibianmennei Ave., Xuanwu District 567 Beijing, Beijing 100053 568 P.R. China 570 EMail: zehn.cao@gmail.com 572 Hui Deng 573 China Mobile 574 53A Xibianmennei Ave., Xuanwu District 575 Beijing, Beijing 100053 576 P.R. China 578 EMail: denghui02@gmail.com 580 Yungui Wang 581 Huawei Technologies Co., Ltd. 582 Floor 10, HuiHong Mansion, No.91 BaiXia Rd. 583 Nanjing, Jiangsu 210001 584 P.R. China 586 Phone: +86 25 84565893 587 EMail: w52006@huawei.com 589 Qin Wu 590 Huawei Technologies Co., Ltd. 591 Floor 12, HuiHong Mansion, No.91 BaiXia Rd. 592 Nanjing, Jiangsu 210001 593 P.R. China 595 Phone: +86 25 84565892 596 EMail: sunseawq@huawei.com 597 Glen Zorn (editor) 598 Network Zen 599 1463 East Republican Street 600 #358 601 Seattle, Washington 98112 602 USA 604 EMail: gwz@net-zen.net