idnits 2.17.1 draft-josefsson-pppext-eap-tls-eap-06.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. == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 52 has weird spacing: '... to diction...' == Line 446 has weird spacing: '...ows the clien...' == Line 466 has weird spacing: '...ssionId will ...' == Line 1471 has weird spacing: '... server to sk...' == 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: After a session is successfully resumed, the EAP-Server starts with Part 2 of the PEAP conversation. The peer may have roamed to a different network and successfully resumed with same EAP server. The peer and the EAP server MUST not assume that a session resume implies either of them will skip inner EAP methods. == 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 591 -- Looks like a reference, but probably isn't: '2' on line 810 -- Looks like a reference, but probably isn't: '3' on line 599 -- Looks like a reference, but probably isn't: '4' on line 603 -- Looks like a reference, but probably isn't: '5' on line 609 == Missing Reference: 'RFC3162' is mentioned on line 1648, but not defined == Missing Reference: 'RFC2434' is mentioned on line 1758, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC1321' is defined on line 1798, but no explicit reference was found in the text == Unused Reference: 'RFC1570' is defined on line 1802, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 1806, but no explicit reference was found in the text == Unused Reference: 'RFC1962' is defined on line 1810, but no explicit reference was found in the text == Unused Reference: 'FIPSDES' is defined on line 1873, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 1887, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021X' == Outdated reference: A later version (-04) exists of draft-puthenkulam-eap-binding-02 -- Possible downref: Normative reference to a draft: ref. 'CompoundBinding' -- 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 Ashwin Palekar 3 INTERNET-DRAFT Dan Simon 4 Category: Standards Track Microsoft 5 Glen Zorn 6 22 March 2003 Cisco 7 S. Josefsson 8 Extundo 10 Protected EAP Protocol (PEAP) 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material 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 39 was originally created for use with PPP, it has since been adopted 40 for use with IEEE 802.1X "Network Port Authentication". 42 Since its deployment, a number of weaknesses in EAP or some EAP 43 protocols have become apparent. These include no per packet 44 confidentiality and integrity protection; which results in lack of 45 protection to user identity, notification messages or EAP 46 negotiation; and sequencing of EAP methods. In addition, there is no 47 standardized mechanism for key exchange; no built-in support for 48 fragmentation and reassembly; no support for acknowledged 49 success/failure indications; and no support for fast reconnect. 51 In addition, some EAP protocols (e.g. like EAP-MD5) are susceptible 52 to dictionary and brute force attacks; do not provide 53 confidentiality; do not support server authentication required to 54 prevent spoofing by rogue servers (gateways), and do not support the 55 generation of key strength required for 802.11i. 57 By wrapping the EAP protocol within TLS, Protected EAP (PEAP) 58 addresses these deficiencies in EAP or EAP protocols. EAP method(s) 59 running within PEAP are provided with built-in support for 61 Privacy of user identity. 62 Protection to individual EAP methods. For example, protection can 63 provide dictionary attack resistance to protocols susceptible to 64 that attack. 65 Protected EAP notification. 66 Protected sequencing of EAP methods. 67 Protected negotiation. 68 Protected EAP header. 69 Protected exchange of parameters (TLVs) between client and server. 70 Standardized mechanism for key exchange. 71 Proven key derivation and management. 72 Session resumption. 73 Server authentication. 74 Protected Acknowledged and result exchange. 75 Fragmentation and reassembly. 77 Table of Contents 79 Protected EAP Protocol (PEAP)......................................1 80 1. Introduction.................................................3 81 1.1. Requirements language.......................................5 82 1.2. Terminology.................................................5 83 1.3. Operational model...........................................6 84 2. Protocol overview............................................7 85 2.1. PEAP Part 1.................................................8 86 2.2. PEAP Part 2................................................11 87 2.3. Version negotiation........................................12 88 2.4. Termination................................................12 89 2.5. Error handling.............................................14 90 2.6. Retry behavior.............................................15 91 2.7. Session resumption.........................................15 92 2.8. Fragmentation..............................................16 93 2.9. Key derivation.............................................17 94 2.10. Ciphersuite negotiation....................................18 95 3. Detailed description of the PEAP protocol...................18 96 3.1. PEAP Packet Format.........................................18 97 3.2. PEAP Request Packet........................................20 98 4. EAP TLV method..............................................23 99 4.1. Protected success/failure..................................23 100 4.2. EAP-TLV Request Packet.....................................25 101 4.3. EAP-TLV Response Packet....................................25 102 4.4. EAP-TLV TLV format.........................................26 103 4.5. Result TLV.................................................27 104 4.6. NAK TLV....................................................28 105 5. Security Considerations.....................................28 106 5.1. Authentication and integrity protection....................28 107 5.2. Method negotiation.........................................29 108 5.3. TLS session cache handling.................................29 109 5.4. Certificate revocation.....................................30 110 5.5. Separation of the EAP server and the authenticator.........31 111 5.6. Separation of PEAP Part 1 and Part 2 Servers...............31 112 5.7. Identity verification......................................32 113 5.8. Man-in-the-middle protection...............................34 114 6. IANA Considerations.........................................35 115 6.1. Definition of Terms........................................35 116 6.2. Recommended Registration Policies..........................35 117 7. Normative references........................................35 118 8. Informative references......................................36 119 9. Appendix A - Examples.......................................37 120 10. and Contributions..........................................49 121 11. Intellectual Property Statement.............................50 122 12. Full Copyright Statement....................................51 124 1. Introduction 126 The Extensible Authentication Protocol (EAP), described in 127 [RFC2284], provides a standard mechanism for support of multiple 128 authentication methods. Through the use of EAP, support for a 129 number of authentication schemes may be added, including smart 130 cards, Kerberos, Public Key, One Time Passwords, and others. 132 EAP was developed or use on wired networks, where physical security 133 was presumed. EAP over PPP, defined in [RFC2284], is typically 134 deployed with leased lines or modem connections, requiring an 135 attacker to gain access to the telephone network in order to snoop 136 on the conversation or inject packets. [IEEE8021X] defines EAP over 137 IEEE 802 local area networks(EAPOL), presuming the existence of 138 switched media; in order to snoop or inject packets, an attacker 139 would need to gain administrative access to 140 the switch. Due to the presumption of physical security, facilities 141 for protection of the EAP conversation were not provided. 143 Where an attacker can easily gain access to the medium (such as on a 144 wireless network or where EAP is run over IP), the presumption of 145 physical security is no longer valid. Since the EAP method 146 negotiation is unprotected, an attacker can inject packets in order 147 to cause the negotiation of a method with lesser security. Denial of 148 service attacks are also possible. Since the initial EAP Identity 149 Request/Response exchange is sent in the clear, an attacker snooping 150 on the conversation can collect user identities for use in 151 subsequent attacks. 153 By initially negotiating a TLS channel, and then conducting the EAP 154 conversation within it, PEAP provides for per-packet encryption, 155 authentication, integrity and replay protection of the EAP 156 conversation. 158 Benefits include: 160 Identity protection 161 By encrypting the identity exchange, and allowing client 162 credentials to be provided after negotiation of the TLS channel, 163 PEAP provides for identity protection. 165 Dictionary attack resistance 166 By conducting the EAP conversation within a TLS channel, PEAP 167 protects EAP methods that might be subject to an offline 168 dictionary attack were they to be conducted in the clear. 170 Protected negotiation 171 Since within PEAP, the EAP conversation is authenticated, 172 integrity and replay protected on a per-packet basis, the EAP 173 method negotiation that occurs within PEAP is protected, as are 174 error messages sent within the TLS channel (TLS alerts or EAP 175 Notification packets). 177 Header protection 178 Within PEAP, the EAP conversation is conducted within a TLS 179 channel. As a result, the EAP header is protected against 180 modification. 182 Protected termination 183 By sending success/failure indications within the TLS channel, 184 PEAP provides support for protected termination of the EAP 185 conversation. This prevents an attacker from carrying out denial 186 of service attacks by spoofing EAP Failure messages, or fooling 187 the EAP peer into accepting a rogue NAS, by spoofing EAP Success 188 messages. 190 Fragmentation and Reassembly 191 Since EAP does not include support for fragmentation and 192 reassembly, individual methods need to include this capability. 193 By including support for fragmentation and reassembly within 194 PEAP,methods leveraging PEAP do not need to support this on their 195 own. 197 Fast reconnect 198 Where EAP is used for authentication in wireless networks, the 199 authentication latency is a concern. As a result, it is valuable 200 to be able to do a quick re-authentication on roaming between 201 access points. PEAP supports this capability by leveraging the 202 TLS session resumption facility, and any EAP method running under 203 PEAP can take advantage of it. 205 Proven and Method independent key management 206 In order to provide keying material for a wide range of link 207 layer ciphersuites, EAP methods need to provide a key hierarchy 208 generating authentication and encryption keys, as well as 209 initialization vectors. Development of a secure key hierarchy is 210 complex, and not easy to generalize for all EAP methods. By 211 relying on the well-reviewed TLS [RFC2246] key derivation method, 212 PEAP provides the required keying material for any EAP method 213 running within it. This frees EAP method developments from 214 creating keying material with key strength required for 802.11i 215 wireless LAN. If EAP methods will also be deployed without the 216 protection of PEAP or IPSEC, then the EAP methods should derive 217 key material of sufficient strength to prevent a Man-in-the- 218 middle attack described in the compound binding draft 219 [CompoundBinding]. 221 1.1. Requirements language 223 In this document, the key words "MAY", "MUST, "MUST NOT", 224 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to 225 be interpreted as described in [RFC2119]. 227 1.2. Terminology 229 This document frequently uses the following terms: 231 Access Point 232 A Network Access Server implementing 802.11. 234 Authenticator 235 The end of the link requiring the authentication. 237 Backend Authentication Server 238 An Authentication Server is an entity that provides an 239 Authentication Service to an NAS. This service verifies from 240 the credentials provided by the peer, the claim of identity 241 made by the peer. 243 EAP server 244 The EAP server is the entity that terminates the EAP 245 conversation with the peer. The EAP server may reside on the 246 NAS, or alternatively within a backend authentication server. 248 Link layer ciphersuite 249 The ciphersuite negotiated for use at the link layer. 251 Master key 252 The key derived between the EAP client and EAP server during 253 the EAP authentication process. 255 Master session key 256 The keys derived from the master key are subsequently 257 used in generation of the transient session keys for 258 authentication, encryption, binding exchange, and 259 IV-generation. 261 NAS Short for "Network Access Server". 263 Peer 264 The other end of the point-to-point link (PPP), 265 point-to-point LAN segment (IEEE 802.1X) or 802.11 266 wireless link, which is being authenticated by the NAS. 267 In IEEE 802.1X, this end is known as the Supplicant. 269 TLS Ciphersuite 270 The ciphersuite negotiated for protection of the PEAP Part 2 271 conversation. 273 Transient session keys 274 The transient session keys are derived from the master session 275 keys, and are of the appropriate size and type for use with 276 the chosen link layer ciphersuite. 278 1.3. Operational model 280 In EAP, the EAP server may be implemented either within a Network 281 Access Server (NAS) or on a backend authentication server. Where the 282 EAP server resides on a NAS, the NAS is required to implement the 283 desired EAP methods, and therefore needs to be upgraded to support 284 each new EAP method. 286 One of the goals of EAP is to enable development of new 287 authentication methods without requiring deployment of new code on 288 the Network Access Server (NAS). Where a backend authentication 289 server is deployed, the NAS acts as a "passthrough" and need not 290 understand specific EAP methods. 292 This allows new EAP methods to be deployed on the EAP peer and 293 backend authentication server, without the need to upgrade code 294 residing on the NAS. 296 Figure 1 describes the relationship between the EAP peer, NAS and 297 EAP server. As described in the figure, the EAP conversation occurs 298 between the EAP peer and EAP server, "passing through" the NAS. In 299 order for the conversation to proceed in the case where the NAS and 300 EAP server reside on separate machines, the NAS and EAP server need 301 to establish trust beforehand. 303 In PEAP, the conversation between the EAP peer and the EAP server is 304 encrypted, authenticated, integrity and replay protected within a 305 TLS channel, and mutual authentication is required between the EAP 306 peer and the EAP server. 308 As a result, where the NAS acts as a "passthrough" it does not have 309 knowledge of the TLS master secret derived between the EAP Peer and 310 the EAP server. In order to provide keying material for link-layer 311 ciphersuites, the NAS obtains the master session keys, which are 312 derived from the TLS master secret via a one-way function. This 313 enables the NAS and EAP peer to derive keys suitable for encrypting, 314 authenticating and integrity protecting session data. However, the 315 NAS cannot decrypt the PEAP conversation or spoof session 316 resumption, since this requires knowledge of the TLS master secret. 318 +-+-+-+-+-+ +-+-+-+-+-+ 319 | | | | 320 | Link | | Link | 321 | Layer | | Layer | 322 | Cipher- | | Cipher- | 323 | Suite | | Suite | 324 | | | | 325 +-+-+-+-+-+ +-+-+-+-+-+ 326 ^ ^ 327 | | 328 | | 329 | | 330 V V 331 +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ 332 | | EAP | |<======>| | 333 | | Conversation | | | | 334 | EAP |<================================>| EAP | 335 | Peer | (over PPP, | NAS | | Server | 336 | | 802.11,etc.) | |<=======| | 337 | | | | Keys | | 338 | | | | | | 339 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 340 ^ ^ 341 | | 342 | EAP API | EAP API 343 | | 344 V V 345 +-+-+-+-+-+ +-+-+-+-+-+ 346 | | | | 347 | | | | 348 | EAP | | EAP | 349 | Method | | Method | 350 | | | | 351 +-+-+-+-+-+ +-+-+-+-+-+ 353 Figure 1 - Relationship between EAP client, backend authentication 354 server and NAS. 356 2. Protocol overview 358 Protected EAP (PEAP) is comprised of a two-part conversation: 360 [1] In Part 1, a TLS session is negotiated, with server 361 authenticating to the client and optionally the client to the 362 server. The negotiated key is then used to encrypt the rest of 363 the conversation. 365 [2] In Part 2, within the TLS session, a complete EAP conversation 366 is carried out, unless part 1 provided client authentication. 368 In the next two sections, we provide an overview of each of the 369 parts of the PEAP conversation. 371 2.1. PEAP Part 1 373 The PEAP conversation typically begins with an optional identity 374 exchange. The authenticator will typically send an EAP- 375 Request/Identity packet to the peer, and the peer will respond with 376 an EAP-Response/Identity packet to the authenticator, containing the 377 peer's EAP-ID. Since the initial identity exchange is used 378 primarily to route the EAP conversation to the EAP server, if the 379 EAP server is known in advance (such as when all users authenticate 380 against the same backend server infrastructure and roaming is not 381 supported), or if the identity is otherwise determined (such as from 382 the dialing phone number or client MAC address), then the identity 383 exchange MAY be omitted. 385 Once the optional initial Identity Request/Response exchange is 386 completed, while nominally the EAP conversation occurs between the 387 authenticator and the peer, the authenticator MAY act as a 388 passthrough device, with the EAP packets received from the peer 389 being encapsulated for transmission to a backend authentication 390 server. However, PEAP does not require a backend authentication 391 server; if the authenticator implements PEAP and is provisioned with 392 the appropriate certificates, then it can authenticate local users. 394 In the discussion that follows, we will use the term "EAP server" to 395 denote the ultimate endpoint conversing with the peer. 397 Once having received the peer's Identity, and determined that PEAP 398 authentication is to occur, the EAP server MUST respond with a 399 PEAP/Start packet, which is an EAP-Request packet with EAP- 400 Type=PEAP,the Start (S) bit set, and no data. Assuming that the 401 peer supports PEAP, the PEAP conversation will then begin, with the 402 peer sending an EAP-Response packet with EAP-Type=PEAP. 404 The data field of the EAP-Response packet will encapsulate one or 405 more TLS records in TLS record layer format, containing a TLS 406 client_hello handshake message. The current cipher spec for the TLS 407 records will be TLS_NULL_WITH_NULL_NULL and null compression. This 408 current cipher spec remains the same until the change_cipher_spec 409 message signals that subsequent records will have the negotiated 410 attributes for the remainder of the handshake. 412 The client_hello message contains the client's TLS version number, a 413 sessionId, a random number, and a set of TLS ciphersuites supported 414 by the client. The version offered by the client MUST correspond to 415 TLS v1.0 or later. 417 The EAP server will then respond with an EAP-Request packet with 418 EAP-Type=PEAP. The data field of this packet will encapsulate one or 419 more TLS records. These will contain a TLS server_hello handshake 420 message, possibly followed by TLS certificate, server_key_exchange, 421 certificate_request, server_hello_done and/or finished handshake 422 messages, and/or a TLS change_cipher_spec message. 424 Since after the TLS session is established, another complete EAP 425 negotiation will occur and the peer will authenticate using a 426 secondary mechanism, with PEAP the client need not authenticate as 427 part of TLS session establishment. As a result, although the EAP- 428 Request packet sent by the EAP Server MAY contain a 429 certificate_request message, this is not required. 431 The certificate_request message indicates that the server desires 432 the client to authenticate itself via public key. Typically when the 433 EAP server sends a certificate_request message, the intent is to 434 complete the PEAP authentication without requiring negotiation of an 435 additional EAP method. However, it is valid for the server to 436 request a certificate in the server_hello and for the client refuse 437 to provide one. In this case, the EAP server MUST require that PEAP 438 Part 2 be completed. 440 Note that since TLS client certificates are sent in the clear, if 441 identity protection is required, then it is possible for the TLS 442 authentication to be re-negotiated after the first server 443 authentication. To accomplish this, the server will typically not 444 request a certificate in the server_hello, then after the 445 server_finished message is sent, and before PEAP part 2, the server 446 MAY send a TLS hello_request. This allows the client to perform 447 client authentication by sending a client_hello if it wants to, or 448 send a no_renegotiation alert to the server indicating that it wants 449 to continue with PEAP part 2 instead. Assuming that the client 450 permits renegotiation by sending a client_hello, then the server 451 will respond with server_hello, a certificate and 452 certificate_request messages. The client replies with certificate, 453 client_key_exchange and certificate_verify messages. Since this re- 454 negotiation occurs within the encrypted TLS channel, it does not 455 reveal client certificate details. 457 The server_hello handshake message contains a TLS version number, 458 another random number, a sessionId, and a TLS ciphersuite. The 459 version offered by the server MUST correspond to TLS v1.0 or later. 460 In order to provide confidentiality, integrity and replay 461 protection, and authentication, the negotiated TLS ciphersuite MUST 462 provide all of these security services. 464 If the client's sessionId is null or unrecognized by the server, the 465 server MUST choose the sessionId to establish a new session; 466 otherwise, the sessionId will match that offered by the client, 467 indicating a resumption of the previously established session with 468 that sessionId. The server will also choose a TLS ciphersuite from 469 those offered by the client; if the session matches the client's, 470 then the TLS ciphersuite MUST match the one negotiated during the 471 handshake protocol execution that established the session. 473 PEAP implementations need not necessarily support all TLS 474 ciphersuites listed in [RFC2246]. Not all TLS ciphersuites are 475 supported by available TLS tool kits and licenses may be required to 476 support some TLS ciphersuites (e.g. TLS ciphersuites utilizing the 477 IDEA encryption algorithm). To ensure interoperability, PEAP peers 478 and Authenticators MUST support and be able to negotiate the 479 following TLS ciphersuites: 481 TLS_RSA_WITH_RC4_128_MD5 482 TLS_RSA_WITH_RC4_128_SHA 483 TLS_RSA_WITH_3DES_EDE_CBC_SHA (FIPS compliant) 485 TLS as described in [RFC2246] supports compression as well as 486 ciphersuite negotiation. Therefore during the PEAP Part 1 487 conversation the EAP endpoints MAY request or negotiate TLS 488 compression. 490 If the EAP server is not resuming a previously established session, 491 then it MUST include a TLS server_certificate handshake message, and 492 a server_hello_done handshake message MUST be the last handshake 493 message encapsulated in this EAP-Request packet. 495 The certificate message contains a public key certificate chain for 496 either a key exchange public key (such as an RSA or Diffie-Hellman 497 key exchange public key) or a signature public key (such as an RSA 498 or DSS signature public key). In the latter case, a TLS 499 server_key_exchange handshake message MUST also be included to allow 500 the key exchange to take place. 502 The peer MUST respond to the EAP-Request with an EAP-Response packet 503 of EAP-Type=PEAP. The data field of this packet will encapsulate 504 one or more TLS records containing a TLS change_cipher_spec message 505 and finished handshake message, and possibly certificate, 506 certificate_verify and/or client_key_exchange handshake messages. 507 If the preceding server_hello message sent by the EAP server in the 508 preceding EAP-Request packet indicated the resumption of a previous 509 session, then the peer MUST send only the change_cipher_spec and 510 finished handshake messages. 512 The finished message contains the peer's authentication response to 513 the EAP server. 515 If the preceding server_hello message sent by the EAP server in the 516 preceding EAP-Request packet did not indicate the resumption of a 517 previous session, then the peer MUST send, in addition to the 518 change_cipher_spec and finished messages, a client_key_exchange 519 message, which completes the exchange of a shared master secret 520 between the peer and the EAP server. 522 The EAP server MUST then respond with an EAP-Request packet with 523 EAP-Type=PEAP, which includes, in the case of a new TLS session, one 524 or more TLS records containing TLS change_cipher_spec and finished 525 handshake messages. The latter contains the EAP server's 526 authentication response to the peer. The peer will then verify the 527 hash in order to authenticate the EAP server. 529 If the EAP server authenticates unsuccessfully, the peer MAY send an 530 EAP-Response packet of EAP-Type=PEAP containing a TLS Alert message 531 identifying the reason for the failed authentication. The peer MAY 532 send a TLS alert message rather than immediately terminating the 533 conversation so as to allow the EAP server to log the cause of the 534 error for examination by the system administrator. 536 To ensure that the EAP Server receives the TLS alert message, the 537 peer MUST wait for the EAP-Server to reply before terminating the 538 conversation. The EAP Server MUST reply with an EAP-Failure packet 539 since server authentication failure is a terminal condition. 541 If the EAP server authenticates successfully, the peer MUST send an 542 EAP-Response packet of EAP-Type=PEAP, and no data. The EAP-Server 543 then continues with Part 2 of the PEAP conversation. 545 2.2. PEAP Part 2 547 The second portion of the PEAP conversation consists of another 548 complete EAP conversation occurring within the TLS session 549 negotiated in PEAP Part 1. It will therefore occur only if 550 establishment of a new TLS session in Part 1 is successful or a TLS 551 session is successfully resumed in Part 1. 553 It MUST NOT occur if the EAP Server authenticates unsuccessfully or 554 if an EAP-Failure has been sent by the EAP Server to the peer, 555 terminating the conversation. Since all packets sent within the 556 PEAP Part 2 conversation occur after TLS session establishment, they 557 are protected using the negotiated TLS ciphersuite. All EAP packets 558 of the EAP conversation in part 2 including the EAP header are 559 protected using the negotiated TLS ciphersuite. 561 Part 2 of the PEAP conversation typically begins with the 562 Authenticator sending an EAP-Request/Identity packet to the peer, 563 protected by the TLS ciphersuite negotiated in PEAP Part 1. The peer 564 responds with an EAP-Response/Identity packet to the authenticator, 565 containing the peer's userId. Since this Identity Request/Response 566 exchange is protected by 567 the ciphersuite negotiated in TLS, it is protected against snooping 568 or packet modification attacks. 570 After the TLS session-protected Identity exchange, the EAP server 571 will then select authentication method(s) for the peer, and will 572 send an EAP-Request with the EAP-Type set to the initial method. As 573 described in [RFC2284], the peer can NAK the suggested EAP method, 574 suggesting an alternative. Since the NAK will be sent within the TLS 575 channel, it is protected from snooping or packet modification. As a 576 result, an attacker snooping on the exchange will be unable to 577 inject NAKs in order to "negotiate down" the authentication method. 578 An attacker will also not be able to determine which EAP method was 579 negotiated. 581 2.3. Version negotiation 583 PEAP packets contain a three bit version field, which enables PEAP 584 implementations to be backward compatible with previous versions of 585 the protocol. Implementations of this specification MUST use a 586 version field set to 2. This specification documents the protocol 587 for version 2. 589 Version negotiation proceeds as follows: 591 [1] In the first EAP-Request sent with EAP type=PEAP, the EAP 592 server MUST set the version field to the highest supported version 593 number. 595 [2] If the EAP client supports this version of the protocol, it 596 MUST respond with an EAP-Response of EAP type=PEAP, and the version 597 number proposed by the EAP server. 599 [3] If the EAP client does not support this version, it responds 600 with an EAP-Response of EAP type=PEAP and the highest supported 601 version number. 603 [4] If the EAP server supports the version proposed by the client, 604 then all future EAP-Request packets of EAP type=PEAP MUST include 605 the version field set to the agreed upon version number. Similarly, 606 the EAP client MUST include the agreed upon version number in all 607 EAP-Response packets of EAP type=PEAP. 609 [5] If the PEAP server does not support the version number proposed 610 by the PEAP client, it terminates the conversation, as described in 611 Section 2.4. 613 This version negotiation procedure guarantees that the EAP client 614 and server will agree to the latest version supported by both 615 parties. If version negotiation fails, then use of PEAP will not be 616 possible, and another mutually acceptable EAP method will need to be 617 negotiated if authentication is to proceed. In order to protect 618 against a downgrade version attack between PEAP versions support by 619 the peers, the peers MUST exchange information on the highest 620 version number supported during the binding exchange. 622 2.4. Termination 623 As described in [RFC2284], EAP Success and Failure packets are not 624 authenticated, so that they may be forged by an attacker without 625 fear of detection. Forged EAP Failure packets can be used to 626 convince an EAP peer to disconnect. Forged EAP Success packets may 627 be used by a rogue NAS to convince a peer to let itself access the 628 network, even though the NAS has not authenticated itself. 630 By requiring mutual authentication and by supporting encrypted, 631 authenticated and integrity protected success/failure indications, 632 (described below as "protected" indications) PEAP provides 633 protection against these attacks. Within PEAP, protected 634 success/failure indications are supported by sending these 635 indications within the TLS channel. 637 PEAP support for protected success/failure indications is 638 constrained by the [RFC2284] and [IEEE8021X] specifications. In 639 [IEEE8021X], the authenticator "manufactures" cleartext EAP Success 640 and Failure packets based on the result indicated by the backend 641 authentication server. As a result, were a PEAP server to send a 642 protected EAP Success or EAP Failure packet as the final packet 643 within the EAP exchange, authenticators compliant with [IEEE8021X] 644 would silently discard the packet, and replace it with a cleartext 645 EAP Success or Failure. Since the client will discard these 646 unprotected indications, where an authenticator compliant with 647 [IEEE8021X] is present, it is not be possible to conclude a 648 successful authentication. As a result, this approach does not 649 provide reliable authenticated success/failure indications on all 650 media. 652 In addition, [RFC2284] states that an EAP Success or EAP Failure 653 packet terminates the EAP conversation, so that no response is 654 possible. Since EAP Success and EAP Failure packets are not 655 retransmitted, if the final packet is lost, then authentication will 656 fail. As a result, where packet loss is expected to be non- 657 negligible, unacknowledged success/failure indications lack 658 robustness. 660 As a result, a PEAP server SHOULD NOT send a protected EAP Success 661 or EAP Failure packet as the final packet within a PEAP 662 conversation. However, in the spirit of being "conservative in what 663 you send, liberal in what you receive", a PEAP client SHOULD accept 664 and process such a packet if it is received. This behavior makes it 665 possible for implementations to save a round-trip (improving the 666 performance of fast reconnect), assuming that the authentication 667 occurs within a low packet loss environment in which "manufacture" 668 of packets is guaranteed not to occur. 670 Instead, EAP servers MUST utilize the acknowledged and protected 671 success/failure indications defined in Section 4. In this approach, 672 the PEAP server sends the success/failure indication as an EAP- 673 Request with type=33 (EAP TLV), protected within the TLS channel. 674 The PEAP client then replies with a protected success/failure 675 indication as an EAP-Response with type=33 (EAP TLV). The 676 conversation concludes with the PEAP server sending a cleartext 677 success/failure indication. 679 Since both sides have already concluded a protected termination 680 conversation, this final packet is ceremonial. 682 Use of a protected and acknowledged success/failure indication 683 provides the PEAP protocol immunity against the "manufacture" of 684 cleartext success/failure indications mandated by [IEEE8021X]. It 685 also enables both sides of the conversation to communicate the 686 outcome of PEAP mutual authentication, although the TLS alert 687 mechanism already provides this capability to some extent. On the 688 other hand, this approach requires an extra round-trip, which 689 affects the performance of fast reconnect. 691 Once PEAP has been selected as the authentication method, compliant 692 PEAP implementations MUST silently discard unprotected success 693 indications (e.g. cleartext EAP Success) unless both the PEAP peer 694 and server have indicated a successful authentication exchange via 695 the mechanism described in Section 4. 697 Similarly, once the TLS channel has been set up, compliant PEAP 698 implementations MUST silently discard unprotected failure 699 indications (e.g. cleartext EAP Failure) unless they are proceeded 700 by a protected failure indication. Protected failure indications 701 include the TLS alert mechanism, as well the indication mechanism 702 described in Section 4. For example, if a PEAP peer has previously 703 received a protected EAP-Request of Type=33 (EAP TLV) with 704 Result=Failure, or if it has received a protected EAP-Request of 705 Type=33 (EAP-TLV) with Result=Success, and responded with a 706 protected EAP-Response of Type=33 (EAP-TLV) with Result=Failure, 707 then it will accept and process a cleartext EAP Failure. 708 However, if a PEAP peer has previously received a protected EAP- 709 Request of Type=33 (EAP-TLV) with Result=Success, and has responded 710 with a protected EAP-Request of Type=33 (EAP-TLV) with 711 Result=Success, then an unprotected failure indication MUST be 712 silently discarded. 714 Prior to establishment of the TLS channel, no keying material 715 exists, so that protected success/failure indications are not 716 possible. However, within PEAP a failure to establish the TLS 717 channel (e.g. failure to verify the server certificate) is 718 considered an unrecoverable error, so that where this failure has 719 occurred, an unprotected failure indication can be safely accepted. 721 2.5. Error handling 723 Other than supporting TLS alert messages, PEAP does not have its own 724 error message capabilities. This is unnecessary since errors in the 725 PEAP Part 1 conversation are communicated via TLS alert messages, 726 and errors in the PEAP Part 2 conversation are expected to be 727 handled by individual EAP methods. 729 If an error occurs at any point in the PEAP conversation, the EAP 730 server SHOULD send an EAP-Request packet with EAP-Type=PEAP, 731 encapsulating a TLS record containing the appropriate TLS alert 732 message. The EAP server SHOULD send a TLS alert message rather than 733 immediately terminating the conversation so as to allow the peer to 734 inform the user of the cause of the failure and possibly allow for a 735 restart of the conversation. To ensure that the peer receives the 736 TLS alert message, the EAP server MUST wait for the peer to reply 737 with an EAP-Response packet. 739 2.6. Retry behavior 741 As with other EAP protocols, the EAP server is responsible for retry 742 behavior. This means that if the EAP server does not receive a reply 743 from the peer, it MUST resend the EAP-Request for which it has not 744 yet received an EAP-Response. However, the peer MUST NOT resend EAP- 745 Response packets without first being prompted by the EAP server. 747 For example, if the initial PEAP start packet sent by the EAP server 748 were to be lost, then the peer would not receive this packet, and 749 would not respond to it. As a result, the PEAP start packet would be 750 resent by the EAP server. Once the peer received the PEAP start 751 packet, it would send an EAP-Response encapsulating the client_hello 752 message. If the EAP-Response were to be lost, then the EAP server 753 would resend the initial PEAP start, and the peer would resend the 754 EAP-Response. 756 As a result, it is possible that a peer will receive duplicate EAP- 757 Request messages, and may send duplicate EAP-Responses. Both the 758 peer and the EAP Server should be engineered to handle this 759 possibility. 761 2.7. Session resumption 763 The purpose of the sessionId within the TLS protocol is to allow for 764 improved efficiency in the case where a client repeatedly attempts 765 to authenticate to an EAP server within a short period of time. This 766 capability is particularly useful for support of wireless roaming. 768 It is left up to the peer whether to attempt to continue a previous 769 session, thus shortening the PEAP Part 1 conversation. Typically the 770 peer's decision will be made based on the time elapsed since the 771 previous authentication attempt to that EAP server. 773 Based on the sessionId chosen by the peer, and the time elapsed 774 since the previous authentication, the EAP server will decide 775 whether to allow the continuation, or whether to choose a new 776 session. 778 In the case where the EAP server and the authenticator reside on the 779 same device, then the client will only be able to continue sessions 780 when connecting to the same NAS or channel server. Should these 781 devices be set up in a rotary or round-robin then it may not be 782 possible for the peer to know in advance the authenticator it will 783 be connecting to, and therefore which sessionId to attempt to reuse. 784 As a result, it is likely that the continuation attempt will fail. 786 In the case where the EAP authentication is remoted then 787 continuation is much more likely to be successful, since multiple 788 NAS devices and channel servers will remote their EAP 789 authentications to the same backend authentication server. 791 If the EAP server is resuming a previously established session, then 792 it MUST include only a TLS change_cipher_spec message and a TLS 793 finished handshake message after the server_hello message. The 794 finished message contains the EAP server's authentication response 795 to the peer. 797 After a session is successfully resumed, the EAP-Server starts with 798 Part 2 of the PEAP conversation. The peer may have roamed to a 799 different network and successfully resumed with same EAP server. The 800 peer and the EAP server MUST not assume that a session resume 801 implies either of them will skip inner EAP methods. 803 2.8. Fragmentation 805 A single TLS record may be up to 16384 octets in length, but a TLS 806 message may span multiple TLS records, and a TLS certificate message 807 may in principle be as long as 16MB. The group of PEAP messages sent 808 in a single round may thus be larger than the PPP MTU size, the 809 maximum RADIUS packet size of 4096 octets, or even the Multilink 810 Maximum Received Reconstructed Unit (MRRU). As described in [2], 811 the multilink MRRU is negotiated via the Multilink MRRU LCP option, 812 which includes an MRRU length field of two octets, and thus can 813 support MRRUs as large as 64 KB. 815 However, note that in order to protect against reassembly lockup and 816 denial of service attacks, it may be desirable for an implementation 817 to set a maximum size for one such group of TLS messages. Since a 818 typical certificate chain is rarely longer than a few thousand 819 octets, and no other field is likely to be anywhere near as long, a 820 reasonable choice of maximum acceptable message length might be 64 821 KB. 823 If this value is chosen, then fragmentation can be handled via the 824 multilink PPP fragmentation mechanisms described in [RFC1990]. While 825 this is desirable, EAP methods are used in other applications such 826 as [IEEE80211] and there may be cases in which multilink or the MRRU 827 LCP option cannot be negotiated. As a result, a PEAP implementation 828 MUST provide its own support for fragmentation and reassembly. 830 Since EAP is an ACK-NAK protocol, fragmentation support can be added 831 in a simple manner. In EAP, fragments that are lost or damaged in 832 transit will be retransmitted, and since sequencing information is 833 provided by the Identifier field in EAP, there is no need for a 834 fragment offset field as is provided in IPv4. 836 PEAP fragmentation support is provided through addition of flag bits 837 within the EAP-Response and EAP-Request packets, as well as a TLS 838 Message Length field of four octets. Flags include the Length 839 included (L), More fragments (M), and PEAP Start (S) bits. The L 840 flag is set to indicate the presence of the four octet TLS Message 841 Length field, and MUST be set for the first fragment of a fragmented 842 TLS message or set of messages. The M flag is set on all but the 843 last fragment. The S flag is set only within the PEAP start message 844 sent from the EAP server to the peer. The TLS Message Length field 845 is four octets, and provides the total length of the TLS message or 846 set of messages that is being fragmented; this simplifies buffer 847 allocation. 849 When a PEAP peer receives an EAP-Request packet with the M bit set, 850 it MUST respond with an EAP-Response with EAP-Type=PEAP and no data. 851 This serves as a fragment ACK. The EAP server MUST wait until it 852 receives the EAP-Response before sending another fragment. In order 853 to prevent errors in processing of fragments, the EAP server MUST 854 increment the Identifier field for each fragment contained within an 855 EAP-Request, and the peer MUST include this Identifier value in the 856 fragment ACK contained within the EAP-Response. Retransmitted 857 fragments will contain the same Identifier value. 859 Similarly, when the EAP server receives an EAP-Response with the M 860 bit set, it MUST respond with an EAP-Request with EAP-Type=PEAP and 861 no data. This serves as a fragment ACK. The EAP peer MUST wait until 862 it receives the EAP-Request before sending another fragment. In 863 order to prevent errors in the processing of fragments, the EAP 864 server MUST increment the Identifier value for each fragment ACK 865 contained within an EAP-Request, and the peer MUST include this 866 Identifier value in the subsequent fragment contained within an EAP- 867 Response. 869 2.9. Key derivation 871 Since the normal TLS keys are used in the handshake, and therefore 872 should not be used in a different context, new keys must be derived 873 from the TLS master secret for use with the selected link layer 874 ciphersuites. 876 In the most general case, keying material must be provided for 877 authentication, encryption and initialization vectors (IVs) in each 878 direction. 880 Since EAP methods may not know the link layer ciphersuite that has 881 been negotiated, it may not be possible for them to provide link 882 layer ciphersuite-specific keys. In addition, attempting to provide 883 such keys is undesirable, since it would require the EAP method to 884 be revised each time a new link layer ciphersuite is developed. As a 885 result, PEAP derives master session keys which can subsequently be 886 truncated for use with a particular link layer ciphersuite. Since 887 the truncation algorithms are ciphersuite-specific, they are not 888 discussed here; examples of such algorithms are provided in 889 [RFC3079]. This draft also does not discuss the format of the 890 attributes used to communicate the master session keys from the 891 backend authentication server to the NAS; examples of such 892 attributes are provided in [RFC2548]. 894 Both the peer and EAP server MUST derive master session keys as 895 described in the compound Session Key derivation section (section 896 4.2) of the draft Compound Authentication Binding Problem 897 [compoundbinding]. 899 Algorithms for the truncation of these encryption and authentication 900 master session keys are specific to each link layer ciphersuite. 901 Link layer ciphersuites in use with PPP include DESEbis [RFC2419], 902 3DES [RFC2420] and MPPE [RFC3078]. IEEE 802.11 ciphersuites are 903 described in [IEEE80211]. An example of how encryption keys for use 904 with MPPE [RFC3078] are derived from the TLS master session keys is 905 given in [RFC3079]. 907 2.10. Ciphersuite negotiation 909 Since TLS supports TLS ciphersuite negotiation, peers completing the 910 TLS negotiation will also have selected a TLS ciphersuite, which 911 includes key strength, encryption and hashing methods. However, 912 unlike in [RFC2716], within PEAP, the negotiated TLS ciphersuite 913 relates only to the mechanism by which the PEAP Part 2 conversation 914 will be protected, and has no relationship to link layer security 915 mechanisms negotiated within the PPP Encryption Control Protocol 916 (ECP) [RFC1968] or within IEEE 802.11 [IEEE80211]. 918 As a result, this specification currently does not support secure 919 negotiation of link layer ciphersuites, although this capability may 920 be added in future by addition of TLVs to the EAP TLV method defined 921 in Section 4. 923 3. Detailed description of the PEAP protocol 925 3.1. PEAP Packet Format 927 A summary of the PEAP Request/Response packet format is shown below. 928 The fields are transmitted from left to right. 930 0 1 2 3 931 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Code | Identifier | Length | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Type | Flags | Ver | Data... 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 Code 941 1 - Request 942 2 - Response 944 Identifier 946 The Identifier field is one octet and aids in matching responses 947 with requests. 949 Length 951 The Length field is two octets and indicates the length of the 952 EAP packet including the Code, Identifier, Length, Type, and Data 953 fields. Octets outside the range of the Length field should be 954 treated as Data Link Layer padding and should be ignored on 955 reception. 957 Type 959 25 - PEAP 961 Flags 963 0 1 2 3 4 964 +-+-+-+-+-+ 965 |L M S R R| 966 +-+-+-+-+-+ 968 L = Length included 969 M = More fragments 970 S = PEAP start 971 R = Reserved (must be zero) 973 The L bit (length included) is set to indicate the presence of 974 the four octet TLS Message Length field, and MUST be set for the 975 first fragment of a fragmented TLS message or set of messages. The M 976 bit(more fragments) is set on all but the last fragment. The S bit 977 (PEAP start) is set in a PEAP Start message. This differentiates the 978 PEAP Start message from a fragment acknowledgment. 980 Version 982 0 1 2 983 +-+-+-+ 984 |R|1|0| 985 +-+-+-+ 987 R = Reserved (must be zero) 989 Data 991 The format of the Data field is determined by the Code field. 993 3.2. PEAP Request Packet 995 A summary of the PEAP Request packet format is shown below. The 996 fields 997 are transmitted from left to right. 999 0 1 2 3 1000 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 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Code | Identifier | Length | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Type | Flags | Ver | TLS Message Length 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | TLS Message Length | TLS Data... 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Code 1011 1 1013 Identifier 1015 The Identifier field is one octet and aids in matching responses 1016 with requests. The Identifier field MUST be changed on each Request 1017 packet. 1019 Length 1021 The Length field is two octets and indicates the length of the 1022 EAP packet including the Code, Identifier, Length, Type, and TLS 1023 Response fields. 1025 Type 1027 25 - PEAP 1029 Flags 1031 0 1 2 3 4 1032 +-+-+-+-+-+ 1033 |L M S R R| 1034 +-+-+-+-+-+ 1035 L = Length included 1036 M = More fragments 1037 S = PEAP start 1038 R = Reserved (must be zero) 1040 The L bit (length included) is set to indicate the presence of 1041 the four octet TLS Message Length field, and MUST be set for the 1042 first fragment of a fragmented TLS message or set of messages. The M 1043 bit(more fragments) is set on all but the last fragment. The S bit 1044 (PEAP start) is set in a PEAP Start message. This differentiates the 1045 PEAP Start message from a fragment acknowledgment. 1047 Version 1049 0 1 2 1050 +-+-+-+ 1051 |R|1|0| 1052 +-+-+-+ 1054 R = Reserved (must be zero) 1056 TLS Message Length 1058 The TLS Message Length field is four octets, and is present only 1059 if the L bit is set. This field provides the total length of the 1060 TLS message or set of messages that is being fragmented. 1062 TLS data 1064 The TLS data consists of the encapsulated packet in TLS record 1065 format. 1067 3.3. PEAP Response Packet 1069 A summary of the PEAP Response packet format is shown below. The 1070 fields are transmitted from left to right. 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Code | Identifier | Length | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Type | Flags |Ver| TLS Message Length 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | TLS Message Length | TLS Data... 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 Code 1084 2 1086 Identifier 1087 The Identifier field is one octet and MUST match the Identifier 1088 field from the corresponding request. 1090 Length 1092 The Length field is two octets and indicates the length of the 1093 EAP packet including the Code, Identifier, Length, Type, and TLS 1094 data fields. 1096 Type 1098 25 - PEAP 1100 Flags 1102 0 1 2 3 4 1103 +-+-+-+-+-+ 1104 |L M S R R| 1105 +-+-+-+-+-+ 1107 L = Length included 1108 M = More fragments 1109 S = PEAP start 1110 R = Reserved (must be zero) 1112 The L bit (length included) is set to indicate the presence of 1113 the four octet TLS Message Length field, and MUST be set for the 1114 first fragment of a fragmented TLS message or set of messages. The M 1115 bit (more fragments) is set on all but the last fragment. The S bit 1116 (PEAP start) is set in a PEAP Start message. This differentiates the 1117 PEAP Start message from a fragment acknowledgment. 1119 Version 1121 0 1 2 1122 +-+-+-+ 1123 |R|1|0| 1124 +-+-+-+ 1126 R = Reserved (must be zero) 1128 TLS Message Length 1130 The TLS Message Length field is four octets, and is present only 1131 if the L bit is set. This field provides the total length of the TLS 1132 message or set of messages that is being fragmented. 1134 TLS data 1136 The TLS data consists of the encapsulated TLS packet in TLS record 1137 format. 1139 4. EAP TLV method 1141 The EAP-TLV method is a payload with standard Type-Length-Value 1142 (TLV) objects. The TLV objects could be used to carry arbitrary 1143 parameters between EAP peer and EAP server. Possible uses for TLV 1144 objects include: language and character set for Notification 1145 messages; cryptographic binding; IPv6 Binding Update. 1147 The EAP peer may not necessarily implement all the TLVs supported by 1148 the EAP server; and hence to allow for interoperability, the TLV 1149 method allows a EAP server to discover if a TLV is supported by the 1150 EAP peer, using the NAK TLV. 1152 The mandatory bit in a TLV indicates that the peer MUST understand 1153 the TLV. A peer can determine that a TLV is unknown when it does not 1154 support the TLV; or when the TLV is corrupted. The mandatory bit 1155 does not indicate that the peer successfully applied the value of 1156 the TLV. The specification of a TLV could define additional 1157 conditions under which the TLV can be determined to be unknown. 1159 If an EAP peer finds an unknown TLV which is marked as mandatory; it 1160 MUST indicate a failure to the EAP server using the NAK TLV; and all 1161 the other TLVs in the message MUST be ignored. 1163 If an EAP peer finds an unknown TLV which is marked as optional; 1164 then it MUST ignore the TLV. The EAP peer is not required to inform 1165 the EAP server of unknown TLVs which are marked as optional. If the 1166 EAP peer finds that the packet has no TLVs, then it MUST send a 1167 response with EAP-TLV Response Packet. The Response packet may 1168 contain no TLVs. 1170 If an EAP server finds an unknown TLV which is marked as mandatory; 1171 the other TLVs in the message MUST be ignored. The EAP server can 1172 drop the connection or send a EAP-TLV request packet with NAK-TLV to 1173 the EAP client. 1175 Compliant PEAP implementations MUST support the EAP TLV method, 1176 processing of mandatory/optional settings on the TLV, the NAK TLV. 1178 TLVs can be contained/nested in other TLVs. A EAP-TLV Request packet 1179 is a EAP method; and it can be sequenced before or after any other 1180 EAP method. The packet does not have to contain any TLVs or does not 1181 have to contain any mandatory TLVs. 1183 4.1. Protected success/failure 1185 Compliant PEAP implementations MUST support acknowledged protected 1186 success/failure together with the Binding exchange. 1188 The Result TLV is used to indicate success or failure of the PEAP 1189 tunnel. The PEAP tunnel success/failure packet MUST contain a Result 1190 TLV along with the Cryto-Binding TLV. Crypto-Binding TLV may be used 1191 in other EAP-TLV packets. Result TLV MUST NOT be sent in packets 1192 other than the protected success/failure indication. 1194 If a CRYPTO BINDING TLV does not exist in a packet that contains 1195 Result TLV, then the EAP peer must disconnect the connection. 1197 If a CRYPTO BINDING TLV fails validation, then peer must disconnect 1198 the connection. Implementations that can delete the TLS handle MUST 1199 delete the TLS handle. Implementations that keep track of session 1200 state MUST ensure that the session handle cannot be used to skip 1201 stage2 authentication. 1203 When using the Result-TLV, the only outcome which should be 1204 considered as successful authentication is when an EAP Request of 1205 Type=EAP-TLVs with Result TLV of Status=Success is answered by an 1206 EAP Response of Type=EAP-TLVs with Result TLV of Status=Success. 1208 If the EAP server has set Result-TLV with Status=Success; and the 1209 response from the EAP peer is Status=Failure, then the server MUST 1210 either continue EAP conversation or return Result=TLV with 1211 Status=Failure. This allows EAP peer to indicate that it refuses to 1212 accept the authentication without negotiating certain auth methods 1213 as per its policy. 1215 All other combinations (EAP-TLVs Failure, EAP-TLVs Success), (EAP- 1216 TLVs Failure, EAP-TLVs Failure), (no EAP-TLVs exchange or no 1217 protected EAP Success or Failure, no Crypto-Binding TLVs, crypto- 1218 binding TLV validation is not successful) should be considered 1219 failed authentications, both by the PEAP peer and authenticator. 1220 Once the PEAP peer and authenticator considers them as failed 1221 authentications, they are the last packets inside the protected 1222 tunnel. These are considered failed authentications regardless of 1223 whether a cleartext EAP Success or EAP Failure packet is 1224 subsequently sent. Because the EAP-TLVs method is protected within 1225 the TLS channel, these packets cannot be spoofed, whereas cleartext 1226 EAP Success and EAP Failure messages can be sent by an attacker. 1228 In order for the validation of crypto-binding TLV to be successful, 1229 the EAP server and EAP peer should be in-sync on which EAP methods 1230 inside the tunnel have been successful. If any or all EAP methods 1231 inside the tunnels have failed as per EAP server or EAP peer, then 1232 that does not mean the Result will always be set to failure. 1234 In a successful authentication for a tunnel, the last packet 1235 exchange (both request and response) inside the tunnel MUST always 1236 contain a valid Crypto-Binding TLV and Result-TLV=Success. 1238 Compliant PEAP implementations MUST support the EAP TLV method, 1239 processing of mandatory/optional settings on the TLV, the NAK TLV, 1240 Result-TLV, Method-Identity-TLV, Crypto-Binding-TLV. 1242 4.2. EAP-TLV Request Packet 1244 A summary of the EAP EAP-TLVs Request packet format is shown below. 1245 The fields are transmitted from left to right. 1247 0 1 2 3 1248 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 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Code | Identifier | Length | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Type | Data.... 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 Code 1257 1 1259 Identifier 1261 The Identifier field is one octet and aids in matching responses 1262 with requests. The Identifier field MUST be changed on each Request 1263 packet. 1265 Length 1267 The Length field is two octets and indicates the length of the 1268 EAP packet including the Code, Identifier, Length, Type, and Data 1269 fields. 1271 Type 1273 33 - EAP-TLV 1275 Data 1277 The Data field is of variable length, and contains EAP-TLV TLVs. 1279 4.3. EAP-TLV Response Packet 1281 A summary of the EAP-TLV Response packet format is shown below. The 1282 fields are transmitted from left to right. 1284 0 1 2 3 1285 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 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Code | Identifier | Length | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Type | Data.... 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 Code 1293 2 1295 Identifier 1297 The Identifier field is one octet and aids in matching responses 1298 with requests. The Identifier field MUST be changed on each Request 1299 packet. 1301 Length 1303 The Length field is two octets and indicates the length of the 1304 EAP packet including the Code, Identifier, Length, Type, and Data 1305 fields. 1307 Type 1309 33 - EAP EAP-TLV 1311 Data 1313 The Data field is of variable length, and contains Attribute- 1314 Value Pairs (TLVs). 1316 4.4. EAP-TLV TLV format 1318 EAP-TLV TLVs are defined as follows: 1320 0 1 2 3 1321 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 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 |M|R| TLV Type | Length | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Value... 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 M 1330 0 - Non-mandatory TLV 1331 1 - Mandatory TLV 1333 R 1334 Reserved, set to 0. 1336 TLV Type 1338 A 14-bit field, denoting the attribute type. Allocated TLV Types 1339 include: 1340 0 - Reserved 1341 1 - Reserved 1342 2 - Reserved 1343 3 - - RESULT_TLV - Acknowledged Result 1344 4 - NAK_TLV 1345 5 - CRYPTO_BINDING TLV 1346 6 - METHOD_IDENTITY TLV 1348 Length 1350 The length of the Value field in octets. 1352 Value 1354 The value of the attribute. 1356 CRYPTO_BINDING_TLV and METHOD_IDENTITY_TLV are defined in the draft 1357 Compound Authentication Binding Problem[CompoundBinding]. 1359 4.5. Result TLV 1361 The Result TLV provides support for acknowledged Success and Failure 1362 messages within PEAP. It is defined as follows: 1364 0 1 2 3 1365 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 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 |M|R| TLV Type | Length | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Status | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 M 1374 1 - Mandatory TLV 1376 R 1378 Reserved, set to zero (0) 1380 TLV Type 1382 3 - Success/Failure 1384 Length 1386 2 1388 Status 1390 The status field is two octets. Values include: 1392 1 - Success 1393 2 - - Failure 1395 4.6. NAK TLV 1397 The NAK TLV allows a peer to detect when TLVs that are not supported 1398 by the other peer. It is defined as follows: 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 |M|R| TLV Type | Length | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | TLV Type number | TLVs� | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 M 1410 1 - Mandatory TLV 1412 R 1414 Reserved, set to zero (0) 1416 TLV Type 1418 4 - 1420 Length 1422 1424 TLV Type number. 1426 The field contains TLV type that is not supported. 1428 TLVs.. 1430 The field contains a list of optional TLVs. These could be used 1431 in future to send information on why the field was determined to 1432 be unknown. 1434 5. Security Considerations 1436 5.1. Authentication and integrity protection 1438 The EAP-TLV method is presumed to run before or after an EAP 1439 method that supports mutual authentication and establishes a 1440 protected channel. PEAP is such a method, and as a result the 1441 acknowledged Success and Failure messages are always protected. 1443 Note however, that [IEEE8021X] manufactures cleartext EAP Success 1444 and EAP Failure messages, so that even though the Result TLV will be 1445 protected, this will be followed by a cleartext EAP Success or EAP 1446 Failure packet. 1448 5.2. Method negotiation 1450 If the peer does not support PEAP, or does not wish to utilize PEAP 1451 authentication, it MUST respond to the initial EAP-Request/PEAP- 1452 Start with a NAK, suggesting an alternate authentication method. 1453 Since the NAK is sent in cleartext with no integrity protection or 1454 authentication, it is subject to spoofing. Unauthentic NAK packets 1455 can be used to trick the peer and Authenticator into "negotiating 1456 down" to a weaker form of authentication, such as EAP-MD5 (which 1457 only provides one way authentication and does not derive a key). 1459 Since a subsequent protected EAP conversation can take place within 1460 the TLS session, selection of PEAP as an authentication method does 1461 not limit the potential secondary authentication methods. As a 1462 result, the only legitimate reason for a peer to NAK PEAP as an 1463 authentication method is that it does not support it. Where the 1464 additional security of PEAP is required, server implementations 1465 SHOULD respond to a NAK with an EAP-Failure, terminating the 1466 authentication conversation. 1468 5.3. TLS session cache handling 1470 In cases where a TLS session has been successfully resumed, in some 1471 circumstances, it is possible for the EAP server to skip the PEAP 1472 Part 2 conversation, and successfully conclude the conversation as 1473 described in Section 2.4. 1475 PEAP "fast reconnect" is desirable in applications such as wireless 1476 roaming, since it minimizes interruptions in connectivity. It is 1477 also desirable when the "inner" EAP mechanism used is such that it 1478 requires user interaction. The user should not be required to re- 1479 authenticate herself, using biometrics, token cards or similar, 1480 every time the radio connectivity is handed over between access 1481 points in wireless environments. 1483 However, there are issues that need to be understood in order to 1484 avoid introducing security vulnerabilities. 1486 Since PEAP Part 1 may not provide client authentication, 1487 establishment of a TLS session (and an entry in the TLS session 1488 cache) does not by itself provide an indication of the peer's 1489 authenticity. The peer's authenticity is only proven after 1490 successful completion of the protected acknowledge exchange in PEAP 1491 part 2. 1493 Some PEAP implementations may not be capable of removing TLS session 1494 cache entries established in PEAP Part 1 after an unsuccessful PEAP 1495 Part 2 authentication. In such implementations, the existence of a 1496 TLS session cache entry provides no indication that the peer has 1497 previously been authenticated. As a result, implementations that do 1498 not remove TLS session cache entries after a failed PEAP Part 2 1499 authentication or failed protected ack MUST use other means than 1500 successful TLS resumption as the indicator of whether the client is 1501 authenticated or not. The implementation MUST determine that the 1502 client is authenticated only after the protected acknowledge has 1503 been successfully exchanged. Failing to do this would enable a 1504 peer to gain access by completing PEAP Part 1, tearing down the 1505 connection, re-connecting and resuming PEAP Part 1, thereby proving 1506 herself authenticated. Thus, TLS resumption MUST only be enabled if 1507 the implementation supports TLS session cache removal. 1508 If an EAP server implementing PEAP removes TLS session cache entries 1509 of peers failing PEAP Part 2 authentication, then it MAY skip the 1510 PEAP Part 2 conversation entirely after a successful session 1511 resumption, successfully terminating the PEAP conversation as 1512 described in Section 2.4. 1514 5.4. Certificate revocation 1516 Since the EAP server is on the Internet during the EAP conversation, 1517 the server is capable of following a certificate chain or verifying 1518 whether the peer's certificate has been revoked. In contrast, the 1519 peer may or may not have Internet connectivity, and thus while it 1520 can validate the EAP server's certificate based on a pre-configured 1521 set of CAs, it may not be able to follow a certificate chain or 1522 verify whether the EAP server's certificate has been revoked. 1524 In the case where the peer is initiating a voluntary Layer 2 channel 1525 using PPTP or L2TP, the peer will typically already have Internet 1526 connectivity established at the time of channel initiation. As a 1527 result, during the EAP conversation it is capable of checking for 1528 certificate revocation. 1530 As part of the TLS negotiation, the server presents a certificate to 1531 the peer. The peer SHOULD verify the validity of the EAP server 1532 certificate, and SHOULD also examine the EAP server name presented 1533 in the certificate, in order to determine whether the EAP server can 1534 be trusted. Please note that in the case where the EAP 1535 authentication is remoted, the EAP server will not reside on the 1536 same machine as the authenticator, and therefore the name in the EAP 1537 server's certificate cannot be expected to match that of the 1538 intended destination. In this case, a more appropriate test might be 1539 whether the EAP server's certificate is signed by a CA controlling 1540 the intended destination and whether the EAP server exists within a 1541 target sub-domain. 1543 In the case where the peer is attempting to obtain network access, 1544 it will not have Internet connectivity. The TLS Extensions [TLSEXT] 1545 support piggybacking of an Online Certificate Status Protocol (OCSP) 1546 response within TLS, therefore can be utilized by the peer in order 1547 to verify the validity of server certificate. However, since all TLS 1548 implementations do not implement the TLS extensions, it may be 1549 necessary for the peer to wait to check for certificate revocation 1550 until after Internet access has been obtained. In this case, the 1551 peer SHOULD conduct the certificate status check immediately upon 1552 going online and SHOULD NOT send data until it has received a 1553 positive response to the status request. If the server certificate 1554 is found to be invalid, then the peer SHOULD disconnect. 1556 5.5. Separation of the EAP server and the authenticator 1558 As a result of a complete PEAP Part 1 and Part 2 conversation, the 1559 EAP endpoints will mutually authenticate, and derive a session key 1560 for subsequent use in link layer security. Since the peer and EAP 1561 client reside on the same machine, it is necessary for the EAP 1562 client module to pass the session key to the link layer encryption 1563 module. 1565 The situation may be more complex on the Authenticator, which may or 1566 may not reside on the same machine as the EAP server. In the case 1567 where the EAP server and the Authenticator reside on different 1568 machines, there are several implications for security. Firstly, the 1569 mutual authentication defined in PEAP will occur between the peer 1570 and the EAP server, not between the peer and the authenticator. This 1571 means that as a result of the PEAP conversation, it is not possible 1572 for the peer to validate the identity of the NAS or channel server 1573 that it is speaking to. 1575 The second issue is that the session key negotiated between the peer 1576 and EAP server will need to be transmitted to the authenticator. 1577 Therefore a mechanism needs to be provided to transmit the session 1578 key from the EAP server to the authenticator or channel server that 1579 needs to use the key. The specification of this transit mechanism is 1580 outside the scope of this document. 1582 5.6. Separation of PEAP Part 1 and Part 2 Servers 1584 The EAP server involved in PEAP Part 2 need not necessarily be the 1585 same as the EAP server involved in PEAP Part 1. For example, a local 1586 authentication server or proxy might serve as the endpoint for the 1587 Part 1 conversation, establishing the TLS channel. Subsequently, 1588 once the EAP-Response/Identity has been received within the TLS 1589 channel, it can be decrypted and forwarded in cleartext to the 1590 destination realm EAP server. The rest of the conversation will 1591 therefore occur between the destination realm EAP server and the 1592 peer, with the local authentication server or proxy acting as an 1593 encrypting/decrypting gateway. This permits a non-TLS capable EAP 1594 server to participate in the PEAP conversation. 1596 Note however that such an approach introduces security 1597 vulnerabilities. Since the EAP Response/Identity is sent in the 1598 clear between the proxy and the EAP server, this enables an attacker 1599 to snoop the user's identity. It also enables a remote 1600 environments, which may be public hot spots or Internet coffee 1601 shops, to gain knowledge of the identity of their users. Since one 1602 of the potential benefits of PEAP is identity protection, this is 1603 undesirable. 1605 If the EAP method negotiated during PEAP Part 2 does not support 1606 mutual authentication, then if the Part 2 conversation is proxied to 1607 another destination, the PEAP peer will not have the opportunity to 1608 verify the secondary EAP server's identity. Only the initial EAP 1609 server's identity will have been verified as Part of TLS session 1610 establishment. 1612 Similarly, if the EAP method negotiated during PEAP Part 2 is 1613 vulnerable to dictionary attack, then an attacker capturing the 1614 cleartext exchange will be able to mount an offline dictionary 1615 attack on the password. 1617 Finally, when a Part 2 conversation is terminated at a different 1618 location than the Part 1 conversation, the Part 2 destination is 1619 unaware that the EAP client has negotiated PEAP. As a result, it is 1620 unable to enforce policies requiring PEAP. Since some EAP methods 1621 require PEAP in order to generate keys or lessen security 1622 vulnerabilities, where such methods are in use, such a configuration 1623 may be unacceptable. 1625 In summary, PEAP encrypting/decrypting gateway configurations are 1626 vulnerable to attack and SHOULD NOT be used. Instead, the entire 1627 PEAP connection SHOULD be proxied to the final destination, and the 1628 subsequently derived master session keys need to be transmitted 1629 back. This provides end to end protection of PEAP. The 1630 specification of this transit mechanism is outside the scope of this 1631 document, but mechanisms similar to [RFC2548] can be used. These 1632 steps protects the client from revealing her identity to the remote 1633 environment. 1635 In order to find the proper PEAP destination, the EAP client SHOULD 1636 place a Network Access Identifier (NAI) conforming to [RFC2486] in 1637 the Identity Response. 1639 There may be cases where a natural trust relationship exists between 1640 the (foreign) authentication server and final EAP server, such as on 1641 a campus or between two offices within the same company, where there 1642 is no danger in revealing the identity of the station to the 1643 authentication server. In these cases, using a proxy solution 1644 without end to end protection of PEAP MAY be used. The PEAP 1645 encrypting/decrypting gateway SHOULD provide support for IPsec 1646 protection of RADIUS in order to provide confidentiality for the 1647 portion of the conversation between the gateway and the EAP server, 1648 as described in [RFC3162]. 1650 5.7. Identity verification 1651 Since the TLS session has not yet been negotiated, the initial 1652 Identity request/response occurs in the clear without integrity 1653 protection or authentication. It is therefore subject to snooping 1654 and packet modification. 1656 In configurations where all users are required to authenticate with 1657 PEAP and the first portion of the PEAP conversation is terminated at 1658 a local backend authentication server, without routing by proxies, 1659 the initial cleartext Identity Request/Response exchange is not 1660 needed in order to determine the required authentication method(s) 1661 or route the authentication conversation to its destination. As a 1662 result, the initial Identity and Request/Response exchange MAY NOT 1663 be present, and a subsequent Identity Request/Response exchange MAY 1664 occur after the TLS session is established. 1666 If the initial cleartext Identity Request/Response has been tampered 1667 with, after the TLS session is established, it is conceivable that 1668 the EAP Server will discover that it cannot verify the peer's claim 1669 of identity. For example, the peer's userID may not be valid or may 1670 not be within a realm handled by the EAP server. Rather than 1671 attempting to proxy the authentication to the server within the 1672 correct realm, the EAP server SHOULD terminate the conversation. 1674 The PEAP peer can present the server with multiple identities. This 1675 includes the claim of identity within the initial EAP- 1676 Response/Identity(MyID) packet, which is typically used to route the 1677 EAP conversation to the appropriate home backend authentication 1678 server. There may also be subsequent EAP-Response/Identity packets 1679 sent by the peer once the TLS channel has been established. 1681 Note that since the PEAP peer may not present a certificate, it is 1682 not always possible to check the initial EAP-Response/Identity 1683 against the identity presented in the certificate, as is done in 1684 [RFC2716]. 1686 Moreover, it cannot be assumed that the peer identities presented 1687 within multiple EAP-Response/Identity packets will be the same. For 1688 example, the initial EAP-Response/Identity might correspond to a 1689 machine identity, while subsequent identities might be those of the 1690 user. Thus, PEAP implementations SHOULD NOT abort the authentication 1691 just because the identities do not match. However, since the 1692 initial EAP-Response/Identity will determine the EAP server handling 1693 the authentication, if this or any other identity is inappropriate 1694 for use with the destination EAP server, there is no alternative but 1695 to terminate the PEAP conversation. 1697 The protected identity or identities presented by the peer within 1698 PEAP Part 2 may not be identical to the cleartext identity presented 1699 in PEAP Part 1, for legitimate reasons. In order to shield the 1700 userID from snooping, the cleartext Identity may only provide enough 1701 information to enable routing of the authentication request to the 1702 correct realm. For example, the peer may initially claim the 1703 identity of "nouser@bigco.com" in order to route the authentication 1704 request to the bigco.com EAP server. Subsequently, once the TLS 1705 session has been negotiated, in PEAP Part 2, the peer may claim the 1706 identity of "fred@bigco.com". Thus, PEAP can provide protection for 1707 the user's identity, though not necessarily the destination realm, 1708 unless the PEAP Part 1 conversation terminates at the local 1709 authentication server. 1711 As a result, PEAP implementations SHOULD NOT attempt to compare the 1712 Identities claimed with Parts 1 and 2 of the PEAP conversation. 1713 Similarly, if multiple Identities are claimed within PEAP Part 2, 1714 these SHOULD NOT be compared. An EAP conversation may involve more 1715 than one EAP authentication method, and the identities claimed for 1716 each of these authentications could be different (e.g. a machine 1717 authentication, followed by a user authentication). 1719 5.8. Man-in-the-middle protection 1721 If an EAP method protected by PEAP is also deployed without 1722 protection (from PEAP or IPSEC), and if the same credential is 1723 allowed in both cases, then a man-in-the-middle attack is possible. 1724 A man-in-the-middle can spoof the client to authenticate to it 1725 instead of the real EAP server; and forward the authentication to 1726 the real server over a protected tunnel. Since the attacker has 1727 access to the keys derived from the tunnel, it can gain access to 1728 the network. 1730 The compound binding draft [CompoundBinding] identifies a number of 1731 solutions to this attack. 1733 The preferred solution is to deploy the authentication method with 1734 protection from PEAP or IPSEC. Protection can address the man-in- 1735 the-middle attack; and in addition can address EAP method and EAP 1736 protocol weaknesses listed in the abstract and introduction sections 1737 in this document. 1739 Another solution is to use knowledge known only to the real peers to 1740 verify that there is no man-in-the-middle. A number of protocols 1741 derive keys for encryption, and these keys are not known to the man- 1742 in-the-middle. These keys can be used in the binding phase exchange 1743 described in compound binding [compoundbinding] draft to detect man- 1744 in-the-middle. PEAP implementations MUST support the binding phase 1745 exchange using compound MACs as described in the section 4.2 of the 1746 compound binding draft[CompoundBinding]. 1748 Another solution is for EAP methods to securely signal to peers that 1749 they are inside the protected channel. This may require changes to 1750 the EAP protocol. In order to allow EAP methods to implement secure 1751 signaling, PEAP implementations SHOULD inform the EAP methods that 1752 they are being protected by PEAP. 1754 6. IANA Considerations 1756 This section provides guidance to the Internet Assigned Numbers 1757 Authority (IANA) regarding registration of values related to the EAP 1758 protocol, in accordance with BCP 26, [RFC2434]. 1760 There is one name space in EAP-TLV that require registration: TLV- 1761 Types. 1763 6.1. Definition of Terms 1765 The following terms are used here with the meanings defined in BCP 1766 26: 1767 "name space", "assigned value", "registration". 1769 The following policies are used here with the meanings defined in 1770 BCP 1771 26: "Private Use", "First Come First Served", "Expert Review", 1772 "Specification Required", "IETF Consensus", "Standards Action". 1774 6.2. Recommended Registration Policies 1776 For registration requests where a Designated Expert should be 1777 consulted, the responsible IESG area director should appoint the 1778 Designated Expert. For Designated Expert with Specification 1779 Required, the request is posted to the EAP WG mailing list (or, if 1780 it has been disbanded, a successor designated by the Area Director) 1781 for comment and review, and MUST include a pointer to a public 1782 specification. Before a period of 30 days has passed, the Designated 1783 Expert will either approve or deny the registration request and 1784 publish a notice of the decision to the EAP WG mailing list or its 1785 successor. A denial notice must be justified by an explanation and, 1786 in the cases where it is possible, concrete suggestions 1787 on how the request can be modified so as to become acceptable. 1789 For registration requests requiring Expert Review, the EAP mailing 1790 list should be consulted. If the EAP mailing list is no longer 1791 operational, an alternative mailing list may be designated by the 1792 responsible IESG Area Director. 1794 EAP-TLVs have a 14-bit field, of which 1-6 have been allocated. 1796 7. Normative references 1798 [RFC1321] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", 1799 RFC 1800 1321, April 1992. 1802 [RFC1570] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, 1803 January 1804 1994. 1806 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 1807 STD 1808 51, RFC 1661, July 1994. 1810 [RFC1962] D. Rand. "The PPP Compression Control Protocol", RFC 1811 1962, 1812 Novell, June 1996. 1814 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, 1815 June 1816 1996. 1818 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 1819 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 1820 August 1821 1996. 1823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1824 Requirement Levels", BCP 14, RFC 2119, March 1997. 1826 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 1827 2246, November 1998. 1829 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 1830 Protocol (EAP)", RFC 2284, March 1998. 1832 [RFC2486] Aboba, B., Beadles, M., "The Network Access Identifier", 1833 RFC 2486, January 1999. 1835 [TLSEXT] Blake-Wilson, S., et al. "TLS Extensions", Internet draft 1836 (work in progress), draft-ietf-tls-extensions-06.txt, Feb 1837 2003. 1839 [IEEE8021X] 1840 IEEE Standards for Local and Metropolitan Area Networks: 1841 Port 1842 based Network Access Control, IEEE Std 802.1X-2001, June 1843 2001. 1845 [CompoundBinding] 1846 Puthenkulam, J., Lortz, V., Palekar, A., Simon, D., 1847 "The Compound Authentication Binding Problem", March 2003; 1848 draft-puthenkulam-eap-binding-02.txt. 1850 8. Informative references 1852 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 1853 Version 2 (DESE-bis)", RFC 2419, September 1998. 1855 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol 1856 (3DESE)", 1857 RFC 2420, September 1998. 1859 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1860 RFC2548, March 1999. 1862 [RFC2716] Aboba, B., Simon, D., "PPP EAP TLS Authentication 1863 Protocol", 1864 RFC 2716, October 1999. 1866 [RFC3078] Pall, G., Zorn, G., "Microsoft Point-to-Point Encryption 1867 (MPPE) Protocol", RFC 3078, March 2001. 1869 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to- 1870 Point 1871 Encryption (MPPE)", RFC 3079, March 2001. 1873 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", 1874 FIPS 1875 PUB 46 (January 1977). 1877 [IEEE80211] 1878 Information technology - Telecommunications and 1879 information 1880 exchange between systems - Local and metropolitan area 1881 networks - Specific Requirements Part 11: Wireless LAN 1882 Medium 1883 Access Control (MAC) and Physical Layer (PHY) 1884 Specifications, 1885 IEEE Std. 802.11-1999, 1999. 1887 [MODES] National Bureau of Standards, "DES Modes of Operation", 1888 FIPS 1889 PUB 81 (December 1980). 1891 [PEAP version 0] 1892 Kamath, V., Palekar, A., Wodrich, M., 1893 "Microsoft's PEAP version 0 (Implementation in Windows XP 1894 SP1)", 1895 draft-kamath-pppext-peapv0-00.txt. 1897 9. Appendix A - Examples 1899 In the case where an identity exchange occurs within PEAP Part 1, 1900 the conversation will appear as follows: 1902 Authenticating Peer Authenticator 1903 ------------------- ------------- 1904 <- EAP-Request/ 1905 Identity 1906 EAP-Response/ 1907 Identity (MyID1) -> 1908 <- EAP-Request/ 1909 EAP-Type=PEAP, V=2 1910 (PEAP Start, S bit set) 1912 EAP-Response/ 1913 EAP-Type=PEAP, V=1 1914 (TLS client_hello)-> 1915 <- EAP-Request/ 1916 EAP-Type=PEAP, V=2 1917 (TLS server_hello, 1918 TLS certificate, 1919 [TLS server_key_exchange,] 1920 [TLS certificate_request,] 1921 TLS server_hello_done) 1922 EAP-Response/ 1923 EAP-Type=PEAP, V=2 1924 ([TLS certificate,] 1925 TLS client_key_exchange, 1926 [TLS certificate_verify,] 1927 TLS change_cipher_spec, 1928 TLS finished) -> 1929 <- EAP-Request/ 1930 EAP-Type=PEAP, V=2 1931 (TLS change_cipher_spec, 1932 TLS finished) 1933 EAP-Response/ 1934 EAP-Type=PEAP -> 1936 TLS channel established 1937 (messages sent within the TLS channel) 1939 <- EAP-Request/ 1940 Identity 1941 EAP-Response/ 1942 Identity (MyID2) -> 1943 <- EAP-Request/ 1944 EAP-Type=X 1946 EAP-Response/ 1947 EAP-Type=X or NAK -> 1949 <- EAP-Request/ 1950 EAP-Type=X 1951 EAP-Response/ 1952 EAP-Type=X -> 1953 <- EAP-Request/ 1954 EAP-Type=EAP-TLV 1956 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 1957 methods=1, Result TLV (Success), Method_Identity_TLV (EAP-Type=X, 1958 EAP-Type-Version=0, keylengthusedforderivation, 1959 ClientIdentityLength= sizeof(MyID2), MyID2, ServerIdentityLength=0, 1960 Media-type=19), Method_Identity_TLV (EAP-Type=PEAP, EAP-Type- 1961 Version=2, keylengthusedforderivation, ClientIdentityLength= 1962 sizeof(MyID1), MyID1, ServerIdentityLength=0, Media-type=19), 1963 CompoundMAC (over entire EAP TLV inside the tunnel including EAP- 1964 header)) 1965 EAP-Response/ 1966 EAP-Type=EAP-TLV 1967 Result=Success 1968 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 1969 methods=1, Result TLV (Success), Method_Identity_TLV (EAP-Type=X, 1970 EAP-Type-Version=0, keylengthusedforderivation, 1971 ClientIdentityLength= sizeof(MyID2), MyID2, ServerIdentityLength=0, 1972 Media-type=19), Method_Identity_TLV (EAP-Type=PEAP, EAP-Type- 1973 Version=2, keylengthusedforderivation, ClientIdentityLength= 1974 sizeof(MyID1), MyID1, ServerIdentityLength=0, Media-type=19), 1975 CompoundMAC (over entire EAP TLV inside the tunnel including EAP- 1976 header)) 1978 -> 1980 TLS channel torn down 1981 (messages sent in cleartext) 1983 <- EAP-Success 1985 Where all peers are known to support PEAP, a non-certificate 1986 authentication is desired for the client and the PEAP Part 1 1987 conversation is carried out between the peer and a local EAP server, 1988 the cleartext identity exchange may be omitted and the conversation 1989 appears as follows: 1991 Authenticating Peer Authenticator 1992 ------------------- ------------- 1993 <- EAP-Request/ 1994 EAP-Type=PEAP, V=1 1995 (PEAP Start, S bit set) 1997 EAP-Response/ 1998 EAP-Type=PEAP, V=1 1999 (TLS client_hello)-> 2000 <- EAP-Request/ 2001 EAP-Type=PEAP, V=2 2002 (TLS server_hello, 2003 TLS certificate, 2004 [TLS server_key_exchange,] 2005 [TLS certificate_request,] 2006 TLS server_hello_done) 2007 EAP-Response/ 2008 EAP-Type=PEAP, V=2 2009 ([TLS certificate,] 2010 TLS client_key_exchange, 2011 [TLS certificate_verify,] 2012 TLS change_cipher_spec, 2013 TLS finished) -> 2014 <- EAP-Request/ 2015 EAP-Type=PEAP, V=2 2016 (TLS change_cipher_spec, 2017 TLS finished) 2018 EAP-Response/ 2019 EAP-Type=PEAP, V=2 -> 2021 TLS channel established 2022 (messages sent within the TLS channel) 2024 <- EAP-Request/ 2025 Identity 2026 EAP-Response/ 2027 Identity (MyID) -> 2028 <- EAP-Request/ 2029 EAP-Type=X 2030 EAP-Response/ 2031 EAP-Type=X or NAK -> 2033 <- EAP-Request/ 2034 EAP-Type=X 2035 EAP-Response/ 2036 EAP-Type=X -> 2037 <- EAP-Request/ 2038 EAP-Type=EAP-TLV 2040 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2041 methods=, Result TLV (Success), Method_Identity_TLV (for 2042 each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), 2043 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2044 EAP-header)) 2046 EAP-Response/ 2047 EAP-Type=EAP-TLV 2048 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2049 methods=, Result TLV (Success), Method_Identity_TLV (for 2050 each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), 2051 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2052 EAP-header)) 2054 TLS channel torn down 2055 (messages sent in cleartext) 2057 <- EAP-Success 2059 Where all peers are known to support PEAP, where client certificate 2060 authentication is desired and the PEAP Part 1 conversation is 2061 carried out between the peer and a local EAP server, the cleartext 2062 identity exchange may be omitted and the conversation appears as 2063 follows: 2065 Authenticating Peer Authenticator 2066 ------------------- ------------- 2067 <- EAP-Request/ 2068 EAP-Type=PEAP, V=2 2069 (PEAP Start, S bit set) 2071 EAP-Response/ 2072 EAP-Type=PEAP, V=2 2073 (TLS client_hello)-> 2074 <- EAP-Request/ 2075 EAP-Type=PEAP, V=2 2076 (TLS server_hello, 2077 TLS certificate, 2078 [TLS server_key_exchange,] 2079 TLS server_hello_done) 2080 EAP-Response/ 2081 EAP-Type=PEAP, V=2 2082 (TLS client_key_exchange, 2083 TLS change_cipher_spec, 2084 TLS finished) -> 2085 <- EAP-Request/ 2086 EAP-Type=PEAP, V=2 2087 (TLS change_cipher_spec, 2088 TLS finished) 2089 EAP-Response/ 2090 EAP-Type=PEAP, V=2 -> 2092 TLS channel established 2093 (messages sent within the TLS channel) 2095 <- EAP-Request/ 2096 EAP-Type=PEAP, V=2 2097 (TLS hello_request) 2098 EAP-Response/ 2099 EAP-Type=PEAP, V=2 2100 (TLS client_hello)-> 2102 <- EAP-Request/ 2103 EAP-Type=PEAP, V=2 2104 (TLS server_hello, 2105 TLS certificate, 2106 [TLS server_key_exchange,] 2107 [TLS certificate_request,] 2108 TLS server_hello_done) 2109 EAP-Response/ 2110 EAP-Type=PEAP, V=2 2111 ([TLS certificate,] 2112 TLS client_key_exchange, 2113 [TLS certificate_verify,] 2114 TLS change_cipher_spec, 2115 TLS finished) -> 2116 <- EAP-Request/ 2117 EAP-Type=PEAP, V=2 2118 (TLS change_cipher_spec, 2119 TLS finished) 2120 EAP-Response/ 2122 EAP-Type=PEAP, V=2 -> 2123 <- EAP-Request/ 2124 EAP-Type=EAP-TLV 2125 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2126 methods=, Result TLV (Success), Method_Identity_TLV (for 2127 each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), 2128 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2129 EAP-header)) 2130 EAP-Response/ 2131 EAP-Type=EAP-TLV 2132 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2133 methods=, Result TLV (Success), Method_Identity_TLV (for 2134 each successful EAP-Type inside PEAP), Method_Identity_TLV (for 2135 PEAP), CompoundMAC (over entire EAP TLV packet inside the tunnel 2136 including EAP-header)) 2138 TLS channel torn down 2139 (messages sent in cleartext) 2141 <- EAP-Success 2143 In the case where the PEAP fragmentation is required, the 2144 conversation will appear as follows: 2146 Authenticating Peer Authenticator 2147 ------------------- ------------- 2148 <- EAP-Request/ 2149 Identity 2150 EAP-Response/ 2151 Identity (MyID) -> 2152 <- EAP-Request/ 2153 EAP-Type=PEAP, V=2 2154 (PEAP Start, S bit set) 2156 EAP-Response/ 2157 EAP-Type=PEAP, V=2 2158 (TLS client_hello)-> 2159 <- EAP-Request/ 2160 EAP-Type=PEAP, V=2 2161 (TLS server_hello, 2162 TLS certificate, 2164 [TLS server_key_exchange,] 2165 [TLS certificate_request,] 2166 TLS server_hello_done) 2167 (Fragment 1: L, M bits set) 2168 EAP-Response/ 2169 EAP-Type=PEAP, V=2 -> 2170 <- EAP-Request/ 2171 EAP-Type=PEAP, V=2 2172 (Fragment 2: M bit set) 2173 EAP-Response/ 2174 EAP-Type=PEAP, V=2 -> 2175 <- EAP-Request/ 2176 EAP-Type=PEAP, V=2 2177 (Fragment 3) 2178 EAP-Response/ 2179 EAP-Type=PEAP, V=2 2180 ([TLS certificate,] 2181 TLS client_key_exchange, 2182 [TLS certificate_verify,] 2183 TLS change_cipher_spec, 2184 TLS finished) 2185 (Fragment 1: L, M bits set)-> 2187 <- EAP-Request/ 2188 EAP-Type=PEAP, V=2 2189 EAP-Response/ 2190 EAP-Type=PEAP, V=2 2191 (Fragment 2)-> 2192 <- EAP-Request/ 2193 EAP-Type=PEAP, V=2 2194 (TLS change_cipher_spec, 2195 TLS finished) 2197 EAP-Response/ 2198 EAP-Type=PEAP, V=2 -> 2200 TLS channel established 2201 (messages sent within the TLS channel) 2203 <- EAP-Request/ 2204 Identity 2205 EAP-Response/ 2206 Identity (MyID) -> 2207 <- EAP-Request/ 2208 EAP-Type=X 2209 EAP-Response/ 2210 EAP-Type=X or NAK -> 2212 <- EAP-Request/ 2213 EAP-Type=X 2214 EAP-Response/ 2215 EAP-Type=X -> 2216 <- EAP-Request/ 2217 EAP-Type=EAP-TLV 2218 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2219 methods=, Result TLV (Success), Method_Identity_TLV (for 2220 each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), 2221 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2222 EAP-header)) 2223 EAP-Response/ 2224 EAP-Type=EAP-TLV 2225 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2226 methods=, Result TLV (Success), Method_Identity_TLV (for 2227 each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), 2228 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2229 EAP-header)) 2231 TLS channel torn down 2232 (messages sent in cleartext) 2234 <- EAP-Success 2236 In the case where the server authenticates to the client 2237 successfully in PEAP Part 1, but the client fails to authenticate to 2238 the server in PEAP Part 2, the conversation will appear as follows: 2240 Authenticating Peer Authenticator 2241 ------------------- ------------- 2242 <- EAP-Request/ 2243 Identity 2244 EAP-Response/ 2245 Identity (MyID) -> 2246 <- EAP-Request/ 2247 EAP-Type=PEAP, V=2 2248 (PEAP Start, S bit set) 2249 EAP-Response/ 2250 EAP-Type=PEAP, V=2 2251 (TLS client_hello)-> 2252 <- EAP-Request/ 2253 EAP-Type=PEAP, V=2 2254 (TLS server_hello, 2255 TLS certificate, 2256 [TLS server_key_exchange,] 2257 [TLS certificate_request,] 2258 TLS server_hello_done) 2259 EAP-Response/ 2260 EAP-Type=PEAP, V=2 2261 ([TLS certificate,] 2262 TLS client_key_exchange, 2263 [TLS certificate_verify,] 2264 TLS change_cipher_spec, 2265 TLS finished) -> 2266 <- EAP-Request/ 2267 EAP-Type=PEAP, V=2 2268 (TLS change_cipher_spec, 2269 TLS finished) 2271 EAP-Response/ 2272 EAP-Type=PEAP, V=2 -> 2274 TLS channel established 2275 (messages sent within the TLS channel) 2277 <- EAP-Request/ 2278 Identity 2279 EAP-Response/ 2280 Identity (MyID) -> 2281 <- EAP-Request/ 2282 EAP-Type=X 2283 EAP-Response/ 2285 EAP-Type=X or NAK -> 2287 <- EAP-Request/ 2288 EAP-Type=X 2289 EAP-Response/ 2290 EAP-Type=X -> 2291 <- EAP-Request/ 2292 EAP-Type=EAP-TLV 2293 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2294 methods=, Result TLV (Failure), Method_Identity_TLV (for 2295 each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), 2296 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2297 EAP-header)) 2298 // Compound MAC calculated using TLS key material only. 2299 EAP-Response/ 2300 EAP-Type=EAP-TLV 2301 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2302 methods=, Result TLV (Failure), Method_Identity_TLV (for 2303 each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), 2304 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2305 EAP-header)) 2307 Result=Failure -> 2309 (TLS session cache entry flushed) 2310 TLS channel torn down 2311 (messages sent in cleartext) 2313 <- EAP-Failure 2315 In the case where server authentication is unsuccessful in PEAP Part 2316 1, the conversation will appear as follows: 2318 Authenticating Peer Authenticator 2319 ------------------- ------------- 2320 <- EAP-Request/ 2321 Identity 2322 EAP-Response/ 2323 Identity (MyID) -> 2324 <- EAP-Request/ 2325 EAP-Type=PEAP, V=2 2326 (PEAP Start) 2327 EAP-Response/ 2328 EAP-Type=PEAP, V=2 2329 (TLS client_hello)-> 2330 <- EAP-Request/ 2331 EAP-Type=PEAP, V=2 2332 (TLS server_hello, 2333 TLS certificate, 2334 [TLS server_key_exchange,] 2335 TLS server_hello_done) 2336 EAP-Response/ 2337 EAP-Type=PEAP, V=2 2338 (TLS client_key_exchange, 2339 [TLS certificate_verify,] 2340 TLS change_cipher_spec, 2341 TLS finished) -> 2342 <- EAP-Request/ 2343 EAP-Type=PEAP, V=2 2344 (TLS change_cipher_spec, 2345 TLS finished) 2346 EAP-Response/ 2347 EAP-Type=PEAP, V=2 2348 (TLS change_cipher_spec, 2349 TLS finished) 2351 <- EAP-Request/ 2352 EAP-Type=PEAP, V=2 2353 EAP-Response/ 2354 EAP-Type=PEAP, V=2 2355 (TLS Alert message) -> 2356 <- EAP-Failure 2357 (TLS session cache entry flushed) 2359 In the case where a previously established session is being resumed, 2360 the EAP server supports TLS session cache flushing for unsuccessful 2361 PEAP Part 2 authentications and both sides authenticate 2362 successfully, the conversation will appear as follows: 2364 Authenticating Peer Authenticator 2365 ------------------- ------------- 2366 <- EAP-Request/ 2367 Identity 2368 EAP-Response/ 2369 Identity (MyID) -> 2370 <- EAP-Request/ 2371 EAP-Type=PEAP,V=2 2372 (PEAP Start) 2373 EAP-Response/ 2374 EAP-Type=PEAP, V=2 2375 (TLS client_hello)-> 2376 <- EAP-Request/ 2377 EAP-Type=PEAP, V=2 2378 (TLS server_hello, 2379 TLS change_cipher_spec 2380 TLS finished) 2381 EAP-Response/ 2382 EAP-Type=PEAP, V=2 2383 (TLS change_cipher_spec, 2384 TLS finished) -> 2385 <- EAP-Request/ 2386 EAP-Type=EAP-TLV 2387 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2388 methods=0, Result TLV (Success), Method_Identity_TLV (for PEAP), 2389 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2390 EAP-header)) 2391 // Compound MAC calculated using TLS keys since there were no inner 2392 EAP methods. 2394 EAP-Response/ 2395 EAP-Type=EAP-TLV 2396 Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP 2397 methods=0, Result TLV (Success), Method_Identity_TLV (for PEAP), 2398 CompoundMAC (over entire EAP TLV packet inside the tunnel including 2399 EAP-header)) . 2400 -> 2401 TLS channel torn down 2402 (messages sent in cleartext) 2404 <- EAP-Success 2406 In the case where a previously established session is being resumed, 2407 and the server authenticates to the client successfully but the 2408 client fails to authenticate to the server, the conversation will 2409 appear as follows: 2411 Authenticating Peer Authenticator 2412 ------------------- ------------- 2413 <- EAP-Request/ 2414 Identity 2415 EAP-Response/ 2416 Identity (MyID) -> 2417 <- EAP-Request/ 2418 EAP-Request/ 2419 EAP-Type=PEAP, V=2 2420 (TLS Start) 2421 EAP-Response/ 2422 EAP-Type=PEAP, V=2 2423 (TLS client_hello) -> 2424 <- EAP-Request/ 2425 EAP-Type=PEAP, V=2 2426 (TLS server_hello, 2427 TLS change_cipher_spec, 2428 TLS finished) 2429 EAP-Response/ 2430 EAP-Type=PEAP, V=2 2431 (TLS change_cipher_spec, 2432 TLS finished) -> 2433 <- EAP-Request 2434 EAP-Type=PEAP, V=2 2435 (TLS Alert message) 2436 EAP-Response 2437 EAP-Type=PEAP, V=2 -> 2438 <- EAP-Failure 2439 (TLS session cache entry flushed) 2441 In the case where a previously established session is being resumed, 2442 and the server authentication is unsuccessful, the conversation will 2443 appear as follows: 2445 Authenticating Peer Authenticator 2446 ------------------- ------------- 2447 <- EAP-Request/ 2448 Identity 2449 EAP-Response/ 2450 Identity (MyID) -> 2451 <- EAP-Request/ 2452 EAP-Request/ 2453 EAP-Type=PEAP, V=2 2454 (TLS Start) 2455 EAP-Response/ 2456 EAP-Type=PEAP, V=2 2457 (TLS client_hello)-> 2458 <- EAP-Request/ 2459 EAP-Type=PEAP, V=2 2460 (TLS server_hello, 2461 TLS change_cipher_spec, 2462 TLS finished) 2463 EAP-Response/ 2464 EAP-Type=PEAP, V=2 2465 (TLS change_cipher_spec, 2466 TLS finished) 2467 <- EAP-Request/ 2468 EAP-Type=PEAP, V=2 2469 EAP-Response/ 2470 EAP-Type=PEAP, V=2 2471 (TLS Alert message) -> 2472 (TLS session cache entry flushed) 2474 <- EAP-Failure 2476 In the case where the peer and authenticator have mismatched PEAP 2477 versions (e.g. the peer has a pre-standard implementation with 2478 version 0, and the authenticator has an implementation compliant 2479 with this specification), the session is being resumed, but the 2480 authentication is unsuccessful, the conversation will occur as 2481 follows: 2483 Authenticating Peer Authenticator 2484 ------------------- ------------- 2485 <- EAP-Request/ 2486 Identity 2487 EAP-Response/ 2488 Identity (MyID) -> 2489 <- EAP-Request/ 2490 EAP-Request/ 2491 EAP-Type=PEAP, V=2 2492 (TLS Start) 2493 EAP-Response/ 2494 EAP-Type=PEAP, V=0 2495 (TLS client_hello)-> 2496 <- EAP-Request/ 2497 EAP-Type=PEAP, V=0 2498 (TLS server_hello, 2499 TLS change_cipher_spec, 2500 TLS finished) 2501 EAP-Response/ 2502 EAP-Type=PEAP, V=0 2503 (TLS change_cipher_spec, 2504 TLS finished) 2505 <- EAP-Request/ 2506 EAP-Type=PEAP, V=0 2507 EAP-Response/ 2508 EAP-Type=PEAP, V=0 2509 (TLS Alert message) -> 2510 (TLS session cache entry flushed) 2512 <- EAP-Failure 2514 10. Acknowledgments and Contributions 2516 Thanks to Jan-Ove Larsson, Magnus Nystrom of RSA Security; Bernard 2517 Aboba, Vivek Kamath, Stephen Bensley, Narendra Gidwani of Microsoft; 2518 Joe Salowey, Hao Zhou, Ilan Frenkel, Nancy Cam-Winget of Cisco; 2519 Hakan Andersson of RSA; Jose Puthenkulam of Intel for their 2520 contributions and critiques. 2522 The compound binding exchange to address man-in-the-middle attack is 2523 based on the draft "The Compound Authentication Binding 2524 Problem"[CompoundBinding]. 2526 The vast majority of the work by Simon Josefsson and Hakan Andersson 2527 was done while he was employed at RSA Laboratories. 2529 Author Addresses 2531 Ashwin Palekar 2532 Microsoft Corporation 2533 One Microsoft Way 2534 Redmond, WA 98052 2536 Phone: +1 425 882 8080 2537 EMail: ashwinp@microsoft.com 2539 Dan Simon 2540 Microsoft Corporation 2541 One Microsoft Way 2542 Redmond, WA 98052 2544 Phone: +1 425 706 6711 2545 EMail: dansimon@microsoft.com 2547 Glen Zorn 2548 Cisco Systems 2549 500 108th Avenue N.E. 2550 Suite 500 2551 Bellevue, Washington 98004 2552 USA 2554 Phone: + 1 425 438 8210 2555 Fax: + 1 425 438 1848 2556 EMail: gwz@cisco.com 2558 Simon Josefsson 2559 Drottningholmsv�gen 70 2560 112 42 Stockholm 2561 Sweden 2563 Phone: +46 8 619 04 22 2564 EMail: jas@extundo.com 2566 11. Intellectual Property Statement 2568 The IETF takes no position regarding the validity or scope of any 2569 intellectual property or other rights that might be claimed to 2570 pertain to the implementation or use of the technology described in 2571 this document or the extent to which any license under such rights 2572 might or might not be available; neither does it represent that it 2573 has made any effort to identify any such rights. Information on the 2574 IETF's procedures with respect to rights in standards-track and 2575 standards-related documentation can be found in BCP-11. Copies of 2576 claims of rights made available for publication and any assurances 2577 of licenses to be made available, or the result of an attempt made 2578 to obtain a general license or permission for the use of such 2579 proprietary rights by implementors or users of this specification 2580 can be obtained from the IETF Secretariat. 2582 The IETF invites any interested party to bring to its attention any 2583 copyrights, patents or patent applications, or other proprietary 2584 rights which may cover technology that may be required to practice 2585 this standard. Please address the information to the IETF Executive 2586 Director. 2588 12. Full Copyright Statement 2590 Copyright (C) The Internet Society (2002). All Rights Reserved. 2591 This document and translations of it may be copied and furnished to 2592 others, and derivative works that comment on or otherwise explain it 2593 or assist in its implementation may be prepared, copied, published 2594 and distributed, in whole or in part, without restriction of any 2595 kind, provided that the above copyright notice and this paragraph 2596 are included on all such copies and derivative works. However, this 2597 document itself may not be modified in any way, such as by removing 2598 the copyright notice or references to the Internet Society or other 2599 Internet organizations, except as needed for the purpose of 2600 developing Internet standards in which case the procedures for 2601 copyrights defined in the Internet Standards process must be 2602 followed, or as required to translate it into languages other than 2603 English. The limited permissions granted above are perpetual and 2604 will not be revoked by the Internet Society or its successors or 2605 assigns. This document and the information contained herein is 2606 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 2607 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2608 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2609 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2612 Expiration Date 2614 This memo is filed as , 2615 and expires after six months.