idnits 2.17.1 draft-josefsson-pppext-eap-tls-eap-04.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 47 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 48 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.) 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 404 has weird spacing: '...ows the clien...' == Line 424 has weird spacing: '...ssionId will ...' == Line 426 has weird spacing: '...ered by the...' == Line 1300 has weird spacing: '... server to sk...' == Line 2209 has weird spacing: '...imed to perta...' == 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In configurations where all users are required to authenticate with PEAP and the first portion of the PEAP conversation is terminated at a local backend authentication server, without routing by proxies, the initial cleartext Identity Request/Response exchange is not needed in order to determine the required authentication method(s) or route the authentication conversation to its destination. As a result, the initial Identity and Request/Response exchange MAY NOT be present, and a subsequent Identity Request/Response exchange MAY occur after the TLS session is established. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 813 -- Looks like a reference, but probably isn't: '2' on line 822 -- Looks like a reference, but probably isn't: '3' on line 826 -- Looks like a reference, but probably isn't: '4' on line 832 -- Looks like a reference, but probably isn't: '5' on line 837 -- Looks like a reference, but probably isn't: '6' on line 843 -- Looks like a reference, but probably isn't: '7' on line 848 == Missing Reference: 'RFC3162' is mentioned on line 1464, but not defined == Unused Reference: 'RFC1321' is defined on line 1535, but no explicit reference was found in the text == Unused Reference: 'RFC1570' is defined on line 1538, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 1541, but no explicit reference was found in the text == Unused Reference: 'RFC1962' is defined on line 1544, but no explicit reference was found in the text == Unused Reference: 'FIPSDES' is defined on line 1594, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 1604, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) == Outdated reference: A later version (-06) exists of draft-ietf-tls-extensions-05 -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) Summary: 7 errors (**), 0 flaws (~~), 19 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group H. Andersson 3 INTERNET-DRAFT S. Josefsson 4 Category: Experimental RSA Security 5 Glen Zorn 6 12 September 2002 Cisco 7 Dan Simon 8 Ashwin Palekar 9 Microsoft 11 Protected EAP Protocol (PEAP) 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet- Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 The Extensible Authentication Protocol (EAP), defined in RFC 2284, 38 provides for support of multiple authentication methods. While EAP was 39 originally created for use with PPP, it has since been adopted for use 40 with IEEE 802.1X "Network Port Authentication". 42 Since its deployment, a number of weaknesses in EAP have become 43 apparent. These include lack of protection of the user identity, 44 notification messages or the EAP negotiation; no standardized mechanism 45 for key exchange; no built-in support for fragmentation and reassembly; 46 no support for acknowledged success/failure indications; and lack of 47 support for fast reconnect. 49 By wrapping the EAP protocol within TLS, Protected EAP (PEAP) addresses 50 these deficiencies. Any EAP method running within PEAP is provided with 51 built-in support for key exchange, session resumption, acknowledged and 52 protected result exchange, and fragmentation and reassembly. 54 Table of Contents 56 1. Introduction .......................................... 3 57 1.1 Requirements language ........................... 4 58 1.2 Terminology ..................................... 5 59 1.3 Operational model ............................... 6 60 2. Protocol overview ..................................... 7 61 2.1 PEAP Part 1 .................................... 8 62 2.2 PEAP Part 2 .................................... 11 63 2.3 Version negotiation ............................ 11 64 2.4 Termination .................................... 12 65 2.5 Error handling ................................. 14 66 2.6 Retry behavior ................................. 15 67 2.7 Session resumption ............................. 15 68 2.8 Fragmentation .................................. 16 69 2.9 Key derivation ................................. 17 70 2.10 Ciphersuite negotiation ........................ 19 71 3. Detailed description of the PEAP protocol ............ 19 72 3.1 PEAP Packet Format ............................. 19 73 3.2 PEAP Request Packet ............................ 21 74 3.3 PEAP Response Packet ........................... 22 75 4. EAP Extensions method ................................ 24 76 4.1 Extension Request packet ....................... 24 77 4.2 Extension Response packet ...................... 25 78 4.3 Extension AVP format ........................... 26 79 4.4 Result AVP ..................................... 27 80 5. Security considerations .............................. 27 81 5.1 Authentication and integrity protection ........ 27 82 5.2 Method negotiation ............................. 28 83 5.3 TLS session cache handling ..................... 28 84 5.4 Certificate revocation ......................... 29 85 5.5 Separation of EAP server and PPP authenticator.. 30 86 5.6 Separation of PEAP Part 1 and Part 2 Servers ... 30 87 5.7 Identity verification .......................... 32 88 6. Normative references ................................ 33 89 7. Informative references .............................. 34 90 Appendix A - Examples ........................................ 35 91 Acknowledgments .............................................. 46 92 Author's Addresses ........................................... 46 93 Intellectual Property Statement .............................. 47 94 Full Copyright Statement ..................................... 47 95 1. Introduction 97 The Extensible Authentication Protocol (EAP), described in [RFC2284], 98 provides a standard mechanism for support of multiple authentication 99 methods. Through the use of EAP, support for a number of authentication 100 schemes may be added, including smart cards, Kerberos, Public Key, One 101 Time Passwords, and others. 103 EAP was developed or use on wired networks, where physical security was 104 presumed. EAP over PPP, defined in [RFC2284], is typically deployed with 105 leased lines or modem connections, requiring an attacker to gain access 106 to the telephone network in order to snoop on the conversation or inject 107 packets. [IEEE8021X] defines EAP over IEEE 802 local area networks 108 (EAPOL), presuming the existence of switched media; in order to snoop or 109 inject packets, an attacker would need to gain administrative access to 110 the switch. Due to the presumption of physical security, facilities for 111 protection of the EAP conversation were not provided. 113 Where an attacker can easily gain access to the medium (such as on a 114 wireless network or where EAP is run over IP), the presumption of 115 physical security is no longer valid. Since the EAP method negotiation 116 is unprotected, an attacker can inject packets in order to cause the 117 negotiation of a method with lesser security. Denial of service attacks 118 are also possible. Since the initial EAP Identity Request/Response 119 exchange is sent in the clear, an attacker snooping on the conversation 120 can collect user identities for use in subsequent attacks. 122 By initially negotiating a TLS channel, and then conducting the EAP 123 conversation within it, PEAP provides for per-packet encryption, 124 authentication, integrity and replay protection of the EAP conversation. 125 Benefits include: 127 Identity protection 128 By encrypting the identity exchange, and allowing client 129 certificates to be provided after negotiation of the TLS channel, 130 PEAP provides for identity protection. 132 Dictionary attack resistance 133 By conducting the EAP conversation within a TLS channel, PEAP 134 protects EAP methods that might be subject to an offline dictionary 135 attack were they to be conducted in the clear. 137 Protected negotiation 138 Since within PEAP, the EAP conversation is authenticated, integrity 139 and replay protected on a per-packet basis, the EAP method 140 negotiation that occurs within PEAP is protected, as are error 141 messages sent within the TLS channel (TLS alerts or EAP 142 Notification packets). 144 Header protection 145 Within PEAP, the EAP conversation is conducted within a TLS 146 channel. As a result, the EAP header is protected against 147 modification. 149 Protected termination 150 By sending success/failure indications within the TLS channel, PEAP 151 provides support for protected termination of the EAP conversation. 152 This prevents an attacker from carrying out denial of service 153 attacks by spoofing EAP Failure messages, or fooling the EAP peer 154 into accepting a rogue NAS, by spoofing EAP Success messages. 156 Fragmentation and Reassembly 157 Since EAP does not include support for fragmentation and 158 reassembly, individual methods need to include this capability. By 159 including support for fragmentation and reassembly within PEAP, 160 methods leveraging PEAP do not need to support this on their own. 162 Fast reconnect 163 Where EAP is used for authentication in wireless networks, the 164 authentication latency is a concern. As a result, it is valuable to 165 be able to do a quick re-authentication on roaming between access 166 points. PEAP supports this capability by leveraging the TLS session 167 resumption facility, and any EAP method running under PEAP can take 168 advantage of it. 170 Proven key management 171 In order to provide keying material for a wide range of link layer 172 ciphersuites, EAP methods need to provide a key hierarchy 173 generating authentication and encryption keys, as well as 174 initialization vectors. Development of a secure key hierarchy is 175 complex, and not easy to generalize for all EAP methods. By 176 relying on the well-reviewed TLS [RFC2246] key derivation method, 177 PEAP provides the required keying material for any EAP method 178 running within it. This frees EAP method developers from taking on 179 the difficult (and error prone) task of designing a key hierarchy 180 for each method. 182 1.1. Requirements language 184 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 185 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 186 described in [RFC2119]. 188 1.2. Terminology 190 This document frequently uses the following terms: 192 Access Point 193 A Network Access Server implementing 802.11. 195 Authenticator 196 The end of the link requiring the authentication. 198 Backend Authentication Server 199 An Authentication Server is an entity that provides an 200 Authentication Service to an NAS. This service verifies from 201 the credentials provided by the peer, the claim of identity 202 made by the peer. 204 EAP server 205 The EAP server is the entity that terminates the EAP 206 conversation with the peer. The EAP server may reside on the 207 NAS, or alternatively within a backend authentication server. 209 Link layer ciphersuite 210 The ciphersuite negotiated for use at the link layer. 212 Master key 213 The key derived between the EAP client and EAP server during 214 the EAP authentication process. 216 Master session key 217 The keys derived from the master key that are subsequently 218 used in generation of the transient session keys for 219 authentication, encryption, and IV-generation. So that the 220 master session keys are usable with any link layer 221 ciphersuite, they are longer than is necessary, and are 222 truncated to fit. 224 NAS Short for "Network Access Server". 226 Peer The other end of the point-to-point link (PPP), point-to-point 227 LAN segment (IEEE 802.1X) or 802.11 wireless link, which is 228 being authenticated by the NAS. In IEEE 802.1X, this end is 229 known as the Supplicant. 231 TLS Ciphersuite 232 The ciphersuite negotiated for protection of the PEAP Part 2 233 conversation. 235 Transient session keys 236 The transient session keys are derived from the master session 237 keys, and are of the appropriate size and type for use with 238 the chosen link layer ciphersuite. 240 1.3. Operational model 242 In EAP, the EAP server may be implemented either within a Network Access 243 Server (NAS) or on a backend authentication server. Where the EAP server 244 resides on a NAS, the NAS is required to implement the desired EAP 245 methods, and therefore needs to be upgraded to support each new EAP 246 method. 248 One of the goals of EAP is to enable development of new authentication 249 methods without requiring deployment of new code on the Network Access 250 Server (NAS). Where a backend authentication server is deployed, the NAS 251 acts as a "passthrough" and need not understand specific EAP methods. 252 This allows new EAP methods to be deployed on the EAP peer and backend 253 authentication server, without the need to upgrade code residing on the 254 NAS. 256 Figure 1 describes the relationship between the EAP peer, NAS and EAP 257 server. As described in the figure, the EAP conversation occurs between 258 the EAP peer and EAP server, "passing through" the NAS. In order for the 259 conversation to proceed in the case where the NAS and EAP server reside 260 on separate machines, the NAS and EAP server need to establish trust 261 beforehand. 263 In PEAP, the conversation between the EAP peer and the EAP server is 264 encrypted, authenticated, integrity and replay protected within a TLS 265 channel, and mutual authentication is required between the EAP peer and 266 the EAP server. 268 As a result, where the NAS acts as a "passthrough" it does not have 269 knowledge of the TLS master secret derived between the EAP Peer and the 270 EAP server. In order to provide keying material for link-layer 271 ciphersuites, the NAS obtains the master session keys, which are derived 272 from the TLS master secret via a one-way function. This enables the NAS 273 and EAP peer to derive keys suitable for encrypting, authenticating and 274 integrity protecting session data. However, the NAS cannot decrypt the 275 PEAP conversation or spoof session resumption, since this requires 276 knowledge of the TLS master secret. 278 +-+-+-+-+-+ +-+-+-+-+-+ 279 | | | | 280 | Link | | Link | 281 | Layer | | Layer | 282 | Cipher- | | Cipher- | 283 | Suite | | Suite | 284 | | | | 285 +-+-+-+-+-+ +-+-+-+-+-+ 286 ^ ^ 287 | | 288 | | 289 | | 290 V V 291 +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ 292 | | EAP | |<======>| | 293 | | Conversation | | | | 294 | EAP |<================================>| EAP | 295 | Peer | (over PPP, | NAS | | Server | 296 | | 802.11,etc.) | |<=======| | 297 | | | | Keys | | 298 | | | | | | 299 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 300 ^ ^ 301 | | 302 | EAP API | EAP API 303 | | 304 V V 305 +-+-+-+-+-+ +-+-+-+-+-+ 306 | | | | 307 | | | | 308 | EAP | | EAP | 309 | Method | | Method | 310 | | | | 311 +-+-+-+-+-+ +-+-+-+-+-+ 313 Figure 1 - Relationship between EAP client, backend authentication 314 server and NAS. 316 2. Protocol overview 318 Protected EAP (PEAP) is comprised of a two-part conversation: 320 [1] In Part 1, a TLS session is negotiated, with server authenticating 321 to the client and optionally the client to the server. The 322 negotiated key is then used to encrypt the rest of the 323 conversation. 325 [2] In Part 2, within the TLS session, a complete EAP conversation is 326 carried out, unless part 1 provided client authentication. 328 In the next two sections, we provide an overview of each of the parts of 329 the PEAP conversation. 331 2.1. PEAP Part 1 333 The PEAP conversation typically begins an optional identity exchange. 334 The authenticator will typically send an EAP-Request/Identity packet to 335 the peer, and the peer will respond with an EAP-Response/Identity packet 336 to the authenticator, containing the peer's userId. Since the initial 337 identity exchange is used primarily to route the EAP conversation to the 338 EAP server, if the EAP server is known in advance (such as when all 339 users authenticate against the same backend server infrastructure and 340 roaming is not supported), or if the identity is otherwise determined 341 (such as from the dialing phone number or client MAC address), then the 342 identity exchange MAY be omitted. 344 Once the optional initial Identity Request/Response exchange is 345 completed, while nominally the EAP conversation occurs between the 346 authenticator and the peer, the authenticator MAY act as a passthrough 347 device, with the EAP packets received from the peer being encapsulated 348 for transmission to a backend authentication server. However, PEAP does 349 not require a backend authentication server; if the authenticator 350 implements PEAP and is provisioned with the appropriate certificates, 351 then it can authenticate local users. In the discussion that follows, 352 we will use the term "EAP server" to denote the ultimate endpoint 353 conversing with the peer. 355 Once having received the peer's Identity, and determined that PEAP 356 authentication is to occur, the EAP server MUST respond with a 357 PEAP/Start packet, which is an EAP-Request packet with EAP-Type=PEAP, 358 the Start (S) bit set, and no data. Assuming that the peer supports 359 PEAP, the PEAP conversation will then begin, with the peer sending an 360 EAP-Response packet with EAP-Type=PEAP. 362 The data field of the EAP-Response packet will encapsulate one or more 363 TLS records in TLS record layer format, containing a TLS client_hello 364 handshake message. The current cipher spec for the TLS records will be 365 TLS_NULL_WITH_NULL_NULL and null compression. This current cipher spec 366 remains the same until the change_cipher_spec message signals that 367 subsequent records will have the negotiated attributes for the remainder 368 of the handshake. 370 The client_hello message contains the client's TLS version number, a 371 sessionId, a random number, and a set of TLS ciphersuites supported by 372 the client. The version offered by the client MUST correspond to TLS 373 v1.0 or later. 375 The EAP server will then respond with an EAP-Request packet with EAP- 376 Type=PEAP. The data field of this packet will encapsulate one or more 377 TLS records. These will contain a TLS server_hello handshake message, 378 possibly followed by TLS certificate, server_key_exchange, 379 certificate_request, server_hello_done and/or finished handshake 380 messages, and/or a TLS change_cipher_spec message. 382 Since after the TLS session is established, another complete EAP 383 negotiation will occur and the peer will authenticate using a secondary 384 mechanism, with PEAP the client need not authenticate as part of TLS 385 session establishment. As a result, although the EAP-Request packet sent 386 by the EAP Server MAY contain a certificate_request message, this is not 387 required. 389 The certificate_request message indicates that the server desires the 390 client to authenticate itself via public key. Typically when the EAP 391 server sends a certificate_request message, the intent is to complete 392 the PEAP authentication without requiring negotiation of an additional 393 EAP method. However, it is valid for the server to request a 394 certificate in the server_hello and for the client refuse to provide 395 one. In this case, the EAP server MUST require that PEAP Part 2 be 396 completed. 398 Note that since TLS client certificates are sent in the clear, if 399 identity protection is required, then it is possible for the TLS 400 authentication to be re-negotiated after the first server 401 authentication. To accomplish this, the server will typically not 402 request a certificate in the server_hello, then after the 403 server_finished message is sent, and before PEAP part 2, the server MAY 404 send a TLS hello_request. This allows the client to perform client 405 authentication by sending a client_hello if it wants to, or send a 406 no_renegotiation alert to the server indicating that it wants to 407 continue with PEAP part 2 instead. Assuming that the client permits 408 renegotiation by sending a client_hello, then the server will respond 409 with server_hello, a certificate and certificate_request messages. The 410 client replies with certificate, client_key_exchange and 411 certificate_verify messages. Since this re-negotiation occurs within 412 the encrypted TLS channel, it does not reveal client certificate 413 details. 415 The server_hello handshake message contains a TLS version number, 416 another random number, a sessionId, and a TLS ciphersuite. The version 417 offered by the server MUST correspond to TLS v1.0 or later. In order to 418 provide confidentiality, integrity and replay protection, and 419 authentication, the negotiated TLS ciphersuite MUST provide all of these 420 security services. 422 If the client's sessionId is null or unrecognized by the server, the 423 server MUST choose the sessionId to establish a new session; otherwise, 424 the sessionId will match that offered by the client, indicating a 425 resumption of the previously established session with that sessionId. 426 The server will also choose a TLS ciphersuite from those offered by the 427 client; if the session matches the client's, then the TLS ciphersuite 428 MUST match the one negotiated during the handshake protocol execution 429 that established the session. 431 PEAP implementations need not necessarily support all TLS ciphersuites 432 listed in [RFC2246]. Not all TLS ciphersuites are supported by available 433 TLS tool kits and licenses may be required to support some TLS 434 ciphersuites (e.g. TLS ciphersuites utilizing the IDEA encryption 435 algorithm). To ensure interoperability, PEAP peers and Authenticators 436 MUST support and be able to negotiate the following TLS ciphersuites: 438 TLS_RSA_WITH_RC4_128_MD5 439 TLS_RSA_WITH_RC4_128_SHA 440 TLS_RSA_WITH_3DES_EDE_CBC_SHA (FIPS compliant) 442 TLS as described in [RFC2246] supports compression as well as 443 ciphersuite negotiation. Therefore during the PEAP Part 1 conversation 444 the EAP endpoints MAY request or negotiate TLS compression. 446 If the EAP server is not resuming a previously established session, then 447 it MUST include a TLS server_certificate handshake message, and a 448 server_hello_done handshake message MUST be the last handshake message 449 encapsulated in this EAP-Request packet. 451 The certificate message contains a public key certificate chain for 452 either a key exchange public key (such as an RSA or Diffie-Hellman key 453 exchange public key) or a signature public key (such as an RSA or DSS 454 signature public key). In the latter case, a TLS server_key_exchange 455 handshake message MUST also be included to allow the key exchange to 456 take place. 458 The peer MUST respond to the EAP-Request with an EAP-Response packet of 459 EAP-Type=PEAP. The data field of this packet will encapsulate one or 460 more TLS records containing a TLS change_cipher_spec message and 461 finished handshake message, and possibly certificate, certificate_verify 462 and/or client_key_exchange handshake messages. If the preceding 463 server_hello message sent by the EAP server in the preceding EAP-Request 464 packet indicated the resumption of a previous session, then the peer 465 MUST send only the change_cipher_spec and finished handshake messages. 466 The finished message contains the peer's authentication response to the 467 EAP server. 469 If the preceding server_hello message sent by the EAP server in the 470 preceding EAP-Request packet did not indicate the resumption of a 471 previous session, then the peer MUST send, in addition to the 472 change_cipher_spec and finished messages, a client_key_exchange message, 473 which completes the exchange of a shared master secret between the peer 474 and the EAP server. 476 The EAP server MUST then respond with an EAP-Request packet with EAP- 477 Type=PEAP, which includes, in the case of a new TLS session, one or more 478 TLS records containing TLS change_cipher_spec and finished handshake 479 messages. The latter contains the EAP server's authentication response 480 to the peer. The peer will then verify the hash in order to 481 authenticate the EAP server. 483 If the EAP server authenticates unsuccessfully, the peer MAY send an 484 EAP-Response packet of EAP-Type=PEAP containing a TLS Alert message 485 identifying the reason for the failed authentication. The peer MAY send 486 a TLS alert message rather than immediately terminating the conversation 487 so as to allow the EAP server to log the cause of the error for 488 examination by the system administrator. 490 To ensure that the EAP Server receives the TLS alert message, the peer 491 MUST wait for the EAP-Server to reply before terminating the 492 conversation. The EAP Server MUST reply with an EAP-Failure packet 493 since server authentication failure is a terminal condition. 495 If the EAP server authenticates successfully, the peer MUST send an EAP- 496 Response packet of EAP-Type=PEAP, and no data. The EAP-Server then 497 continues with Part 2 of the PEAP conversation. 499 2.2. PEAP Part 2 501 The second portion of the PEAP conversation consists of another complete 502 EAP conversation occurring within the TLS session negotiated in PEAP 503 Part 1. It will therefore occur only if establishment of the TLS session 504 in Part 1 is successful. It MUST NOT occur if the EAP Server 505 authenticates unsuccessfully or if an EAP-Failure has been sent by the 506 EAP Server to the peer, terminating the conversation. Since all packets 507 sent within the PEAP Part 2 conversation occur after TLS session 508 establishment, they are protected using the negotiated TLS ciphersuite. 510 Part 2 of the PEAP conversation typically begins with the Authenticator 511 sending an EAP-Request/Identity packet to the peer, protected by the TLS 512 ciphersuite negotiated in PEAP Part 1. The peer responds with an EAP- 513 Response/Identity packet to the authenticator, containing the peer's 514 userId. Since this Identity Request/Response exchange is protected by 515 the ciphersuite negotiated in TLS, it is protected against snooping or 516 packet modification attacks. 518 After the TLS session-protected Identity exchange, the EAP server will 519 then select authentication method(s) for the peer, and will send an EAP- 520 Request with the EAP-Type set to the initial method. As described in 521 [RFC2284], the peer can NAK the suggested EAP method, suggesting an 522 alternative. Since the NAK will be sent within the TLS channel, it is 523 protected from snooping or packet modification. As a result, an attacker 524 snooping on the exchange will be unable to inject NAKs in order to 525 "negotiate down" the authentication method. An attacker will also not 526 be able to determine which EAP method was negotiated. 528 2.3. Version negotiation 530 PEAP packets contain a three bit version field, which enables PEAP 531 implementations to be backward compatible with previous versions of the 532 protocol. Implementations of this specification MUST use a version field 533 set to 1. Version negotiation proceeds as follows: 535 [1] In the first EAP-Request sent with EAP type=PEAP, the EAP server 536 MUST set the version field to the highest supported version number. 538 [2] If the EAP client supports this version of the protocol, it MUST 539 respond with an EAP-Response of EAP type=PEAP, and the version 540 number proposed by the EAP server. 542 [3] If the EAP client does not support this version, it responds with 543 an EAP-Response of EAP type=PEAP and the highest supported version 544 number. 546 [4] If the EAP server supports the version proposed by the client, then 547 all future EAP-Request packets of EAP type=PEAP MUST include the 548 version field set to the agreed upon version number. Similarly, the 549 EAP client MUST include the agreed upon version number in all EAP- 550 Response packets of EAP type=PEAP. 552 [5] If the PEAP server does not support the version number proposed by 553 the PEAP client, it terminates the conversation, as described in 554 Section 2.4. 556 This version negotiation procedure guarantees that the EAP client and 557 server will agree to the latest version supported by both parties. If 558 version negotiation fails, then use of PEAP will not be possible, and 559 another mutually acceptable EAP method will need to be negotiated if 560 authentication is to proceed. 562 2.4. Termination 564 As described in [RFC2284], EAP Success and Failure packets are not 565 authenticated, so that they may be forged by an attacker without fear of 566 detection. Forged EAP Failure packets can be used to convince an EAP 567 peer to disconnect. Forged EAP Success packets may be used by a rogue 568 NAS to convince a peer to let itself access the network, even though the 569 NAS has not authenticated itself. 571 By requiring mutual authentication and by supporting encrypted, 572 authenticated and integrity protected success/failure indications, 573 (described below as "protected" indications) PEAP provides protection 574 against these attacks. Within PEAP, protected success/failure 575 indications are supported by sending these indications within the TLS 576 channel. 578 PEAP support for protected success/failure indications is constrained by 579 the [RFC2284] and [IEEE8021X] specifications. In [IEEE8021X], the 580 authenticator "manufactures" cleartext EAP Success and Failure packets 581 based on the result indicated by the backend authentication server. As a 582 result, were a PEAP server to send a protected EAP Success or EAP 583 Failure packet as the final packet within the EAP exchange, 584 authenticators compliant with [IEEE8021X] would silently discard the 585 packet, and replace it with a cleartext EAP Success or Failure. Since 586 the client will discard these unprotected indications, where an 587 authenticator compliant with [IEEE8021X] is present, it is not be 588 possible to conclude a successful authentication. As a result, this 589 approach does not provide reliable authenticated success/failure 590 indications on all media. 592 In addition, [RFC2284] states that an EAP Success or EAP Failure packet 593 terminates the EAP conversation, so that no response is possible. Since 594 EAP Success and EAP Failure packets are not retransmitted, if the final 595 packet is lost, then authentication will fail. As a result, where packet 596 loss is expected to be non-negligible, unacknowledged success/failure 597 indications lack robustness. 599 As a result, a PEAP server SHOULD NOT send a protected EAP Success or 600 EAP Failure packet as the final packet within a PEAP conversation. 601 However, in the spirit of being "conservative in what you send, liberal 602 in what you receive", a PEAP client SHOULD accept and process such a 603 packet if it is received. This behavior makes it possible for 604 implementations to save a round-trip (improving the performance of fast 605 reconnect), assuming that the authentication occurs within a low packet 606 loss environment in which "manufacture" of packets is guaranteed not to 607 occur. 609 Instead, EAP servers SHOULD utilize the acknowledged and protected 610 success/failure indications defined in Section 4. In this approach, the 611 PEAP server sends the success/failure indication as an EAP-Request with 612 type=33 (EAP Extensions), protected within the TLS channel. The PEAP 613 client then replies with a protected success/failure indication as an 614 EAP-Response with type=33 (EAP Extensions). The conversation concludes 615 with the PEAP server sending a cleartext success/failure indication. 616 Since both sides have already concluded a protected termination 617 conversation, this final packet is ceremonial. 619 Use of a protected and acknowledged success/failure indication provides 620 the PEAP protocol immunity against the "manufacture" of cleartext 621 success/failure indications mandated by [IEEE8021X]. It also enables 622 both sides of the conversation to communicate the outcome of PEAP mutual 623 authentication, although the TLS alert mechanism already provides this 624 capability to some extent. On the other hand, this approach requires an 625 extra round-trip, which affects the performance of fast reconnect. 627 Once PEAP has been selected as the authentication method, compliant PEAP 628 implementations MUST silently discard unprotected success indications 629 (e.g. cleartext EAP Success) unless both the PEAP peer and server have 630 indicated a successful authentication exchange via the mechanism 631 described in Section 4. 633 Similarly, once the TLS channel has been set up, compliant PEAP 634 implementations MUST silently discard unprotected failure indications 635 (e.g. cleartext EAP Failure) unless they are proceeded by a protected 636 failure indication. Protected failure indications include the TLS alert 637 mechanism, as well the indication mechanism described in Section 4. For 638 example, if a PEAP peer has previously received a protected EAP-Request 639 of Type=33 (Extensions) with Result=Failure, or if it has received a 640 protected EAP-Request of Type=33 (Extensions) with Result=Success, and 641 responded with a protected EAP-Response of Type=33 (Extensions) with 642 Result=Failure, then it will accept and process a cleartext EAP Failure. 643 However, if a PEAP peer has previously received a protected EAP-Request 644 of Type=33 (Extensions) with Result=Success, and has responded with a 645 protected EAP-Request of Type=33 (Extensions) with Result=Success, then 646 an unprotected failure indication MUST be silently discarded. 648 Prior to establishment of the TLS channel, no keying material exists, so 649 that protected success/failure indications are not possible. However, 650 within PEAP a failure to establish the TLS channel (e.g. failure to 651 verify the server certificate) is considered an unrecoverable error, so 652 that where this failure has occurred, an unprotected failure indication 653 can be safely accepted. 655 2.5. Error handling 657 Other than supporting TLS alert messages, PEAP does not have its own 658 error message capabilities. This is unnecessary since errors in the PEAP 659 Part 1 conversation are communicated via TLS alert messages, and errors 660 in the PEAP Part 2 conversation are expected to be handled by individual 661 EAP methods. 663 If an error occurs at any point in the PEAP conversation, the EAP server 664 SHOULD send an EAP-Request packet with EAP-Type=PEAP, encapsulating a 665 TLS record containing the appropriate TLS alert message. The EAP server 666 SHOULD send a TLS alert message rather than immediately terminating the 667 conversation so as to allow the peer to inform the user of the cause of 668 the failure and possibly allow for a restart of the conversation. To 669 ensure that the peer receives the TLS alert message, the EAP server MUST 670 wait for the peer to reply with an EAP-Response packet. 672 2.6. Retry behavior 674 As with other EAP protocols, the EAP server is responsible for retry 675 behavior. This means that if the EAP server does not receive a reply 676 from the peer, it MUST resend the EAP-Request for which it has not yet 677 received an EAP-Response. However, the peer MUST NOT resend EAP-Response 678 packets without first being prompted by the EAP server. 680 For example, if the initial PEAP start packet sent by the EAP server 681 were to be lost, then the peer would not receive this packet, and would 682 not respond to it. As a result, the PEAP start packet would be resent by 683 the EAP server. Once the peer received the PEAP start packet, it would 684 send an EAP-Response encapsulating the client_hello message. If the 685 EAP-Response were to be lost, then the EAP server would resend the 686 initial PEAP start, and the peer would resend the EAP-Response. 688 As a result, it is possible that a peer will receive duplicate EAP- 689 Request messages, and may send duplicate EAP-Responses. Both the peer 690 and the EAP Server should be engineered to handle this possibility. 692 2.7. Session resumption 694 The purpose of the sessionId within the TLS protocol is to allow for 695 improved efficiency in the case where a client repeatedly attempts to 696 authenticate to an EAP server within a short period of time. This 697 capability is particularly useful for support of wireless roaming. 699 It is left up to the peer whether to attempt to continue a previous 700 session, thus shortening the PEAP Part 1 conversation. Typically the 701 peer's decision will be made based on the time elapsed since the 702 previous authentication attempt to that EAP server. Based on the 703 sessionId chosen by the peer, and the time elapsed since the previous 704 authentication, the EAP server will decide whether to allow the 705 continuation, or whether to choose a new session. 707 In the case where the EAP server and the authenticator reside on the 708 same device, then the client will only be able to continue sessions when 709 connecting to the same NAS or channel server. Should these devices be 710 set up in a rotary or round-robin then it may not be possible for the 711 peer to know in advance the authenticator it will be connecting to, and 712 therefore which sessionId to attempt to reuse. As a result, it is likely 713 that the continuation attempt will fail. 715 In the case where the EAP authentication is remoted then continuation is 716 much more likely to be successful, since multiple NAS devices and 717 channel servers will remote their EAP authentications to the same 718 backend authentication server. 720 If the EAP server is resuming a previously established session, then it 721 MUST include only a TLS change_cipher_spec message and a TLS finished 722 handshake message after the server_hello message. The finished message 723 contains the EAP server's authentication response to the peer. 725 2.8. Fragmentation 727 A single TLS record may be up to 16384 octets in length, but a TLS 728 message may span multiple TLS records, and a TLS certificate message may 729 in principle be as long as 16MB. The group of PEAP messages sent in a 730 single round may thus be larger than the PPP MTU size, the maximum 731 RADIUS packet size of 4096 octets, or even the Multilink Maximum 732 Received Reconstructed Unit (MRRU). As described in [2], the multilink 733 MRRU is negotiated via the Multilink MRRU LCP option, which includes an 734 MRRU length field of two octets, and thus can support MRRUs as large as 735 64 KB. 737 However, note that in order to protect against reassembly lockup and 738 denial of service attacks, it may be desirable for an implementation to 739 set a maximum size for one such group of TLS messages. Since a typical 740 certificate chain is rarely longer than a few thousand octets, and no 741 other field is likely to be anywhere near as long, a reasonable choice 742 of maximum acceptable message length might be 64 KB. 744 If this value is chosen, then fragmentation can be handled via the 745 multilink PPP fragmentation mechanisms described in [RFC1990]. While 746 this is desirable, EAP methods are used in other applications such as 747 [IEEE80211] and there may be cases in which multilink or the MRRU LCP 748 option cannot be negotiated. As a result, a PEAP implementation MUST 749 provide its own support for fragmentation and reassembly. 751 Since EAP is an ACK-NAK protocol, fragmentation support can be added in 752 a simple manner. In EAP, fragments that are lost or damaged in transit 753 will be retransmitted, and since sequencing information is provided by 754 the Identifier field in EAP, there is no need for a fragment offset 755 field as is provided in IPv4. 757 PEAP fragmentation support is provided through addition of flag bits 758 within the EAP-Response and EAP-Request packets, as well as a TLS 759 Message Length field of four octets. Flags include the Length included 760 (L), More fragments (M), and PEAP Start (S) bits. The L flag is set to 761 indicate the presence of the four octet TLS Message Length field, and 762 MUST be set for the first fragment of a fragmented TLS message or set of 763 messages. The M flag is set on all but the last fragment. The S flag is 764 set only within the PEAP start message sent from the EAP server to the 765 peer. The TLS Message Length field is four octets, and provides the 766 total length of the TLS message or set of messages that is being 767 fragmented; this simplifies buffer allocation. 769 When a PEAP peer receives an EAP-Request packet with the M bit set, it 770 MUST respond with an EAP-Response with EAP-Type=PEAP and no data. This 771 serves as a fragment ACK. The EAP server MUST wait until it receives the 772 EAP-Response before sending another fragment. In order to prevent errors 773 in processing of fragments, the EAP server MUST increment the Identifier 774 field for each fragment contained within an EAP-Request, and the peer 775 MUST include this Identifier value in the fragment ACK contained within 776 the EAP-Response. Retransmitted fragments will contain the same 777 Identifier value. 779 Similarly, when the EAP server receives an EAP-Response with the M bit 780 set, it MUST respond with an EAP-Request with EAP-Type=PEAP and no data. 781 This serves as a fragment ACK. The EAP peer MUST wait until it receives 782 the EAP-Request before sending another fragment. In order to prevent 783 errors in the processing of fragments, the EAP server MUST increment the 784 Identifier value for each fragment ACK contained within an EAP-Request, 785 and the peer MUST include this Identifier value in the subsequent 786 fragment contained within an EAP-Response. 788 2.9. Key derivation 790 Since the normal TLS keys are used in the handshake, and therefore 791 should not be used in a different context, new keys must be derived from 792 the TLS master secret for use with the selected link layer ciphersuites. 793 In the most general case, keying material must be provided for 794 authentication, encryption and initialization vectors (IVs) in each 795 direction. 797 Since EAP methods may not know the link layer ciphersuite that has been 798 negotiated, it may not be possible for them to provide link layer 799 ciphersuite-specific keys. In addition, attempting to provide such keys 800 is undesirable, since it would require the EAP method to be revised each 801 time a new link layer ciphersuite is developed. As a result, PEAP 802 derives master session keys which can subsequently be truncated for use 803 with a particular link layer ciphersuite. Since the truncation 804 algorithms are ciphersuite-specific, they are not discussed here; 805 examples of such algorithms are provided in [RFC3079]. This draft also 806 does not discuss the format of the attributes used to communicate the 807 master session keys from the backend authentication server to the NAS; 808 examples of such attributes are provided in [RFC2548]. 810 For both peer and EAP server, the derivation of master session keys 811 proceeds as follows: 813 [1] Given the master key negotiated by the TLS handshake, the pseudo- 814 random function (PRF) defined in the specification for the version 815 of TLS in use, and the value random defined as the concatenation of 816 the handshake message fields client_hello.random and 817 server_hello.random (in that order), the value PRF(master key, 818 "client PEAP encryption", random) is computed up to 128 bytes, and 819 the value PRF("", "client PEAP encryption", random) is computed up 820 to 64 bytes (where "" is an empty string). 822 [2] The peer master session encryption key (the one used for encrypting 823 data from peer to EAP server) is obtained by truncating to the 824 correct length the first 32 bytes of these two PRF output strings. 826 [3] The EAP server master session encryption key (the one used to 827 encrypting data from EAP server to peer), if different from the 828 client master session encryption key, is obtained by truncating to 829 the correct length the second 32 bytes of this same PRF output 830 string. 832 [4] The peer master session authentication key (the one used for 833 computing MACs for messages from peer to EAP server), if used, is 834 obtained by truncating to the correct length the third 32 bytes of 835 this same PRF output string. 837 [5] The EAP server master session authentication key (the one used for 838 computing MACs for messages from EAP server to peer), if used, and 839 if different from the peer master session authentication key, is 840 obtained by truncating to the correct length the fourth 32 bytes of 841 this same PRF output string. 843 [6] The peer master session initialization vector (IV), used for 844 messages from peer to EAP server, is obtained by truncating to the 845 cipher's block size the first 32 bytes of the second PRF output 846 string mentioned above. 848 [7] Finally, the EAP server master session initialization vector (IV), 849 used for messages from peer to EAP server, is obtained by 850 truncating to the cipher's block size the second 32 bytes of this 851 second PRF output. 853 Algorithms for the truncation of these encryption and authentication 854 master session keys are specific to each link layer ciphersuite. Link 855 layer ciphersuites in use with PPP include DESEbis [RFC2419], 3DES 856 [RFC2420] and MPPE [RFC3078]. IEEE 802.11 ciphersuites are described in 857 [IEEE80211]. An example of how encryption keys for use with MPPE 858 [RFC3078] are derived from the TLS master session keys is given in 859 [RFC3079]. Additional keys or other non-secret values (such as IVs) can 860 be obtained as needed by extending the outputs of the PRF beyond 128 861 bytes and 64 bytes, respectively. 863 2.10. Ciphersuite negotiation 865 Since TLS supports TLS ciphersuite negotiation, peers completing the TLS 866 negotiation will also have selected a TLS ciphersuite, which includes 867 key strength, encryption and hashing methods. However, unlike in 868 [RFC2716], within PEAP, the negotiated TLS ciphersuite relates only to 869 the mechanism by which the PEAP Part 2 conversation will be protected, 870 and has no relationship to link layer security mechanisms negotiated 871 within the PPP Encryption Control Protocol (ECP) [RFC1968] or within 872 IEEE 802.11 [IEEE80211]. 874 As a result, this specification currently does not support secure 875 negotiation of link layer ciphersuites, although this capability may be 876 added in future by addition of AVPs to the EAP Extensions method defined 877 in Section 4. 879 3. Detailed description of the PEAP protocol 881 3.1. PEAP Packet Format 883 A summary of the PEAP Request/Response packet format is shown below. 884 The fields are transmitted from left to right. 886 0 1 2 3 887 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 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Code | Identifier | Length | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Type | Flags | Ver | Data... 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Code 896 1 - Request 897 2 - Response 899 Identifier 901 The Identifier field is one octet and aids in matching responses with 902 requests. 904 Length 906 The Length field is two octets and indicates the length of the EAP 907 packet including the Code, Identifier, Length, Type, and Data fields. 908 Octets outside the range of the Length field should be treated as 909 Data Link Layer padding and should be ignored on reception. 911 Type 913 25 - PEAP 915 Flags 917 0 1 2 3 4 918 +-+-+-+-+-+ 919 |L M S R R| 920 +-+-+-+-+-+ 922 L = Length included 923 M = More fragments 924 S = PEAP start 925 R = Reserved (must be zero) 927 The L bit (length included) is set to indicate the presence of the 928 four octet TLS Message Length field, and MUST be set for the first 929 fragment of a fragmented TLS message or set of messages. The M bit 930 (more fragments) is set on all but the last fragment. The S bit (PEAP 931 start) is set in a PEAP Start message. This differentiates the PEAP 932 Start message from a fragment acknowledgment. 934 Version 936 0 1 2 937 +-+-+-+ 938 |R|R|1| 939 +-+-+-+ 941 R = Reserved (must be zero) 943 Data 945 The format of the Data field is determined by the Code field. 947 3.2. PEAP Request Packet 949 A summary of the PEAP Request packet format is shown below. The fields 950 are transmitted from left to right. 952 0 1 2 3 953 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 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Code | Identifier | Length | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Type | Flags | Ver | TLS Message Length 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | TLS Message Length | TLS Data... 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Code 964 1 966 Identifier 968 The Identifier field is one octet and aids in matching responses with 969 requests. The Identifier field MUST be changed on each Request 970 packet. 972 Length 974 The Length field is two octets and indicates the length of the EAP 975 packet including the Code, Identifier, Length, Type, and TLS Response 976 fields. 978 Type 980 25 - PEAP 982 Flags 984 0 1 2 3 4 985 +-+-+-+-+-+ 986 |L M S R R| 987 +-+-+-+-+-+ 989 L = Length included 990 M = More fragments 991 S = PEAP start 992 R = Reserved (must be zero) 994 The L bit (length included) is set to indicate the presence of the 995 four octet TLS Message Length field, and MUST be set for the first 996 fragment of a fragmented TLS message or set of messages. The M bit 997 (more fragments) is set on all but the last fragment. The S bit (PEAP 998 start) is set in a PEAP Start message. This differentiates the PEAP 999 Start message from a fragment acknowledgment. 1001 Version 1003 0 1 2 1004 +-+-+-+ 1005 |R|R|1| 1006 +-+-+-+ 1008 R = Reserved (must be zero) 1010 TLS Message Length 1012 The TLS Message Length field is four octets, and is present only if 1013 the L bit is set. This field provides the total length of the TLS 1014 message or set of messages that is being fragmented. 1016 TLS data 1018 The TLS data consists of the encapsulated packet in TLS record 1019 format. 1021 3.3. PEAP Response Packet 1023 A summary of the PEAP Response packet format is shown below. The fields 1024 are transmitted from left to right. 1026 0 1 2 3 1027 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 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Code | Identifier | Length | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Type | Flags |Ver| TLS Message Length 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | TLS Message Length | TLS Data... 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 Code 1038 2 1040 Identifier 1042 The Identifier field is one octet and MUST match the Identifier field 1043 from the corresponding request. 1045 Length 1047 The Length field is two octets and indicates the length of the EAP 1048 packet including the Code, Identifier, Length, Type, and TLS data 1049 fields. 1051 Type 1053 25 - PEAP 1055 Flags 1057 0 1 2 3 4 1058 +-+-+-+-+-+ 1059 |L M S R R| 1060 +-+-+-+-+-+ 1062 L = Length included 1063 M = More fragments 1064 S = PEAP start 1065 R = Reserved (must be zero) 1067 The L bit (length included) is set to indicate the presence of the 1068 four octet TLS Message Length field, and MUST be set for the first 1069 fragment of a fragmented TLS message or set of messages. The M bit 1070 (more fragments) is set on all but the last fragment. The S bit (PEAP 1071 start) is set in a PEAP Start message. This differentiates the PEAP 1072 Start message from a fragment acknowledgment. 1074 Version 1076 0 1 2 1077 +-+-+-+ 1078 |R|R|1| 1079 +-+-+-+ 1081 R = Reserved (must be zero) 1083 TLS Message Length 1085 The TLS Message Length field is four octets, and is present only if 1086 the L bit is set. This field provides the total length of the TLS 1087 message or set of messages that is being fragmented. 1089 TLS data 1091 The TLS data consists of the encapsulated TLS packet in TLS record 1092 format. 1094 4. EAP Extensions method 1096 Compliant PEAP implementations MUST support acknowledged, protected 1097 success/failure indications via the EAP Extensions method, type 33. This 1098 is accomplished via the Result AVP; PEAP does not utilize any other AVPs 1099 within the EAP Extensions method. 1101 PEAP implementations supporting the EAP Extensions method MUST support 1102 the Result AVP. When using this AVP, the only outcome which should be 1103 considered a successful authentication is when an EAP Request of 1104 Type=Extensions with Result AVP of Status=Success is answered by an EAP 1105 Response of Type=Extensions with Result AVP of Status=Success. 1107 All other combinations (Extensions Success, Extensions Failure), 1108 (Extensions Failure, Extensions Success), (Extensions Failure, 1109 Extensions Failure), (no extensions exchange or protected EAP Success or 1110 Failure) should be considered failed authentications, both by the PEAP 1111 peer and authenticator. This is true regardless of whether a cleartext 1112 EAP Success or EAP Failure packet is subsequently sent. Because the EAP 1113 Extensions method is protected within the TLS channel, these packets 1114 cannot be spoofed, whereas cleartext EAP Success and EAP Failure 1115 messages can be sent by an attacker. 1117 4.1. Extension Request Packet 1119 A summary of the EAP Extensions Request packet format is shown below. 1120 The fields are transmitted from left to right. 1122 0 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Code | Identifier | Length | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Type | Data.... 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 Code 1132 1 1134 Identifier 1136 The Identifier field is one octet and aids in matching responses with 1137 requests. The Identifier field MUST be changed on each Request 1138 packet. 1140 Length 1142 The Length field is two octets and indicates the length of the EAP 1143 packet including the Code, Identifier, Length, Type, and Data fields. 1145 Type 1147 33 - EAP Extensions 1149 Data 1151 The Data field is of variable length, and contains Extension AVPs. 1153 4.2. Extension Response Packet 1155 A summary of the Extension Response packet format is shown below. The 1156 fields are transmitted from left to right. 1158 0 1 2 3 1159 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 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Code | Identifier | Length | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Type | Data.... 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 Code 1168 2 1170 Identifier 1172 The Identifier field is one octet and aids in matching responses with 1173 requests. The Identifier field MUST be changed on each Request 1174 packet. 1176 Length 1178 The Length field is two octets and indicates the length of the EAP 1179 packet including the Code, Identifier, Length, Type, and Data fields. 1181 Type 1183 33 - EAP Extensions 1185 Data 1187 The Data field is of variable length, and contains Attribute-Value 1188 Pairs (AVPs). 1190 4.3. Extension AVP format 1192 Extension AVPs are defined as follows: 1194 0 1 2 3 1195 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 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 |M|R| AVP Type | Length | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Value... 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 M 1204 0 - Non-mandatory AVP 1205 1 - Mandatory AVP 1207 R 1209 Reserved, set to zero (0) 1211 AVP Type 1213 A 14-bit field, denoting the attribute type. Allocated AVP Types 1214 include: 1215 0 - Reserved 1216 1 - Reserved 1217 2 - Reserved 1218 3 - Acknowledged Result 1220 Length 1222 The length of the Value field in octets. 1224 Value 1226 The value of the attribute. 1228 4.4. Result AVP 1230 The Result AVP provides support for acknowledged Success and Failure 1231 messages within PEAP. It is defined as follows: 1233 0 1 2 3 1234 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 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 |M|R| AVP Type | Length | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Status | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 M 1243 1 - Mandatory AVP 1245 R 1247 Reserved, set to zero (0) 1249 AVP Type 1251 3 - Success/Failure 1253 Length 1255 2 1257 Status 1259 The status field is two octets. Values include: 1261 1 - Success 1262 2 - Failure 1264 5. Security Considerations 1266 5.1. Authentication and integrity protection 1268 The EAP Extension method is presumed to run before or after an EAP 1269 method that supports mutual authentication and establishes a protected 1270 channel. PEAP is such a method, and as a result the acknowledged 1271 Success and Failure messages are always protected. 1273 Note however, that [IEEE8021X] manufactures cleartext EAP Success and 1274 EAP Failure messages, so that even though the Result AVP will be 1275 protected, this will be followed by a cleartext EAP Success or EAP 1276 Failure packet. 1278 5.2. Method negotiation 1280 If the peer does not support PEAP, or does not wish to utilize PEAP 1281 authentication, it MUST respond to the initial EAP-Request/PEAP-Start 1282 with a NAK, suggesting an alternate authentication method. Since the NAK 1283 is sent in cleartext with no integrity protection or authentication, it 1284 is subject to spoofing. Unauthentic NAK packets can be used to trick 1285 the peer and Authenticator into "negotiating down" to a weaker form of 1286 authentication, such as EAP-MD5 (which only provides one way 1287 authentication and does not derive a key). 1289 Since a subsequent protected EAP conversation can take place within the 1290 TLS session, selection of PEAP as an authentication method does not 1291 limit the potential secondary authentication methods. As a result, the 1292 only legitimate reason for a peer to NAK PEAP as an authentication 1293 method is that it does not support it. Where the additional security of 1294 PEAP is required, server implementations SHOULD respond to a NAK with an 1295 EAP-Failure, terminating the authentication conversation. 1297 5.3. TLS session cache handling 1299 In cases where a TLS session has been successfully resumed, in some 1300 circumstances, it is possible for the EAP server to skip the PEAP Part 1301 2 conversation entirely, and successfully conclude the conversation as 1302 described in Section 2.4. 1304 PEAP "fast reconnect" is desirable in applications such as wireless 1305 roaming, since it minimizes interruptions in connectivity. It is also 1306 desirable when the "inner" EAP mechanism used is such that it requires 1307 user interaction. The user should not be required to re-authenticate 1308 herself, using biometrics, token cards or similar, every time the radio 1309 connectivity is handed over between access points in wireless 1310 environments. 1312 However, there are issues that need to be understood in order to avoid 1313 introducing security vulnerabilities. 1315 Since PEAP Part 1 may not provide client authentication, establishment 1316 of a TLS session (and an entry in the TLS session cache) does not by 1317 itself provide an indication of the peer's authenticity. The peer's 1318 authenticity is only proven by successful completion of the PEAP Part 2 1319 authentication. 1321 Some PEAP implementations may not be capable of removing TLS session 1322 cache entries established in PEAP Part 1 after an unsuccessful PEAP Part 1323 2 authentication. In such implementations, the existence of a TLS 1324 session cache entry provides no indication that the peer has previously 1325 been authenticated. As a result, implementations that do not remove TLS 1326 session cache entries after a failed PEAP Part 2 authentication MUST use 1327 other means than successful TLS resumption as the indicator of whether 1328 the client is authenticated or not. Failing to do this would enable a 1329 peer to gain access by completing PEAP Part 1, tearing down the 1330 connection, re-connecting and resuming PEAP Part 1, thereby proving 1331 herself authenticated. Thus, TLS resumption MUST only be enabled if the 1332 implementation supports TLS session cache removal. 1334 If an EAP server implementing PEAP removes TLS session cache entries of 1335 peers failing PEAP Part 2 authentication, then it MAY skip the PEAP Part 1336 2 conversation entirely after a successful session resumption, 1337 successfully terminating the PEAP conversation as described in Section 1338 2.4. 1340 5.4. Certificate revocation 1342 Since the EAP server is on the Internet during the EAP conversation, the 1343 server is capable of following a certificate chain or verifying whether 1344 the peer's certificate has been revoked. In contrast, the peer may or 1345 may not have Internet connectivity, and thus while it can validate the 1346 EAP server's certificate based on a pre-configured set of CAs, it may 1347 not be able to follow a certificate chain or verify whether the EAP 1348 server's certificate has been revoked. 1350 In the case where the peer is initiating a voluntary Layer 2 channel 1351 using PPTP or L2TP, the peer will typically already have Internet 1352 connectivity established at the time of channel initiation. As a 1353 result, during the EAP conversation it is capable of checking for 1354 certificate revocation. 1356 As part of the TLS negotiation, the server presents a certificate to the 1357 peer. The peer SHOULD verify the validity of the EAP server 1358 certificate, and SHOULD also examine the EAP server name presented in 1359 the certificate, in order to determine whether the EAP server can be 1360 trusted. Please note that in the case where the EAP authentication is 1361 remoted, the EAP server will not reside on the same machine as the 1362 authenticator, and therefore the name in the EAP server's certificate 1363 cannot be expected to match that of the intended destination. In this 1364 case, a more appropriate test might be whether the EAP server's 1365 certificate is signed by a CA controlling the intended destination and 1366 whether the EAP server exists within a target sub-domain. 1368 In the case where the peer is attempting to obtain network access, it 1369 will not have Internet connectivity. The TLS Extensions [TLSEXT] support 1370 piggybacking of an Online Certificate Status Protocol (OCSP) response 1371 within TLS, therefore can be utilized by the peer in order to verify the 1372 validity of server certificate. However, since all TLS implementations 1373 do not implement the TLS extensions, it may be necessary for the peer to 1374 wait to check for certificate revocation until after Internet access has 1375 been obtained. In this case, the peer SHOULD conduct the certificate 1376 status check immediately upon going online and SHOULD NOT send data 1377 until it has received a positive response to the status request. If the 1378 server certificate is found to be invalid, then the peer SHOULD 1379 disconnect. 1381 5.5. Separation of the EAP server and the authenticator 1383 As a result of a complete PEAP Part 1 and Part 2 conversation, the EAP 1384 endpoints will mutually authenticate, and derive a session key for 1385 subsequent use in link layer security. Since the peer and EAP client 1386 reside on the same machine, it is necessary for the EAP client module to 1387 pass the session key to the link layer encryption module. 1389 The situation may be more complex on the Authenticator, which may or may 1390 not reside on the same machine as the EAP server. In the case where the 1391 EAP server and the Authenticator reside on different machines, there are 1392 several implications for security. Firstly, the mutual authentication 1393 defined in PEAP will occur between the peer and the EAP server, not 1394 between the peer and the authenticator. This means that as a result of 1395 the PEAP conversation, it is not possible for the peer to validate the 1396 identity of the NAS or channel server that it is speaking to. 1398 The second issue is that the session key negotiated between the peer and 1399 EAP server will need to be transmitted to the authenticator. Therefore 1400 a mechanism needs to be provided to transmit the session key from the 1401 EAP server to the authenticator or channel server that needs to use the 1402 key. The specification of this transit mechanism is outside the scope of 1403 this document. 1405 5.6. Separation of PEAP Part 1 and Part 2 Servers 1407 The EAP server involved in PEAP Part 2 need not necessarily be the same 1408 as the EAP server involved in PEAP Part 1. For example, a local 1409 authentication server or proxy might serve as the endpoint for the Part 1410 1 conversation, establishing the TLS channel. Subsequently, once the 1411 EAP-Response/Identity has been received within the TLS channel, it can 1412 be decrypted and forwarded in cleartext to the destination realm EAP 1413 server. The rest of the conversation will therefore occur between the 1414 destination realm EAP server and the peer, with the local authentication 1415 server or proxy acting as an encrypting/decrypting gateway. This permits 1416 a non-TLS capable EAP server to participate in the PEAP conversation. 1418 Note however that such an approach introduces security vulnerabilities. 1419 Since the EAP Response/Identity is sent in the clear between the proxy 1420 and the EAP server, this enables an attacker to snoop the user's 1421 identity. It also enables a remote environments, which may be public 1422 hot spots or Internet coffee shops, to gain knowledge of the identity of 1423 their users. Since one of the potential benefits of PEAP is identity 1424 protection, this is undesirable. 1426 If the EAP method negotiated during PEAP Part 2 does not support mutual 1427 authentication, then if the Part 2 conversation is proxied to another 1428 destination, the PEAP peer will not have the opportunity to verify the 1429 secondary EAP server's identity. Only the initial EAP server's identity 1430 will have been verified as Part of TLS session establishment. 1432 Similarly, if the EAP method negotiated during PEAP Part 2 is vulnerable 1433 to dictionary attack, then an attacker capturing the cleartext exchange 1434 will be able to mount an offline dictionary attack on the password. 1436 Finally, when a Part 2 conversation is terminated at a different 1437 location than the Part 1 conversation, the Part 2 destination is unaware 1438 that the EAP client has negotiated PEAP. As a result, it is unable to 1439 enforce policies requiring PEAP. Since some EAP methods require PEAP in 1440 order to generate keys or lessen security vulnerabilities, where such 1441 methods are in use, such a configuration may be unacceptable. 1443 In summary, PEAP encrypting/decrypting gateway configurations are 1444 vulnerable to attack and SHOULD NOT be used. Instead, the entire PEAP 1445 connection SHOULD be proxied to the final destination, and the 1446 subsequently derived master session keys need to be transmitted back. 1447 This provides end to end protection of PEAP. The specification of this 1448 transit mechanism is outside the scope of this document, but mechanisms 1449 similar to [RFC2548] can be used. These steps protects the client from 1450 revealing her identity to the remote environment. 1452 In order to find the proper PEAP destination, the EAP client SHOULD 1453 place a Network Access Identifier (NAI) conforming to [RFC2486] in the 1454 Identity Response. 1456 There may be cases where a natural trust relationship exists between the 1457 (foreign) authentication server and final EAP server, such as on a 1458 campus or between two offices within the same company, where there is no 1459 danger in revealing the identity of the station to the authentication 1460 server. In these cases, using a proxy solution without end to end 1461 protection of PEAP MAY be used. The PEAP encrypting/decrypting gateway 1462 SHOULD provide support for IPsec protection of RADIUS in order to 1463 provide confidentiality for the portion of the conversation between the 1464 gateway and the EAP server, as described in [RFC3162]. 1466 5.7. Identity verification 1468 Since the TLS session has not yet been negotiated, the initial Identity 1469 request/response occurs in the clear without integrity protection or 1470 authentication. It is therefore subject to snooping and packet 1471 modification. 1473 In configurations where all users are required to authenticate with PEAP 1474 and the first portion of the PEAP conversation is terminated at a local 1475 backend authentication server, without routing by proxies, the initial 1476 cleartext Identity Request/Response exchange is not needed in order to 1477 determine the required authentication method(s) or route the 1478 authentication conversation to its destination. As a result, the initial 1479 Identity and Request/Response exchange MAY NOT be present, and a 1480 subsequent Identity Request/Response exchange MAY occur after the TLS 1481 session is established. 1483 If the initial cleartext Identity Request/Response has been tampered 1484 with, after the TLS session is established, it is conceivable that the 1485 EAP Server will discover that it cannot verify the peer's claim of 1486 identity. For example, the peer's userID may not be valid or may not be 1487 within a realm handled by the EAP server. Rather than attempting to 1488 proxy the authentication to the server within the correct realm, the EAP 1489 server SHOULD terminate the conversation. 1491 The PEAP peer can present the server with multiple identities. This 1492 includes the claim of identity within the initial EAP-Response/Identity 1493 (MyID) packet, which is typically used to route the EAP conversation to 1494 the appropriate home backend authentication server. There may also be 1495 subsequent EAP-Response/Identity packets sent by the peer once the TLS 1496 channel has been established. 1498 Note that since the PEAP peer may not present a certificate, it is not 1499 always possible to check the initial EAP-Response/Identity against the 1500 identity presented in the certificate, as is done in [RFC2716]. 1501 Moreover, it cannot be assumed that the peer identities presented within 1502 multiple EAP-Response/Identity packets will be the same. For example, 1503 the initial EAP-Response/Identity might correspond to a machine 1504 identity, while subsequent identities might be those of the user. Thus, 1505 PEAP implementations SHOULD NOT abort the authentication just because 1506 the identities do not match. However, since the initial EAP- 1507 Response/Identity will determine the EAP server handling the 1508 authentication, if this or any other identity is inappropriate for use 1509 with the destination EAP server, there is no alternative but to 1510 terminate the PEAP conversation. 1512 The protected identity or identities presented by the peer within PEAP 1513 Part 2 may not be identical to the cleartext identity presented in PEAP 1514 Part 1, for legitimate reasons. In order to shield the userID from 1515 snooping, the cleartext Identity may only provide enough information to 1516 enable routing of the authentication request to the correct realm. For 1517 example, the peer may initially claim the identity of "nouser@bigco.com" 1518 in order to route the authentication request to the bigco.com EAP 1519 server. Subsequently, once the TLS session has been negotiated, in PEAP 1520 Part 2, the peer may claim the identity of "fred@bigco.com". Thus, PEAP 1521 can provide protection for the user's identity, though not necessarily 1522 the destination realm, unless the PEAP Part 1 conversation terminates at 1523 the local authentication server. 1525 As a result, PEAP implementations SHOULD NOT attempt to compare the 1526 Identities claimed with Parts 1 and 2 of the PEAP conversation. 1527 Similarly, if multiple Identities are claimed within PEAP Part 2, these 1528 SHOULD NOT be compared. An EAP conversation may involve more than one 1529 EAP authentication method, and the identities claimed for each of these 1530 authentications could be different (e.g. a machine authentication, 1531 followed by a user authentication). 1533 6. Normative references 1535 [RFC1321] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1536 1321, April 1992. 1538 [RFC1570] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1539 1994. 1541 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 1542 51, RFC 1661, July 1994. 1544 [RFC1962] D. Rand. "The PPP Compression Control Protocol", RFC 1962, 1545 Novell, June 1996. 1547 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1548 1996. 1550 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 1551 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1552 1996. 1554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1555 Requirement Levels", BCP 14, RFC 2119, March 1997. 1557 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 1558 2246, November 1998. 1560 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 1561 Protocol (EAP)", RFC 2284, March 1998. 1563 [RFC2486] Aboba, B., Beadles, M., "The Network Access Identifier", RFC 1564 2486, January 1999. 1566 [TLSEXT] Blake-Wilson, S., et al. "TLS Extensions", Internet draft 1567 (work in progress), draft-ietf-tls-extensions-05.txt, July 1568 2002. 1570 [IEEE8021X] 1571 IEEE Standards for Local and Metropolitan Area Networks: Port 1572 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 1574 7. Informative references 1576 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 1577 Version 2 (DESE-bis)", RFC 2419, September 1998. 1579 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 1580 RFC 2420, September 1998. 1582 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1583 RFC2548, March 1999. 1585 [RFC2716] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", 1586 RFC 2716, October 1999. 1588 [RFC3078] Pall, G., Zorn, G., "Microsoft Point-to-Point Encryption 1589 (MPPE) Protocol", RFC 3078, March 2001. 1591 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 1592 Encryption (MPPE)", RFC 3079, March 2001. 1594 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS 1595 PUB 46 (January 1977). 1597 [IEEE80211] 1598 Information technology - Telecommunications and information 1599 exchange between systems - Local and metropolitan area 1600 networks - Specific Requirements Part 11: Wireless LAN Medium 1601 Access Control (MAC) and Physical Layer (PHY) Specifications, 1602 IEEE Std. 802.11-1999, 1999. 1604 [MODES] National Bureau of Standards, "DES Modes of Operation", FIPS 1605 PUB 81 (December 1980). 1607 Appendix A - Examples 1609 In the case where an identity exchange occurs within PEAP Part 1, the 1610 conversation will appear as follows: 1612 Authenticating Peer Authenticator 1613 ------------------- ------------- 1614 <- EAP-Request/ 1615 Identity 1616 EAP-Response/ 1617 Identity (MyID) -> 1618 <- EAP-Request/ 1619 EAP-Type=PEAP, V=1 1620 (PEAP Start, S bit set) 1622 EAP-Response/ 1623 EAP-Type=PEAP, V=1 1624 (TLS client_hello)-> 1625 <- EAP-Request/ 1626 EAP-Type=PEAP, V=1 1627 (TLS server_hello, 1628 TLS certificate, 1629 [TLS server_key_exchange,] 1630 [TLS certificate_request,] 1631 TLS server_hello_done) 1632 EAP-Response/ 1633 EAP-Type=PEAP, V=1 1634 ([TLS certificate,] 1635 TLS client_key_exchange, 1636 [TLS certificate_verify,] 1637 TLS change_cipher_spec, 1638 TLS finished) -> 1639 <- EAP-Request/ 1640 EAP-Type=PEAP, V=1 1641 (TLS change_cipher_spec, 1642 TLS finished) 1643 EAP-Response/ 1644 EAP-Type=PEAP -> 1646 TLS channel established 1647 (messages sent within the TLS channel) 1649 <- EAP-Request/ 1650 Identity 1651 EAP-Response/ 1652 Identity (MyID) -> 1653 <- EAP-Request/ 1654 EAP-Type=X 1656 EAP-Response/ 1657 EAP-Type=X or NAK -> 1659 <- EAP-Request/ 1660 EAP-Type=X 1661 EAP-Response/ 1662 EAP-Type=X -> 1663 <- EAP-Request/ 1664 EAP-Type=Extensions 1665 Result=Success 1666 EAP-Response/ 1667 EAP-Type=Extensions 1668 Result=Success -> 1670 TLS channel torn down 1671 (messages sent in cleartext) 1673 <- EAP-Success 1675 Where all peers are known to support PEAP, a non-certificate 1676 authentication is desired for the client and the PEAP Part 1 1677 conversation is carried out between the peer and a local EAP server, the 1678 cleartext identity exchange may be omitted and the conversation appears 1679 as follows: 1681 Authenticating Peer Authenticator 1682 ------------------- ------------- 1683 <- EAP-Request/ 1684 EAP-Type=PEAP, V=1 1685 (PEAP Start, S bit set) 1687 EAP-Response/ 1688 EAP-Type=PEAP, V=1 1689 (TLS client_hello)-> 1690 <- EAP-Request/ 1691 EAP-Type=PEAP, V=1 1692 (TLS server_hello, 1693 TLS certificate, 1694 [TLS server_key_exchange,] 1695 [TLS certificate_request,] 1696 TLS server_hello_done) 1697 EAP-Response/ 1698 EAP-Type=PEAP, V=1 1699 ([TLS certificate,] 1700 TLS client_key_exchange, 1701 [TLS certificate_verify,] 1702 TLS change_cipher_spec, 1703 TLS finished) -> 1704 <- EAP-Request/ 1705 EAP-Type=PEAP, V=1 1706 (TLS change_cipher_spec, 1707 TLS finished) 1708 EAP-Response/ 1709 EAP-Type=PEAP, V=1 -> 1711 TLS channel established 1712 (messages sent within the TLS channel) 1714 <- EAP-Request/ 1715 Identity 1716 EAP-Response/ 1717 Identity (MyID) -> 1718 <- EAP-Request/ 1719 EAP-Type=X 1720 EAP-Response/ 1721 EAP-Type=X or NAK -> 1723 <- EAP-Request/ 1724 EAP-Type=X 1725 EAP-Response/ 1726 EAP-Type=X -> 1727 <- EAP-Request/ 1728 EAP-Type=Extensions 1729 Result=Success 1730 EAP-Response/ 1731 EAP-Type=Extensions 1732 Result=Success -> 1734 TLS channel torn down 1735 (messages sent in cleartext) 1737 <- EAP-Success 1739 Where all peers are known to support PEAP, where client certificate 1740 authentication is desired and the PEAP Part 1 conversation is carried 1741 out between the peer and a local EAP server, the cleartext identity 1742 exchange may be omitted and the conversation appears as follows: 1744 Authenticating Peer Authenticator 1745 ------------------- ------------- 1746 <- EAP-Request/ 1747 EAP-Type=PEAP, V=1 1748 (PEAP Start, S bit set) 1750 EAP-Response/ 1751 EAP-Type=PEAP, V=1 1752 (TLS client_hello)-> 1753 <- EAP-Request/ 1754 EAP-Type=PEAP, V=1 1755 (TLS server_hello, 1756 TLS certificate, 1757 [TLS server_key_exchange,] 1758 TLS server_hello_done) 1759 EAP-Response/ 1760 EAP-Type=PEAP, V=1 1761 (TLS client_key_exchange, 1762 TLS change_cipher_spec, 1763 TLS finished) -> 1764 <- EAP-Request/ 1765 EAP-Type=PEAP, V=1 1766 (TLS change_cipher_spec, 1767 TLS finished) 1768 EAP-Response/ 1769 EAP-Type=PEAP, V=1 -> 1771 TLS channel established 1772 (messages sent within the TLS channel) 1774 <- EAP-Request/ 1775 EAP-Type=PEAP, V=1 1776 (TLS hello_request) 1777 EAP-Response/ 1778 EAP-Type=PEAP, V=1 1779 (TLS client_hello)-> 1781 <- EAP-Request/ 1782 EAP-Type=PEAP, V=1 1783 (TLS server_hello, 1784 TLS certificate, 1785 [TLS server_key_exchange,] 1786 [TLS certificate_request,] 1787 TLS server_hello_done) 1788 EAP-Response/ 1789 EAP-Type=PEAP, V=1 1790 ([TLS certificate,] 1791 TLS client_key_exchange, 1792 [TLS certificate_verify,] 1793 TLS change_cipher_spec, 1794 TLS finished) -> 1795 <- EAP-Request/ 1796 EAP-Type=PEAP, V=1 1797 (TLS change_cipher_spec, 1798 TLS finished) 1799 EAP-Response/ 1800 EAP-Type=PEAP, V=1 -> 1801 <- EAP-Request/ 1802 EAP-Type=Extensions 1803 Result=Success 1804 EAP-Response/ 1805 EAP-Type=Extensions 1806 Result=Success -> 1808 TLS channel torn down 1809 (messages sent in cleartext) 1811 <- EAP-Success 1813 In the case where the PEAP fragmentation is required, the conversation 1814 will appear as follows: 1816 Authenticating Peer Authenticator 1817 ------------------- ------------- 1818 <- EAP-Request/ 1819 Identity 1820 EAP-Response/ 1821 Identity (MyID) -> 1822 <- EAP-Request/ 1823 EAP-Type=PEAP, V=1 1824 (PEAP Start, S bit set) 1826 EAP-Response/ 1827 EAP-Type=PEAP, V=1 1828 (TLS client_hello)-> 1829 <- EAP-Request/ 1830 EAP-Type=PEAP, V=1 1831 (TLS server_hello, 1832 TLS certificate, 1833 [TLS server_key_exchange,] 1834 [TLS certificate_request,] 1835 TLS server_hello_done) 1836 (Fragment 1: L, M bits set) 1837 EAP-Response/ 1838 EAP-Type=PEAP, V=1 -> 1839 <- EAP-Request/ 1840 EAP-Type=PEAP, V=1 1841 (Fragment 2: M bit set) 1842 EAP-Response/ 1843 EAP-Type=PEAP, V=1 -> 1844 <- EAP-Request/ 1845 EAP-Type=PEAP, V=1 1846 (Fragment 3) 1847 EAP-Response/ 1848 EAP-Type=PEAP, V=1 1849 ([TLS certificate,] 1850 TLS client_key_exchange, 1851 [TLS certificate_verify,] 1852 TLS change_cipher_spec, 1853 TLS finished) 1854 (Fragment 1: L, M bits set)-> 1856 <- EAP-Request/ 1857 EAP-Type=PEAP, V=1 1858 EAP-Response/ 1859 EAP-Type=PEAP, V=1 1860 (Fragment 2)-> 1861 <- EAP-Request/ 1862 EAP-Type=PEAP, V=1 1863 (TLS change_cipher_spec, 1864 TLS finished) 1866 EAP-Response/ 1867 EAP-Type=PEAP, V=1 -> 1869 TLS channel established 1870 (messages sent within the TLS channel) 1872 <- EAP-Request/ 1873 Identity 1874 EAP-Response/ 1875 Identity (MyID) -> 1876 <- EAP-Request/ 1877 EAP-Type=X 1878 EAP-Response/ 1879 EAP-Type=X or NAK -> 1881 <- EAP-Request/ 1882 EAP-Type=X 1883 EAP-Response/ 1884 EAP-Type=X -> 1885 <- EAP-Request/ 1886 EAP-Type=Extensions 1887 Result=Success 1888 EAP-Response/ 1889 EAP-Type=Extensions 1890 Result=Success -> 1892 TLS channel torn down 1893 (messages sent in cleartext) 1895 <- EAP-Success 1897 In the case where the server authenticates to the client successfully in 1898 PEAP Part 1, but the client fails to authenticate to the server in PEAP 1899 Part 2, the conversation will appear as follows: 1901 Authenticating Peer Authenticator 1902 ------------------- ------------- 1903 <- EAP-Request/ 1904 Identity 1905 EAP-Response/ 1906 Identity (MyID) -> 1907 <- EAP-Request/ 1908 EAP-Type=PEAP, V=1 1909 (PEAP Start, S bit set) 1910 EAP-Response/ 1911 EAP-Type=PEAP, V=1 1912 (TLS client_hello)-> 1913 <- EAP-Request/ 1914 EAP-Type=PEAP, V=1 1915 (TLS server_hello, 1916 TLS certificate, 1917 [TLS server_key_exchange,] 1918 [TLS certificate_request,] 1919 TLS server_hello_done) 1920 EAP-Response/ 1921 EAP-Type=PEAP, V=1 1922 ([TLS certificate,] 1923 TLS client_key_exchange, 1924 [TLS certificate_verify,] 1925 TLS change_cipher_spec, 1926 TLS finished) -> 1927 <- EAP-Request/ 1928 EAP-Type=PEAP, V=1 1929 (TLS change_cipher_spec, 1930 TLS finished) 1932 EAP-Response/ 1933 EAP-Type=PEAP, V=1 -> 1935 TLS channel established 1936 (messages sent within the TLS channel) 1938 <- EAP-Request/ 1939 Identity 1940 EAP-Response/ 1941 Identity (MyID) -> 1942 <- EAP-Request/ 1943 EAP-Type=X 1944 EAP-Response/ 1945 EAP-Type=X or NAK -> 1947 <- EAP-Request/ 1948 EAP-Type=X 1949 EAP-Response/ 1950 EAP-Type=X -> 1951 <- EAP-Request/ 1952 EAP-Type=Extensions 1953 Result=Failure 1954 EAP-Response/ 1955 EAP-Type=Extensions 1956 Result=Failure -> 1958 (TLS session cache entry flushed) 1959 TLS channel torn down 1960 (messages sent in cleartext) 1962 <- EAP-Failure 1964 In the case where server authentication is unsuccessful in PEAP Part 1, 1965 the conversation will appear as follows: 1967 Authenticating Peer Authenticator 1968 ------------------- ------------- 1969 <- EAP-Request/ 1970 Identity 1971 EAP-Response/ 1972 Identity (MyID) -> 1973 <- EAP-Request/ 1974 EAP-Type=PEAP, V=1 1975 (PEAP Start) 1976 EAP-Response/ 1977 EAP-Type=PEAP, V=1 1978 (TLS client_hello)-> 1979 <- EAP-Request/ 1980 EAP-Type=PEAP, V=1 1981 (TLS server_hello, 1982 TLS certificate, 1983 [TLS server_key_exchange,] 1984 TLS server_hello_done) 1985 EAP-Response/ 1986 EAP-Type=PEAP, V=1 1987 (TLS client_key_exchange, 1988 [TLS certificate_verify,] 1989 TLS change_cipher_spec, 1990 TLS finished) -> 1991 <- EAP-Request/ 1992 EAP-Type=PEAP, V=1 1993 (TLS change_cipher_spec, 1994 TLS finished) 1995 EAP-Response/ 1996 EAP-Type=PEAP, V=1 1997 (TLS change_cipher_spec, 1998 TLS finished) 2000 <- EAP-Request/ 2001 EAP-Type=PEAP, V=1 2002 EAP-Response/ 2003 EAP-Type=PEAP, V=1 2004 (TLS Alert message) -> 2005 <- EAP-Failure 2006 (TLS session cache entry flushed) 2008 In the case where a previously established session is being resumed, the 2009 EAP server supports TLS session cache flushing for unsuccessful PEAP 2010 Part 2 authentications and both sides authenticate successfully, the 2011 conversation will appear as follows: 2013 Authenticating Peer Authenticator 2014 ------------------- ------------- 2015 <- EAP-Request/ 2016 Identity 2017 EAP-Response/ 2018 Identity (MyID) -> 2019 <- EAP-Request/ 2020 EAP-Type=PEAP,V=1 2021 (PEAP Start) 2022 EAP-Response/ 2023 EAP-Type=PEAP, V=1 2024 (TLS client_hello)-> 2025 <- EAP-Request/ 2026 EAP-Type=PEAP, V=1 2027 (TLS server_hello, 2028 TLS change_cipher_spec 2029 TLS finished) 2030 EAP-Response/ 2031 EAP-Type=PEAP, V=1 2032 (TLS change_cipher_spec, 2033 TLS finished) -> 2034 <- EAP-Request/ 2035 EAP-Type=Extensions 2036 Result=Success 2037 EAP-Response/ 2038 EAP-Type=Extensions 2039 Result=Success -> 2040 TLS channel torn down 2041 (messages sent in cleartext) 2043 <- EAP-Success 2045 In the case where a previously established session is being resumed, and 2046 the server authenticates to the client successfully but the client fails 2047 to authenticate to the server, the conversation will appear as follows: 2049 Authenticating Peer Authenticator 2050 ------------------- ------------- 2051 <- EAP-Request/ 2052 Identity 2053 EAP-Response/ 2054 Identity (MyID) -> 2055 <- EAP-Request/ 2056 EAP-Request/ 2057 EAP-Type=PEAP, V=1 2058 (TLS Start) 2059 EAP-Response/ 2060 EAP-Type=PEAP, V=1 2061 (TLS client_hello) -> 2062 <- EAP-Request/ 2063 EAP-Type=PEAP, V=1 2064 (TLS server_hello, 2065 TLS change_cipher_spec, 2066 TLS finished) 2067 EAP-Response/ 2068 EAP-Type=PEAP, V=1 2069 (TLS change_cipher_spec, 2070 TLS finished) -> 2071 <- EAP-Request 2072 EAP-Type=PEAP, V=1 2073 (TLS Alert message) 2074 EAP-Response 2075 EAP-Type=PEAP, V=1 -> 2076 <- EAP-Failure 2077 (TLS session cache entry flushed) 2079 In the case where a previously established session is being resumed, and 2080 the server authentication is unsuccessful, the conversation will appear 2081 as follows: 2083 Authenticating Peer Authenticator 2084 ------------------- ------------- 2085 <- EAP-Request/ 2086 Identity 2087 EAP-Response/ 2088 Identity (MyID) -> 2089 <- EAP-Request/ 2090 EAP-Request/ 2091 EAP-Type=PEAP, V=1 2092 (TLS Start) 2093 EAP-Response/ 2094 EAP-Type=PEAP, V=1 2095 (TLS client_hello)-> 2096 <- EAP-Request/ 2097 EAP-Type=PEAP, V=1 2098 (TLS server_hello, 2099 TLS change_cipher_spec, 2100 TLS finished) 2101 EAP-Response/ 2102 EAP-Type=PEAP, V=1 2103 (TLS change_cipher_spec, 2104 TLS finished) 2105 <- EAP-Request/ 2106 EAP-Type=PEAP, V=1 2107 EAP-Response/ 2108 EAP-Type=PEAP, V=1 2109 (TLS Alert message) -> 2110 (TLS session cache entry flushed) 2112 <- EAP-Failure 2114 In the case where the peer and authenticator have mismatched PEAP 2115 versions (e.g. the peer has a pre-standard implementation with version 2116 0, and the authenticator has an implementation compliant with this 2117 specification), the session is being resumed, but the authentication is 2118 unsuccessful, the conversation will occur as follows: 2120 Authenticating Peer Authenticator 2121 ------------------- ------------- 2122 <- EAP-Request/ 2123 Identity 2124 EAP-Response/ 2125 Identity (MyID) -> 2126 <- EAP-Request/ 2127 EAP-Request/ 2128 EAP-Type=PEAP, V=1 2129 (TLS Start) 2130 EAP-Response/ 2131 EAP-Type=PEAP, V=0 2132 (TLS client_hello)-> 2133 <- EAP-Request/ 2134 EAP-Type=PEAP, V=0 2135 (TLS server_hello, 2136 TLS change_cipher_spec, 2137 TLS finished) 2138 EAP-Response/ 2139 EAP-Type=PEAP, V=0 2140 (TLS change_cipher_spec, 2141 TLS finished) 2142 <- EAP-Request/ 2143 EAP-Type=PEAP, V=0 2144 EAP-Response/ 2145 EAP-Type=PEAP, V=0 2146 (TLS Alert message) -> 2147 (TLS session cache entry flushed) 2149 <- EAP-Failure 2151 Acknowledgments 2153 Thanks to Jan-Ove Larsson and Magnus Nystrom of RSA Security, and 2154 Narendra Gidwani and Bernard Aboba of Microsoft for useful discussions 2155 of this problem space. 2157 Author Addresses 2159 Hakan Andersson 2160 RSA Security 2161 Box 107 04 2162 SE-121 29 Stockholm 2163 Sweden 2165 Phone: +46 8 725 9758 2166 Fax: +46 8 649 4970 2167 EMail: handersson@rsasecurity.com 2169 Simon Josefsson 2170 RSA Security 2171 Box 107 04 2172 SE-121 29 Stockholm 2173 Sweden 2175 Phone: +46 8 725 0914 2176 Fax: +46 8 649 4970 2177 EMail: sjosefsson@rsasecurity.com 2179 Glen Zorn 2180 Cisco Systems 2181 500 108th Avenue N.E. 2182 Suite 500 2183 Bellevue, Washington 98004 2184 USA 2186 Phone: + 1 425 438 8210 2187 Fax: + 1 425 438 1848 2188 EMail: gwz@cisco.com 2190 Dan Simon 2191 Microsoft Corporation 2192 One Microsoft Way 2193 Redmond, WA 98052 2195 Phone: +1 425 706 6711 2196 EMail: dansimon@microsoft.com 2198 Ashwin Palekar 2199 Microsoft Corporation 2200 One Microsoft Way 2201 Redmond, WA 98052 2203 Phone: +1 425 882 8080 2204 EMail: ashwinp@microsoft.com 2206 Intellectual Property Statement 2208 The IETF takes no position regarding the validity or scope of any 2209 intellectual property or other rights that might be claimed to pertain 2210 to the implementation or use of the technology described in this 2211 document or the extent to which any license under such rights might or 2212 might not be available; neither does it represent that it has made any 2213 effort to identify any such rights. Information on the IETF's 2214 procedures with respect to rights in standards-track and standards- 2215 related documentation can be found in BCP-11. Copies of claims of 2216 rights made available for publication and any assurances of licenses to 2217 be made available, or the result of an attempt made to obtain a general 2218 license or permission for the use of such proprietary rights by 2219 implementors or users of this specification can be obtained from the 2220 IETF Secretariat. 2222 The IETF invites any interested party to bring to its attention any 2223 copyrights, patents or patent applications, or other proprietary rights 2224 which may cover technology that may be required to practice this 2225 standard. Please address the information to the IETF Executive 2226 Director. 2228 Full Copyright Statement 2230 Copyright (C) The Internet Society (2002). All Rights Reserved. 2231 This document and translations of it may be copied and furnished to 2232 others, and derivative works that comment on or otherwise explain it or 2233 assist in its implementation may be prepared, copied, published and 2234 distributed, in whole or in part, without restriction of any kind, 2235 provided that the above copyright notice and this paragraph are included 2236 on all such copies and derivative works. However, this document itself 2237 may not be modified in any way, such as by removing the copyright notice 2238 or references to the Internet Society or other Internet organizations, 2239 except as needed for the purpose of developing Internet standards in 2240 which case the procedures for copyrights defined in the Internet 2241 Standards process must be followed, or as required to translate it into 2242 languages other than English. The limited permissions granted above are 2243 perpetual and will not be revoked by the Internet Society or its 2244 successors or assigns. This document and the information contained 2245 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 2246 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2247 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2248 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2249 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2251 Expiration Date 2253 This memo is filed as , and 2254 expires April 22, 2003.