idnits 2.17.1 draft-josefsson-pppext-eap-tls-eap-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4014. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 86 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 87 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 487 has weird spacing: '...er, the conve...' == Line 773 has weird spacing: '...root of a ser...' == Line 1297 has weird spacing: '...resence of th...' == Line 1303 has weird spacing: '...ndicate the p...' == Line 2538 has weird spacing: '... server to sk...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == 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 (e.g. TLS alert). == 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 MUST NOT be responded to with a NAK TLV. PEAPv2 implementations MAY NOT support the Vendor TLVs inside in the Vendor-Specific TLV, and can respond to the Vendor TLVs with a NAK TLV containing the appropriate Vendor-ID and Vendor-TLV type. == 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: TLV type 11 is reserved due to use in previous implementations. PEAPv2 implementations MAY NOT support this TLV, which MUST be marked as OPTIONAL. This TLV MUST NOT be responded to 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: The Server-Trusted-Root TLV is always marked as optional, and cannot be responded to with a NAK TLV. PEAPv2 server implementations that claim to support provisioning MUST support Server-Trusted-Root TLV, PKCS#7 TLV, and the PKCS#7-Server-Certificate-Root credential format defined in this TLV. PEAPv2 peer implementations MAY NOT support this 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: The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. PEAPv2 server implementations that claim to support provisioning MUST support this TLV. PEAPv2 peer implementations MAY NOT support this 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: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2955 -- Looks like a reference, but probably isn't: '2' on line 2958 -- Looks like a reference, but probably isn't: '3' on line 2964 -- Looks like a reference, but probably isn't: '4' on line 2968 == Missing Reference: 'RFC2315' is mentioned on line 2314, but not defined -- Looks like a reference, but probably isn't: '5' on line 2972 -- Looks like a reference, but probably isn't: '6' on line 2974 -- Looks like a reference, but probably isn't: '7' on line 2977 == Missing Reference: 'PKLENGTH' is mentioned on line 3024, but not defined == Unused Reference: 'RFC1321' is defined on line 3085, but no explicit reference was found in the text == Unused Reference: 'RFC2373' is defined on line 3094, but no explicit reference was found in the text == Unused Reference: 'RFC2419' is defined on line 3126, but no explicit reference was found in the text == Unused Reference: 'RFC2420' is defined on line 3129, but no explicit reference was found in the text == Unused Reference: 'RFC3078' is defined on line 3142, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 3145, but no explicit reference was found in the text == Unused Reference: 'RFC3766' is defined on line 3158, but no explicit reference was found in the text == Unused Reference: 'FIPSDES' is defined on line 3162, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 3165, but no explicit reference was found in the text == Unused Reference: 'IEEE802.11i' is defined on line 3175, but no explicit reference was found in the text == Unused Reference: 'PEAPv0' is defined on line 3188, but no explicit reference was found in the text == Unused Reference: 'CompoundBinding' is defined on line 3193, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) Summary: 14 errors (**), 0 flaws (~~), 31 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Ashwin Palekar 3 INTERNET-DRAFT Dan Simon 4 Category: Informational Microsoft Corporation 5 Joe Salowey 6 15 October 2004 Hao Zhou 7 Glen Zorn 8 Cisco Systems 9 S. Josefsson 10 Extundo 12 Protected EAP Protocol (PEAP) Version 2 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 22, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society 2004. All rights reserved. 41 Abstract 43 The Extensible Authentication Protocol (EAP) provides support for 44 multiple authentication methods. This document defines the Protected 45 Extensible Authentication Protocol (PEAP) Version 2, which provides 46 an encrypted and authenticated tunnel based on transport layer 47 security (TLS) that encapsulates EAP authentication mechanisms. 48 PEAPv2 uses TLS to protect against rogue authenticators, protect 49 against various attacks on the confidentiality and integrity of the 50 inner EAP method exchange and provide EAP peer identity privacy. 51 PEAPv2 also provides support for chaining multiple EAP mechanisms, 52 cryptographic binding between authentications performed by inner EAP 53 mechanisms and the tunnel, exchange of arbitrary parameters (TLVs), 54 and fragmentation and reassembly. 56 Table of Contents 58 1. Introduction .......................................... 4 59 1.1 Requirements Language .......................... 6 60 1.2 Terminology .................................... 7 61 1.3 Operational Model .............................. 8 62 2. Protocol overview ..................................... 11 63 2.1 PEAPv2 Part 1 .................................. 11 64 2.2 PEAPv2 Part 2 .................................. 15 65 2.3 Error Handling ................................. 21 66 2.4 Fragmentation .................................. 22 67 2.5 Key Derivation ................................. 24 68 2.6 Ciphersuite Negotiation ........................ 26 69 3. PEAPv2 Protocol Description .......................... 27 70 3.1 PEAPv2 Protocol Layers ......................... 27 71 3.2 PEAPv2 Packet Format ........................... 27 72 4. TLVs ................................................. 30 73 4.1 TLV Format ..................................... 30 74 4.2 Result TLV ..................................... 32 75 4.3 NAK TLV ........................................ 32 76 4.4 Error-Code TLV ................................. 34 77 4.5 Crypto-Binding TLV ............................. 34 78 4.6 Connection-Binding TLV ......................... 37 79 4.7 Vendor-Specific TLV ............................ 38 80 4.8 URI TLV ........................................ 39 81 4.9 EAP-Payload TLV ................................ 40 82 4.10 Intermediate-Result TLV ........................ 41 83 4.11 Reserved TLVs .................................. 42 84 4.12 Calling-Station-Id TLV ......................... 42 85 4.13 Called-Station-Id TLV .......................... 44 86 4.14 NAS-Port-Type TLV .............................. 45 87 4.15 Server-Identifier TLV .......................... 46 88 4.16 Identity-Type TLV .............................. 47 89 4.17 Server-Trusted-Root TLV ........................ 48 90 4.18 PKCS#7 TLV ..................................... 50 91 4.19 Request-Action TLV ............................. 51 92 4.20 TLV Rules ...................................... 52 94 5. Security Considerations .............................. 54 95 5.1 Authentication and Integrity Protection ........ 54 96 5.2 Method Negotiation ............................. 55 97 5.3 TLS Session Cache Handling ..................... 55 98 5.4 Certificate Revocation ......................... 56 99 5.5 Separation of EAP Server and Authenticator ..... 57 100 5.6 Separation of PEAPv2 Part 1 and 2 Servers ...... 58 101 5.7 Identity Verification .......................... 59 102 5.8 Man-in-the-Middle Attack Protection ............ 61 103 5.9 Cleartext Forgeries ............................ 62 104 5.10 TLS Ciphersuites ............................... 63 105 5.11 Denial of Service Attacks ...................... 63 106 5.12 Server Unauthenticated Tunnel Provisioning Mode. 63 107 5.13 Security Claims ................................ 65 108 6. IANA Considerations ................................. 66 109 6.1 Definition of Terms ............................ 66 110 6.2 Recommended Registration Policies .............. 66 111 7. References .......................................... 67 112 7.1 Normative References ........................... 67 113 7.2 Informative References ......................... 68 114 Appendix A - Examples ........................................ 70 115 Acknowledgments .............................................. 85 116 Author's Addresses ........................................... 85 117 Intellectual Property Statement .............................. 86 118 Disclaimer of Validity ....................................... 86 119 Full Copyright Statement ..................................... 87 120 1. Introduction 122 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 123 provides support for multiple authentication methods. EAP over PPP, 124 defined in [RFC3748], is typically deployed with leased lines or 125 modem connections. [IEEE8021X] defines EAP over IEEE 802 local area 126 networks (EAPOL). 128 Since its deployment, a number of weaknesses in EAP framework have 129 become apparent. These include lack of support for: 131 Identity protection 132 Protected method negotiation 133 Protected notification messages 134 Protected termination messages 135 Sequences of EAP methods 136 Fragmentation and reassembly 137 Exchange of arbitrary parameters in a secure channel 138 Optimized re-authentication 140 In addition, some EAP methods lack the following features: 142 Mutual authentication 143 Resistance to dictionary attacks 144 Adequate key generation 146 By wrapping the EAP protocol within TLS, Protected EAP (PEAP) Version 147 2 addresses deficiencies in EAP or EAP methods. Benefits of PEAP 148 Version 2 include: 150 Identity protection 151 By encrypting the identity exchange, and allowing client identity 152 to be provided after negotiation of the TLS channel, PEAPv2 153 provides for identity protection. 155 Dictionary attack resistance 156 By conducting the EAP conversation within a TLS channel, PEAPv2 157 protects EAP methods that might be subject to an offline dictionary 158 attack were they to be conducted in the clear. 160 Protected negotiation 161 Since within PEAPv2, the EAP conversation is authenticated, 162 integrity and replay protected on a per-packet basis, the EAP 163 method negotiation that occurs within PEAPv2 is protected, as are 164 error messages sent within the TLS channel (TLS alerts or EAP 165 Notification packets). EAP negotiation outside of PEAPv2 is not 166 protected. 168 Header protection 169 Within PEAPv2, TLS provides per-packet encryption, authentication, 170 integrity and replay protection for the EAP conversation. As a 171 result, the Type-Data field within PEAPv2 (including the EAP header 172 of the EAP method within PEAPv2) is protected against modification. 173 However, the EAP header of PEAPv2 itself is not protected against 174 modification, including the Code, Identifier and Type fields. 176 Protected termination 177 By sending success/failure indications within the TLS channel, 178 PEAPv2 provides support for protected termination of the EAP 179 conversation. This prevents an attacker from carrying out denial 180 of service attacks by spoofing EAP Failure messages, or fooling the 181 EAP peer into accepting a rogue NAS, by spoofing EAP Success 182 messages. 184 Fragmentation and Reassembly 185 Since EAP does not include support for fragmentation and 186 reassembly, individual methods need to include this capability. By 187 including support for fragmentation and reassembly within PEAPv2, 188 methods leveraging PEAPv2 do not need to support this on their own. 190 Fast reconnect 191 Where EAP is used for authentication in wireless networks, the 192 authentication latency is a concern. As a result, it is valuable 193 to be able to do a quick re-authentication on roaming between 194 access points. PEAPv2 supports this capability by leveraging the 195 TLS session resumption facility, and any EAP method running under 196 PEAPv2 can take advantage of it. 198 Standard key establishment 199 In order to provide keying material for a wide range of link layer 200 ciphersuites, EAP methods need to provide keying material. Key 201 derivation is complex. PEAPv2 provides for key establishment by 202 relying on the widely implemented and well-reviewed TLS [RFC2246] 203 key derivation mechanism. PEAPv2 provides keying material for any 204 EAP method running within it. If EAP methods will also be deployed 205 without external protection (e.g PEAPv2 or IPSec), then the EAP 206 methods should follow the guidelines in Section 5.8 to prevent the 207 man-in-the-middle attacks. 209 Sequencing of multiple EAP methods 210 In order to enhance security, PEAPv2 implementations may choose to 211 provide multi-factor authentication that validates different 212 identities (for example user and machine identities) and/or uses 213 different credentials of the same or different identities of the 214 peer (e.g. user password and machine cert). PEAPv2 provides a 215 standard way to chain different types of authentication mechanisms 216 supporting different types of credentials. 218 Protected exchange of arbitrary parameters 219 Type-Length-Value (TLV) tuples provide a way to exchange arbitrary 220 information between peer and EAP server within a secure channel. 221 This information can include signaling parameters for EAP protocol, 222 provisioning parameters, media specific and environment specific 223 data, and authorization parameters. The advantage of using PEAP 224 TLVs is that every EAP method does not have to be modified. 226 Credential provisioning 227 PEAPv2 supports provisioning of certificate trust anchors by the 228 server using TLVs and can be extended to support provisioning of 229 other peer credentials. 231 Optimized for light weight devices 232 In order to support peers that may not support certificate 233 ciphersuites, and may not support provisioning of certificate trust 234 anchors, PEAPv2 enables negotiation of other TLS ciphersuites. 236 Server unauthenticated tunnel provisioning mode 237 In some cases, the peer may only support password credentials and 238 may not be provisioned with a certificate trust anchor. 240 In server unauthenticated tunnel provisioning mode, a PEAPv2 peer 241 can authenticate using a password, in order to be provisioned with 242 a pre-shared key and other credentials that can be used for 243 subsequent authentication. In server unauthenticated tunnel 244 provisioning mode the PEAPv2 peer only confirms possession of the 245 private key corresponding to the public key contained within the 246 server certificate, but does not otherwise validate the server 247 certificate. As a result, it is possible for an attacker to act as 248 a man-in-the-middle during the initial exchange in order to perform 249 an offline dictionary attack, based on capture of the password- 250 based authentication exchange. 252 In PEAPv2, implementation of server unauthenticated tunnel 253 provisioning mode is optional, and due to the security 254 vulnerabilities introduced by this mode, it is not recommended for 255 use with peers that support certificate validation and provisioning 256 of certificate trust anchors. 258 1.1. Requirements Language 260 In this document, the key words "MAY", "MUST, "MUST NOT", 261 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 262 interpreted as described in [RFC2119]. 264 1.2. Terminology 266 This document frequently uses the following terms: 268 Access Point 269 A Network Access Server implementing 802.11. 271 Authenticator 272 The end of the link initiating EAP authentication. This term is 273 also used in [IEEE8021X] and has the same meaning in this document. 275 Backend Authentication Server 276 A backend authentication server is an entity that provides an 277 authentication service to an Authenticator. When used, this server 278 typically executes EAP methods for the Authenticator. This 279 terminology is also used in [IEEE8021X]. 281 EAP server 282 The entity that terminates the EAP authentication method with the 283 peer. In the case where no backend authentication server is used, 284 the EAP server is part of the Authenticator. In the case where the 285 authenticator operates in pass-through mode, the EAP server is 286 located on the backend authentication server. 288 Link layer ciphersuite 289 The ciphersuite negotiated for use at the link layer. 291 NAS Short for "Network Access Server". 293 Peer The end of the link that responds to the authenticator. In 294 [IEEE8021X], this end is known as the Supplicant. 296 TLS Ciphersuite 297 The ciphersuite negotiated for protection of the PEAPv2 Part 2 298 conversation. 300 EAP Master key (MK) 301 A key derived between the PEAPv2 client and server during the 302 authentication conversation, and that is kept local to PEAPv2 and 303 not exported or made available to a third party. 305 Master Session Key (MSK) 306 Keying material that is derived between the EAP peer and server and 307 exported by the EAP method. The MSK is at least 64 octets in 308 length. In existing implementations, a AAA server acting as an EAP 309 server transports the MSK to the authenticator. 311 Extended Master Session Key (EMSK) 312 Additional keying material derived between the EAP client and 313 server that is exported by the EAP method. The EMSK is at least 64 314 octets in length. The EMSK is not shared with the authenticator or 315 any other third party. The EMSK is reserved for future uses that 316 are not defined yet. 318 Type Length Value (TLV) 319 The PEAPv2 protocol utilizes objects in Type Length Value (TLV) 320 format. The TLV format is defined in Section 4 of this document. 322 1.3. Operational Model 324 In EAP, the EAP server may be implemented either within a Network 325 Access Server (NAS) or on a backend authentication server. Where the 326 EAP server resides on a NAS, the NAS is required to implement the 327 desired EAP methods, and therefore needs to be upgraded to support 328 each new EAP method. 330 One of the goals of EAP is to enable development of new 331 authentication methods without requiring deployment of new code on 332 the Network Access Server (NAS). Where a backend authentication 333 server is deployed, the NAS acts as a "passthrough" and need not 334 understand specific EAP methods. 336 This allows new EAP methods to be deployed on the EAP peer and 337 backend authentication server, without the need to upgrade code 338 residing on the NAS. 340 Figure 1 describes the relationship between the EAP peer, NAS and EAP 341 server. As described in the figure, the EAP conversation occurs 342 between the EAP peer and EAP server, "passing through" the NAS. In 343 order for the conversation to proceed in the case where the NAS and 344 EAP server reside on separate machines, the NAS and EAP server need 345 to establish trust beforehand. 347 +-+-+-+-+-+ +-+-+-+-+-+ 348 | | | | 349 | Link | | Link | 350 | Layer | | Layer | 351 | Cipher- | | Cipher- | 352 | Suite | | Suite | 353 | | | | 354 +-+-+-+-+-+ +-+-+-+-+-+ 355 ^ ^ 356 | | 357 | | 358 | | 359 V V 360 +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ 361 | | EAP | |<======>| | 362 | | Conversation | | | | 363 | EAP |<================================>| EAP | 364 | Peer | (over PPP, | NAS | | Server | 365 | | 802.11,etc.) | |<=======| | 366 | | | | Keys | | 367 | | | | | | 368 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 369 ^ ^ 370 | | 371 | EAP API | EAP API 372 | | 373 V V 374 +-+-+-+-+-+ +-+-+-+-+-+ 375 | | | | 376 | | | | 377 | EAP | | EAP | 378 | Method | | Method | 379 | | | | 380 +-+-+-+-+-+ +-+-+-+-+-+ 382 Figure 1 - Relationship between EAP client, backend 383 authentication server and NAS. 385 In PEAPv2, the conversation between the EAP peer and the EAP server 386 is encrypted, authenticated, integrity and replay protected within a 387 TLS channel. 389 As a result, where the NAS acts as a "passthrough" it does not have 390 knowledge of the TLS master secret derived between the peer and the 391 EAP server. In order to provide keying material for link-layer 392 ciphersuites, the NAS obtains the master session key, which is 393 derived from a one-way function of the TLS master secret as well as 394 keying material provided by EAP methods protected within a TLS 395 channel. This enables the NAS and EAP peer to subsequently derive 396 transient session keys suitable for encrypting, authenticating and 397 integrity protecting session data. However, the NAS cannot decrypt 398 the PEAPv2 conversation or spoof session resumption, since this 399 requires knowledge of the TLS master secret. 401 1.3.1. Sequences 403 EAP [RFC3748] prohibits use of multiple authentication methods within 404 a single EAP conversation, except when tunneled methods such as 405 PEAPv2 are used. This restriction was imposed in order to limit 406 vulnerabilities to man-in-the-middle attacks as well as to ensure 407 compatibility with existing EAP implementations. 409 Within PEAP these concerns are addressed since PEAPv2 includes 410 support for cryptographic binding to address man-in-the-middle 411 attacks, as well as version negotiation so as to enable backward 412 compatibility with prior versions of PEAP. 414 Within this document, the term "sequence" refers to a series of EAP 415 authentication methods run in sequence or TLV exchanges before or 416 after EAP methods. The methods need not be distinct - for example, 417 EAP-TLS could be run initially with machine credentials followed by 418 the same protocol authenticating with user credentials. 420 PEAPv2 supports initiating additional EAP method(s) after a 421 successful or a failed EAP method. The result of failure of a EAP 422 method does not always imply a failure of the overall authentication. 423 The overall result of authentication depends on the policy at EAP 424 server and the peer. For example, successful authentication might 425 require a successful machine authentication followed by a successful 426 user authentication. Alternatively, if machine authentication fails, 427 then user authentication can be attempted. PEAP does not support 428 initiating multiple EAP methods simultaneously. 430 2. Protocol Overview 432 Protected EAP (PEAP) Version 2 is comprised of a two-part 433 conversation: 435 [1] In Part 1, a TLS session is negotiated, with server authenticating 436 to the client and optionally the client to the server. The 437 negotiated key is then used to encrypt the rest of the 438 conversation. 440 [2] In Part 2, within the TLS session, zero or more EAP methods are 441 carried out. Part 2 completes with a success/failure indication 442 protected by the TLS session or a protected error (TLS alert). 444 In the next two sections, we provide an overview of each of the parts 445 of the PEAPv2 conversation. 447 2.1. PEAPv2 Part 1 449 2.1.1. Initial identity exchange 451 The PEAP conversation typically begins with an optional identity 452 exchange. The authenticator will typically send an EAP- 453 Request/Identity packet to the peer, and the peer will respond with 454 an EAP-Response/Identity packet to the authenticator. 456 The initial identity exchange is used primarily to route the EAP 457 conversation to the EAP server. Since the initial identity exchange 458 is in the clear, the peer MAY decide to place a routing realm instead 459 of its real name in the EAP-Response/Identity. The real identity of 460 the peer can be established later in PEAPv2 part 2. 462 If the EAP server is known in advance (such as when all users 463 authenticate against the same backend server infrastructure and 464 roaming is not supported), or if the identity is otherwise determined 465 (such as from the dialing phone number or client MAC address), then 466 the EAP-Request/Response-identity exchange MAY be omitted. 468 Once the optional initial Identity Request/Response exchange is 469 completed, while nominally the EAP conversation occurs between the 470 authenticator and the peer, the authenticator MAY act as a 471 passthrough device, with the EAP packets received from the peer being 472 encapsulated for transmission to a backend authentication server. 473 However, PEAP does not require a backend authentication server; if 474 the authenticator implements PEAP, then it can authenticate local 475 users. 477 In the discussion that follows, we will use the term "EAP server" to 478 denote the ultimate endpoint conversing with the peer. 480 2.1.2. TLS Session Establishment 482 In this section, the protocol is described, and in Appendix A, 483 examples of protocol exchanges are provided. While this section and 484 the examples in Appendix A often describe negotiation of a 485 certificate-based ciphersuite within TLS, PEAPv2 supports negotiation 486 of other ciphersuites (for example, ciphersuites that do not use 487 certificates) or extensions. However, the conversation may slightly 488 differ if other TLS ciphersuites or extensions are used. 490 Once having received the peer's Identity, and determined that PEAP 491 authentication is to occur, the EAP server MUST respond with a 492 PEAP/Start packet, which is an EAP-Request packet with EAP-Type=PEAP, 493 the Start (S) bit set, the PEAP version as specified in Section 494 2.1.5, and optionally, the Server-Identifier TLV. 496 Assuming that the peer supports PEAP, the PEAP conversation will then 497 begin, with the peer sending an EAP-Response packet with EAP- 498 Type=PEAP. The Type-Data field of the EAP-Response Packet will 499 encapsulate one or more TLS records containing the TLS handshake 500 messages. As defined in [RFC2246], the TLS handshake is used to 501 negotiate parameters and cryptographic keys and may take several 502 roundtrips between the TLS client and server. 504 The version offered by the TLS client and server MUST be TLS v1.0 or 505 later. PEAPv2 implementations need not necessarily support all TLS 506 ciphersuites listed in [RFC2246]. Not all TLS ciphersuites are 507 supported by available TLS tool kits and licenses may be required in 508 some cases. 510 To ensure interoperability, PEAPv2 peers and servers MUST support the 511 TLS v1.0 [RFC2246] mandatory-to-implement ciphersuite: 513 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 515 In addition, PEAPv2 servers SHOULD support and be able to negotiate 516 all of the following TLS ciphersuites: 518 TLS_RSA_WITH_3DES_EDE_CBC_SHA 519 TLS_RSA_WITH_RC4_128_MD5 520 TLS_RSA_WITH_RC4_128_SHA 521 TLS_RSA_WITH_AES_128_CBC_SHA 523 In addition, PEAPv2 peers SHOULD support at least one of the 524 following TLS ciphersuites: 526 TLS_RSA_WITH_3DES_EDE_CBC_SHA 527 TLS_RSA_WITH_RC4_128_MD5 528 TLS_RSA_WITH_RC4_128_SHA 529 TLS_RSA_WITH_AES_128_CBC_SHA 531 TLS as described in [RFC2246] supports compression as well as 532 ciphersuite negotiation. Therefore during the PEAPv2 Part 1 533 conversation the PEAPv2 endpoints MAY request or negotiate TLS 534 compression. 536 If the full TLS handshake is performed, then the first payload of 537 PEAPv2 part 2 MAY be sent along with finished handshake message to 538 reduce number of round trips. 540 Since after the TLS session is established, another complete EAP 541 negotiation will occur and the peer will authenticate using a 542 secondary mechanism, with PEAPv2 the client need not authenticate as 543 part of TLS session establishment. 545 Note that since TLS client certificates are sent in the clear, if 546 identity protection is required, then it is possible for the TLS 547 authentication to be re-negotiated after the first server 548 authentication. Alternatively, if identity protection is required, 549 then it is possible to perform certificate authentication using a EAP 550 method (for example: EAP-TLS) within the TLS session in PEAPv2 part 551 2. 553 To accomplish this, the server will typically not request a 554 certificate in the server_hello, then after the server_finished 555 message is sent, and before PEAP part 2, the server MAY send a TLS 556 hello_request. This allows the client to perform client 557 authentication by sending a client_hello if it wants to, or send a 558 no_renegotiation alert to the server indicating that it wants to 559 continue with PEAP part 2 instead. Assuming that the client permits 560 renegotiation by sending a client_hello, then the server will respond 561 with server_hello, a certificate and certificate_request messages. 562 The client replies with certificate, client_key_exchange and 563 certificate_verify messages. Since this re-negotiation occurs within 564 the encrypted TLS channel, it does not reveal client certificate 565 details. 567 2.1.3. Session Resumption 569 The purpose of the sessionId within the TLS protocol and the Server- 570 Identifier TLV in PEAP is to allow for improved efficiency in the 571 case where a client repeatedly attempts to authenticate to an EAP 572 server within a short period of time. This capability is 573 particularly useful for support of wireless roaming. 575 In order to help the peer choose a sessionID that belongs to the 576 specific server, the EAP server MAY send an identifier (Server- 577 Identifier TLV) that the peer can use as a hint. The Server- 578 Identifier TLV MAY be sent in the first PEAP packet from the EAP 579 server to the peer. In order to detect modification of the Server- 580 Identifier TLV, the Server-Identifier TLV is included in calculation 581 of the compound MAC. 583 It is left up to the peer whether to attempt to continue a previous 584 session, thus shortening the PEAP Part 1 conversation. Typically the 585 peer's decision will be made based on the time elapsed since the 586 previous authentication attempt to that EAP server. 588 Based on the sessionId chosen by the peer, and the time elapsed since 589 the previous authentication, the EAP server will decide whether to 590 allow the continuation, or whether to choose a new session. 592 If the EAP server is resuming a previously established session, then 593 it MUST include only a TLS change_cipher_spec message and a TLS 594 finished handshake message after the server_hello message. The 595 finished message contains the EAP server's authentication response to 596 the peer. 598 If the preceding server_hello message sent by the EAP server in the 599 preceding EAP-Request packet indicated the resumption of a previous 600 session, then the peer MUST send only the change_cipher_spec and 601 finished handshake messages. The finished message contains the 602 peer's authentication response to the EAP server. The latter contains 603 the EAP server's authentication response to the peer. The peer will 604 verify the hash in order to authenticate the EAP server. 606 If authentication fails, then the peer and EAP-server MUST follow the 607 error handling behavior specified in section 2.3. 609 Even if the session is successfully resumed with the same EAP server, 610 the peer and EAP server MUST NOT assume that either will skip inner 611 EAP methods. The peer may have roamed to a network which may use the 612 same EAP server, but may require conformance with a different 613 authentication policy, and therefore may require inner EAP 614 authentication methods. 616 2.1.4. Version Negotiation 618 PEAP packets contain a three bit version field, which enables PEAP 619 implementations to be backward compatible with previous versions of 620 the protocol. This specification documents the PEAP version 2 621 protocol; implementations of this specification MUST use a version 622 field set to 2. Version negotiation proceeds as follows: 624 [1] In the first EAP-Request sent with EAP-Type=PEAP, the EAP server 625 MUST set the version field to the highest supported version number. 627 [2] If the EAP peer supports this version of the protocol, it MUST 628 respond with an EAP-Response of EAP-Type=PEAP, and the version 629 number proposed by the EAP server. 631 [3] If the EAP peer does not support this version, it responds with an 632 EAP-Response of EAP-Type=PEAP and the highest supported version 633 number. 635 [4] If the PEAP server does not support the version number proposed by 636 the PEAP peer, it either starts a different EAP type or terminates 637 the conversation by sending an EAP-Failure, depending on the server 638 policy. 640 The version negotiation procedure guarantees that the EAP peer and 641 server will agree to the latest version supported by both parties. 642 If version negotiation fails, then use of PEAP will not be possible, 643 and another mutually acceptable EAP method will need to be negotiated 644 if authentication is to proceed. 646 The PEAP version field is not protected by TLS and therefore can be 647 modified in transit. In order to detect modification of the PEAP 648 version which could occur as part of a "downgrade" attack, the peer 649 and EAP server check if the version it sent during negotiation is 650 same as the version claimed to be received by the other party. Each 651 party uses the Crypto-Binding TLV to inform the other party of the 652 version number it received during the PEAP version negotiation. The 653 receiver of the Crypto-Binding TLV must verify that the version in 654 the Crypto-Binding TLV matches the version it sent during PEAP 655 version negotiation. 657 2.2. PEAPv2 Part 2 659 The second portion of the PEAPv2 conversation typically consists of a 660 complete EAP conversation occurring within the TLS session negotiated 661 in PEAPv2 Part 1, ending with protected termination using the Result 662 TLV. PEAPv2 part 2 will occur only if establishment of a new TLS 663 session in Part 1 is successful or a TLS session is successfully 664 resumed in Part 1. In cases where a new TLS session is established 665 in PEAPv2 part 1, the first payload of the part 2 conversation MAY be 666 sent by the EAP server along with the finished message to save a 667 round-trip. 669 Part 2 SHOULD NOT occur if the EAP Server authenticates 670 unsuccessfully, and MUST NOT occur if establishment of the TLS 671 session in part 1 was not successful Or a TLS fatal error has been 672 sent terminating the conversation. 674 Since all packets sent within the PEAPv2 Part 2 conversation occur 675 after TLS session establishment, they are protected using the 676 negotiated TLS ciphersuite. All EAP packets of the EAP conversation 677 in part 2 including the EAP header of the inner EAP method are 678 protected using the negotiated TLS ciphersuite. 680 Part 2 MAY NOT always include a EAP conversation within the TLS 681 session, referred to in this document as inner EAP methods. However, 682 Part 2 MUST always end with either protected termination or protected 683 error termination (e.g. TLS alert). 685 Within Part 2, protected EAP conversation and protected termination 686 packets are always carried within TLVs. There are TLVs defined for 687 specific purposes such as carrying EAP-authentication messages and 688 carrying cryptographic binding. New TLVs may be developed for other 689 purposes. 691 2.2.1. Protected Conversation 693 Part 2 of the PEAPv2 conversation typically begins with the EAP 694 server sending an optional EAP-Request/Identity packet to the peer, 695 protected by the TLS ciphersuite negotiated in PEAPv2 Part 1. The 696 peer responds with an EAP-Response/Identity packet to the EAP server, 697 containing the peer's userId. Since this Identity Request/Response 698 exchange is protected by the ciphersuite negotiated in TLS, it is not 699 vulnerable to snooping or packet modification attacks. 701 After the TLS session-protected Identity exchange, the EAP server 702 will then select authentication method(s) for the peer, and will send 703 an EAP-Request with the Type field set to the initial method. As 704 described in [RFC3748], the peer can NAK the suggested EAP method, 705 suggesting an alternative. Since the NAK will be sent within the TLS 706 channel, it is protected from snooping or packet modification. As a 707 result, an attacker snooping on the exchange will be unable to inject 708 NAKs in order to "negotiate down" the authentication method. An 709 attacker will also not be able to determine which EAP method was 710 negotiated. 712 The EAP conversation within the TLS protected session may involve a 713 sequence of zero or more EAP authentication methods; it completes 714 with the protected termination described in Section 2.2.2. Several 715 TLVs may be included in each Request and Response. EAP methods are 716 always encapsulated within EAP Payload-TLV. 718 In a typical EAP conversation, the result of the conversation is 719 communicated by sending EAP Success or EAP Failure packets after the 720 EAP method is complete. The EAP Success or Failure packet is 721 considered the last packet of the EAP conversation; and therefore 722 cannot be used when sequences need to be supported. Hence, instead 723 of using the EAP-success or EAP-failure packet, both peer and EAP 724 server MUST use the Intermediate Result TLV to communicate the 725 result. 727 In a typical EAP conversation, the EAP Success or EAP Failure is 728 considered the last packet of the EAP conversation. Within PEAPv2, 729 the EAP server can start another EAP method after success or failure 730 of the previous EAP method inside the protected session. 732 In a sequence of more than one EAP authentication method, to make 733 sure the same parties are involved in tunnel establishment and 734 successful completion of previous inner EAP methods, before 735 completing negotiation of the next EAP method, both peer and EAP 736 server MUST use crypto binding (Crypto-Binding TLV). 738 The Intermediate-Result TLV is used to indicate the result of a 739 individual successful EAP method, and the Result TLV is used to 740 indicate result of the entire PEAP conversation. 742 The Intermediate-Result TLV and Crypto-Binding TLV MUST be sent after 743 each EAP method that was successful. If the EAP method failed, or if 744 the EAP method negotiation did not complete, then an Intermediate- 745 Result TLV MAY be included, and the Crypto-Binding TLV MUST NOT be 746 included. An exception is that the Crypto-Binding TLV MUST be sent 747 along with a protected success/failure indication as described in 748 Section 2.2.2. 750 If these TLVs are not sent after a successful EAP method, it should 751 be considered a tunnel compromise error by peer and EAP server, 752 resulting in terminating the conversation as described in Section 753 2.3. 755 A subsequent EAP conversation can be started after both TLVs are 756 exchanged in a TLV packet. Alternatively, if a subsequent EAP 757 conversation is being attempted, then in order to reduce round trips, 758 both TLVs SHOULD be sent with the EAP-Payload of the first EAP packet 759 of the next EAP conversation (for example, EAP- Identity or EAP- 760 packet of the EAP method). Alternatively, if the next packet is the 761 protected success/failure packet, then in order to reduce round 762 trips, both TLVs MUST be sent with the protected success/failure 763 packet. 765 If the EAP server sends a valid Crypto-Binding TLV to the peer, the 766 peer MUST respond with a Crypto-Binding TLV. If the Crypto-Binding 767 TLV is invalid, it should be considered a tunnel compromise error by 768 the peer. If the peer does not respond with a TLV packet containing 769 the Crypto-Binding TLV, it MUST be considered a tunnel compromise 770 error by the EAP server. 772 Within a PEAPv2 part 2 conversation, a peer MAY request the trusted 773 root of a server certificate using a Server-Trusted-Root TLV, and 774 the EAP server MAY respond with a Server-Trusted-Root TLV to the 775 peer. The Server-Trusted-Root can be exchanged in regular 776 authentication mode or server unauthenticated tunnel provisioning 777 mode. 779 After the peer has determined that it has successfully authenticated 780 the EAP server and determined that the tunnel and inner EAP methods 781 were between the same peer and EAP server by validating the Crypto- 782 Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked 783 as optional) to request the trusted root of server certificate from 784 the EAP server. The peer may receive a response, but is not required 785 to use the trusted root received from the EAP server. 787 If the EAP server has determined that it has successfully 788 authenticated the peer and determined that the tunnel and inner EAP 789 methods were between the same peer and EAP server by validating the 790 Crypto-Binding TLV, then it MAY respond with the the server-trusted- 791 root containing the PCKS#7 TLV. 793 2.2.2. Protected Termination 795 The PEAPv2 part 2 conversation is completed by exchanges of 796 success/failure indications (Result TLV) within a TLV packet 797 protected by the TLS session. 799 Even if Crypto-Binding TLVs have been exchanged in previous 800 conversations, the Crypto-Binding TLV MUST be included in both 801 protected success/failure (Result TLV) indications. If the TLVs are 802 not included, or if the TLVs are invalid, it should be considered a 803 tunnel compromise error, and the peer and EAP server MUST follow the 804 rules described in Section 2.3 to abort the conversation. 806 The Result TLV is sent within the TLS channel. The PEAP client then 807 replies with a Result TLV. The conversation concludes with the PEAP 808 server sending a cleartext success/failure indication. 810 The only outcome which should be considered as successful 811 authentication is when a Result TLV of Status=Success is answered by 812 the peer with a Result TLV of Status=Success. 814 The combinations (Result TLV=Failure, Result TLV=Success), (Result 815 TLV=Failure, Result TLV=Failure), (no TLVs exchange or no protected 816 success or failure) should be considered an authentication failure by 817 both the peer and EAP server. Once the peer and EAP server consider 818 that authentiation has failed, these are the last packets inside the 819 protected tunnel. These combinations are considered an 820 authentication failure regardless of whether a cleartext EAP Success 821 or EAP Failure packet is subsequently sent. 823 If the EAP server wants authentication to fail, it sends the TLV 824 response with Result TLV=Failure. If the EAP server sends a failure, 825 the peer MUST respond with Result TLV=Failure and the Crypto-Binding 826 TLV, without any other mandatory TLVs. The Crypto-Binding TLV is 827 calculated using the key derivation formula in Section 2.5; if for 828 some reason one or more inner EAP method MSKs were not derived, then 829 these MSKs are assumed to be null. 831 If the EAP server has sent the success indication (Result 832 TLV=Success), the peer is allowed to refuse to accept a Success 833 message from the EAP server since the client's policy may require 834 completion of certain EAP methods or the client may require 835 credentials. 837 If the EAP server has sent a success indication (Result TLV=success), 838 and the peer wants authentication to fail, it sends the TLV response 839 with Result TLV=Failure and Crypto-Binding TLV. 841 After the EAP-server returns success, if the peer wants to request 842 the EAP server to continue conversation, it sends a Result 843 TLV=Success along with a Request-Action TLV with the appropriate 844 action (e.g. Negotiate-EAP, or Process-TLV). If the Request-Action 845 TLV is set to mandatory, then the EAP server MUST process the action, 846 or return status=failure, closing the conversation inside the tunnel. 847 If the Request-Action TLV is set to optional, then the EAP server can 848 ignore the TLV and return Result TLV=Success again, closing the 849 conversation inside the tunnel. 851 2.2.3. Provisioning of Credentials 853 PEAPv2 supports built-in provisioning of certificate trust anchors 854 and can be extended to provisioning of other types of credentials. 855 The following two provisioning modes are suported: 857 [a] Provisioning inside a server authenticated TLS tunnel. 859 After regular authentication in PEAP part 2, the peer and EAP 860 server can use the Server-Trusted-Root TLV to request and provision 861 peer credentials. The provisioning payload is exchanged after the 862 peer and EAP server have determined that both have successfully 863 authenticated each other (either thru TLS handshake and/or inner 864 EAP method), and the tunnel and inner EAP methods are between the 865 same peers. 867 After the peer has determined that it has successfully 868 authenticated the EAP server and determined that the tunnel and 869 inner EAP methods were between the same peer and EAP server by 870 validating the Crypto-Binding TLV, it MAY send one or more Server- 871 Trusted-Root TLVs (marked as optional) to request credentials from 872 the EAP server. The EAP server will send corresponding credentials 873 in the Server-Trusted-Root TLVs if its internal policy has been 874 satisfied. It may ignore the credential provisioning request or 875 request additional authentication methods if its policy dictates. 876 The peer may receive a credential, but is not required to use the 877 credentials received from the EAP server. 879 [b] Provisioning inside a server unauthenticated TLS tunnel. 881 In some cases, peer lacks the credentials to authenticate the 882 server in the TLS handshake. At the same time, bootstrapping the 883 information to the peer out of band may be prohibitive from a 884 deployment cost perspective. It can rely on the inner EAP method 885 using existing credentials to authenticate the server. This 886 provisioning mode provides ease of deployment at the cost of 887 introducing man-in-the-middle vulnerabilities. As a result, 888 implementation of the server unauthenticated tunnel provisioning 889 mode is OPTIONAL. 891 In this provisioning mode, as part of PEAPv2 part 1, if the peer 892 does not authenticate, or does not successfully authenticate the 893 EAP server during TLS negotiation, it can decide to go into server 894 unauthenticated tunnel provisioning mode. While this section 895 describes negotiation of a certificate-based ciphersuite within 896 TLS, PEAPv2 supports negotiation of other ciphersuites (for 897 example, ciphersuites that do not use certificates such as 898 anonymous DH) or extensions. However, the conversation may 899 slightly differ if other TLS ciphersuites or extensions are used. 900 For example, in a certificate based TLS handshake, the peer 901 verifies that the EAP server possesses the private key 902 corresponding to the public key contained in the certificate 903 presented by the EAP server. However, the peer does not verify 904 whether the certificate presented by the server chains to a 905 provisioned trust anchor, as the peer may not be configured with a 906 certificate trust anchor required to validate the server 907 certificate. If the peer cannot verify that the server possesses 908 the corresponding private key, or if the certificate presented by 909 the server is unacceptable for any reason other than the lack of an 910 appropriate trust anchor, the peer MUST NOT use this provisioning 911 mode. Assuming that the server demonstrates possession of the 912 private key, the peer continues with establishment of the tunnel 913 (PEAPv2 part 2). As a result, it is possible that the TLS channel 914 (PEAPv2 part 2) may be terminated by an attacker. 916 The PEAPv2 Part 2 conversation is unchanged in this mode, except 917 that the peer will only accept an EAP method supporting mutual 918 authentication and key derivation that is compatible with its 919 initial credentials (such as a password-based EAP method). The 920 peer then uses the Crypto-Binding TLV to validate that the same 921 server terminates both the TLS channel and the successfully 922 completed EAP method, thereby verifying that the exchange was not 923 subject to a man-in-the-middle attack. Assuming that the Crypto- 924 Binding TLV exchange is successful, the peer will request and the 925 server will subsequently provide a trusted root, using the Server- 926 Trusted-Root TLV. 928 Once the initial provisioning exchange completes, the peer is 929 expected to use the provisioned credentials in subsequent PEAPv2 930 authentications, and SHOULD NOT use this provisioning mode. 932 PEAPv2 servers implementing this provisioning mode MUST support the 933 following additional ciphersuites, beyond those specified in 934 Section 2.1.2: 936 TLS_DH_anon_WITH_AES_128_CBC_SHA 938 PEAPv2 peers implementing this provisioning mode MAY support the 939 following additional ciphersuites, beyond those specified in 940 Section 2.1.2: 942 TLS_DH_anon_WITH_AES_128_CBC_SHA 944 2.3. Error Handling 946 PEAPv2 does not have its own error message capabilities since: 948 [1] Errors in TLS layer are communicated via TLS alert messages. 950 [2] Errors within the EAP conversation in PEAPv2 Part 2 are expected to 951 be handled by individual EAP methods. 953 [3] Violation of the TLV rules for inner-TLVs are handled using Result- 954 TLVs together with the Error-Code TLV. 956 If an error occurs at any point in the TLS layer, the EAP server 957 SHOULD send a TLS alert message instead of the next EAP-request 958 packet to the peer. The EAP server SHOULD send an EAP-Request packet 959 with EAP-Type=PEAP, encapsulating a TLS record containing the 960 appropriate TLS alert message. The EAP server SHOULD send a TLS 961 alert message rather than immediately terminating the conversation so 962 as to allow the peer to inform the user of the cause of the failure 963 and possibly allow for a restart of the conversation. To ensure that 964 the peer receives the TLS alert message, the EAP server MUST wait for 965 the peer to reply with an EAP-Response packet. 967 The EAP-Response packet sent by the peer MAY encapsulate a TLS 968 client_hello handshake message, in which case the EAP server MAY 969 allow the PEAPv2 conversation to be restarted, or it MAY contain an 970 EAP-Response packet with EAP-Type=PEAP and no data, in which case the 971 PEAPv2 server MUST send an EAP-Failure packet, and terminate the 972 conversation. 974 It is up to the EAP server whether to allow restarts, and if so, how 975 many times the conversation can be restarted. An EAP server 976 implementing restart capability SHOULD impose a limit on the number 977 of restarts, so as to protect against denial of service attacks. 979 If an error occurs at any point in the TLS layer, the peer SHOULD 980 send a TLS alert message instead of the next EAP-response packet to 981 the EAP server. The peer SHOULD send an EAP-Response packet with 982 EAP-Type=PEAP, encapsulating a TLS record containing the appropriate 983 TLS alert message. The EAP server may restart the conversation by 984 sending a EAP-Request packet encapsulating the TLS 985 hello_request_handshake message, in which case the peer MAY allow the 986 PEAPv2 conversation to be restarted; or the EAP server can response 987 with EAP Failure. 989 Any time the peer or the EAP server finds an error when processing 990 the sequence of exchanges, such as a violation of TLV rules, it 991 should send a Result TLV of failure and Error-Code 992 TLV=Unexpected_TLVs_Exchanged (a Fatal error), and terminate the 993 tunnel. This is usually due to an implementation problem and is 994 considered an fatal error. The party that receives the Error-Code 995 TLV=Unexpected_TLVs_Exchanged should terminate the tunnel. 997 If a tunnel compromise error (see Section 2.2) is detected by the 998 Peer or EAP server, the party SHOULD send a Result TLV of failure 999 without a Crypto-Binding TLV, and Error-Code TLV=Tunnel-compromise- 1000 error (a Fatal error), and terminate the tunnel. The party that 1001 receives the Error-Code TLV=Tunnel-compromise error should terminate 1002 the tunnel. 1004 2.4. Fragmentation 1006 A single TLS record may be up to 16384 octets in length, but a TLS 1007 message may span multiple TLS records, and a TLS certificate message 1008 may in principle be as long as 16MB. 1010 The group of PEAPv2 messages sent in a single round may thus be 1011 larger than the PPP MTU size, the maximum RADIUS packet size of 4096 1012 octets, or even the Multilink Maximum Received Reconstructed Unit 1013 (MRRU). 1015 As described in [RFC1990], the multilink MRRU is negotiated via the 1016 Multilink MRRU LCP option, which includes an MRRU length field of two 1017 octets, and thus can support MRRUs as large as 64 KB. 1019 However, note that in order to protect against reassembly lockup and 1020 denial of service attacks, it may be desirable for an implementation 1021 to set a maximum size for one such group of TLS messages. Since a 1022 typical certificate chain is rarely longer than a few thousand 1023 octets, and no other field is likely to be anywhere near as long, a 1024 reasonable choice of maximum acceptable message length might be 64 1025 KB. 1027 If this value is chosen, then fragmentation can be handled via the 1028 multilink PPP fragmentation mechanisms described in [RFC1990]. While 1029 this is desirable, EAP methods are used in other applications such as 1030 [IEEE80211] and there may be cases in which multilink or the MRRU LCP 1031 option cannot be negotiated. As a result, a PEAPv2 implementation 1032 MUST provide its own support for fragmentation and reassembly. 1034 Since EAP is an ACK-NAK protocol, fragmentation support can be added 1035 in a simple manner. In EAP, fragments that are lost or damaged in 1036 transit will be retransmitted, and since sequencing information is 1037 provided by the Identifier field in EAP, there is no need for a 1038 fragment offset field as is provided in IPv4. 1040 PEAPv2 fragmentation support is provided through addition of flag 1041 bits within the EAP-Response and EAP-Request packets, as well as a 1042 TLV Message Length field of four octets. Flags include the Length 1043 included (L), More fragments (M), and PEAP Start (S) bits. The L 1044 flag is set to indicate the presence of the four octet TLV Message 1045 Length field, and MUST be set only for the first fragment of a 1046 fragmented TLV message or set of messages. 1048 The TLV Message Length field in the PEAPv2 header is not protected, 1049 and hence can be modified by a attacker. The TLS record length in 1050 the TLS data is protected. Hence, if the TLV Message length received 1051 in the first packet (with L bit set) is greater or less than the 1052 total size of TLS messages received including multiple fragments, 1053 then the TLV message length should be ignored. 1055 In order to protect against reassembly lockup and denial of service 1056 attacks, it may be desirable for an implementation to set a maximum 1057 size for one group of Outer-TLV messages. Since a typical 1058 certificate chain is rarely longer than a few thousand octets, and no 1059 other field is likely to be anywhere near as long, a reasonable 1060 choice of maximum acceptable message length for all the Outer-TLVs in 1061 a group of messages might be 64 KB. 1063 The M flag is set on all but the last fragment. The S flag is set 1064 only within the PEAP start message sent from the EAP server to the 1065 peer. The TLV Message Length field is four octets, and provides the 1066 total length of the TLV message or set of messages that is being 1067 fragmented; this simplifies buffer allocation. 1069 When a peer receives an EAP-Request packet with the M bit set, it 1070 MUST respond with an EAP-Response with EAP-Type=PEAP and no data. 1071 This serves as a fragment ACK. The EAP server MUST wait until it 1072 receives the EAP-Response before sending another fragment. In order 1073 to prevent errors in processing of fragments, the EAP server MUST 1074 increment the Identifier field for each fragment contained within an 1075 EAP-Request, and the peer MUST include this Identifier value in the 1076 fragment ACK contained within the EAP-Response. Retransmitted 1077 fragments will contain the same Identifier value. 1079 Similarly, when the EAP server receives an EAP-Response with the M 1080 bit set, it MUST respond with an EAP-Request with EAP-Type=PEAP and 1081 no TLS data. This serves as a fragment ACK. The EAP peer MUST wait 1082 until it receives the EAP-Request before sending another fragment. 1083 In order to prevent errors in the processing of fragments, the EAP 1084 server MUST increment the Identifier value for each fragment ACK 1085 contained within an EAP-Request, and the peer MUST include this 1086 Identifier value in the subsequent fragment contained within an EAP- 1087 Response. 1089 2.5. Key Derivation 1091 Since the normal TLS keys are used in the handshake, and therefore 1092 should not be used in a different context, new keys must be derived 1093 from the TLS master secret to protect the conversation within the 1094 PEAPv2 tunnel. 1096 Instead of deriving keys specific to link layer ciphersuites, EAP 1097 methods provides a Master Session Key (MSK) used to derive keys in a 1098 link layer specific manner. The method used to extract ciphering 1099 keys from the MSK is beyond the scope of this document. 1101 PEAPv2 also derives an Extended Master Session Key (EMSK) which is 1102 reserved for use in deriving keys in other ciphering applications. 1103 This draft also does not discuss the format of the attributes used to 1104 communicate the master session keys from the backend authentication 1105 server to the NAS; examples of such attributes are provided in 1106 [RFC2548]. 1108 PEAPv2 combines key material from the TLS exchange with key material 1109 from inner key generating EAP methods to provide stronger keys and to 1110 bind inner authentication mechanisms to the TLS tunnel. Both the 1111 peer and EAP server MUST derive compound MAC and compound session 1112 keys using the procedure described below. 1114 The input for the cryptographic binding includes the following: 1116 [a] The PEAPv2 tunnel key (TK) is calculated using the first 40 octets 1117 of the (secret) key material generated as described in the EAP-TLS 1118 algorithm ([RFC2716] Section 3.5). More explicitly, the TK is the 1119 first 40 octets of the PRF as defined in [RFC2716]: 1121 PRF(master secret,"client EAP encryption", random) 1123 Where random is the concatenation of client_hello.random and 1124 server_hello.random 1126 [b] The first 32 octets of the MSK provided by each successful inner 1127 EAP method ;for each successful EAP method completed within the 1128 tunnel. 1130 ISK1..ISKn are the MSK portion of the EAP keying material obtained 1131 from methods 1 to n. The ISKj shall be the first 32 octets of the 1132 generated MSK of the jth EAP method. If the MSK length is less than 1133 32 octets, it shall be padded with 0x00's to ensure the MSK is 32 1134 octets. Similarly, if no keying material is provided for the EAP 1135 method, then ISKj shall be set to zero (e.g. 32 octets of 0x00). 1137 The PRF algorithm is based on PRF+ from IKEv2 shown below ("|" 1138 denotes concatenation) 1140 K = Key, S = Seed, LEN = output length, represented as binary 1141 in a single octet. 1143 PRF (K,S,LEN) = T1 | T2 | T3 | T4 | ... where: 1145 T1 = HMAC-SHA1(K, S | LEN | 0x01) 1146 T2 = HMAC-SHA1 (K, T1 | S | LEN | 0x02) 1147 T3 = HMAC-SHA1 (K, T2 | S | LEN | 0x03) 1148 T4 = HMAC-SHA1 (K, T3 | S | LEN | 0x04) 1149 ... 1151 The intermediate combined key is generated after each successful EAP 1152 method inside the tunnel. 1154 Generating the intermediate combined key: 1156 S-IPMK0 = TK 1157 for j = 1 to k do 1159 IPMKj = PRF+(S-IPMK(j-1),"Inner Methods Compound Keys " | ISKj, 60); 1160 Where S-IPMKj are the first 40 octets of IPMKj 1161 and CMKj are the last 20 octets of IPMKj used to generate 1162 the intermediate Compound MACs 1164 k = the last successful EAP method inside the tunnel at the point 1165 where the combined MAC key is derived. 1167 Each IPMKj output is 60 octets. The first 40 octets are used as the 1168 key input to the succeeding IPMK(j+1) derivation and the latter 20 1169 octets are used as the key, CMKj, used to generate the intermediate 1170 Crypto-Binding Compound MAC value at the jth EAP method. 1172 Compound Session Key derivation: 1174 The compound session key (CSK) is derived on both the peer and EAP 1175 server. 1177 CSK = PRF+(S-IPMKn, "Session Key Generating Function", OutputLength) 1179 The output length of the CSK must be at least 128 bytes. The first 64 1180 octets are taken and the MSK and the second 64 octets are taken as 1181 the EMSK. The MSK and EMSK are described in [RFC3748]. 1183 2.6. Ciphersuite Negotiation 1185 Since TLS supports TLS ciphersuite negotiation, peers completing the 1186 TLS negotiation will also have selected a TLS ciphersuite, which 1187 includes key strength, encryption and hashing methods. However, 1188 unlike in [RFC2716], within PEAPv2, the negotiated TLS ciphersuite 1189 relates only to the mechanism by which the PEAPv2 Part 2 conversation 1190 will be protected, and has no relationship to link layer security 1191 mechanisms negotiated within the PPP Encryption Control Protocol 1192 (ECP) [RFC1968] or within IEEE 802.11 [IEEE80211]. 1194 As a result, this specification currently does not support secure 1195 negotiation of link layer ciphersuites. 1197 3. PEAPv2 Protocol Description 1199 3.1. PEAPv2 Protocol Layers 1201 PEAPv2 packets may include TLVs both inside and outside the TLS 1202 tunnel. The term "Outer TLVs" is used to refer to optional TLVs 1203 outside the TLS tunnel, which are only allowed in the first two 1204 messages in the PEAPv2 protocol. That is the first EAP server to 1205 peer message and first peer to EAP server message. If the message is 1206 fragmented, the whole set of messages is counted as one message. The 1207 term "Inner TLVs" is used to refer to TLVs sent within the TLS 1208 tunnel. 1210 In PEAPv2 Part 1, Outer TLVs are used to help establishing the TLS 1211 tunnel, but no Inner TLVs are used. Therefore the layering of PEAPv2 1212 Part 1 is as follows: 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | TLS | Optional Outer TLVs | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | PEAP | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | EAP | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 In PEAPv2 Part 2, TLS records may encapsulate zero or more Inner 1223 TLVs, but no Outer TLVs. EAP packets (including EAP header fields) 1224 used within tunneled EAP authentication methods are carried within 1225 Inner TLVs. Therefore the layering of PEAPv2 Part 2 is as follows: 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | EAP | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Inner-TLVs (EAP-Payload TLV) | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | TLS | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | PEAP | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | EAP | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 3.2. PEAPv2 Packet Format 1241 A summary of the PEAPv2 packet format is shown below. The fields are 1242 transmitted from left to right. 1244 0 1 2 3 1245 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 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Code | Identifier | Length | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Type | Flags | Ver | Fragment Message Length 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Fragment Message Length | TLS Message Length 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | TLS Message Length | TLS Data... 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Outer TLVs... 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 Code 1260 1 - Request 1261 2 - Response 1263 Identifier 1265 The Identifier field is one octet and aids in matching responses 1266 with requests. The Identifier field MUST be changed on each 1267 Request packet. The Identifier field in a Response packet MUST 1268 match the Identifier field from the corresponding Request. 1270 Length 1272 The Length field is two octets and indicates the length of the EAP 1273 packet including the Code, Identifier, Length, Type, Flags, 1274 Version, Fragmented Length, TLS Message Length, TLS Data, and 1275 Outer-TLV fields. Octets outside the range of the Length field 1276 should be treated as Data Link Layer padding and should be ignored 1277 on reception. 1279 Type 1281 25 - PEAP 1283 Flags 1285 0 1 2 3 4 1286 +-+-+-+-+-+ 1287 |L M S T R| 1288 +-+-+-+-+-+ 1290 L = Length included 1291 M = More fragments 1292 S = PEAP start 1293 T = TLS Length included 1294 R = Reserved (must be zero) 1296 The L bit (Fragmented Message Length included) is set to indicate 1297 the presence of the four octet Fragmented Message Length field, 1298 and MUST be set for the first fragment of a fragmented PEAP 1299 message or set of messages. The M bit (more fragments) is set on 1300 all but the last fragment. The S bit (PEAP start) is set in a 1301 PEAP Start message. This differentiates the PEAP Start message 1302 from a fragment acknowledgment. The T bit (TLS Message Length 1303 included) is set to indicate the presence of the four octet TLS 1304 Message Length field, and MUST only be set for packet that 1305 contains Out-TLVs. It can be used to calculate the start of the 1306 Outer-TLVs. 1308 Version 1310 0 1 2 1311 +-+-+-+ 1312 |R|1|0| 1313 +-+-+-+ 1315 R = Reserved (must be zero) 1317 Fragmented Message Length 1319 The Fragmented Message Length field is four octets, and is present 1320 only if the L bit is set. This field provides the total length of 1321 the data after the Fragmented Message Length field in the PEAP 1322 message or set of messages that is being fragmented. 1324 TLS Message Length 1326 The TLS Message Length field is four octets, and is present only 1327 if the T bit is set. This field provides the total length of the 1328 TLS Data in the PEAP message. Data after this length of TLS data 1329 are the Outer TLVs. 1331 TLS Data 1333 The TLS data consists of the encapsulated packet in TLS record 1334 format. 1336 Outer TLVs 1338 The Outer-TLVs consists of the optional data used to help 1339 establishing the TLS tunnel in TLV format. The start of the 1340 Outer-TLV can be derived from the EAP Length field and TLS Length 1341 field. 1343 4. TLVs 1345 The TLVs used within PEAPv2 are standard Type-Length-Value (TLV) 1346 objects. The TLV objects could be used to carry arbitrary parameters 1347 between EAP peer and EAP server. Possible uses for TLV objects 1348 include: language and character set for Notification messages and 1349 cryptographic binding. 1351 The EAP peer may not necessarily implement all the TLVs supported by 1352 the EAP server; and hence to allow for interoperability, TLVs allow 1353 an EAP server to discover if a TLV is supported by the EAP peer, 1354 using the NAK TLV. The PEAPv2 packet does not have to contain any 1355 TLVs, nor need it contain any mandatory TLVs. 1357 The mandatory bit in a TLV indicates whether support of the TLV is 1358 required. If the peer or server does not support the TLV, it MUST 1359 send a NAK TLV in response, and all the other TLVs in the message 1360 MUST be ignored. If an EAP peer or server finds an unsupported TLV 1361 which is marked as optional, it can ignore the unsupported TLV. It 1362 MUST NOT send an NAK TLV. 1364 Note that a peer or server may support a TLV with the mandatory bit 1365 set, but may not understand the contents. The appropriate response 1366 to a supported TLV with content that is not understood is defined by 1367 the TLV specification. 1369 Outer-TLVs SHOULD NOT be included in messages after the first two 1370 Outer-TLV messages sent by the peer and EAP server respectively. A 1371 single Outer-TLV message may be fragmented in multiple PEAP packets. 1373 All Outer-TLVs MUST NOT have the mandatory bit set. If an Outer-TLV 1374 has the mandatory bit set, then the packet MUST be ignored. 1376 PEAPv2 implementations MUST support TLVs, as well as processing of 1377 mandatory/optional settings on the TLV. 1379 4.1. TLV Format 1381 TLVs are defined as described below. The fields are transmitted from 1382 left to right. 1384 0 1 2 3 1385 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 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 |M|R| TLV Type | Length | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Value... 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 M 1394 0 - Optional TLV 1395 1 - Mandatory TLV 1397 R 1399 Reserved, set to zero (0) 1401 TLV Type 1403 A 14-bit field, denoting the TLV type. Allocated Types include: 1405 0 - Reserved 1406 1 - Reserved 1407 2 - Reserved 1408 3 - Result-TLV - Acknowledged Result 1409 4 - NAK-TLV 1410 5 - Error-Code TLV 1411 6 - Connection-Binding TLV 1412 7 - Vendor-Specific TLV 1413 8 - URI-TLV 1414 9 - EAP-Payload TLV 1415 10 - Intermediate-Result TLV 1416 11 - Reserved 1417 12 - Crypto-Binding TLV 1418 13 - Calling-Station-Id TLV 1419 14 - Called-Station-Id TLV 1420 15 - NAS-Port-Type TLV 1421 16 - Server-Identifier TLV 1422 17 - Identity-Type TLV 1423 18 - Server-Trusted-Root TLV 1424 19 - Request-Action TLV 1425 20 - PKCS#7 TLV 1427 Length 1429 The length of the Value field in octets. 1431 Value 1432 The value of the TLV. 1434 4.2. Result TLV 1436 The Result TLV provides support for acknowledged success and failure 1437 messages within PEAPv2. PEAPv2 implementations MUST support this 1438 TLV, which cannot be responded to with a NAK TLV. If the Status 1439 field does not contain one of the known values, then the peer or EAP 1440 server MUST drop the connection. The Result TLV is defined as 1441 follows: 1443 0 1 2 3 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 |M|R| TLV Type | Length | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Status | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 M 1453 1 - Mandatory TLV 1455 R 1457 Reserved, set to zero (0) 1459 TLV Type 1461 3 1463 Length 1465 2 1467 Status 1469 The Status field is two octets. Values include: 1471 1 - Success 1472 2 - Failure 1474 4.3. NAK TLV 1476 The NAK TLV allows a peer to detect TLVs that are not supported by 1477 the other peer. A TLV packet can contain 0 or more NAK TLVs. PEAPv2 1478 implementations MUST support the NAK TLV, which cannot be responded 1479 to with a NAK TLV. The NAK TLV is defined as follows: 1481 0 1 2 3 1482 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 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 |M|R| TLV Type | Length | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Vendor-Id | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | NAK-Type | TLVs.... 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 M 1493 1 - Mandatory TLV 1495 R 1497 Reserved, set to zero (0) 1499 TLV Type 1501 4 1503 Length 1505 >=6 1507 Vendor-Id 1509 The Vendor-Id field is four octets, and contains the Vendor-Id of 1510 the TLV that was not supported. The high-order octet is 0 and the 1511 low-order 3 octets are the SMI Network Management Private 1512 Enterprise Code of the Vendor in network byte order. The Vendor- 1513 Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. 1514 For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI 1515 code. 1517 NAK-Type 1519 The NAK-Type field is two octets. The field contains the Type of 1520 the TLV that was not supported. A TLV of this Type MUST have been 1521 included in the previous packet. 1523 TLVs 1525 This field contains a list of TLVs, each of which MUST NOT have 1526 the mandatory bit set. These optional TLVs can be used in the 1527 future to communicate why the offending TLV was determined to be 1528 unsupported. 1530 4.4. Error-Code TLV 1532 The Error-Code TLV allows a PEAPv2 peer or server to indicate errors 1533 to the other party. A TLV packet can contain 0 or more Error TLVs. 1534 Error-Code TLVs MUST be marked as Mandatory. PEAPv2 implementations 1535 MUST support the Error-Code TLV, which cannot be responded to with a 1536 NAK TLV. The Error-Code TLV is defined as follows: 1538 0 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 |M|R| TLV Type | Length | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Error-Code | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 M 1548 1 - Mandatory TLV 1550 R 1552 Reserved, set to zero (0) 1554 TLV Type 1556 5 1558 Length 1560 4 1562 Error-Code 1564 The Error-Code field is four octets. Error Codes 1-999 represent 1565 successful outcomes (informative messages), 1000-1999 represent 1566 warnings, and codes 2000-2999 represent fatal errors. If an Error- 1567 Code TLV with a fatal error has been sent, then the conversation 1568 must be terminated. 1570 Currently defined values for Error-Code include: 1571 2001 Tunnel_Compromise_Error 1572 2002 Unexpected_TLVs_Exchanged 1574 4.5. Crypto-Binding TLV 1576 The Crypto-Binding TLV is used prove that both peers participated in 1577 the sequence of authentications (specifically the TLS session and 1578 inner EAP methods that generate keys). 1580 Both the Binding Request (B1) and Binding Response (B2) use the same 1581 packet format. However the Sub-Type indicates whether it is B1 or 1582 B2. 1584 The Crypto-Binding TLV MUST be used to perform Cryptographic Binding 1585 after each successful EAP method in a sequence of EAP methods is 1586 complete in PEAPv2 part 2. The Crypto-Binding TLV can also be used 1587 during Protected Termination. 1589 The Crypto-Binding TLV must have the version number received during 1590 the PEAP version negotiation. The receiver of the Crypto-Binding TLV 1591 must verify that the version in the Crypto-Binding TLV matches the 1592 version it sent during the PEAP version negotiation. If this check 1593 fails then the TLV is invalid. 1595 The receiver of the Crypto-Binding TLV must verify that the subtype 1596 is not set to any value other than the ones allowed. If this check 1597 fails then the TLV is invalid. 1599 This message format is used for the Binding Request (B1) and also the 1600 Binding Response. This uses TLV type CRYPTO_BINDING_TLV. PEAPv2 1601 implementations MUST support this TLV and this TLV cannot be 1602 responded to with a NAK TLV. The Crypto-Binding TLV is defined as 1603 follows: 1605 0 1 2 3 1606 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 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 |M|R| TLV Type | Length | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | Reserved | Version | Received Ver. | Sub-Type | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | | 1613 ~ Nonce ~ 1614 | | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | | 1617 ~ Compound MAC ~ 1618 | | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 M 1623 1 - Mandatory TLV 1625 R 1626 Reserved, set to zero (0) 1628 TLV Type 1630 12 1632 Length 1634 56 1636 Reserved 1638 Reserved, set to zero (0) 1640 Version 1642 The Version field is a single octet, which is set to the version 1643 of Crypto-Binding TLV. For the Crypto-Binding TLV defined in this 1644 specification, it is set to two (2). 1646 Received Version 1648 The Received Version field is a single octet and MUST be set to 1649 the PEAP version number received during version negotiation. Note 1650 that this field only provides protection against downgrade attacks 1651 where a version of PEAP requiring support for this TLV is required 1652 on both sides (such as PEAPv2 or a more recent version). 1654 Sub-Type 1656 The Sub-Type field is two octets. Possible values include: 1658 0 - Binding Request 1659 1 - Binding Response 1661 Nonce 1663 The Nonce field is 32 octets. It contains a 256 bit nonce that is 1664 temporally unique, used for compound MAC key derivation at each 1665 end. This is the S_NONCE for the B1 message and a C_NONCE for the 1666 B2 message. 1668 Compound MAC 1670 The Compound MAC field is 20 octets. This can be the Server MAC 1671 (B1_MAC) or the Client MAC (B2_MAC). It is computed using the 1672 HMAC-SHA1-160 keyed MAC that provides 160 bits of output using the 1673 CMK key. The MAC is computed over the buffer created after 1674 concatenating these fields in the following order: 1676 [a] The entire Crypto-Binding TLV attribute with the MAC field zeroed 1677 out. 1679 [b] The EAP Type sent by the other party in the first PEAP message. 1681 [c] All the Outer-TLVs from the first PEAP message sent by EAP-server 1682 to peer. If a single PEAP message is fragmented into multiple PEAP 1683 packets; then the Outer-TLVs in all the fragments of that message 1684 MUST be included. 1686 [d] All the Outer-TLVs from the first PEAP message sent by the peer to 1687 the EAP server. If a single PEAP message is fragmented into 1688 multiple PEAP packets, then the Outer-TLVs in all the fragments of 1689 that message MUST be included. 1691 4.6. Connection-Binding TLV 1693 The Connection-Binding TLV allows for connection specific information 1694 to be sent by the peer to the AAA server. This TLV should be logged 1695 by the EAP or AAA server. The AAA or EAP server should not deny 1696 access if there i s a mismatch between the value sent through the AAA 1697 protocol and this TLV. 1699 The format of this TLV is defined for the layer that defines the 1700 parameters. The format of the value sent by the peer to the EAP 1701 server may be different from the format of the corresponding value 1702 sent through the AAA protocol. For example, the connection binding 1703 TLV may contain the 802.11 MAC Address or SSID. 1705 PEAP implementations MAY support this TLV and this TLV MUST NOT be 1706 responded to with a NAK TLV. The Connection-Binding TLV is defined 1707 as follows: 1709 0 1 2 3 1710 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 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 |M|R| TLV Type | Length | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | TLVs... 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 M 1719 0 - Optional TLV 1721 R 1723 Reserved, set to zero (0) 1725 TLV Type 1727 6 1729 Length 1731 >=0 1733 TLVs... 1735 The field contains a list of TLVs, each in the same format defined 1736 in Section 4.3, with the optional bit set. These TLVs contain 1737 information on the identity of the peer and authenticator (layer 2 1738 or IP addresses); the media used to connect the peer and 1739 authenticator (NAS-Port-Type); and/or the service the client is 1740 trying to access on the gateway (SSID). The format of these TLVs 1741 will be defined in a separate draft. 1743 4.7. Vendor-Specific TLV 1745 The Vendor-Specific TLV is available to allow vendors to support 1746 their own extended attributes not suitable for general usage. 1748 A Vendor-Specific-TLV attribute can contain one or more TLVs, 1749 referred to as Vendor TLVs. The TLV-type of the Vendor-TLV will be 1750 defined by the vendor. All the Vendor TLVs inside a single Vendor- 1751 Specific TLV belong to the same vendor. 1753 PEAPv2 implementations MUST support the Vendor-Specific TLV, and this 1754 TLV MUST NOT be responded to with a NAK TLV. PEAPv2 implementations 1755 MAY NOT support the Vendor TLVs inside in the Vendor-Specific TLV, 1756 and can respond to the Vendor TLVs with a NAK TLV containing the 1757 appropriate Vendor-ID and Vendor-TLV type. 1759 Vendor TLVs may be optional or mandatory. Vendor TLVs sent in the 1760 protected success and failure packets MUST be marked as optional. If 1761 Vendor TLVs sent in protected success/failure packets are marked as 1762 Mandatory, then the peer or EAP server MUST drop the connection. 1764 The Vendor-Specific TLV is defined as follows: 1766 0 1 2 3 1767 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 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 |M|R| TLV Type | Length | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Vendor-Id | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | Vendor TLVs.... 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 M 1778 1 - Mandatory TLV 1780 R 1782 Reserved, set to zero (0) 1784 TLV Type 1786 7 1788 Length 1790 >=4 1792 Vendor-Id 1794 The Vendor-Id field is four octets. The high-order octet is 0 and 1795 the low-order 3 octets are the SMI Network Management Private 1796 Enterprise Code of the Vendor in network byte order. The Vendor- 1797 Id MUST be zero for TLVs that are not Vendor-Specific TLVs. For 1798 Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code. 1800 Vendor TLVs 1802 This field is of indefinite length. It contains vendor-specific 1803 TLVs, in a format defined by the vendor. 1805 4.8. URI TLV 1807 The URI TLV allows a server to send a URI to the client to refer it 1808 to a resource. The TLV contains a URI in the format specified in 1809 RFC2396 with UTF-8 encoding. Interpretation of the value of the URI 1810 is outside the scope of this document. 1812 If a packet contains multiple URI TLVs, then the client SHOULD select 1813 the first TLV it can implement, and ignore the others. If the client 1814 is unable to implement any of the URI TLVs, then it MAY ignore the 1815 error. PEAP implementations MAY support this TLV; and this TLV 1816 cannot be responded to with a NAK TLV. The URI TLV is defined as 1817 follows: 1819 0 1 2 3 1820 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 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 |M|R| TLV Type | Length | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 | URI... 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 M 1829 0 - Optional TLV 1831 R 1833 Reserved, set to zero (0) 1835 TLV Type 1837 8 1839 Length 1841 >=0 1843 URI 1845 This field is of indefinite length, and conforms to the format 1846 specified in [RFC2396]. 1848 4.9. EAP-Payload TLV 1850 To allow piggybacking EAP request and response with other TLVs, the 1851 EAP Payload TLV is defined, which includes an encapsulated EAP packet 1852 and 0 or more TLVs. PEAPv2 implementations MUST support this TLV, 1853 which cannot be responded to with a NAK TLV. The EAP-Payload TLV is 1854 defined as follows: 1856 0 1 2 3 1857 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 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 |M|R| TLV Type | Length | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | EAP packet... 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | TLVs... 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 M 1868 1 - Mandatory TLV 1870 R 1872 Reserved, set to zero (0) 1874 TLV Type 1876 9 1878 Length 1880 >=0 1882 EAP packet 1884 This field contains a complete EAP packet, including the EAP 1885 header (Code, Identifier, Length, Type) fields. The length of 1886 this field is determined by the Length field of the encapsulated 1887 EAP packet. 1889 TLVs... 1891 This (optional) field contains a list of TLVs associated with the 1892 EAP packet field. The TLVs utilize the same format described 1893 Section 4.3, and MUST NOT have the mandatory bit set. The total 1894 length of this field is equal to the Length field of the EAP- 1895 Payload-TLV, minus the Length field in the EAP header of the EAP 1896 packet field. 1898 4.10. Intermediate Result TLV 1900 The Intermediate Result TLV provides support for acknowledged 1901 intermediate Success and Failure messages within EAP. PEAPv2 1902 implementations MUST support this TLV, which cannot be responded to 1903 with a NAK TLV. The Intermediate Result TLV is defined as follows: 1905 0 1 2 3 1906 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 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 |M|R| TLV Type | Length | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Status | TLVs... 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 M 1915 1 - Mandatory TLV 1917 R 1919 Reserved, set to zero (0) 1921 TLV Type 1923 10 1925 Length 1927 >=2 1929 Status 1931 The Status field is two octets. Values include: 1933 1 - Success 1934 2 - Failure 1936 TLVs 1938 This (optional) field is of indeterminate length, and contains the 1939 TLVs associated with the Intermediate Result TLV, in the same 1940 format as described in Section 4.3. The TLVs in this field MUST 1941 NOT have the mandatory bit set. 1943 4.11. Reserved TLVs 1945 TLV type 11 is reserved due to use in previous implementations. 1946 PEAPv2 implementations MAY NOT support this TLV, which MUST be marked 1947 as OPTIONAL. This TLV MUST NOT be responded to with a NAK TLV. 1949 4.12. Calling-Station-ID TLV 1951 This TLV allows a peer to send information to EAP server about the 1952 call originator. This TLV MAY be included in the Connection-Binding- 1953 TLV. 1955 For dial-up, the Called-Station-ID TLV contains the phone number of 1956 the peer. For use with IEEE 802.1X, the MAC address of the peer is 1957 included, as specified in [RFC3580]. 1959 For VPN, this attribute is used to send the IPv4 or IPV6 address of 1960 the interface of the peer used to initiate the VPN in ASCII format. 1961 Where the Fully Qualified Domain Name (FQDN) of the VPN client is 1962 known, it SHOULD be appended, separated from the address with a " " 1963 (space). Example: "12.20.2.3 vpnserver.company.com". 1965 As described in [RFC3748] Section 7.15, this TLV SHOULD be logged by 1966 the EAP or AAA server, and MAY be used for comparison with 1967 information gathered by other means. 1969 However, since the format of this TLV may not match the format of the 1970 information gathered by other means, if an EAP server or AAA server 1971 supports the capability to deny access based on a mismatch, spurious 1972 authentication failures may occur. As a result, implementations 1973 SHOULD allow the administrator to disable this check. 1975 PEAP implementations MAY support this TLV and this TLV MUST NOT be 1976 responded to with a NAK TLV. The Calling-Station-ID TLV is defined 1977 as follows: 1979 0 1 2 3 1980 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 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 |M|R| TLV Type | Length | 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | String... 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 M 1989 0 - Optional TLV 1991 R 1993 Reserved, set to zero (0) 1995 TLV Type 1997 13 1999 Length 2000 >=0 2002 String 2004 The field should be the same as the value of the Calling-Station- 2005 ID attribute in [RFC2865]. 2007 4.13. Called-Station-ID TLV 2009 This TLV allows a peer to send information to EAP server about the 2010 NAS it called. This TLV MAY be included in the Connection-Binding- 2011 TLV. 2013 For dial-up, the Calling-Station-ID TLV contains the phone number 2014 called by the peer. For use with IEEE 802.1X, the MAC address of the 2015 NAS is included, as specified in [RFC3580]. 2017 For VPN, this attribute is used to send the IPv4 or IPv6 address of 2018 VPN server in ASCII format. Where the Fully Qualified Domain Name 2019 (FQDN) of the VPN server is known, it SHOULD be appended, separated 2020 from the address with a " " (space). Example: "12.20.2.3 2021 vpnserver.company.com". 2023 This TLV SHOULD be logged by the EAP or AAA server, and MAY be used 2024 for comparison with information gathered by other means. However, 2025 since the format of this TLV may not match the format of the 2026 information gathered by other means, if an EAP server or AAA server 2027 supports the capability to deny access based on a mismatch, spurious 2028 authentication failures may occur. As a result, implementations 2029 SHOULD allow the administrator to disable this check. 2031 PEAP implementations MAY support this TLV, and this TLV MUST NOT be 2032 responded to with a NAK TLV. The Called-Station-ID TLV is defined as 2033 follows: 2035 0 1 2 3 2036 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 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 |M|R| TLV Type | Length | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | String... 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 M 2045 0 - Optional TLV 2047 R 2048 Reserved, set to zero (0) 2050 TLV Type 2052 14 2054 Length 2056 >=0 2058 String 2060 The field should be the same as the value of the Called-Station-ID 2061 attribute in [RFC2865]. 2063 4.14. NAS-Port-Type TLV 2065 This TLV allows a peer to send information to EAP server about the 2066 type of physical connection used by the peer to connect to NAS. This 2067 TLV MAY be included in the Connection-Binding-TLV. 2069 The value of this field is the same as the value of NAS-Port-Type 2070 attribute in [RFC2865]. 2072 This TLV SHOULD be logged by the EAP or AAA server and MAY be used 2073 for comparison with information gathered by other means. However, 2074 since the format of this TLV may not match the format of the 2075 information gathered by other means, if an EAP server or AAA server 2076 supports the capability to deny access based on a mismatch, spurious 2077 authentication failures may occur. As a result, implementations 2078 SHOULD allow the administrator to disable this check. 2080 PEAP implementations MAY support this TLV; and this TLV MUST NOT be 2081 responded to with a NAK TLV. The NAS-Port-Type TLV is defined as 2082 follows: 2084 0 1 2 3 2085 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 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 |M|R| TLV Type | Length | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 | Value | 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 M 2094 0 - Optional TLV 2096 R 2098 Reserved, set to zero (0) 2100 TLV Type 2102 15 2104 Length 2106 4 2108 Value 2110 The Value field is four octets. Values are the same as for the 2111 NAS-Port-Type attribute defined in [RFC2865]. 2113 4.15. Server-Identifier TLV 2115 This TLV allows a EAP-Server to send a hint to the EAP peer to help 2116 the EAP peer select the appropriate sessionID for session resumption. 2117 The field is a string sent by the EAP server, and the field should be 2118 treated as a opaque string by the peer. During a full-tls-handshake, 2119 the EAP-peer MAY keep track of this field and the corresponding 2120 sessionID, and use it as a hint to select the appropriate sessionID 2121 during session resumption. 2123 PEAP implementations MAY support this TLV and this TLV MUST NOT be 2124 responded to with a NAK TLV. The Server-Identifier TLV is defined as 2125 follows: 2127 0 1 2 3 2128 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 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 |M|R| TLV Type | Length | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | String... 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 M 2137 0 - Optional TLV 2139 R 2141 Reserved, set to zero (0) 2143 TLV Type 2145 16 2147 Length 2149 >=0 2151 String 2153 Contains an identifier sent by the EAP server. 2155 4.16. Identity-Type TLV 2157 The Identity-Type TLV allows an EAP-server to send a hint to help the 2158 EAP-peer select the right type of identity; for example; user or 2159 machine. 2161 PEAPv2 implementations MAY support this TLV, which cannot be 2162 responded to with a NAK TLV. 2164 If the Identity-type field does not contain one of the known values 2165 or if the EAP peer does not have an identity corresponding to the 2166 identity-type, then the peer MUST ignore the value. The Identity- 2167 Type TLV is defined as follows: 2169 0 1 2 3 2170 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 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 |M|R| TLV Type | Length | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Identity-Type | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 M 2179 0 - Optional TLV 2181 R 2183 Reserved, set to zero (0) 2185 TLV Type 2187 17 2189 Length 2191 2 2193 Identity-Type 2195 The Identity-Type field is two octets. Values include: 2197 1 - User 2198 2 - Machine 2200 4.17. Server-Trusted-Root TLV 2202 The Server-Trusted-Root TLV allows the peer to send a request to the 2203 EAP server for a trusted root in PKCS#7 format. 2205 The Server-Trusted-Root TLV is always marked as optional, and cannot 2206 be responded to with a NAK TLV. PEAPv2 server implementations that 2207 claim to support provisioning MUST support Server-Trusted-Root TLV, 2208 PKCS#7 TLV, and the PKCS#7-Server-Certificate-Root credential format 2209 defined in this TLV. PEAPv2 peer implementations MAY NOT support 2210 this TLV. 2212 The Server-Trusted-Root TLV can only be sent as an inner TLV (inside 2213 PEAP part 2 conversation), in both server unauthenticated tunnel 2214 provisioning mode, and the regular authentication process. 2216 The peer MUST NOT request, or accept the trusted root sent inside the 2217 Server-Root credential TLV by EAP-server until it has completed 2218 authentication of EAP server, and validated the Crypto-Binding TLV. 2219 The peer may receive a trusted root, but is not required to use the 2220 trusted root received from the EAP server. 2222 If the EAP server sets credential-format to PKCS#7-Server- 2223 Certificate-Root, then the Server-Trusted-Root TLV MUST contain the 2224 root of the certificate chain of the certificate issued to the EAP 2225 server packages in a PKCS#7 TLV. If the Server certificate is a 2226 self-signed certificate, then the root is the self-signed 2227 certificate. In this case, the EAP server does not have to sign the 2228 certificate inside the PCKS#7 TLV since it does not necessarily have 2229 to private key for it. 2231 If the Server-Trusted-Root TLV credential format does not contain one 2232 of the known values, then the EAP-server MUST ignore the value. 2234 The Server-Trusted-Root TLV is defined as follows: 2236 0 1 2 3 2237 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 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 |M|R| TLV Type | Length | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Credential-Format | TLVs... 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2244 M 2246 0 - Optional TLV 2248 R 2250 Reserved, set to zero (0) 2252 TLV Type 2254 18 2256 Length 2258 >=2 2260 Credential-Format 2262 The Credential-Format field is two octets. Values include: 2264 1 - PKCS#7-Server-Certificate-Root. 2266 TLVs 2268 This field is of indefinite length. It contains TLVs associated 2269 with the certificate-request. 2271 4.18. PKCS#7 TLV 2273 The PKCS#7 TLV contains the PKCS #7 wrapped X.509 certificate. This 2274 field contains a certificate or certificate chain in PKCS#7 [RFC2315] 2275 format requested by the peer. 2277 The PKCS#7 TLV is always marked as optional, which cannot be 2278 responded to with a NAK TLV. PEAPv2 server implementations that 2279 claim to support provisioning MUST support this TLV. PEAPv2 peer 2280 implementations MAY NOT support this TLV. 2282 If the PKCS#7 TLV contains a certificate or certificate chain that is 2283 not acceptable to the peer, then peer MUST ignore the value. 2285 The PKCS#7 TLV is defined as follows: 2287 0 1 2 3 2288 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 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 |M|R| TLV Type | Length | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | PKCS#7 data... 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 M 2297 0 - Optional TLV 2299 R 2301 Reserved, set to zero (0) 2303 TLV Type 2305 20 2307 Length 2309 >=0 2311 PKCS#7 Data 2313 PKCS #7 wrapped X.509 certificate. This field contains a 2314 certificate or certificate chain in PKCS#7 [RFC2315] format. 2316 4.19. Request-Action TLV 2318 The Request-Action TLV MAY be sent by the peer along with 2319 acknowledged failure. It allows the peer to request the EAP server 2320 to negotiate EAP methods or process TLVs specified in the failure 2321 packet. The server MAY ignore this TLV. 2323 PEAPv2 implementations MUST support this TLV, which cannot be 2324 responded to with a NAK TLV. 2326 The Request-Action TLV is defined as follows: 2328 0 1 2 3 2329 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 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 |M|R| TLV Type | Length | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | Action | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 M 2338 1 - Mandatory TLV 0 - Optional TLV 2340 R 2342 Reserved, set to zero (0) 2344 TLV Type 2346 19 2348 Length 2350 2 2352 Action 2354 The Action field is two octets. Values include: 2356 1 - Process-TLV 2357 2 - Negotiate-EAP 2359 4.20. TLV Rules 2361 To save round trips, multiple TLVs can be sent in the single PEAPv2 2362 packet. However, multiple EAP Payload TLVs within one single PEAPv2 2363 packet is not supported in this version and MUST NOT be sent. If the 2364 peer or EAP server receives multiple EAP Payload TLVs, then it MUST 2365 drop the connection. 2367 The following table defines the meaning of the table entries in the 2368 sections below: 2370 0 This TLV MUST NOT be present in the packet. 2371 0+ Zero or more instances of this TLV MAY be present in packet. 2372 0-1 Zero or one instance of this TLV MAY be present in packet. 2373 1 Exactly one instance of this TLV MUST be present in packet. 2375 4.20.1. Outer TLVs 2377 The following table provides a guide to which TLVs may be included in 2378 the PEAPv2 packet outside the TLS channel, which kind of packets, and 2379 in what quantity: 2381 Request Response Success Failure TLV in unencrypted-TLVs field 2382 0-1 0 0 0 Server-Identifier TLV 2383 0+ 0+ 0 0 Vendor-Specific TLV 2385 Outer-TLVs MUST be marked as optional. Vendor-TLVs inside Vendor- 2386 Specific TLV MUST be marked as optional when included in Outer TLVs. 2387 Outer-TLVs MUST NOT be included in messages after the first two 2388 PEAPv2 messages sent by peer and EAP-server respectively. That is 2389 the first EAP server to peer message and first peer to EAP server 2390 message. If the message is fragmented, the whole set of messages is 2391 counted as one message. If Outer-TLVs are included in messages after 2392 the first two PEAPv2 messages, they MUST be ignored. 2394 4.20.2. Inner TLVs 2396 The following table provides a guide to which Inner TLVs may be 2397 encapsulated in TLS in PEAPv2 Part 2, in which kind of packets, and 2398 in what quantity: 2400 Request Response Success Failure Inner-TLVs 2401 0-1 0-1 0-1 0-1 Intermediate Result 2402 0-1 0-1 0 0 EAP Payload 2403 0-1 0-1 1 1 Result 2404 0-1 0-1 1 1 Crypto-Binding 2405 0+ 0+ 0+ 0+ Error 2406 0+ 0+ 0 0 NAK 2407 0-1 0-1 0-1 0-1 Connection-Binding 2408 0+ 0+ 0+ 0+ Vendor-Specific 2409 0+ 0 0+ 0-1 URI 2410 0+ 0 0 0 Identity-Type 2411 0+ 0+ 0+ 0+ Server-Trusted-Root 2412 0 0-1 0 0-1 Request-Action 2414 Vendor TLVs (included in Vendor-Specific TLVs) sent in the protected 2415 success and failure packets MUST be marked as optional. If Vendor 2416 TLVs sent in protected success/failure packets are marked as 2417 Mandatory, then the peer or EAP server MUST drop the connection. 2419 The following defines the meaning of packet type in the table above: 2421 Packet type Description 2422 ---------------------------- 2423 Request - TLV request packet sent by the EAP server to the peer. 2424 Response - TLV packet sent by the peer to the EAP server. 2425 Success - TLV packet sent by the peer or EAP server as 2426 a protected success 2427 Failure - TLV packet sent by the peer or EAP server as 2428 a protected failure. 2430 4.20.3. EAP-Payload TLV 2432 The EAP-Payload TLV can contain other TLVs. The table below defines 2433 which TLVs can be contained inside the EAP-Payload TLV and how many 2434 such TLVs can be included. 2436 Request Response TLV 2437 0+ 0+ Vendor-Specific 2438 0+ 0+ Identity-Type 2440 Vendor TLVs inside Vendor-Specific TLV MUST be marked as optional 2441 when included in EAP-Payload TLV. 2443 4.20.4. Connection-Binding TLV 2445 The Connection-Binding TLV can contain other TLVs. The table below 2446 defines which TLVs can be contained inside the Connecting-Binding TLV 2447 and how many such TLVs can be included. 2449 Request Response TLV 2450 0-1 0 Calling-Station-ID 2451 0-1 0 Called-Station-ID 2452 0-1 0 NAS-port-type 2453 0+ 0+ Vendor-Specific 2455 Vendor TLVs inside the Vendor-Specific TLV MUST be marked as optional 2456 when included in Connection-Binding TLV. 2458 4.20.5. Server-Trusted-Root TLV 2460 The Server-Trusted-Root TLV can contain other TLVs. The table below 2461 defines which TLVs can be contained inside the Server-Trusted-Root 2462 TLV and how many such TLVs can be included. 2464 Request Response TLV 2465 0-1 0 PKCS#7 TLV 2467 5. Security Considerations 2469 5.1. Authentication and integrity protection 2471 PEAPv2 provides a server authenticated, encrypted and integrity 2472 protected tunnel. All data within the tunnel has these properties. 2473 Data outside the tunnel such as EAP Success and Failure, Outer-TLVs, 2474 authentication methods negotiated outside of PEAPv2 and the PEAPv2 2475 headers themselves (including the EAP-Type in the header) are not 2476 protected by this tunnel. 2478 In addition, the Crypto-Binding TLV can reveal man-in-the-middle 2479 attack described in section 6.8. Hence, the server should not reveal 2480 any sensitive data to the client until after the Crypto-Binding TLV 2481 has been properly verified. 2483 In order to detect modification of Outer-TLVs, the first two Outer- 2484 TLVs messages sent by both peer and EAP-server are included in the 2485 calculation of the Crypto-Binding TLV. Outer-TLVs SHOULD NOT be 2486 included in other PEAP packets since there is no mechanism to detect 2487 modification. 2489 In order to detect modification of EAP-Type sent in the clear (EAP- 2490 Type should be set to PEAP), the EAP-Type sent in the first two 2491 messages by both peer and EAP-server is included in the calculation 2492 of Crypto-Binding TLV. The EAP Type in the clear could be modified 2493 in other PEAP packets and will likely result in failure, hence it is 2494 not included in the Crypto-Binding calculation. 2496 5.2. Method Negotiation 2498 If the peer does not support PEAPv2, or does not wish to utilize 2499 PEAPv2 authentication, it MUST respond to the initial EAP- 2500 Request/PEAP-Start with a NAK, suggesting an alternate authentication 2501 method. Since the NAK is sent in cleartext with no integrity 2502 protection or authentication, it is subject to spoofing. Inauthentic 2503 NAK packets can be used to trick the peer and authenticator into 2504 "negotiating down" to a weaker form of authentication, such as EAP- 2505 MD5 (which only provides one way authentication and does not derive a 2506 key). 2508 Since a subsequent protected EAP conversation can take place within 2509 the TLS session, selection of PEAPv2 as an authentication method does 2510 not limit the potential secondary authentication methods. As a 2511 result, the only legitimate reason for a peer to NAK PEAPv2 as an 2512 authentication method is that it does not support it. Where the 2513 additional security of PEAPv2 is required, server implementations 2514 SHOULD respond to a NAK with an EAP-Failure, terminating the 2515 authentication conversation. 2517 Since method negotiation outside of PEAP is not protected, if the 2518 peer is configured to allow PEAP and other EAP methods at the same 2519 time, the negotiation is subject to downgrade attacks. Since method 2520 negotiation outside of PEAP is not protected, if the peer is 2521 configured to allow PEAPv2 and previous PEAP versions at the same 2522 time, the negotiation is subject to negotiation downgrade attacks. 2523 However, peers configured to allow PEAPv2 and later PEAP versions may 2524 not be subject to downgrade negotiation attack since the highest 2525 version supported by both peers is checked within the protected 2526 tunnel. 2528 If peer implementations select incorrect methods or credentials with 2529 EAP servers, then attacks are possible on the credentials. Hence, a 2530 PEAPv2 peer implementation should preferably be configured with a set 2531 of credentials and methods that may be used with a specific PEAPv2 2532 server. The peer implementation may be configured to use different 2533 methods and/or credentials based on the PEAPv2 server. 2535 5.3. TLS Session Cache Handling 2537 In cases where a TLS session has been successfully resumed, in some 2538 circumstances, it is possible for the EAP server to skip the PEAPv2 2539 Part 2 conversation, and successfully conclude the conversation with 2540 a protected termination. 2542 PEAPv2 "fast reconnect" is desirable in applications such as wireless 2543 roaming, since it minimizes interruptions in connectivity. It is 2544 also desirable when the "inner" EAP mechanism used is such that it 2545 requires user interaction. The user should not be required to re- 2546 authenticate herself, using biometrics, token cards or similar, every 2547 time the radio connectivity is handed over between access points in 2548 wireless environments. 2550 However, there are issues that need to be understood in order to 2551 avoid introducing security vulnerabilities. 2553 Since PEAPv2 Part 1 may not provide client authentication, 2554 establishment of a TLS session (and an entry in the TLS session 2555 cache) does not by itself provide an indication of the peer's 2556 authenticity. 2558 Some PEAPv2 implementations may not be capable of removing TLS 2559 session cache entries established in PEAPv2 Part 1 after an 2560 unsuccessful PEAPv2 Part 2 authentication. In such implementations, 2561 the existence of a TLS session cache entry provides no indication 2562 that the peer has previously been authenticated. As a result, 2563 implementations that do not remove TLS session cache entries after a 2564 failed PEAPv2 Part 2 authentication or failed protected termination 2565 MUST use other means than successful TLS resumption as the indicator 2566 of whether the client is authenticated or not. The implementation 2567 MUST determine that the client is authenticated only after the 2568 completion of protected termination. Failing to do this would enable 2569 a peer to gain access by completing PEAPv2 Part 1, tearing down the 2570 connection, re-connecting and resuming PEAPv2 Part 1, thereby proving 2571 herself authenticated. Thus, TLS resumption MUST only be enabled if 2572 the implementation supports TLS session cache removal. If an EAP 2573 server implementing PEAPv2 removes TLS session cache entries of peers 2574 failing PEAPv2 Part 2 authentication, then it MAY skip the PEAPv2 2575 Part 2 conversation entirely after a successful session resumption, 2576 successfully terminating the PEAPv2 conversation as described in 2577 Section 2.4. 2579 5.4. Certificate Revocation 2581 Since the EAP server usually has network connectivity during the EAP 2582 conversation, the server is capable of following a certificate chain 2583 or verifying whether the peer's certificate has been revoked. In 2584 contrast, the peer may or may not have network connectivity, and thus 2585 while it can validate the EAP server's certificate based on a pre- 2586 configured set of CAs, it may not be able to follow a certificate 2587 chain or verify whether the EAP server's certificate has been 2588 revoked. 2590 In the case where the peer is initiating a voluntary Layer 2 channel 2591 using PPTP or L2TP, the peer will typically already have network 2592 connectivity established at the time of channel initiation. As a 2593 result, during the EAP conversation it is capable of checking for 2594 certificate revocation. 2596 As part of the TLS negotiation, the server presents a certificate to 2597 the peer. The peer SHOULD verify the validity of the EAP server 2598 certificate, and SHOULD also examine the EAP server name presented in 2599 the certificate, in order to determine whether the EAP server can be 2600 trusted. Please note that in the case where the EAP authentication is 2601 remoted, the EAP server will not reside on the same machine as the 2602 authenticator, and therefore the name in the EAP server's certificate 2603 cannot be expected to match that of the intended destination. In 2604 this case, a more appropriate test might be whether the EAP server's 2605 certificate is signed by a CA controlling the intended destination 2606 and whether the EAP server exists within a target sub-domain. 2608 In the case where the peer is attempting to obtain network access, it 2609 will not have network connectivity. The TLS Extensions [RFC3546] 2610 support piggybacking of an Online Certificate Status Protocol (OCSP) 2611 response within TLS, therefore can be utilized by the peer in order 2612 to verify the validity of server certificate. However, since not all 2613 TLS implementations implement the TLS extensions, it may be necessary 2614 for the peer to wait to check for certificate revocation until after 2615 network access has been obtained. In this case, the peer SHOULD 2616 conduct the certificate status check immediately upon going online 2617 and SHOULD NOT send data until it has received a positive response to 2618 the status request. If the server certificate is found to be invalid 2619 as per client policy, then the peer SHOULD disconnect. 2621 If the client has a policy to require checking certificate revocation 2622 and it cannot obtain revocation information then it may need to 2623 disallow the use of all or some of the inner methods since some 2624 methods may reveal some sensitive information. 2626 5.5. Separation of the EAP Server and the Authenticator 2628 As a result of a complete PEAPv2 Part 1 and Part 2 conversation, the 2629 EAP endpoints will mutually authenticate, and derive a session key 2630 for subsequent use in link layer security. Since the peer and EAP 2631 client reside on the same machine, it is necessary for the EAP client 2632 module to pass the session key to the link layer encryption module. 2634 The situation may be more complex on the Authenticator, which may or 2635 may not reside on the same machine as the EAP server. In the case 2636 where the EAP server and the Authenticator reside on different 2637 machines, there are several implications for security. Firstly, the 2638 mutual authentication defined in PEAPv2 will occur between the peer 2639 and the EAP server, not between the peer and the authenticator. This 2640 means that as a result of the PEAP conversation, it is not possible 2641 for the peer to validate the identity of the NAS or channel server 2642 that it is speaking to. 2644 The second issue is that the session key negotiated between the peer 2645 and EAP server will need to be transmitted to the authenticator. 2646 Therefore a secure mechanism needs to be provided to transmit the 2647 session key from the EAP server to the authenticator or channel 2648 server that needs to use the key. The specification of this transit 2649 mechanism is outside the scope of this document. 2651 5.6. Separation of PEAPv2 Part 1 and 2 Servers 2653 The EAP server involved in PEAPv2 Part 2 need not necessarily be the 2654 same as the EAP server involved in PEAPv2 Part 1. For example, a 2655 local authentication server or proxy might serve as the endpoint for 2656 the Part 1 conversation, establishing the TLS channel. Subsequently, 2657 once the EAP-Response/Identity has been received within the TLS 2658 channel, it can be decrypted and forwarded in cleartext to the 2659 destination realm EAP server. The rest of the conversation will 2660 therefore occur between the destination realm EAP server and the 2661 peer, with the local authentication server or proxy acting as an 2662 encrypting/decrypting gateway. This permits a non-TLS capable EAP 2663 server to participate in the PEAPv2 conversation. 2665 Note however that such an approach introduces security 2666 vulnerabilities. Since the EAP Response/Identity is sent in the 2667 clear between the proxy and the EAP server, this enables an attacker 2668 to snoop the user's identity. It also enables a remote environments, 2669 which may be public hot spots or Internet coffee shops, to gain 2670 knowledge of the identity of their users. Since one of the potential 2671 benefits of PEAPv2 is identity protection, this is undesirable. 2673 If the EAP method negotiated during PEAPv2 Part 2 does not support 2674 mutual authentication, then if the Part 2 conversation is proxied to 2675 another destination, the PEAPv2 peer will not have the opportunity to 2676 verify the secondary EAP server's identity. Only the initial EAP 2677 server's identity will have been verified as part of TLS session 2678 establishment. 2680 Similarly, if the EAP method negotiated during PEAPv2 Part 2 is 2681 vulnerable to dictionary attack, then an attacker capturing the 2682 cleartext exchange will be able to mount an offline dictionary attack 2683 on the password. 2685 Finally, when a Part 2 conversation is terminated at a different 2686 location than the Part 1 conversation, the Part 2 destination is 2687 unaware that the EAP client has negotiated PEAPv2. As a result, it is 2688 unable to enforce policies requiring PEAP. Since some EAP methods 2689 require PEAPv2 in order to generate keys or lessen security 2690 vulnerabilities, where such methods are in use, such a configuration 2691 may be unacceptable. 2693 In summary, PEAPv2 encrypting/decrypting gateway configurations are 2694 vulnerable to attack and SHOULD NOT be used. Instead, the entire 2695 PEAPv2 connection SHOULD be proxied to the final destination, and the 2696 subsequently derived master session keys need to be transmitted back. 2697 T his provides end to end protection of PEAPv2. The specification of 2698 this transit mechanism is outside the scope of this document, but 2699 mechanisms similar to [RFC2548] can be used. These steps protect the 2700 client from revealing her identity to the remote environment. 2702 In order to find the proper PEAP destination, the EAP client SHOULD 2703 place a Network Access Identifier (NAI) conforming to [RFC2486] in 2704 the Identity Response. 2706 There may be cases where a natural trust relationship exists between 2707 the (foreign) authentication server and final EAP server, such as on 2708 a campus or between two offices within the same company, where there 2709 is no danger in revealing the identity of the station to the 2710 authentication server. In these cases, a proxy solution without end 2711 to end protection of PEAPv2 MAY be used. If RADIUS is used to 2712 communicate between gateway and EAP server, then the PEAPv2 2713 encrypting/decrypting gateway SHOULD provide support for IPsec 2714 protection of RADIUS in order to provide confidentiality for the 2715 portion of the conversation between the gateway and the EAP server, 2716 as described in [RFC3579]. 2718 5.7. Identity Verification 2720 Since the TLS session has not yet been negotiated, the initial 2721 Identity request/response occurs in the clear without integrity 2722 protection or authentication. It is therefore subject to snooping and 2723 packet modification. 2725 In configurations where all users are required to authenticate with 2726 PEAPv2 and the first portion of the PEAPv2 conversation is terminated 2727 at a local backend authentication server, without routing by proxies, 2728 the initial cleartext Identity Request/Response exchange is not 2729 needed in order to determine the required authentication method(s) or 2730 route the authentication conversation to its destination. As a 2731 result, the initial Identity and Request/Response exchange MAY NOT 2732 be present, and a subsequent Identity Request/Response exchange MAY 2733 occur after the TLS session is established. 2735 If the initial cleartext Identity Request/Response has been tampered 2736 with, after the TLS session is established, it is conceivable that 2737 the EAP Server will discover that it cannot verify the peer's claim 2738 of identity. For example, the peer's userID may not be valid or may 2739 not be within a realm handled by the EAP server. Rather than 2740 attempting to proxy the authentication to the server within the 2741 correct realm, the EAP server SHOULD terminate the conversation. 2743 The PEAPv2 peer can present the server with multiple identities. This 2744 includes the claim of identity within the initial EAP- 2745 Response/Identity (MyID) packet, which is typically used to route the 2746 EAP conversation to the appropriate home backend authentication 2747 server. There may also be subsequent EAP-Response/Identity packets 2748 sent by the peer once the TLS channel has been established. 2750 Note that since the PEAPv2 peer may not present a certificate, it is 2751 not always possible to check the initial EAP-Response/Identity 2752 against the identity presented in the certificate, as is done in 2753 [RFC2716]. 2755 Moreover, it cannot be assumed that the peer identities presented 2756 within multiple EAP-Response/Identity packets will be the same. For 2757 example, the initial EAP-Response/Identity might correspond to a 2758 machine identity, while subsequent identities might be those of the 2759 user. Thus, PEAPv2 implementations SHOULD NOT abort the 2760 authentication just because the identities do not match. However, 2761 since the initial EAP-Response/Identity will determine the EAP server 2762 handling the authentication, if this or any other identity is 2763 inappropriate for use with the destination EAP server, there is no 2764 alternative but to terminate the PEAPv2 conversation. 2766 The protected identity or identities presented by the peer within 2767 PEAPv2 Part 2 may not be identical to the cleartext identity 2768 presented in PEAPv2 Part 1, for legitimate reasons. In order to 2769 shield the userID from snooping, the cleartext Identity may only 2770 provide enough information to enable routing of the authentication 2771 request to the correct realm. For example, the peer may initially 2772 claim the identity of "nouser@bigco.com" in order to route the 2773 authentication request to the bigco.com EAP server. Subsequently, 2774 once the TLS session has been negotiated, in PEAPv2 Part 2, the peer 2775 may claim the identity of "fred@bigco.com". Thus, PEAPv2 can provide 2776 protection for the user's identity, though not necessarily the 2777 destination realm, unless the PEAPv2 Part 1 conversation terminates 2778 at the local authentication server. 2780 As a result, PEAPv2 implementations SHOULD NOT attempt to compare the 2781 Identities claimed with Parts 1 and 2 of the PEAPv2 conversation. 2782 Similarly, if multiple Identities are claimed within PEAPv2 Part 2, 2783 these SHOULD NOT be compared. An EAP conversation may involve more 2784 than one EAP authentication method, and the identities claimed for 2785 each of these authentications could be different (e.g. a machine 2786 authentication, followed by a user authentication). 2788 5.8. Man-in-the-Middle Attack Protection 2790 TLS protection can address a number of weaknesses in the EAP method; 2791 as well as EAP protocol weaknesses listed in the abstract and 2792 introduction sections in this document. 2794 Hence, the recommended solution is to always deploy authentication 2795 methods with protection of PEAPv2. 2797 if a deployment chooses to allow a EAP method protected by PEAPv2 2798 without protection of PEAPv2 or IPsec at the same time, then this 2799 opens up a possibility of a man-in-the-middle attack. 2801 A man-in-the-middle can spoof the client to authenticate to it 2802 instead of the real EAP server; and forward the authentication to the 2803 real server over a protected tunnel. Since the attacker has access to 2804 the keys derived from the tunnel, it can gain access to the network. 2806 PEAP version 2 prevents this attack by using the keys generated by 2807 the inner EAP method in the crypto-binding exchange described in 2808 protected termination section. This attack is not prevented if the 2809 inner EAP method does not generate keys or if the keys generated by 2810 the inner EAP method can be compromised. Hence, in cases where the 2811 inner EAP method does not generate keys, the recommended solution is 2812 to always deploy authentication methods protected by PEAPv2. 2814 Alternatively, the attack can also be thwarted if the inner EAP 2815 method can signal to the peer that the packets are being sent within 2816 the tunnel. In most cases this may require modification to the inner 2817 EAP method. In order to allow for these implementations, PEAPv2 2818 implementations should inform inner EAP methods that the EAP method 2819 is being protected by a PEAPv2 tunnel. 2821 Since all sequence negotiations and exchanges are protected by TLS 2822 channel, they are immune to snooping and MITM attacks with the use of 2823 Crypto-Binding TLV. To make sure the same parties are involved tunnel 2824 establishment and previous inner method, before engaging the next 2825 method to sent more sensitive information, both peer and server MUST 2826 use the Crypto-Binding TLV between methods to check the tunnel 2827 integrity. If the Crypto-Binding TLV failed validation, they SHOULD 2828 stop the sequence and terminate the tunnel connection, to prevent 2829 more sensitive information being sent in subsequent methods. 2831 5.9. Cleartext Forgeries 2833 As described in [RFC3748], EAP Success and Failure packets are not 2834 authenticated, so that they may be forged by an attacker without fear 2835 of detection. Forged EAP Failure packets can be used to convince an 2836 EAP peer to disconnect. Forged EAP Success and Failure packets may 2837 be used to convince a peer to disconnect; or convince a peer to 2838 access the network even before authentication is complete, resulting 2839 in denial of service for the peer. 2841 By supporting encrypted, authenticated and integrity protected 2842 success/failure indications, PEAPv2 provides protection against these 2843 attacks. 2845 Once the peer responds with the first PEAP packet; and the EAP server 2846 receives the first PEAPv2 packet from the peer, both MUST silently 2847 discard all clear text EAP messages unless both the PEAPv2 peer and 2848 server have indicated success or failure or error using a protected 2849 error or protected termination mechanism. The success/failure 2850 decisions sent by a protected mechanism indicate the final decision 2851 of the EAP authentication conversation. After success/failure has 2852 been indicated by a protected mechanism, the PEAPv2 client can 2853 process unprotected EAP success and EAP failure message; however MUST 2854 ignore any unprotected EAP success or failure messages where the 2855 decision does not match the decision of the protected mechanism. 2857 After a Fatal alert is received or after protected termination is 2858 complete, the peer or EAP server should accept clear text EAP 2859 messages. If the PEAPv2 tunnel is nested inside another tunnel, then 2860 the clear text EAP messages should only be accepted after protected 2861 termination of outer tunnels. 2863 [RFC3748] states that an EAP Success or EAP Failure packet terminates 2864 the EAP conversation, so that no response is possible. Since EAP 2865 Success and EAP Failure packets are not retransmitted, if the final 2866 packet is lost, then authentication will fail. As a result, where 2867 packet loss is expected to be non-negligible, unacknowledged 2868 success/failure indications lack robustness. 2870 As a result, a EAP server SHOULD send a clear text EAP success or 2871 EAP-failure packet after the protected success or failure packet or 2872 TLS alert. The peer MUST NOT require the clear text EAP Success or 2873 EAP Failure if it has received the protected success or failure or 2874 TLS alert. For more details, refer to [RFC3748] Section 4.2. 2876 5.10. TLS Ciphersuites 2878 Anonymous ciphersuites are vulnerable to man-in-the-middle attacks, 2879 and SHOULD NOT be used with PEAPv2, unless the EAP methods inside 2880 PEAPv2 can address the man-in-the-middle attack or unless the man-in- 2881 the-middle attack can be addressed by mechanisms external to PEAPv2. 2883 5.11. Denial of Service Attacks 2885 Denial of service attacks are possible if the attacker can insert or 2886 modify packets in the authentication channel. The attacker can 2887 modify unprotected fields in the PEAP packet such as the EAP protocol 2888 or PEAP version number. This can result in a denial of service 2889 attack. It is also possible for the attacker to modify protected 2890 fields in a packet to cause decode errors resulting in a denial of 2891 service. In these ways the attacker can prevent access for peers 2892 connecting to the network. 2894 Denial of service attacks with multiplier impacts are more 2895 interesting than the ones above. It is possible to multiply the 2896 impact by creating a large number of TLS sessions with the EAP 2897 server. 2899 5.12. Server Unauthenticated Tunnel Provisioning Mode 2901 This section describes the rationale and security risks behind server 2902 unauthenticated tunnel provisioning mode. Server unauthenticated 2903 tunnel provisioning mode results in potential security 2904 vulnerabilities. Hence, this mode is optional in PEAPv2 2905 implementations. 2907 In order to achieve strong mutual authentication, it is best to use 2908 an out of band mechanism to pre-provision the device with strong 2909 symmetric or asymmetric keys. In addition, if the device is not 2910 physically secure (mobile or devices at public places), then it is 2911 important to ensure that the device has secure storage. 2913 Server unauthenticated tunnel provisioning mode is not recommended 2914 for use in devices which already support secure provisioning and 2915 secure credential storage capabilities, since the security 2916 vulnerabilities will outweight the benefits. 2918 If the provisioned credential is a shared key or asymmetric key 2919 issued to the peer, then the credential should only be issued to 2920 devices that can protect the provisioned credentials using secure 2921 storage, or use physical security. 2923 If the credentials are not protected, the attacker can compromise the 2924 provisioned credentials, and use it to get access to the network. 2925 Mobile light weight devices are typically not physically secure. 2926 Another concern is that credentials provisioned to a light weight 2927 mobile device that does not use secure storage could be transferred 2928 to a general operating system and used to get access to the network. 2930 If the provisioned credential is a certificate trusted root of the 2931 EAP server, this is public information and hence not susceptible to 2932 the same attacks as a shared key or asymmetric key. 2934 In server unauthenticated tunnel provisioning mode, an attacker may 2935 terminate the tunnel instead of the real server. The attacker can be 2936 detected after the Crypto-Binding TLV is exchanged and validated. 2937 However, the EAP packets exchanged inside the tunnel until Crypto- 2938 Binding TLV is validated are available in unencrypted form to the 2939 attacker. It is difficult to completely negate the security risk 2940 unless the EAP methods inside the tunnel are secure; or unless 2941 physical wire security is assumed. 2943 The standard credential request/response capability is designed to be 2944 independent of the server unauthenticated tunnel provisioning mode, 2945 and can be used in regular authentication mode to provision other 2946 credentials to the peer that can be used for authentication to the 2947 network, or for potentially authentications to other services. 2949 The security risks vary depending on the type of credential 2950 exchanged, the scope of use of the credential, and the implementation 2951 of the device. 2953 These are a few guidelines to reduce the security risk: 2955 [1] Minimize the use of this mode only during initial authentication to 2956 the network to reduce the risk of attack. 2958 [2] If the password based EAP method used in provisioned mode is 2959 susceptible to dictionary attacks, then the implementation should 2960 support deployment of sound password password policies e.g. 2961 capability to enforce strong password policies and support rotation 2962 of passwords. 2964 [3] Disable this mode by default and require users to initiate 2965 provisioning mode explicitly rather than being prompted during 2966 initiation of regular authentication process. 2968 [4] Provide appropriate policy capabilities to allow administrators to 2969 lockdown the device and prevent regular users from enabling the 2970 mode. 2972 [5] Ensure that the EAP methods used support mutual authentication. 2974 [6] Ensure that the EAP methods used generate keys of sufficient 2975 strength to prevent compounding binding from being compromised. 2977 [7] Minimize the information disclosed to the EAP server. 2979 Notes: 2981 [a] The attacker may try to crack the password in the time required for 2982 authentication to complete. 2984 [b] The attacker may start the conversation, capture the hash, and 2985 launch a offline dictionary attack. 2987 5.13. Security Claims 2989 Intended use: Wireless or Wired networks, and over 2990 the Internet, where physical security 2991 cannot be assumed. 2992 Auth. mechanism: Use arbitrary EAP and TLS authentication 2993 mechanisms for authentication of the 2994 client and server. 2995 Ciphersuite negotiation: Yes. 2996 Mutual authentication: Yes. Depends on the type of EAP method 2997 used within the tunnel and the type of 2998 authentication used within TLS. 2999 Integrity protection: Yes 3000 Replay protection: Yes 3001 Confidentiality: Yes 3002 Key derivation: Yes 3003 Key strength: Variable 3004 Dictionary attack prot: Not susceptible. 3005 Fast reconnect: Yes 3006 Crypt. binding: Yes. 3007 Acknowledged S/F: Yes 3008 Session independence: Yes. 3009 Fragmentation: Yes 3010 State Synchronization: Yes [80211Req] 3012 The PEAPv2 protocol is unconditionally compliant with the 3013 requirements for WLAN authentication mechanisms, as specified in 3014 [80211Req]. 3016 PEAPv2 derives keys by combining keys from TLS and the inner EAP 3017 methods. It should be noted that the use of TLS ciphersuites with a 3018 particular key lengths does not guarantee that the key strength of 3019 the keys will be equivalent to the length. The key exchange 3020 mechanisms (eg. RSA or Diffie-Hellman) used must provide sufficient 3021 security or they will be the weakest link. For example RSA key sizes 3022 with a modulus of 1024 bits provides less than 128 bits of security, 3023 this may provide sufficient key strength for some applications and 3024 not for others. See [PKLENGTH] for a detailed analysis of 3025 determining the public key strengths used to exchange symmetric keys. 3027 6. IANA Considerations 3029 This section provides guidance to the Internet Assigned Numbers 3030 Authority (IANA) regarding registration of values related to the 3031 PEAPv2 protocol, in accordance with BCP 26, [RFC2434]. 3033 The following name spaces in PEAPv2 require registration: TLV-Types, 3034 the Identity-Type field in the Identity-Type TLV, the Credential-Type 3035 field of the Server-Trusted-Root TLV, and the Action field of the 3036 Request-Action TLV. TLV types within Vendor-Specific TLVs do not 3037 require registration. 3039 6.1. Definition of Terms 3041 The following terms are used here with the meanings defined in BCP 3042 26: "name space", "assigned value", "registration". 3044 The following policies are used here with the meanings defined in BCP 3045 26: "Private Use", "First Come First Served", "Expert Review", 3046 "Specification Required", "IETF Consensus", "Standards Action". 3048 6.2. Recommended Registration Policies 3050 For "Designated Expert with Specification Required", the request is 3051 posted to the EAP WG mailing list (or, if it has been disbanded, a 3052 successor designated by the Area Director) for comment and review, 3053 and MUST include a pointer to a public specification. Before a 3054 period of 30 days has passed, the Designated Expert will either 3055 approve or deny the registration request and publish a notice of the 3056 decision to the EAP WG mailing list or its successor. A denial 3057 notice must be justified by an explanation and, in the cases where it 3058 is possible, concrete suggestions on how the request can be modified 3059 so as to become acceptable. 3061 TLV Types may assume a value between 0 and 16383 of which 0-20 have 3062 been allocated. Additional TLV type codes may be allocated following 3063 Designated Expert with Specification Required [RFC2434]. 3065 The Identity-Type field may assume a value between 0 and 65535, of 3066 which 0-2 have been allocated. Additional Identity-Type values may 3067 be allocated following Designated Expert with Specification Required 3069 [RFC2434]. 3071 The Credential-Type field may assume a value between 0 and 65535, of 3072 which 0-1 have already been allocated. Additional Credential-Type 3073 values may be allocated following Designated Expert with 3074 Specification Required [RFC2434]. 3076 The Action field may assume a value between 0 and 65535, of which 0-2 3077 have already been allocated. Additional Action values may be 3078 allocated following Designated Expert with Specification Required 3079 [RFC2434]. 3081 7. References 3083 7.1. Normative references 3085 [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", 3086 RFC 1321, April 1992. 3088 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3089 Requirement Levels", BCP 14, RFC 2119, March 1997. 3091 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 3092 2246, November 1998. 3094 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 3095 Architecture", RFC 2373, July 1998. 3097 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 3098 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 3099 1998. 3101 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3102 Considerations Section in RFCs", BCP 26, RFC 2434, October 3103 1998. 3105 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 3106 2486, January 1999. 3108 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 3109 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3110 3748, June 2004. 3112 [80211Req] 3113 Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 3114 for Wireless LANs", draft-walker-ieee802-req-04.txt, Internet 3115 draft (work in progress), August 2004. 3117 7.2. Informative references 3119 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 3120 1996. 3122 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. 3123 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 3124 1996. 3126 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 3127 Version 2 (DESE-bis)", RFC 2419, September 1998. 3129 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 3130 RFC 2420, September 1998. 3132 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 3133 2548, March 1999. 3135 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 3136 Authentication Dial In User Service (RADIUS)", RFC 2865, June 3137 2000. 3139 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 3140 RFC 2716, October 1999. 3142 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption 3143 (MPPE) Protocol", RFC 3078, March 2001. 3145 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 3146 Encryption (MPPE)", RFC 3079, March 2001. 3148 [RFC3546] Blake-Wilson, S., et al. "TLS Extensions", RFC 3546, June 3149 2003. 3151 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for EAP", RFC 3579, 3152 September 2003. 3154 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 3155 "IEEE 802.1X Remote Authentication Dial In User Service 3156 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 3158 [RFC3766] H. Orman and P. Hoffman, "Determining Strengths For Public 3159 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 3160 2004. 3162 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS 3163 PUB 46 (January 1977). 3165 [MODES] National Bureau of Standards, "DES Modes of Operation", FIPS 3166 PUB 81 (December 1980). 3168 [IEEE80211] 3169 Information technology - Telecommunications and information 3170 exchange between systems - Local and metropolitan area 3171 networks - Specific Requirements Part 11: Wireless LAN Medium 3172 Access Control (MAC) and Physical Layer (PHY) Specifications, 3173 IEEE Std. 802.11-2003, 2003. 3175 [IEEE802.11i] 3176 Institute of Electrical and Electronics Engineers, " 3177 Supplement to Standard for Telecommunications and Information 3178 Exchange Between Systems - LAN/MAN Specific Requirements - 3179 Part 11: Wireless LAN Medium Access Control (MAC) and Physical 3180 Layer (PHY) Specifications: Specification for Enhanced 3181 Security", IEEE 802.11i, November 2004. 3183 [IEEE8021X] 3184 IEEE Standards for Local and Metropolitan Area Networks: Port 3185 based Network Access Control, IEEE Std 802.1X-2004, November 3186 2004. 3188 [PEAPv0] Kamath, V., Palekar, A. and M. Wodrich, "Microsoft's PEAP 3189 version 0 (Implementation in Windows XP SP1)", draft-kamath- 3190 pppext-peapv0-00.txt, Internet draft (work in progress), July 3191 2002. 3193 [CompoundBinding] 3194 Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, "The 3195 Compound Authentication Binding Problem", draft-puthenkulam- 3196 eap-binding-04.txt, Internet Draft (work in progress), October 3197 2003. 3199 Appendix A - Examples 3201 A.1 Cleartext Identity Exchange 3203 In the case where an identity exchange occurs within PEAPv2 Part 1, 3204 the conversation will appear as follows: 3206 Authenticating Peer Authenticator 3207 ------------------- ------------- 3208 <- EAP-Request/ 3209 Identity 3210 EAP-Response/ 3211 Identity (MyID1) -> 3213 // Identity sent in the clear. May be a hint to help route the 3214 authentication request to EAP server, instead of the full user 3215 identity. 3217 <- EAP-Request/ 3218 EAP-Type=PEAP, V=2 3219 (PEAP Start, S bit set) 3220 EAP-Response/ 3221 EAP-Type=PEAP, V=2 3222 (TLS client_hello)-> 3223 <- EAP-Request/ 3224 EAP-Type=PEAP, V=2 3225 (TLS server_hello, 3226 TLS certificate, 3227 [TLS server_key_exchange,] 3228 [TLS certificate_request,] 3229 TLS server_hello_done) 3230 EAP-Response/ 3231 EAP-Type=PEAP, V=2 3232 ([TLS certificate,] 3233 TLS client_key_exchange, 3234 [TLS certificate_verify,] 3235 TLS change_cipher_spec, 3236 TLS finished) -> 3237 <- EAP-Request/ 3238 EAP-Type=PEAP, V=2 3239 (TLS change_cipher_spec, 3240 TLS finished, 3241 EAP-Request/EAP-Type=EAP-TLV 3242 [EAP-Payload-TLV[EAP-Request/ 3243 Identity]]) 3245 // identity protected by TLS. EAP-TLV packet does not include an EAP- 3246 header. 3248 TLS channel established (EAP messages sent within TLS channel 3249 encapsulated in EAP-TLV packets without EAP header) 3251 EAP-TLV [EAP-Payload-TLV 3252 [EAP-Response/Identity (MyID2)]]]-> 3254 <- EAP-TLV [EAP-Payload-TLV 3255 [EAP-Request/EAP-Type=X]] 3257 EAP-TLV [EAP-Payload-TLV 3258 [EAP-Response/EAP-Type=X]] -> 3260 // Protected termination 3262 <- EAP-TLV [Result TLV (Success), 3263 Crypto-Binding TLV (Version=2, 3264 received-version=2, Nonce, B1_MAC), 3265 Intermediate-Result TLV (Success)] 3267 EAP-TLV [Result TLV (Success), 3268 Intermediate-Result TLV (Success), 3269 Crypto-Binding TLV (Version=2, 3270 received-version=2,Nonce, B2_MAC)]-> 3272 TLS channel torn down 3273 (messages sent in cleartext) 3275 <- EAP-Success 3277 A.2 No cleartext Identity Exchange 3279 Where all peers are known to support PEAPv2, a non-certificate 3280 authentication is desired for the client and the PEAPv2 Part 1 3281 conversation is carried out between the peer and a local EAP server, 3282 the cleartext identity exchange may be omitted and the conversation 3283 appears as follows: 3285 Authenticating Peer Authenticator 3286 ------------------- ------------- 3287 <- EAP-Request/ 3288 EAP-Type=PEAP, V=2 3289 (PEAP Start, S bit set) 3291 EAP-Response/ 3292 EAP-Type=PEAP, V=2 3293 (TLS client_hello)-> 3294 <- EAP-Request/ 3295 EAP-Type=PEAP, V=2 3296 (TLS server_hello, 3297 TLS certificate, 3298 [TLS server_key_exchange,] 3299 [TLS certificate_request,] 3300 TLS server_hello_done) 3301 EAP-Response/ 3302 EAP-Type=PEAP, V=2 3303 ([TLS certificate,] 3304 TLS client_key_exchange, 3305 [TLS certificate_verify,] 3306 TLS change_cipher_spec, 3307 TLS finished) -> 3308 <- EAP-Request/ 3309 EAP-Type=PEAP, V=2 3310 (TLS change_cipher_spec, 3311 TLS finished, 3312 EAP-TLV [EAP-Payload-TLV 3313 (EAP-Request/Identity)]) 3315 TLS channel established 3316 (messages sent within the TLS channel) 3318 EAP-TLV [EAP-Payload-TLV 3319 [EAP-Response/Identity (MyID)]] -> 3321 <- EAP-TLV [EAP-Payload-TLV 3322 [EAP-Type=EAP-Request/ 3323 EAP-Type=X]] 3325 EAP-TLV [EAP-Payload-TLV 3326 [EAP-Response/EAP-Type=X 3327 or NAK] -> 3328 <- EAP-TLV [EAP-Payload-TLV 3329 [EAP-Request/EAP-Type=X]] 3331 EAP-TLV [EAP-Payload-TLV [EAP-Response/ 3332 EAP-Type=X]] -> 3334 // Protected success 3335 <- EAP-TLV [Crypto-Binding TLV= 3336 (Version=2, Received-version=2, 3337 Nonce, B1_MAC), 3338 Intermediate-Result TLV(Success), 3339 Result TLV (Success)] 3341 EAP-TLV [Crypto-Binding TLV= 3342 (Version=2,Received-version=2, 3343 Nonce, B2_MAC), 3344 Intermediate-Result TLV (Success), 3345 Result TLV (Success)]-> 3347 TLS channel torn down 3348 (messages sent in cleartext) 3350 <- EAP-Success 3352 A.3 Client certificate authentication with identity privacy 3354 Where all peers are known to support PEAPv2, where client certificate 3355 authentication is desired and the PEAPv2 Part 1 conversation is 3356 carried out between the peer and a local EAP server, the cleartext 3357 identity exchange may be omitted and the conversation appears as 3358 follows: 3360 Authenticating Peer Authenticator 3361 ------------------- ------------- 3362 <- EAP-Request/ 3363 EAP-Type=PEAP, V=2 3364 (PEAP Start, S bit set) 3366 EAP-Response/ 3367 EAP-Type=PEAP, V=2 3368 (TLS client_hello)-> 3369 <- EAP-Request/ 3370 EAP-Type=PEAP, V=2 3371 (TLS server_hello, 3372 TLS certificate, 3373 [TLS server_key_exchange,] 3374 TLS server_hello_done) 3375 EAP-Response/ 3376 EAP-Type=PEAP, V=2 3377 (TLS client_key_exchange, 3378 TLS change_cipher_spec, 3379 TLS finished) -> 3380 <- EAP-Request/ 3381 EAP-Type=PEAP, V=2 3382 (TLS change_cipher_spec, 3383 TLS finished,TLS Hello-Request) 3384 EAP-Response/ 3385 EAP-Type=PEAP, V=2 3386 (TLS client_hello)-> 3388 TLS channel established 3389 (messages sent within the TLS channel) 3390 <- EAP-Request/ 3391 EAP-Type=PEAP, V=2 3392 (TLS server_hello, 3393 TLS certificate, 3394 [TLS server_key_exchange,] 3395 [TLS certificate_request,] 3396 TLS server_hello_done) 3397 EAP-Response/ 3398 EAP-Type=PEAP, V=2 3399 ([TLS certificate,] 3400 TLS client_key_exchange, 3401 [TLS certificate_verify,] 3402 TLS change_cipher_spec, 3403 TLS finished) -> 3405 <- EAP-Request/ 3406 EAP-Type=PEAP, V=2 3407 (TLS change_cipher_spec, 3408 TLS finished, EAP-TLV 3409 [Crypto-Binding TLV (version=2, 3410 Received-version=2, Nonce, 3411 B1_MAC), 3412 Result TLV (Success)]) 3414 // packet format within the TLS channel 3416 EAP-TLV [ 3417 Crypto-Binding TLV=(Version=2, 3418 Received-version=2, 3419 Nonce, B2_MAC), 3420 Result TLV (Success)] 3422 TLS channel torn down 3423 (messages sent in cleartext) 3425 <- EAP-Success 3427 A.4 Fragmentation and Reassembly 3429 In the case where PEAPv2 fragmentation is required, the conversation 3430 will appear as follows: 3432 Authenticating Peer Authenticator 3433 ------------------- ------------- 3434 <- EAP-Request/ 3435 Identity 3436 EAP-Response/ 3437 Identity (MyID) -> 3438 <- EAP-Request/ 3439 EAP-Type=PEAP, V=2 3440 (PEAP Start, S bit set) 3442 EAP-Response/ 3443 EAP-Type=PEAP, V=2 3444 (TLS client_hello)-> 3445 <- EAP-Request/ 3446 EAP-Type=PEAP, V=2 3447 (TLS server_hello, 3448 TLS certificate, 3449 [TLS server_key_exchange,] 3450 [TLS certificate_request,] 3451 TLS server_hello_done) 3452 (Fragment 1: L, M bits set) 3454 EAP-Response/ 3455 EAP-Type=PEAP, V=2 -> 3457 <- EAP-Request/ 3458 EAP-Type=PEAP, V=2 3459 (Fragment 2: M bit set) 3460 EAP-Response/ 3461 EAP-Type=PEAP, V=2 -> 3462 <- EAP-Request/ 3463 EAP-Type=PEAP, V=2 3464 (Fragment 3) 3465 EAP-Response/ 3466 EAP-Type=PEAP, V=2 3467 ([TLS certificate,] 3468 TLS client_key_exchange, 3469 [TLS certificate_verify,] 3470 TLS change_cipher_spec, 3471 TLS finished) 3472 (Fragment 1: L, M bits set)-> 3474 <- EAP-Request/ 3475 EAP-Type=PEAP, V=2 3476 EAP-Response/ 3477 EAP-Type=PEAP, V=2 3478 (Fragment 2)-> 3479 <- EAP-Request/ 3480 EAP-Type=PEAP, V=2 3481 (TLS change_cipher_spec, 3482 TLS finished, EAP-TLV 3483 [EAP-Payload-TLV[ 3484 EAP-Request/Identity]]) 3486 TLS channel established 3487 (messages sent within the TLS channel) 3489 EAP-TLV 3490 [EAP-Payload-TLV 3491 [EAP-Response/Identity(myID)]] -> 3493 <- EAP-TLV [ EAP-Payload-TLV 3494 [EAP-Request/EAP-Type=X]] 3496 EAP-TLV [EAP-Payload-TLV 3497 [EAP-Response/EAP-Type=X or NAK]]-> 3499 <- EAP-TLV [ EAP-Payload-TLV 3500 [EAP-Request/EAP-Type=X]] 3502 EAP-TLV [EAP-Payload-TLV 3503 [EAP-Response/EAP-Type=X] -> 3505 <- EAP-TLV [Crypto-Binding TLV 3506 =(Version=0, Received-Version=2, 3507 Nonce, B1_MAC), 3508 Intermediate-Result TLV(Success), 3509 Result TLV (Success)] 3511 EAP-TLV [ 3512 Crypto-Binding TLV=(Version=2, 3513 Received-Version=2,Nonce, B2_MAC), 3514 Result TLV (Success), 3515 Intermediate-Result TLV (Success)] -> 3517 TLS channel torn down 3518 (messages sent in cleartext) 3520 <- EAP-Success 3522 A.5 Server authentication fails in Part 2 3524 In the case where the server authenticates to the client successfully 3525 in PEAPv2 Part 1, but the client fails to authenticate to the server 3526 in PEAPv2 Part 2, the conversation will appear as follows: 3528 Authenticating Peer Authenticator 3529 ------------------- ------------- 3530 <- EAP-Request/ 3531 Identity 3532 EAP-Response/ 3533 Identity (MyID) -> 3534 <- EAP-Request/ 3535 EAP-Type=PEAP, V=2 3536 (PEAP Start, S bit set) 3537 EAP-Response/ 3538 EAP-Type=PEAP, V=2 3539 (TLS client_hello)-> 3540 <- EAP-Request/ 3541 EAP-Type=PEAP, V=2 3542 (TLS server_hello, 3543 TLS certificate, 3544 [TLS server_key_exchange,] 3545 [TLS certificate_request,] 3546 TLS server_hello_done) 3547 EAP-Response/ 3548 EAP-Type=PEAP, V=2 3549 ([TLS certificate,] 3550 TLS client_key_exchange, 3551 [TLS certificate_verify,] 3552 TLS change_cipher_spec, 3553 TLS finished) -> 3554 <- EAP-Request/ 3555 EAP-Type=PEAP, V=2 3556 (TLS change_cipher_spec, 3557 TLS finished, EAP-TLV 3558 [EAP-Payload-TLV 3559 [EAP-Request/Identity]]) 3561 TLS channel established 3562 (messages sent within the TLS channel) 3564 EAP-TLV [EAP-Payload-TLV 3565 [EAP-Response/Identity (MyID)]] -> 3567 <- EAP-TLV [EAP-Payload-TLV 3568 [EAP-Request/EAP-Type=X]] 3570 EAP-TLV [EAP-Payload 3571 [EAP-Response/EAP-Type=X 3572 or NAK]] -> 3573 <- EAP-TLV [EAP-Payload 3574 [EAP-Request/EAP-Type=X]] 3576 EAP-TLV [EAP-Payload 3577 [EAP-Response/ 3578 EAP-Type=X]] -> 3579 <- EAP-TLV [Crypto-Binding TLV 3580 (Version=2, Received-Version=2, 3581 Nonce, B1_MAC), 3582 Intermediate-Result TLV (Failure), 3583 Result TLV (Failure)] 3585 EAP-TLV [Crypto-Binding TLV 3586 (Version=0, Received-version=2, 3587 Nonce, B2_MAC), 3588 Result TLV (Failure), 3589 Intermediate-Result TLV (Failure)] 3591 (TLS session cache entry flushed) 3592 TLS channel torn down 3593 (messages sent in cleartext) 3595 <- EAP-Failure 3597 A.6 Server authentication fails in Part 1 3599 In the case where server authentication is unsuccessful in PEAPv2 3600 Part 1, the conversation will appear as follows: 3602 Authenticating Peer Authenticator 3603 ------------------- ------------- 3604 <- EAP-Request/ 3605 Identity 3606 EAP-Response/ 3607 Identity (MyID) -> 3608 <- EAP-Request/ 3609 EAP-Type=PEAP, V=2 3610 (PEAP Start) 3611 EAP-Response/ 3612 EAP-Type=PEAP, V=2 3613 (TLS client_hello)-> 3614 <- EAP-Request/ 3615 EAP-Type=PEAP, V=2 3616 (TLS server_hello, 3617 TLS certificate, 3618 [TLS server_key_exchange,] 3619 TLS server_hello_done) 3620 EAP-Response/ 3621 EAP-Type=PEAP, V=2 3622 (TLS client_key_exchange, 3623 [TLS certificate_verify,] 3624 TLS change_cipher_spec, 3625 TLS finished) -> 3626 <- EAP-Request/ 3627 EAP-Type=PEAP, V=2 3628 (TLS change_cipher_spec, 3629 TLS finished, EAP-TLV 3630 [EAP-Payload-TLV [ 3631 EAP-Request/Identity]]) 3632 EAP-Response/ 3633 EAP-Type=PEAP, V=2 3634 (TLS Alert message) -> 3635 <- EAP-Failure 3636 (TLS session cache entry flushed) 3638 A.7 Session resume success 3640 In the case where a previously established session is being resumed, 3641 the EAP server supports TLS session cache flushing for unsuccessful 3642 PEAPv2 Part 2 authentications and both sides authenticate 3643 successfully, the conversation will appear as follows: 3645 Authenticating Peer Authenticator 3646 ------------------- ------------- 3647 <- EAP-Request/ 3648 Identity 3649 EAP-Response/ 3650 Identity (MyID) -> 3651 <- EAP-Request/ 3652 EAP-Type=PEAP,V=2 3653 (PEAP Start) 3654 EAP-Response/ 3655 EAP-Type=PEAP, V=2 3656 (TLS client_hello)-> 3657 <- EAP-Request/ 3658 EAP-Type=PEAP, V=2 3659 (TLS server_hello, 3660 TLS change_cipher_spec 3661 TLS finished) 3662 EAP-Response/ 3663 EAP-Type=PEAP, V=2 3664 (TLS change_cipher_spec, 3665 TLS finished) -> 3666 <- EAP-Request/ 3667 EAP-Type=EAP-TLV 3668 Result TLV (Success) 3670 // Compound MAC calculated using TLS keys since there were no inner 3671 EAP methods. 3673 EAP-Response/ 3674 EAP-Type=EAP-TLV 3675 Crypto-Binding TLV=(Version=2, Nonce, B2_MAC), 3676 Result TLV (Success)-> 3677 TLS channel torn down 3678 (messages sent in cleartext) 3680 <- EAP-Success 3682 A.8 Session resume failure 3684 In the case where a previously established session is being resumed, 3685 and the server authenticates to the client successfully but the 3686 client fails to authenticate to the server, the conversation will 3687 appear as follows: 3689 Authenticating Peer Authenticator 3690 ------------------- ------------- 3691 <- EAP-Request/ 3692 Identity 3693 EAP-Response/ 3694 Identity (MyID) -> 3695 <- EAP-Request/ 3696 EAP-Request/ 3697 EAP-Type=PEAP, V=2 3698 (PEAP Start) 3699 EAP-Response/ 3700 EAP-Type=PEAP, V=2 3701 (TLS client_hello) -> 3702 <- EAP-Request/ 3703 EAP-Type=PEAP, V=2 3704 (TLS server_hello, 3705 TLS change_cipher_spec, 3706 TLS finished) 3707 EAP-Response/ 3708 EAP-Type=PEAP, V=2 3709 (TLS change_cipher_spec, 3710 TLS finished) -> 3711 <- EAP-Request 3712 EAP-Type=PEAP, V=2 3713 (TLS Alert message) 3714 EAP-Response 3715 EAP-Type=PEAP, V=2 -> 3716 <- EAP-Failure 3717 (TLS session cache entry flushed) 3719 A.9 Session resume failure 3721 In the case where a previously established session is being resumed, 3722 and the server authentication is unsuccessful, the conversation will 3723 appear as follows: 3725 Authenticating Peer Authenticator 3726 ------------------- ------------- 3727 <- EAP-Request/ 3728 Identity 3729 EAP-Response/ 3730 Identity (MyID) -> 3731 <- EAP-Request/ 3732 EAP-Request/ 3733 EAP-Type=PEAP, V=2 3734 (PEAP Start) 3735 EAP-Response/ 3736 EAP-Type=PEAP, V=2 3737 (TLS client_hello)-> 3738 <- EAP-Request/ 3739 EAP-Type=PEAP, V=2 3740 (TLS server_hello, 3741 TLS change_cipher_spec, 3742 TLS finished) 3743 EAP-Response/ 3744 EAP-Type=PEAP, V=2 3745 (TLS change_cipher_spec, 3746 TLS finished) 3747 <- EAP-Request/ 3748 EAP-Type=PEAP, V=2 3749 EAP-Response/ 3750 EAP-Type=PEAP, V=2 3751 (TLS Alert message) -> 3753 (TLS session cache entry flushed) 3754 <- EAP-Failure 3756 A.10 PEAP version negotiation 3758 In the case where the peer and authenticator have mismatched PEAP 3759 versions (e.g. the peer has a pre-standard implementation with 3760 version 0, and the authenticator has an implementation compliant with 3761 this specification), the conversation will occur as follows: 3763 Authenticating Peer Authenticator 3764 ------------------- ------------- 3765 <- EAP-Request/ 3766 Identity 3767 EAP-Response/ 3768 Identity (MyID) -> 3769 <- EAP-Request/ 3770 EAP-Request/ 3771 EAP-Type=PEAP, V=2 3772 (PEAP Start) 3774 EAP-Response/ 3775 EAP-Type=PEAP, V=0 3776 (TLS client_hello)-> 3777 <- EAP-Request/ 3778 EAP-Type=PEAP, V=0 3779 (TLS server_hello, 3780 TLS change_cipher_spec, 3781 TLS finished) 3783 //conversation continued using pre-standard PEAP version 0 3785 A.11 Sequences of EAP methods 3787 Where PEAPv2 is negotiated, with a sequence of EAP method X followed 3788 by method Y, the conversation will occur as follows: 3790 Authenticating Peer Authenticator 3791 ------------------- ------------- 3792 <- EAP-Request/ 3793 Identity 3794 EAP-Response/ 3795 Identity (MyID1) -> 3796 <- EAP-Request/ 3797 EAP-Type=PEAP, V=2 3798 (PEAP Start, S bit set) 3800 EAP-Response/ 3801 EAP-Type=PEAP, V=2 3802 (TLS client_hello)-> 3803 <- EAP-Request/ 3804 EAP-Type=PEAP, V=2 3805 (TLS server_hello, 3806 TLS certificate, 3807 [TLS server_key_exchange,] 3808 [TLS certificate_request,] 3809 TLS server_hello_done) 3810 EAP-Response/ 3811 EAP-Type=PEAP, V=2 3812 ([TLS certificate,] 3813 TLS client_key_exchange, 3814 [TLS certificate_verify,] 3815 TLS change_cipher_spec, 3816 TLS finished) -> 3817 <- EAP-Request/ 3818 EAP-Type=PEAP, V=2 3819 (TLS change_cipher_spec, 3820 TLS finished, EAP-TLV 3822 [EAP-Payload TLV[ 3823 EAP-Request/Identity]]) 3825 TLS channel established 3826 (messages sent within the TLS channel) 3828 EAP-TLV [EAP-Payload TLV 3829 [EAP-Response/Identity]] -> 3831 <- EAP-TLV [EAP-Payload TLV 3832 [EAP-Request/EAP-Type=X]]] 3834 EAP-TLV [EAP-Payload-TLV 3835 [EAP-Response/EAP-Type=X]] -> 3837 <- EAP-TLV [ EAP-Payload TLV 3838 [EAP-Request/EAP-Type=X]] 3840 EAP-TLV [EAP-Payload TLV 3841 [EAP-Response/EAP-Type=X]]-> 3843 <- EAP-TLV [EAP-Payload TLV [EAP-Type=Y], 3844 (Intermediate Result TLV (Success), 3845 Crypto-Binding TLV 3846 (Version=2, Received-version=2, 3847 Nonce, B1_MAC))] 3849 // Next EAP conversation started after successful completion of 3850 previous method X. The Intermediate-Status and Crypto-Binding TLVs 3851 are sent in next packet to minimize round-trips. In this example, 3852 identity request is not sent before negotiating EAP-Type=Y. 3854 EAP-TLV [EAP-Payload-TLV [EAP-Type=Y], 3855 (Intermediate Result TLV (Success), 3856 Crypto-Binding TLV (Version=2, 3857 Received-version=2, Nonce, B2_MAC))]-> 3859 // Compound MAC calculated using Keys generated from 3860 EAP methods X and the TLS tunnel. 3862 <- EAP-TLV [EAP Payload TLV [ 3863 EAP-Type=Y]] 3865 EAP-TLV[EAP Payload TLV 3866 [EAP-Type=Y]] -> 3867 <- EAP-TLV [Result TLV (Success), 3868 Intermediate Result TLV (Success), 3869 Crypto-Binding TLV 3870 (Version=2, Received-version=2, 3871 Nonce, B1_MAC))] 3873 EAP-TLV [(Result TLV (Success), 3874 Intermediate Result TLV (Success), 3875 Crypto-Binding TLV (Version=2, 3876 Received-version=2, Nonce, B2_MAC))]-> 3878 // Compound MAC calculated using Keys generated from EAP methods X 3879 and Y and the TLS tunnel. // Compound Keys generated using Keys 3880 generated from EAP methods X and Y; and the TLS tunnel. 3882 TLS channel torn down (messages sent in cleartext) 3884 <- EAP-Success 3885 A.12 Successful Session Resume with Server-Identifier TLV 3887 In the case where an server-identifier TLV is used by server to 3888 indicate its identity, the conversation will appear as follows: 3890 Authenticating Peer Authenticator 3891 ------------------- ------------- 3892 <- EAP-Request/ 3893 Identity 3894 EAP-Response/ 3895 Identity (MyID1) -> 3897 // The T bit is set to indicate the TLS message length. The bytes 3898 after TLS Data (which is in this case is zero length) are the Outer- 3899 TLVs. The Server-Identifier-TLV is sent in the clear. 3901 <- EAP-Request/ 3902 EAP-Type=PEAP, V=2 3903 (PEAP Start, S bit set, T bit set), 3904 TLS message length=0, 3905 Server-Identitifer TLV 3906 // The Server-Identifier TLV identifies the server. The peer selects 3907 a session handle that corresponds to that specific server to that the 3908 TLS session could be resumed (instead of going through the full 3909 handshake) 3911 EAP-Response/ 3912 EAP-Type=PEAP, V=2 3913 (TLS client_hello)-> 3915 // subsequent packets are same as example "session resume success" 3917 Acknowledgments 3919 Thanks to Hakan Andersson, Jan-Ove Larsson and Magnus Nystrom of RSA 3920 Security; Bernard Aboba, Vivek Kamath, Stephen Bensley and Narendra 3921 Gidwani of Microsoft; Ilan Frenkel and Nancy Cam-Winget of Cisco; 3922 Jose Puthenkulam of Intel for their contributions and critiques. 3924 The compound binding exchange to address man-in-the-middle attack is 3925 based on the draft "The Compound Authentication Binding 3926 Problem"[CompoundBinding]. 3928 The vast majority of the work by Simon Josefsson and Hakan Andersson 3929 was done while they were employed at RSA Laboratories. 3931 Author Addresses 3933 Ashwin Palekar 3934 Microsoft Corporation 3935 One Microsoft Way 3936 Redmond, WA 98052 3938 Phone: +1 425 882 8080 3939 EMail: ashwinp@microsoft.com 3941 Dan Simon 3942 Microsoft Corporation 3943 One Microsoft Way 3944 Redmond, WA 98052 3946 Phone: +1 425 706 6711 3947 EMail: dansimon@microsoft.com 3949 Glen Zorn 3950 Cisco Systems 3951 500 108th Avenue N.E. 3952 Suite 500 3953 Bellevue, Washington 98004 3955 Phone: + 1 425 438 8210 3956 Fax: + 1 425 438 1848 3957 EMail: gwz@cisco.com 3959 Simon Josefsson 3960 Drottningholmsvagen 70 3961 112 42 Stockholm 3962 Sweden 3964 Phone: +46 8 619 04 22 3965 EMail: jas@extundo.com 3967 Hao Zhou 3968 Cisco Systems, Inc. 3969 4125 Highlander Parkway 3970 Richfield, OH 44286 3972 Phone: +1 330 523 2132 3973 Fax: +1 330 523 2239 3974 EMail: hzhou@cisco.com 3976 Joseph Salowey 3977 Cisco Systems 3978 2901 3rd Ave 3979 Seattle, WA 98121 3981 Phone: +1 206 256 3380 3982 EMail: jsalowey@cisco.com 3984 Intellectual Property Statement 3986 The IETF takes no position regarding the validity or scope of any 3987 intellectual property or other rights that might be claimed to 3988 pertain to the implementation or use of the technology described in 3989 this document or the extent to which any license under such rights 3990 might or might not be available; neither does it represent that it 3991 has made any effort to identify any such rights. Information on the 3992 IETF's procedures with respect to rights in standards-track and 3993 standards-related documentation can be found in BCP-11. Copies of 3994 claims of rights made available for publication and any assurances of 3995 licenses to be made available, or the result of an attempt made to 3996 obtain a general license or permission for the use of such 3997 proprietary rights by implementors or users of this specification can 3998 be obtained from the IETF Secretariat. 4000 The IETF invites any interested party to bring to its attention any 4001 copyrights, patents or patent applications, or other proprietary 4002 rights which may cover technology that may be required to practice 4003 this standard. Please address the information to the IETF Executive 4004 Director. 4006 Disclaimer of Validity 4008 This document and the information contained herein are provided on an 4009 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4010 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4011 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4012 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4013 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4014 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4016 Copyright Statement 4018 Copyright (C) The Internet Society (2004). This document is subject 4019 to the rights, licenses and restrictions contained in BCP 78, and 4020 except as set forth therein, the authors retain all their rights. 4022 Open Issues 4024 Open issues relating to this specification are tracked on the 4025 following web site: 4027 http://www.drizzle.com/~aboba/PEAP/