idnits 2.17.1 draft-josefsson-pppext-eap-tls-eap-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 326 has weird spacing: '...ows the clien...' == Line 341 has weird spacing: '...ssionId will ...' == Line 343 has weird spacing: '...ered by the...' == Line 1013 has weird spacing: '... server to sk...' == Line 1780 has weird spacing: '...imed to perta...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In configurations where all users are required to authenticate with PEAP and the first portion of the PEAP conversation is terminated at a local backend authentication server, without routing by proxies, the initial cleartext Identity Request/Response exchange is not needed in order to determine the required authentication method(s) or route the authentication conversation to its destination. As a result, the initial Identity and Request/Response exchange MAY NOT be present, and a subsequent Identity Request/Response exchange MAY occur after the TLS session is established. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: 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 667 -- Looks like a reference, but probably isn't: '2' on line 676 == Missing Reference: 'RFC2869' is mentioned on line 472, but not defined -- Looks like a reference, but probably isn't: '3' on line 680 -- Looks like a reference, but probably isn't: '4' on line 686 -- Looks like a reference, but probably isn't: '5' on line 691 -- Looks like a reference, but probably isn't: '6' on line 697 -- Looks like a reference, but probably isn't: '7' on line 702 == Missing Reference: 'RFC3162' is mentioned on line 1177, but not defined == Unused Reference: 'RFC1321' is defined on line 1248, but no explicit reference was found in the text == Unused Reference: 'RFC1570' is defined on line 1251, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'RFC1962' is defined on line 1257, but no explicit reference was found in the text == Unused Reference: 'IEEE8021X' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: 'FIPSDES' is defined on line 1307, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 1317, 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) == Outdated reference: A later version (-06) exists of draft-ietf-tls-extensions-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021X' -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) Summary: 8 errors (**), 0 flaws (~~), 21 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group H. Andersson 3 INTERNET-DRAFT S. Josefsson 4 Category: Standards Track RSA Security 5 Glen Zorn 6 September 2002 Cisco 7 Dan Simon 8 Ashwin Palekar 9 Microsoft 11 Protected EAP Protocol (PEAP) 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet- Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 The Extensible Authentication Protocol (EAP), defined in RFC 2284, 38 provides for support of multiple authentication methods. While EAP was 39 originally created for use with PPP, it has since been adopted for use 40 with IEEE 802.1X "Network Port Authentication". 42 Since its deployment, a number of weaknesses in EAP have become 43 apparent. These include lack of protection of the user identity or the 44 EAP negotiation; no standardized mechanism for key exchange; no built-in 45 support for fragmentation and reassembly; and lack of support for fast 46 reconnect. 48 By wrapping the EAP protocol within TLS, Protected EAP (PEAP) addresses 49 these deficiencies. Any EAP method running within PEAP is provided with 50 built-in support for key exchange, session resumption and fragmentation 51 and reassembly. 53 Table of Contents 55 1. Introduction .......................................... 3 56 1.1 EAP Issues ...................................... 3 57 1.2 Requirements language ........................... 5 58 1.3 Terminology ..................................... 5 59 2. Protocol overview ..................................... 6 60 2.1 PEAP Part 1 .................................... 6 61 2.2 PEAP Part 2 .................................... 10 62 2.3 Version negotiation ............................ 11 63 2.4 Error handling ................................. 12 64 2.5 Retry behavior ................................. 12 65 2.6 Session resumption ............................. 12 66 2.7 Fragmentation .................................. 13 67 2.8 Key derivation ................................. 14 68 2.9 Ciphersuite negotiation ........................ 16 69 3. Detailed description of the PEAP protocol ............ 18 70 3.1 PEAP Packet Format ............................. 18 71 3.2 PEAP Request Packet ............................ 20 72 3.3 PEAP Response Packet ........................... 22 73 4. Security considerations .............................. 23 74 4.1 Method negotiation ............................. 23 75 4.2 TLS session cache handling ..................... 24 76 4.3 Certificate revocation ......................... 24 77 4.4 Separation of EAP server and PPP authenticator.. 25 78 4.5 Separation of PEAP Part 1 and Part 2 Servers ... 26 79 4.6 Identity verification .......................... 27 80 5. Normative references ................................ 28 81 6. Informative references .............................. 29 82 Appendix A - Examples ........................................ 31 83 Acknowledgments .............................................. 40 84 Author's Addresses ........................................... 40 85 Intellectual Property Statement .............................. 41 86 Full Copyright Statement ..................................... 41 87 1. Introduction 89 The Extensible Authentication Protocol (EAP), described in [RFC2284], 90 provides a standard mechanism for support of multiple authentication 91 methods. Through the use of EAP, support for a number of authentication 92 schemes may be added, including smart cards, Kerberos, Public Key, One 93 Time Passwords, and others. 95 One of the goals of EAP is to enable development of new authentication 96 methods without requiring deployment of new code on the Network Access 97 Server (NAS). As a result, the NAS acts as a "passthrough", and need not 98 understand specific EAP methods. 100 Figure 1 describes the relationship between the EAP peer, NAS and 101 backend authentication server. As described in the figure, the EAP 102 conversation "passes through" the NAS on its way between the client and 103 the backend authentication server. While the authentication 104 conversation is between the EAP peer and backend authentication server, 105 the NAS and backend authentication server need to have established trust 106 for the conversation to proceed. 108 In PEAP, the conversation between the EAP peer and the backend server is 109 encrypted and integrity protected within a TLS channel, and mutual 110 authentication is required between the EAP peer and the backend server. 112 As a result, the NAS does not have knowledge of the TLS master secret 113 derived between the EAP Peer and the backend authentication server, and 114 cannot decrypt the PEAP conversation. In order to providing keying 115 material for link-layer ciphersuites however, the NAS does obtain the 116 master session keys, which are derived from the TLS master secret via a 117 one-way function. 119 1.1. EAP Issues 121 With the increasing adoption of EAP, a number of deficiencies have 122 become apparent. Since the EAP method negotiation is unprotected, where 123 an attacker can easily access the medium (such as on a wireless network 124 or where EAP is run over IP), it is possible for an attacker to inject 125 packets in order to cause the negotiation of a method with lesser 126 security. Denial of service attacks are also possible. By protecting the 127 EAP negotiation within a TLS channel, PEAP addresses this issue. 129 Since the initial EAP Identity Request/Response exchange is sent in the 130 clear, an attacker snooping on the conversation can collect user 131 identities for use in subsequent attacks. By initially negotiating a TLS 132 channel, PEAP provies support for identity protection. 134 +-+-+-+-+-+ +-+-+-+-+-+ 135 | | | | 136 | | | | 137 | Cipher- | | Cipher- | 138 | Suite | | Suite | 139 | | | | 140 +-+-+-+-+-+ +-+-+-+-+-+ 141 ^ ^ 142 | | 143 | | 144 | | 145 V V 146 +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ 147 | | EAP | |<======>| | 148 | | Conversation | | | | 149 | |<================================>| Backend | 150 | Client | (over PPP, | NAS | | Server | 151 | | 802.11,etc.) | |<=======| | 152 | | | | Keys | | 153 | | | | | | 154 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 155 ^ ^ 156 | | 157 | EAP API | EAP API 158 | | 159 V V 160 +-+-+-+-+-+ +-+-+-+-+-+ 161 | | | | 162 | | | | 163 | EAP | | EAP | 164 | Method | | Method | 165 | | | | 166 +-+-+-+-+-+ +-+-+-+-+-+ 168 Figure 1 - Relationship between EAP client, backend authentication 169 server and NAS. 171 Since EAP does not include support for fragmentation and reassembly, 172 individual methods need to include this capability. By including support 173 for fragmentation and reassembly within PEAP, methods leveraging PEAP do 174 not need to support this on their own. 176 Where EAP is used for authentication in wireless networks, the 177 authentication latency is a concern. As a result, it is valuable to be 178 able to do a quick re-authentication on roaming between access points. 179 PEAP supports this capability by leveraging the TLS session resumption 180 facility, and any EAP method running under PEAP can take advantage of 181 it. 183 In order to provide keying material for a wide range of link layer 184 ciphersuites, EAP methods need to provide a key hierarchy generating 185 authentication and encryption keys, as well as initialization vectors. 186 Development of a secure key hierarchy is complex, and not easy to 187 generalize for all EAP methods. By relying on the well-reviewed TLS 188 [RFC2246] key derivation method, PEAP provides the required keying 189 material for any EAP method running within it. This frees EAP method 190 developers from taking on the difficult (and error prone) task of 191 designing a key hierarchy for each method. 193 1.2. Requirements language 195 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 196 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 197 described in [RFC2119]. 199 1.3. Terminology 201 This document frequently uses the following terms: 203 Access Point 204 A Network Access Server implementing 802.11. 206 Authenticator 207 The end of the link requiring the authentication. 209 Authentication Server 210 An Authentication Server is an entity that provides an 211 Authentication Service to an NAS. This service verifies from 212 the credentials provided by the peer, the claim of identity 213 made by the peer. 215 Link layer ciphersuite 216 The ciphersuite negotiated for use at the link layer. 218 Master key 219 The key derived between the EAP client and EAP server during 220 the EAP authentication process. 222 Master session key 223 The keys derived from the master key that are subsequently 224 used in generation of the transient session keys for 225 authentication, encryption, and IV-generation. So that the 226 master session keys are usable with any link layer 227 ciphersuite, they are longer than is necessary, and are 228 truncated to fit. 230 NAS Short for "Network Access Server". 232 Peer The other end of the point-to-point link (PPP), point-to-point 233 LAN segment (IEEE 802.1X) or 802.11 wireless link, which is 234 being authenticated by the NAS. In IEEE 802.1X, this end is 235 known as the Supplicant. 237 TLS Ciphersuite 238 The ciphersuite negotiated for protection of the PEAP Part 2 239 conversation. 241 Transient session keys 242 The transient session keys are derived from the master session 243 keys, and are of the appropriate size and type for use with 244 the chosen link layer ciphersuite. 246 2. Protocol overview 248 Protected EAP (PEAP) is comprised of a two-part conversation: 250 [1] In Part 1, a TLS session is negotiated, with server authenticating 251 to the client and optionally the client to the server. The 252 negotiated key is then used to encrypt the rest of the 253 conversation. 255 [2] In Part 2, within the TLS session, a complete EAP conversation is 256 carried out, unless part 1 provided client authentication. 258 In the next two sections, we provide an overview of each of the parts of 259 the PEAP conversation. 261 2.1. PEAP Part 1 263 The PEAP conversation typically begins with the authenticator and the 264 peer negotiating EAP. The authenticator will typically send an EAP- 265 Request/Identity packet to the peer, and the peer will respond with an 266 EAP-Response/Identity packet to the authenticator, containing the peer's 267 userId. 269 Once the optional initial Identity Request/Response exchange is 270 completed, while nominally the EAP conversation occurs between the 271 authenticator and the peer, the authenticator MAY act as a passthrough 272 device, with the EAP packets received from the peer being encapsulated 273 for transmission to a backend authentication server. In the discussion 274 that follows, we will use the term "EAP server" to denote the ultimate 275 endpoint conversing with the peer. 277 Once having received the peer's Identity, and determined that PEAP 278 authentication is to occur, the EAP server MUST respond with a 279 PEAP/Start packet, which is an EAP-Request packet with EAP-Type=PEAP, 280 the Start (S) bit set, and no data. Assuming that the peer supports 281 PEAP, the PEAP conversation will then begin, with the peer sending an 282 EAP-Response packet with EAP-Type=PEAP. 284 The data field of the EAP-Response packet will encapsulate one or more 285 TLS records in TLS record layer format, containing a TLS client_hello 286 handshake message. The current cipher spec for the TLS records will be 287 TLS_NULL_WITH_NULL_NULL and null compression. This current cipher spec 288 remains the same until the change_cipher_spec message signals that 289 subsequent records will have the negotiated attributes for the remainder 290 of the handshake. 292 The client_hello message contains the client's TLS version number, a 293 sessionId, a random number, and a set of TLS ciphersuites supported by 294 the client. The version offered by the client MUST correspond to TLS 295 v1.0 or later. 297 The EAP server will then respond with an EAP-Request packet with EAP- 298 Type=PEAP. The data field of this packet will encapsulate one or more 299 TLS records. These will contain a TLS server_hello handshake message, 300 possibly followed by TLS certificate, server_key_exchange, 301 certificate_request, server_hello_done and/or finished handshake 302 messages, and/or a TLS change_cipher_spec message. 304 Since after the TLS session is established, another complete EAP 305 negotiation will occur and the peer will authenticate using a secondary 306 mechanism, with PEAP the client need not authenticate as part of TLS 307 session establishment. As a result, although the EAP-Request packet sent 308 by the EAP Server MAY contain a certificate_request message, this is not 309 required. 311 The certificate_request message indicates that the server desires the 312 client to authenticate itself via public key. Typically when the EAP 313 server sends a certificate_request message, the intent is to complete 314 the PEAP authentication without requiring negotiation of an additional 315 EAP method, so that only an EAP-Success or EAP-Failure message is sent 316 inside the TLS channel. However, it is valid for the server to request 317 a certificate in the server_hello and for the client refuse to provide 318 one. In this case, the EAP server MUST require that PEAP Part 2 be 319 completed. 321 Note that since TLS client certificates are sent in the clear, if 322 identity protection is required, then it is possible for the TLS 323 authentication to be re-negotiated after the first server 324 authentication. To accomplish this, after the server_finished message 325 is sent, and before PEAP part 2, the server sends a TLS hello_request. 326 This allows the client to perform client authentication by sending a 327 client_hello if it wants to, or, send a no_renegotiation alert to the 328 server indicating that it wants to continue with PEAP part 2 instead. 329 Since this re-negotiation occurs within the encrypted TLS channel, it 330 does not reveal client certificate details. 332 The server_hello handshake message contains a TLS version number, 333 another random number, a sessionId, and a TLS ciphersuite. The version 334 offered by the server MUST correspond to TLS v1.0 or later. In order to 335 provide confidentiality, integrity and replay protection, and 336 authentication, the negotiated TLS ciphersuite MUST provide all of these 337 security services. 339 If the client's sessionId is null or unrecognized by the server, the 340 server MUST choose the sessionId to establish a new session; otherwise, 341 the sessionId will match that offered by the client, indicating a 342 resumption of the previously established session with that sessionID. 343 The server will also choose a TLS ciphersuite from those offered by the 344 client; if the session matches the client's, then the TLS ciphersuite 345 MUST match the one negotiated during the handshake protocol execution 346 that established the session. 348 PEAP implementations need not necessarily support all TLS ciphersuites 349 listed in [RFC2246]. Not all TLS ciphersuites are supported by available 350 TLS tool kits and licenses may be required to support some TLS 351 ciphersuites (e.g. TLS ciphersuites utilizing the IDEA encryption 352 algorithm). To ensure interoperability, PEAP peers and Authenticators 353 MUST be able to negotiate the following TLS ciphersuites: 355 TLS_RSA_WITH_RC4_128_MD5 356 TLS_RSA_WITH_RC4_128_SHA 358 TLS as described in [RFC2246] supports compression as well as 359 ciphersuite negotiation. Therefore during the PEAP Part 1 conversation 360 the EAP endpoints MAY request or negotiate TLS compression. 362 If the EAP server is not resuming a previously established session, then 363 it MUST include a TLS server_certificate handshake message, and a 364 server_hello_done handshake message MUST be the last handshake message 365 encapsulated in this EAP-Request packet. 367 The certificate message contains a public key certificate chain for 368 either a key exchange public key (such as an RSA or Diffie-Hellman key 369 exchange public key) or a signature public key (such as an RSA or DSS 370 signature public key). In the latter case, a TLS server_key_exchange 371 handshake message MUST also be included to allow the key exchange to 372 take place. 374 The peer MUST respond to the EAP-Request with an EAP-Response packet of 375 EAP-Type=PEAP. The data field of this packet will encapsulate one or 376 more TLS records containing a TLS change_cipher_spec message and 377 finished handshake message, and possibly certificate, certificate_verify 378 and/or client_key_exchange handshake messages. If the preceding 379 server_hello message sent by the EAP server in the preceding EAP-Request 380 packet indicated the resumption of a previous session, then the peer 381 MUST send only the change_cipher_spec and finished handshake messages. 382 The finished message contains the peer's authentication response to the 383 EAP server. 385 If the preceding server_hello message sent by the EAP server in the 386 preceeding EAP-Request packet did not indicate the resumption of a 387 previous session, then the peer MUST send, in addition to the 388 change_cipher_spec and finished messages, a client_key_exchange message, 389 which completes the exchange of a shared master secret between the peer 390 and the EAP server. 392 The EAP server MUST then respond with an EAP-Request packet with EAP- 393 Type=PEAP, which includes, in the case of a new TLS session, one or more 394 TLS records containing TLS change_cipher_spec and finished handshake 395 messages. The latter contains the EAP server's authentication response 396 to the peer. The peer will then verify the hash in order to 397 authenticate the EAP server. 399 If the EAP server authenticates unsuccessfully, the peer MAY send an 400 EAP-Response packet of EAP-Type=PEAP containing a TLS Alert message 401 identifying the reason for the failed authentication. The peer MAY send 402 a TLS alert message rather than immediately terminating the conversation 403 so as to allow the EAP server to log the cause of the error for 404 examination by the system administrator. 406 To ensure that the EAP Server receives the TLS alert message, the peer 407 MUST wait for the EAP-Server to reply before terminating the 408 conversation. The EAP Server MUST reply with an EAP-Failure packet 409 since server authentication failure is a terminal condition. 411 If the EAP server authenticates successfully, the peer MUST send an EAP- 412 Response packet of EAP-Type=PEAP, and no data. The EAP-Server then 413 continues with Part 2 of the PEAP conversation. 415 2.1.1. Forging of Success and Failure packets 417 Within EAP, Success and Failure packets are not authenticated, so that 418 they may be forged by an attacker without fear of detection. Forged EAP 419 Failure packets can be used to convince an EAP peer to disconnect. 420 Forged EAP Success packets may be used by a rogue NAS to convince a peer 421 to let itself access the network, even though the NAS has not 422 authenticated itself. 424 By requiring mutual authentication and by encrypting and integrity 425 protecting the EAP conversation within a TLS channel, PEAP provides 426 protection against these attacks. Since the EAP Server MUST authenticate 427 itself to the EAP Peer in PEAP Part 1, once the TLS channel has been 428 brought up, EAP Success or Failure packets should be sent down the 429 encrypted channel, rather than being sent in cleartext. As a result, 430 once PEAP has been selected as the authentication method, and the PEAP 431 conversation has begun, a peer receiving cleartext Success or Failure 432 packets MUST silently discard them. 434 2.2. PEAP Part 2 436 The second portion of the PEAP conversation consists of another complete 437 EAP conversation occurring within the TLS session negotiated in PEAP 438 Part 1. It will therefore occur only if establishment of the TLS session 439 in Part 1 is successful. It MUST NOT occur if the EAP Server 440 authenticates unsuccessfully or if an EAP-Failure has been sent by the 441 EAP Server to the peer, terminating the conversation. Since all packets 442 sent within the PEAP Part 2 conversation occur after TLS session 443 establishment, they are protected using the negotiated TLS ciphersuite. 445 Part 2 of the PEAP conversation typically begins with the Authenticator 446 sending an EAP-Request/Identity packet to the peer, protected by the TLS 447 ciphersuite negotiated in PEAP Part 1. The peer responds with an EAP- 448 Response/Identity packet to the authenticator, containing the peer's 449 userId. Since this Identity Request/Response exchange is protected by 450 the ciphersuite negotiated in TLS, it is protected against snooping or 451 packet modification attacks. 453 After the TLS session-protected Identity exchange, the EAP server will 454 then select authentication method(s) for the peer, and will send an EAP- 455 Request with the EAP-Type set to the initial method. As described in 456 [RFC2284], the peer can NAK the suggested EAP method, suggesting an 457 alternative. Since the NAK will be sent within the TLS channel, it is 458 protected from snooping or packet modification. As a result, an attacker 459 snooping on the exchange will be unable to inject NAKs in order to 460 "negotiate down" the authentication method. An attacker will also not 461 be able to determine which EAP method was negotiated. 463 As with a normal EAP conversation described in [RFC2284], an EAP 464 conversation encapsulated within the TLS channel as within PEAP Part 2 465 continues until the EAP server sends an EAP-Failure or EAP-Success. The 466 receipt of an EAP-Failure or EAP-Success within the TLS protected 467 channel results in a shutdown of the TLS channel by the peer and EAP 468 server. The EAP-Failure or EAP-Success packet sent within the TLS 469 channel is protected from snooping or packet modification, and as a 470 result, while an EAP server MAY send an additional EAP-Failure or EAP- 471 Success message in cleartext, this is not required, since it adds 472 another round-trip. As described in [RFC2869], a RADIUS Access-Accept or 473 Access-Reject packet need not contain an EAP-Message attribute, since 474 the NAS determines the success of the conversation from the RADIUS 475 message (Accept/Reject), not the encapsulated EAP-Message attribute. 477 2.3. Version negotiation 479 PEAP packets contain a two bit version field, which enables PEAP 480 implementations to be backward compatible with previous versions of the 481 protocol. Implementations of this specification MUST use a version field 482 set to 1. Version negotiation proceeds as follows: 484 [1] In the first EAP-Request sent with EAP type=PEAP, the EAP server 485 MUST set the version field to the highest supported version number. 487 [2] If the EAP client supports this version of the protocol, it MUST 488 respond with an EAP-Response of EAP type=PEAP, and the version 489 number proposed by the EAP server. 491 [3] If the EAP client does not support this version, it responds with 492 an EAP-Response of EAP type=PEAP and a lower version number, 493 indicating the highest supported version number. 495 [4] If the EAP server supports the version proposed by the client, then 496 all future EAP-Request and EAP-Response packets of EAP type=PEAP 497 MUST include the version field set to the agreed upon version 498 number. 500 [5] If the EAP server does not support the version number proposed by 501 the EAP client, it responds with an EAP-Failure sent in the clear. 503 This version negotiation procedure guarantees that the EAP client and 504 server will agree to the latest version supported by both parties. If 505 version negotiation fails, then use of PEAP will not be possible, and 506 another mutually acceptable EAP method will need to be negotiated if 507 authentication is to proceed. 509 2.4. Error handling 511 Other than supporting TLS alert messages, PEAP does not have its own 512 error message capabilities. This is unnecessary since errors in the PEAP 513 Part 1 conversation are communicated via TLS alert messages, and errors 514 in the PEAP Part 2 conversation are expected to be handled by individual 515 EAP methods. 517 If an error occurs at any point in the PEAP conversation, the EAP server 518 SHOULD send an EAP-Request packet with EAP-Type=PEAP, encapsulating a 519 TLS record containing the appropriate TLS alert message. The EAP server 520 SHOULD send a TLS alert message rather than immediately terminating the 521 conversation so as to allow the peer to inform the user of the cause of 522 the failure and possibly allow for a restart of the conversation. To 523 ensure that the peer receives the TLS alert message, the EAP server MUST 524 wait for the peer to reply with an EAP-Response packet. 526 2.5. Retry behavior 528 As with other EAP protocols, the EAP server is responsible for retry 529 behavior. This means that if the EAP server does not receive a reply 530 from the peer, it MUST resend the EAP-Request for which it has not yet 531 received an EAP-Response. However, the peer MUST NOT resend EAP-Response 532 packets without first being prompted by the EAP server. 534 For example, if the initial PEAP start packet sent by the EAP server 535 were to be lost, then the peer would not receive this packet, and would 536 not respond to it. As a result, the PEAP start packet would be resent by 537 the EAP server. Once the peer received the PEAP start packet, it would 538 send an EAP-Response encapsulating the client_hello message. If the 539 EAP-Response were to be lost, then the EAP server would resend the 540 initial PEAP start, and the peer would resend the EAP-Response. 542 As a result, it is possible that a peer will receive duplicate EAP- 543 Request messages, and may send duplicate EAP-Responses. Both the peer 544 and the EAP Server should be engineered to handle this possibility. 546 2.6. Session resumption 548 The purpose of the sessionId within the TLS protocol is to allow for 549 improved efficiency in the case where a client repeatedly attempts to 550 authenticate to an EAP server within a short period of time. This 551 capability is particularly useful for support of wireless roaming. 553 It is left up to the peer whether to attempt to continue a previous 554 session, thus shortening the PEAP Part 1 conversation. Typically the 555 peer's decision will be made based on the time elapsed since the 556 previous authentication attempt to that EAP server. Based on the 557 sessionId chosen by the peer, and the time elapsed since the previous 558 authentication, the EAP server will decide whether to allow the 559 continuation, or whether to choose a new session. 561 In the case where the EAP server and the authenticator reside on the 562 same device, then the client will only be able to continue sessions when 563 connecting to the same NAS or tunnel server. Should these devices be set 564 up in a rotary or round-robin then it may not be possible for the peer 565 to know in advance the authenticator it will be connecting to, and 566 therefore which sessionId to attempt to reuse. As a result, it is likely 567 that the continuation attempt will fail. 569 In the case where the EAP authentication is remoted then continuation is 570 much more likely to be successful, since multiple NAS devices and tunnel 571 servers will remote their EAP authentications to the same backend 572 authentication server. 574 If the EAP server is resuming a previously established session, then it 575 MUST include only a TLS change_cipher_spec message and a TLS finished 576 handshake message after the server_hello message. The finished message 577 contains the EAP server's authentication response to the peer. 579 2.7. Fragmentation 581 A single TLS record may be up to 16384 octets in length, but a TLS 582 message may span multiple TLS records, and a TLS certificate message may 583 in principle be as long as 16MB. The group of PEAP messages sent in a 584 single round may thus be larger than the PPP MTU size, the maximum 585 RADIUS packet size of 4096 octets, or even the Multilink Maximum 586 Received Reconstructed Unit (MRRU). As described in [2], the multilink 587 MRRU is negotiated via the Multilink MRRU LCP option, which includes an 588 MRRU length field of two octets, and thus can support MRRUs as large as 589 64 KB. 591 However, note that in order to protect against reassembly lockup and 592 denial of service attacks, it may be desirable for an implementation to 593 set a maximum size for one such group of TLS messages. Since a typical 594 certificate chain is rarely longer than a few thousand octets, and no 595 other field is likely to be anywhere near as long, a reasonable choice 596 of maximum acceptable message length might be 64 KB. 598 If this value is chosen, then fragmentation can be handled via the 599 multilink PPP fragmentation mechanisms described in [RFC1990]. While 600 this is desirable, EAP methods are used in other applications such as 601 [IEEE80211] and there may be cases in which multilink or the MRRU LCP 602 option cannot be negotiated. As a result, a PEAP implementation MUST 603 provide its own support for fragmentation and reassembly. 605 Since EAP is an ACK-NAK protocol, fragmentation support can be added in 606 a simple manner. In EAP, fragments that are lost or damaged in transit 607 will be retransmitted, and since sequencing information is provided by 608 the Identifier field in EAP, there is no need for a fragment offset 609 field as is provided in IPv4. 611 PEAP fragmentation support is provided through addition of flag bits 612 within the EAP-Response and EAP-Request packets, as well as a TLS 613 Message Length field of four octets. Flags include the Length included 614 (L), More fragments (M), and PEAP Start (S) bits. The L flag is set to 615 indicate the presence of the four octet TLS Message Length field, and 616 MUST be set for the first fragment of a fragmented TLS message or set of 617 messages. The M flag is set on all but the last fragment. The S flag is 618 set only within the PEAP start message sent from the EAP server to the 619 peer. The TLS Message Length field is four octets, and provides the 620 total length of the TLS message or set of messages that is being 621 fragmented; this simplifies buffer allocation. 623 When a PEAP peer receives an EAP-Request packet with the M bit set, it 624 MUST respond with an EAP-Response with EAP-Type=PEAP and no data. This 625 serves as a fragment ACK. The EAP server MUST wait until it receives the 626 EAP-Response before sending another fragment. In order to prevent errors 627 in processing of fragments, the EAP server MUST increment the Identifier 628 field for each fragment contained within an EAP-Request, and the peer 629 MUST include this Identifier value in the fragment ACK contained within 630 the EAP-Response. Retransmitted fragments will contain the same 631 Identifier value. 633 Similarly, when the EAP server receives an EAP-Response with the M bit 634 set, it MUST respond with an EAP-Request with EAP-Type=PEAP and no data. 635 This serves as a fragment ACK. The EAP peer MUST wait until it receives 636 the EAP-Request before sending another fragment. In order to prevent 637 errors in the processing of fragments, the EAP server MUST increment the 638 Identifier value for each fragment ACK contained within an EAP-Request, 639 and the peer MUST include this Identifier value in the subsequent 640 fragment contained within an EAP-Response. 642 2.8. Key derivation 644 Since the normal TLS keys are used in the handshake, and therefore 645 should not be used in a different context, new keys must be derived from 646 the TLS master secret for use with the selected link layer ciphersuites. 647 In the most general case, keying material must be provided for 648 authentication, encryption and initialization vectors (IVs) in each 649 direction. 651 Since EAP methods may not know the link layer ciphersuite that has been 652 negotiated, it may not be possible for them to provide link layer 653 ciphersuite-specific keys. In addition, attempting to provide such keys 654 is undesirable, since it would require the EAP method to be revised each 655 time a new link layer ciphersuite is developed. As a result, PEAP 656 derives master session keys which can subsequently be truncated for use 657 with a particular link layer ciphersuite. Since the truncation 658 algorithms are ciphersuite-specific, they are not discussed here; 659 examples of such algorithms are provided in [RFC3079]. This draft also 660 does not discuss the format of the attributes used to communicate the 661 master session keys from the backend authentication server to the NAS; 662 examples of such attributes are provided in [RFC2548]. 664 For both peer and EAP server, the derivation of master session keys 665 proceeds as follows: 667 [1] Given the master key negotiated by the TLS handshake, the 668 pseudorandom function (PRF) defined in the specification for the 669 version of TLS in use, and the value random defined as the 670 concatenation of the handshake message fields client_hello.random 671 and server_hello.random (in that order), the value PRF(master key, 672 "client PEAP encryption", random) is computed up to 128 bytes, and 673 the value PRF("", "client PEAP encryption", random) is computed up 674 to 64 bytes (where "" is an empty string). 676 [2] The peer master session encryption key (the one used for encrypting 677 data from peer to EAP server) is obtained by truncating to the 678 correct length the first 32 bytes of these two PRF output strings. 680 [3] The EAP server master session encryption key (the one used to 681 encrypting data from EAP server to peer), if different from the 682 client master session encryption key, is obtained by truncating to 683 the correct length the second 32 bytes of this same PRF output 684 string. 686 [4] The peer master session authentication key (the one used for 687 computing MACs for messages from peer to EAP server), if used, is 688 obtained by truncating to the correct length the third 32 bytes of 689 this same PRF output string. 691 [5] The EAP server master session authentication key (the one used for 692 computing MACs for messages from EAP server to peer), if used, and 693 if different from the peer master session authentication key, is 694 obtained by truncating to the correct length the fourth 32 bytes of 695 this same PRF output string. 697 [6] The peer master session initialization vector (IV), used for 698 messages from peer to EAP server, is obtained by truncating to the 699 cipher's block size the first 32 bytes of the second PRF output 700 string mentioned above. 702 [7] Finally, the EAP server master session initialization vector (IV), 703 used for messages from peer to EAP server, is obtained by 704 truncating to the cipher's block size the second 32 bytes of this 705 second PRF output. 707 Algorithms for the truncation of these encryption and authentication 708 master session keys are specific to each link layer ciphersuite. Link 709 layer ciphersuites in use with PPP include DESEbis [RFC2419], 3DES 710 [RFC2420] and MPPE [RFC3078]. IEEE 802.11 ciphersuites are described in 711 [IEEE80211]. An example of how encryption keys for use with MPPE 712 [RFC3078] are derived from the TLS master session keys is given in 713 [RFC3079]. Additional keys or other non-secret values (such as IVs) can 714 be obtained as needed by extending the outputs of the PRF beyond 128 715 bytes and 64 bytes, respectively. 717 2.9. Ciphersuite negotiation 719 Since TLS supports TLS ciphersuite negotiation, peers completing the TLS 720 negotiation will also have selected a TLS ciphersuite, which includes 721 key strength, encryption and hashing methods. However, unlike in 722 [RFC2716], within PEAP, the negotiated TLS ciphersuite relates only to 723 the mechanism by which the PEAP Part 2 conversation will be protected, 724 and has no relationship to link layer security mechanisms negotiated 725 within the PPP Encryption Control Protocol (ECP) [RFC1968] or within 726 IEEE 802.11 [IEEE80211]. 728 As a result, PEAP does not support secure negotiation of link layer 729 ciphersuites. While such a negotiation is preferable from a security 730 perspective, it is in practice difficult to integrate with existing PPP 731 and IEEE 802.11 link layer security negotiation, as well as with backend 732 authentication servers. 734 Depending on the link layer technology in use, the link layer security 735 negotiation will occur at different stages in the connection process. In 736 IEEE 802.11, selection of the link layer security mechanism occurs via 737 the association/re-association messages, prior to authentication. In 738 contrast, within PPP, link layer security negotiation occurs in ECP 739 [RFC1968], which occurs after authentication. 741 As a result, within IEEE 802.11, by the time that PEAP is invoked, the 742 link layer security technology has already been selected. Thus if PEAP 743 were to support a protected link layer ciphersuite negotiation whose 744 conclusion disagreed with the IEEE 802.11 negotiation, a reassociation 745 (and additional authentication!) would be required to synchronize the 746 results of the two negotiations. Within PPP, it is conceivable that the 747 results of a PEAP secure link layer security negotiation could be 748 subsequently reflected in the ECP negotiation. 750 There are other issues as well. While link layer ciphersuite 751 negotiation occurs between the peer and the NAS, the EAP conversation 752 occurs between the peer and the EAP server. Since the EAP server may 753 not be aware of the link layer ciphersuites supported by the NAS, it is 754 conceivable that the NAS and peer can negotiate a link layer ciphersuite 755 that is not supported by the NAS. To address this issue, it would be 756 necessary for the NAS to send the list of supported link layer 757 ciphersuites to the backend authentication server, and have the backend 758 security server respond with a list of acceptable choices. However, when 759 used with technologies such as IEEE 802.11 where link layer security 760 technology selection occurs prior to authentication, multiple 761 association/reassociation exchanges might be required to synchronize the 762 negotiations, resulting in extended connectivity loss. 764 The situation typically cannot be addressed merely by omitting IEEE 765 802.11 link layer security negotiation. Unless all users on the AP are 766 to be authenticated with PEAP or an alternative EAP method providing 767 secure link layer security negotiation, then omitting IEEE 802.11 768 security negotiation would leave some users without the ability to 769 negotiate security mechanisms. 771 For these reasons, protected negotiation of link layer ciphersuites 772 within PEAP is considered impractical and is omitted from this 773 specification. 775 3. Detailed description of the PEAP protocol 777 3.1. PEAP Packet Format 779 A summary of the PEAP Request/Response packet format is shown below. 780 The fields are transmitted from left to right. 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Code | Identifier | Length | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type | Flags |Ver| Data... 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 Code 792 1 - Request 793 2 - Response 795 Identifier 797 The Identifier field is one octet and aids in matching responses with 798 requests. 800 Length 802 The Length field is two octets and indicates the length of the EAP 803 packet including the Code, Identifier, Length, Type, and Data fields. 804 Octets outside the range of the Length field should be treated as 805 Data Link Layer padding and should be ignored on reception. 807 Type 809 25 - PEAP 811 Flags 813 0 1 2 3 4 5 814 +-+-+-+-+-+-+ 815 |L M S R R R| 816 +-+-+-+-+-+-+ 818 L = Length included 819 M = More fragments 820 S = PEAP start 821 R = Reserved (must be zero) 822 The L bit (length included) is set to indicate the presence of the 823 four octet TLS Message Length field, and MUST be set for the first 824 fragment of a fragmented TLS message or set of messages. The M bit 825 (more fragments) is set on all but the last fragment. The S bit (PEAP 826 start) is set in a PEAP Start message. This differentiates the PEAP 827 Start message from a fragment acknowledgment. 829 Version 831 0 1 832 +-+-+ 833 |R 1| 834 +-+-+ 836 R = Reserved (must be zero) 838 Data 840 The format of the Data field is determined by the Code field. 842 3.2. PEAP Request Packet 844 A summary of the PEAP Request packet format is shown below. The fields 845 are transmitted from left to right. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Code | Identifier | Length | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Type | Flags |Ver| TLS Message Length 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | TLS Message Length | TLS Data... 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Code 859 1 861 Identifier 863 The Identifier field is one octet and aids in matching responses with 864 requests. The Identifier field MUST be changed on each Request 865 packet. 867 Length 869 The Length field is two octets and indicates the length of the EAP 870 packet including the Code, Identifier, Length, Type, and TLS Response 871 fields. 873 Type 875 25 - PEAP 877 Flags 879 0 1 2 3 4 5 880 +-+-+-+-+-+-+ 881 |L M S R R R| 882 +-+-+-+-+-+-+ 884 L = Length included 885 M = More fragments 886 S = PEAP start 887 R = Reserved (must be zero) 889 The L bit (length included) is set to indicate the presence of the 890 four octet TLS Message Length field, and MUST be set for the first 891 fragment of a fragmented TLS message or set of messages. The M bit 892 (more fragments) is set on all but the last fragment. The S bit (PEAP 893 start) is set in a PEAP Start message. This differentiates the PEAP 894 Start message from a fragment acknowledgment. 896 Version 898 0 1 899 +-+-+ 900 |R 1| 901 +-+-+ 903 R = Reserved (must be zero) 905 TLS Message Length 907 The TLS Message Length field is four octets, and is present only if 908 the L bit is set. This field provides the total length of the TLS 909 message or set of messages that is being fragmented. 911 TLS data 913 The TLS data consists of the encapsulated packet in TLS record 914 format. 916 3.3. PEAP Response Packet 918 A summary of the PEAP Response packet format is shown below. The fields 919 are transmitted from left to right. 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Code | Identifier | Length | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type | Flags |Ver| TLS Message Length 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | TLS Message Length | TLS Data... 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Code 933 2 935 Identifier 937 The Identifier field is one octet and MUST match the Identifier field 938 from the corresponding request. 940 Length 942 The Length field is two octets and indicates the length of the EAP 943 packet including the Code, Identifier, Length, Type, and TLS data 944 fields. 946 Type 948 25 - PEAP 950 Flags 952 0 1 2 3 4 5 953 +-+-+-+-+-+-+ 954 |L M S R R R| 955 +-+-+-+-+-+-+ 957 L = Length included 958 M = More fragments 959 S = PEAP start 960 R = Reserved (must be zero) 962 The L bit (length included) is set to indicate the presence of the 963 four octet TLS Message Length field, and MUST be set for the first 964 fragment of a fragmented TLS message or set of messages. The M bit 965 (more fragments) is set on all but the last fragment. The S bit (PEAP 966 start) is set in a PEAP Start message. This differentiates the PEAP 967 Start message from a fragment acknowledgment. 969 Version 971 0 1 972 +-+-+ 973 |R 1| 974 +-+-+ 976 R = Reserved (must be zero) 978 TLS Message Length 980 The TLS Message Length field is four octets, and is present only if 981 the L bit is set. This field provides the total length of the TLS 982 message or set of messages that is being fragmented. 984 TLS data 986 The TLS data consists of the encapsulated TLS packet in TLS record 987 format. 989 4. Security Considerations 991 4.1. Method negotiation 993 If the peer does not support PEAP, or does not wish to utilize PEAP 994 authentication, it MUST respond to the initial EAP-Request/PEAP-Start 995 with a NAK, suggesting an alternate authentication method. Since the NAK 996 is sent in cleartext with no integrity protection or authentication, it 997 is subject to spoofing. Unauthentic NAK packets can be used to trick 998 the peer and Authenticator into "negotiating down" to a weaker form of 999 authentication, such as EAP-MD5 (which only provides one way 1000 authentication and does not derive a key). 1002 Since a subsequent protected EAP conversation can take place within the 1003 TLS session, selection of PEAP as an authentication method does not 1004 limit the potential secondary authentication methods. As a result, the 1005 only legitimate reason for a peer to NAK PEAP as an authentication 1006 method is that it does not support it. Where the additional security of 1007 PEAP is required, server implementations SHOULD respond to a NAK with an 1008 EAP-Failure, terminating the authentication conversation. 1010 4.2. TLS session cache handling 1012 In cases where a TLS session has been successfully resumed, in some 1013 circumstances, it is possible for the EAP server to skip the PEAP Part 1014 2 conversation entirely, and immediately send an EAP-Success message 1015 within the TLS channel established via session resumption. 1017 PEAP "fast reconnect" is desirable in applications such as wireless 1018 roaming, since it minimizes interruptions in connectivity. It is also 1019 desirable when the "inner" EAP mechanism used is such that it requires 1020 user interaction. The user should not be required to re-authenticate 1021 herself, using biometrics, token cards or similar, every time the radio 1022 connectivity is handed over between access points in wireless 1023 environments. 1025 However, there are issues that need to be understood in order to avoid 1026 introducing security vulnerabilities. 1028 Since PEAP Part 1 may not provide client authentication, establishment 1029 of a TLS session (and an entry in the TLS session cache) does not by 1030 itself provide an indication of the peer's authenticity. The peer's 1031 authenticity is only proven by successful completion of the PEAP Part 2 1032 authentication. 1034 Some PEAP implementations may not be capable of removing TLS session 1035 cache entries established in PEAP Part 1 after an unsuccessful PEAP Part 1036 2 authentication. In such implementations, the existence of a TLS 1037 session cache entry provides no indication that the peer has previously 1038 been authenticated. As a result, implementations that do not remove TLS 1039 session cache entries after a failed PEAP Part 2 authentication MUST use 1040 other means than successful TLS resumption as the indicator of whether 1041 the client is authenticated or not. Failing to do this would enable a 1042 peer to gain access by completing PEAP Part 1, tearing down the 1043 connection and re-connect and resume PEAP Part 1 thereby proving herself 1044 authenticated. Thus, TLS resumption MUST only be used as an indicator 1045 of whether the client is authenticated or not if the implementation 1046 supports TLS session cache removal. 1048 If an EAP server implementing PEAP removes TLS session cache entries of 1049 peers failing PEAP Part 2 authentication, then it SHOULD skip the PEAP 1050 Part 2 conversation entirely after a successful session resumption, 1051 immediately sending an EAP-Success message within the TLS channel. 1053 4.3. Certificate revocation 1055 Since the EAP server is on the Internet during the EAP conversation, the 1056 server is capable of following a certificate chain or verifying whether 1057 the peer's certificate has been revoked. In contrast, the peer may or 1058 may not have Internet connectivity, and thus while it can validate the 1059 EAP server's certificate based on a pre-configured set of CAs, it may 1060 not be able to follow a certificate chain or verify whether the EAP 1061 server's certificate has been revoked. 1063 In the case where the peer is initiating a voluntary Layer 2 tunnel 1064 using PPTP or L2TP, the peer will typically already have Internet 1065 connectivity established at the time of tunnel initiation. As a result, 1066 during the EAP conversation it is capable of checking for certificate 1067 revocation. 1069 As part of the TLS negotiation, the server presents a certificate to the 1070 peer. The peer SHOULD verify the validity of the EAP server 1071 certificate, and SHOULD also examine the EAP server name presented in 1072 the certificate, in order to determine whether the EAP server can be 1073 trusted. Please note that in the case where the EAP authentication is 1074 remoted, the EAP server will not reside on the same machine as the 1075 authenticator, and therefore the name in the EAP server's certificate 1076 cannot be expected to match that of the intended destination. In this 1077 case, a more appropriate test might be whether the EAP server's 1078 certificate is signed by a CA controlling the intended destination and 1079 whether the EAP server exists within a target sub-domain. 1081 In the case where the peer is attempting to obtain network access, it 1082 will not have Internet connectivity. The TLS Extensions [TLSEXT] support 1083 piggybacking of an Online Certificate Status Protocol (OCSP) response 1084 within TLS, therefore can be utilized by the peer in order to verify the 1085 validity of server certificate. However, since all TLS implementations 1086 do not implement the TLS extensions, it may be necessary for the peer to 1087 wait to check for certificate revocation until after Internet access has 1088 been obtained. In this case, the peer SHOULD conduct the certificate 1089 status check immediately upon going online and SHOULD NOT send data 1090 until it has received a positive response to the status request. If the 1091 server certificate is found to be invalid, then the peer SHOULD 1092 disconnect. 1094 4.4. Separation of the EAP server and the authenticator 1096 As a result of a complete PEAP Part 1 and Part 2 conversation, the EAP 1097 endpoints will mutually authenticate, and derive a session key for 1098 subsequent use in link layer security. Since the peer and EAP client 1099 reside on the same machine, it is necessary for the EAP client module to 1100 pass the session key to the link layer encryption module. 1102 The situation may be more complex on the Authenticator, which may or may 1103 not reside on the same machine as the EAP server. In the case where the 1104 EAP server and the Authenticator reside on different machines, there are 1105 several implications for security. Firstly, the mutual authentication 1106 defined in PEAP will occur between the peer and the EAP server, not 1107 between the peer and the authenticator. This means that as a result of 1108 the PEAP conversation, it is not possible for the peer to validate the 1109 identity of the NAS or tunnel server that it is speaking to. 1111 The second issue is that the session key negotiated between the peer and 1112 EAP server will need to be transmitted to the authenticator. Therefore 1113 a mechanism needs to be provided to transmit the session key from the 1114 EAP server to the authenticator or tunnel server that needs to use the 1115 key. The specification of this transit mechanism is outside the scope of 1116 this document. 1118 4.5. Separation of PEAP Part 1 and Part 2 Servers 1120 The EAP server involved in PEAP Part 2 need not necessarily be the same 1121 as the EAP server involved in PEAP Part 1. For example, a local 1122 authentication server or proxy might serve as the endpoint for the Part 1123 1 conversation, establishing the TLS channel. Subsequently, once the 1124 EAP-Response/Identity has been received within the TLS channel, it can 1125 be decrypted and forwarded in cleartext to the destination realm EAP 1126 server. The rest of the conversation will therefore occur between the 1127 destination realm EAP server and the peer, with the local authentication 1128 server or proxy acting as an encrypting/decrypting gateway. This permits 1129 a non-TLS capable EAP server to participate in the PEAP conversation. 1131 Note however that such an approach introduces security vulnerabilities. 1132 Since the EAP Response/Identity is sent in the clear between the proxy 1133 and the EAP server, this enables an attacker to snoop the user's 1134 identity. It also enables a remote environments, which may be public 1135 hot spots or Internet coffee shops, to gain knowledge of the identity of 1136 their users. Since one of the potential benefits of PEAP is identity 1137 protection, this is undesirable. 1139 If the EAP method negotiated during PEAP Part 2 does not support mutual 1140 authentication, then if the Part 2 conversation is proxied to another 1141 destination, the PEAP peer will not have the opportunity to verify the 1142 secondary EAP server's identity. Only the initial EAP server's identity 1143 will have been verified as Part of TLS session establishment. 1145 Similarly, if the EAP method negotiated during PEAP Part 2 is vulnerable 1146 to dictionary attack, then an attacker capturing the cleartext exchange 1147 will be able to mount an offline dictionary attack on the password. 1149 Finally, when a Part 2 conversation is terminated at a different 1150 location than the Part 1 conversation, the Part 2 destination is unaware 1151 that the EAP client has negotiated PEAP. As a result, it is unable to 1152 enforce policies requiring PEAP. Since some EAP methods require PEAP in 1153 order to generate keys or lessen security vulnerabilities, where such 1154 methods are in use, such a configuration may be unacceptable. 1156 In summary, PEAP encrypting/decrypting gateway configurations are 1157 vulnerable to attack and SHOULD NOT be used. Instead, the entire PEAP 1158 connection SHOULD be proxied to the final destination, and the 1159 subsequently derived master session keys need to be transmitted back. 1160 This provides end to end protection of PEAP. The specification of this 1161 transit mechanism is outside the scope of this document, but mechanisms 1162 similar to [RFC2548] can be used. These steps protects the client from 1163 revealing her identity to the remote environment. 1165 In order to find the proper PEAP destination, the EAP client SHOULD 1166 place a Network Access Identifier (NAI) conforming to [RFC2486] in the 1167 Identity Response. 1169 There may be cases where a natural trust relationship exists between the 1170 (foreign) authentication server and final EAP server, such as on a 1171 campus or between two offices within the same company, where there is no 1172 danger in revealing the identity of the station to the authentication 1173 server. In these cases, using a proxy solution without end to end 1174 protection of PEAP MAY be used. The PEAP encrypting/decrypting gateway 1175 SHOULD provide support for IPsec protection of RADIUS in order to 1176 provide confidentiality for the portion of the conversation between the 1177 gateway and the EAP server, as described in [RFC3162]. 1179 4.6. Identity verification 1181 Since the TLS session has not yet been negotiated, the initial Identity 1182 request/response occurs in the clear without integrity protection or 1183 authentication. It is therefore subject to snooping and packet 1184 modification. 1186 In configurations where all users are required to authenticate with PEAP 1187 and the first portion of the PEAP conversation is terminated at a local 1188 backend authentication server, without routing by proxies, the initial 1189 cleartext Identity Request/Response exchange is not needed in order to 1190 determine the required authentication method(s) or route the 1191 authentication conversation to its destination. As a result, the initial 1192 Identity and Request/Response exchange MAY NOT be present, and a 1193 subsequent Identity Request/Response exchange MAY occur after the TLS 1194 session is established. 1196 If the initial cleartext Identity Request/Response has been tampered 1197 with, after the TLS session is established, it is conceivable that the 1198 EAP Server will discover that it cannot verify the peer's claim of 1199 identity. For example, the peer's userID may not be valid or may not be 1200 within a realm handled by the EAP server. Rather than attempting to 1201 proxy the authentication to the server within the correct realm, the EAP 1202 server SHOULD terminate the conversation. 1204 The PEAP peer can present the server with multiple identities. This 1205 includes the claim of identity within the initial EAP-Response/Identity 1206 (MyID) packet, which is typically used to route the EAP conversation to 1207 the appropriate home backend authentication server. There may also be 1208 subsequent EAP-Response/Identity packets sent by the peer once the TLS 1209 tunnel has been established. 1211 Note that since the PEAP peer may not present a certificate, it is not 1212 always possible to check the initial EAP-Response/Identity against the 1213 identity presented in the certificate, as is done in [RFC2716]. 1214 Moreover, it cannot be assumed that the peer identities presented within 1215 multiple EAP-Response/Identity packets will be the same. For example, 1216 the initial EAP-Response/Identity might correspond to a machine 1217 identity, while subsequent identities might be those of the user. Thus, 1218 PEAP implementations SHOULD NOT abort the authentication just because 1219 the identities do not match. However, since the initial EAP- 1220 Response/Identity will determine the EAP server handling the 1221 authentication, if this or any other identity is inappropriate for use 1222 with the destination EAP server, there is no alternative but to 1223 terminate the PEAP conversation. 1225 The protected identity or identities presented by the peer within PEAP 1226 Part 2 may not be identical to the cleartext identity presented in PEAP 1227 Part 1, for legitimate reasons. In order to shield the userID from 1228 snooping, the cleartext Identity may only provide enough information to 1229 enable routing of the authentication request to the correct realm. For 1230 example, the peer may initially claim the identity of "nouser@bigco.com" 1231 in order to route the authentication request to the bigco.com EAP 1232 server. Subsequently, once the TLS session has been negotiated, in PEAP 1233 Part 2, the peer may claim the identity of "fred@bigco.com". Thus, PEAP 1234 can provide protection for the user's identity, though not necessarily 1235 the destination realm, unless the PEAP Part 1 conversation terminates at 1236 the local authentication server. 1238 As a result, PEAP implementations SHOULD NOT attempt to compare the 1239 Identities claimed with Parts 1 and 2 of the PEAP conversation. 1240 Similarly, if multiple Identities are claimed within PEAP Part 2, these 1241 SHOULD NOT be compared. An EAP conversation may involve more than one 1242 EAP authentication method, and the identities claimed for each of these 1243 authentications could be different (e.g. a machine authentication, 1244 followed by a user authentication). 1246 5. Normative references 1248 [RFC1321] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1249 1321, April 1992. 1251 [RFC1570] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1252 1994. 1254 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 1255 51, RFC 1661, July 1994. 1257 [RFC1962] D. Rand. "The PPP Compression Control Protocol", RFC 1962, 1258 Novell, June 1996. 1260 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1261 1996. 1263 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 1264 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1265 1996. 1267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1268 Requirement Levels", BCP 14, RFC 2119, March 1997. 1270 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 1271 2246, November 1998. 1273 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 1274 Protocol (EAP)", RFC 2284, March 1998. 1276 [RFC2486] Aboba, B., Beadles, M., "The Network Access Identifier", RFC 1277 2486, January 1999. 1279 [TLSEXT] Blake-Wilson, S., et al. "TLS Extensions", Internet draft 1280 (work in progress), draft-ietf-tls-extensions-02.txt, December 1281 2001. 1283 [IEEE8021X] 1284 IEEE Standards for Local and Metropolitan Area Networks: Port 1285 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 1287 6. Informative references 1289 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 1290 Version 2 (DESE-bis)", RFC 2419, September 1998. 1292 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 1293 RFC 2420, September 1998. 1295 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1296 RFC2548, March 1999. 1298 [RFC2716] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", 1299 RFC 2716, October 1999. 1301 [RFC3078] Pall, G., Zorn, G., "Microsoft Point-to-Point Encryption 1302 (MPPE) Protocol", RFC 3078, March 2001. 1304 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 1305 Encryption (MPPE)", RFC 3079, March 2001. 1307 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS 1308 PUB 46 (January 1977). 1310 [IEEE80211] 1311 Information technology - Telecommunications and information 1312 exchange between systems - Local and metropolitan area 1313 networks - Specific Requirements Part 11: Wireless LAN Medium 1314 Access Control (MAC) and Physical Layer (PHY) Specifications, 1315 IEEE Std. 802.11-1999, 1999. 1317 [MODES] National Bureau of Standards, "DES Modes of Operation", FIPS 1318 PUB 81 (December 1980). 1320 Appendix A - Examples 1322 In the case where the identity exchange occurs within PEAP Part 1, the 1323 conversation will appear as follows: 1325 Authenticating Peer Authenticator 1326 ------------------- ------------- 1327 <- EAP-Request/ 1328 Identity 1329 EAP-Response/ 1330 Identity (MyID) -> 1331 <- EAP-Request/ 1332 EAP-Type=PEAP 1333 (PEAP Start, S bit set) 1335 EAP-Response/ 1336 EAP-Type=PEAP 1337 (TLS client_hello)-> 1338 <- EAP-Request/ 1339 EAP-Type=PEAP 1340 (TLS server_hello, 1341 TLS certificate, 1342 [TLS server_key_exchange,] 1343 [TLS certificate_request,] 1344 TLS server_hello_done) 1345 EAP-Response/ 1346 EAP-Type=PEAP 1347 ([TLS certificate,] 1348 TLS client_key_exchange, 1349 [TLS certificate_verify,] 1350 TLS change_cipher_spec, 1351 TLS finished) -> 1352 <- EAP-Request/ 1353 EAP-Type=PEAP 1354 (TLS change_cipher_spec, 1355 TLS finished) 1357 TLS channel established 1358 (messages sent within the TLS channel) 1360 EAP-Response/ 1361 EAP-Type=PEAP -> 1363 <- EAP-Request/ 1364 Identity 1365 EAP-Response/ 1366 Identity (MyID) -> 1367 <- EAP-Request/ 1368 EAP-Type=X 1369 EAP-Response/ 1370 EAP-Type=X or NAK -> 1372 <- EAP-Request/ 1373 EAP-Type=X 1374 EAP-Response/ 1375 EAP-Type=X -> 1377 <- EAP-Success 1379 TLS channel torn down 1380 (messages sent in cleartext) 1382 Where all peers are known to support PEAP, and the PEAP Part 1 1383 conversation is carried out between the peer and a local EAP server, the 1384 cleartext identity exchange may be omitted and the conversation appears 1385 as follows: 1387 Authenticating Peer Authenticator 1388 ------------------- ------------- 1389 <- EAP-Request/ 1390 EAP-Type=PEAP 1391 (PEAP Start, S bit set) 1393 EAP-Response/ 1394 EAP-Type=PEAP 1395 (TLS client_hello)-> 1396 <- EAP-Request/ 1397 EAP-Type=PEAP 1398 (TLS server_hello, 1399 TLS certificate, 1400 [TLS server_key_exchange,] 1401 [TLS certificate_request,] 1402 TLS server_hello_done) 1403 EAP-Response/ 1404 EAP-Type=PEAP 1405 ([TLS certificate,] 1406 TLS client_key_exchange, 1407 [TLS certificate_verify,] 1408 TLS change_cipher_spec, 1409 TLS finished) -> 1410 <- EAP-Request/ 1411 EAP-Type=PEAP 1412 (TLS change_cipher_spec, 1413 TLS finished) 1415 TLS channel established 1416 (messages sent within the TLS channel) 1418 EAP-Response/ 1419 EAP-Type=PEAP -> 1421 <- EAP-Request/ 1422 Identity 1423 EAP-Response/ 1424 Identity (MyID) -> 1425 <- EAP-Request/ 1426 EAP-Type=X 1427 EAP-Response/ 1428 EAP-Type=X or NAK -> 1430 <- EAP-Request/ 1431 EAP-Type=X 1432 EAP-Response/ 1433 EAP-Type=X -> 1435 <- EAP-Success 1437 TLS channel torn down 1438 (messages sent in cleartext) 1440 In the case where the PEAP fragmentation is required, the conversation 1441 will appear as follows: 1443 Authenticating Peer Authenticator 1444 ------------------- ------------- 1445 <- EAP-Request/ 1446 Identity 1447 EAP-Response/ 1448 Identity (MyID) -> 1449 <- EAP-Request/ 1450 EAP-Type=PEAP 1451 (PEAP Start, S bit set) 1453 EAP-Response/ 1454 EAP-Type=PEAP 1455 (TLS client_hello)-> 1456 <- EAP-Request/ 1457 EAP-Type=PEAP 1458 (TLS server_hello, 1459 TLS certificate, 1460 [TLS server_key_exchange,] 1461 [TLS certificate_request,] 1462 TLS server_hello_done) 1463 (Fragment 1: L, M bits set) 1465 EAP-Response/ 1466 EAP-Type=PEAP -> 1467 <- EAP-Request/ 1468 EAP-Type=PEAP 1469 (Fragment 2: M bit set) 1470 EAP-Response/ 1471 EAP-Type=PEAP -> 1472 <- EAP-Request/ 1473 EAP-Type=PEAP 1474 (Fragment 3) 1475 EAP-Response/ 1476 EAP-Type=PEAP 1477 ([TLS certificate,] 1478 TLS client_key_exchange, 1479 [TLS certificate_verify,] 1480 TLS change_cipher_spec, 1481 TLS finished) 1482 (Fragment 1: L, M bits set)-> 1484 <- EAP-Request/ 1485 EAP-Type=PEAP 1486 EAP-Response/ 1487 EAP-Type=PEAP 1488 (Fragment 2)-> 1489 <- EAP-Request/ 1490 EAP-Type=PEAP 1491 (TLS change_cipher_spec, 1492 TLS finished) 1494 TLS channel established 1495 (messages sent within the TLS channel) 1497 EAP-Response/ 1498 EAP-Type=PEAP -> 1500 <- EAP-Request/ 1501 Identity 1502 EAP-Response/ 1503 Identity (MyID) -> 1504 <- EAP-Request/ 1505 EAP-Type=X 1506 EAP-Response/ 1507 EAP-Type=X or NAK -> 1509 <- EAP-Request/ 1510 EAP-Type=X 1511 EAP-Response/ 1512 EAP-Type=X -> 1513 <- EAP-Success 1515 TLS channel torn down 1516 (messages sent in cleartext) 1518 In the case where the server authenticates to the client successfully in 1519 PEAP Part 1, but the client fails to authenticate to the server in PEAP 1520 Part 2, the conversation will appear as follows: 1522 Authenticating Peer Authenticator 1523 ------------------- ------------- 1524 <- EAP-Request/ 1525 Identity 1526 EAP-Response/ 1527 Identity (MyID) -> 1528 <- EAP-Request/ 1529 EAP-Type=PEAP 1530 (PEAP Start, S bit set) 1531 EAP-Response/ 1532 EAP-Type=PEAP 1533 (TLS client_hello)-> 1534 <- EAP-Request/ 1535 EAP-Type=PEAP 1536 (TLS server_hello, 1537 TLS certificate, 1538 [TLS server_key_exchange,] 1539 [TLS certificate_request,] 1540 TLS server_hello_done) 1541 EAP-Response/ 1542 EAP-Type=PEAP 1543 ([TLS certificate,] 1544 TLS client_key_exchange, 1545 [TLS certificate_verify,] 1546 TLS change_cipher_spec, 1547 TLS finished) -> 1548 <- EAP-Request/ 1549 EAP-Type=PEAP 1550 (TLS change_cipher_spec, 1551 TLS finished) 1553 TLS channel established 1554 (messages sent within the TLS channel) 1556 EAP-Response/ 1557 EAP-Type=PEAP -> 1559 <- EAP-Request/ 1560 Identity 1562 EAP-Response/ 1563 Identity (MyID) -> 1564 <- EAP-Request/ 1565 EAP-Type=X 1566 EAP-Response/ 1567 EAP-Type=X or NAK -> 1569 <- EAP-Request/ 1570 EAP-Type=X 1571 EAP-Response/ 1572 EAP-Type=X -> 1574 <- EAP-Failure 1575 (TLS session cache entry flushed) 1577 TLS channel torn down 1578 (messages sent in cleartext) 1580 In the case where server authentication is unsuccessful in PEAP Part 1, 1581 the conversation will appear as follows: 1583 Authenticating Peer Authenticator 1584 ------------------- ------------- 1585 <- EAP-Request/ 1586 Identity 1587 EAP-Response/ 1588 Identity (MyID) -> 1589 <- EAP-Request/ 1590 EAP-Type=PEAP 1591 (PEAP Start) 1592 EAP-Response/ 1593 EAP-Type=PEAP 1594 (TLS client_hello)-> 1595 <- EAP-Request/ 1596 EAP-Type=PEAP 1597 (TLS server_hello, 1598 TLS certificate, 1599 [TLS server_key_exchange,] 1600 TLS server_hello_done) 1601 EAP-Response/ 1602 EAP-Type=PEAP 1603 (TLS client_key_exchange, 1604 [TLS certificate_verify,] 1605 TLS change_cipher_spec, 1606 TLS finished) -> 1607 <- EAP-Request/ 1608 EAP-Type=PEAP 1609 (TLS change_cipher_spec, 1610 TLS finished) 1611 EAP-Response/ 1612 EAP-Type=PEAP 1613 (TLS change_cipher_spec, 1614 TLS finished) 1616 <- EAP-Request/ 1617 EAP-Type=PEAP 1618 PPP EAP-Response/ 1619 EAP-Type=PEAP 1620 (TLS Alert message) -> 1621 <- EAP-Failure 1622 (TLS session cache entry flushed) 1624 In the case where a previously established session is being resumed, the 1625 EAP server supports TLS session cache flushing for unsuccessful PEAP 1626 Part 2 authentications and both sides authenticate successfully, the 1627 conversation will appear as follows: 1629 Authenticating Peer Authenticator 1630 ------------------- ------------- 1631 <- EAP-Request/ 1632 Identity 1633 EAP-Response/ 1634 Identity (MyID) -> 1635 <- PPP EAP-Request/ 1636 EAP-Request/ 1637 EAP-Type=PEAP 1638 (PEAP Start) 1639 EAP-Response/ 1640 EAP-Type=PEAP 1641 (TLS client_hello)-> 1642 <- EAP-Request/ 1643 EAP-Type=PEAP 1644 (TLS server_hello, 1645 TLS change_cipher_spec 1646 TLS finished) 1647 EAP-Response/ 1648 EAP-Type=PEAP 1649 (TLS change_cipher_spec, 1650 TLS finished) -> 1651 <- EAP-Success 1653 In the case where a previously established session is being resumed, and 1654 the server authenticates to the client successfully but the client fails 1655 to authenticate to the server, the conversation will appear as follows: 1657 Authenticating Peer Authenticator 1658 ------------------- ------------- 1659 <- EAP-Request/ 1660 Identity 1661 EAP-Response/ 1662 Identity (MyID) -> 1663 <- EAP-Request/ 1664 EAP-Request/ 1665 EAP-Type=PEAP 1666 (TLS Start) 1667 EAP-Response/ 1668 EAP-Type=PEAP 1669 (TLS client_hello) -> 1670 <- EAP-Request/ 1671 EAP-Type=PEAP 1672 (TLS server_hello, 1673 TLS change_cipher_spec, 1674 TLS finished) 1675 EAP-Response/ 1676 EAP-Type=PEAP 1677 (TLS change_cipher_spec, 1678 TLS finished) -> 1679 <- EAP-Request 1680 EAP-Type=PEAP 1681 (TLS Alert message) 1682 EAP-Response 1683 EAP-Type=PEAP -> 1684 <- EAP-Failure 1685 (TLS session cache entry flushed) 1687 In the case where a previously established session is being resumed, and 1688 the server authentication is unsuccessful, the conversation will appear 1689 as follows: 1691 Authenticating Peer Authenticator 1692 ------------------- ------------- 1693 <- EAP-Request/ 1694 Identity 1695 EAP-Response/ 1696 Identity (MyID) -> 1697 <- EAP-Request/ 1698 EAP-Request/ 1699 EAP-Type=PEAP 1700 (TLS Start) 1702 EAP-Response/ 1703 EAP-Type=PEAP 1704 (TLS client_hello)-> 1705 <- EAP-Request/ 1706 EAP-Type=PEAP 1707 (TLS server_hello, 1708 TLS change_cipher_spec, 1709 TLS finished) 1710 EAP-Response/ 1711 EAP-Type=PEAP 1712 (TLS change_cipher_spec, 1713 TLS finished) 1714 <- EAP-Request/ 1715 EAP-Type=PEAP 1716 EAP-Response/ 1717 EAP-Type=PEAP 1718 (TLS Alert message) -> 1719 <- EAP-Failure 1720 (TLS session cache entry flushed) 1722 Acknowledgments 1724 Thanks to Jan-Ove Larsson and Magnus Nystrom of RSA Security, and 1725 Narendra Gidwani and Bernard Aboba of Microsoft for useful discussions 1726 of this problem space. 1728 Author Addresses 1730 Hakan Andersson 1731 RSA Security 1732 Box 107 04 1733 SE-121 29 Stockholm 1734 Sweden 1736 Phone: +46 8 725 9758 1737 Fax: +46 8 649 4970 1738 EMail: handersson@rsasecurity.com 1740 Simon Josefsson 1741 RSA Security 1742 Box 107 04 1743 SE-121 29 Stockholm 1744 Sweden 1746 Phone: +46 8 725 0914 1747 Fax: +46 8 649 4970 1748 EMail: sjosefsson@rsasecurity.com 1750 Glen Zorn 1751 Cisco Systems 1752 500 108th Avenue N.E. 1753 Suite 500 1754 Bellevue, Washington 98004 1755 USA 1757 Phone: + 1 425 438 8210 1758 Fax: + 1 425 438 1848 1759 EMail: gwz@cisco.com 1761 Dan Simon 1762 Microsoft Corporation 1763 One Microsoft Way 1764 Redmond, WA 98052 1766 Phone: +1 425 706 6711 1767 EMail: dansimon@microsoft.com 1769 Ashwin Palekar 1770 Microsoft Corporation 1771 One Microsoft Way 1772 Redmond, WA 98052 1774 Phone: +1 425 882 8080 1775 EMail: ashwinp@microsoft.com 1777 Intellectual Property Statement 1779 The IETF takes no position regarding the validity or scope of any 1780 intellectual property or other rights that might be claimed to pertain 1781 to the implementation or use of the technology described in this 1782 document or the extent to which any license under such rights might or 1783 might not be available; neither does it represent that it has made any 1784 effort to identify any such rights. Information on the IETF's 1785 procedures with respect to rights in standards-track and standards- 1786 related documentation can be found in BCP-11. Copies of claims of 1787 rights made available for publication and any assurances of licenses to 1788 be made available, or the result of an attempt made to obtain a general 1789 license or permission for the use of such proprietary rights by 1790 implementors or users of this specification can be obtained from the 1791 IETF Secretariat. 1793 The IETF invites any interested party to bring to its attention any 1794 copyrights, patents or patent applications, or other proprietary rights 1795 which may cover technology that may be required to practice this 1796 standard. Please address the information to the IETF Executive 1797 Director. 1799 Full Copyright Statement 1801 Copyright (C) The Internet Society (2002). All Rights Reserved. 1802 This document and translations of it may be copied and furnished to 1803 others, and derivative works that comment on or otherwise explain it or 1804 assist in its implementation may be prepared, copied, published and 1805 distributed, in whole or in part, without restriction of any kind, 1806 provided that the above copyright notice and this paragraph are included 1807 on all such copies and derivative works. However, this document itself 1808 may not be modified in any way, such as by removing the copyright notice 1809 or references to the Internet Society or other Internet organizations, 1810 except as needed for the purpose of developing Internet standards in 1811 which case the procedures for copyrights defined in the Internet 1812 Standards process must be followed, or as required to translate it into 1813 languages other than English. The limited permissions granted above are 1814 perpetual and will not be revoked by the Internet Society or its 1815 successors or assigns. This document and the information contained 1816 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1817 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1818 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1819 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1822 Expiration Date 1824 This memo is filed as , and 1825 expires March 19, 2003.