idnits 2.17.1 draft-josefsson-pppext-eap-tls-eap-07.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 71 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 72 pages 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 552 has weird spacing: '...ssionId will ...' == Line 1039 has weird spacing: '...include the 6...' == Line 2059 has weird spacing: '... server to sk...' == Line 3381 has weird spacing: '... and expire...' == 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: Even if the session is successfully resumed with the same EAP server, the peer and EAP server MUST not assume that either will skip inner EAP methods. The peer may have roamed to a network which may use the same EAP server, but may require conformance with a different authentication policy. == 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: Part 2 MAY NOT always include a EAP conversation within the TLS session, referred to in this document as inner EAP methods. However, Part 2 MUST always end with either protected termination or protected error termination. == 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: PEAPv2 implementations MUST support the Vendor-Specific TLV; and this TLV cannot be responded to with a NAK TLV. PEAPv2 implementations MAY NOT support the Vendor-TLVs included in the Vendor-Specific TLV and can respond with a NAK TLV. == 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 PEAPv2 and the first portion of the PEAPv2 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) == Missing Reference: 'IEEE80211i' is mentioned on line 303, but not defined -- Looks like a reference, but probably isn't: '1' on line 673 -- Looks like a reference, but probably isn't: '2' on line 676 -- Looks like a reference, but probably isn't: '3' on line 680 -- Looks like a reference, but probably isn't: '4' on line 684 == Missing Reference: 'RFC2284BIS' is mentioned on line 747, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Missing Reference: 'RFC228bis' is mentioned on line 2386, but not defined == Unused Reference: 'RFC1321' is defined on line 2486, but no explicit reference was found in the text == Unused Reference: 'RFC2419' is defined on line 2519, but no explicit reference was found in the text == Unused Reference: 'RFC2420' is defined on line 2522, but no explicit reference was found in the text == Unused Reference: 'RFC3078' is defined on line 2535, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 2538, but no explicit reference was found in the text == Unused Reference: 'FIPSDES' is defined on line 2541, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 2551, but no explicit reference was found in the text == Unused Reference: 'PEAPv0' is defined on line 2554, but no explicit reference was found in the text == Unused Reference: 'CompoundBinding' is defined on line 2568, 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 2486 (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-06 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-08) exists of draft-orman-public-key-lengths-05 == Outdated reference: A later version (-04) exists of draft-puthenkulam-eap-binding-03 Summary: 9 errors (**), 0 flaws (~~), 28 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPPEXT Working Group Ashwin Palekar 2 INTERNET-DRAFT Dan Simon 3 Category: Standards Track Microsoft Corporation 4 Glen Zorn 5 26 October 2003 Joe Salowey 6 Hao Zhou 7 Cisco Systems 8 S. Josefsson 9 Exundo 11 Protected EAP Protocol (PEAP) Version 2 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 (2003). All Rights Reserved. 35 Abstract 37 The Extensible Authentication Protocol (EAP) provides for support of 38 multiple authentication methods. This document defines the Protected 39 Extensible Authentication Protocol (PEAP) Version 2, which provides 40 an encrypted and authenticated tunnel based on transport layer 41 security (TLS) that encapsulates EAP authentication mechanisms. 42 PEAPv2 uses TLS to protect against rogue authenticators, protect 43 against various attacks on the confidentiality and integrity of the 44 inner EAP method exchange and provide EAP peer identity privacy. 45 PEAPv2 also provides support for chaining multiple EAP mechanisms, 46 cryptographic binding between authentications performed by inner EAP 47 mechanisms and the tunnel, exchange of arbitrary parameters (TLVs), 48 optimized session resumption, and fragmentation and reassembly. 50 Table of Contents 52 1. Introduction .......................................... 4 53 1.1 Requirements language ........................... 6 54 1.2 Terminology ..................................... 6 55 1.3 Operational model ............................... 8 56 2. Protocol overview ..................................... 11 57 2.1 PEAPv2 Part 1 .................................. 11 58 2.2 PEAPv2 Part 2 .................................. 16 59 2.3 Error handling ................................. 19 60 2.4 Fragmentation .................................. 21 61 2.5 Key derivation ................................. 22 62 2.6 Ciphersuite negotiation ........................ 24 63 3. Detailed description of the PEAPv2 protocol .......... 25 64 3.1 PEAPv2 Packet Format ........................... 25 65 3.2 PEAPv2 Request Packet .......................... 26 66 3.3 PEAPv2 Response Packet ......................... 28 67 3.4 PEAPv2 Part 2 Packet Format ................... 29 68 4. EAP TLV method ....................................... 30 69 4.1 EAP-TLV Request packet ......................... 30 70 4.2 EAP-TLV Response packet ......,,................ 31 71 4.3 TLV format ..................................... 32 72 4.4 Result TLV ..................................... 33 73 4.5 NAK TLV ........................................ 34 74 4.6 Crypto-Binding TLV ............................. 35 75 4.7 Connection-Binding TLV ......................... 37 76 4.8 Vendor-Specific TLV ............................ 38 77 4.9 URI TLV ........................................ 39 78 4.10 EAP Payload TLV ................................ 40 79 4.11 Intermediate Result TLV ........................ 41 80 4.12 TLV Rules ...................................... 42 81 5. Security considerations .............................. 43 82 5.1 Authentication and integrity protection ........ 43 83 5.2 Method negotiation ............................. 44 84 5.3 TLS session cache handling ..................... 44 85 5.4 Certificate revocation ......................... 45 86 5.5 Separation of EAP server and authenticator ..... 46 87 5.6 Separation of PEAPv2 Part 1 and Part 2 Servers . 47 88 5.7 Identity verification .......................... 48 89 5.8 Man-in-the-middle attack protection ............ 50 90 5.9 Cleartext forgeries ............................ 50 91 5.10 TLS Ciphersuites ............................... 51 92 5.11 Denial of service attacks ...................... 51 93 5.12 Security Claims ................................ 52 95 6. IANA Considerations ................................. 53 96 6.1 Definition of Terms ............................ 53 97 6.2 Recommended Registration Policies .............. 53 98 7. References .......................................... 53 99 7.1 Normative references ........................... 53 100 7.2 Informative references ......................... 54 101 Appendix A - Examples ........................................ 56 102 Acknowledgments .............................................. 70 103 Author's Addresses ........................................... 70 104 Intellectual Property Statement .............................. 71 105 Full Copyright Statement ..................................... 72 106 1. Introduction 108 The Extensible Authentication Protocol (EAP), defined in 109 [RFC2284bis], provides for support of multiple authentication 110 methods. EAP was developed for use on wired networks, where physical 111 security was presumed. EAP over PPP, defined in [RFC2284bis], is 112 typically deployed with leased lines or modem connections, requiring 113 an attacker to gain access to the telephone network in order to snoop 114 on the conversation or inject packets. [IEEE8021X] defines EAP over 115 IEEE 802 local area networks(EAPOL), presuming the existence of 116 switched media; in order to snoop or inject packets, an attacker 117 would need to gain administrative access to the switch. Due to the 118 presumption of physical security, facilities for protection of the 119 EAP conversation were not provided. Where an attacker can easily gain 120 access to the medium (such as on a wireless network or where EAP is 121 run over IP), the presumption of physical security is no longer 122 valid. 124 Since its deployment, a number of weaknesses in EAP framework have 125 become apparent. These include lack of: 127 identity protection 128 protected method negotiation 129 protected notification messages 130 protected termination messages 131 support for sequences of EAP methods 132 support for fragmentation and reassembly 133 support for a generic way to exchange arbitrary 134 parameters in a secure channel 135 support for generic optimized re-authentication 137 In addition many EAP methods lack the following features: 139 mutual authentication 140 resistance to dictionary attacks 141 adequate key generation 143 By wrapping the EAP protocol within TLS, Protected EAP (PEAP) Version 144 2 addresses these deficiencies in EAP or EAP methods. TLS provides 145 per-packet encryption, authentication, integrity and replay 146 protection of the EAP conversation. Benefits of PEAP Version 2 147 include: 149 Identity protection 150 By encrypting the identity exchange, and allowing client 151 certificates to be provided after negotiation of the TLS channel, 152 PEAPv2 provides for identity protection. 154 Dictionary attack resistance 155 By conducting the EAP conversation within a TLS channel, PEAPv2 156 protects EAP methods that might be subject to an offline dictionary 157 attack were they to be conducted in the clear. 159 Protected negotiation 160 Since within PEAPv2, the EAP conversation is authenticated, 161 integrity and replay protected on a per-packet basis, the EAP 162 method negotiation that occurs within PEAPv2 is protected, as are 163 error messages sent within the TLS channel (TLS alerts or EAP 164 Notification packets). EAP negotiation outside of PEAPv2 is not 165 protected. 167 Header protection 168 Within PEAPv2, the EAP conversation is conducted within a TLS 169 channel. As a result, the Type-Data field within PEAPv2 (including 170 the EAP header of the EAP method within PEAPv2) is protected 171 against modification. However, the EAP header of PEAPv2 itself is 172 not protected against modification, including the Code, Identifier 173 and Type fields. 175 Protected termination 176 By sending success/failure indications within the TLS channel, 177 PEAPv2 provides support for protected termination of the EAP 178 conversation. This prevents an attacker from carrying out denial 179 of service attacks by spoofing EAP Failure messages, or fooling the 180 EAP peer into accepting a rogue NAS, by spoofing EAP Success 181 messages. 183 Fragmentation and Reassembly 184 Since EAP does not include support for fragmentation and 185 reassembly, individual methods need to include this capability. By 186 including support for fragmentation and reassembly within PEAPv2, 187 methods leveraging PEAPv2 do not need to support this on their own. 189 Fast reconnect 190 Where EAP is used for authentication in wireless networks, the 191 authentication latency is a concern. As a result, it is valuable 192 to be able to do a quick re-authentication on roaming between 193 access points. PEAPv2 supports this capability by leveraging the 194 TLS session resumption facility, and any EAP method running under 195 PEAPv2 can take advantage of it. 197 Standard key establishment 198 In order to provide keying material for a wide range of link layer 199 ciphersuites, EAP methods need to provide keying material. Key 200 derivation is complex. PEAPv2 provides for key establishment by 201 relying on the widely implemented and well-reviewed TLS [RFC2246] 202 key derivation mechanism. PEAPv2 provides keying material for any 203 EAP method running within it. If EAP methods will also be deployed 204 without external protection (e.g PEAPv2 or IPSec), then the EAP 205 methods should follow the guidelines in section 6.8 to prevent the 206 man-in-the-middle attacks. 208 Sequencing of multiple EAP methods 209 In order to enhance security, PEAPv2 implementations may choose to 210 provide multi-factor authentication that validates different 211 identities (for example user and machine identities) and/or uses 212 different credentials of the same or different identities of the 213 peer (e.g. user password and machine cert). PEAPv2 provides a 214 standard way to chain different types of authentication mechanisms 215 supporting different types of credentials. 217 Protected exchange of arbitrary parameters (TLVs) 218 Type-Length-Value (TLV) tuples provide a way to exchange arbitrary 219 information between peer and EAP server within a secure channel. 220 This information can include signaling parameters for EAP protocol, 221 provisioning parameters, media specific and environment specific 222 data, and authorization parameters. The advantage of using PEAP 223 TLVs is that every EAP method does not have to be modified. 225 1.1. Requirements language 227 In this document, the key words "MAY", "MUST, "MUST NOT", 228 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 229 interpreted as described in [RFC2119]. 231 1.2. Terminology 233 This document frequently uses the following terms: 235 Access Point 236 A Network Access Server implementing 802.11. 238 Authenticator 239 The end of the link initiating EAP authentication. This term is 240 also used in [IEEE8021X] and has the same meaning in this document. 242 Backend Authentication Server 243 A backend authentication server is an entity that provides an 244 authentication service to an Authenticator. When used, this server 245 typically executes EAP methods for the Authenticator. This 246 terminology is also used in [IEEE8021X]. 248 EAP server 249 The entity that terminates the EAP authentication method with the 250 peer. In the case where no backend authentication server is used, 251 the EAP server is part of the Authenticator. In the case where the 252 authenticator operates in pass-through mode, the EAP server is 253 located on the backend authentication server. 255 Link layer ciphersuite 256 The ciphersuite negotiated for use at the link layer. 258 NAS Short for "Network Access Server". 260 Peer The end of the link that responds to the authenticator. In 261 [IEEE8021X], this end is known as the Supplicant. 263 TLS Ciphersuite 264 The ciphersuite negotiated for protection of the PEAPv2 Part 2 265 conversation. 267 EAP Master key (MK) 268 A key derived between the PEAPv2 client and server during the 269 authentication conversation, and that is kept local to PEAPv2 and 270 not exported or made available to a third party. 272 Master Session Key (MSK) 273 Keying material (64 octets) that is derived between the PEAPv2 274 client and server and exported by the PEAPv2 implementation. 276 AAA-Key 277 Where a backend authentication server is present, acting as an EAP 278 server, keying material known as the AAA-Key is transported from 279 the authentication server to the authenticator. The AAA-Key is 280 used by the EAP peer and authenticator in the derivation of 281 Transient Session Keys (TSKs) for the ciphersuite negotiated 282 between the EAP peer and authenticator. As a result, the AAA-Key 283 is typically known by all parties in the EAP exchange: the peer, 284 authenticator and the authentication server (if present). 286 Extended Master Session Key (EMSK) 287 Additional keying material (64 octets) derived between the EAP 288 client and server that is exported by the EAP method. The EMSK is 289 known only to the EAP peer and server and is not provided to a 290 third party. 292 Initialization Vector (IV) 293 A 64 octet quantity, suitable for use in an initialization vector 294 field, that is derived between the EAP client and server. Since 295 the IV is a known value in PEAPv2, it cannot be used by itself for 296 computation of any quantity that needs to remain secret. As a 297 result, PEAPv2 implementations are not required to generate it. 299 Pairwise Master Key (PMK) 300 The AAA-Key is divided into two halves, the "Peer to Authenticator 301 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 302 Encryption Key" (Enc-SEND-Key) (reception is defined from the point 303 of view of the authenticator). Within [IEEE80211i] Octets 0-31 of 304 the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key 305 (PMK). 307 Transient EAP Keys (TEKs) 308 Session keys which are used to establish a protected channel 309 between the EAP peer and server during the EAP authentication 310 exchange. The TEKs are appropriate for use with the ciphersuite 311 negotiated between EAP peer and server for use in protecting the 312 EAP conversation. Note that the ciphersuite used to set up the 313 protected channel between the EAP peer and server during EAP 314 authentication is unrelated to the ciphersuite used to subsequently 315 protect data sent between the EAP peer and Authenticator. 317 TLV TLV standards for objects of format Type-Length-Value. The TLV 318 format is defined in Section 4 of this document. 320 1.3. Operational model 322 In EAP, the EAP server may be implemented either within a Network 323 Access Server (NAS) or on a backend authentication server. Where the 324 EAP server resides on a NAS, the NAS is required to implement the 325 desired EAP methods, and therefore needs to be upgraded to support 326 each new EAP method. 328 One of the goals of EAP is to enable development of new 329 authentication methods without requiring deployment of new code on 330 the Network Access Server (NAS). Where a backend authentication 331 server is deployed, the NAS acts as a "passthrough" and need not 332 understand specific EAP methods. 334 This allows new EAP methods to be deployed on the EAP peer and 335 backend authentication server, without the need to upgrade code 336 residing on the NAS. 338 Figure 1 describes the relationship between the EAP peer, NAS and EAP 339 server. As described in the figure, the EAP conversation occurs 340 between the EAP peer and EAP server, "passing through" the NAS. In 341 order for the conversation to proceed in the case where the NAS and 342 EAP server reside on separate machines, the NAS and EAP server need 343 to establish trust beforehand. 345 +-+-+-+-+-+ +-+-+-+-+-+ 346 | | | | 347 | Link | | Link | 348 | Layer | | Layer | 349 | Cipher- | | Cipher- | 350 | Suite | | Suite | 351 | | | | 352 +-+-+-+-+-+ +-+-+-+-+-+ 353 ^ ^ 354 | | 355 | | 356 | | 357 V V 358 +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ 359 | | EAP | |<======>| | 360 | | Conversation | | | | 361 | EAP |<================================>| EAP | 362 | Peer | (over PPP, | NAS | | Server | 363 | | 802.11,etc.) | |<=======| | 364 | | | | Keys | | 365 | | | | | | 366 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 367 ^ ^ 368 | | 369 | EAP API | EAP API 370 | | 371 V V 372 +-+-+-+-+-+ +-+-+-+-+-+ 373 | | | | 374 | | | | 375 | EAP | | EAP | 376 | Method | | Method | 377 | | | | 378 +-+-+-+-+-+ +-+-+-+-+-+ 380 Figure 1 - Relationship between EAP client, backend authentication 381 server and NAS. 383 In PEAPv2, the conversation between the EAP peer and the EAP server 384 is encrypted, authenticated, integrity and replay protected within a 385 TLS channel. 387 As a result, where the NAS acts as a "passthrough" it does not have 388 knowledge of the TLS master secret derived between the peer and the 389 EAP server. In order to provide keying material for link-layer 390 ciphersuites, the NAS obtains the master session key, which is 391 derived from a one-way function of the TLS master secret as well as 392 keying material provided by EAP methods protected within a TLS 393 channel. This enables the NAS and EAP peer to subsequently derive 394 transient session keys suitable for encrypting, authenticating and 395 integrity protecting session data. However, the NAS cannot decrypt 396 the PEAPv2 conversation or spoof session resumption, since this 397 requires knowledge of the TLS master secret. 399 1.3.1. Sequences 401 EAP [RFC2284bis] prohibits use of multiple authentication methods 402 within a single EAP conversation, except when tunneled methods such 403 as PEAPv2 are used. This restriction was imposed in order to limit 404 vulnerabilities to man-in-the-middle attacks as well as to ensure 405 compatibility with existing EAP implementations. 407 Within PEAP these concerns are addressed since PEAPv2 includes 408 support for cryptographic binding to address man-in-the-middle 409 attacks, as well as version negotiation so as to enable backward 410 compatibility with prior versions of PEAP. 412 Within this document, the term "sequence" refers to a series of EAP 413 authentication methods run in sequence. The methods need not be 414 distinct - for example, EAP-TLS could be run initially with machine 415 credentials followed by the same protocol authenticating with user 416 credentials. 418 PEAPv2 supports two types of sequences: 420 [1] Serial authentication. Initiating additional EAP method(s) after a 421 first successful authentication. In this case the sequence is 422 successful if each of the EAP authentication methods completes 423 successfully. For example, successful authentication might require 424 a successful machine authentication followed by a successful user 425 authentication. 427 [2] Parallel authentication. Initiating an alternative EAP method after 428 failure of one or more initial methods. In this case the overall 429 authentication is successful if any of the methods is successful. 430 For example, if machine authentication fails, then user 431 authentication can be attempted. 433 2. Protocol overview 435 Protected EAP (PEAP) Version 2 is comprised of a two-part 436 conversation: 438 [1] In Part 1, a TLS session is negotiated, with server authenticating 439 to the client and optionally the client to the server. The 440 negotiated key is then used to encrypt the rest of the 441 conversation. 443 [2] In Part 2, within the TLS session, zero or more EAP methods are 444 carried out. Part 2 completes with a success/failure indication 445 protected by the TLS session or a protected error (TLS alert). 447 In the next two sections, we provide an overview of each of the parts 448 of the PEAPv2 conversation. 450 2.1. PEAPv2 Part 1 452 2.1.1. Initial identity exchange 454 The PEAP conversation typically begins with an optional identity 455 exchange. The authenticator will typically send an EAP- 456 Request/Identity packet to the peer, and the peer will respond with 457 an EAP-Response/Identity packet to the authenticator. 459 The initial identity exchange is used primarily to route the EAP 460 conversation to the EAP server. Since the initial identity exchange 461 is in the clear, the peer MAY decide to place a routing realm instead 462 of its real name in the EAP-Response/Identity. The real identity of 463 the peer can be established later in PEAPv2 part 2. 465 If the EAP server is known in advance (such as when all users 466 authenticate against the same backend server infrastructure and 467 roaming is not supported), or if the identity is otherwise determined 468 (such as from the dialing phone number or client MAC address), then 469 the EAP-Request/Response-identity exchange MAY be omitted. 471 Once the optional initial Identity Request/Response exchange is 472 completed, while nominally the EAP conversation occurs between the 473 authenticator and the peer, the authenticator MAY act as a 474 passthrough device, with the EAP packets received from the peer being 475 encapsulated for transmission to a backend authentication server. 476 However, PEAP does not require a backend authentication server; if 477 the authenticator implements PEAP, then it can authenticate local 478 users. 480 In the discussion that follows, we will use the term "EAP server" to 481 denote the ultimate endpoint conversing with the peer. 483 2.1.2. TLS Session Establishment 485 In this section, the protocol is described assuming a certificate 486 based ciphersuite is negotiated in TLS. The conversation may 487 slightly differ if other TLS ciphersuites are used. 489 Once having received the peer's Identity, and determined that PEAP 490 authentication is to occur, the EAP server MUST respond with a 491 PEAP/Start packet, which is an EAP-Request packet with EAP-Type=PEAP, 492 the Start (S) bit set, the PEAP version as specified in Section 493 2.1.5, and no data. Assuming that the peer supports PEAP, the PEAP 494 conversation will then begin, with the peer sending an EAP-Response 495 packet with EAP-Type=PEAP. 497 The data field of the EAP-Response packet will encapsulate one or 498 more TLS records in TLS record layer format, containing a TLS 499 client_hello handshake message. The current cipher spec for the TLS 500 records will be TLS_NULL_WITH_NULL_NULL and null compression. This 501 current cipher spec remains the same until the change_cipher_spec 502 message signals that subsequent records will have the negotiated 503 attributes for the remainder of the handshake. 505 The client_hello message contains the client's TLS version number, a 506 sessionId, a random number, and a set of TLS ciphersuites supported 507 by the client. The version offered by the client MUST correspond to 508 TLS v1.0 or later. 510 The EAP server will then respond with an EAP-Request packet with EAP- 511 Type=PEAP. The data field of this packet will encapsulate one or 512 more TLS records. These will contain a TLS server_hello handshake 513 message, possibly followed by TLS certificate, server_key_exchange, 514 certificate_request, server_hello_done and/or finished handshake 515 messages, and/or a TLS change_cipher_spec message. 517 Since after the TLS session is established, another complete EAP 518 negotiation will occur and the peer will authenticate using a 519 secondary mechanism, with PEAPv2 the client need not authenticate as 520 part of TLS session establishment. As a result, although the EAP- 521 Request packet sent by the EAP Server MAY contain a 522 certificate_request message, this is not required. 524 The certificate_request message indicates that the server desires the 525 client to authenticate itself via public key. It is valid for the 526 server to request a certificate in the server_hello and for the 527 client refuse to provide one. 529 Note that since TLS client certificates are sent in the clear, if 530 identity protection is required, then it is possible for the TLS 531 authentication to be re-negotiated after the first server 532 authentication. To accomplish this, the server will typically not 533 request a certificate in the server_hello, then after the 534 server_finished message is sent, and before PEAP part 2, the server 535 MAY send a TLS hello_request. This allows the client to perform 536 client authentication by sending a client_hello if it wants to, or 537 send a no_renegotiation alert to the server indicating that it wants 538 to continue with PEAP part 2 instead. Assuming that the client 539 permits renegotiation by sending a client_hello, then the server will 540 respond with server_hello, a certificate and certificate_request 541 messages. The client replies with certificate, client_key_exchange 542 and certificate_verify messages. Since this re-negotiation occurs 543 within the encrypted TLS channel, it does not reveal client 544 certificate details. 546 The server_hello handshake message contains a TLS version number, 547 another random number, a sessionId, and a TLS ciphersuite. The 548 version offered by the server MUST correspond to TLS v1.0 or later. 550 If the client's sessionId is null or unrecognized by the server, the 551 server MUST choose the sessionId to establish a new session; 552 otherwise, the sessionId will match that offered by the client, 553 indicating a resumption of the previously established session with 554 that sessionId. The server will also choose a TLS ciphersuite from 555 those offered by the client; if the session matches the client's, 556 then the TLS ciphersuite MUST match the one negotiated during the 557 handshake protocol execution that established the session. 559 PEAP implementations need not necessarily support all TLS 560 ciphersuites listed in [RFC2246]. Not all TLS ciphersuites are 561 supported by available TLS tool kits and licenses may be required to 562 support some TLS ciphersuites (e.g. TLS ciphersuites utilizing the 563 IDEA encryption algorithm). 565 To ensure interoperability, PEAP peers and EAP servers MUST support 566 and be able to negotiate the following TLS ciphersuites: 568 TLS_RSA_WITH_3DES_EDE_CBC_SHA 570 In addition, PEAP peers and EAP servers SHOULD support and be able to 571 negotiate the following TLS ciphersuites. 573 TLS_RSA_WITH_AES_128_CBC_SHA 574 TLS_RSA_WITH_RC4_128_MD5 575 TLS_RSA_WITH_RC4_128_SHA 577 TLS as described in [RFC2246] supports compression as well as 578 ciphersuite negotiation. Therefore during the PEAPv2 Part 1 579 conversation the EAP endpoints MAY request or negotiate TLS 580 compression. 582 2.1.3. Full handshake 584 If the EAP server is not resuming a previously established session, 585 and if a ciphersuite based on certificates is used, then it MUST 586 include a TLS server_certificate handshake message, and a 587 server_hello_done handshake message MUST be the last handshake 588 message encapsulated in this EAP-Request packet. 590 The certificate message contains a public key certificate chain for 591 either a key exchange public key (such as an RSA or Diffie-Hellman 592 key exchange public key) or a signature public key (such as an RSA or 593 DSS signature public key). In the latter case, a TLS 594 server_key_exchange handshake message MUST also be included to allow 595 the key exchange to take place. 597 If the preceding server_hello message sent by the EAP server in the 598 preceding EAP-Request packet did not indicate the resumption of a 599 previous session, then the peer MUST respond to the EAP-Request with 600 an EAP-Response packet of EAP-Type=PEAP. The data field of this 601 packet will encapsulate one or more TLS records containing a TLS 602 change_cipher_spec message and finished handshake message, and 603 possibly certificate, certificate_verify and/or client_key_exchange 604 handshake messages. 606 The EAP server MUST then respond with an EAP-Request packet with EAP- 607 Type=PEAP, which includes, in the case of a new TLS session, one or 608 more TLS records containing TLS change_cipher_spec, finished 609 handshake messages; and the first payload of PEAPv2 part 2. The 610 first payload of PEAPv2 part 2 is sent along with finished handshake 611 message to reduce number of round trips. 613 2.1.4. Session resumption 615 The purpose of the sessionId within the TLS protocol is to allow for 616 improved efficiency in the case where a client repeatedly attempts to 617 authenticate to an EAP server within a short period of time. This 618 capability is particularly useful for support of wireless roaming. 620 It is left up to the peer whether to attempt to continue a previous 621 session, thus shortening the PEAP Part 1 conversation. Typically the 622 peer's decision will be made based on the time elapsed since the 623 previous authentication attempt to that EAP server. 625 Based on the sessionId chosen by the peer, and the time elapsed since 626 the previous authentication, the EAP server will decide whether to 627 allow the continuation, or whether to choose a new session. 629 In the case where the EAP server and the authenticator reside on the 630 same device, then the client will only be able to continue sessions 631 when connecting to the same NAS or channel server. Should these 632 devices be set up in a rotary or round-robin then it may not be 633 possible for the peer to know in advance the authenticator it will be 634 connecting to, and therefore which sessionId to attempt to reuse. As 635 a result, it is likely that the continuation attempt will fail. 637 In the case where the EAP authentication is remoted then continuation 638 is much more likely to be successful, since multiple NAS devices and 639 channel servers will remote their EAP authentications to the same 640 backend authentication server. 642 If the EAP server is resuming a previously established session, then 643 it MUST include only a TLS change_cipher_spec message and a TLS 644 finished handshake message after the server_hello message. The 645 finished message contains the EAP server's authentication response to 646 the peer. 648 If the preceding server_hello message sent by the EAP server in the 649 preceding EAP-Request packet indicated the resumption of a previous 650 session, then the peer MUST send only the change_cipher_spec and 651 finished handshake messages. The finished message contains the 652 peer's authentication response to the EAP server. The latter contains 653 the EAP server's authentication response to the peer. The peer will 654 verify the hash in order to authenticate the EAP server. 656 If authentication fails, then the peer and EAP-server MUST follow the 657 error handling behavior specified in section 2.3. 659 Even if the session is successfully resumed with the same EAP server, 660 the peer and EAP server MUST not assume that either will skip inner 661 EAP methods. The peer may have roamed to a network which may use the 662 same EAP server, but may require conformance with a different 663 authentication policy. 665 2.1.5. Version negotiation 667 PEAP packets contain a three bit version field, which enables PEAP 668 implementations to be backward compatible with previous versions of 669 the protocol. This specification documents the PEAP version 2 670 protocol; implementations of this specification MUST use a version 671 field set to 2. Version negotiation proceeds as follows: 673 [1] In the first EAP-Request sent with EAP type=PEAP, the EAP server 674 MUST set the version field to the highest supported version number. 676 [2] If the EAP peer supports this version of the protocol, it MUST 677 respond with an EAP-Response of EAP type=PEAP, and the version 678 number proposed by the EAP server. 680 [3] If the EAP peer does not support this version, it responds with an 681 EAP-Response of EAP type=PEAP and the highest supported version 682 number. 684 [4] If the PEAP server does not support the version number proposed by 685 the PEAP peer, it terminates the conversation, as described in 686 Section 2.2.2. 688 The version negotiation procedure guarantees that the EAP peer and 689 server will agree to the latest version supported by both parties. 690 If version negotiation fails, then use of PEAP will not be possible, 691 and another mutually acceptable EAP method will need to be negotiated 692 if authentication is to proceed. 694 The PEAP version field is not protected by TLS and therefore can be 695 modified in transit. In order to detect modification of the PEAP 696 version which could occur as part of a "downgrade" attack, the 697 PEAPv2 peer and server MUST exchange information on the highest 698 supported versions proposed by the peers using the crypto-binding- 699 TLV. 701 2.2. PEAPv2 Part 2 703 The second portion of the PEAPv2 conversation typically consists of a 704 complete EAP conversation occurring within the TLS session negotiated 705 in PEAPv2 Part 1; ending with protected termination using the Result- 706 TLV. PEAPv2 part 2 will occur only if establishment of a new TLS 707 session in Part 1 is successful or a TLS session is successfully 708 resumed in Part 1. In cases where a new TLS session is established 709 in PEAPv2 part 1, the first payload of the part 2 conversation is 710 sent by the EAP server along with the finished message to save a 711 round-trip. 713 Part 2 MUST NOT occur if the EAP Server authenticates unsuccessfully 714 or if an EAP-Failure has been sent by the EAP server to the peer, 715 terminating the conversation. Since all packets sent within the 716 PEAPv2 Part 2 conversation occur after TLS session establishment, 717 they are protected using the negotiated TLS ciphersuite. All EAP 718 packets of the EAP conversation in part 2 including the EAP header of 719 the inner EAP method are protected using the negotiated TLS 720 ciphersuite. 722 Part 2 MAY NOT always include a EAP conversation within the TLS 723 session, referred to in this document as inner EAP methods. However, 724 Part 2 MUST always end with either protected termination or protected 725 error termination. 727 Within Part 2, protected EAP conversation and protected termination 728 packets are always carried within an EAP-TLV packet. The EAP-TLV 729 packet does not include an EAP header. There are TLVs defined for 730 specific purposes such as carrying EAP-authentication messages and 731 carrying cryptographic binding. New TLVs may be developed for other 732 purposes. 734 2.2.1. Protected conversation 736 Part 2 of the PEAP conversation typically begins with the EAP server 737 sending an optional EAP-Request/Identity packet to the peer, 738 protected by the TLS ciphersuite negotiated in PEAP Part 1. The peer 739 responds with an EAP-Response/Identity packet to the EAP server, 740 containing the peer's userId. Since this Identity Request/Response 741 exchange is protected by the ciphersuite negotiated in TLS, it is not 742 vulnerable to snooping or packet modification attacks. 744 After the TLS session-protected Identity exchange, the EAP server 745 will then select authentication method(s) for the peer, and will send 746 an EAP-Request with the Type field set to the initial method. As 747 described in [RFC2284BIS], the peer can NAK the suggested EAP method, 748 suggesting an alternative. Since the NAK will be sent within the TLS 749 channel, it is protected from snooping or packet modification. As a 750 result, an attacker snooping on the exchange will be unable to inject 751 NAKs in order to "negotiate down" the authentication method. An 752 attacker will also not be able to determine which EAP method was 753 negotiated. 755 The EAP conversation within the TLS protected session may involve a 756 sequence of zero or more EAP authentication methods; it completes 757 with the protected termination described in section 2.2.2. Several 758 EAP-TLVs may be included in each Request and Response. EAP-methods 759 (except if the type is EAP-TLV) are always encapsulated within EAP 760 Payload-TLV. 762 In a typical EAP conversation, the result of the conversation is 763 communicated by sending EAP Success or EAP Failure packets after the 764 EAP method is complete. The EAP Success or Failure packet is 765 considered the last packet of the EAP conversation; and therefore 766 cannot be used when sequences need to be supported. Hence, instead 767 of using the EAP-success or EAP-failure packet, both peer and EAP 768 server MUST use the Intermediate Result TLV to communicate the 769 result. 771 In a typical EAP conversation, the EAP Success or EAP Failure is 772 considered the last packet of the EAP conversation. Within PEAP, the 773 EAP server can start another EAP method after success or failure of 774 the previous EAP method inside the protected session. 776 In a sequence of more than one EAP authentication method, to make 777 sure the same parties are involved in tunnel establishment and 778 successful completion of previous inner EAP methods, before 779 completing negotiation of the next EAP method, both peer and EAP 780 server MUST use crypto binding (Crypto-Binding TLV). If no EAP 781 methods have been negotiated inside the tunnel or no EAP methods have 782 been successfully completed inside the tunnel, the crypto-binding TLV 783 MUST NOT be used. 785 The Crypto-Binding TLV and the Intermediate-Result TLV MUST be sent 786 after each successful EAP method (except for type EAP-TLV). If these 787 TLVs are not sent, it should be considered as tunnel compromise error 788 by peer and EAP server. 790 Both TLVs can be sent in an EAP-TLV packet. Alternatively, if a 791 subsequent EAP conversation is being attempted, then in order to 792 reduce round trips, both TLVs SHOULD be sent in the EAP-Payload of 793 the first EAP packet of the next EAP conversation (for example, EAP- 794 Identity or EAP-packet of the EAP method). Alternatively, if the 795 next packet is the PEAP termination packet, then in order to reduce 796 round trips, both TLVs SHOULD be sent with the termination packet. 798 If the EAP server sends a valid Crypto-Binding-TLV to the peer, the 799 peer MUST respond with a Crypto-Binding TLV. If the Crypto-Binding- 800 TLV is invalid, it should be considered a tunnel compromise error by 801 the peer. If the peer does not respond with a EAP-TLV packet 802 containing the crypto-binding TLV, it should be considered a tunnel 803 compromise error by the EAP server. 805 2.2.2. Protected Termination 807 The PEAPv2 part 2 conversation is completed by an exchange of 808 success/failure indications (Result-TLV) within a EAP-TLV packet 809 protected by the TLS session. 811 If the Crypto-Binding TLV and the Intermediate-Result TLV have NOT 812 been exchanged in the previous conversation, then they MUST be 813 present in the protected indication packet. Otherwise, it should be 814 considered a tunnel compromise error by the peer and EAP server. 816 The Result TLV is sent within the TLS channel. The PEAP client then 817 replies with a Result-TLV. The conversation concludes with the PEAP 818 server sending a cleartext success/failure indication. 820 The only outcome which should be considered as successful 821 authentication is when an EAP Request of Type=EAP-TLVs with Result 822 TLV of Status=Success, is answered by an EAP Response of Type=EAP- 823 TLVs with Result TLV of Status=Success. 825 All other combinations (EAP-TLVs Failure, EAP-TLVs Success), (EAP- 826 TLVs Failure, EAP-TLVs Failure), (no EAP-TLVs exchange or no 827 protected EAP Success or Failure) should be considered failed 828 authentications, both by the PEAP peer and EAP server. Once the 829 PEAPv2 peer and PEAPv2 server considers them as failed 830 authentications, they are the last packets inside the protected 831 tunnel. These are considered failed authentications regardless of 832 whether a cleartext EAP Success or EAP Failure packet is subsequently 833 sent. 835 After the PEAPv2 server has sent the success indication, the peer is 836 allowed to refuse to accept a Success message from the PEAPv2 server 837 since the client's policy may require completion of certain EAP 838 methods. If the peer wants the server to negotiate EAP methods, it 839 MUST send the EAP-TLV packet with Result-TLV with Status=Failure. If 840 the success indication from the EAP server contains the crypto- 841 binding TLV, then the peer MUST include a crypto-binding TLV in the 842 EAP-TLV response. If the peer does not respond with a EAP-TLV packet 843 containing the crypto-binding TLV or if the crypto-binding TLV is 844 invalid, it should be considered as a tunnel compromise error by the 845 EAP server. 847 If the EAP server has set Result-TLV with Status=Success; and the 848 response from the peer is Status=Failure, then the EAP server MUST 849 either start another EAP conversation inside the protected channel or 850 return Result=TLV with Status=Failure without a crypto-binding TLV 851 and Intermediate Result TLV. 853 A PEAPv2 tunnel may be nested inside another tunnel, for example, 854 PEAPv2 may be negotiated as a EAP method inside a PEAPv2 tunnel. In 855 this case, each tunnel MUST use protected termination. 857 2.3. Error handling 859 Once the peer responds with the first PEAP packet and the EAP server 860 receives the first PEAP packet from the peer, both MUST silently 861 discard all clear text EAP messages unless both the PEAP peer and 862 server have indicated success or failure or an error using a 863 protected error or protected termination mechanism. If the PEAPv2 864 tunnel is nested inside another tunnel, then the clear text EAP 865 messages should be accepted after protected termination of all the 866 tunnels. After a Fatal alert is received or after protected 867 termination is complete, the peer or EAP server should accept clear 868 text EAP messages. 870 Other than supporting TLS alert messages, PEAPv2 does not have its 871 own error message capabilities. This is unnecessary since errors in 872 the PEAPv2 Part 1 conversation are communicated via TLS alert 873 messages, and errors in the PEAPv2 Part 2 conversation are expected 874 to be handled by individual EAP methods. 876 If an error occurs at any point in the TLS layer, the EAP server 877 SHOULD send a TLS alert message instead of the next EAP-request 878 packet to the peer. The EAP server SHOULD send an EAP-Request packet 879 with EAP-Type=PEAP, encapsulating a TLS record containing the 880 appropriate TLS alert message. The EAP server SHOULD send a TLS 881 alert message rather than immediately terminating the conversation so 882 as to allow the peer to inform the user of the cause of the failure 883 and possibly allow for a restart of the conversation. To ensure that 884 the peer receives the TLS alert message, the EAP server MUST wait for 885 the peer to reply with an EAP-Response packet. 887 The EAP-Response packet sent by the peer MAY encapsulate a TLS 888 client_hello handshake message, in which case the EAP server MAY 889 allow the PEAPv2 conversation to be restarted, or it MAY contain an 890 EAP-Response packet with EAP-Type=PEAP and no data, in which case the 891 PEAPv2 server MUST send an EAP-Failure packet, and terminate the 892 conversation. 894 It is up to the EAP server whether to allow restarts, and if so, how 895 many times the conversation can be restarted. An EAP server 896 implementing restart capability SHOULD impose a limit on the number 897 of restarts, so as to protect against denial of service attacks. 899 If an error occurs at any point in the TLS layer, the peer SHOULD 900 send a TLS alert message instead of the next EAP-response packet to 901 the EAP server. The peer SHOULD send an EAP-Response packet with 902 EAP-Type=PEAP, encapsulating a TLS record containing the appropriate 903 TLS alert message. The EAP server may restart the conversation by 904 sending a EAP-Request packet encapsulating the TLS 905 hello_request_handshake message, in which case the peer MAY allow the 906 PEAPv2 conversation to be restarted; or the EAP server can response 907 with EAP Failure. 909 Any time the peer or the EAP server finds an error when processing 910 the sequence of exchanges, such a violation of TLV rules, it should 911 send a Result TLV of failure and terminate the tunnel. This is 912 usually due to an implementation problem and is considered an fatal 913 error. 915 If a tunnel compromise error (see Section 2.2) is detected by the 916 peer, the peer SHOULD send a TLS Internal Error alert (a Fatal error) 917 message instead of the next EAP-response packet to the EAP server. 918 Similarly, if a tunnel compromise error is detected by the EAP 919 server, the EAP server SHOULD send a TLS Internal error alert (a 920 Fatal error) message instead of the next EAP-response packet to the 921 peer. 923 2.4. Fragmentation 925 A single TLS record may be up to 16384 octets in length, but a TLS 926 message may span multiple TLS records, and a TLS certificate message 927 may in principle be as long as 16MB. The group of PEAP messages sent 928 in a single round may thus be larger than the PPP MTU size, the 929 maximum RADIUS packet size of 4096 octets, or even the Multilink 930 Maximum Received Reconstructed Unit (MRRU). As described in 931 [RFC1990], the multilink MRRU is negotiated via the Multilink MRRU 932 LCP option, which includes an MRRU length field of two octets, and 933 thus can support MRRUs as large as 64 KB. 935 However, note that in order to protect against reassembly lockup and 936 denial of service attacks, it may be desirable for an implementation 937 to set a maximum size for one such group of TLS messages. Since a 938 typical certificate chain is rarely longer than a few thousand 939 octets, and no other field is likely to be anywhere near as long, a 940 reasonable choice of maximum acceptable message length might be 64 941 KB. 943 If this value is chosen, then fragmentation can be handled via the 944 multilink PPP fragmentation mechanisms described in [RFC1990]. While 945 this is desirable, EAP methods are used in other applications such as 946 [IEEE80211] and there may be cases in which multilink or the MRRU LCP 947 option cannot be negotiated. As a result, a PEAPv2 implementation 948 MUST provide its own support for fragmentation and reassembly. 950 Since EAP is an ACK-NAK protocol, fragmentation support can be added 951 in a simple manner. In EAP, fragments that are lost or damaged in 952 transit will be retransmitted, and since sequencing information is 953 provided by the Identifier field in EAP, there is no need for a 954 fragment offset field as is provided in IPv4. 956 PEAPv2 fragmentation support is provided through addition of flag 957 bits within the EAP-Response and EAP-Request packets, as well as a 958 TLS Message Length field of four octets. Flags include the Length 959 included (L), More fragments (M), and PEAP Start (S) bits. The L 960 flag is set to indicate the presence of the four octet TLS Message 961 Length field, and MUST be set only for the first fragment of a 962 fragmented TLS message or set of messages. 964 The TLS Message Length field in the PEAPv2 header is not protected; 965 and hence can be modified by a attacker. The TLS record length in 966 the TLS data is protected. Hence, if TLS Message length received in 967 the first packet (with L bit set) is greater or less than the total 968 size of TLS data received including multiple fragments, then the TLS 969 message length should be ignored. 971 A single TLS record may be up to 16384 octets in length, but a TLS 972 message may span multiple TLS records, and a TLS certificate message 973 may in principle be as long as 16MB. However, note that in order to 974 protect against reassembly lockup and denial of service attacks, it 975 may be desirable for an implementation to set a maximum size for one 976 such group of TLS messages. Since a typical certificate chain is 977 rarely longer than a few thousand octets, and no other field is 978 likely to be anywhere near as long, a reasonable choice of maximum 979 acceptable message length might be 64 KB. 981 The M flag is set on all but the last fragment. The S flag is set 982 only within the PEAP start message sent from the EAP server to the 983 peer. The TLS Message Length field is four octets, and provides the 984 total length of the TLS message or set of messages that is being 985 fragmented; this simplifies buffer allocation. 987 When a PEAPv2 peer receives an EAP-Request packet with the M bit set, 988 it MUST respond with an EAP-Response with EAP-Type=PEAP and no data. 989 This serves as a fragment ACK. The EAP server MUST wait until it 990 receives the EAP-Response before sending another fragment. In order 991 to prevent errors in processing of fragments, the EAP server MUST 992 increment the Identifier field for each fragment contained within an 993 EAP-Request, and the peer MUST include this Identifier value in the 994 fragment ACK contained within the EAP-Response. Retransmitted 995 fragments will contain the same Identifier value. 997 Similarly, when the EAP server receives an EAP-Response with the M 998 bit set, it MUST respond with an EAP-Request with EAP-Type=PEAP and 999 no data. This serves as a fragment ACK. The EAP peer MUST wait until 1000 it receives the EAP-Request before sending another fragment. In 1001 order to prevent errors in the processing of fragments, the EAP 1002 server MUST increment the Identifier value for each fragment ACK 1003 contained within an EAP-Request, and the peer MUST include this 1004 Identifier value in the subsequent fragment contained within an EAP- 1005 Response. 1007 2.5. Key derivation 1009 Since the normal TLS keys are used in the handshake, and therefore 1010 should not be used in a different context, new keys must be derived 1011 from the TLS master secret for use with the selected link layer 1012 ciphersuites. 1014 Instead of deriving keys specific to link layer ciphersuites EAP 1015 methods provides a Master Session Key (MSK) used to derive keys in a 1016 link layer specific manner. The method used to extract ciphering 1017 keys from the MSK is beyond the scope of this document. 1019 PEAPv2 also derives an Extended Master Session Key (EMSK) which is 1020 reserved for use in deriving keys in other ciphering applications. 1021 This draft also does not discuss the format of the attributes used to 1022 communicate the master session keys from the backend authentication 1023 server to the NAS; examples of such attributes are provided in 1024 [RFC2548]. 1026 PEAPv2 combines key material from the TLS exchange with key material 1027 from inner key generating EAP methods to provide stronger keys and to 1028 bind inner authentication mechanisms to the TLS tunnel. Both the 1029 peer and EAP server MUST derive compound MAC and compound session 1030 keys using the procedure described below. 1032 The input for the cryptographic binding includes the following: 1034 [a] The PEAPv2 tunnel key (TK) is calculated using the first 64 octets 1035 of the (secret) key material generated as described in the EAP-TLS 1036 algorithm (RFC2716 section 3.5) 1038 [b] The MSK provided by each successful inner EAP method (should not 1039 include the 64 octets of EMSK); for each successful EAP method 1040 completed within the tunnel. 1042 ISK1..ISKn are the MSK portion of the EAP keying material obtained 1043 from methods 1 to n. In some cases (except in the case of the EAP- 1044 TLV method), where the inner EAP method does not provide keys: ISKi, 1045 for some i, may be the null string (""). 1047 The algorithm uses P_SHA-1 PRF specified in the TLS specification 1048 [RFC2246] ("|" denotes concatenation). 1050 The intermediate combined key is generated after each successful EAP 1051 method inside the tunnel. 1053 Generating the intermediate combined key: 1055 Take the second 32 octets of TK 1057 IPMK0 = TK 1059 for j = 1 to k do 1060 IPMKj = P_SHA1(IPMK(j-1),"Intermediate PEAP MAC key" | ISKj); 1062 k = the last successful EAP method inside the tunnel at the point 1063 where the combined MAC key is derived. 1065 Each IPMKj output is 32 octets. IPMKn is the intermediate combined 1066 key used to derive combined session and combined MAC keys. 1068 Compound MAC Key derivation: 1070 The Compound MAC Key for the server (the B1_MAC) is derived CMK_B1 1072 CMK_B1 = P_SHA1(IPMKn,"PEAP Server B1 MAC key" | S_NONCE) 1074 The Compound MAC Key for the client (the B2_MAC) is derived from MAC 1075 key called CMK B2. 1077 CMK_B2 = P_SHA1(IPMKn,"PEAP Client B2 MAC key" | C_NONCE | S_NONCE) 1079 The compound MAC keys (CMK_B1 and CMK_B2) are each 20 octets long. 1081 Compound Session Key derivation: 1083 The compound session key (CSK) is derived on both the peer and EAP 1084 server after successful completion of protected termination. 1086 CSK = P_SHA1 (IPMKn, "PEAP compound session key" | C_NONCE | S_NONCE 1087 | OutputLength) 1089 The output length of the CSK must be at least 128 bytes. The first 1090 64 octets are taken and the MSK and the second 64 octets are taken as 1091 the EMSK. The MSK and EMSK are described in [RFC2284bis]. 1093 2.6. Ciphersuite negotiation 1095 Since TLS supports TLS ciphersuite negotiation, peers completing the 1096 TLS negotiation will also have selected a TLS ciphersuite, which 1097 includes key strength, encryption and hashing methods. However, 1098 unlike in [RFC2716], within PEAPv2, the negotiated TLS ciphersuite 1099 relates only to the mechanism by which the PEAPv2 Part 2 conversation 1100 will be protected, and has no relationship to link layer security 1101 mechanisms negotiated within the PPP Encryption Control Protocol 1102 (ECP) [RFC1968] or within IEEE 802.11 [IEEE80211]. 1104 As a result, this specification currently does not support secure 1105 negotiation of link layer ciphersuites, although this capability may 1106 be added in future by addition of TLVs to the EAP TLV method defined 1107 in Section 4. 1109 3. Detailed description of the PEAPv2 protocol 1111 3.1. PEAPv2 Packet Format 1113 A summary of the PEAPv2 Request/Response packet format is shown 1114 below. The fields are transmitted from left to right. 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Code | Identifier | Length | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Type | Flags | Ver | Data... 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Code 1126 1 - Request 1127 2 - Response 1129 Identifier 1131 The Identifier field is one octet and aids in matching responses 1132 with requests. 1134 Length 1136 The Length field is two octets and indicates the length of the EAP 1137 packet including the Code, Identifier, Length, Type, and Data 1138 fields. Octets outside the range of the Length field should be 1139 treated as Data Link Layer padding and should be ignored on 1140 reception. 1142 Type 1144 25 - PEAP 1146 Flags 1148 0 1 2 3 4 1149 +-+-+-+-+-+ 1150 |L M S R R| 1151 +-+-+-+-+-+ 1153 L = Length included 1154 M = More fragments 1155 S = PEAP start 1156 R = Reserved (must be zero) 1157 The L bit (length included) is set to indicate the presence of the 1158 four octet TLS Message Length field, and MUST be set for the first 1159 fragment of a fragmented TLS message or set of messages. The L 1160 bit MUST NOT be set for other fragments of the same set of 1161 messages. The M bit(more fragments) is set on all but the last 1162 fragment. The S bit (PEAP start) is set in a PEAP Start message. 1163 This differentiates the PEAP Start message from a fragment 1164 acknowledgment. 1166 Version 1168 0 1 2 1169 +-+-+-+ 1170 |R|1|0| 1171 +-+-+-+ 1173 R = Reserved (must be zero) 1175 Data 1177 The format of the Data field is determined by the Code field. 1179 3.2. PEAPv2 Request Packet 1181 A summary of the PEAPv2 Request packet format is shown below. The 1182 fields are transmitted from left to right. 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Code | Identifier | Length | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Type | Flags | Ver | TLS Message Length 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | TLS Message Length | TLS Data... 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 Code 1196 1 1198 Identifier 1200 The Identifier field is one octet and aids in matching responses 1201 with requests. The Identifier field MUST be changed on each 1202 Request packet. 1204 Length 1205 The Length field is two octets and indicates the length of the EAP 1206 packet including the Code, Identifier, Length, Type, Flags, TLS 1207 message length and TLS data fields. 1209 Type 1211 25 - PEAP 1213 Flags 1215 0 1 2 3 4 1216 +-+-+-+-+-+ 1217 |L M S R R| 1218 +-+-+-+-+-+ 1220 L = Length included 1221 M = More fragments 1222 S = PEAP start 1223 R = Reserved (must be zero) 1225 The L bit (length included) is set to indicate the presence of the 1226 four octet TLS Message Length field, and MUST be set for the first 1227 fragment of a fragmented TLS message or set of messages. The M 1228 bit(more fragments) is set on all but the last fragment. The S 1229 bit (PEAP start) is set in a PEAP Start message. This 1230 differentiates the PEAP Start message from a fragment 1231 acknowledgment. 1233 Version 1235 0 1 2 1236 +-+-+-+ 1237 |R|1|0| 1238 +-+-+-+ 1240 R = Reserved (must be zero) 1242 TLS Message Length 1244 The TLS Message Length field is four octets, and is present only 1245 if the L bit is set. This field provides the total length of the 1246 TLS message or set of messages that is being fragmented. 1248 TLS data 1250 The TLS data consists of the encapsulated packet in TLS record 1251 format. 1253 3.3. PEAPv2 Response Packet 1255 A summary of the PEAPv2 Response packet format is shown below. The 1256 fields are transmitted from left to right. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Code | Identifier | Length | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Type | Flags |Ver| TLS Message Length 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | TLS Message Length | TLS Data... 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 Code 1270 2 1272 Identifier 1274 The Identifier field is one octet and MUST match the Identifier 1275 field from the corresponding request. 1277 Length 1279 The Length field is two octets and indicates the length of the EAP 1280 packet including the Code, Identifier, Length, Type, Flags, Ver, 1281 TLS message length, and TLS data fields. 1283 Type 1285 25 - PEAP 1287 Flags 1289 0 1 2 3 4 1290 +-+-+-+-+-+ 1291 |L M S R R| 1292 +-+-+-+-+-+ 1294 L = Length included 1295 M = More fragments 1296 S = PEAP start 1297 R = Reserved (must be zero) 1299 The L bit (length included) is set to indicate the presence of the 1300 four octet TLS Message Length field, and MUST be set for the first 1301 fragment of a fragmented TLS message or set of messages. The M 1302 bit (more fragments) is set on all but the last fragment. The S 1303 bit (PEAP start) is set in a PEAP Start message. This 1304 differentiates the PEAP Start message from a fragment 1305 acknowledgment. 1307 Version 1309 0 1 2 1310 +-+-+-+ 1311 |R|1|0| 1312 +-+-+-+ 1314 R = Reserved (must be zero) 1316 TLS Message Length 1318 The TLS Message Length field is four octets, and is present only 1319 if the L bit is set. This field provides the total length of the 1320 TLS message or set of messages that is being fragmented. 1322 TLS data 1324 The TLS data consists of the encapsulated TLS packet in TLS record 1325 format. 1327 3.4. PEAPv2 Part 2 Packet Format 1329 The PEAPv2 Part 2 packet format is the same as the PEAPv2 Request and 1330 Response packet formats described in Sections 3.1 and 3.2, except 1331 that the TLS Data field encapsulates TLS packets in TLS record 1332 format, representing encrypted EAP-TLVs. 1334 Although the EAP-TLV method has been allocated an EAP Type, use of 1335 this method is prohibited outside of a tunnel by [RFC2284bis]. Since 1336 EAP-TLVs are self-describing, when transmitted within PEAPv2, the EAP 1337 header portion of the EAP-TLV packet is absent (including the Code, 1338 Identifier, Length and Type fields), leaving only a list of TLVs as 1339 the payload. 1341 Within PEAPv2, all inner EAP method packets are encapsulated in EAP- 1342 TLV format. The EAP-Payload is an (optional) TLV which encapsulates 1343 EAP packets (including all EAP header fields) and in addition carries 1344 TLVs associated with them. 1346 PEAP Part 2 packet format = EAP-TLV [EAP-Payload TLV [[EAP packet], 1347 TLVs, ...], TLVs, ...] OR TLS Alert 1348 The EAP-TLV packet is included without the EAP header fields (Code, 1349 Identifier, Length, Type) 1351 4. EAP-TLV method 1353 The EAP-TLV method is a payload with standard Type-Length-Value (TLV) 1354 objects. The TLV objects could be used to carry arbitrary parameters 1355 between EAP peer and EAP server. Possible uses for TLV objects 1356 include: language and character set for Notification messages; 1357 cryptographic binding; MIPv6 Binding Update. 1359 The EAP peer may not necessarily implement all the TLVs supported by 1360 the EAP server; and hence to allow for interoperability, the TLV 1361 method allows a EAP server to discover if a TLV is supported by the 1362 EAP peer, using the NAK TLV. 1364 The mandatory bit in a TLV indicates that if the peer does not 1365 support the TLV, it MUST send a NAK TLV in response; and all the 1366 other TLVs in the message MUST be ignored. If an EAP peer finds an 1367 unsupported TLV which is marked as optional, it MUST NOT send an NAK 1368 TLV. 1370 The mandatory bit does not imply that the peer is required to 1371 understand the contents of the TLV. The appropriate response to a 1372 supported TLV with content that is not understood is defined by the 1373 TLV specification. 1375 If the EAP peer finds that the packet has no TLVs, then it MUST send 1376 a response with EAP-TLV Response Packet. 1378 The mandatory bit in a TLV indicates that if the EAP server does not 1379 support the TLV, it MUST send a NAK TLV in response; otherwise it 1380 MUST send a protected termination message. If an EAP server finds an 1381 unsupported TLV which is marked as mandatory; the other TLVs in the 1382 message MUST be ignored. 1384 An EAP-TLV packet is a EAP method and within a PEAPv2 tunnel, it can 1385 be sequenced before or after any other EAP method. An EAP-TLV packet 1386 does not have to contain any TLVs nor need it contain any mandatory 1387 TLVs. 1389 PEAPv2 implementations MUST support the EAP TLV method, as well as 1390 processing of mandatory/optional settings on the TLV. 1392 4.1. EAP-TLV Request Packet 1394 A summary of the EAP-TLV Request packet format is shown below. The 1395 fields are transmitted from left to right. 1397 0 1 2 3 1398 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 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Code | Identifier | Length | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Type | Data.... 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 Code 1407 1 1409 Identifier 1411 The Identifier field is one octet and aids in matching responses 1412 with requests. The Identifier field MUST be changed on each 1413 Request packet. 1415 Length 1417 The Length field is two octets and indicates the length of the EAP 1418 packet including the Code, Identifier, Length, Type, and Data 1419 fields. 1421 Type 1423 33 - EAP-TLV 1425 Data 1427 The Data field is of variable length, and contains Type-Length- 1428 Value tuples (TLVs). 1430 4.2. EAP-TLV Response Packet 1432 A summary of the Extension Response packet format is shown below. 1433 The fields are transmitted from left to right. 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | Code | Identifier | Length | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | Type | Data.... 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 Code 1444 2 1446 Identifier 1448 The Identifier field is one octet and aids in matching responses 1449 with requests. The Identifier field MUST be changed on each 1450 Request packet. 1452 Length 1454 The Length field is two octets and indicates the length of the EAP 1455 packet including the Code, Identifier, Length, Type, and Data 1456 fields. 1458 Type 1460 33 - EAP-TLV 1462 Data 1464 The Data field is of variable length, and contains Type-Length- 1465 Value tuples (TLVs). 1467 4.3. TLV format 1469 EAP-TLV TLVs are defined as follows: 1471 0 1 2 3 1472 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 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 |M|R| TLV Type | Length | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Value... 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 M 1481 0 - Non-mandatory TLV 1482 1 - Mandatory TLV 1484 R 1486 Reserved, set to zero (0) 1488 TLV Type 1490 A 14-bit field, denoting the TLV type. Allocated Types include: 1492 0 - Reserved 1493 1 - Reserved 1494 2 - Reserved 1495 3 - RESULT_TLV - Acknowledged Result 1496 4 - NAK_TLV 1497 5 - Crypto-Binding TLV 1498 6 - Connection-Binding TLV 1499 7 - Vendor-Specific TLV 1500 8 - URI TLV 1501 9 - EAP Payload TLV 1502 10 - Intermediate Result TLV 1504 Length 1506 The length of the Value field in octets. 1508 Value 1510 The value of the TLV. 1512 4.4. Result TLV 1514 The Result TLV provides support for acknowledged success and failure 1515 messages within PEAPv2. PEAPv2 implementations MUST support this 1516 TLV, which cannot be responded to with a NAK TLV. If the Status 1517 field does not contain one of the known values, then the peer or EAP 1518 server MUST drop the connection. The Result TLV is defined as 1519 follows: 1521 0 1 2 3 1522 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 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 |M|R| TLV Type | Length | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Status | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 M 1531 1 - Mandatory TLV 1533 R 1535 Reserved, set to zero (0) 1537 TLV Type 1539 3 1541 Length 1543 2 1545 Status 1547 The Status field is two octets. Values include: 1549 1 - Success 1550 2 - Failure 1552 4.5. NAK TLV 1554 The NAK TLV allows a peer to detect TLVs that are not supported by 1555 the other peer. An EAP-TLV packet can contain 0 or more NAK TLVs. 1556 PEAPv2 implementations MUST support this TLV and this TLV cannot be 1557 responded to with a NAK TLV. The NAK TLV is defined as follows: 1559 0 1 2 3 1560 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 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 |M|R| TLV Type | Length | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Vendor-Id | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | NAK-Type | TLVs.... 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 M 1571 1 - Mandatory TLV 1573 R 1575 Reserved, set to zero (0) 1577 TLV Type 1579 4 1581 Length 1583 >=6 1585 Vendor-Id 1587 The Vendor-Id field is four octets, and contains the Vendor-Id of 1588 the TLV that was not supported. The high-order octet is 0 and the 1589 low-order 3 octets are the SMI Network Management Private 1590 Enterprise Code of the Vendor in network byte order. The Vendor- 1591 Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. 1592 For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI 1593 code. 1595 NAK-Type 1597 The NAK-Type field is two octets. The field contains the Type of 1598 the TLV that was not supported. A TLV of this Type MUST have been 1599 included in the previous packet. 1601 TLVs 1603 This field contains a list of TLVs, each of which MUST NOT have 1604 the mandatory bit set. These optional TLVs can be used in the 1605 future to communicate why the offending TLV was determined to be 1606 unsupported. 1608 4.6. Crypto-binding TLV 1610 The Crypto-Binding TLV is used prove that both peers participated in 1611 the sequence of authentications (specifically the TLS session and 1612 inner EAP methods that generate keys). 1614 Both the Binding Request (B1) and Binding Response (B2) use the same 1615 packet format. However the Sub-Type indicates whether it is B1 or 1616 B2. 1618 The Crypto-Binding TLV MUST be used to perform Cryptographic Binding 1619 after each successful EAP method (except EAP-TLV) in a sequence of 1620 EAP methods is complete in PEAPv2 part 2. The Crypto-Binding TLV can 1621 also be used during Protected Termination. 1623 The crypto-binding TLV must have the version number received during 1624 the PEAP version negotiation. The receiver of the crypto binding TLV 1625 must verify that the version in the crypto binding TLV matches the 1626 version it sent during the PEAP version negotiation. If this check 1627 fails then the TLV is invalid. 1629 The receiver of the crypto binding TLV must verify that the subtype 1630 is not set to any value other than the ones allowed. If this check 1631 fails then the TLV is invalid. 1633 This message format is used for the Binding Request (B1) and also the 1634 Binding Response. This uses TLV type CRYPTO_BINDING_TLV. PEAPv2 1635 implementations MUST support this TLV and this TLV cannot be 1636 responded to with a NAK TLV. The format is as given below. 1638 0 1 2 3 1639 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 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 |M|R| TLV Type | Length | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Version |Received Ver. | Sub-Type | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | | 1646 ~ Nonce ~ 1647 | | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | | 1650 ~ Compound MAC ~ 1651 | | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 M 1656 1 - Mandatory TLV 1658 R 1660 Reserved, set to zero (0) 1662 TLV Type 1664 5 1666 Length 1668 52 1670 Version 1672 The Version field is a single octet, which is set to the version 1673 of crypto binding TLV. For the crypto-binding TLV defined in this 1674 specification, It is set to zero (0). 1676 Received Version 1678 The Received Version field is a single octet and MUST be set to 1679 the PEAP version number received during version negotiation. Note 1680 that this field only provides protection against downgrade attacks 1681 where a version of PEAP requiring support for this TLV is required 1682 on both sides (such as PEAPv2 or a more recent version). 1684 Sub-Type 1685 The Sub-Type field is two octets. Possible values include: 1687 0 - Binding Request 1688 1 - Binding Response 1690 Nonce 1692 The Nonce field is 32 octets. It contains a 256 bit nonce that is 1693 temporally unique, used for compound MAC key derivation at each 1694 end. This is the S_NONCE for the B1 message and a C_NONCE for the 1695 B2 message. 1697 Compound MAC 1699 The Compound MAC field is 16 octets. This can be the Server MAC 1700 (B1_MAC) or the Client MAC (B2_MAC). It is computed over the 1701 entire Crypto-Binding TLV attribute using the HMAC-SHA1-128 that 1702 provides 128 bits of output using the CMK_B1 or CMK_B2 with the 1703 MAC field zeroed out. 1705 4.7. Connection-Binding TLV 1707 The Connection-Binding TLV allows for connection specific information 1708 to be sent by the peer to the AAA server. This TLV should be logged 1709 by the EAP or AAA server. The AAA or EAP server should not deny 1710 access if there i s a mismatch between the value sent through the AAA 1711 protocol and this TLV. 1713 The format of this TLV is defined for the layer that defines the 1714 parameters. The format of the value sent by the peer to the EAP 1715 server may be different from the format of the corresponding value 1716 sent through the AAA protocol. For example, the connection binding 1717 TLV may contain 802.11 MAC Address and SSID. 1719 PEAP implementations MAY support this TLV and this TLV MUST NOT be 1720 responded to with a NAK TLV. It is defined as follows: 1722 0 1 2 3 1723 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 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 |M|R| TLV Type | Length | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | TLVs... 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 M 1732 0 - Optional TLV 1734 R 1736 Reserved, set to zero (0) 1738 TLV Type 1740 6 1742 Length 1744 >=0 1746 TLVs... 1748 The field contains a list of TLVs, each in the same format defined 1749 in Section 4.3, with the optional bit set. These TLVs contain 1750 information on the identity of the peer and authenticator (layer 2 1751 or IP addresses); the media used to connect the peer and 1752 authenticator (NAS-Port-Type); and/or the service the client is 1753 trying to access on the gateway (SSID). The format of these TLVs 1754 will be defined in a separate draft. 1756 4.8. Vendor-Specific TLV 1758 The Vendor-Specific TLV is available to allow vendors to support 1759 their own extended attributes not suitable for general usage. 1761 A Vendor-Specific-TLV attribute can contain one or more TLVs, 1762 referred to as Vendor-TLVs. The TLV-type of the Vendor-TLV will be 1763 defined by the vendor. All the Vendor-TLVs inside a single Vendor- 1764 Specific TLV belong to the same vendor. 1766 PEAPv2 implementations MUST support the Vendor-Specific TLV; and this 1767 TLV cannot be responded to with a NAK TLV. PEAPv2 implementations 1768 MAY NOT support the Vendor-TLVs included in the Vendor-Specific TLV 1769 and can respond with a NAK TLV. 1771 Vendor-TLVs may be optional or mandatory. Vendor-TLVs sent in the 1772 protected success and failure packets MUST be marked as optional. If 1773 Vendor-TLVs sent in protected success/failure packets are marked as 1774 Mandatory, then the peer or EAP server MUST drop the connection. 1776 A summary of the Vendor-Specific Attribute format is shown below. 1777 The fields are transmitted from left to right. 1779 0 1 2 3 1780 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 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 |M|R| TLV Type | Length | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Vendor-Id | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Vendor-TLVs.... 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 M 1791 1 - Mandatory TLV 1793 R 1795 Reserved, set to zero (0) 1797 TLV Type 1799 7 1801 Length 1803 >=4 1805 Vendor-Id 1807 The Vendor-Id field is four octets. The high-order octet is 0 and 1808 the low-order 3 octets are the SMI Network Management Private 1809 Enterprise Code of the Vendor in network byte order. The Vendor- 1810 Id MUST be zero for TLVs that are not Vendor-Specific TLVs. For 1811 Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code. 1813 Vendor-TLVs 1815 This field is of indefinite length. It contains vendor-specific 1816 TLVs, in a format defined by the vendor. 1818 4.9. URI TLV 1820 The URI TLV allows a server to send a URI to the client to refer it 1821 to a resource. The TLV contains a URI in the format specified in 1822 RFC2396 with UTF-8 encoding. If a packet contains multiple URI TLVs, 1823 then the client SHOULD select the first TLV it can implement, and 1824 ignore the others. If the client is unable to implement any of the 1825 URI TLVs, then it MAY ignore the error. PEAP implementations MAY 1826 support this TLV; and this TLV cannot be responded to with a NAK TLV. 1828 A summary of this field is shown below: 1830 0 1 2 3 1831 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 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 |M|R| TLV Type | Length | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | URI... 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 M 1840 0 - Optional TLV 1842 R 1844 Reserved, set to zero (0) 1846 TLV Type 1848 8 1850 Length 1852 >=0 1854 URI 1856 This field is of indefinite length, and conforms to the format 1857 specified in [RFC2396]. 1859 4.10. EAP-Payload TLV 1861 To allow piggybacking EAP request and response with other TLVs, the 1862 EAP Payload TLV is defined, which includes an encapsulated EAP packet 1863 and 0 or more TLVs. PEAPv2 implementations MUST support this TLV, 1864 which cannot be responded to with a NAK TLV. The EAP-Payload TLV is 1865 defined as follows: 1867 0 1 2 3 1868 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 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 |M|R| TLV Type | Length | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | EAP packet... 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | TLVs... 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 M 1878 1 - Mandatory TLV 1880 R 1882 Reserved, set to zero (0) 1884 TLV Type 1886 8 1888 Length 1890 >=0 1892 EAP packet 1894 This field contains a complete EAP packet, including the EAP 1895 header (Code, Identifier, Length, Type) fields. The length of 1896 this field is determined by the Length field of the encapsulated 1897 EAP packet. 1899 TLVs... 1901 This (optional) field contains a list of TLVs associated with the 1902 EAP packet field. The TLVs utilize the same format described 1903 Section 4.3, and MUST NOT have the mandatory bit set. The total 1904 length of this field is equal to the Length field of the EAP- 1905 Payload-TLV, minus the Length field in the EAP header of the EAP 1906 packet field. 1908 4.11. Intermediate Result TLV 1910 The Intermediate Result TLV provides support for acknowledged 1911 intermediate Success and Failure messages within EAP. PEAPv2 1912 implementations MUST support this TLV, which cannot be responded to 1913 with a NAK TLV. This TLV is defined as follows: 1915 0 1 2 3 1916 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 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 |M|R| TLV Type | Length | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Status | TLVs... 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 M 1924 1 - Mandatory TLV 1926 R 1928 Reserved, set to zero (0) 1930 TLV Type 1932 10 1934 Length 1936 >=2 1938 Status 1940 The Status field is two octets. Values include: 1942 1 - Success 1943 2 - Failure 1945 TLVs 1947 This (optional) field is of indeterminate length, and contains the 1948 TLVs associated with the Intermediate Result TLV, in the same 1949 format as described in Section 4.3. The TLVs in this field MUST 1950 NOT have the mandatory bit set. 1952 4.12. TLV Rules 1954 To save round trips, multiple TLVs can be sent in the single PEAPv2 1955 packet. However, multiple EAP Payload TLVs within one single PEAPv2 1956 packet is not supported in this version and MUST NOT be sent. If the 1957 peer or EAP server receives multiple EAP Payload TLVs, then it MUST 1958 drop the connection. 1960 The following table provides a guide to which TLVs may be found in 1961 which kind of packets, and in which quantity: 1963 Request Response Success Failure TLV 1964 0-1 0-1 0-1 0-1 Intermediate Result TLV 1965 0-1 0-1 0 0 EAP Payload TLV 1966 0-1 0-1 1 1 Result TLV 1967 0-1 0-1 0-1 0-1 Crypto-Binding TLV 1968 0+ 0+ 0 0 NAK TLV 1969 0-1 0-1 0-1 0-1 Connection-Binding TLV 1970 0+ 0+ 0+ 0+ Vendor-Specific TLV 1971 0+ 0 0+ 0-1 URI TLV 1972 The following table defines the meaning of the above table entries. 1974 0 This TLV MUST NOT be present in the packet. 1975 0+ Zero or more instances of this TLV MAY be present in packet. 1976 0-1 Zero or one instance of this TLV MAY be present in packet. 1977 1 Exactly one instance of this TLV MUST be present in packet. 1979 Packet type Description 1980 ---------------------------- 1981 Request - EAP-TLV request packet sent by EAP server to peer. 1982 Response - EAP-TLV response packet sent by peer to EAP server. 1983 Success - EAP-TLV packet sent by Peer or EAP server as 1984 protected success 1985 Failure - EAP-TLV packet sent by Peer or EAP server as 1986 protected failure. 1988 The EAP-Payload TLV can contain other TLVs. The table below 1989 defines which TLVs can be contained inside the EAP-Payload TLV 1990 and how many such TLVs can be included. 1992 EAP-Payload-TLV TLV 1993 0 Intermediate Result TLV 1994 0 EAP Payload TLV 1995 0 Result TLV 1996 0 Crypto-Binding TLV 1997 0+ NAK TLV 1998 0 Connection-Binding TLV 1999 0+ Vendor-Specific TLV 2000 0 URI TLV 2002 5. Security Considerations 2004 5.1. Authentication and integrity protection 2006 PEAPv2 provides a server authenticated, encrypted and integrity 2007 protected tunnel. All data within the tunnel has these properties. 2008 Data outside the tunnel such as EAP Success and Failure, 2009 authentication methods negotiated outside of PEAPv2 and the PEAPv2 2010 headers themselves are not protected by this tunnel. 2012 In addition, the crypto-binding TLV can reveal man-in-the-middle 2013 attack described in section 6.8. Hence, the server should not reveal 2014 any sensitive data to the client until after the Crypto-Binding TLV 2015 has been properly verified. 2017 5.2. Method negotiation 2019 If the peer does not support PEAPv2, or does not wish to utilize 2020 PEAPv2 authentication, it MUST respond to the initial EAP- 2021 Request/PEAP-Start with a NAK, suggesting an alternate authentication 2022 method. Since the NAK is sent in cleartext with no integrity 2023 protection or authentication, it is subject to spoofing. Inauthentic 2024 NAK packets can be used to trick the peer and authenticator into 2025 "negotiating down" to a weaker form of authentication, such as EAP- 2026 MD5 (which only provides one way authentication and does not derive a 2027 key). 2029 Since a subsequent protected EAP conversation can take place within 2030 the TLS session, selection of PEAPv2 as an authentication method does 2031 not limit the potential secondary authentication methods. As a 2032 result, the only legitimate reason for a peer to NAK PEAPv2 as an 2033 authentication method is that it does not support it. Where the 2034 additional security of PEAPv2 is required, server implementations 2035 SHOULD respond to a NAK with an EAP-Failure, terminating the 2036 authentication conversation. 2038 Since method negotiation outside of PEAP is not protected, if the 2039 peer is configured to allow PEAP and other EAP methods at the same 2040 time, the negotiation is subject to downgrade attacks. Since method 2041 negotiation outside of PEAP is not protected, if the peer is 2042 configured to allow PEAP version 2; and previous PEAP versions at the 2043 same time, the negotiation is subject to negotiation downgrade 2044 attacks. However, peers configured to allow PEAPv2 and later PEAP 2045 versions may not be subject to downgrade negotiation attack since the 2046 highest version supported by both peers is checked within the 2047 protected tunnel. 2049 If peer implementations select incorrect methods or credentials with 2050 EAP servers, then attacks are possible on the credentials. Hence, a 2051 PEAPv2 peer implementation should preferably be configured with a set 2052 of credentials and methods that may be used with a specific PEAPv2 2053 Server. The peer implementation may be configured to use different 2054 methods and/or credentials based on the PEAPv2 server. 2056 5.3. TLS session cache handling 2058 In cases where a TLS session has been successfully resumed, in some 2059 circumstances, it is possible for the EAP server to skip the PEAPv2 2060 Part 2 conversation, and successfully conclude the conversation with 2061 a protected termination. 2063 PEAPv2 "fast reconnect" is desirable in applications such as wireless 2064 roaming, since it minimizes interruptions in connectivity. It is 2065 also desirable when the "inner" EAP mechanism used is such that it 2066 requires user interaction. The user should not be required to re- 2067 authenticate herself, using biometrics, token cards or similar, every 2068 time the radio connectivity is handed over between access points in 2069 wireless environments. 2071 However, there are issues that need to be understood in order to 2072 avoid introducing security vulnerabilities. 2074 Since PEAPv2 Part 1 may not provide client authentication, 2075 establishment of a TLS session (and an entry in the TLS session 2076 cache) does not by itself provide an indication of the peer's 2077 authenticity. 2079 Some PEAPv2 implementations may not be capable of removing TLS 2080 session cache entries established in PEAPv2 Part 1 after an 2081 unsuccessful PEAPv2 Part 2 authentication. In such implementations, 2082 the existence of a TLS session cache entry provides no indication 2083 that the peer has previously been authenticated. As a result, 2084 implementations that do not remove TLS session cache entries after a 2085 failed PEAPv2 Part 2 authentication or failed protected termination 2086 MUST use other means than successful TLS resumption as the indicator 2087 of whether the client is authenticated or not. The implementation 2088 MUST determine that the client is authenticated only after the 2089 completion of protected termination. Failing to do this would enable 2090 a peer to gain access by completing PEAPv2 Part 1, tearing down the 2091 connection, re-connecting and resuming PEAPv2 Part 1, thereby proving 2092 herself authenticated. Thus, TLS resumption MUST only be enabled if 2093 the implementation supports TLS session cache removal. If an EAP 2094 server implementing PEAPv2 removes TLS session cache entries of peers 2095 failing PEAPv2 Part 2 authentication, then it MAY skip the PEAPv2 2096 Part 2 conversation entirely after a successful session resumption, 2097 successfully terminating the PEAPv2 conversation as described in 2098 Section 2.4. 2100 5.4. Certificate revocation 2102 Since the EAP server is on the Internet during the EAP conversation, 2103 the server is capable of following a certificate chain or verifying 2104 whether the peer's certificate has been revoked. In contrast, the 2105 peer may or may not have Internet connectivity, and thus while it can 2106 validate the EAP server's certificate based on a pre-configured set 2107 of CAs, it may not be able to follow a certificate chain or verify 2108 whether the EAP server's certificate has been revoked. 2110 In the case where the peer is initiating a voluntary Layer 2 channel 2111 using PPTP or L2TP, the peer will typically already have Internet 2112 connectivity established at the time of channel initiation. As a 2113 result, during the EAP conversation it is capable of checking for 2114 certificate revocation. 2116 As part of the TLS negotiation, the server presents a certificate to 2117 the peer. The peer SHOULD verify the validity of the EAP server 2118 certificate, and SHOULD also examine the EAP server name presented in 2119 the certificate, in order to determine whether the EAP server can be 2120 trusted. Please note that in the case where the EAP authentication is 2121 remoted, the EAP server will not reside on the same machine as the 2122 authenticator, and therefore the name in the EAP server's certificate 2123 cannot be expected to match that of the intended destination. In 2124 this case, a more appropriate test might be whether the EAP server's 2125 certificate is signed by a CA controlling the intended destination 2126 and whether the EAP server exists within a target sub-domain. 2128 In the case where the peer is attempting to obtain network access, it 2129 will not have Internet connectivity. The TLS Extensions [RFC3546] 2130 support piggybacking of an Online Certificate Status Protocol (OCSP) 2131 response within TLS, therefore can be utilized by the peer in order 2132 to verify the validity of server certificate. However, since not all 2133 TLS implementations implement the TLS extensions, it may be necessary 2134 for the peer to wait to check for certificate revocation until after 2135 Internet access has been obtained. In this case, the peer SHOULD 2136 conduct the certificate status check immediately upon going online 2137 and SHOULD NOT send data until it has received a positive response to 2138 the status request. If the server certificate is found to be invalid 2139 as per client policy, then the peer SHOULD disconnect. 2141 If the client has a policy to require checking certificate revocation 2142 and it cannot obtain revocation information then it may need to 2143 disallow the use of all or some of the inner methods since some 2144 methods may reveal some sensitive information. 2146 5.5. Separation of the EAP server and the authenticator 2148 As a result of a complete PEAPv2 Part 1 and Part 2 conversation, the 2149 EAP endpoints will mutually authenticate, and derive a session key 2150 for subsequent use in link layer security. Since the peer and EAP 2151 client reside on the same machine, it is necessary for the EAP client 2152 module to pass the session key to the link layer encryption module. 2154 The situation may be more complex on the Authenticator, which may or 2155 may not reside on the same machine as the EAP server. In the case 2156 where the EAP server and the Authenticator reside on different 2157 machines, there are several implications for security. Firstly, the 2158 mutual authentication defined in PEAP will occur between the peer and 2159 the EAP server, not between the peer and the authenticator. This 2160 means that as a result of the PEAP conversation, it is not possible 2161 for the peer to validate the identity of the NAS or channel server 2162 that it is speaking to. 2164 The second issue is that the session key negotiated between the peer 2165 and EAP server will need to be transmitted to the authenticator. 2166 Therefore a secure mechanism needs to be provided to transmit the 2167 session key from the EAP server to the authenticator or channel 2168 server that needs to use the key. The specification of this transit 2169 mechanism is outside the scope of this document. 2171 5.6. Separation of PEAPv2 Part 1 and Part 2 Servers 2173 The EAP server involved in PEAPv2 Part 2 need not necessarily be the 2174 same as the EAP server involved in PEAPv2 Part 1. For example, a 2175 local authentication server or proxy might serve as the endpoint for 2176 the Part 1 conversation, establishing the TLS channel. Subsequently, 2177 once the EAP-Response/Identity has been received within the TLS 2178 channel, it can be decrypted and forwarded in cleartext to the 2179 destination realm EAP server. The rest of the conversation will 2180 therefore occur between the destination realm EAP server and the 2181 peer, with the local authentication server or proxy acting as an 2182 encrypting/decrypting gateway. This permits a non-TLS capable EAP 2183 server to participate in the PEAPv2 conversation. 2185 Note however that such an approach introduces security 2186 vulnerabilities. Since the EAP Response/Identity is sent in the 2187 clear between the proxy and the EAP server, this enables an attacker 2188 to snoop the user's identity. It also enables a remote environments, 2189 which may be public hot spots or Internet coffee shops, to gain 2190 knowledge of the identity of their users. Since one of the potential 2191 benefits of PEAP is identity protection, this is undesirable. 2193 If the EAP method negotiated during PEAPv2 Part 2 does not support 2194 mutual authentication, then if the Part 2 conversation is proxied to 2195 another destination, the PEAP peer will not have the opportunity to 2196 verify the secondary EAP server's identity. Only the initial EAP 2197 server's identity will have been verified as part of TLS session 2198 establishment. 2200 Similarly, if the EAP method negotiated during PEAPv2 Part 2 is 2201 vulnerable to dictionary attack, then an attacker capturing the 2202 cleartext exchange will be able to mount an offline dictionary attack 2203 on the password. 2205 Finally, when a Part 2 conversation is terminated at a different 2206 location than the Part 1 conversation, the Part 2 destination is 2207 unaware that the EAP client has negotiated PEAPv2. As a result, it is 2208 unable to enforce policies requiring PEAP. Since some EAP methods 2209 require PEAPv2 in order to generate keys or lessen security 2210 vulnerabilities, where such methods are in use, such a configuration 2211 may be unacceptable. 2213 In summary, PEAPv2 encrypting/decrypting gateway configurations are 2214 vulnerable to attack and SHOULD NOT be used. Instead, the entire 2215 PEAPv2 connection SHOULD be proxied to the final destination, and the 2216 subsequently derived master session keys need to be transmitted back. 2217 T his provides end to end protection of PEAPv2. The specification of 2218 this transit mechanism is outside the scope of this document, but 2219 mechanisms similar to [RFC2548] can be used. These steps protect the 2220 client from revealing her identity to the remote environment. 2222 In order to find the proper PEAP destination, the EAP client SHOULD 2223 place a Network Access Identifier (NAI) conforming to [RFC2486] in 2224 the Identity Response. 2226 There may be cases where a natural trust relationship exists between 2227 the (foreign) authentication server and final EAP server, such as on 2228 a campus or between two offices within the same company, where there 2229 is no danger in revealing the identity of the station to the 2230 authentication server. In these cases, a proxy solution without end 2231 to end protection of PEAPv2 MAY be used. If RADIUS is used to 2232 communicate between gateway and EAP server, then the PEAPv2 2233 encrypting/decrypting gateway SHOULD provide support for IPsec 2234 protection of RADIUS in order to provide confidentiality for the 2235 portion of the conversation between the gateway and the EAP server, 2236 as described in [RFC3579]. 2238 5.7. Identity verification 2240 Since the TLS session has not yet been negotiated, the initial 2241 Identity request/response occurs in the clear without integrity 2242 protection or authentication. It is therefore subject to snooping and 2243 packet modification. 2245 In configurations where all users are required to authenticate with 2246 PEAPv2 and the first portion of the PEAPv2 conversation is terminated 2247 at a local backend authentication server, without routing by proxies, 2248 the initial cleartext Identity Request/Response exchange is not 2249 needed in order to determine the required authentication method(s) or 2250 route the authentication conversation to its destination. As a 2251 result, the initial Identity and Request/Response exchange MAY NOT 2252 be present, and a subsequent Identity Request/Response exchange MAY 2253 occur after the TLS session is established. 2255 If the initial cleartext Identity Request/Response has been tampered 2256 with, after the TLS session is established, it is conceivable that 2257 the EAP Server will discover that it cannot verify the peer's claim 2258 of identity. For example, the peer's userID may not be valid or may 2259 not be within a realm handled by the EAP server. Rather than 2260 attempting to proxy the authentication to the server within the 2261 correct realm, the EAP server SHOULD terminate the conversation. 2263 The PEAPv2 peer can present the server with multiple identities. This 2264 includes the claim of identity within the initial EAP- 2265 Response/Identity (MyID) packet, which is typically used to route the 2266 EAP conversation to the appropriate home backend authentication 2267 server. There may also be subsequent EAP-Response/Identity packets 2268 sent by the peer once the TLS channel has been established. 2270 Note that since the PEAPv2 peer may not present a certificate, it is 2271 not always possible to check the initial EAP-Response/Identity 2272 against the identity presented in the certificate, as is done in 2273 [RFC2716]. 2275 Moreover, it cannot be assumed that the peer identities presented 2276 within multiple EAP-Response/Identity packets will be the same. For 2277 example, the initial EAP-Response/Identity might correspond to a 2278 machine identity, while subsequent identities might be those of the 2279 user. Thus, PEAPv2 implementations SHOULD NOT abort the 2280 authentication just because the identities do not match. However, 2281 since the initial EAP-Response/Identity will determine the EAP server 2282 handling the authentication, if this or any other identity is 2283 inappropriate for use with the destination EAP server, there is no 2284 alternative but to terminate the PEAPv2 conversation. 2286 The protected identity or identities presented by the peer within 2287 PEAPv2 Part 2 may not be identical to the cleartext identity 2288 presented in PEAPv2 Part 1, for legitimate reasons. In order to 2289 shield the userID from snooping, the cleartext Identity may only 2290 provide enough information to enable routing of the authentication 2291 request to the correct realm. For example, the peer may initially 2292 claim the identity of "nouser@bigco.com" in order to route the 2293 authentication request to the bigco.com EAP server. Subsequently, 2294 once the TLS session has been negotiated, in PEAPv2 Part 2, the peer 2295 may claim the identity of "fred@bigco.com". Thus, PEAPv2 can provide 2296 protection for the user's identity, though not necessarily the 2297 destination realm, unless the PEAPv2 Part 1 conversation terminates 2298 at the local authentication server. 2300 As a result, PEAPv2 implementations SHOULD NOT attempt to compare the 2301 Identities claimed with Parts 1 and 2 of the PEAPv2 conversation. 2302 Similarly, if multiple Identities are claimed within PEAPv2 Part 2, 2303 these SHOULD NOT be compared. An EAP conversation may involve more 2304 than one EAP authentication method, and the identities claimed for 2305 each of these authentications could be different (e.g. a machine 2306 authentication, followed by a user authentication). 2308 5.8. Man-in-the-middle attack protection 2310 TLS protection can address a number of weaknesses in the EAP method; 2311 as well as EAP protocol weaknesses listed in the abstract and 2312 introduction sections in this document. 2314 Hence, the recommended solution is to always deploy authentication 2315 methods with protection of PEAPv2. 2317 if a deployment chooses to allow a EAP method protected by PEAP 2318 without protection of PEAP or IPsec at the same time, then this opens 2319 up a possibility of a man-in-the-middle attack. 2321 A man-in-the-middle can spoof the client to authenticate to it 2322 instead of the real EAP server; and forward the authentication to the 2323 real server over a protected tunnel. Since the attacker has access to 2324 the keys derived from the tunnel, it can gain access to the network. 2326 PEAP version 2 prevents this attack by using the keys generated by 2327 the inner EAP method in the crypto-binding exchange described in 2328 protected termination section. This attack is not prevented if the 2329 inner EAP method does not generate keys or if the keys generated by 2330 the inner EAP method can be compromised. 2332 Alternatively, the attack can also be thwarted if the inner EAP 2333 method can signal to the peer that the packets are being sent within 2334 the tunnel. In most cases this may require modification to the inner 2335 EAP method. In order to allow for these implementations, PEAPv2 2336 implementations should inform inner EAP methods that the EAP method 2337 is being protected by a PEAPv2 tunnel. 2339 Since all sequence negotiations and exchanges are protected by TLS 2340 channel, they are immune to snooping and MITM attacks with the use of 2341 Crypto-Binding TLV. To make sure the same parties are involved tunnel 2342 establishment and previous inner method, before engaging the next 2343 method to sent more sensitive information, both peer and server MUST 2344 use the Crypto-Binding TLV between methods to check the tunnel 2345 integrity. If the Crypto-Binding TLV failed validation, they SHOULD 2346 stop the sequence and terminate the tunnel connection, to prevent 2347 more sensitive information being sent in subsequent methods. 2349 5.9. Cleartext forgeries 2351 As described in [RFC2284bis], EAP Success and Failure packets are not 2352 authenticated, so that they may be forged by an attacker without fear 2353 of detection. Forged EAP Failure packets can be used to convince an 2354 EAP peer to disconnect. Forged EAP Success and Failure packets may be 2355 used to convince a peer to disconnect; or convince a peer to access 2356 the network even before authentication is complete, resulting in 2357 denial of service for the peer. 2359 By supporting encrypted, authenticated and integrity protected 2360 success/failure indications, PEAPv2 provides protection against these 2361 attacks. 2363 When the peer responds with the first PEAP packet; and the EAP server 2364 receives the first PEAPv2 packet from the peer, both MUST silently 2365 discard all clear text EAP messages unless both the PEAPv2 peer and 2366 server have indicated success or failure or error using a protected 2367 error or protected termination mechanism. The success/failure 2368 decisions sent by a protected mechanism indicate the final decision 2369 of the EAP authentication conversation. After success/failure has 2370 been indicated by a protected mechanism, the PEAPv2 client can 2371 process unprotected EAP success and EAP failure message; however MUST 2372 ignore any unprotected EAP success or failure messages where the 2373 decision does not match the decision of the protected mechanism. 2375 [RFC2284bis] states that an EAP Success or EAP Failure packet 2376 terminates the EAP conversation, so that no response is possible. 2377 Since EAP Success and EAP Failure packets are not retransmitted, if 2378 the final packet is lost, then authentication will fail. As a 2379 result, where packet loss is expected to be non-negligible, 2380 unacknowledged success/failure indications lack robustness. 2382 As a result, a EAP server SHOULD send a clear text EAP success or 2383 EAP-failure packet after the protected success or failure packet or 2384 TLS alert. The peer MUST NOT require the clear text EAP Success or 2385 EAP Failure if it has received the protected success or failure or 2386 TLS alert. For more details, refer to [RFC228bis], Section 4.2. 2388 5.10. TLS Ciphersuites 2390 Anonymous ciphersuites are vulnerable to man-in-the-middle attacks, 2391 and SHOULD NOT be used with PEAPv2, unless the EAP methods inside 2392 PEAPv2 can address the man-in-the-middle attack or unless the man-in- 2393 the-middle attack can be addressed by mechanisms external to PEAPv2. 2395 5.11. Denial of service attacks 2397 Denial of service attacks are possible if the attacker can insert or 2398 modify packets in the authentication channel. The attacker can 2399 modify unprotected fields in the PEAP packet such as the EAP protocol 2400 or PEAP version number. This can result in a denial of service 2401 attack. It is also possible for the attacker to modify protected 2402 fields in a packet to cause decode errors resulting in a denial of 2403 service. In these ways the attacker can prevent access for peers 2404 connecting to the network. 2406 Denial of service attacks with multiplier impacts are more 2407 interesting than the ones above. It is possible to multiply the 2408 impact by creating a large number of TLS sessions with the EAP 2409 server. 2411 5.12. Security Claims 2413 Intended use: Wireless or Wired networks, and over 2414 the Internet, where physical security 2415 cannot be assumed. 2416 Auth. mechanism: Use arbitrary EAP and TLS authentication 2417 mechanisms for authentication of the 2418 client and server. 2419 Ciphersuite negotiation: Yes. 2420 Mutual authentication: Yes. Depends on the type of EAP method 2421 used within the tunnel and the type of 2422 authentication used within TLS. 2423 Integrity protection: Yes 2424 Replay protection: Yes 2425 Confidentiality: Yes 2426 Key derivation: Yes 2427 Key strength: Variable 2428 Dictionary attack prot: Not susceptible. 2429 Fast reconnect: Yes 2430 Crypt. binding: Yes. 2431 Acknowledged S/F: Yes 2432 Session independence: Yes. 2433 Fragmentation: Yes 2435 PEAPv2 derives keys by combining keys from TLS and the inner EAP 2436 methods. It should be noted that the use of TLS ciphersuites with a 2437 particular key lengths does not guarantee that the key strength of 2438 the keys will be equivalent to the length. The key exchange 2439 mechanisms (eg. RSA or Diffie-Hellman) used must provide sufficient 2440 security or they will be the weakest link. For example RSA key sizes 2441 with a modulus of 1024 bits provides less than 128 bits of security, 2442 this may provide sufficient key strength for some applications and 2443 not for others. See [PKLENGTH] for a detailed analysis of 2444 determining the public key strengths used to exchange symmetric keys. 2446 6. IANA Considerations 2448 This section provides guidance to the Internet Assigned Numbers 2449 Authority (IANA) regarding registration of values related to the EAP 2450 protocol, in accordance with BCP 26, [RFC2434]. 2452 There is one name space in EAP-TLV that requires registration: PEAPv2 2453 TLV-Types. 2455 6.1. Definition of Terms 2457 The following terms are used here with the meanings defined in BCP 2458 26: "name space", "assigned value", "registration". 2460 The following policies are used here with the meanings defined in BCP 2461 26: "Private Use", "First Come First Served", "Expert Review", 2462 "Specification Required", "IETF Consensus", "Standards Action". 2464 6.2. Recommended Registration Policies 2466 For "Designated Expert with Specification Required", the request is 2467 posted to the EAP WG mailing list (or, if it has been disbanded, a 2468 successor designated by the Area Director) for comment and review, 2469 and MUST include a pointer to a public specification. Before a period 2470 of 30 days has passed, the Designated Expert will either approve or 2471 deny the registration request and publish a notice of the decision to 2472 the EAP WG mailing list or its successor. A denial notice must be 2473 justified by an explanation and, in the cases where it is possible, 2474 concrete suggestions on how the request can be modified so as to 2475 become acceptable. 2477 EAP-TLVs have a 14-bit field, of which 0-10 have been allocated. 2479 Additional EAP-TLV type codes may be allocated following Designated 2480 Expert with Specification Required [RFC2434]. 2482 7. References 2484 7.1. Normative references 2486 [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", 2487 RFC 1321, April 1992. 2489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2490 Requirement Levels", BCP 14, RFC 2119, March 1997. 2492 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2493 2246, November 1998. 2495 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2496 2486, January 1999. 2498 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2499 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2500 1998. 2502 [RFC3546] Blake-Wilson, S., et al. "TLS Extensions", RFC 3546, June 2503 2003. 2505 [RFC2284bis] 2506 Blunk, L. et al., "Extensible Authentication Protocol (EAP)", 2507 draft-ietf-eap-rfc2284bis-06.txt, Internet draft (work in 2508 progress), October 2003. 2510 7.2. Informative references 2512 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 2513 1996. 2515 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. 2516 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 2517 1996. 2519 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 2520 Version 2 (DESE-bis)", RFC 2419, September 1998. 2522 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 2523 RFC 2420, September 1998. 2525 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2526 Considerations Section in RFCs", BCP 26, RFC 2434, October 2527 1998. 2529 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 2530 RFC2548, March 1999. 2532 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2533 RFC 2716, October 1999. 2535 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption 2536 (MPPE) Protocol", RFC 3078, March 2001. 2538 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 2539 Encryption (MPPE)", RFC 3079, March 2001. 2541 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS 2542 PUB 46 (January 1977). 2544 [IEEE80211] 2545 Information technology - Telecommunications and information 2546 exchange between systems - Local and metropolitan area 2547 networks - Specific Requirements Part 11: Wireless LAN Medium 2548 Access Control (MAC) and Physical Layer (PHY) Specifications, 2549 IEEE Std. 802.11-1999, 1999. 2551 [MODES] National Bureau of Standards, "DES Modes of Operation", FIPS 2552 PUB 81 (December 1980). 2554 [PEAPv0] Kamath, V., Palekar, A. and M. Wodrich, "Microsoft's PEAP 2555 version 0 (Implementation in Windows XP SP1)", draft-kamath- 2556 pppext-peapv0-00.txt, Internet draft (work in progress), July 2557 2002. 2559 [PKLENGTH] 2560 H. Orman and P. Hoffman, "Determining Strengths For Public 2561 Keys Used For Exchanging Symmetric Keys", draft-orman-public- 2562 key-lengths-05.txt, Internet Draft (work in progress), 2563 December 2002. 2565 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for EAP", RFC 3579, 2566 September 2003. 2568 [CompoundBinding] 2569 Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, "The 2570 Compound Authentication Binding Problem", draft-puthenkulam- 2571 eap-binding-03.txt, Internet Draft (work in progress), May 2572 2003. 2574 [IEEE8021X] 2575 IEEE Standards for Local and Metropolitan Area Networks: Port 2576 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 2578 Appendix A - Examples 2580 A.1 Cleartext Identity Exchange 2582 In the case where an identity exchange occurs within PEAPv2 Part 1, 2583 the conversation will appear as follows: 2585 Authenticating Peer Authenticator 2586 ------------------- ------------- 2587 <- EAP-Request/ 2588 Identity 2589 EAP-Response/ 2590 Identity (MyID1) -> 2592 // Identity sent in the clear. May be a hint to help route the 2593 authentication request to EAP server, instead of the full user 2594 identity. 2596 <- EAP-Request/ 2597 EAP-Type=PEAP, V=2 2598 (PEAP Start, S bit set) 2599 EAP-Response/ 2600 EAP-Type=PEAP, V=2 2601 (TLS client_hello)-> 2602 <- EAP-Request/ 2603 EAP-Type=PEAP, V=2 2604 (TLS server_hello, 2605 TLS certificate, 2606 [TLS server_key_exchange,] 2607 [TLS certificate_request,] 2608 TLS server_hello_done) 2609 EAP-Response/ 2610 EAP-Type=PEAP, V=2 2611 ([TLS certificate,] 2612 TLS client_key_exchange, 2613 [TLS certificate_verify,] 2614 TLS change_cipher_spec, 2615 TLS finished) -> 2616 <- EAP-Request/ 2617 EAP-Type=PEAP, V=2 2618 (TLS change_cipher_spec, 2619 TLS finished, 2620 EAP-Request/EAP-Type=EAP-TLV 2621 [EAP-Payload-TLV[EAP-Request/ 2622 Identity]]) 2624 // identity protected by TLS. EAP-TLV packet does not include an EAP- 2625 header. 2627 TLS channel established (EAP messages sent within TLS channel 2628 encapsulated in EAP-TLV packets without EAP header) 2630 EAP-TLV [EAP-Payload-TLV 2631 [EAP-Response/Identity (MyID2)]]]-> 2633 <- EAP-TLV [EAP-Payload-TLV 2634 [EAP-Request/EAP-Type=X]] 2636 EAP-TLV [EAP-Payload-TLV 2637 [EAP-Response/EAP-Type=X]] -> 2639 // Protected termination 2641 <- EAP-TLV [Result TLV (Success), 2642 Crypto-Binding-TLV (Version=0, 2643 received-version=2, Nonce, B1_MAC), 2644 Intermediate-Result-TLV (Success)] 2646 EAP-TLV [Result-TLV (Success), 2647 Intermediate-Result-TLV (Success), 2648 Crypto-Binding-TLV (Version=0, 2649 received-version=2,Nonce, B2_MAC)]-> 2651 TLS channel torn down 2652 (messages sent in cleartext) 2654 <- EAP-Success 2656 A.2 No cleartext Identity Exchange 2658 Where all peers are known to support PEAPv2, a non-certificate 2659 authentication is desired for the client and the PEAP Part 1 2660 conversation is carried out between the peer and a local EAP server, 2661 the cleartext identity exchange may be omitted and the conversation 2662 appears as follows: 2664 Authenticating Peer Authenticator 2665 ------------------- ------------- 2666 <- EAP-Request/ 2667 EAP-Type=PEAP, V=2 2668 (PEAP Start, S bit set) 2670 EAP-Response/ 2671 EAP-Type=PEAP, V=2 2672 (TLS client_hello)-> 2673 <- EAP-Request/ 2674 EAP-Type=PEAP, V=2 2675 (TLS server_hello, 2676 TLS certificate, 2677 [TLS server_key_exchange,] 2678 [TLS certificate_request,] 2679 TLS server_hello_done) 2680 EAP-Response/ 2681 EAP-Type=PEAP, V=2 2682 ([TLS certificate,] 2683 TLS client_key_exchange, 2684 [TLS certificate_verify,] 2685 TLS change_cipher_spec, 2686 TLS finished) -> 2687 <- EAP-Request/ 2688 EAP-Type=PEAP, V=2 2689 (TLS change_cipher_spec, 2690 TLS finished, 2691 EAP-TLV [EAP-Payload-TLV 2692 (EAP-Request/Identity)]) 2694 TLS channel established 2695 (messages sent within the TLS channel) 2697 EAP-TLV [EAP-Payload-TLV 2698 [EAP-Response/Identity (MyID)]] -> 2700 <- EAP-TLV [EAP-Payload-TLV 2701 [EAP-Type=EAP-Request/ 2702 EAP-Type=X]] 2704 EAP-TLV [EAP-Payload-TLV 2705 [EAP-Response/EAP-Type=X 2706 or NAK] -> 2707 <- EAP-TLV [EAP-Payload-TLV 2708 [EAP-Request/EAP-Type=X]] 2710 EAP-TLV [EAP-Payload-TLV [EAP-Response/ 2711 EAP-Type=X]] -> 2713 // Protected success 2714 <- EAP-TLV [Crypto-Binding-TLV= 2715 (Version=0, Received-version=2, 2716 Nonce, B1_MAC), 2717 Intermediate-Result-TLV(Success), 2718 Result TLV (Success)] 2720 EAP-TLV [Crypto-Binding-TLV= 2721 (Version=0,Received-version=2, 2722 Nonce, B2_MAC), 2723 Intermediate-Result-TLV (Success), 2724 Result TLV (Success)]-> 2726 TLS channel torn down 2727 (messages sent in cleartext) 2729 <- EAP-Success 2731 A.3 Client certificate authentication with identity privacy 2733 Where all peers are known to support PEAPv2, where client certificate 2734 authentication is desired and the PEAPv2 Part 1 conversation is 2735 carried out between the peer and a local EAP server, the cleartext 2736 identity exchange may be omitted and the conversation appears as 2737 follows: 2739 Authenticating Peer Authenticator 2740 ------------------- ------------- 2741 <- EAP-Request/ 2742 EAP-Type=PEAP, V=2 2743 (PEAP Start, S bit set) 2745 EAP-Response/ 2746 EAP-Type=PEAP, V=2 2747 (TLS client_hello)-> 2748 <- EAP-Request/ 2749 EAP-Type=PEAP, V=2 2750 (TLS server_hello, 2751 TLS certificate, 2752 [TLS server_key_exchange,] 2753 TLS server_hello_done) 2754 EAP-Response/ 2755 EAP-Type=PEAP, V=2 2756 (TLS client_key_exchange, 2757 TLS change_cipher_spec, 2758 TLS finished) -> 2759 <- EAP-Request/ 2760 EAP-Type=PEAP, V=2 2761 (TLS change_cipher_spec, 2762 TLS finished,TLS Hello-Request) 2763 EAP-Response/ 2764 EAP-Type=PEAP, V=2 2765 (TLS client_hello)-> 2767 TLS channel established 2768 (messages sent within the TLS channel) 2769 <- EAP-Request/ 2770 EAP-Type=PEAP, V=2 2771 (TLS server_hello, 2772 TLS certificate, 2773 [TLS server_key_exchange,] 2774 [TLS certificate_request,] 2775 TLS server_hello_done) 2776 EAP-Response/ 2777 EAP-Type=PEAP, V=2 2778 ([TLS certificate,] 2779 TLS client_key_exchange, 2780 [TLS certificate_verify,] 2781 TLS change_cipher_spec, 2782 TLS finished) -> 2784 <- EAP-Request/ 2785 EAP-Type=PEAP, V=2 2786 (TLS change_cipher_spec, 2787 TLS finished, EAP-TLV 2788 [Crypto-binding-TLV (version=0, 2789 Received-version=2, Nonce, 2790 B1_MAC), 2791 Result-TLV (Success)]) 2793 // packet format within the TLS channel 2795 EAP-TLV [ 2796 Crypto-Binding-TLV=(Version=0, 2797 Received-version=2, 2798 Nonce, B2_MAC), 2799 Result TLV (Success)] 2801 TLS channel torn down 2802 (messages sent in cleartext) 2804 <- EAP-Success 2806 A.4 Fragmentation and Reassembly 2808 In the case where the PEAP fragmentation is required, the 2809 conversation will appear as follows: 2811 Authenticating Peer Authenticator 2812 ------------------- ------------- 2813 <- EAP-Request/ 2814 Identity 2815 EAP-Response/ 2816 Identity (MyID) -> 2817 <- EAP-Request/ 2818 EAP-Type=PEAP, V=2 2819 (PEAP Start, S bit set) 2821 EAP-Response/ 2822 EAP-Type=PEAP, V=2 2823 (TLS client_hello)-> 2824 <- EAP-Request/ 2825 EAP-Type=PEAP, V=2 2826 (TLS server_hello, 2827 TLS certificate, 2828 [TLS server_key_exchange,] 2829 [TLS certificate_request,] 2830 TLS server_hello_done) 2831 (Fragment 1: L, M bits set) 2833 EAP-Response/ 2834 EAP-Type=PEAP, V=2 -> 2836 <- EAP-Request/ 2837 EAP-Type=PEAP, V=2 2838 (Fragment 2: M bit set) 2839 EAP-Response/ 2840 EAP-Type=PEAP, V=2 -> 2841 <- EAP-Request/ 2842 EAP-Type=PEAP, V=2 2843 (Fragment 3) 2844 EAP-Response/ 2845 EAP-Type=PEAP, V=2 2846 ([TLS certificate,] 2847 TLS client_key_exchange, 2848 [TLS certificate_verify,] 2849 TLS change_cipher_spec, 2850 TLS finished) 2851 (Fragment 1: L, M bits set)-> 2853 <- EAP-Request/ 2854 EAP-Type=PEAP, V=2 2855 EAP-Response/ 2856 EAP-Type=PEAP, V=2 2857 (Fragment 2)-> 2858 <- EAP-Request/ 2859 EAP-Type=PEAP, V=2 2860 (TLS change_cipher_spec, 2861 TLS finished, EAP-TLV 2862 [EAP-Payload-TLV[ 2863 EAP-Request/Identity]]) 2865 TLS channel established 2866 (messages sent within the TLS channel) 2868 EAP-TLV 2869 [EAP-Payload-TLV 2870 [EAP-Response/Identity(myID)]] -> 2872 <- EAP-TLV [ EAP-Payload-TLV 2873 [EAP-Request/EAP-Type=X]] 2875 EAP-TLV [EAP-Payload-TLV 2876 [EAP-Response/EAP-Type=X or NAK]]-> 2878 <- EAP-TLV [ EAP-Payload-TLV 2879 [EAP-Request/EAP-Type=X]] 2881 EAP-TLV [EAP-Payload-TLV 2882 [EAP-Response/EAP-Type=X] -> 2884 <- EAP-TLV [Crypto-Binding-TLV 2885 =(Version=0, Received-Version=2, 2886 Nonce, B1_MAC), 2887 Intermediate-Result-TLV(Success), 2888 Result TLV (Success)] 2890 EAP-TLV [ 2891 Crypto-Binding-TLV=(Version=0, 2892 Received-Version=2,Nonce, B2_MAC), 2893 Result TLV (Success), 2894 Intermediate-Result-TLV (Success)] -> 2896 TLS channel torn down 2897 (messages sent in cleartext) 2899 <- EAP-Success 2901 A.5 Server authentication fails in Part 2 2903 In the case where the server authenticates to the client successfully 2904 in PEAPv2 Part 1, but the client fails to authenticate to the server 2905 in PEAPv2 Part 2, the conversation will appear as follows: 2907 Authenticating Peer Authenticator 2908 ------------------- ------------- 2909 <- EAP-Request/ 2910 Identity 2911 EAP-Response/ 2912 Identity (MyID) -> 2913 <- EAP-Request/ 2914 EAP-Type=PEAP, V=2 2915 (PEAP Start, S bit set) 2916 EAP-Response/ 2917 EAP-Type=PEAP, V=2 2918 (TLS client_hello)-> 2919 <- EAP-Request/ 2920 EAP-Type=PEAP, V=2 2921 (TLS server_hello, 2922 TLS certificate, 2923 [TLS server_key_exchange,] 2924 [TLS certificate_request,] 2925 TLS server_hello_done) 2926 EAP-Response/ 2927 EAP-Type=PEAP, V=2 2928 ([TLS certificate,] 2929 TLS client_key_exchange, 2930 [TLS certificate_verify,] 2931 TLS change_cipher_spec, 2932 TLS finished) -> 2933 <- EAP-Request/ 2934 EAP-Type=PEAP, V=2 2935 (TLS change_cipher_spec, 2936 TLS finished, EAP-TLV 2937 [EAP-Payload-TLV 2938 [EAP-Request/Identity]]) 2940 TLS channel established 2941 (messages sent within the TLS channel) 2943 EAP-TLV [EAP-Payload-TLV 2944 [EAP-Response/Identity (MyID)]] -> 2946 <- EAP-TLV [EAP-Payload-TLV 2947 [EAP-Request/EAP-Type=X]] 2949 EAP-TLV [EAP-Payload 2950 [EAP-Response/EAP-Type=X 2951 or NAK]] -> 2952 <- EAP-TLV [EAP-Payload 2953 [EAP-Request/EAP-Type=X]] 2955 EAP-TLV [EAP-Payload 2956 [EAP-Response/ 2957 EAP-Type=X]] -> 2958 <- EAP-TLV [Crypto-Binding-TLV 2959 (Version=0, Received-Version=2, 2960 Nonce, B1_MAC), 2961 Intermediate-Result-TLV (Failure), 2962 Result TLV (Failure)] 2964 EAP-TLV [Crypto-Binding-TLV 2965 (Version=0, Received-version=2, 2966 Nonce, B2_MAC), 2967 Result TLV (Failure), 2968 Intermediate-Result-TLV (Failure)] 2970 (TLS session cache entry flushed) 2971 TLS channel torn down 2972 (messages sent in cleartext) 2974 <- EAP-Failure 2976 A.6 Server authentication fails in Part 1 2978 In the case where server authentication is unsuccessful in PEAP Part 2979 1, the conversation will appear as follows: 2981 Authenticating Peer Authenticator 2982 ------------------- ------------- 2983 <- EAP-Request/ 2984 Identity 2985 EAP-Response/ 2986 Identity (MyID) -> 2987 <- EAP-Request/ 2988 EAP-Type=PEAP, V=2 2989 (PEAP Start) 2990 EAP-Response/ 2991 EAP-Type=PEAP, V=2 2992 (TLS client_hello)-> 2993 <- EAP-Request/ 2994 EAP-Type=PEAP, V=2 2995 (TLS server_hello, 2996 TLS certificate, 2997 [TLS server_key_exchange,] 2998 TLS server_hello_done) 2999 EAP-Response/ 3000 EAP-Type=PEAP, V=2 3001 (TLS client_key_exchange, 3002 [TLS certificate_verify,] 3003 TLS change_cipher_spec, 3004 TLS finished) -> 3005 <- EAP-Request/ 3006 EAP-Type=PEAP, V=2 3007 (TLS change_cipher_spec, 3008 TLS finished, EAP-TLV 3009 [EAP-Payload-TLV [ 3010 EAP-Request/Identity]]) 3011 EAP-Response/ 3012 EAP-Type=PEAP, V=2 3013 (TLS Alert message) -> 3014 <- EAP-Failure 3015 (TLS session cache entry flushed) 3017 A.7 Session resume success 3019 In the case where a previously established session is being resumed, 3020 the EAP server supports TLS session cache flushing for unsuccessful 3021 PEAPv2 Part 2 authentications and both sides authenticate 3022 successfully, the conversation will appear as follows: 3024 Authenticating Peer Authenticator 3025 ------------------- ------------- 3026 <- EAP-Request/ 3027 Identity 3028 EAP-Response/ 3029 Identity (MyID) -> 3030 <- EAP-Request/ 3031 EAP-Type=PEAP,V=2 3032 (PEAP Start) 3033 EAP-Response/ 3034 EAP-Type=PEAP, V=2 3035 (TLS client_hello)-> 3036 <- EAP-Request/ 3037 EAP-Type=PEAP, V=2 3038 (TLS server_hello, 3039 TLS change_cipher_spec 3040 TLS finished) 3041 EAP-Response/ 3042 EAP-Type=PEAP, V=2 3043 (TLS change_cipher_spec, 3044 TLS finished) -> 3045 <- EAP-Request/ 3046 EAP-Type=EAP-TLV 3047 Result TLV (Success) 3049 // Compound MAC calculated using TLS keys since there were no inner 3050 EAP methods. 3052 EAP-Response/ 3053 EAP-Type=EAP-TLV 3054 Crypto-Binding-TLV=(Version=0, Nonce, B2_MAC), 3055 Result TLV (Success)-> 3056 TLS channel torn down 3057 (messages sent in cleartext) 3059 <- EAP-Success 3061 A.8 Session resume failure 3063 In the case where a previously established session is being resumed, 3064 and the server authenticates to the client successfully but the 3065 client fails to authenticate to the server, the conversation will 3066 appear as follows: 3068 Authenticating Peer Authenticator 3069 ------------------- ------------- 3070 <- EAP-Request/ 3071 Identity 3072 EAP-Response/ 3073 Identity (MyID) -> 3074 <- EAP-Request/ 3075 EAP-Request/ 3076 EAP-Type=PEAP, V=2 3077 (PEAP Start) 3078 EAP-Response/ 3079 EAP-Type=PEAP, V=2 3080 (TLS client_hello) -> 3081 <- EAP-Request/ 3082 EAP-Type=PEAP, V=2 3083 (TLS server_hello, 3084 TLS change_cipher_spec, 3085 TLS finished) 3086 EAP-Response/ 3087 EAP-Type=PEAP, V=2 3088 (TLS change_cipher_spec, 3089 TLS finished) -> 3090 <- EAP-Request 3091 EAP-Type=PEAP, V=2 3092 (TLS Alert message) 3093 EAP-Response 3094 EAP-Type=PEAP, V=2 -> 3095 <- EAP-Failure 3096 (TLS session cache entry flushed) 3098 A.9 Session resume failure 3100 In the case where a previously established session is being resumed, 3101 and the server authentication is unsuccessful, the conversation will 3102 appear as follows: 3104 Authenticating Peer Authenticator 3105 ------------------- ------------- 3106 <- EAP-Request/ 3107 Identity 3108 EAP-Response/ 3109 Identity (MyID) -> 3110 <- EAP-Request/ 3111 EAP-Request/ 3112 EAP-Type=PEAP, V=2 3113 (PEAP Start) 3114 EAP-Response/ 3115 EAP-Type=PEAP, V=2 3116 (TLS client_hello)-> 3117 <- EAP-Request/ 3118 EAP-Type=PEAP, V=2 3119 (TLS server_hello, 3120 TLS change_cipher_spec, 3121 TLS finished) 3122 EAP-Response/ 3123 EAP-Type=PEAP, V=2 3124 (TLS change_cipher_spec, 3125 TLS finished) 3126 <- EAP-Request/ 3127 EAP-Type=PEAP, V=2 3128 EAP-Response/ 3129 EAP-Type=PEAP, V=2 3130 (TLS Alert message) -> 3132 (TLS session cache entry flushed) 3133 <- EAP-Failure 3135 A.10 PEAP version negotiation 3137 In the case where the peer and authenticator have mismatched PEAP 3138 versions (e.g. the peer has a pre-standard implementation with 3139 version 0, and the authenticator has an implementation compliant with 3140 this specification), the conversation will occur as follows: 3142 Authenticating Peer Authenticator 3143 ------------------- ------------- 3144 <- EAP-Request/ 3145 Identity 3146 EAP-Response/ 3147 Identity (MyID) -> 3148 <- EAP-Request/ 3149 EAP-Request/ 3150 EAP-Type=PEAP, V=2 3151 (PEAP Start) 3153 EAP-Response/ 3154 EAP-Type=PEAP, V=0 3155 (TLS client_hello)-> 3156 <- EAP-Request/ 3157 EAP-Type=PEAP, V=0 3158 (TLS server_hello, 3159 TLS change_cipher_spec, 3160 TLS finished) 3162 //conversation continued using pre-standard PEAP version 0 3164 A.11 Sequences of EAP methods 3166 Where PEAPv2 is negotiated, with a sequence of EAP method X followed 3167 by method Y, the conversation will occur as follows: 3169 Authenticating Peer Authenticator 3170 ------------------- ------------- 3171 <- EAP-Request/ 3172 Identity 3173 EAP-Response/ 3174 Identity (MyID1) -> 3175 <- EAP-Request/ 3176 EAP-Type=PEAP, V=2 3177 (PEAP Start, S bit set) 3179 EAP-Response/ 3180 EAP-Type=PEAP, V=2 3181 (TLS client_hello)-> 3182 <- EAP-Request/ 3183 EAP-Type=PEAP, V=2 3184 (TLS server_hello, 3185 TLS certificate, 3186 [TLS server_key_exchange,] 3187 [TLS certificate_request,] 3188 TLS server_hello_done) 3189 EAP-Response/ 3190 EAP-Type=PEAP, V=2 3191 ([TLS certificate,] 3192 TLS client_key_exchange, 3193 [TLS certificate_verify,] 3194 TLS change_cipher_spec, 3195 TLS finished) -> 3196 <- EAP-Request/ 3197 EAP-Type=PEAP, V=2 3198 (TLS change_cipher_spec, 3199 TLS finished, EAP-TLV 3201 [EAP-Payload-TLV[ 3202 EAP-Request/Identity]]) 3204 TLS channel established 3205 (messages sent within the TLS channel) 3207 EAP-TLV [EAP-Payload-TLV 3208 [EAP-Response/Identity]] -> 3210 <- EAP-TLV [EAP-Payload-TLV 3211 [EAP-Request/EAP-Type=X]]] 3213 EAP-TLV [EAP-Payload-TLV 3214 [EAP-Response/EAP-Type=X]] -> 3216 <- EAP-TLV [ EAP-Payload-TLV 3217 [EAP-Request/EAP-Type=X]] 3219 EAP-TLV [EAP-Payload-TLV 3220 [EAP-Response/EAP-Type=X]]-> 3222 <- EAP-TLV [EAP Payload TLV [EAP-Type=Y], 3223 (Intermediate Result TLV (Success), 3224 Crypto-Binding-TLV 3225 (Version=0, Received-version=2, 3226 Nonce, B1_MAC))] 3228 // Next EAP conversation started after successful completion of 3229 previous method X. The intermediate-status and crypto-binding TLVs 3230 are sent in next packet to minimize round-trips. In this example, 3231 identity request is not sent before negotiating EAP-Type=Y. 3233 EAP-TLV [EAP-Payload-TLV [EAP-Type=Y], 3234 (Intermediate Result TLV (Success), 3235 Crypto-Binding-TLV (Version=0, 3236 Received-version=2, Nonce, B2_MAC))]-> 3238 // Compound MAC calculated using Keys generated from 3239 EAP methods X and the TLS tunnel. 3241 <- EAP-TLV [EAP Payload TLV [ 3242 EAP-Type=Y]] 3244 EAP-TLV[EAP Payload TLV 3245 [EAP-Type=Y]] -> 3246 <- EAP-TLV [Result-TLV (Success), 3247 Intermediate Result TLV (Success), 3248 Crypto-Binding-TLV 3249 (Version=0, Received-version=2, 3250 Nonce, B1_MAC))] 3252 EAP-TLV [(Result-TLV (Success), 3253 Intermediate Result TLV (Success), 3254 Crypto-Binding-TLV (Version=0, 3255 Received-version=2, Nonce, B2_MAC))]-> 3257 // Compound MAC calculated using Keys generated from EAP methods X 3258 and Y and the TLS tunnel. // Compound Keys generated using Keys 3259 generated from EAP methods X and Y; and the TLS tunnel. 3261 TLS channel torn down (messages sent in cleartext) 3263 <- EAP-Success 3265 Acknowledgments 3267 Thanks to Hakan Andersson, Jan-Ove Larsson and Magnus Nystrom of RSA 3268 Security; Bernard Aboba, Vivek Kamath, Stephen Bensley and Narendra 3269 Gidwani of Microsoft; Ilan Frenkel and Nancy Cam-Winget of Cisco; 3270 Jose Puthenkulam of Intel for their contributions and critiques. 3272 The compound binding exchange to address man-in-the-middle attack is 3273 based on the draft "The Compound Authentication Binding 3274 Problem"[CompoundBinding]. 3276 The vast majority of the work by Simon Josefsson and Hakan Andersson 3277 was done while they were employed at RSA Laboratories. 3279 Author Addresses 3281 Ashwin Palekar 3282 Microsoft Corporation 3283 One Microsoft Way 3284 Redmond, WA 98052 3286 Phone: +1 425 882 8080 3287 EMail: ashwinp@microsoft.com 3289 Dan Simon 3290 Microsoft Corporation 3291 One Microsoft Way 3292 Redmond, WA 98052 3294 Phone: +1 425 706 6711 3295 EMail: dansimon@microsoft.com 3296 Glen Zorn 3297 Cisco Systems 3298 500 108th Avenue N.E. 3299 Suite 500 3300 Bellevue, Washington 98004 3302 Phone: + 1 425 438 8210 3303 Fax: + 1 425 438 1848 3304 EMail: gwz@cisco.com 3306 Simon Josefsson 3307 Drottningholmsvagen 70 3308 112 42 Stockholm 3309 Sweden 3311 Phone: +46 8 619 04 22 3312 EMail: jas@extundo.com 3314 Hao Zhou 3315 Cisco Systems, Inc. 3316 4125 Highlander Parkway 3317 Richfield, OH 44286 3319 Phone: +1 330 523 2132 3320 Fax: +1 330 523 2239 3321 EMail: hzhou@cisco.com 3323 Joseph Salowey 3324 Cisco Systems 3325 2901 3rd Ave 3326 Seattle, WA 98121 3328 Phone: +1 206 256 3380 3329 EMail: jsalowey@cisco.com 3331 Intellectual Property Statement 3333 The IETF takes no position regarding the validity or scope of any 3334 intellectual property or other rights that might be claimed to 3335 pertain to the implementation or use of the technology described in 3336 this document or the extent to which any license under such rights 3337 might or might not be available; neither does it represent that it 3338 has made any effort to identify any such rights. Information on the 3339 IETF's procedures with respect to rights in standards-track and 3340 standards- related documentation can be found in BCP-11. Copies of 3341 claims of rights made available for publication and any assurances of 3342 licenses to be made available, or the result of an attempt made to 3343 obtain a general license or permission for the use of such 3344 proprietary rights by implementors or users of this specification can 3345 be obtained from the IETF Secretariat. 3347 The IETF invites any interested party to bring to its attention any 3348 copyrights, patents or patent applications, or other proprietary 3349 rights which may cover technology that may be required to practice 3350 this standard. Please address the information to the IETF Executive 3351 Director. 3353 Full Copyright Statement 3355 Copyright (C) The Internet Society (2003). All Rights Reserved. 3357 This document and translations of it may be copied and furnished to 3358 others, and derivative works that comment on or otherwise explain it 3359 or assist in its implementation may be prepared, copied, published 3360 and distributed, in whole or in part, without restriction of any 3361 kind, provided that the above copyright notice and this paragraph are 3362 included on all such copies and derivative works. However, this 3363 document itself may not be modified in any way, such as by removing 3364 the copyright notice or references to the Internet Society or other 3365 Internet organizations, except as needed for the purpose of 3366 developing Internet standards in which case the procedures for 3367 copyrights defined in the Internet Standards process must be 3368 followed, or as required to translate it into languages other than 3369 English. The limited permissions granted above are perpetual and 3370 will not be revoked by the Internet Society or its successors or 3371 assigns. This document and the information contained herein is 3372 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 3373 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 3374 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3378 Expiration Date 3380 This memo is filed as , 3381 and expires April 22, 2004.