idnits 2.17.1 draft-kamath-pppext-peapv0-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 6 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 783 has weird spacing: '...imed to perta...' == Line 827 has weird spacing: '...>, and expir...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 October 2002) is 7851 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE 8021X' is mentioned on line 323, but not defined == Unused Reference: 'RFC1661' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC2284' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'IEEE80211' is defined on line 349, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-02 ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group Vivek Kamath 3 INTERNET-DRAFT Ashwin Palekar 4 Category: Informational Mark Wodrich 5 Microsoft 6 25 October 2002 8 Microsoft's PEAP version 0 (Implementation in Windows XP SP1) 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 32 Abstract 34 This specification documents the implementation of PEAP supported in 35 Windows XP SP1. This implementation utilizes a version number of zero 36 (0) and supports acknowledged and protected success and failure 37 indications, using the EAP Extensions method, Type 33. 39 Table of Contents 41 1. Introduction .......................................... 3 42 1.1 EAP encapsulation ............................... 3 43 1.2 Version field ................................... 3 44 1.3 EAP Extensions method ........................... 4 45 2. Details of EAP extensions method ...................... 4 46 2.1 Extensions Request Packet ....................... 4 47 2.2 Extensions Response Packet ...................... 5 48 2.3 AVP format ...................................... 6 49 3. Security considerations ............................. 7 50 3.1 Authentication and integrity protection ......... 7 51 3.2 Outcomes ........................................ 7 52 4. Normative references ................................ 8 53 5. Informative references .............................. 9 54 Appendix A - Examples ........................................ 10 55 Acknowledgments .............................................. 18 56 Author's Addresses ........................................... 18 57 Intellectual Property Statement .............................. 18 58 Full Copyright Statement ..................................... 19 59 1. Introduction 61 Microsoft's Windows XP SP1 implementation of PEAP version 0 differs in 62 the following ways from the protocol specified in [PEAP]. 64 Version field 65 EAP encapsulation 66 Acknowledged and protected success and failure using EAP extensions method 68 PEAP protocol [PEAP] supports versioning and hence servers and clients can 69 support multiple versions of the protocol. [PEAP] is currently at version 1. 70 Each of these differences is explained in the sections that follow. 72 1.1. EAP encapsulation 74 The [PEAP] specification requires that EAP packets be tunneled within a 75 TLS channel in their entirety. However, the Windows XP SP1 76 implementation of PEAP does not include an EAP header on packets sent 77 within the TLS channel, except for EAP Extension packets (Type 33), 78 where the complete header is sent. As a result, for EAP Types other 79 than 33, the Code, Identifier, and Length fields are not sent, but 80 rather EAP packets sent within the PEAP tunnel begin with the Type 81 field. 83 While the Code, Identifier and Length fields are not sent over the wire, 84 they are reconstructed at the receiver prior to EAP processing. For 85 example, the Code and Identifier fields of the tunneled EAP packet are 86 assumed to be the same as the equivalent fields within the outer EAP 87 header, and the Length field of the tunneled EAP packet is derived from 88 the Length field of the PEAP packet. This has the following 89 implications: 91 [a] The Code field of the tunneled EAP packet is assumed to be the same 92 as the Code field of the PEAP packet. This may not always be the 93 case; for example, an EAP Success or Failure packet (Code 3 and 4) 94 may be tunneled within a PEAP Request packet (Code 1). This means 95 that the Windows XP SP1 implementation of PEAP is incapable of 96 tunneling arbitrary EAP packets. 98 [b] Since the full EAP header is sent for the EAP Extensions type (Type 99 33), but not for other Types, it is difficult for the 100 implementation to distinguish an Extensions Request (Code 1) from 101 an EAP Type 1 (Identity) Request packet. In practice, this implies 102 that the Windows XP SP1 PEAP implementation can only support 103 authentication using a single EAP method per session. 105 1.2. Version Field 107 [PEAP] is currently a work-in-progress. In order to allow for backward 108 compatibility once the final specification of PEAP is completed, a 109 version field of zero (0) is used, rather than the value of one (1) 110 required for conformant implementations as specified in [PEAP]. 112 Note that use of distinct version numbers enables backward compatibility 113 once the final specification of PEAP is complete. Version negotiation 114 takes place at the start of the conversation, with the authenticator 115 indicating its highest supported version. The peer then responds with 116 the highest version it supports. The conversation will then occur using 117 the highest version supported by both parties. This behavior is 118 illustrated in the last example in Appendix A. 120 1.3. EAP extensions method 122 The [PEAP] termination mechanism (sending an encrypted EAP Success or 123 EAP Failure packet) does not function correctly with Authenticators 124 implementing [IEEE8021X]. Since IEEE 802.1X authenticators "manufacture" 125 a clear-text EAP Success based on receipt of a RADIUS Access-Accept, or 126 a clear-text EAP Failure based on receipt of a RADIUS Access-Reject, 127 unless an acknowledged success/failure indication is used, the PEAP 128 Supplicant may never receive a protected success/failure indication. 129 This leaves the PEAP Supplicant open to attack. As a result, the Windows 130 XP SP1 PEAP implementation supports acknowledged and protected 131 success/failure indications, using the EAP Extensions method (Type 33). 133 2. Details of EAP extensions method 135 The packet formats for the EAP Extensions method (type 33) follow. 137 2.1. Extensions Request Packet 139 A summary of the Extensions Request packet format is shown below. The 140 fields are transmitted from left to right. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Code | Identifier | Length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type | Data.... 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Code 152 1 154 Identifier 156 The Identifier field is one octet and aids in matching responses with 157 requests. The Identifier field MUST be changed on each Request 158 packet. 160 Length 162 The Length field is two octets and indicates the length of the EAP 163 packet including the Code, Identifier, Length, Type, and Data fields. 165 Type 167 33 - EAP Extensions 169 Data 170 The Data field is of variable length, and contains Attribute-Value 171 Pairs (AVPs). 173 2.2. Extensions Response Packet 175 A summary of the Extensions Response packet format is shown below. The 176 fields are transmitted from left to right. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Code | Identifier | Length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Data.... 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Code 188 2 190 Identifier 192 The Identifier field is one octet and aids in matching responses with 193 requests. The Identifier field MUST be changed on each Request 194 packet. 196 Length 198 The Length field is two octets and indicates the length of the EAP 199 packet including the Code, Identifier, Length, Type, and Data fields. 201 Type 202 33 - EAP Extensions 204 Data 205 The Data field is of variable length, and contains Attribute-Value 206 Pairs (AVPs). 208 2.3. AVP format 210 Extensions AVPs are defined as follows: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |M|R| AVP Type | Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Value... 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 M 222 0 - Non-mandatory AVP 223 1 - Mandatory AVP 225 R 227 Reserved, set to zero (0) 229 AVP Type 231 A 14-bit field, denoting the attribute type. Allocated AVP Types 232 include: 234 0 - Reserved 235 1 - Reserved 236 2 - Reserved 237 3 - Acknowledged Result 239 Length 241 The length of the value field in octets. 243 Value 245 The value of the attribute. 247 2.3.1. Result AVP 249 The Result AVP provides support for acknowledged Success and Failure 250 within EAP. It is defined as follows: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |M|R| AVP Type | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Status | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 M 262 1 - Mandatory AVP 264 R 266 Reserved, set to zero (0) 268 AVP Type 270 3 - Result 272 Length 274 2 276 Status 278 The status field is two octets. Values include: 280 1 - Success 281 2 - Failure 283 3. Security considerations 285 3.1. Authentication and integrity protection 287 The EAP Extension method is presumed to run before or after an EAP 288 method that supports mutual authentication and establishes a protected 289 channel. PEAP is such a method, and as a result the acknowledged 290 Success and Failure messages are always protected. 292 Note however, that [IEEE8021X] manufactures clear-text EAP Success and 293 EAP Failure messages, so that even though the Result AVP will be 294 protected, this will be followed by a clear-text EAP Success or EAP 295 Failure packet. 297 3.2. Outcomes 299 Within the Microsoft PEAP Version 0 implementation, support for the EAP 300 Extensions method and the Result AVP is required. The only outcome which 301 should be considered a successful authentication is when an EAP Request 302 of Type=Extensions with Result AVP of Status=Success is answered by an 303 EAP Response of Type=Extensions with Result AVP of Status=Success. All 304 other combinations (Extensions Success, Extensions Failure), (Extensions 305 Failure, Extensions Success), (Extensions Failure, Extensions Failure), 306 (No extensions exchange) should be considered failed authentications, 307 both by the EAP Peer and EAP Server. This is true regardless of whether 308 an EAP Success or EAP Failure packet is subsequently sent, either in 309 clear-text or within the PEAP tunnel. Because the EAP Extensions method 310 is protected within the PEAP channel, its messages cannot be spoofed, 311 whereas clear-text Success and Failure messages can be sent by an 312 attacker. 314 While the [PEAP] specification permits a tunneled EAP Success or Failure 315 packet to be sent as the last message, this is not possible within the 316 Windows XP SP1 implementation, which can only tunnel EAP packets of 317 codes Request or Response within PEAP. Since the [IEEE8021X] 318 specification requires that the switch or access point "manufacture" a 319 clear-text EAP Success packet when an Access-Accept is received from the 320 backend authentication server, and a clear-text EAP Failure packet when 321 an Access-Reject is received. As a result, a tunneled EAP Success or 322 Failure packet, if sent as the last message, would be thrown away by 323 conformant [IEEE 8021X] implementations, and replaced with clear-text. 324 This problem is being addressed within the IEEE 802.1aa revision to IEEE 325 802.1X, but the fix may take a while to move through the standards 326 process and be implemented in commercial products. 328 4. Normative references 330 [PEAP] Andersson, H., et al. "Protected EAP Protocol", Internet 331 draft (work in progress), draft-josefsson-pppext-eap-tls- 332 eap-02.txt, February 2002. 334 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 335 STD 51, RFC 1661, July 1994. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 341 Protocol (EAP)", RFC 2284, March 1998. 343 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 344 Port based Network Access Control, IEEE Std 802.1X-2001, 345 June 2001. 347 5. Informative references 349 [IEEE80211] Information technology - Telecommunications and 350 information exchange between systems - Local and 351 metropolitan area networks - Specific Requirements Part 352 11: Wireless LAN Medium Access Control (MAC) and 353 Physical Layer (PHY) Specifications, IEEE Std. 354 802.11-1999, 1999. 356 Appendix A - Examples 358 In the case where an identity exchange occurs within 359 PEAP Part 1, the conversation will appear as follows: 361 Authenticating Peer Authenticator 362 ------------------- ------------- 363 <- EAP-Request/ 364 Identity 365 EAP-Response/ 366 Identity (MyID) -> 367 <- EAP-Request/ 368 EAP-Type=PEAP, V=0 369 (PEAP Start, S bit set) 371 EAP-Response/ 372 EAP-Type=PEAP, V=0 373 (TLS client_hello)-> 374 <- EAP-Request/ 375 EAP-Type=PEAP, V=0 376 (TLS server_hello, 377 TLS certificate, 378 [TLS server_key_exchange,] 379 [TLS certificate_request,] 380 TLS server_hello_done) 381 EAP-Response/ 382 EAP-Type=PEAP, V=0 383 ([TLS certificate,] 384 TLS client_key_exchange, 385 [TLS certificate_verify,] 386 TLS change_cipher_spec, 387 TLS finished) -> 388 <- EAP-Request/ 389 EAP-Type=PEAP, V=0 390 (TLS change_cipher_spec, 391 TLS finished) 392 EAP-Response/ 393 EAP-Type=PEAP -> 395 TLS channel established 396 (messages sent within the TLS channel) 398 <- EAP-Request/ 399 Identity 400 EAP-Response/ 401 Identity (MyID) -> 402 <- EAP-Request/ 403 EAP-Type=X 405 EAP-Response/ 406 EAP-Type=X or NAK -> 408 <- EAP-Request/ 409 EAP-Type=X 410 EAP-Response/ 411 EAP-Type=X -> 412 <- EAP-Request/ 413 EAP-Type=Extensions 414 Result=Success 415 EAP-Response/ 416 EAP-Type=Extensions 417 Result=Success -> 419 TLS channel torn down 420 (messages sent in clear-text) 422 <- EAP-Success 424 In the case where the PEAP fragmentation is required, the conversation 425 will appear as follows: 427 Authenticating Peer Authenticator 428 ------------------- ------------- 429 <- EAP-Request/ 430 Identity 431 EAP-Response/ 432 Identity (MyID) -> 433 <- EAP-Request/ 434 EAP-Type=PEAP, V=0 435 (PEAP Start, S bit set) 437 EAP-Response/ 438 EAP-Type=PEAP, V=0 439 (TLS client_hello)-> 440 <- EAP-Request/ 441 EAP-Type=PEAP, V=0 442 (TLS server_hello, 443 TLS certificate, 444 [TLS server_key_exchange,] 445 [TLS certificate_request,] 446 TLS server_hello_done) 447 (Fragment 1: L, M bits set) 448 EAP-Response/ 449 EAP-Type=PEAP, V=0 -> 450 <- EAP-Request/ 451 EAP-Type=PEAP, V=0 452 (Fragment 2: M bit set) 454 EAP-Response/ 455 EAP-Type=PEAP, V=0 -> 456 <- EAP-Request/ 457 EAP-Type=PEAP, V=0 458 (Fragment 3) 459 EAP-Response/ 460 EAP-Type=PEAP, V=0 461 ([TLS certificate,] 462 TLS client_key_exchange, 463 [TLS certificate_verify,] 464 TLS change_cipher_spec, 465 TLS finished) 466 (Fragment 1: L, M bits set)-> 468 <- EAP-Request/ 469 EAP-Type=PEAP, V=0 470 EAP-Response/ 471 EAP-Type=PEAP, V=0 472 (Fragment 2)-> 473 <- EAP-Request/ 474 EAP-Type=PEAP, V=0 475 (TLS change_cipher_spec, 476 TLS finished) 478 EAP-Response/ 479 EAP-Type=PEAP, V=0 -> 481 TLS channel established 482 (messages sent within the TLS channel) 484 <- EAP-Request/ 485 Identity 486 EAP-Response/ 487 Identity (MyID) -> 488 <- EAP-Request/ 489 EAP-Type=X 490 EAP-Response/ 491 EAP-Type=X or NAK -> 493 <- EAP-Request/ 494 EAP-Type=X 495 EAP-Response/ 496 EAP-Type=X -> 497 <- EAP-Request/ 498 EAP-Type=Extensions 499 Result=Success 500 EAP-Response/ 501 EAP-Type=Extensions 502 Result=Success -> 504 TLS channel torn down 505 (messages sent in clear-text) 507 <- EAP-Success 509 In the case where the server authenticates to the client 510 successfully in PEAP Part 1, but the client fails to authenticate 511 to the server in PEAP Part 2, the conversation will appear as follows: 513 Authenticating Peer Authenticator 514 ------------------- ------------- 515 <- EAP-Request/ 516 Identity 517 EAP-Response/ 518 Identity (MyID) -> 519 <- EAP-Request/ 520 EAP-Type=PEAP, V=0 521 (PEAP Start, S bit set) 522 EAP-Response/ 523 EAP-Type=PEAP, V=0 524 (TLS client_hello)-> 525 <- EAP-Request/ 526 EAP-Type=PEAP, V=0 527 (TLS server_hello, 528 TLS certificate, 529 [TLS server_key_exchange,] 530 [TLS certificate_request,] 531 TLS server_hello_done) 532 EAP-Response/ 533 EAP-Type=PEAP, V=0 534 ([TLS certificate,] 535 TLS client_key_exchange, 536 [TLS certificate_verify,] 537 TLS change_cipher_spec, 538 TLS finished) -> 539 <- EAP-Request/ 540 EAP-Type=PEAP, V=0 541 (TLS change_cipher_spec, 542 TLS finished) 544 EAP-Response/ 545 EAP-Type=PEAP, V=0 -> 547 TLS channel established 548 (messages sent within the TLS channel) 549 <- EAP-Request/ 550 Identity 551 EAP-Response/ 552 Identity (MyID) -> 553 <- EAP-Request/ 554 EAP-Type=X 555 EAP-Response/ 556 EAP-Type=X or NAK -> 558 <- EAP-Request/ 559 EAP-Type=X 560 EAP-Response/ 561 EAP-Type=X -> 562 <- EAP-Request/ 563 EAP-Type=Extensions 564 Result=Failure 565 EAP-Response/ 566 EAP-Type=Extensions 567 Result=Failure -> 569 (TLS session cache entry flushed) 570 TLS channel torn down 571 (messages sent in clear-text) 573 <- EAP-Failure 575 In the case where server authentication is unsuccessful in PEAP Part 1, 576 the conversation will appear as follows: 578 Authenticating Peer Authenticator 579 ------------------- ------------- 580 <- EAP-Request/ 581 Identity 582 EAP-Response/ 583 Identity (MyID) -> 584 <- EAP-Request/ 585 EAP-Type=PEAP, V=0 586 (PEAP Start) 587 EAP-Response/ 588 EAP-Type=PEAP, V=0 589 (TLS client_hello)-> 590 <- EAP-Request/ 591 EAP-Type=PEAP, V=0 592 (TLS server_hello, 593 TLS certificate, 594 [TLS server_key_exchange,] 595 TLS server_hello_done) 596 EAP-Response/ 597 EAP-Type=PEAP, V=0 598 (TLS client_key_exchange, 599 [TLS certificate_verify,] 600 TLS change_cipher_spec, 601 TLS finished) -> 602 <- EAP-Request/ 603 EAP-Type=PEAP, V=0 604 (TLS change_cipher_spec, 605 TLS finished) 606 EAP-Response/ 607 EAP-Type=PEAP, V=0 608 (TLS change_cipher_spec, 609 TLS finished) 611 <- EAP-Request/ 612 EAP-Type=PEAP, V=0 613 EAP-Response/ 614 EAP-Type=PEAP, V=0 615 (TLS Alert message) -> 616 <- EAP-Failure 617 (TLS session cache entry flushed) 619 In the case where a previously established session is being resumed, 620 the EAP server supports TLS session cache 621 flushing for unsuccessful PEAP Part 2 authentications and both sides 622 authenticate successfully, the conversation 623 will appear as follows: 625 Authenticating Peer Authenticator 626 ------------------- ------------- 627 <- EAP-Request/ 628 Identity 629 EAP-Response/ 630 Identity (MyID) -> 631 <- EAP-Request/ 632 EAP-Type=PEAP,V=0 633 (PEAP Start) 634 EAP-Response/ 635 EAP-Type=PEAP, V=0 636 (TLS client_hello)-> 637 <- EAP-Request/ 638 EAP-Type=PEAP, V=0 639 (TLS server_hello, 640 TLS change_cipher_spec 641 TLS finished) 642 EAP-Response/ 643 EAP-Type=PEAP, V=0 644 (TLS change_cipher_spec, 645 TLS finished) -> 646 <- EAP-Request/ 647 EAP-Type=Extensions 648 Result=Success 649 EAP-Response/ 650 EAP-Type=Extensions 651 Result=Success -> 652 TLS channel torn down 653 (messages sent in clear-text) 655 <- EAP-Success 657 In the case where a previously established session is being resumed, and the 658 server authenticates to the client successfully 659 but the client fails to authenticate to the server, the conversation 660 will appear as follows: 662 Authenticating Peer Authenticator 663 ------------------- ------------- 664 <- EAP-Request/ 665 Identity 666 EAP-Response/ 667 Identity (MyID) -> 668 <- EAP-Request/ 669 EAP-Request/ 670 EAP-Type=PEAP, V=0 671 (TLS Start) 672 EAP-Response/ 673 EAP-Type=PEAP, V=0 674 (TLS client_hello) -> 675 <- EAP-Request/ 676 EAP-Type=PEAP, V=0 677 (TLS server_hello, 678 TLS change_cipher_spec, 679 TLS finished) 680 EAP-Response/ 681 EAP-Type=PEAP, V=0 682 (TLS change_cipher_spec, 683 TLS finished) -> 684 <- EAP-Request 685 EAP-Type=PEAP, V=0 686 (TLS Alert message) 687 EAP-Response 688 EAP-Type=PEAP, V=0 -> 689 <- EAP-Failure 690 (TLS session cache entry flushed) 692 In the case where a previously established session is being resumed, 693 and the server authentication is unsuccessful, 694 the conversation will appear as follows: 696 Authenticating Peer Authenticator 697 ------------------- ------------- 698 <- EAP-Request/ 699 Identity 700 EAP-Response/ 701 Identity (MyID) -> 702 <- EAP-Request/ 703 EAP-Request/ 704 EAP-Type=PEAP, V=0 705 (TLS Start) 706 EAP-Response/ 707 EAP-Type=PEAP, V=0 708 (TLS client_hello)-> 709 <- EAP-Request/ 710 EAP-Type=PEAP, V=0 711 (TLS server_hello, 712 TLS change_cipher_spec, 713 TLS finished) 714 EAP-Response/ 715 EAP-Type=PEAP, V=0 716 (TLS change_cipher_spec, 717 TLS finished) 718 <- EAP-Request/ 719 EAP-Type=PEAP, V=0 720 EAP-Response/ 721 EAP-Type=PEAP, V=0 722 (TLS Alert message) -> 723 (TLS session cache entry flushed) 725 <- EAP-Failure 727 In the case where the peer and authenticator have mismatched PEAP versions 728 (e.g. the peer has a pre-standard implementation 729 with version 0, and the authenticator has a Version 1 implementation, 730 but the authentication is unsuccessful, the conversation will occur as follows: 732 Authenticating Peer Authenticator 733 ------------------- ------------- 734 <- EAP-Request/ 735 Identity 736 EAP-Response/ 737 Identity (MyID) -> 738 <- EAP-Request/ 739 EAP-Request/ 740 EAP-Type=PEAP, V=1 741 (TLS Start) 742 EAP-Response/ 743 EAP-Type=PEAP, V=0 744 (TLS client_hello)-> 745 <- EAP-Request/ 746 EAP-Type=PEAP, V=0 747 (TLS server_hello, 748 TLS change_cipher_spec, 749 TLS finished) 750 EAP-Response/ 751 EAP-Type=PEAP, V=0 752 (TLS change_cipher_spec, 753 TLS finished) 754 <- EAP-Request/ 755 EAP-Type=PEAP, V=0 756 EAP-Response/ 757 EAP-Type=PEAP, V=0 758 (TLS Alert message) -> 759 (TLS session cache entry flushed) 761 <- EAP-Failure 763 Acknowledgments 765 Thanks to Narendra Gidwani of Microsoft for useful discussions of this 766 problem space. 768 Author Addresses 770 Vivek Kamath 771 Ashwin Palekar 772 Mark Wodrich 773 Microsoft Corporation 774 One Microsoft Way 775 Redmond, WA 98052 777 Phone: +1 425 882 8080 778 EMail: {vivek, ashwinp, markwo}@microsoft.com 780 Intellectual Property Statement 782 The IETF takes no position regarding the validity or scope of any 783 intellectual property or other rights that might be claimed to pertain 784 to the implementation or use of the technology described in this 785 document or the extent to which any license under such rights might or 786 might not be available; neither does it represent that it has made any 787 effort to identify any such rights. Information on the IETF's 788 procedures with respect to rights in standards-track and standards- 789 related documentation can be found in BCP-11. Copies of claims of 790 rights made available for publication and any assurances of licenses to 791 be made available, or the result of an attempt made to obtain a general 792 license or permission for the use of such proprietary rights by 793 implementors or users of this specification can be obtained from the 794 IETF Secretariat. 796 The IETF invites any interested Party to bring to its attention any 797 copyrights, patents or patent applications, or other proprietary rights 798 which may cover technology that may be required to practice this 799 standard. Please address the information to the IETF Executive 800 Director. 802 Full Copyright Statement 804 Copyright (C) The Internet Society (2002). All Rights Reserved. 805 This document and translations of it may be copied and furnished to 806 others, and derivative works that comment on or otherwise explain it or 807 assist in its implementation may be prepared, copied, published and 808 distributed, in whole or in Part, without restriction of any kind, 809 provided that the above copyright notice and this paragraph are included 810 on all such copies and derivative works. However, this document itself 811 may not be modified in any way, such as by removing the copyright notice 812 or references to the Internet Society or other Internet organizations, 813 except as needed for the purpose of developing Internet standards in 814 which case the procedures for copyrights defined in the Internet 815 Standards process must be followed, or as required to translate it into 816 languages other than English. The limited permissions granted above are 817 perpetual and will not be revoked by the Internet Society or its 818 successors or assigns. This document and the information contained 819 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 820 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 821 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 822 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 823 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 825 Expiration Date 827 This memo is filed as , and expires 828 April 23, 2002.