idnits 2.17.1 draft-josefsson-pppext-eap-tls-eap-09.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 3959. ** 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? ** 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 84 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 85 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 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 488 has weird spacing: '...er, the conve...' == Line 780 has weird spacing: '...root of a ser...' == Line 906 has weird spacing: '...lic key in th...' == Line 1107 has weird spacing: '...include the 6...' == Line 2505 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: 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 2909 -- Looks like a reference, but probably isn't: '2' on line 2912 -- Looks like a reference, but probably isn't: '3' on line 2918 -- Looks like a reference, but probably isn't: '4' on line 2922 == Missing Reference: 'Issue' is mentioned on line 3174, but not defined == Missing Reference: 'RFC2315' is mentioned on line 2282, but not defined == Missing Reference: 'RFC228bis' is mentioned on line 2841, but not defined -- Looks like a reference, but probably isn't: '5' on line 2926 -- Looks like a reference, but probably isn't: '6' on line 2928 -- Looks like a reference, but probably isn't: '7' on line 2931 == Missing Reference: 'PKLENGTH' is mentioned on line 2998, but not defined == Unused Reference: 'RFC1321' is defined on line 3058, but no explicit reference was found in the text == Unused Reference: 'RFC2373' is defined on line 3067, but no explicit reference was found in the text == Unused Reference: 'IEEE802.11i' is defined on line 3092, but no explicit reference was found in the text == Unused Reference: '80211Req' is defined on line 3105, but no explicit reference was found in the text == Unused Reference: 'RFC2419' is defined on line 3119, but no explicit reference was found in the text == Unused Reference: 'RFC2420' is defined on line 3122, but no explicit reference was found in the text == Unused Reference: 'RFC3078' is defined on line 3135, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 3138, but no explicit reference was found in the text == Unused Reference: 'RFC3766' is defined on line 3151, but no explicit reference was found in the text == Unused Reference: 'FIPSDES' is defined on line 3155, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 3158, but no explicit reference was found in the text == Unused Reference: 'PEAPv0' is defined on line 3161, but no explicit reference was found in the text == Unused Reference: 'CompoundBinding' is defined on line 3166, 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 2486 (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- 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: 15 errors (**), 0 flaws (~~), 34 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group Ashwin Palekar 3 INTERNET-DRAFT Dan Simon 4 Category: Informational Microsoft Corporation 5 Joe Salowey 6 8 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 for support of 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 optimized session resumption, 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 ..................................... 10 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 .......................... 26 70 3.1 PEAP Protocol Layers ........................... 26 71 3.2 PEAPv2 Packet Format ........................... 27 72 4. TLVs ................................................. 28 73 4.1 TLV format ..................................... 29 74 4.2 TLS-Payload TLV ................................ 30 75 4.3 Result TLV ..................................... 31 76 4.4 NAK TLV ........................................ 32 77 4.5 Crypto-Binding TLV ............................. 33 78 4.6 Connection-Binding TLV ......................... 36 79 4.7 Vendor-Specific TLV ............................ 37 80 4.8 URI TLV ........................................ 38 81 4.9 EAP Payload TLV ................................ 39 82 4.10 Intermediate Result TLV ........................ 40 83 4.11 Reserved TLVs .................................. 41 84 4.12 Calling-Station-Id TLV ......................... 41 85 4.13 Called-Station-Id TLV .......................... 43 86 4.14 NAS-Port-Type TLV .............................. 44 87 4.15 Server-Identifier TLV .......................... 45 88 4.16 Identity-Type TLV .............................. 46 89 4.17 Server-Trusted-Root TLV ........................ 47 90 4.18 PKCS #7 TLV .................................... 48 91 4.19 Request-Action TLV ............................. 49 92 4.20 TLV Rules ...................................... 50 94 5. Security considerations .............................. 52 95 5.1 Authentication and Integrity Protection ........ 52 96 5.2 Method Negotiation ............................. 53 97 5.3 TLS Session Cache Handling ..................... 54 98 5.4 Certificate Revocation ......................... 55 99 5.5 Separation of EAP server and Authenticator ..... 56 100 5.6 Separation of PEAPv2 Part 1 and Part 2 Servers . 56 101 5.7 Identity Verification .......................... 58 102 5.8 Man-in-the-middle Attack Protection ............ 59 103 5.9 Cleartext Forgeries ............................ 60 104 5.10 TLS Ciphersuites ............................... 61 105 5.11 Denial of Service Attacks ...................... 61 106 5.12 Server Unauthenticated Provisioning Mode ....... 61 107 5.13 Security Claims ................................ 64 108 6. IANA Considerations ................................. 64 109 6.1 Definition of Terms ............................ 65 110 6.2 Recommended Registration Policies .............. 65 111 7. References .......................................... 65 112 7.1 Normative References ........................... 65 113 7.2 Informative References ......................... 66 114 Appendix A - Examples ........................................ 69 115 Acknowledgments .............................................. 83 116 Author's Addresses ........................................... 83 117 Intellectual Property Statement .............................. 84 118 Disclaimer of Validity ....................................... 85 119 Copyright Statement .......................................... 85 120 1. Introduction 122 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 123 provides for support of multiple authentication methods. EAP over 124 PPP, 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 6.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 (64 octets) that is derived between the PEAPv2 307 client and server and exported by the PEAPv2 implementation. 309 Extended Master Session Key (EMSK) 310 Additional keying material (64 octets) derived between the EAP 311 client and server that is exported by the EAP method. The EMSK is 312 known only to the EAP peer and server and is not provided to a 313 third party. 315 TLV TLV standards for objects of format Type-Length-Value. The TLV 316 format is defined in Section 4 of this document. 318 1.3. Operational Model 320 In EAP, the EAP server may be implemented either within a Network 321 Access Server (NAS) or on a backend authentication server. Where the 322 EAP server resides on a NAS, the NAS is required to implement the 323 desired EAP methods, and therefore needs to be upgraded to support 324 each new EAP method. 326 One of the goals of EAP is to enable development of new 327 authentication methods without requiring deployment of new code on 328 the Network Access Server (NAS). Where a backend authentication 329 server is deployed, the NAS acts as a "passthrough" and need not 330 understand specific EAP methods. 332 This allows new EAP methods to be deployed on the EAP peer and 333 backend authentication server, without the need to upgrade code 334 residing on the NAS. 336 Figure 1 describes the relationship between the EAP peer, NAS and EAP 337 server. As described in the figure, the EAP conversation occurs 338 between the EAP peer and EAP server, "passing through" the NAS. In 339 order for the conversation to proceed in the case where the NAS and 340 EAP server reside on separate machines, the NAS and EAP server need 341 to establish trust beforehand. 343 In PEAPv2, the conversation between the EAP peer and the EAP server 344 is encrypted, authenticated, integrity and replay protected within a 345 TLS channel. 347 As a result, where the NAS acts as a "passthrough" it does not have 348 knowledge of the TLS master secret derived between the peer and the 349 EAP server. In order to provide keying material for link-layer 350 ciphersuites, the NAS obtains the master session key, which is 351 derived from a one-way function of the TLS master secret as well as 352 keying material provided by EAP methods protected within a TLS 353 channel. This enables the NAS and EAP peer to subsequently derive 354 transient session keys suitable for encrypting, authenticating and 355 integrity protecting session data. However, the NAS cannot decrypt 356 the PEAPv2 conversation or spoof session resumption, since this 357 requires knowledge of the TLS master secret. 359 +-+-+-+-+-+ +-+-+-+-+-+ 360 | | | | 361 | Link | | Link | 362 | Layer | | Layer | 363 | Cipher- | | Cipher- | 364 | Suite | | Suite | 365 | | | | 366 +-+-+-+-+-+ +-+-+-+-+-+ 367 ^ ^ 368 | | 369 | | 370 | | 371 V V 372 +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ 373 | | EAP | |<======>| | 374 | | Conversation | | | | 375 | EAP |<================================>| EAP | 376 | Peer | (over PPP, | NAS | | Server | 377 | | 802.11,etc.) | |<=======| | 378 | | | | Keys | | 379 | | | | | | 380 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 381 ^ ^ 382 | | 383 | EAP API | EAP API 384 | | 385 V V 386 +-+-+-+-+-+ +-+-+-+-+-+ 387 | | | | 388 | | | | 389 | EAP | | EAP | 390 | Method | | Method | 391 | | | | 392 +-+-+-+-+-+ +-+-+-+-+-+ 394 Figure 1 - Relationship between EAP client, backend 395 authentication server and NAS. 397 1.3.1. Sequences 399 EAP [RFC3748] prohibits use of multiple authentication methods within 400 a single EAP conversation, except when tunneled methods such as 401 PEAPv2 are used. This restriction was imposed in order to limit 402 vulnerabilities to man-in-the-middle attacks as well as to ensure 403 compatibility with existing EAP implementations. 405 Within PEAP these concerns are addressed since PEAPv2 includes 406 support for cryptographic binding to address man-in-the-middle 407 attacks, as well as version negotiation so as to enable backward 408 compatibility with prior versions of PEAP. 410 Within this document, the term "sequence" refers to a series of EAP 411 authentication methods run in sequence or TLV exchanges before or 412 after EAP methods. The methods need not be distinct - for example, 413 EAP-TLS could be run initially with machine credentials followed by 414 the same protocol authenticating with user credentials. 416 PEAPv2 supports two types of sequences: 418 [1] Serial authentication. Initiating additional EAP method(s) after a 419 first successful authentication. In this case the sequence is 420 successful if each of the EAP authentication methods completes 421 successfully. For example, successful authentication might require 422 a successful machine authentication followed by a successful user 423 authentication. 425 [2] Parallel authentication. Initiating an alternative EAP method after 426 failure of one or more initial methods. In this case the overall 427 authentication is successful if any of the methods is successful. 428 For example, if machine authentication fails, then user 429 authentication can be attempted. 431 2. Protocol Overview 433 Protected EAP (PEAP) Version 2 is comprised of a two-part 434 conversation: 436 [1] In Part 1, a TLS session is negotiated, with server authenticating 437 to the client and optionally the client to the server. The 438 negotiated key is then used to encrypt the rest of the 439 conversation. 441 [2] In Part 2, within the TLS session, zero or more EAP methods are 442 carried out. Part 2 completes with a success/failure indication 443 protected by the TLS session or a protected error (TLS alert). 445 In the next two sections, we provide an overview of each of the parts 446 of the PEAPv2 conversation. 448 2.1. PEAPv2 Part 1 450 2.1.1. Initial identity exchange 452 The PEAP conversation typically begins with an optional identity 453 exchange. The authenticator will typically send an EAP- 454 Request/Identity packet to the peer, and the peer will respond with 455 an EAP-Response/Identity packet to the authenticator. 457 The initial identity exchange is used primarily to route the EAP 458 conversation to the EAP server. Since the initial identity exchange 459 is in the clear, the peer MAY decide to place a routing realm instead 460 of its real name in the EAP-Response/Identity. The real identity of 461 the peer can be established later in PEAPv2 part 2. 463 If the EAP server is known in advance (such as when all users 464 authenticate against the same backend server infrastructure and 465 roaming is not supported), or if the identity is otherwise determined 466 (such as from the dialing phone number or client MAC address), then 467 the EAP-Request/Response-identity exchange MAY be omitted. 469 Once the optional initial Identity Request/Response exchange is 470 completed, while nominally the EAP conversation occurs between the 471 authenticator and the peer, the authenticator MAY act as a 472 passthrough device, with the EAP packets received from the peer being 473 encapsulated for transmission to a backend authentication server. 474 However, PEAP does not require a backend authentication server; if 475 the authenticator implements PEAP, then it can authenticate local 476 users. 478 In the discussion that follows, we will use the term "EAP server" to 479 denote the ultimate endpoint conversing with the peer. 481 2.1.2. TLS Session Establishment 483 In this section, the protocol is described, and in Appendix A, 484 examples of protocol exchanges are provided. While this section and 485 the examples in Appendix A often describe negotiation of a 486 certificate-based ciphersuite within TLS, PEAPv2 supports negotiation 487 of other ciphersuites (for example, ciphersuites that do not use 488 certificates) or extensions. However, the conversation may slightly 489 differ if other TLS ciphersuites or extensions are used. 491 Once having received the peer's Identity, and determined that PEAP 492 authentication is to occur, the EAP server MUST respond with a 493 PEAP/Start packet, which is an EAP-Request packet with EAP-Type=PEAP, 494 the Start (S) bit set, the PEAP version as specified in Section 495 2.1.5, and optionally, the Server-Identity TLV. 497 Assuming that the peer supports PEAP, the PEAP conversation will then 498 begin, with the peer sending an EAP-Response packet with EAP- 499 Type=PEAP. The Type-data field of the EAP-Response Packet will 500 encapsulate one or more TLS records containing the TLS handshake 501 messages. As defined in [RFC2246], the TLS handshake is used to 502 negotiate parameters and cryptographic keys and may take several 503 roundtrips between the client and server. 505 The version offered by the client and server MUST be TLS v1.0 or 506 later. PEAP implementations need not necessarily support all TLS 507 ciphersuites listed in [RFC2246]. Not all TLS ciphersuites are 508 supported by available TLS tool kits and licenses may be required in 509 some cases. 511 To ensure interoperability, PEAPv2 peers and servers MUST support the 512 TLS v1.0 [RFC2246] mandatory-to-implement ciphersuite: 514 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 516 In addition, PEAPv2 servers SHOULD support and be able to negotiate 517 the following TLS ciphersuites: 519 TLS_RSA_WITH_3DES_EDE_CBC_SHA 520 TLS_RSA_WITH_RC4_128_MD5 521 TLS_RSA_WITH_RC4_128_SHA 522 TLS_RSA_WITH_AES_128_CBC_SHA 524 In addition, PEAPv2 peers SHOULD support at least one of the 525 following TLS ciphersuites: 527 TLS_RSA_WITH_3DES_EDE_CBC_SHA 528 TLS_RSA_WITH_RC4_128_MD5 529 TLS_RSA_WITH_RC4_128_SHA 530 TLS_RSA_WITH_AES_128_CBC_SHA 532 TLS as described in [RFC2246] supports compression as well as 533 ciphersuite negotiation. Therefore during the PEAPv2 Part 1 534 conversation the PEAPv2 endpoints MAY request or negotiate TLS 535 compression. 537 If the full TLS handshake is performed, then the first payload of 538 PEAPv2 part 2 is sent along with finished handshake message to reduce 539 number of round trips. 541 Since after the TLS session is established, another complete EAP 542 negotiation will occur and the peer will authenticate using a 543 secondary mechanism, with PEAPv2 the client need not authenticate as 544 part of TLS session establishment. 546 Note that since TLS client certificates are sent in the clear, if 547 identity protection is required, then it is possible for the TLS 548 authentication to be re-negotiated after the first server 549 authentication. To accomplish this, the server will typically not 550 request a certificate in the server_hello, then after the 551 server_finished message is sent, and before PEAP part 2, the server 552 MAY send a TLS hello_request. This allows the client to perform 553 client authentication by sending a client_hello if it wants to, or 554 send a no_renegotiation alert to the server indicating that it wants 555 to continue with PEAP part 2 instead. Assuming that the client 556 permits renegotiation by sending a client_hello, then the server will 557 respond with server_hello, a certificate and certificate_request 558 messages. The client replies with certificate, client_key_exchange 559 and certificate_verify messages. Since this re-negotiation occurs 560 within the encrypted TLS channel, it does not reveal client 561 certificate details. 563 2.1.3. Session Resumption 565 The purpose of the sessionId within the TLS protocol and the Server- 566 Identifier TLV in PEAP is to allow for improved efficiency in the 567 case where a client repeatedly attempts to authenticate to an EAP 568 server within a short period of time. This capability is 569 particularly useful for support of wireless roaming. 571 In order to help the peer choose a sessionID that belongs to the 572 specific server, the EAP server MAY send an identifier (Server- 573 Identifier TLV) that the peer can use as a hint. The Server- 574 Identifier TLV MAY be sent in the first PEAP packet from the EAP 575 server to the peer. In order to detect modification of the Server- 576 Identifier TLV, the Server-Identifier TLV is included in calculation 577 of the compound MAC. 579 It is left up to the peer whether to attempt to continue a previous 580 session, thus shortening the PEAP Part 1 conversation. Typically the 581 peer's decision will be made based on the time elapsed since the 582 previous authentication attempt to that EAP server. 584 Based on the sessionId chosen by the peer, and the time elapsed since 585 the previous authentication, the EAP server will decide whether to 586 allow the continuation, or whether to choose a new session. 588 In the case where the EAP server and the authenticator reside on the 589 same device, then the client will only be able to continue sessions 590 when connecting to the same NAS or channel server. Should devices be 591 set up in a rotary or round-robin, where the Server-Identifier TLV is 592 not used, it may not be possible for the peer to know in advance the 593 authenticator it will be connecting to, and therefore which sessionId 594 to attempt to reuse. As a result, the continuation attempt is likely 595 to fail. 597 In the case where the EAP authentication is remoted then continuation 598 is much more likely to be successful, since multiple NAS devices and 599 channel servers will remote their EAP authentications to the same 600 backend authentication server. 602 If the EAP server is resuming a previously established session, then 603 it MUST include only a TLS change_cipher_spec message and a TLS 604 finished handshake message after the server_hello message. The 605 finished message contains the EAP server's authentication response to 606 the peer. 608 If the preceding server_hello message sent by the EAP server in the 609 preceding EAP-Request packet indicated the resumption of a previous 610 session, then the peer MUST send only the change_cipher_spec and 611 finished handshake messages. The finished message contains the 612 peer's authentication response to the EAP server. The latter contains 613 the EAP server's authentication response to the peer. The peer will 614 verify the hash in order to authenticate the EAP server. 616 If authentication fails, then the peer and EAP-server MUST follow the 617 error handling behavior specified in section 2.3. 619 Even if the session is successfully resumed with the same EAP server, 620 the peer and EAP server MUST NOT assume that either will skip inner 621 EAP methods. The peer may have roamed to a network which may use the 622 same EAP server, but may require conformance with a different 623 authentication policy. 625 2.1.4. Version Negotiation 627 PEAP packets contain a three bit version field, which enables PEAP 628 implementations to be backward compatible with previous versions of 629 the protocol. This specification documents the PEAP version 2 630 protocol; implementations of this specification MUST use a version 631 field set to 2. Version negotiation proceeds as follows: 633 [1] In the first EAP-Request sent with EAP-Type=PEAP, the EAP server 634 MUST set the version field to the highest supported version number. 636 [2] If the EAP peer supports this version of the protocol, it MUST 637 respond with an EAP-Response of EAP-Type=PEAP, and the version 638 number proposed by the EAP server. 640 [3] If the EAP peer does not support this version, it responds with an 641 EAP-Response of EAP-Type=PEAP and the highest supported version 642 number. 644 [4] If the PEAP server does not support the version number proposed by 645 the PEAP peer, it terminates the conversation, as described in 646 Section 2.2.2. 648 The version negotiation procedure guarantees that the EAP peer and 649 server will agree to the latest version supported by both parties. 650 If version negotiation fails, then use of PEAP will not be possible, 651 and another mutually acceptable EAP method will need to be negotiated 652 if authentication is to proceed. 654 The PEAP version field is not protected by TLS and therefore can be 655 modified in transit. In order to detect modification of the PEAP 656 version which could occur as part of a "downgrade" attack, the peer 657 and EAP server check if the version it sent during negotiation is 658 same as the version claimed to be received by the other party. Each 659 party uses the Crypto-Binding TLV to inform the other party of the 660 version number it received during the PEAP version negotiation. The 661 receiver of the crypto binding TLV must verify that the version in 662 the crypto binding TLV matches the version it sent during PEAP 663 version negotiation. 665 2.2. PEAPv2 Part 2 667 The second portion of the PEAPv2 conversation typically consists of a 668 complete EAP conversation occurring within the TLS session negotiated 669 in PEAPv2 Part 1; ending with protected termination using the Result- 670 TLV. PEAPv2 part 2 will occur only if establishment of a new TLS 671 session in Part 1 is successful or a TLS session is successfully 672 resumed in Part 1. In cases where a new TLS session is established 673 in PEAPv2 part 1, the first payload of the part 2 conversation is 674 sent by the EAP server along with the finished message to save a 675 round-trip. 677 Part 2 SHOULD NOT occur if the EAP Server authenticates 678 unsuccessfully, and MUST NOT occur if establishment of the TLS 679 session in part 1 was not successful Or a TLS fatal error has been 680 sent terminating the conversation. 682 Since all packets sent within the PEAPv2 Part 2 conversation occur 683 after TLS session establishment, they are protected using the 684 negotiated TLS ciphersuite. All EAP packets of the EAP conversation 685 in part 2 including the EAP header of the inner EAP method are 686 protected using the negotiated TLS ciphersuite. 688 Part 2 MAY NOT always include a EAP conversation within the TLS 689 session, referred to in this document as inner EAP methods. However, 690 Part 2 MUST always end with either protected termination or protected 691 error termination (e.g. TLS alert). 693 Within Part 2, protected EAP conversation and protected termination 694 packets are always carried within TLVs. There are TLVs defined for 695 specific purposes such as carrying EAP-authentication messages and 696 carrying cryptographic binding. New TLVs may be developed for other 697 purposes. 699 2.2.1. Protected Conversation 701 Part 2 of the PEAPv2 conversation typically begins with the EAP 702 server sending an optional EAP-Request/Identity packet to the peer, 703 protected by the TLS ciphersuite negotiated in PEAPv2 Part 1. The 704 peer responds with an EAP-Response/Identity packet to the EAP server, 705 containing the peer's userId. Since this Identity Request/Response 706 exchange is protected by the ciphersuite negotiated in TLS, it is not 707 vulnerable to snooping or packet modification attacks. 709 After the TLS session-protected Identity exchange, the EAP server 710 will then select authentication method(s) for the peer, and will send 711 an EAP-Request with the Type field set to the initial method. As 712 described in [RFC3748], the peer can NAK the suggested EAP method, 713 suggesting an alternative. Since the NAK will be sent within the TLS 714 channel, it is protected from snooping or packet modification. As a 715 result, an attacker snooping on the exchange will be unable to inject 716 NAKs in order to "negotiate down" the authentication method. An 717 attacker will also not be able to determine which EAP method was 718 negotiated. 720 The EAP conversation within the TLS protected session may involve a 721 sequence of zero or more EAP authentication methods; it completes 722 with the protected termination described in Section 2.2.2. Several 723 TLVs may be included in each Request and Response. EAP methods are 724 always encapsulated within EAP Payload-TLV. 726 In a typical EAP conversation, the result of the conversation is 727 communicated by sending EAP Success or EAP Failure packets after the 728 EAP method is complete. The EAP Success or Failure packet is 729 considered the last packet of the EAP conversation; and therefore 730 cannot be used when sequences need to be supported. Hence, instead 731 of using the EAP-success or EAP-failure packet, both peer and EAP 732 server MUST use the Intermediate Result TLV to communicate the 733 result. 735 In a typical EAP conversation, the EAP Success or EAP Failure is 736 considered the last packet of the EAP conversation. Within PEAPv2, 737 the EAP server can start another EAP method after success or failure 738 of the previous EAP method inside the protected session. 740 In a sequence of more than one EAP authentication method, to make 741 sure the same parties are involved in tunnel establishment and 742 successful completion of previous inner EAP methods, before 743 completing negotiation of the next EAP method, both peer and EAP 744 server MUST use crypto binding (Crypto-Binding TLV). If no EAP 745 methods have been negotiated inside the tunnel or no EAP methods have 746 been successfully completed inside the tunnel, the Crypto-Binding TLV 747 MUST NOT be used. 749 The Intermediate-Result TLV and Crypto-Binding TLV MUST be sent after 750 each EAP method that was successful. If the EAP method failed, or if 751 the EAP method negotiation did not complete, then an Intermediate- 752 Result TLV MAY be included, and the Crypto-Binding TLV MUST NOT be 753 included. An exception is that the Crypto-Binding TLV MUST be sent 754 along with a protected success/failure indication as described in 755 Section 2.2.2. 757 If these TLVs are not sent after a successful EAP method, it should 758 be considered a tunnel compromise error by peer and EAP server, 759 resulting in terminating the conversation as described in Section 760 2.3. 762 A subsequent EAP conversation can be started after both TLVs are 763 exchanged in a TLV packet. Alternatively, if a subsequent EAP 764 conversation is being attempted, then in order to reduce round trips, 765 both TLVs SHOULD be sent with the EAP-Payload of the first EAP packet 766 of the next EAP conversation (for example, EAP- Identity or EAP- 767 packet of the EAP method). Alternatively, if the next packet is the 768 protected success/failure packet, then in order to reduce round 769 trips, both TLVs MUST be sent with the protected success/failure 770 packet. 772 If the EAP server sends a valid Crypto-Binding-TLV to the peer, the 773 peer MUST respond with a Crypto-Binding TLV. If the Crypto-Binding- 774 TLV is invalid, it should be considered a tunnel compromise error by 775 the peer. If the peer does not respond with a TLV packet containing 776 the Crypto-Binding TLV, it MUST be considered a tunnel compromise 777 error by the EAP server. 779 Within a PEAPv2 part 2 conversation, a peer MAY request the trusted 780 root of a server certificate using a Server-Trusted-Root TLV, and 781 the EAP server MAY respond with a Server-Trusted-Root TLV to the 782 peer. The Server-Trusted-Root can be exchanged in regular 783 authentication mode or server unauthenticated tunnel provisioning 784 mode. 786 After the peer has determined that it has successfully authenticated 787 the EAP server and determined that the tunnel and inner EAP methods 788 were between the same peer and EAP server by validating the Crypto- 789 Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked 790 as optional) to request the trusted root of server certificate from 791 the EAP server. The peer may receive a response, but is not required 792 to use the trusted root received from the EAP server. 794 If the EAP server has determined that it has successfully 795 authenticated the peer and determined that the tunnel and inner EAP 796 methods were between the same peer and EAP server by validating the 797 Crypto-Binding TLV, then it MAY respond with the the server-trusted- 798 root containing the PCKS#7 TLV. 800 2.2.2. Protected Termination 802 The PEAPv2 part 2 conversation is completed by exchanges of 803 success/failure indications (Result-TLV) within a TLV packet 804 protected by the TLS session. 806 Even if Crypto-Binding TLVs have been exchanged in previous 807 conversations, the Crypto-Binding TLV MUST be included in both 808 protected success/failure (Result-TLV) indications. If the TLVs are 809 not included, or if the TLVs are invalid, it should be considered a 810 tunnel compromise error, and the peer and EAP server MUST follow the 811 rules described in Section 2.3 to abort the conversation. 813 The Result TLV is sent within the TLS channel. The PEAP client then 814 replies with a Result-TLV. The conversation concludes with the PEAP 815 server sending a cleartext success/failure indication. 817 The only outcome which should be considered as successful 818 authentication is when a Result-TLV of Status=Success is answered by 819 the peer with a Result TLV of Status=Success. 821 The combinations (Result-TLV=Failure, Result-TLV=Success), (Result- 822 TLV=Failure, Result-TLV=Failure), (no TLVs exchange or no protected 823 success or failure) should be considered an authentication failure by 824 both the peer and EAP server. Once the peer and EAP server consider 825 that authentiation has failed, these are the last packets inside the 826 protected tunnel. These combinations are considered an 827 authentication failure regardless of whether a cleartext EAP Success 828 or EAP Failure packet is subsequently sent. 830 If the EAP server wants authentication to fail, it sends the TLV 831 response with Result-TLV=Failure. If the EAP server sends a failure, 832 the peer MUST respond with Result-TLV=Failure and the Crypto-Binding 833 TLV, without any other mandatory TLVs. The Crypto-Binding TLV is 834 calculated using the key derivation formula in Section 2.5; if for 835 some reason one or more inner EAP method MSKs were not derived, then 836 these MSKs are assumed to be null. 838 If the EAP server has sent the success indication (Result- 839 TLV=Success), the peer is allowed to refuse to accept a Success 840 message from the EAP server since the client's policy may require 841 completion of certain EAP methods or the client may require 842 credentials. 844 If the EAP server has sent a success indication (Result TLV=success), 845 and the peer wants authentication to fail, it sends the TLV response 846 with Result-TLV=Failure and Crypto-Binding-TLV. 848 After the EAP-server returns success, if the peer wants to request 849 the EAP server to continue conversation, it sends a Result 850 TLV=Success along with a Request-Action TLV with the appropriate 851 action (e.g. Negotiate-EAP, or Process-TLV). If the Request-Action 852 TLV is set to mandatory, then the EAP server MUST process the action, 853 or return status=failure, closing the conversation inside the tunnel. 854 If the Request-Action TLV is set to optional, then the EAP server can 855 ignore the TLV and return Result-TLV=Success again, closing the 856 conversation inside the tunnel. 858 2.2.3. Server Unauthenticated Tunnel Provisioning Mode 860 Server unauthenticated tunnel provisioning mode provides ease of 861 deployment at the cost of introducing man-in-the-middle 862 vulnerabilities. As a result, implementation of the server 863 unauthenticated tunnel provisioning mode is OPTIONAL. 865 In server unauthenticated tunnel provisioning mode, as part of PEAPv2 866 part 1, the peer verifies that the EAP server possesses the private 867 key corresponding to the public key contained in the certificate 868 presented by the EAP server. However, the peer does not verify 869 whether the certificate presented by the server chains to a 870 provisioned trust anchor. Assuming that the server demonstrates 871 possession of the private key, the peer continues with establishment 872 of the tunnel (PEAPv2 part 2). As a result, it is possible that the 873 TLS channel (PEAPv2 part 2) may be terminated by an attacker. 875 The PEAPv2 Part 2 conversation is unchanged in server unauthenticated 876 tunnel provisioning mode, except that the peer will only accept an 877 EAP method supporting mutual authentication and key derivation that 878 is compatible with its initial credentials (such as a password-based 879 EAP method). The peer then uses the Crypto-Binding TLV to validate 880 that the same server terminates both the TLS channel and the 881 successfully completed EAP method, thereby verifying that the 882 exchange was not subject to a man-in-the-middle attack. Assuming 883 that the Crypto-Binding TLV exchange is successful, the peer will 884 request and the server will subsequently provide a trusted root, 885 using the Server-Trusted-Root TLV. 887 Once the server unauthenticated tunnel provisioning exchange 888 completes, the peer is expected to use the provisioned credentials in 889 subsequent PEAPv2 authentications, and SHOULD NOT use server 890 unauthenticated tunnel provisioning mode. 892 PEAPv2 servers implementing server unauthenticated tunnel 893 provisioning mode MAY support the following additional ciphersuites, 894 beyond those specified in Section 2.1.2: 896 TLS_DH_anon_WITH_AES_128_CBC_SHA 898 PEAPv2 peers implementing server unauthenticated tunnel provisioning 899 mode MAY support the following additional ciphersuites, beyond those 900 specified in Section 2.1.2: 902 TLS_DH_anon_WITH_AES_128_CBC_SHA 904 Where TLS certificate ciphersuites are negotiated in PEAPv2 Part 1, 905 if the peer can verify that the EAP server possesses the private key 906 corresponding to the public key in the certificate presented by the 907 PEAPv2 server, but the peer is not configured with a certificate 908 trust anchor required to validate the server certificate, the peer 909 MAY choose to go into server unauthenticated tunnel provisioning 910 mode. 912 If the peer cannot verify that the server possesses the corresponding 913 private key, or if the certificate presented by the server is 914 unacceptable for any reason other than the lack of an appropriate 915 trust anchor, the peer MUST NOT use server unauthenticated tunnel 916 provisioning mode. If the peer decides to proceed with server 917 unauthenticated tunnel provisioning mode, it MUST NOT send a TLS 918 fatal alert, but instead continues with establishment of the TLS 919 channel as in PEAPv2 Part 1. 921 [Issue] Can the peer use some other TLS alert to indicate the failure 922 to EAP server? In Anon-DH, the server explicitly knows that the 923 client will use provisioning mode. Will this in anyway make this 924 provisioning mode less secure? 926 [Issue] Since the server does not know upfront that the peer has 927 decided to go into provisioning mode, does this result in any attacks 928 like privacy et al? 930 2.3. Error Handling 932 PEAPv2 does not have its own error message capabilities since: 934 [1] Errors in TLS and errors related to crypto-binding (tunnel 935 compromise errors) are communicated via TLS alert messages. 937 [2] Errors within the EAP conversation in PEAPv2 Part 2 are expected to 938 be handled by individual EAP methods. 940 [3] Violation of the TLV rules for inner-TLVs are handled using Result- 941 TLVs. 943 If an error occurs at any point in the TLS layer, the EAP server 944 SHOULD send a TLS alert message instead of the next EAP-request 945 packet to the peer. The EAP server SHOULD send an EAP-Request packet 946 with EAP-Type=PEAP, encapsulating a TLS record containing the 947 appropriate TLS alert message. The EAP server SHOULD send a TLS 948 alert message rather than immediately terminating the conversation so 949 as to allow the peer to inform the user of the cause of the failure 950 and possibly allow for a restart of the conversation. To ensure that 951 the peer receives the TLS alert message, the EAP server MUST wait for 952 the peer to reply with an EAP-Response packet. 954 The EAP-Response packet sent by the peer MAY encapsulate a TLS 955 client_hello handshake message, in which case the EAP server MAY 956 allow the PEAPv2 conversation to be restarted, or it MAY contain an 957 EAP-Response packet with EAP-Type=PEAP and no data, in which case the 958 PEAPv2 server MUST send an EAP-Failure packet, and terminate the 959 conversation. 961 It is up to the EAP server whether to allow restarts, and if so, how 962 many times the conversation can be restarted. An EAP server 963 implementing restart capability SHOULD impose a limit on the number 964 of restarts, so as to protect against denial of service attacks. 966 If an error occurs at any point in the TLS layer, the peer SHOULD 967 send a TLS alert message instead of the next EAP-response packet to 968 the EAP server. The peer SHOULD send an EAP-Response packet with 969 EAP-Type=PEAP, encapsulating a TLS record containing the appropriate 970 TLS alert message. The EAP server may restart the conversation by 971 sending a EAP-Request packet encapsulating the TLS 972 hello_request_handshake message, in which case the peer MAY allow the 973 PEAPv2 conversation to be restarted; or the EAP server can response 974 with EAP Failure. 976 Any time the peer or the EAP server finds an error when processing 977 the sequence of exchanges, such a violation of TLV rules, it should 978 send a Result TLV of failure and terminate the tunnel. This is 979 usually due to an implementation problem and is considered an fatal 980 error. 982 If a tunnel compromise error (see Section 2.2) is detected by the 983 peer, the peer SHOULD send a TLS Internal Error alert (a Fatal error) 984 message instead of the next EAP-response packet to the EAP server. 985 Similarly, if a tunnel compromise error is detected by the EAP 986 server, the EAP server SHOULD send a TLS Internal error alert (a 987 Fatal error) message instead of the next EAP-response packet to the 988 peer. 990 2.4. Fragmentation 992 A single TLS record may be up to 16384 octets in length, but a TLS 993 message may span multiple TLS records, and a TLS certificate message 994 may in principle be as long as 16MB. 996 The group of PEAPv2 messages sent in a single round may thus be 997 larger than the PPP MTU size, the maximum RADIUS packet size of 4096 998 octets, or even the Multilink Maximum Received Reconstructed Unit 999 (MRRU). 1001 As described in [RFC1990], the multilink MRRU is negotiated via the 1002 Multilink MRRU LCP option, which includes an MRRU length field of two 1003 octets, and thus can support MRRUs as large as 64 KB. 1005 However, note that in order to protect against reassembly lockup and 1006 denial of service attacks, it may be desirable for an implementation 1007 to set a maximum size for one such group of TLS messages. Since a 1008 typical certificate chain is rarely longer than a few thousand 1009 octets, and no other field is likely to be anywhere near as long, a 1010 reasonable choice of maximum acceptable message length might be 64 1011 KB. 1013 If this value is chosen, then fragmentation can be handled via the 1014 multilink PPP fragmentation mechanisms described in [RFC1990]. While 1015 this is desirable, EAP methods are used in other applications such as 1016 [IEEE80211] and there may be cases in which multilink or the MRRU LCP 1017 option cannot be negotiated. As a result, a PEAPv2 implementation 1018 MUST provide its own support for fragmentation and reassembly. 1020 Since EAP is an ACK-NAK protocol, fragmentation support can be added 1021 in a simple manner. In EAP, fragments that are lost or damaged in 1022 transit will be retransmitted, and since sequencing information is 1023 provided by the Identifier field in EAP, there is no need for a 1024 fragment offset field as is provided in IPv4. 1026 PEAPv2 fragmentation support is provided through addition of flag 1027 bits within the EAP-Response and EAP-Request packets, as well as a 1028 TLV Message Length field of four octets. Flags include the Length 1029 included (L), More fragments (M), and PEAP Start (S) bits. The L 1030 flag is set to indicate the presence of the four octet TLV Message 1031 Length field, and MUST be set only for the first fragment of a 1032 fragmented TLV message or set of messages. 1034 The TLV Message Length field in the PEAPv2 header is not protected, 1035 and hence can be modified by a attacker. The TLS record length in 1036 the TLS data is protected. Hence, if the TLV Message length received 1037 in the first packet (with L bit set) is greater or less than the 1038 total size of TLS messages received including multiple fragments, 1039 then the TLV message length should be ignored. 1041 In order to protect against reassembly lockup and denial of service 1042 attacks, it may be desirable for an implementation to set a maximum 1043 size for one group of Outer-TLV messages. Since a typical 1044 certificate chain is rarely longer than a few thousand octets, and no 1045 other field is likely to be anywhere near as long, a reasonable 1046 choice of maximum acceptable message length for all the Outer-TLVs in 1047 a group of messages might be 64 KB. 1049 The M flag is set on all but the last fragment. The S flag is set 1050 only within the PEAP start message sent from the EAP server to the 1051 peer. The TLV Message Length field is four octets, and provides the 1052 total length of the TLV message or set of messages that is being 1053 fragmented; this simplifies buffer allocation. 1055 When a peer receives an EAP-Request packet with the M bit set, it 1056 MUST respond with an EAP-Response with EAP-Type=PEAP and no data. 1057 This serves as a fragment ACK. The EAP server MUST wait until it 1058 receives the EAP-Response before sending another fragment. In order 1059 to prevent errors in processing of fragments, the EAP server MUST 1060 increment the Identifier field for each fragment contained within an 1061 EAP-Request, and the peer MUST include this Identifier value in the 1062 fragment ACK contained within the EAP-Response. Retransmitted 1063 fragments will contain the same Identifier value. 1065 Similarly, when the EAP server receives an EAP-Response with the M 1066 bit set, it MUST respond with an EAP-Request with EAP-Type=PEAP and 1067 no TLS data. This serves as a fragment ACK. The EAP peer MUST wait 1068 until it receives the EAP-Request before sending another fragment. 1069 In order to prevent errors in the processing of fragments, the EAP 1070 server MUST increment the Identifier value for each fragment ACK 1071 contained within an EAP-Request, and the peer MUST include this 1072 Identifier value in the subsequent fragment contained within an EAP- 1073 Response. 1075 2.5. Key Derivation 1077 Since the normal TLS keys are used in the handshake, and therefore 1078 should not be used in a different context, new keys must be derived 1079 from the TLS master secret for use with the selected link layer 1080 ciphersuites. 1082 Instead of deriving keys specific to link layer ciphersuites EAP 1083 methods provide a Master Session Key (MSK) used to derive keys in a 1084 link layer specific manner. The method used to extract ciphering 1085 keys from the MSK is beyond the scope of this document. 1087 PEAPv2 also derives an Extended Master Session Key (EMSK) which is 1088 reserved for use in deriving keys in other ciphering applications. 1089 This draft also does not discuss the format of the attributes used to 1090 communicate the master session keys from the backend authentication 1091 server to the NAS. Examples of such attributes are provided in 1092 [RFC2548]. 1094 PEAPv2 combines key material from the TLS exchange with key material 1095 from inner key generating EAP methods to provide stronger keys and to 1096 bind inner authentication mechanisms to the TLS tunnel. Both the 1097 peer and EAP server MUST derive compound MAC and compound session 1098 keys using the procedure described below. 1100 The input for the cryptographic binding includes the following: 1102 [a] The PEAPv2 tunnel key (TK) is calculated using the first 64 octets 1103 of the (secret) key material generated as described in the EAP-TLS 1104 algorithm ([RFC2716] section 3.5) 1106 [b] The MSK provided by each successful inner EAP method (should not 1107 include the 64 octets of EMSK); for each successful EAP method 1108 completed within the tunnel. 1110 ISK1..ISKn are the MSK portion of the EAP keying material obtained 1111 from methods 1 to n. In some cases where the inner EAP method does 1112 not provide keys: ISKi, for some i, may be the null string (""). 1114 The PRF algorithm is based on PRF+ from IKEv2 shown below ("|" 1115 denotes concatenation) 1116 K = Key, S = Seed, LEN = output length, represented as binary 1117 in a single octet. 1119 PRF (K,S,LEN) = T1 | T2 | T3 | T4 | ... where: 1121 T1 = HMAC-SHA1(K, S | LEN | 0x01) 1122 T2 = HMAC-SHA1 (K, T1 | S | LEN | 0x02) 1123 T3 = HMAC-SHA1 (K, T2 | S | LEN | 0x03) 1124 T4 = HMAC-SHA1 (K, T3 | S | LEN | 0x04) 1125 ... 1126 The intermediate combined key is generated after each 1127 successful EAP method inside the tunnel. 1129 Generating the intermediate combined key: 1131 Take the second 32 octets of TK 1133 IPMK0 = TK 1134 for j = 1 to k do 1135 IPMKj = PRF(IPMK(j-1),"Intermediate PEAP MAC key" | ISKj, 32); 1137 k = the last successful EAP method inside the tunnel at the point 1138 where the combined MAC key is derived. 1140 Each IPMKj output is 32 octets. IPMKn is the intermediate combined 1141 key used to derive combined session and combined MAC keys. 1143 Compound MAC Key derivation: 1145 The Compound MAC Key for the server (the B1_MAC) is derived CMK_B1 1147 CMK_B1 = PRF(IPMKn,"PEAP Server B1 MAC key" | S_NONCE, 20) 1149 The Compound MAC Key for the client (the B2_MAC) is derived from 1150 MAC key called CMK B2. 1152 CMK_B2 = PRF(IPMKn,"PEAP Client B2 MAC key" | C_NONCE | S_NONCE, 1153 20) 1155 The compound MAC keys (CMK_B1 and CMK_B2) are each 20 octets long. 1157 Compound Session Key derivation: 1159 The compound session key (CSK) is derived on both the peer and EAP 1160 server. 1162 CSK = PRF(IPMKn, "PEAP compound session key" | C_NONCE | S_NONCE, 1163 OutputLength) 1164 The output length of the CSK must be at least 128 bytes. The first 1165 64 octets are taken and the MSK and the second 64 octets are taken 1166 as the EMSK. The MSK and EMSK are described in [RFC3748]. 1168 2.6. Ciphersuite Negotiation 1170 Since TLS supports TLS ciphersuite negotiation, peers completing the 1171 TLS negotiation will also have selected a TLS ciphersuite, which 1172 includes key strength, encryption and hashing methods. However, 1173 unlike in [RFC2716], within PEAPv2, the negotiated TLS ciphersuite 1174 relates only to the mechanism by which the PEAPv2 Part 2 conversation 1175 will be protected, and has no relationship to link layer security 1176 mechanisms negotiated within the PPP Encryption Control Protocol 1177 (ECP) [RFC1968] or within IEEE 802.11 [IEEE80211]. 1179 As a result, this specification currently does not support secure 1180 negotiation of link layer ciphersuites. 1182 3. PEAPv2 Protocol Description 1184 3.1. PEAP Protocol Layers 1186 PEAP packets may encapsulate TLVs both inside and outside the TLS 1187 tunnel. The term "Outer TLVs" is used to refer to TLVs outside the 1188 TLS tunnel; TLS records are themselves enclosed within Outer TLVs. 1189 The term "Inner TLVs" is used to refer to TLVs sent within the TLS 1190 tunnel. 1192 In PEAPv2 Part 1, Outer TLVs are used to encapsulate TLS records 1193 (TLS-Payload TLV) as well as for other purposes, but no Inner TLVs 1194 are used. Therefore the layering of PEAPv2 Part 1 is as follows: 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | TLS | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Outer-TLVs (TLS-Payload TLV) | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | PEAP | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | EAP | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 In PEAPv2 Part 2, Outer TLVs are used to encapsulate TLS records 1207 which in turn may encapsulate zero or more Inner TLVs. EAP packets 1208 (including EAP header fields) used within tunneled EAP authentication 1209 methods are carried within Inner TLVs. Therefore the layering of 1210 PEAPv2 Part 2 is as follows: 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | EAP | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Inner-TLVs (EAP-Payload TLV) | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | TLS | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Outer-TLVs (TLS-Payload TLV) | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | PEAP | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | EAP | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 3.2. PEAPv2 Packet Format 1228 A summary of the PEAPv2 packet format is shown below. The fields are 1229 transmitted from left to right. 1231 0 1 2 3 1232 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 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Code | Identifier | Length | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Type | Flags | Ver | Outer-TLV Message Length 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Outer-TLV Message Length | Outer-TLVs... 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 Code 1243 1 - Request 1244 2 - Response 1246 Identifier 1248 The Identifier field is one octet and aids in matching responses 1249 with requests. The Identifier field MUST be changed on each 1250 Request packet. The Identifier field in a Response packet MUST 1251 match the Identifier field from the corresponding Request. 1253 Length 1255 The Length field is two octets and indicates the length of the EAP 1256 packet including the Code, Identifier, Length, Type, Flags, 1257 Version, Outer-TLV Message Length and Outer-TLV fields. Octets 1258 outside the range of the Length field should be treated as Data 1259 Link Layer padding and should be ignored on reception. 1261 Type 1263 25 - PEAP 1265 Flags 1267 0 1 2 3 4 1268 +-+-+-+-+-+ 1269 |L M S R R| 1270 +-+-+-+-+-+ 1272 L = Length included 1273 M = More fragments 1274 S = PEAP start 1275 R = Reserved (must be zero) 1277 The L bit (length included) is set to indicate the presence of the 1278 four octet Outer-TLV Message Length field, and MUST be set for the 1279 first fragment of a fragmented Outer-TLV message or set of 1280 messages. The M bit(more fragments) is set on all but the last 1281 fragment. The S bit (PEAP start) is set in a PEAP Start message. 1282 This differentiates the PEAP Start message from a fragment 1283 acknowledgment. 1285 Version 1287 0 1 2 1288 +-+-+-+ 1289 |R|1|0| 1290 +-+-+-+ 1292 R = Reserved (must be zero) 1294 Outer-TLV Message Length 1296 The Outer-TLV Message Length field is four octets, and is present 1297 only if the L bit is set. This field provides the total length of 1298 the Outer-TLV message or set of messages that is being fragmented. 1300 Outer-TLV data 1302 The Outer-TLV data consists of the encapsulated packet in TLV 1303 format. 1305 4. TLVs 1307 The TLVs used within PEAPv2 are standard Type-Length-Value (TLV) 1308 objects. The TLV objects could be used to carry arbitrary parameters 1309 between EAP peer and EAP server. Possible uses for TLV objects 1310 include: language and character set for Notification messages and 1311 cryptographic binding. 1313 The EAP peer may not necessarily implement all the TLVs supported by 1314 the EAP server; and hence to allow for interoperability, TLVs allow 1315 an EAP server to discover if a TLV is supported by the EAP peer, 1316 using the NAK TLV. The PEAPv2 packet does not have to contain any 1317 TLVs, nor need it contain any mandatory TLVs. 1319 The mandatory bit in a TLV indicates that if the peer does not 1320 support the TLV, it MUST send a NAK TLV in response; and all the 1321 other TLVs in the message MUST be ignored. If an EAP peer finds an 1322 unsupported TLV which is marked as optional, it MUST NOT send an NAK 1323 TLV. 1325 Note that a peer may support a TLV with the mandatory bit set, but 1326 may not understand the contents. The appropriate response to a 1327 supported TLV with content that is not understood is defined by the 1328 TLV specification. 1330 Outer-TLVs (other than TLS-Payload-TLV) SHOULD NOT be included in 1331 messages after the first two Outer-TLV messages sent by the peer and 1332 EAP server respectively. A single Outer-TLV message may be 1333 fragmented in multiple PEAP packets. 1335 All Outer-TLVs (except TLS-Payload) MUST NOT have the mandatory bit 1336 set. If an Outer-TLV other than TLS-Payload has the mandatory bit 1337 set, then the packet MUST be ignored. 1339 PEAPv2 implementations MUST support TLVs, as well as processing of 1340 mandatory/optional settings on the TLV. 1342 4.1. TLV Format 1344 TLVs are defined as described below. The fields are transmitted from 1345 left to right. 1347 0 1 2 3 1348 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 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 |M|R| TLV Type | Length | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Value... 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 M 1356 0 - Optional TLV 1357 1 - Mandatory TLV 1359 R 1361 Reserved, set to zero (0) 1363 TLV Type 1365 A 14-bit field, denoting the TLV type. Allocated Types include: 1367 0 - Reserved 1368 1 - Reserved 1369 2 - Reserved 1370 3 - Result-TLV - Acknowledged Result 1371 4 - NAK-TLV 1372 5 - Error-Code TLV 1373 6 - Connection-Binding TLV 1374 7 - Vendor-Specific TLV 1375 8 - URI-TLV 1376 9 - EAP-Payload TLV 1377 10 - Intermediate-Result TLV 1378 11 - Reserved 1379 12 - Crypto-Binding TLV 1380 13 - Calling-Station-Id TLV 1381 14 - Called-Station-Id TLV 1382 15 - NAS-Port-Type TLV 1383 16 - Server-Identifier TLV 1384 17 - Identity-Type TLV 1385 18 - Server-Trusted-Root TLV 1386 19 - Request-Action TLV 1387 20 - PKCS#7 TLV 1389 Length 1391 The length of the Value field in octets. 1393 Value 1395 The value of the TLV. 1397 4.2. TLS-Payload TLV 1399 The TLS-Payload TLV encapsulates TLS records. PEAPv2 implementations 1400 MUST support this TLV, which cannot be responded to with a NAK TLV. 1402 The TLS-Payload TLV is defined as follows: 1404 0 1 2 3 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 |M|R| TLV Type | Length | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | TLS... 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 M 1414 1 - Mandatory TLV 1416 R 1418 Reserved, set to zero (0) 1420 TLV Type 1422 2 1424 Length 1426 >=0 1428 TLS 1430 TLS records. If no TLS data, then this TLV has a Length field 1431 set to zero (0). As noted in Section 2.4, a single TLS record may 1432 be up to 16384 octets in length, but a TLS message may span 1433 multiple TLS records, and a TLS certificate message may in 1434 principle be as long as 16MB. However, in order to protect 1435 against reassembly lockup and denial of service attacks, a 1436 maximum TLS payload size of 64 KB is assumed. 1438 4.3. Result TLV 1440 The Result TLV provides support for acknowledged success and failure 1441 messages within PEAPv2. PEAPv2 implementations MUST support this 1442 TLV, which cannot be responded to with a NAK TLV. If the Status 1443 field does not contain one of the known values, then the peer or EAP 1444 server MUST drop the connection. The Result TLV is defined as 1445 follows: 1447 0 1 2 3 1448 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 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 |M|R| TLV Type | Length | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | Status | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 M 1457 1 - Mandatory TLV 1459 R 1461 Reserved, set to zero (0) 1463 TLV Type 1465 3 1467 Length 1469 2 1471 Status 1473 The Status field is two octets. Values include: 1475 1 - Success 1476 2 - Failure 1478 4.4. NAK TLV 1480 The NAK TLV allows a peer to detect TLVs that are not supported by 1481 the other peer. A TLV packet can contain 0 or more NAK TLVs. PEAPv2 1482 implementations MUST support the NAK TLV, which cannot be responded 1483 to with a NAK TLV. The NAK TLV is defined as follows: 1485 0 1 2 3 1486 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 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 |M|R| TLV Type | Length | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Vendor-Id | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | NAK-Type | TLVs.... 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 M 1496 1 - Mandatory TLV 1498 R 1500 Reserved, set to zero (0) 1502 TLV Type 1504 4 1506 Length 1508 >=6 1510 Vendor-Id 1512 The Vendor-Id field is four octets, and contains the Vendor-Id of 1513 the TLV that was not supported. The high-order octet is 0 and the 1514 low-order 3 octets are the SMI Network Management Private 1515 Enterprise Code of the Vendor in network byte order. The Vendor- 1516 Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. 1517 For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI 1518 code. 1520 NAK-Type 1522 The NAK-Type field is two octets. The field contains the Type of 1523 the TLV that was not supported. A TLV of this Type MUST have been 1524 included in the previous packet. 1526 TLVs 1528 This field contains a list of TLVs, each of which MUST NOT have 1529 the mandatory bit set. These optional TLVs can be used in the 1530 future to communicate why the offending TLV was determined to be 1531 unsupported. 1533 4.5. Crypto-Binding TLV 1535 The Crypto-Binding TLV is used prove that both peers participated in 1536 the sequence of authentications (specifically the TLS session and 1537 inner EAP methods that generate keys). 1539 Both the Binding Request (B1) and Binding Response (B2) use the same 1540 packet format. However the Sub-Type indicates whether it is B1 or 1541 B2. 1543 The Crypto-Binding TLV MUST be used to perform Cryptographic Binding 1544 after each successful EAP method in a sequence of EAP methods is 1545 complete in PEAPv2 part 2. The Crypto-Binding TLV can also be used 1546 during Protected Termination. 1548 The Crypto-Binding TLV must have the version number received during 1549 the PEAP version negotiation. The receiver of the crypto binding TLV 1550 must verify that the version in the crypto binding TLV matches the 1551 version it sent during the PEAP version negotiation. If this check 1552 fails then the TLV is invalid. 1554 The receiver of the crypto binding TLV must verify that the subtype 1555 is not set to any value other than the ones allowed. If this check 1556 fails then the TLV is invalid. 1558 This message format is used for the Binding Request (B1) and also the 1559 Binding Response. This uses TLV type CRYPTO_BINDING_TLV. PEAPv2 1560 implementations MUST support this TLV and this TLV cannot be 1561 responded to with a NAK TLV. The Crypto-Binding TLV is defined as 1562 follows: 1564 0 1 2 3 1565 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 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 |M|R| TLV Type | Length | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | Reserved | Version | Received Ver. | Sub-Type | 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | | 1572 ~ Nonce ~ 1573 | | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | | 1576 ~ Compound MAC ~ 1577 | | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 M 1582 1 - Mandatory TLV 1584 R 1586 Reserved, set to zero (0) 1588 TLV Type 1590 12 1592 Length 1594 56 1596 Reserved 1598 Reserved, set to zero (0) 1600 Version 1602 The Version field is a single octet, which is set to the version 1603 of crypto binding TLV. For the Crypto-Binding TLV defined in this 1604 specification, it is set to two (2). 1606 Received Version 1608 The Received Version field is a single octet and MUST be set to 1609 the PEAP version number received during version negotiation. Note 1610 that this field only provides protection against downgrade attacks 1611 where a version of PEAP requiring support for this TLV is required 1612 on both sides (such as PEAPv2 or a more recent version). 1614 Sub-Type 1616 The Sub-Type field is two octets. Possible values include: 1618 0 - Binding Request 1619 1 - Binding Response 1621 Nonce 1623 The Nonce field is 32 octets. It contains a 256 bit nonce that is 1624 temporally unique, used for compound MAC key derivation at each 1625 end. This is the S_NONCE for the B1 message and a C_NONCE for the 1626 B2 message. 1628 Compound MAC 1630 The Compound MAC field is 20 octets. This can be the Server MAC 1631 (B1_MAC) or the Client MAC (B2_MAC). It is computed over the 1632 entire Crypto-Binding TLV attribute using the HMAC-SHA1-128 that 1633 provides 128 bits of output using the CMK_B1 or CMK_B2 with the 1634 MAC field zeroed out. The MAC is computed over the buffer created 1635 after concatenating these fields in the following order: 1637 [a] Entire Crypto-Binding TLV attribute received from the other party 1638 [b] The first two Outer-TLVs packets sent by EAP-server to the peer. 1639 If a single outer-TLV packet is fragmented in multiple PEAP 1640 packets; then all fragments for that message MUST be included. The 1641 TLS-Payload TLV MUST NOT be included in the calculation of the MAC. 1643 [c] The first two Outer-TLV packets sent by peer to the EAP-server. If 1644 a single outer-TLV packet is fragmented in multiple PEAP packets; 1645 then all fragments for that message MUST be included. The TLS- 1646 Payload TLV MUST NOT be included in the calculation of the MAC. 1647 [Issue] The length in the TLS payload TLV will not be included in 1648 calc of the MAC. Is this ok? 1650 [d] The EAP Type sent by the EAP server in the first PEAP packet. 1652 [e] The EAP Type sent by the peer in the first PEAP packet. 1654 If Compound MAC validation fails, then it is considered a tunnel 1655 compromise error. 1657 [Issue] if Outer-TLVs are modified, it compound MAC would fail; but 1658 is this really a tunnel compromise error?. 1660 4.6. Connection-Binding TLV 1662 The Connection-Binding TLV allows for connection specific information 1663 to be sent by the peer to the AAA server. This TLV should be logged 1664 by the EAP or AAA server. The AAA or EAP server should not deny 1665 access if there i s a mismatch between the value sent through the AAA 1666 protocol and this TLV. 1668 The format of this TLV is defined for the layer that defines the 1669 parameters. The format of the value sent by the peer to the EAP 1670 server may be different from the format of the corresponding value 1671 sent through the AAA protocol. For example, the connection binding 1672 TLV may contain the 802.11 MAC Address or SSID. 1674 PEAP implementations MAY support this TLV and this TLV MUST NOT be 1675 responded to with a NAK TLV. The Connection-Binding TLV is defined 1676 as follows: 1678 0 1 2 3 1679 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 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 |M|R| TLV Type | Length | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | TLVs... 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 M 1687 0 - Optional TLV 1689 R 1691 Reserved, set to zero (0) 1693 TLV Type 1695 6 1697 Length 1699 >=0 1701 TLVs... 1703 The field contains a list of TLVs, each in the same format defined 1704 in Section 4.3, with the optional bit set. These TLVs contain 1705 information on the identity of the peer and authenticator (layer 2 1706 or IP addresses); the media used to connect the peer and 1707 authenticator (NAS-Port-Type); and/or the service the client is 1708 trying to access on the gateway (SSID). The format of these TLVs 1709 will be defined in a separate draft. 1711 4.7. Vendor-Specific TLV 1713 The Vendor-Specific TLV is available to allow vendors to support 1714 their own extended attributes not suitable for general usage. 1716 A Vendor-Specific-TLV attribute can contain one or more TLVs, 1717 referred to as Vendor-TLVs. The TLV-type of the Vendor-TLV will be 1718 defined by the vendor. All the Vendor-TLVs inside a single Vendor- 1719 Specific TLV belong to the same vendor. 1721 PEAPv2 implementations MUST support the Vendor-Specific TLV, and this 1722 TLV MUST NOT be responded to with a NAK TLV. PEAPv2 implementations 1723 MAY NOT support the Vendor-TLVs inside in the Vendor-Specific TLV, 1724 and can respond to the Vendor-TLVs with a NAK TLV containing the 1725 appropriate Vendor-ID and Vendor-TLV type. 1727 Vendor-TLVs may be optional or mandatory. Vendor-TLVs sent in the 1728 protected success and failure packets MUST be marked as optional. If 1729 Vendor-TLVs sent in protected success/failure packets are marked as 1730 Mandatory, then the peer or EAP server MUST drop the connection. 1732 The Vendor-Specific TLV is defined as follows: 1734 0 1 2 3 1735 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 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 |M|R| TLV Type | Length | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 | Vendor-Id | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | Vendor-TLVs.... 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 M 1746 1 - Mandatory TLV 1748 R 1750 Reserved, set to zero (0) 1752 TLV Type 1754 7 1756 Length 1758 >=4 1760 Vendor-Id 1762 The Vendor-Id field is four octets. The high-order octet is 0 and 1763 the low-order 3 octets are the SMI Network Management Private 1764 Enterprise Code of the Vendor in network byte order. The Vendor- 1765 Id MUST be zero for TLVs that are not Vendor-Specific TLVs. For 1766 Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code. 1768 Vendor-TLVs 1770 This field is of indefinite length. It contains vendor-specific 1771 TLVs, in a format defined by the vendor. 1773 4.8. URI TLV 1775 The URI TLV allows a server to send a URI to the client to refer it 1776 to a resource. The TLV contains a URI in the format specified in 1777 RFC2396 with UTF-8 encoding. Interpretation of the value of the URI 1778 is outside the scope of this document. 1780 If a packet contains multiple URI TLVs, then the client SHOULD select 1781 the first TLV it can implement, and ignore the others. If the client 1782 is unable to implement any of the URI TLVs, then it MAY ignore the 1783 error. PEAP implementations MAY support this TLV; and this TLV 1784 cannot be responded to with a NAK TLV. The URI TLV is defined as 1785 follows: 1787 0 1 2 3 1788 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 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 |M|R| TLV Type | Length | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | URI... 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 M 1797 0 - Optional TLV 1799 R 1801 Reserved, set to zero (0) 1803 TLV Type 1805 8 1807 Length 1809 >=0 1811 URI 1813 This field is of indefinite length, and conforms to the format 1814 specified in [RFC2396]. 1816 4.9. EAP-Payload TLV 1818 To allow piggybacking EAP request and response with other TLVs, the 1819 EAP Payload TLV is defined, which includes an encapsulated EAP packet 1820 and 0 or more TLVs. PEAPv2 implementations MUST support this TLV, 1821 which cannot be responded to with a NAK TLV. The EAP-Payload TLV is 1822 defined as follows: 1824 0 1 2 3 1825 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 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 |M|R| TLV Type | Length | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | EAP packet... 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | TLVs... 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 M 1836 1 - Mandatory TLV 1838 R 1840 Reserved, set to zero (0) 1842 TLV Type 1844 9 1846 Length 1848 >=0 1850 EAP packet 1852 This field contains a complete EAP packet, including the EAP 1853 header (Code, Identifier, Length, Type) fields. The length of 1854 this field is determined by the Length field of the encapsulated 1855 EAP packet. 1857 TLVs... 1859 This (optional) field contains a list of TLVs associated with the 1860 EAP packet field. The TLVs utilize the same format described 1861 Section 4.3, and MUST NOT have the mandatory bit set. The total 1862 length of this field is equal to the Length field of the EAP- 1863 Payload-TLV, minus the Length field in the EAP header of the EAP 1864 packet field. 1866 4.10. Intermediate Result TLV 1868 The Intermediate Result TLV provides support for acknowledged 1869 intermediate Success and Failure messages within EAP. PEAPv2 1870 implementations MUST support this TLV, which cannot be responded to 1871 with a NAK TLV. The Intermediate Result TLV is defined as follows: 1873 0 1 2 3 1874 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 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 |M|R| TLV Type | Length | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | Status | TLVs... 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 M 1883 1 - Mandatory TLV 1885 R 1887 Reserved, set to zero (0) 1889 TLV Type 1891 10 1893 Length 1895 >=2 1897 Status 1899 The Status field is two octets. Values include: 1901 1 - Success 1902 2 - Failure 1904 TLVs 1906 This (optional) field is of indeterminate length, and contains the 1907 TLVs associated with the Intermediate Result TLV, in the same 1908 format as described in Section 4.3. The TLVs in this field MUST 1909 NOT have the mandatory bit set. 1911 4.11. Reserved TLVs 1913 TLV type 11 is reserved due to use in previous implementations. 1914 PEAPv2 implementations MAY NOT support this TLV, which MUST be marked 1915 as OPTIONAL. This TLV MUST NOT be responded to with a NAK TLV. 1917 4.12. Calling-Station-ID TLV 1919 This TLV allows a peer to send information to EAP server about the 1920 call originator. This TLV MAY be included in the Connection-Binding- 1921 TLV. 1923 For dial-up, the Called-Station-ID TLV contains the phone number of 1924 the peer. For use with IEEE 802.1X, the MAC address of the peer is 1925 included, as specified in [RFC3580]. 1927 For VPN, this attribute is used to send the IPv4 or IPV6 address of 1928 the interface of the peer used to initiate the VPN in ASCII format. 1929 Where the Fully Qualified Domain Name (FQDN) of the VPN client is 1930 known, it SHOULD be appended, separated from the address with a space 1931 (" "). Example: "12.20.2.3 vpnserver.company.com". 1933 As described in [RFC3748] Section 7.15, this TLV SHOULD be logged by 1934 the EAP or AAA server, and MAY be used for comparison with 1935 information gathered by other means. 1937 However, since the format of this TLV may not match the format of the 1938 information gathered by other means, if an EAP server or AAA server 1939 supports the capability to deny access based on a mismatch, spurious 1940 authentication failures may occur. As a result, implementations 1941 SHOULD allow the administrator to disable this check. 1943 PEAP implementations MAY support this TLV and this TLV MUST NOT be 1944 responded to with a NAK TLV. The Calling-Station-ID TLV is defined 1945 as follows: 1947 0 1 2 3 1948 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 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 |M|R| TLV Type | Length | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 | String... 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 M 1957 0 - Optional TLV 1959 R 1961 Reserved, set to zero (0) 1963 TLV Type 1965 13 1967 Length 1968 >=0 1970 String 1972 The field should be the same as the value of the Calling-Station- 1973 ID attribute in [RFC2865]. 1975 4.13. Called-Station-ID TLV 1977 This TLV allows a peer to send information to EAP server about the 1978 NAS it called. This TLV MAY be included in the Connection-Binding- 1979 TLV. 1981 For dial-up, the Calling-Station-ID TLV contains the phone number 1982 called by the peer. For use with IEEE 802.1X, the MAC address of the 1983 NAS is included, as specified in [RFC3580]. 1985 For VPN, this attribute is used to send the IPv4 or IPv6 address of 1986 VPN server in ASCII format. Where the Fully Qualified Domain Name 1987 (FQDN) of the VPN server is known, it SHOULD be appended, separated 1988 from the address with a space (" "). Example: "12.20.2.3 1989 vpnserver.company.com". 1991 This TLV SHOULD be logged by the EAP or AAA server, and MAY be used 1992 for comparison with information gathered by other means. However, 1993 since the format of this TLV may not match the format of the 1994 information gathered by other means, if an EAP server or AAA server 1995 supports the capability to deny access based on a mismatch, spurious 1996 authentication failures may occur. As a result, implementations 1997 SHOULD allow the administrator to disable this check. 1999 PEAP implementations MAY support this TLV, and this TLV MUST NOT be 2000 responded to with a NAK TLV. The Called-Station-ID TLV is defined as 2001 follows: 2003 0 1 2 3 2004 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 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 |M|R| TLV Type | Length | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | String... 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 M 2013 0 - Optional TLV 2015 R 2016 Reserved, set to zero (0) 2018 TLV Type 2020 14 2022 Length 2024 >=0 2026 String 2028 The field should be the same as the value of the Called-Station-ID 2029 attribute in [RFC2865]. 2031 4.14. NAS-Port-Type TLV 2033 This TLV allows a peer to send information to EAP server about the 2034 type of physical connection used by the peer to connect to NAS. This 2035 TLV MAY be included in the Connection-Binding-TLV. 2037 The value of this field is the same as the value of NAS-Port-Type 2038 attribute in [RFC2865]. 2040 This TLV SHOULD be logged by the EAP or AAA server and MAY be used 2041 for comparison with information gathered by other means. However, 2042 since the format of this TLV may not match the format of the 2043 information gathered by other means, if an EAP server or AAA server 2044 supports the capability to deny access based on a mismatch, spurious 2045 authentication failures may occur. As a result, implementations 2046 SHOULD allow the administrator to disable this check. 2048 PEAP implementations MAY support this TLV; and this TLV MUST NOT be 2049 responded to with a NAK TLV. The NAS-Port-Type TLV is defined as 2050 follows: 2052 0 1 2 3 2053 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 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 |M|R| TLV Type | Length | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | Value | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 M 2062 0 - Optional TLV 2064 R 2066 Reserved, set to zero (0) 2068 TLV Type 2070 15 2072 Length 2074 4 2076 Value 2078 The Value field is four octets. Values are the same as for the 2079 NAS-Port-Type attribute defined in [RFC2865]. 2081 4.15. Server-Identifier TLV 2083 This TLV allows a EAP-Server to send a hint to the EAP peer to help 2084 the EAP peer select the appropriate sessionID for session resumption. 2085 The field is a string sent by the EAP server, and the field should be 2086 treated as a opaque string by the peer. During a full-tls-handshake, 2087 the EAP-peer MAY keep track of this field and the corresponding 2088 sessionID, and use it as a hint to select the appropriate sessionID 2089 during session resumption. 2091 PEAP implementations MAY support this TLV and this TLV MUST NOT be 2092 responded to with a NAK TLV. The Server-Identifier TLV is defined as 2093 follows: 2095 0 1 2 3 2096 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 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 |M|R| TLV Type | Length | 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 | String... 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 M 2105 0 - Optional TLV 2107 R 2109 Reserved, set to zero (0) 2111 TLV Type 2112 16 2114 Length 2116 >=0 2118 String 2120 Contains an identifier sent by the EAP server. 2122 4.16. Identity-Type TLV 2124 The Identity-Type TLV allows an EAP-server to send a hint to help the 2125 EAP-peer select the right type of identity; for example; user or 2126 machine. 2128 PEAPv2 implementations MAY support this TLV, which cannot be 2129 responded to with a NAK TLV. 2131 If the Identity-type field does not contain one of the known values 2132 or if the EAP peer does not have an identity corresponding to the 2133 identity-type, then the peer MUST ignore the value. The Identity- 2134 Type TLV is defined as follows: 2136 0 1 2 3 2137 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 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 |M|R| TLV Type | Length | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | Identity-Type | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 M 2146 0 - Optional TLV 2148 R 2150 Reserved, set to zero (0) 2152 TLV Type 2154 17 2156 Length 2158 2 2160 Identity-Type 2162 The Identity-Type field is two octets. Values include: 2164 1 - User 2165 2 - Machine 2167 4.17. Server-Trusted-Root TLV 2169 The Server-Trusted-Root TLV allows the peer to send a request to the 2170 EAP server for a trusted root in PKCS#7 format. 2172 The Server-Trusted-Root TLV is always marked as optional, and cannot 2173 be responded to with a NAK TLV. PEAPv2 server implementations that 2174 claim to support provisioning MUST support Server-Trusted-Root TLV, 2175 PKCS#7 TLV, and the the PKCS#7-Server-Certificate-Root credential 2176 format defined in this TLV. 2178 PEAPv2 peer implementations MAY NOT support this TLV. 2180 The Server-Trusted-Root TLV can only be sent as an inner TLV (inside 2181 PEAP part 2 conversation), in both server unauthenticated tunnel 2182 provisioning mode, and the regular authentication process. 2184 The peer MUST NOT request, or accept the trusted root sent inside the 2185 Server-Root credential TLV by EAP server until it has completed 2186 authentication of EAP server, and validated the Crypto-Binding TLV. 2187 The peer may receive a trusted root, but is not required to use the 2188 trusted root received from the EAP server. 2190 If the EAP server sets credential-format to PKCS#7-Server- 2191 Certificate-Root, then the Server-Trusted-Root^A TLV MUST contain the 2192 root of the certificate chain of the certificate issued to the EAP 2193 server packages in a PKCS#7 TLV. If the Server certificate is a 2194 self-signed certificate, then the root is the self-signed 2195 certificate. In this case, the EAP server does not have to sign the 2196 certificate inside the PCKS#7 TLV since it does not necessarily have 2197 to private key for it. 2199 If the Server-Trusted-Root TLV credential format does not contain one 2200 of the known values, then the EAP-server MUST ignore the value. 2202 The Server-Trusted-Root TLV is defined as follows: 2204 0 1 2 3 2205 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 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 |M|R| TLV Type | Length | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | Credential-Type | TLVs... 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2212 M 2214 0 - Optional TLV 2216 R 2218 Reserved, set to zero (0) 2220 TLV Type 2222 18 2224 Length 2226 >=2 2228 Credential-Type 2230 The Credential-Type field is two octets. Values include: 2232 1 - PKCS#7-Server-Certificate-Root. 2234 TLVs 2236 This field is of indefinite length. It contains TLVs associated 2237 with the certificate-request. 2239 4.18. PKCS#7 TLV 2241 The PKCS#7 TLV contains the PKCS #7 wrapped X.509 certificate. This 2242 field contains a certificate or certificate chain in PKCS#7 [RFC2315] 2243 format requested by the peer. 2245 The PKCS#7 TLV is always marked as optional, which cannot be 2246 responded to with a NAK TLV. PEAPv2 server implementations that 2247 claim to support provisioning MUST support this TLV. PEAPv2 peer 2248 implementations MAY NOT support this TLV. 2250 If the PKCS#7 TLV contains a certificate or certificate chain that is 2251 not acceptable to the peer, then peer MUST ignore the value. 2253 The PKCS#7 TLV is defined as follows: 2255 0 1 2 3 2256 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 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 |M|R| TLV Type | Length | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | PKCS#7 data... 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 2263 M 2265 0 - Optional TLV 2267 R 2269 Reserved, set to zero (0) 2271 TLV Type 2273 20 2275 Length 2277 >=0 2279 PKCS#7 Data 2281 PKCS #7 wrapped X.509 certificate. This field contains a 2282 certificate or certificate chain in PKCS#7 [RFC2315] format. 2284 4.19. Request-Action TLV 2286 The Request-Action TLV MAY be sent by the peer along with 2287 acknowledged failure. It allows the peer to request the EAP server 2288 to negotiate EAP methods or process TLVs specified in the failure 2289 packet. The server MAY ignore this TLV. 2291 PEAPv2 implementations MUST support this TLV, which cannot be 2292 responded to with a NAK TLV. 2294 The Request-Action TLV is defined as follows: 2296 0 1 2 3 2297 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 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 |M|R| TLV Type | Length | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | Action | 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 M 2306 0 - Optional TLV 1 - Mandatory TLV 2308 R 2310 Reserved, set to zero (0) 2312 TLV Type 2314 19 2316 Length 2318 2 2320 Action 2322 The Action field is two octets. Values include: 2324 1 - Process-TLV 2325 2 - Negotiate-EAP 2327 4.20. TLV Rules 2329 To save round trips, multiple TLVs can be sent in the single PEAPv2 2330 packet. However, multiple EAP Payload TLVs within one single PEAPv2 2331 packet is not supported in this version and MUST NOT be sent. If the 2332 peer or EAP server receives multiple EAP Payload TLVs, then it MUST 2333 drop the connection. 2335 The following table defines the meaning of the table entries in the 2336 sections below: 2338 0 This TLV MUST NOT be present in the packet. 2339 0+ Zero or more instances of this TLV MAY be present in packet. 2340 0-1 Zero or one instance of this TLV MAY be present in packet. 2341 1 Exactly one instance of this TLV MUST be present in packet. 2343 4.20.1. Outer TLVs 2345 The following table provides a guide to which TLVs may be included in 2346 the PEAPv2 packet outside the TLS channel, which kind of packets, and 2347 in what quantity: 2349 Request Response Success Failure TLV in unencrypted-TLVs field 2350 0-1 0-1 0-1 0-1 Server-Identifier TLV 2351 0+ 0+ 0+ 0+ Vendor-Specific TLV 2352 1 1 1 1 TLS-Payload TLV 2354 Outer-TLVs (other than TLS-Payload TLV) MUST be marked as optional. 2355 Vendor-TLVs inside Vendor-Specific TLV MUST be marked as optional 2356 when included in Outer TLVs. Outer-TLVs (other than TLS-Payload-TLV) 2357 SHOULD NOT be included in messages after the first two Outer-TLV 2358 messages sent by peer and EAP-server respectively. A single Outer- 2359 TLV message may be fragmented in multiple PEAP packets. 2361 4.20.2. Inner TLVs 2363 The following table provides a guide to which Inner TLVs may be 2364 encapsulated in TLS in PEAPv2 Part 2, in which kind of packets, and 2365 in what quantity: 2367 Request Response Success Failure Inner-TLVs 2368 0-1 0-1 0-1 0-1 Intermediate Result TLV 2369 0-1 0-1 0 0 EAP Payload TLV 2370 0-1 0-1 1 1 Result TLV 2371 0-1 0-1 1 1 Crypto-Binding TLV 2372 0+ 0+ 0 0 NAK TLV 2373 0-1 0-1 0-1 0-1 Connection-Binding TLV 2374 0+ 0+ 0+ 0+ Vendor-Specific TLV 2375 0+ 0 0+ 0-1 URI TLV 2376 0+ 0 0 0 Identity-Type TLV 2377 0+ 0+ 0+ 0+ Server-Trusted-Root TLV 2378 0 0-1 0 0-1 Request-Action TLV 2380 Vendor-TLVs (included in Vendor-Specific TLVs) sent in the protected 2381 success and failure packets MUST be marked as optional. If Vendor- 2382 TLVs sent in protected success/failure packets are marked as 2383 Mandatory, then the peer or EAP server MUST drop the connection. 2385 The following defines the meaning of packet type in the table above: 2387 Packet type Description 2388 ---------------------------- 2389 Request - TLV request packet sent by the EAP server to the peer. 2390 Response - TLV packet sent by the peer to the EAP server. 2392 Success - TLV packet sent by the peer or EAP server as 2393 a protected success 2394 Failure - TLV packet sent by the peer or EAP server as 2395 a protected failure. 2397 4.20.3. EAP-Payload TLV 2399 The EAP-Payload TLV can contain other TLVs. The table below defines 2400 which TLVs can be contained inside the EAP-Payload TLV and how many 2401 such TLVs can be included. 2403 Request Response TLV 2404 0+ 0+ Vendor-Specific TLV 2405 0+ 0+ Identity-Type TLV 2407 Vendor-TLVs inside Vendor-Specific TLV MUST be marked as optional 2408 when included in EAP-Payload TLV. 2410 4.20.4. Connection-Binding TLV 2412 The Connection-Binding TLV can contain other TLVs. The table below 2413 defines which TLVs can be contained inside the Connecting-Binding TLV 2414 and how many such TLVs can be included. 2416 Request Response TLV 2417 0-1 0 Calling-Station-ID TLV 2418 0-1 0 Called-Station-ID TLV 2419 0-1 0 NAS-port-type TLV 2420 0+ 0+ Vendor-Specific TLV 2422 Vendor-TLVs inside Vendor-Specific TLV MUST be marked as optional 2423 when included in Connection-Binding TLV. 2425 4.20.5. Server-Trusted-Root TLV 2427 The Server-Trusted-Root TLV can contain other TLVs. The table below 2428 defines which TLVs can be contained inside the Server-Trusted-Root 2429 TLV and how many such TLVs can be included. 2431 Request Response TLV 2432 0-1 0 PKCS#7 TLV 2434 5. Security Considerations 2436 5.1. Authentication and integrity protection 2438 PEAPv2 provides a server authenticated, encrypted and integrity 2439 protected tunnel. All data within the tunnel has these properties. 2441 Data outside the tunnel such as EAP Success and Failure, Outer-TLVs, 2442 authentication methods negotiated outside of PEAPv2 and the PEAPv2 2443 headers themselves (including the EAP-Type in the header) are not 2444 protected by this tunnel. 2446 In addition, the Crypto-Binding TLV can reveal man-in-the-middle 2447 attack described in section 6.8. Hence, the server should not reveal 2448 any sensitive data to the client until after the Crypto-Binding TLV 2449 has been properly verified. 2451 In order to detect modification of Outer-TLVs, the first two Outer- 2452 TLVs messages sent by both peer and EAP-server are included in the 2453 calculation of the Crypto-Binding TLV. Outer-TLVs (other than TLS- 2454 Payload TLV) SHOULD NOT be included in other PEAP packets since there 2455 is no mechanism to detect modification. 2457 In order to detect modification of EAP-Type sent in the clear (EAP- 2458 Type should be set to PEAP), the EAP-Type sent in the first two 2459 messages by both peer and EAP-server is included in the calculation 2460 of Crypto-Binding TLV. The EAP-type in the clear could modified in 2461 other PEAP packets. 2463 5.2. Method negotiation 2465 If the peer does not support PEAPv2, or does not wish to utilize 2466 PEAPv2 authentication, it MUST respond to the initial EAP- 2467 Request/PEAP-Start with a NAK, suggesting an alternate authentication 2468 method. Since the NAK is sent in cleartext with no integrity 2469 protection or authentication, it is subject to spoofing. Inauthentic 2470 NAK packets can be used to trick the peer and authenticator into 2471 "negotiating down" to a weaker form of authentication, such as EAP- 2472 MD5 (which only provides one way authentication and does not derive a 2473 key). 2475 Since a subsequent protected EAP conversation can take place within 2476 the TLS session, selection of PEAPv2 as an authentication method does 2477 not limit the potential secondary authentication methods. As a 2478 result, the only legitimate reason for a peer to NAK PEAPv2 as an 2479 authentication method is that it does not support it. Where the 2480 additional security of PEAPv2 is required, server implementations 2481 SHOULD respond to a NAK with an EAP-Failure, terminating the 2482 authentication conversation. 2484 Since method negotiation outside of PEAP is not protected, if the 2485 peer is configured to allow PEAP and other EAP methods at the same 2486 time, the negotiation is subject to downgrade attacks. Since method 2487 negotiation outside of PEAP is not protected, if the peer is 2488 configured to allow PEAP version 2; and previous PEAP versions at the 2489 same time, the negotiation is subject to negotiation downgrade 2490 attacks. However, peers configured to allow PEAPv2 and later PEAP 2491 versions may not be subject to downgrade negotiation attack since the 2492 highest version supported by both peers is checked within the 2493 protected tunnel. 2495 If peer implementations select incorrect methods or credentials with 2496 EAP servers, then attacks are possible on the credentials. Hence, a 2497 PEAPv2 peer implementation should preferably be configured with a set 2498 of credentials and methods that may be used with a specific PEAPv2 2499 server. The peer implementation may be configured to use different 2500 methods and/or credentials based on the PEAPv2 server. 2502 5.3. TLS session cache handling 2504 In cases where a TLS session has been successfully resumed, in some 2505 circumstances, it is possible for the EAP server to skip the PEAPv2 2506 Part 2 conversation, and successfully conclude the conversation with 2507 a protected termination. 2509 PEAPv2 "fast reconnect" is desirable in applications such as wireless 2510 roaming, since it minimizes interruptions in connectivity. It is 2511 also desirable when the "inner" EAP mechanism used is such that it 2512 requires user interaction. The user should not be required to re- 2513 authenticate herself, using biometrics, token cards or similar, every 2514 time the radio connectivity is handed over between access points in 2515 wireless environments. 2517 However, there are issues that need to be understood in order to 2518 avoid introducing security vulnerabilities. 2520 Since PEAPv2 Part 1 may not provide client authentication, 2521 establishment of a TLS session (and an entry in the TLS session 2522 cache) does not by itself provide an indication of the peer's 2523 authenticity. 2525 Some PEAPv2 implementations may not be capable of removing TLS 2526 session cache entries established in PEAPv2 Part 1 after an 2527 unsuccessful PEAPv2 Part 2 authentication. In such implementations, 2528 the existence of a TLS session cache entry provides no indication 2529 that the peer has previously been authenticated. As a result, 2530 implementations that do not remove TLS session cache entries after a 2531 failed PEAPv2 Part 2 authentication or failed protected termination 2532 MUST use other means than successful TLS resumption as the indicator 2533 of whether the client is authenticated or not. The implementation 2534 MUST determine that the client is authenticated only after the 2535 completion of protected termination. Failing to do this would enable 2536 a peer to gain access by completing PEAPv2 Part 1, tearing down the 2537 connection, re-connecting and resuming PEAPv2 Part 1, thereby proving 2538 herself authenticated. Thus, TLS resumption MUST only be enabled if 2539 the implementation supports TLS session cache removal. If an EAP 2540 server implementing PEAPv2 removes TLS session cache entries of peers 2541 failing PEAPv2 Part 2 authentication, then it MAY skip the PEAPv2 2542 Part 2 conversation entirely after a successful session resumption, 2543 successfully terminating the PEAPv2 conversation as described in 2544 Section 2.4. 2546 5.4. Certificate revocation 2548 Since the EAP server usually has network connectivity during the EAP 2549 conversation, the server is capable of following a certificate chain 2550 or verifying whether the peer's certificate has been revoked. In 2551 contrast, the peer may or may not have network connectivity, and thus 2552 while it can validate the EAP server's certificate based on a pre- 2553 configured set of CAs, it may not be able to follow a certificate 2554 chain or verify whether the EAP server's certificate has been 2555 revoked. 2557 In the case where the peer is initiating a voluntary Layer 2 channel 2558 using PPTP or L2TP, the peer will typically already have network 2559 connectivity established at the time of channel initiation. As a 2560 result, during the EAP conversation it is capable of checking for 2561 certificate revocation. 2563 As part of the TLS negotiation, the server presents a certificate to 2564 the peer. The peer SHOULD verify the validity of the EAP server 2565 certificate, and SHOULD also examine the EAP server name presented in 2566 the certificate, in order to determine whether the EAP server can be 2567 trusted. Please note that in the case where the EAP authentication is 2568 remoted, the EAP server will not reside on the same machine as the 2569 authenticator, and therefore the name in the EAP server's certificate 2570 cannot be expected to match that of the intended destination. In 2571 this case, a more appropriate test might be whether the EAP server's 2572 certificate is signed by a CA controlling the intended destination 2573 and whether the EAP server exists within a target sub-domain. 2575 In the case where the peer is attempting to obtain network access, it 2576 will not have network connectivity. The TLS Extensions [RFC3546] 2577 support piggybacking of an Online Certificate Status Protocol (OCSP) 2578 response within TLS, therefore can be utilized by the peer in order 2579 to verify the validity of server certificate. However, since not all 2580 TLS implementations implement the TLS extensions, it may be necessary 2581 for the peer to wait to check for certificate revocation until after 2582 network access has been obtained. In this case, the peer SHOULD 2583 conduct the certificate status check immediately upon going online 2584 and SHOULD NOT send data until it has received a positive response to 2585 the status request. If the server certificate is found to be invalid 2586 as per client policy, then the peer SHOULD disconnect. 2588 If the client has a policy to require checking certificate revocation 2589 and it cannot obtain revocation information then it may need to 2590 disallow the use of all or some of the inner methods since some 2591 methods may reveal some sensitive information. 2593 5.5. Separation of the EAP server and the authenticator 2595 As a result of a complete PEAPv2 Part 1 and Part 2 conversation, the 2596 EAP endpoints will mutually authenticate, and derive a session key 2597 for subsequent use in link layer security. Since the peer and EAP 2598 client reside on the same machine, it is necessary for the EAP client 2599 module to pass the session key to the link layer encryption module. 2601 The situation may be more complex on the Authenticator, which may or 2602 may not reside on the same machine as the EAP server. In the case 2603 where the EAP server and the Authenticator reside on different 2604 machines, there are several implications for security. Firstly, the 2605 mutual authentication defined in PEAP will occur between the peer and 2606 the EAP server, not between the peer and the authenticator. This 2607 means that as a result of the PEAP conversation, it is not possible 2608 for the peer to validate the identity of the NAS or channel server 2609 that it is speaking to. 2611 The second issue is that the session key negotiated between the peer 2612 and EAP server will need to be transmitted to the authenticator. 2613 Therefore a secure mechanism needs to be provided to transmit the 2614 session key from the EAP server to the authenticator or channel 2615 server that needs to use the key. The specification of this transit 2616 mechanism is outside the scope of this document. 2618 5.6. Separation of PEAPv2 Part 1 and Part 2 Servers 2620 The EAP server involved in PEAPv2 Part 2 need not necessarily be the 2621 same as the EAP server involved in PEAPv2 Part 1. For example, a 2622 local authentication server or proxy might serve as the endpoint for 2623 the Part 1 conversation, establishing the TLS channel. Subsequently, 2624 once the EAP-Response/Identity has been received within the TLS 2625 channel, it can be decrypted and forwarded in cleartext to the 2626 destination realm EAP server. The rest of the conversation will 2627 therefore occur between the destination realm EAP server and the 2628 peer, with the local authentication server or proxy acting as an 2629 encrypting/decrypting gateway. This permits a non-TLS capable EAP 2630 server to participate in the PEAPv2 conversation. 2632 Note however that such an approach introduces security 2633 vulnerabilities. Since the EAP Response/Identity is sent in the 2634 clear between the proxy and the EAP server, this enables an attacker 2635 to snoop the user's identity. It also enables a remote environments, 2636 which may be public hot spots or Internet coffee shops, to gain 2637 knowledge of the identity of their users. Since one of the potential 2638 benefits of PEAP is identity protection, this is undesirable. 2640 If the EAP method negotiated during PEAPv2 Part 2 does not support 2641 mutual authentication, then if the Part 2 conversation is proxied to 2642 another destination, the PEAP peer will not have the opportunity to 2643 verify the secondary EAP server's identity. Only the initial EAP 2644 server's identity will have been verified as part of TLS session 2645 establishment. 2647 Similarly, if the EAP method negotiated during PEAPv2 Part 2 is 2648 vulnerable to dictionary attack, then an attacker capturing the 2649 cleartext exchange will be able to mount an offline dictionary attack 2650 on the password. 2652 Finally, when a Part 2 conversation is terminated at a different 2653 location than the Part 1 conversation, the Part 2 destination is 2654 unaware that the EAP client has negotiated PEAPv2. As a result, it is 2655 unable to enforce policies requiring PEAP. Since some EAP methods 2656 require PEAPv2 in order to generate keys or lessen security 2657 vulnerabilities, where such methods are in use, such a configuration 2658 may be unacceptable. 2660 In summary, PEAPv2 encrypting/decrypting gateway configurations are 2661 vulnerable to attack and SHOULD NOT be used. Instead, the entire 2662 PEAPv2 connection SHOULD be proxied to the final destination, and the 2663 subsequently derived master session keys need to be transmitted back. 2664 T his provides end to end protection of PEAPv2. The specification of 2665 this transit mechanism is outside the scope of this document, but 2666 mechanisms similar to [RFC2548] can be used. These steps protect the 2667 client from revealing her identity to the remote environment. 2669 In order to find the proper PEAP destination, the EAP client SHOULD 2670 place a Network Access Identifier (NAI) conforming to [RFC2486] in 2671 the Identity Response. 2673 There may be cases where a natural trust relationship exists between 2674 the (foreign) authentication server and final EAP server, such as on 2675 a campus or between two offices within the same company, where there 2676 is no danger in revealing the identity of the station to the 2677 authentication server. In these cases, a proxy solution without end 2678 to end protection of PEAPv2 MAY be used. If RADIUS is used to 2679 communicate between gateway and EAP server, then the PEAPv2 2680 encrypting/decrypting gateway SHOULD provide support for IPsec 2681 protection of RADIUS in order to provide confidentiality for the 2682 portion of the conversation between the gateway and the EAP server, 2683 as described in [RFC3579]. 2685 5.7. Identity verification 2687 Since the TLS session has not yet been negotiated, the initial 2688 Identity request/response occurs in the clear without integrity 2689 protection or authentication. It is therefore subject to snooping and 2690 packet modification. 2692 In configurations where all users are required to authenticate with 2693 PEAPv2 and the first portion of the PEAPv2 conversation is terminated 2694 at a local backend authentication server, without routing by proxies, 2695 the initial cleartext Identity Request/Response exchange is not 2696 needed in order to determine the required authentication method(s) or 2697 route the authentication conversation to its destination. As a 2698 result, the initial Identity and Request/Response exchange MAY NOT 2699 be present, and a subsequent Identity Request/Response exchange MAY 2700 occur after the TLS session is established. 2702 If the initial cleartext Identity Request/Response has been tampered 2703 with, after the TLS session is established, it is conceivable that 2704 the EAP Server will discover that it cannot verify the peer's claim 2705 of identity. For example, the peer's userID may not be valid or may 2706 not be within a realm handled by the EAP server. Rather than 2707 attempting to proxy the authentication to the server within the 2708 correct realm, the EAP server SHOULD terminate the conversation. 2710 The PEAPv2 peer can present the server with multiple identities. 2711 This includes the claim of identity within the initial EAP- 2712 Response/Identity (MyID) packet, which is typically used to route the 2713 EAP conversation to the appropriate home backend authentication 2714 server. There may also be subsequent EAP-Response/Identity packets 2715 sent by the peer once the TLS channel has been established. 2717 Note that since the PEAPv2 peer may not present a certificate, it is 2718 not always possible to check the initial EAP-Response/Identity 2719 against the identity presented in the certificate, as is done in 2720 [RFC2716]. 2722 Moreover, it cannot be assumed that the peer identities presented 2723 within multiple EAP-Response/Identity packets will be the same. For 2724 example, the initial EAP-Response/Identity might correspond to a 2725 machine identity, while subsequent identities might be those of the 2726 user. Thus, PEAPv2 implementations SHOULD NOT abort the 2727 authentication just because the identities do not match. However, 2728 since the initial EAP-Response/Identity will determine the EAP server 2729 handling the authentication, if this or any other identity is 2730 inappropriate for use with the destination EAP server, there is no 2731 alternative but to terminate the PEAPv2 conversation. 2733 The protected identity or identities presented by the peer within 2734 PEAPv2 Part 2 may not be identical to the cleartext identity 2735 presented in PEAPv2 Part 1, for legitimate reasons. In order to 2736 shield the userID from snooping, the cleartext Identity may only 2737 provide enough information to enable routing of the authentication 2738 request to the correct realm. For example, the peer may initially 2739 claim the identity of "nouser@bigco.com" in order to route the 2740 authentication request to the bigco.com EAP server. Subsequently, 2741 once the TLS session has been negotiated, in PEAPv2 Part 2, the peer 2742 may claim the identity of "fred@bigco.com". Thus, PEAPv2 can provide 2743 protection for the user's identity, though not necessarily the 2744 destination realm, unless the PEAPv2 Part 1 conversation terminates 2745 at the local authentication server. 2747 As a result, PEAPv2 implementations SHOULD NOT attempt to compare the 2748 Identities claimed with Parts 1 and 2 of the PEAPv2 conversation. 2749 Similarly, if multiple Identities are claimed within PEAPv2 Part 2, 2750 these SHOULD NOT be compared. An EAP conversation may involve more 2751 than one EAP authentication method, and the identities claimed for 2752 each of these authentications could be different (e.g. a machine 2753 authentication, followed by a user authentication). 2755 5.8. Man-in-the-middle attack protection 2757 TLS protection can address a number of weaknesses in the EAP method; 2758 as well as EAP protocol weaknesses listed in the abstract and 2759 introduction sections in this document. 2761 Hence, the recommended solution is to always deploy authentication 2762 methods with protection of PEAPv2. 2764 if a deployment chooses to allow a EAP method protected by PEAP 2765 without protection of PEAP or IPsec at the same time, then this opens 2766 up a possibility of a man-in-the-middle attack. 2768 A man-in-the-middle can spoof the client to authenticate to it 2769 instead of the real EAP server; and forward the authentication to the 2770 real server over a protected tunnel. Since the attacker has access to 2771 the keys derived from the tunnel, it can gain access to the network. 2773 PEAP version 2 prevents this attack by using the keys generated by 2774 the inner EAP method in the crypto-binding exchange described in 2775 protected termination section. This attack is not prevented if the 2776 inner EAP method does not generate keys or if the keys generated by 2777 the inner EAP method can be compromised. Hence, in cases where the 2778 inner EAP method does not generate keys, the recommended solution is 2779 to always deploy authentication methods protected by PEAPv2. 2781 Alternatively, the attack can also be thwarted if the inner EAP 2782 method can signal to the peer that the packets are being sent within 2783 the tunnel. In most cases this may require modification to the inner 2784 EAP method. In order to allow for these implementations, PEAPv2 2785 implementations should inform inner EAP methods that the EAP method 2786 is being protected by a PEAPv2 tunnel. 2788 Since all sequence negotiations and exchanges are protected by TLS 2789 channel, they are immune to snooping and MITM attacks with the use of 2790 Crypto-Binding TLV. To make sure the same parties are involved tunnel 2791 establishment and previous inner method, before engaging the next 2792 method to sent more sensitive information, both peer and server MUST 2793 use the Crypto-Binding TLV between methods to check the tunnel 2794 integrity. If the Crypto-Binding TLV failed validation, they SHOULD 2795 stop the sequence and terminate the tunnel connection, to prevent 2796 more sensitive information being sent in subsequent methods. 2798 5.9. Cleartext forgeries 2800 As described in [RFC3748], EAP Success and Failure packets are not 2801 authenticated, so that they may be forged by an attacker without fear 2802 of detection. Forged EAP Failure packets can be used to convince an 2803 EAP peer to disconnect. Forged EAP Success and Failure packets may be 2804 used to convince a peer to disconnect; or convince a peer to access 2805 the network even before authentication is complete, resulting in 2806 denial of service for the peer. 2808 By supporting encrypted, authenticated and integrity protected 2809 success/failure indications, PEAPv2 provides protection against these 2810 attacks. 2812 Once the peer responds with the first PEAP packet; and the EAP server 2813 receives the first PEAPv2 packet from the peer, both MUST silently 2814 discard all clear text EAP messages unless both the PEAPv2 peer and 2815 server have indicated success or failure or error using a protected 2816 error or protected termination mechanism. The success/failure 2817 decisions sent by a protected mechanism indicate the final decision 2818 of the EAP authentication conversation. After success/failure has 2819 been indicated by a protected mechanism, the PEAPv2 client can 2820 process unprotected EAP success and EAP failure message; however MUST 2821 ignore any unprotected EAP success or failure messages where the 2822 decision does not match the decision of the protected mechanism. 2824 After a Fatal alert is received or after protected termination is 2825 complete, the peer or EAP server should accept clear text EAP 2826 messages. If the PEAPv2 tunnel is nested inside another tunnel, then 2827 the clear text EAP messages should only be accepted after protected 2828 termination of outer tunnels. 2830 [RFC3748] states that an EAP Success or EAP Failure packet terminates 2831 the EAP conversation, so that no response is possible. Since EAP 2832 Success and EAP Failure packets are not retransmitted, if the final 2833 packet is lost, then authentication will fail. As a result, where 2834 packet loss is expected to be non-negligible, unacknowledged 2835 success/failure indications lack robustness. 2837 As a result, a EAP server SHOULD send a clear text EAP success or 2838 EAP-failure packet after the protected success or failure packet or 2839 TLS alert. The peer MUST NOT require the clear text EAP Success or 2840 EAP Failure if it has received the protected success or failure or 2841 TLS alert. For more details, refer to [RFC228bis], Section 4.2. 2843 5.10. TLS Ciphersuites 2845 Anonymous ciphersuites are vulnerable to man-in-the-middle attacks, 2846 and SHOULD NOT be used with PEAPv2, unless the EAP methods inside 2847 PEAPv2 can address the man-in-the-middle attack or unless the man-in- 2848 the-middle attack can be addressed by mechanisms external to PEAPv2. 2850 5.11. Denial of service attacks 2852 Denial of service attacks are possible if the attacker can insert or 2853 modify packets in the authentication channel. The attacker can 2854 modify unprotected fields in the PEAP packet such as the EAP protocol 2855 or PEAP version number. This can result in a denial of service 2856 attack. It is also possible for the attacker to modify protected 2857 fields in a packet to cause decode errors resulting in a denial of 2858 service. In these ways the attacker can prevent access for peers 2859 connecting to the network. 2861 Denial of service attacks with multiplier impacts are more 2862 interesting than the ones above. It is possible to multiply the 2863 impact by creating a large number of TLS sessions with the EAP 2864 server. 2866 5.12. Server Unauthenticated Tunnel Provisioning Mode 2868 This section describes the rationale and security risks behind server 2869 unauthenticated tunnel provisioning mode. Server unauthenticated 2870 tunnel provisioning mode results in loss of security strength. Hence, 2871 PEAPv2 implementations are not required to implement this mode. 2873 In order to achieve strong mutual authentication, it is best to use 2874 an out of band mechanism to pre-provision the device with strong 2875 symmetric or asymmetric keys. In addition, if the device is not 2876 physically secure (mobile or devices at public places), then it is 2877 important to ensure that the device has secure storage. 2879 Devices such as regular operating systems typically support secure 2880 provisioning and secure credential storage capabilities, for example 2881 regular operating systems; and hence server unauthenticated tunnel 2882 provisioning mode is not recommended for these systems. 2884 If the provisioned credential is a shared key or asymmetric key 2885 issued to the peer, then the credential should only be issued to 2886 devices that can protect the provisioned credentials using secure 2887 storage, or use physical security. If the credentials are not 2888 protected, the attacker can compromise the provisioned credentials, 2889 and use it to get access to the network. Mobile light weight devices 2890 are typically not physically secure. Another concern is that 2891 credentials provisioned to a light weight mobile device that does not 2892 use secure storage could be transferred to a general operating system 2893 and used to get access to the network. 2895 If the provisioned credential is a certificate trusted root of the 2896 EAP server, this is public information and hence not susceptible to 2897 the same attacks as a shared key or asymmetric key. 2899 In server unauthenticated tunnel provisioning mode, an attacker may 2900 terminate the tunnel instead of the real server. The attacker can be 2901 detected after the crypto binding TLV is exchanged and validated. 2902 However, the EAP packets exchanged inside the tunnel until Crypto- 2903 Binding TLV is validated are available in unencrypted form to the 2904 attacker. It is difficult to completely negate the security risk 2905 unless the EAP methods inside the tunnel are secure; or unless 2906 physical wire security is assumed. These are a few guidelines to 2907 reduce the security risk: 2909 [1] Minimize the use of this mode only during initial authentication to 2910 the network to reduce the risk of attack. 2912 [2] If the password based EAP method used in provisioned mode is 2913 susceptible to dictionary attacks, then the implementation should 2914 support deployment of sound password password policies e.g. 2915 capability to enforce strong password policies and support rotation 2916 of passwords. 2918 [3] Disable this mode by default and require users to initiate 2919 provisioning mode explicitly rather than being prompted during 2920 initiation of regular authentication process. 2922 [4] Provide appropriate policy capabilities to allow administrators to 2923 lockdown the device and prevent regular users from enabling the 2924 mode. 2926 [5] Ensure that the EAP methods used support mutual authentication. 2928 [6] Ensure that the EAP methods used generate keys of sufficient 2929 strength to prevent compounding binding from being compromised. 2931 [7] Minimize the information disclosed to the EAP server. 2933 Notes: 2935 [a] The attacker may try to crack the password in the time required for 2936 authentication to complete. 2938 [b] The attacker may start the conversation, capture the hash, and 2939 launch a offline dictionary attack. 2941 5.12.1. Mechanism for credential provisioning 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 If the provisioned credential is a shared key or asymmetric key 2954 issued to the device, then the credential should only be issued to 2955 devices that can protect the provisioned credentials using secure 2956 storage, or using physical security. The attacker can compromise the 2957 provisioned credentials and use them to get access to the network. 2958 It is not advisable to assume physical security for Mobile devices 2959 and devices at public places. 2961 If the provisioned credential is a certificate trusted root of the 2962 EAP server, this is public information, and hence not susceptible to 2963 the same attacks. 2965 5.13. Security Claims 2967 Intended use: Wireless or Wired networks, and over 2968 the Internet, where physical security 2969 cannot be assumed. 2970 Auth. mechanism: Use arbitrary EAP and TLS authentication 2971 mechanisms for authentication of the 2972 client and server. 2973 Ciphersuite negotiation: Yes. 2974 Mutual authentication: Yes. Depends on the type of EAP method 2975 used within the tunnel and the type of 2976 authentication used within TLS. 2977 Integrity protection: Yes 2978 Replay protection: Yes 2979 Confidentiality: Yes 2980 Key derivation: Yes 2981 Key strength: Variable 2982 Dictionary attack prot: Not susceptible. 2983 Fast reconnect: Yes 2984 Crypt. binding: Yes. 2985 Acknowledged S/F: Yes 2986 Session independence: Yes. 2987 Fragmentation: Yes 2988 State Synchronization: Yes 2990 PEAPv2 derives keys by combining keys from TLS and the inner EAP 2991 methods. It should be noted that the use of TLS ciphersuites with a 2992 particular key lengths does not guarantee that the key strength of 2993 the keys will be equivalent to the length. The key exchange 2994 mechanisms (eg. RSA or Diffie-Hellman) used must provide sufficient 2995 security or they will be the weakest link. For example RSA key sizes 2996 with a modulus of 1024 bits provides less than 128 bits of security, 2997 this may provide sufficient key strength for some applications and 2998 not for others. See [PKLENGTH] for a detailed analysis of 2999 determining the public key strengths used to exchange symmetric keys. 3001 6. IANA Considerations 3003 This section provides guidance to the Internet Assigned Numbers 3004 Authority (IANA) regarding registration of values related to the 3005 PEAPv2 protocol, in accordance with BCP 26, [RFC2434]. 3007 The following name spaces in PEAPv2 require registration: TLV-Types, 3008 the Identity-Type field in the Identity-Type TLV, the Credential-Type 3009 field of the Server-Trusted-Root TLV, and the Action field of the 3010 Request-Action TLV. TLV types within Vendor-Specific TLVs do not 3011 require registration. 3013 6.1. Definition of Terms 3015 The following terms are used here with the meanings defined in BCP 3016 26: "name space", "assigned value", "registration". 3018 The following policies are used here with the meanings defined in BCP 3019 26: "Private Use", "First Come First Served", "Expert Review", 3020 "Specification Required", "IETF Consensus", "Standards Action". 3022 6.2. Recommended Registration Policies 3024 For "Designated Expert with Specification Required", the request is 3025 posted to the EAP WG mailing list (or, if it has been disbanded, a 3026 successor designated by the Area Director) for comment and review, 3027 and MUST include a pointer to a public specification. Before a 3028 period of 30 days has passed, the Designated Expert will either 3029 approve or deny the registration request and publish a notice of the 3030 decision to the EAP WG mailing list or its successor. A denial 3031 notice must be justified by an explanation and, in the cases where it 3032 is possible, concrete suggestions on how the request can be modified 3033 so as to become acceptable. 3035 TLV Types may assume a value between 0 and 16383 of which 0-20 have 3036 been allocated. Additional TLV type codes may be allocated following 3037 Designated Expert with Specification Required [RFC2434]. 3039 The Identity-Type field may assume a value between 0 and 65535, of 3040 which 0-2 have been allocated. Additional Identity-Type values may 3041 be allocated following Designated Expert with Specification Required 3042 [RFC2434]. 3044 The Credential-Type field may assume a value between 0 and 65535, of 3045 which 0-1 have already been allocated. Additional Credential-Type 3046 values may be allocated following Designated Expert with 3047 Specification Required [RFC2434]. 3049 The Action field may assume a value between 0 and 65535, of which 0-2 3050 have already been allocated. Additional Action values may be 3051 allocated following Designated Expert with Specification Required 3052 [RFC2434]. 3054 7. References 3056 7.1. Normative references 3058 [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", 3059 RFC 1321, April 1992. 3061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3062 Requirement Levels", BCP 14, RFC 2119, March 1997. 3064 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 3065 2246, November 1998. 3067 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 3068 Architecture", RFC 2373, July 1998. 3070 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 3071 2486, January 1999. 3073 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 3074 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 3075 1998. 3077 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3078 Considerations Section in RFCs", BCP 26, RFC 2434, October 3079 1998. 3081 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 3082 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3083 3748, June 2004. 3085 [IEEE80211] 3086 Information technology - Telecommunications and information 3087 exchange between systems - Local and metropolitan area 3088 networks - Specific Requirements Part 11: Wireless LAN Medium 3089 Access Control (MAC) and Physical Layer (PHY) Specifications, 3090 IEEE Std. 802.11-2003, 2003. 3092 [IEEE802.11i] 3093 Institute of Electrical and Electronics Engineers, "Unapproved 3094 Draft Supplement to Standard for Telecommunications and 3095 Information Exchange Between Systems - LAN/MAN Specific 3096 Requirements - Part 11: Wireless LAN Medium Access Control 3097 (MAC) and Physical Layer (PHY) Specifications: Specification 3098 for Enhanced Security", IEEE 802.11i, 2004. 3100 [IEEE8021X] 3101 IEEE Standards for Local and Metropolitan Area Networks: Port 3102 based Network Access Control, IEEE Std 802.1X-2004, December 3103 2004. 3105 [80211Req] 3106 Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 3107 for Wireless LANs", draft-walker-ieee802-req-04.txt, Internet 3108 draft (work in progress), August 2004. 3110 7.2. Informative references 3112 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 3113 1996. 3115 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. 3116 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 3117 1996. 3119 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 3120 Version 2 (DESE-bis)", RFC 2419, September 1998. 3122 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 3123 RFC 2420, September 1998. 3125 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 3126 2548, March 1999. 3128 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 3129 Authentication Dial In User Service (RADIUS)", RFC 2865, June 3130 2000. 3132 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 3133 RFC 2716, October 1999. 3135 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption 3136 (MPPE) Protocol", RFC 3078, March 2001. 3138 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 3139 Encryption (MPPE)", RFC 3079, March 2001. 3141 [RFC3546] Blake-Wilson, S., et al. "TLS Extensions", RFC 3546, June 3142 2003. 3144 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for EAP", RFC 3579, 3145 September 2003. 3147 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 3148 "IEEE 802.1X Remote Authentication Dial In User Service 3149 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 3151 [RFC3766] H. Orman and P. Hoffman, "Determining Strengths For Public 3152 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 3153 2004. 3155 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS 3156 PUB 46 (January 1977). 3158 [MODES] National Bureau of Standards, "DES Modes of Operation", FIPS 3159 PUB 81 (December 1980). 3161 [PEAPv0] Kamath, V., Palekar, A. and M. Wodrich, "Microsoft's PEAP 3162 version 0 (Implementation in Windows XP SP1)", draft-kamath- 3163 pppext-peapv0-00.txt, Internet draft (work in progress), July 3164 2002. 3166 [CompoundBinding] 3167 Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, "The 3168 Compound Authentication Binding Problem", draft-puthenkulam- 3169 eap-binding-04.txt, Internet Draft (work in progress), October 3170 2003. 3172 Appendix A - Examples 3174 [Issue] The examples have not been changed to show outer TLVs. 3176 A.1 Cleartext Identity Exchange 3178 In the case where an identity exchange occurs within PEAPv2 Part 1, 3179 the conversation will appear as follows: 3181 Authenticating Peer Authenticator 3182 ------------------- ------------- 3183 <- EAP-Request/ 3184 Identity 3185 EAP-Response/ 3186 Identity (MyID1) -> 3188 // Identity sent in the clear. May be a hint to help route the 3189 authentication request to EAP server, instead of the full user 3190 identity. 3192 <- EAP-Request/ 3193 EAP-Type=PEAP, V=2 3194 (PEAP Start, S bit set) 3195 EAP-Response/ 3196 EAP-Type=PEAP, V=2 3197 (TLS client_hello)-> 3198 <- EAP-Request/ 3199 EAP-Type=PEAP, V=2 3200 (TLS server_hello, 3201 TLS certificate, 3202 [TLS server_key_exchange,] 3203 [TLS certificate_request,] 3204 TLS server_hello_done) 3205 EAP-Response/ 3206 EAP-Type=PEAP, V=2 3207 ([TLS certificate,] 3208 TLS client_key_exchange, 3209 [TLS certificate_verify,] 3210 TLS change_cipher_spec, 3211 TLS finished) -> 3212 <- EAP-Request/ 3213 EAP-Type=PEAP, V=2 3214 (TLS change_cipher_spec, 3215 TLS finished, 3216 EAP-Request/EAP-Type=EAP-TLV 3217 [EAP-Payload-TLV[EAP-Request/ 3218 Identity]]) 3220 // identity protected by TLS. EAP-TLV packet does not include an EAP- 3221 header. 3223 TLS channel established (EAP messages sent within TLS channel 3224 encapsulated in EAP-TLV packets without EAP header) 3226 EAP-TLV [EAP-Payload-TLV 3227 [EAP-Response/Identity (MyID2)]]]-> 3229 <- EAP-TLV [EAP-Payload-TLV 3230 [EAP-Request/EAP-Type=X]] 3232 EAP-TLV [EAP-Payload-TLV 3233 [EAP-Response/EAP-Type=X]] -> 3235 // Protected termination 3237 <- EAP-TLV [Result TLV (Success), 3238 Crypto-Binding-TLV (Version=0, 3239 received-version=2, Nonce, B1_MAC), 3240 Intermediate-Result-TLV (Success)] 3242 EAP-TLV [Result-TLV (Success), 3243 Intermediate-Result-TLV (Success), 3244 Crypto-Binding-TLV (Version=0, 3245 received-version=2,Nonce, B2_MAC)]-> 3247 TLS channel torn down 3248 (messages sent in cleartext) 3250 <- EAP-Success 3252 A.2 No cleartext Identity Exchange 3254 Where all peers are known to support PEAPv2, a non-certificate 3255 authentication is desired for the client and the PEAP Part 1 3256 conversation is carried out between the peer and a local EAP server, 3257 the cleartext identity exchange may be omitted and the conversation 3258 appears as follows: 3260 Authenticating Peer Authenticator 3261 ------------------- ------------- 3262 <- EAP-Request/ 3263 EAP-Type=PEAP, V=2 3264 (PEAP Start, S bit set) 3266 EAP-Response/ 3267 EAP-Type=PEAP, V=2 3268 (TLS client_hello)-> 3269 <- EAP-Request/ 3270 EAP-Type=PEAP, V=2 3271 (TLS server_hello, 3272 TLS certificate, 3273 [TLS server_key_exchange,] 3274 [TLS certificate_request,] 3275 TLS server_hello_done) 3276 EAP-Response/ 3277 EAP-Type=PEAP, V=2 3278 ([TLS certificate,] 3279 TLS client_key_exchange, 3280 [TLS certificate_verify,] 3281 TLS change_cipher_spec, 3282 TLS finished) -> 3283 <- EAP-Request/ 3284 EAP-Type=PEAP, V=2 3285 (TLS change_cipher_spec, 3286 TLS finished, 3287 EAP-TLV [EAP-Payload-TLV 3288 (EAP-Request/Identity)]) 3290 TLS channel established 3291 (messages sent within the TLS channel) 3293 EAP-TLV [EAP-Payload-TLV 3294 [EAP-Response/Identity (MyID)]] -> 3296 <- EAP-TLV [EAP-Payload-TLV 3297 [EAP-Type=EAP-Request/ 3298 EAP-Type=X]] 3300 EAP-TLV [EAP-Payload-TLV 3301 [EAP-Response/EAP-Type=X 3302 or NAK] -> 3303 <- EAP-TLV [EAP-Payload-TLV 3304 [EAP-Request/EAP-Type=X]] 3306 EAP-TLV [EAP-Payload-TLV [EAP-Response/ 3307 EAP-Type=X]] -> 3309 // Protected success 3310 <- EAP-TLV [Crypto-Binding-TLV= 3311 (Version=0, Received-version=2, 3312 Nonce, B1_MAC), 3313 Intermediate-Result-TLV(Success), 3314 Result TLV (Success)] 3316 EAP-TLV [Crypto-Binding-TLV= 3317 (Version=0,Received-version=2, 3318 Nonce, B2_MAC), 3319 Intermediate-Result-TLV (Success), 3320 Result TLV (Success)]-> 3322 TLS channel torn down 3323 (messages sent in cleartext) 3325 <- EAP-Success 3327 A.3 Client certificate authentication with identity privacy 3329 Where all peers are known to support PEAPv2, where client certificate 3330 authentication is desired and the PEAPv2 Part 1 conversation is 3331 carried out between the peer and a local EAP server, the cleartext 3332 identity exchange may be omitted and the conversation appears as 3333 follows: 3335 Authenticating Peer Authenticator 3336 ------------------- ------------- 3337 <- EAP-Request/ 3338 EAP-Type=PEAP, V=2 3339 (PEAP Start, S bit set) 3341 EAP-Response/ 3342 EAP-Type=PEAP, V=2 3343 (TLS client_hello)-> 3344 <- EAP-Request/ 3345 EAP-Type=PEAP, V=2 3346 (TLS server_hello, 3347 TLS certificate, 3348 [TLS server_key_exchange,] 3349 TLS server_hello_done) 3350 EAP-Response/ 3351 EAP-Type=PEAP, V=2 3352 (TLS client_key_exchange, 3353 TLS change_cipher_spec, 3354 TLS finished) -> 3355 <- EAP-Request/ 3356 EAP-Type=PEAP, V=2 3357 (TLS change_cipher_spec, 3358 TLS finished,TLS Hello-Request) 3359 EAP-Response/ 3360 EAP-Type=PEAP, V=2 3361 (TLS client_hello)-> 3363 TLS channel established 3364 (messages sent within the TLS channel) 3366 <- EAP-Request/ 3367 EAP-Type=PEAP, V=2 3368 (TLS server_hello, 3369 TLS certificate, 3370 [TLS server_key_exchange,] 3371 [TLS certificate_request,] 3372 TLS server_hello_done) 3373 EAP-Response/ 3374 EAP-Type=PEAP, V=2 3375 ([TLS certificate,] 3376 TLS client_key_exchange, 3377 [TLS certificate_verify,] 3378 TLS change_cipher_spec, 3379 TLS finished) -> 3381 <- EAP-Request/ 3382 EAP-Type=PEAP, V=2 3383 (TLS change_cipher_spec, 3384 TLS finished, EAP-TLV 3385 [Crypto-Binding-TLV (version=0, 3386 Received-version=2, Nonce, 3387 B1_MAC), 3388 Result-TLV (Success)]) 3390 // packet format within the TLS channel 3392 EAP-TLV [ 3393 Crypto-Binding-TLV=(Version=0, 3394 Received-version=2, 3395 Nonce, B2_MAC), 3396 Result TLV (Success)] 3398 TLS channel torn down 3399 (messages sent in cleartext) 3401 <- EAP-Success 3403 A.4 Fragmentation and Reassembly 3405 In the case where the PEAP fragmentation is required, the 3406 conversation will appear as follows: 3408 Authenticating Peer Authenticator 3409 ------------------- ------------- 3410 <- EAP-Request/ 3411 Identity 3413 EAP-Response/ 3414 Identity (MyID) -> 3415 <- EAP-Request/ 3416 EAP-Type=PEAP, V=2 3417 (PEAP Start, S bit set) 3419 EAP-Response/ 3420 EAP-Type=PEAP, V=2 3421 (TLS client_hello)-> 3422 <- EAP-Request/ 3423 EAP-Type=PEAP, V=2 3424 (TLS server_hello, 3425 TLS certificate, 3426 [TLS server_key_exchange,] 3427 [TLS certificate_request,] 3428 TLS server_hello_done) 3429 (Fragment 1: L, M bits set) 3431 EAP-Response/ 3432 EAP-Type=PEAP, V=2 -> 3434 <- EAP-Request/ 3435 EAP-Type=PEAP, V=2 3436 (Fragment 2: M bit set) 3437 EAP-Response/ 3438 EAP-Type=PEAP, V=2 -> 3439 <- EAP-Request/ 3440 EAP-Type=PEAP, V=2 3441 (Fragment 3) 3442 EAP-Response/ 3443 EAP-Type=PEAP, V=2 3444 ([TLS certificate,] 3445 TLS client_key_exchange, 3446 [TLS certificate_verify,] 3447 TLS change_cipher_spec, 3448 TLS finished) 3449 (Fragment 1: L, M bits set)-> 3451 <- EAP-Request/ 3452 EAP-Type=PEAP, V=2 3453 EAP-Response/ 3454 EAP-Type=PEAP, V=2 3455 (Fragment 2)-> 3456 <- EAP-Request/ 3457 EAP-Type=PEAP, V=2 3458 (TLS change_cipher_spec, 3459 TLS finished, EAP-TLV 3460 [EAP-Payload-TLV[ 3461 EAP-Request/Identity]]) 3463 TLS channel established 3464 (messages sent within the TLS channel) 3466 EAP-TLV 3467 [EAP-Payload-TLV 3468 [EAP-Response/Identity(myID)]] -> 3470 <- EAP-TLV [ EAP-Payload-TLV 3471 [EAP-Request/EAP-Type=X]] 3473 EAP-TLV [EAP-Payload-TLV 3474 [EAP-Response/EAP-Type=X or NAK]]-> 3476 <- EAP-TLV [ EAP-Payload-TLV 3477 [EAP-Request/EAP-Type=X]] 3479 EAP-TLV [EAP-Payload-TLV 3480 [EAP-Response/EAP-Type=X] -> 3482 <- EAP-TLV [Crypto-Binding-TLV 3483 =(Version=0, Received-Version=2, 3484 Nonce, B1_MAC), 3485 Intermediate-Result-TLV(Success), 3486 Result TLV (Success)] 3488 EAP-TLV [ 3489 Crypto-Binding-TLV=(Version=0, 3490 Received-Version=2,Nonce, B2_MAC), 3491 Result TLV (Success), 3492 Intermediate-Result-TLV (Success)] -> 3494 TLS channel torn down 3495 (messages sent in cleartext) 3497 <- EAP-Success 3499 A.5 Server authentication fails in Part 2 3501 In the case where the server authenticates to the client successfully 3502 in PEAPv2 Part 1, but the client fails to authenticate to the server 3503 in PEAPv2 Part 2, the conversation will appear as follows: 3505 Authenticating Peer Authenticator 3506 ------------------- ------------- 3507 <- EAP-Request/ 3508 Identity 3510 EAP-Response/ 3511 Identity (MyID) -> 3512 <- EAP-Request/ 3513 EAP-Type=PEAP, V=2 3514 (PEAP Start, S bit set) 3515 EAP-Response/ 3516 EAP-Type=PEAP, V=2 3517 (TLS client_hello)-> 3518 <- EAP-Request/ 3519 EAP-Type=PEAP, V=2 3520 (TLS server_hello, 3521 TLS certificate, 3522 [TLS server_key_exchange,] 3523 [TLS certificate_request,] 3524 TLS server_hello_done) 3525 EAP-Response/ 3526 EAP-Type=PEAP, V=2 3527 ([TLS certificate,] 3528 TLS client_key_exchange, 3529 [TLS certificate_verify,] 3530 TLS change_cipher_spec, 3531 TLS finished) -> 3532 <- EAP-Request/ 3533 EAP-Type=PEAP, V=2 3534 (TLS change_cipher_spec, 3535 TLS finished, EAP-TLV 3536 [EAP-Payload-TLV 3537 [EAP-Request/Identity]]) 3539 TLS channel established 3540 (messages sent within the TLS channel) 3542 EAP-TLV [EAP-Payload-TLV 3543 [EAP-Response/Identity (MyID)]] -> 3545 <- EAP-TLV [EAP-Payload-TLV 3546 [EAP-Request/EAP-Type=X]] 3548 EAP-TLV [EAP-Payload 3549 [EAP-Response/EAP-Type=X 3550 or NAK]] -> 3551 <- EAP-TLV [EAP-Payload 3552 [EAP-Request/EAP-Type=X]] 3554 EAP-TLV [EAP-Payload 3555 [EAP-Response/ 3556 EAP-Type=X]] -> 3557 <- EAP-TLV [Crypto-Binding-TLV 3558 (Version=0, Received-Version=2, 3559 Nonce, B1_MAC), 3560 Intermediate-Result-TLV (Failure), 3561 Result TLV (Failure)] 3563 EAP-TLV [Crypto-Binding-TLV 3564 (Version=0, Received-version=2, 3565 Nonce, B2_MAC), 3566 Result TLV (Failure), 3567 Intermediate-Result-TLV (Failure)] 3569 (TLS session cache entry flushed) 3570 TLS channel torn down 3571 (messages sent in cleartext) 3573 <- EAP-Failure 3575 A.6 Server authentication fails in Part 1 3577 In the case where server authentication is unsuccessful in PEAP Part 3578 1, the conversation will appear as follows: 3580 Authenticating Peer Authenticator 3581 ------------------- ------------- 3582 <- EAP-Request/ 3583 Identity 3584 EAP-Response/ 3585 Identity (MyID) -> 3586 <- EAP-Request/ 3587 EAP-Type=PEAP, V=2 3588 (PEAP Start) 3589 EAP-Response/ 3590 EAP-Type=PEAP, V=2 3591 (TLS client_hello)-> 3592 <- EAP-Request/ 3593 EAP-Type=PEAP, V=2 3594 (TLS server_hello, 3595 TLS certificate, 3596 [TLS server_key_exchange,] 3597 TLS server_hello_done) 3598 EAP-Response/ 3599 EAP-Type=PEAP, V=2 3600 (TLS client_key_exchange, 3601 [TLS certificate_verify,] 3602 TLS change_cipher_spec, 3603 TLS finished) -> 3604 <- EAP-Request/ 3605 EAP-Type=PEAP, V=2 3606 (TLS change_cipher_spec, 3607 TLS finished, EAP-TLV 3608 [EAP-Payload-TLV [ 3609 EAP-Request/Identity]]) 3610 EAP-Response/ 3611 EAP-Type=PEAP, V=2 3612 (TLS Alert message) -> 3613 <- EAP-Failure 3614 (TLS session cache entry flushed) 3616 A.7 Session resume success 3618 In the case where a previously established session is being resumed, 3619 the EAP server supports TLS session cache flushing for unsuccessful 3620 PEAPv2 Part 2 authentications and both sides authenticate 3621 successfully, the conversation will appear as follows: 3623 Authenticating Peer Authenticator 3624 ------------------- ------------- 3625 <- EAP-Request/ 3626 Identity 3627 EAP-Response/ 3628 Identity (MyID) -> 3629 <- EAP-Request/ 3630 EAP-Type=PEAP,V=2 3631 (PEAP Start) 3632 EAP-Response/ 3633 EAP-Type=PEAP, V=2 3634 (TLS client_hello)-> 3635 <- EAP-Request/ 3636 EAP-Type=PEAP, V=2 3637 (TLS server_hello, 3638 TLS change_cipher_spec 3639 TLS finished) 3640 EAP-Response/ 3641 EAP-Type=PEAP, V=2 3642 (TLS change_cipher_spec, 3643 TLS finished) -> 3644 <- EAP-Request/ 3645 EAP-Type=EAP-TLV 3646 Result TLV (Success) 3648 // Compound MAC calculated using TLS keys since there were no inner 3649 EAP methods. 3651 EAP-Response/ 3652 EAP-Type=EAP-TLV 3653 Crypto-Binding-TLV=(Version=0, Nonce, B2_MAC), 3654 Result TLV (Success)-> 3656 TLS channel torn down 3657 (messages sent in cleartext) 3659 <- EAP-Success 3661 A.8 Session resume failure 3663 In the case where a previously established session is being resumed, 3664 and the server authenticates to the client successfully but the 3665 client fails to authenticate to the server, the conversation will 3666 appear as follows: 3668 Authenticating Peer Authenticator 3669 ------------------- ------------- 3670 <- EAP-Request/ 3671 Identity 3672 EAP-Response/ 3673 Identity (MyID) -> 3674 <- EAP-Request/ 3675 EAP-Request/ 3676 EAP-Type=PEAP, V=2 3677 (PEAP Start) 3678 EAP-Response/ 3679 EAP-Type=PEAP, V=2 3680 (TLS client_hello) -> 3681 <- EAP-Request/ 3682 EAP-Type=PEAP, V=2 3683 (TLS server_hello, 3684 TLS change_cipher_spec, 3685 TLS finished) 3686 EAP-Response/ 3687 EAP-Type=PEAP, V=2 3688 (TLS change_cipher_spec, 3689 TLS finished) -> 3690 <- EAP-Request 3691 EAP-Type=PEAP, V=2 3692 (TLS Alert message) 3693 EAP-Response 3694 EAP-Type=PEAP, V=2 -> 3695 <- EAP-Failure 3696 (TLS session cache entry flushed) 3698 A.9 Session resume failure 3700 In the case where a previously established session is being resumed, 3701 and the server authentication is unsuccessful, the conversation will 3702 appear as follows: 3704 Authenticating Peer Authenticator 3705 ------------------- ------------- 3706 <- EAP-Request/ 3707 Identity 3708 EAP-Response/ 3709 Identity (MyID) -> 3710 <- EAP-Request/ 3711 EAP-Request/ 3712 EAP-Type=PEAP, V=2 3713 (PEAP Start) 3714 EAP-Response/ 3715 EAP-Type=PEAP, V=2 3716 (TLS client_hello)-> 3717 <- EAP-Request/ 3718 EAP-Type=PEAP, V=2 3719 (TLS server_hello, 3720 TLS change_cipher_spec, 3721 TLS finished) 3722 EAP-Response/ 3723 EAP-Type=PEAP, V=2 3724 (TLS change_cipher_spec, 3725 TLS finished) 3726 <- EAP-Request/ 3727 EAP-Type=PEAP, V=2 3728 EAP-Response/ 3729 EAP-Type=PEAP, V=2 3730 (TLS Alert message) -> 3732 (TLS session cache entry flushed) 3733 <- EAP-Failure 3735 A.10 PEAP version negotiation 3737 In the case where the peer and authenticator have mismatched PEAP 3738 versions (e.g. the peer has a pre-standard implementation with 3739 version 0, and the authenticator has an implementation compliant with 3740 this specification), the conversation will occur as follows: 3742 Authenticating Peer Authenticator 3743 ------------------- ------------- 3744 <- EAP-Request/ 3745 Identity 3746 EAP-Response/ 3747 Identity (MyID) -> 3748 <- EAP-Request/ 3749 EAP-Request/ 3750 EAP-Type=PEAP, V=2 3751 (PEAP Start) 3752 EAP-Response/ 3753 EAP-Type=PEAP, V=0 3754 (TLS client_hello)-> 3755 <- EAP-Request/ 3756 EAP-Type=PEAP, V=0 3757 (TLS server_hello, 3758 TLS change_cipher_spec, 3759 TLS finished) 3761 //conversation continued using pre-standard PEAP version 0 3763 A.11 Sequences of EAP methods 3765 Where PEAPv2 is negotiated, with a sequence of EAP method X followed 3766 by method Y, the conversation will occur as follows: 3768 Authenticating Peer Authenticator 3769 ------------------- ------------- 3770 <- EAP-Request/ 3771 Identity 3772 EAP-Response/ 3773 Identity (MyID1) -> 3774 <- EAP-Request/ 3775 EAP-Type=PEAP, V=2 3776 (PEAP Start, S bit set) 3778 EAP-Response/ 3779 EAP-Type=PEAP, V=2 3780 (TLS client_hello)-> 3781 <- EAP-Request/ 3782 EAP-Type=PEAP, V=2 3783 (TLS server_hello, 3784 TLS certificate, 3785 [TLS server_key_exchange,] 3786 [TLS certificate_request,] 3787 TLS server_hello_done) 3788 EAP-Response/ 3789 EAP-Type=PEAP, V=2 3790 ([TLS certificate,] 3791 TLS client_key_exchange, 3792 [TLS certificate_verify,] 3793 TLS change_cipher_spec, 3794 TLS finished) -> 3795 <- EAP-Request/ 3796 EAP-Type=PEAP, V=2 3797 (TLS change_cipher_spec, 3798 TLS finished, EAP-TLV 3799 [EAP-Payload-TLV[ 3800 EAP-Request/Identity]]) 3802 TLS channel established 3803 (messages sent within the TLS channel) 3805 EAP-TLV [EAP-Payload-TLV 3806 [EAP-Response/Identity]] -> 3808 <- EAP-TLV [EAP-Payload-TLV 3809 [EAP-Request/EAP-Type=X]]] 3811 EAP-TLV [EAP-Payload-TLV 3812 [EAP-Response/EAP-Type=X]] -> 3814 <- EAP-TLV [ EAP-Payload-TLV 3815 [EAP-Request/EAP-Type=X]] 3817 EAP-TLV [EAP-Payload-TLV 3818 [EAP-Response/EAP-Type=X]]-> 3820 <- EAP-TLV [EAP Payload TLV [EAP-Type=Y], 3821 (Intermediate Result TLV (Success), 3822 Crypto-Binding-TLV 3823 (Version=0, Received-version=2, 3824 Nonce, B1_MAC))] 3826 // Next EAP conversation started after successful completion of 3827 previous method X. The Intermediate-Status and Crypto-Binding TLVs 3828 are sent in next packet to minimize round-trips. In this example, 3829 identity request is not sent before negotiating EAP-Type=Y. 3831 EAP-TLV [EAP-Payload-TLV [EAP-Type=Y], 3832 (Intermediate Result TLV (Success), 3833 Crypto-Binding-TLV (Version=0, 3834 Received-version=2, Nonce, B2_MAC))]-> 3836 // Compound MAC calculated using Keys generated from 3837 EAP methods X and the TLS tunnel. 3839 <- EAP-TLV [EAP Payload TLV [ 3840 EAP-Type=Y]] 3842 EAP-TLV[EAP Payload TLV 3843 [EAP-Type=Y]] -> 3844 <- EAP-TLV [Result-TLV (Success), 3845 Intermediate Result TLV (Success), 3846 Crypto-Binding-TLV 3847 (Version=0, Received-version=2, 3848 Nonce, B1_MAC))] 3850 EAP-TLV [(Result-TLV (Success), 3851 Intermediate Result TLV (Success), 3852 Crypto-Binding-TLV (Version=0, 3853 Received-version=2, Nonce, B2_MAC))]-> 3855 // Compound MAC calculated using Keys generated from EAP methods X 3856 and Y and the TLS tunnel. // Compound Keys generated using Keys 3857 generated from EAP methods X and Y; and the TLS tunnel. 3859 TLS channel torn down (messages sent in cleartext) 3861 <- EAP-Success 3863 Acknowledgments 3865 Thanks to Hakan Andersson, Jan-Ove Larsson and Magnus Nystrom of RSA 3866 Security; Bernard Aboba, Vivek Kamath, Stephen Bensley and Narendra 3867 Gidwani of Microsoft; Ilan Frenkel and Nancy Cam-Winget of Cisco; 3868 Jose Puthenkulam of Intel for their contributions and critiques. 3870 The compound binding exchange to address man-in-the-middle attack is 3871 based on the draft "The Compound Authentication Binding 3872 Problem"[CompoundBinding]. 3874 The vast majority of the work by Simon Josefsson and Hakan Andersson 3875 was done while they were employed at RSA Laboratories. 3877 Author Addresses 3879 Ashwin Palekar 3880 Microsoft Corporation 3881 One Microsoft Way 3882 Redmond, WA 98052 3884 Phone: +1 425 882 8080 3885 EMail: ashwinp@microsoft.com 3887 Dan Simon 3888 Microsoft Corporation 3889 One Microsoft Way 3890 Redmond, WA 98052 3891 Phone: +1 425 706 6711 3892 EMail: dansimon@microsoft.com 3894 Glen Zorn 3895 Cisco Systems 3896 500 108th Avenue N.E. 3897 Suite 500 3898 Bellevue, Washington 98004 3900 Phone: + 1 425 438 8210 3901 Fax: + 1 425 438 1848 3902 EMail: gwz@cisco.com 3904 Simon Josefsson 3905 Drottningholmsvagen 70 3906 112 42 Stockholm 3907 Sweden 3909 Phone: +46 8 619 04 22 3910 EMail: jas@extundo.com 3912 Hao Zhou 3913 Cisco Systems, Inc. 3914 4125 Highlander Parkway 3915 Richfield, OH 44286 3917 Phone: +1 330 523 2132 3918 Fax: +1 330 523 2239 3919 EMail: hzhou@cisco.com 3921 Joseph Salowey 3922 Cisco Systems 3923 2901 3rd Ave 3924 Seattle, WA 98121 3926 Phone: +1 206 256 3380 3927 EMail: jsalowey@cisco.com 3929 Intellectual Property Statement 3931 The IETF takes no position regarding the validity or scope of any 3932 intellectual property or other rights that might be claimed to 3933 pertain to the implementation or use of the technology described in 3934 this document or the extent to which any license under such rights 3935 might or might not be available; neither does it represent that it 3936 has made any effort to identify any such rights. Information on the 3937 IETF's procedures with respect to rights in standards-track and 3938 standards- related documentation can be found in BCP-11. Copies of 3939 claims of rights made available for publication and any assurances of 3940 licenses to be made available, or the result of an attempt made to 3941 obtain a general license or permission for the use of such 3942 proprietary rights by implementors or users of this specification can 3943 be obtained from the IETF Secretariat. 3945 The IETF invites any interested party to bring to its attention any 3946 copyrights, patents or patent applications, or other proprietary 3947 rights which may cover technology that may be required to practice 3948 this standard. Please address the information to the IETF Executive 3949 Director. 3951 Disclaimer of Validity 3953 This document and the information contained herein are provided on an 3954 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3955 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3956 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3957 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3958 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3959 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3961 Copyright Statement 3963 Copyright (C) The Internet Society (2004). This document is subject 3964 to the rights, licenses and restrictions contained in BCP 78, and 3965 except as set forth therein, the authors retain all their rights. 3967 Open Issues 3969 Open issues with this specification are tracked on the following web 3970 site: 3972 http://www.drizzle.com/~aboba/PEAP/