idnits 2.17.1 draft-ietf-hokey-erp-aak-00.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 (April 9, 2010) is 5130 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-02 -- 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: October 11, 2010 Y. Wang 6 Q. Wu 7 Huawei Technologies Co., Ltd. 8 G. Zorn, Ed. 9 Network Zen 10 April 9, 2010 12 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory 13 Keying 14 draft-ietf-hokey-erp-aak-00 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 October 11, 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 . . . . . . . . . . . . . . . . . . . . 6 73 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 7 74 5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 7 75 5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 8 76 5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 9 77 5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 11 78 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 12 79 7. AAA Transport Consideration . . . . . . . . . . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 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) [I-D.ietf-hokey-preauth-ps] 100 is a method by which cryptographic keying material may be established 101 prior to handover upon one or more candidate attachment points 102 (CAPs). AAK 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 121 Authentication, Authorization and Accounting [RFC3588] 123 CAP 124 Candidate Attachment Point [I-D.ietf-hokey-preauth-ps] 126 EA 128 Abbreviation for "ERP/AAK"; used in figures 130 ERP/AAK 131 EAP Re-authentication Protocol Extensions for Authenticated 132 Anticipatory Keying 134 MH 135 Mobile Host 137 SAP 138 Serving Attachment Point [I-D.ietf-hokey-preauth-ps] 140 3. ERP/AAK Overview 142 ERP/AAK is intended to allow the establishment of cryptographic 143 keying materials on one or more Candidate Attachment Points prior to 144 the arrival of the MH at the Candidate Access Network (CAN). The 145 document also specifies a method by which the SAP may send the 146 identities of neighboring attachment points to the peer in the EAP- 147 Initiate/Re-auth-Start message. 149 It is assumed that the peer has previously completed full EAP 150 authentication. Figure 1 shows the general protocol exchange by 151 which the keying material is established on the CAP(s). 153 +------+ +-----+ +-----+ +-----+ +-----------+ 154 | Peer | | SAP | |CAP1 | |CAPx | | EA Server | 155 +--+---+ +--+--+ +--+--+ +--+--+ +-----+-----+ 156 | | | | | 157 1. | [EAP-Initiate/ | | | 158 | Re-auth-start | | | 159 | (E-flag) | | | | 160 |<----------| | | | 161 | | | | | 162 2. | EAP-Initiate/ | | | 163 | Re-auth | | | | 164 | (E-flag) | | | | 165 |---------->| | | | 166 3. | | AAA (EAP-Initiate/Re-auth(E-flag))| 167 | |---------------------------------->| 168 | | | | | 169 | | | | +---------+---------+ 170 | | | | | CA authorized & | 171 4. | | | | | authenticated; | 172 | | | | | EA keying | 173 | | | | | materials derived | 174 | | | | +---------+---------+ 175 | | | | | 176 5. | | | AAA (pMSK) | 177 | | | |<----------->| 178 | | |<---------------------->| 179 | | | | | 180 6. | | AAA (EAP-Finish/Re-auth(E-flag)) | 181 | |<----------------------------------| 182 | | | | | 183 7. | EAP-Finish/ | | | 184 | Re-auth(E-flag) | | | 185 |<----------| | | | 186 | | | | | 188 Figure 1: ERP/AAK Operation 190 ERP/AAK re-uses the packet format defined by ERP, but specifies a new 191 flag to differentiate EAP early-authentication from EAP re- 192 authentication. The peer initiates ERP/AAK itself, or does so in 193 response to an EAP-Initiate/Re-Auth-Start message from the SAP. In 194 this document, it is required that the SAP should support ERP/AAK. 195 If either the peer or the SAP does not support ERP/AAK, it should 196 fall back to full EAP authentication. 198 The peer sends an early-authentication request message (EAP-Initiate/ 199 Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS- 200 Identifier, rIK and sequence number. The realm in the keyName-NAI 201 field is used to locate the peer's ERP/AAK server. The NAS- 202 Identifier is used to identify the CAP(s). The rIK is used to 203 protect the message. The sequence number is used for replay 204 protection. To avoid the same pre-established Master Session Key 205 (pMSK) being derived for multiple CAPs, the sequence number MUST be 206 unique for each CAP. 208 The SAP encapsulates the early-authentication message into a AAA 209 message and sends it to the peer's ERP/AAK server in the realm 210 indicated in the keyName-NAI field. 212 Upon receiving the message, the ERP/AAK server first checks its 213 integrity and freshness, then authenticates and authorizes the CAP(s) 214 presented in the NAS-Identifier TLV(s). After the CAP(s) is 215 authenticated and authorized successfully, the ERP/AAK server derives 216 the pRK and the subsequent pMSK for each CAP. 218 The ERP/AAK server transports the pMSK to the authenticated and 219 authorized CAP(s) via AAA as described in Section 7. After the 220 keying materials are delivered, the ERP/AAK server should determine 221 each CA whether accepts the pMSK and whether the peer could be 222 attached to. 224 At last, the ERP/AAK server sends the early-authentication finish 225 message (EAP-Finish/Re-auth with E-flag) containing the determinate 226 CAP(s) to the peer via the SAP. 228 4. ERP/AAK Key Hierarchy 230 As an optimization of ERP, ERP/AAK uses key hierarchy similar to that 231 of ERP. The EMSK is used to derive the ERP/AAK pre-established Root 232 Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key 233 (pIK) and the pre-established Master Session Key (pMSK) are derived 234 from the pRK. The pMSK is established for the CAP(s) when the peer 235 early authenticates to the network. The pIK is established for the 236 peer to re-authenticate the network after handover. The hierarchy 237 relationship is illustrated in Figure 2, below. 239 DSRK EMSK 240 | | 241 +---+---+---+---+ 242 | | | 243 pRK rRK ... 245 Figure 2 247 The EMSK and DSRK both can be used to derive the pRK. In general, 248 the pRK is derived from the EMSK in case of the peer moving in the 249 home AAA realm and derived from the DRSK in case of the peer moving 250 in the visited AAA realm. The DSRK is delivered from the EAP server 251 to the ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. 252 If the peer has previously authenticated by means of ERP or ERP/AAK, 253 the DSRK SHOULD be directly re-used. 255 pRK 256 | 257 +--------+--------+ 258 | | | 259 pIK pMSK ... 261 Figure 3 263 The pRK is used to derive the pIK and pMSK for the CAP(s). Different 264 sequence numbers for each CAP MUST be used to derive the unique 265 pMSK(s). 267 5. Packet and TLV Extension 269 This section describes the packet and TLV extensions for the ERP/AAK 270 exchange. 272 5.1. EAP-Initiate/Re-auth-Start Packet Extension 274 Figure 4 shows the changed parameters contained in the EAP-Initiate/ 275 Re-auth-Start packet defined in RFC 5296 [RFC5296]. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Code | Identifier | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type |E| Reserved | 1 or more TVs or TLVs ~ 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 4 287 Flags 289 'E' - The E flag is used to indicate early-authentication. 291 Reserved: MUST be set to 0. 293 TVs and TLVs 295 NAS-Identifier: As defined in [RFC5296], it is carried in a TLV 296 payload. It is used by the SAP to advertise the identifier(s) of 297 CAP(s) to the peer. One or more NAS-Identifier TLVs MAY be included 298 in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP 299 discovery. 301 If the EAP-Initiate/Re-auth-Start packet is not supported by the 302 peer, it is discarded silently. 304 5.2. EAP-Initiate/Re-auth Packet Extension 306 Figure 5 illustrates the changed parameters contained in the EAP- 307 Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Code | Identifier | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type |R|x|L|E|Resved | SEQ | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | 1 or more TVs or TLVs ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Cryptosuite | Authentication Tag ~ 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 5 323 Flags 325 'x' - The x flag is reserved. It MUST be set to 0. 327 'E' - The E flag is used to indicate early-authentication. 329 The rest of the 4 bits (Resved) MUST be set to 0 and ignored on 330 reception. 332 SEQ 334 A 16-bit sequence number is used for replay protection. 336 TVs and TLVs 338 keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a 339 TLV payload. The Type is 1. The NAI is variable in length, not 340 exceeding 253 octets. The username part of the NAI is the EMSKname 341 used identify the peer. The realm part of the NAI is the peer's home 342 domain name or the domain to which the peer is currently attached. 343 Exactly one keyName-NAI attribute SHALL be present in an EAP- 344 Initiate/Re-auth packet. 346 NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a 347 TLV payload. It is used to indicate the identifier of a CAP. One or 348 more NAS-Identifier may be included in the EAP-Initiate/Re-auth 349 packet. 351 Sequence number: It is carried in a TV payload. The Type is TBD 352 (which is lower than 128). It is used in the derivation of the pMSK 353 for each CAP to avoid multiple CAP using the same pMSK. Each NAS- 354 Identifier in the packet MUST be associated with a unique sequence 355 number. 357 Cryptosuite 359 This field indicates the integrity algorithm used for ERP/AAK. Key 360 lengths and output lengths are either indicated or are obvious from 361 the cryptosuite name. We specify some cryptosuites below: 363 0 RESERVED 365 1 HMAC-SHA256-64 367 2 HMAC-SHA256-128 369 3 HMAC-SHA256-256 371 HMAC-SHA256-128 is mandatory to implement and should be enabled in 372 the default configuration. 374 Authentication Tag 376 This field contains the integrity checksum over the ERP/AAK packet, 377 excluding the authentication tag field itself. The length of the 378 field is indicated by the Cryptosuite. 380 If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is 381 discarded silently. 383 5.3. EAP-Finish/Re-auth extension 385 Figure 6 shows the changed parameters contained in the EAP-Finish/ 386 Re-auth packet defined in [RFC5296]. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Code | Identifier | Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type |R|x|L|E|Resved | SEQ | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | 1 or more TVs or TLVs ~ 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Cryptosuite | Authentication Tag ~ 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 6 402 Flags 404 'x' - The x flag is reserved. It MUST be set to 0. 406 'E' - The E flag is used to indicate early-authentication. 408 The rest of the 4 bits (Resved) MUST be set to 0 and ignored on 409 reception. 411 SEQ 413 A 16-bit sequence number is used for replay protection. 415 TVs and TLVs 417 keyName-NAI: As defined in[RFC5296], this is carried in a TLV 418 payload. The Type is 1. The NAI is variable in length, not 419 exceeding 253 octets. The realm part of the NAI is the home domain 420 name. Exactly one keyName-NAI attribute SHALL be present in an EAP- 421 Finish/Re-auth packet. 423 ERP/AAK-Key: It is carried in a TLV payload for the key container. 424 The type is TBD. One or more than one ERP/AAK-key may be present in 425 an EAP-Finish/Re-auth packet. 427 ERP/AAK-Key ::= 428 { sub-TLV: NAS-Identifier } 429 { sub-TLV: pMSK-lifetime } 430 { sub-TLV: pRK-lifetime } 431 { sub-TLV: Cryptosuites } 433 NAS-Identifier: It is carried in a sub-TLV payload. It is used to 434 indicate the identifier of candidate authenticator. There exactly 435 one instance of the NAS-Identifier TLV MUST be present in the ERP/ 436 AAK-Key TLV. 438 pMSK-lifetime: It is carried in a sub-TLV payload. The Type is 439 TBD. The value field is a 32-bit field and contains the lifetime 440 of the pMSK in seconds. If the 'L' flag is set, the pMSK Lifetime 441 attribute SHOULD be present. 443 pRK-lifetime: It is carried in a sub-TLV payload. The Type is 444 TBD. The value field is a 32-bit field and contains the lifetime 445 of the pRK in seconds. If the 'L' flag is set, the pRK Lifetime 446 attribute SHOULD be present. 448 List of Cryptosuites: This is a sub-TLV payload. The Type is TBD. 449 The value field contains a list of cryptosuites, each 1 octet in 450 length. The allowed cryptosuite values are as specified in 451 Section 5.2, above. The server SHOULD include this attribute if 452 the cryptosuite used in the EAP-Initiate/Re-auth message was not 453 acceptable and the message is being rejected. The server MAY 454 include this attribute in other cases. The server MAY use this 455 attribute to signal to the peer about its cryptographic algorithm 456 capabilities. 458 Cryptosuite 460 This field indicates the integrity algorithm and PRF used for ERP/ 461 AAK. Key lengths and output lengths are either indicated or are 462 obvious from the cryptosuite name. 464 Authentication Tag 466 This field contains the integrity checksum over the ERP/AAK packet, 467 excluding the authentication tag field itself. The length of the 468 field is indicated by the Cryptosuite. 470 5.4. TV/TLV and sub-TLV Attributes 472 The TV and TLV attributes are the same specified as section 5.3.4 of 473 [RFC5296]. In this document, some new TLV(s) which may be present in 474 the EAP-Initiate or EAP-Finish messages are defined as below: 476 Sequence number - This is a TV payload. The type is TBD. 478 ERP/AAK-Key - This is a TLV payload. The type is TBD. 480 The format of sub-TLV attributes that may be present in the EAP- 481 Initiate or EAP-Finish messages is: 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 | Type | Length | Value ... 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 The following types are defined in this document: 491 pRK Lifetime: This is a TV payload. The type of this sub-TLV is 492 TBD. 494 pMSK Lifetime: This is a TV payload. The type of this sub-TLV is 495 TBD. 497 List of Cryptosuites: This is a TLV payload. The type of this 498 sub-TLV is TBD. 500 6. Lower Layer Considerations 502 Similar to ERP, the lower layer specifications may need to be revised 503 to support ERP/AAK. Refer to section 6 of [RFC5296] for additional 504 guidance. 506 7. AAA Transport Consideration 508 AAA transport of ERP/AAK message is the same as AAA transport of the 509 ERP message specified ERP [RFC5296]. In addition, the document 510 requires AAA transport of the ERP/AAK keying materials delivered by 511 the ERP/AAK server to the CAP. Hence, a new Diameter ERP/AAK 512 application message should be specified to transport the keying 513 materials. 515 8. Security Considerations 517 TBD. 519 9. IANA Considerations 521 New TLV types: 523 NAS-Identifier 525 Sequence number 527 ERP/AAK-Key 529 New sub-TLV types: 531 NAS-Identifier 533 pRK Lifetime 535 pMSK Lifetime 537 List of Cryptosuites 539 10. References 541 10.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in 544 RFCs to Indicate Requirement Levels", 545 BCP 14, RFC 2119, March 1997. 547 [RFC5296] Narayanan, V. and L. Dondeti, "EAP 548 Extensions for EAP Re-authentication 549 Protocol (ERP)", RFC 5296, 550 August 2008. 552 10.2. Informative References 554 [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, 555 "Diameter Attribute-Value Pairs for 556 Cryptographic Key Transport", 557 draft-ietf-dime-local-keytran-02 (work 558 in progress), March 2010. 560 [I-D.ietf-hokey-preauth-ps] Ohba, Y., Wu, Q., and G. Zorn, 561 "Extensible Authentication Protocol 562 (EAP) Early Authentication Problem 563 Statement", 564 draft-ietf-hokey-preauth-ps-12 (work 565 in progress), December 2009. 567 [RFC3588] Calhoun, P., Loughney, J., Guttman, 568 E., Zorn, G., and J. Arkko, "Diameter 569 Base Protocol", RFC 3588, 570 September 2003. 572 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 573 Carlson, J., and H. Levkowetz, 574 "Extensible Authentication Protocol 575 (EAP)", RFC 3748, June 2004. 577 Authors' Addresses 579 Zhen Cao 580 China Mobile 581 53A Xibianmennei Ave., Xuanwu District 582 Beijing, Beijing 100053 583 P.R. China 585 EMail: caozhen@chinamobile.com 587 Hui Deng 588 China Mobile 589 53A Xibianmennei Ave., Xuanwu District 590 Beijing, Beijing 100053 591 P.R. China 593 EMail: denghui02@gmail.com 595 Yungui Wang 596 Huawei Technologies Co., Ltd. 597 Floor 10, HuiHong Mansion, No.91 BaiXia Rd. 598 Nanjing, Jiangsu 210001 599 P.R. China 601 Phone: +86 25 84565893 602 EMail: w52006@huawei.com 604 Qin Wu 605 Huawei Technologies Co., Ltd. 606 Floor 12, HuiHong Mansion, No.91 BaiXia Rd. 607 Nanjing, Jiangsu 210001 608 P.R. China 610 Phone: +86 25 84565892 611 EMail: sunseawq@huawei.com 612 Glen Zorn (editor) 613 Network Zen 614 1463 East Republican Street 615 #358 616 Seattle, Washington 98112 617 USA 619 EMail: gwz@net-zen.net