idnits 2.17.1 draft-cam-winget-eap-fast-provisioning-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1812. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (October 31, 2008) is 5656 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '40' on line 450 -- Looks like a reference, but probably isn't: '16' on line 452 == Outdated reference: A later version (-05) exists of draft-zhou-emu-fast-gtc-04 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Cam-Winget 3 Internet-Draft D. McGrew 4 Intended status: Informational J. Salowey 5 Expires: May 4, 2009 H. Zhou 6 Cisco Systems 7 October 31, 2008 9 Dynamic Provisioning using Flexible Authentication via Secure Tunneling 10 Extensible Authentication Protocol (EAP-FAST) 11 draft-cam-winget-eap-fast-provisioning-10 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 4, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The flexible authentication via secure tunneling EAP method (EAP- 45 FAST) enables secure communication between a peer and a server by 46 using Transport Layer Security (TLS) to establish a mutually 47 authenticated tunnel. EAP-FAST also enables the provisioning 48 credentials or other information through this protected tunnel. This 49 document describes the use of EAP-FAST for dynamic provisioning. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Specification Requirements . . . . . . . . . . . . . . . . 4 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. EAP-FAST Provisioning Modes . . . . . . . . . . . . . . . . . 6 59 3. Dynamic Provisioning using EAP-FAST Conversation . . . . . . . 8 60 3.1. Phase 1 TLS tunnel . . . . . . . . . . . . . . . . . . . . 8 61 3.1.1. Server-Authenticated Phase 1 . . . . . . . . . . . . . 8 62 3.1.2. Server-Unauthenticated Phase 1 . . . . . . . . . . . . 8 63 3.2. Phase 2 - Tunneled Authentication and Provisioning . . . . 9 64 3.2.1. Server-Authenticated Tunneled Authentication . . . . . 9 65 3.2.2. Server-Unauthenticated Tunneled Authentication . . . . 10 66 3.2.3. Authenticating Using EAP-MSCHAPv2 . . . . . . . . . . 10 67 3.2.4. Use of other Inner EAP Methods for EAP-FAST 68 Provisioning . . . . . . . . . . . . . . . . . . . . . 11 69 3.3. Key Derivations Used in the EAP-FAST Provisioning 70 Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.4. Peer-Id, Server-Id and Session-Id . . . . . . . . . . . . 12 72 3.5. Network Access after EAP-FAST Provisioning . . . . . . . . 12 74 4. Information Provisioned in EAP-FAST . . . . . . . . . . . . . 14 75 4.1. Protected Access Credential . . . . . . . . . . . . . . . 14 76 4.1.1. Tunnel PAC . . . . . . . . . . . . . . . . . . . . . . 14 77 4.1.2. Machine Authentication PAC . . . . . . . . . . . . . . 15 78 4.1.3. User Authorization PAC . . . . . . . . . . . . . . . . 15 79 4.1.4. PAC Provisioning . . . . . . . . . . . . . . . . . . . 16 80 4.2. PAC TLV Format . . . . . . . . . . . . . . . . . . . . . . 16 81 4.2.1. Formats for PAC Attributes . . . . . . . . . . . . . . 17 82 4.2.2. PAC-Key . . . . . . . . . . . . . . . . . . . . . . . 18 83 4.2.3. PAC-Opaque . . . . . . . . . . . . . . . . . . . . . . 19 84 4.2.4. PAC-Info . . . . . . . . . . . . . . . . . . . . . . . 20 85 4.2.5. PAC-Acknowledgement TLV . . . . . . . . . . . . . . . 22 86 4.2.6. PAC-Type TLV . . . . . . . . . . . . . . . . . . . . . 22 87 4.3. Trusted Server Root Certificate . . . . . . . . . . . . . 23 88 4.3.1. Server-Trusted-Root TLV . . . . . . . . . . . . . . . 24 89 4.3.2. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . . 25 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 94 6.1. Provisioning Modes and Man-in-the-middle Attacks . . . . . 28 95 6.1.1. Server-Authenticated Provisioning Mode and 96 Man-in-the-middle Attacks . . . . . . . . . . . . . . 28 97 6.1.2. Server-Unauthenticated Provisioning Mode and 98 Man-in-the-middle Attacks . . . . . . . . . . . . . . 28 99 6.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 30 100 6.3. Considerations in Selecting a Provisioning Mode . . . . . 31 101 6.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 31 102 6.5. Tunnel PAC Usage . . . . . . . . . . . . . . . . . . . . . 31 103 6.6. Machine Authentication PAC Usage . . . . . . . . . . . . . 31 104 6.7. User Authorization PAC Usage . . . . . . . . . . . . . . . 32 105 6.8. PAC Storage Considerations . . . . . . . . . . . . . . . . 32 106 6.9. Security Claims . . . . . . . . . . . . . . . . . . . . . 33 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 110 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 111 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 112 8.2. Informative References . . . . . . . . . . . . . . . . . . 36 114 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37 115 A.1. Example 1: Successful Tunnel PAC Provisioning . . . . . . 37 116 A.2. Example 2: Failed Provisioning . . . . . . . . . . . . . . 38 117 A.3. Example 3: Provisioning a Authentication Server's 118 Trusted Root Certificate . . . . . . . . . . . . . . . . . 40 120 Appendix B. Recent Changes . . . . . . . . . . . . . . . . . . . 42 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 123 Intellectual Property and Copyright Statements . . . . . . . . . . 45 125 1. Introduction 127 EAP-FAST [RFC4851] is an EAP method that can be used to mutually 128 authenticate peer and server. Credentials such as a pre-shared key, 129 certificate trust anchor or a Protected Access Credential (PAC) must 130 be provisioned to the peer before it can establish mutual 131 authentication with the server. In many cases, the provisioning of 132 such information presents deployment hurdles. Through the use of the 133 protected TLS [RFC4346] tunnel, EAP-FAST can enable dynamic in-band 134 provisioning to address such deployment obstacles. 136 1.1. Specification Requirements 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 1.2. Terminology 144 Much of the terminology used in this document comes from [RFC3748]. 145 The terms "peer" and "server" are used interchangeably with the terms 146 "EAP peer" and "EAP server" respectively. Additional terms are 147 defined below: 149 Man in the Middle (MitM) 151 An adversary that can successfully inject itself between a peer 152 and EAP server. The MitM succeeds by impersonating itself as a 153 valid peer or server. 155 Provisioning 157 Providing peer with a trust anchor, shared secret or other 158 appropriate information needed to establish a security 159 association. 161 Protected Access Credential (PAC) 163 Credentials distributed to a peer for future optimized network 164 authentication. The PAC consists of at most three components: a 165 shared secret, an opaque element and optional information. The 166 shared secret part contains the secret key shared between the peer 167 and server. The opaque part contains the shared secret encrypted 168 by a private key only known to the server. It is provided to the 169 peer and is presented back to the server when the peer wishes to 170 obtain access to network resources. Finally, a PAC may optionally 171 include other information that may be useful to the peer. 173 Tunnel PAC 175 A set of credentials stored by the peer and consumed by both the 176 peer and the server to establish a TLS tunnel. 178 User Authorization PAC 180 A User Authorization PAC is server encrypted data containing 181 authorization information associated with a previously 182 authenticated user. The User Authorization PAC does not contain a 183 key, but rather it is generally bound to a Tunnel PAC which is 184 used with the User Authorization PAC. 186 Machine Authentication PAC 188 A Machine Authentication PAC contains server encrypted data 189 containing authorization information associated with a device. A 190 Machine Authentication PAC may be used instead of a Tunnel PAC to 191 establish the TLS tunnel to provide machine authentication and 192 authorization information. The Machine Authentication PAC is 193 useful in cases where the machine needs to be authenticated and 194 authorized to access a network before a user has logged in. 196 2. EAP-FAST Provisioning Modes 198 EAP-FAST supports two modes for provisioning: 200 1. Server-Authenticated Provisioning Mode - Provisioning inside a 201 TLS tunnel that provides server-side authentication. 203 2. Server-Unauthenticated Provisioning Mode - Provisioning inside an 204 anonymous TLS tunnel. 206 The EAP-FAST provisioning modes use EAP-FAST phase 2 inside a secure 207 TLS tunnel established during phase 1. [RFC4851] describes the EAP- 208 FAST phases in greater detail. 210 In the Server-Authenticated Provisioning Mode, the peer has 211 successfully authenticated the EAP server as part of EAP-FAST Phase 1 212 (i.e. TLS tunnel establishment). Additional exchanges MAY occur 213 inside the tunnel to allow the EAP Server to authenticate the EAP 214 peer before provisioning any information. 216 In the Server-Unauthenticated Provisioning Mode, an unauthenticated 217 TLS tunnel is established in the EAP-FAST Phase 1. The peer MUST 218 negotiate a TLS anonymous Diffie-Hellman based cipher suite to signal 219 that it wishes to use Server-Unauthenticateded Provisioning Mode. 220 This provisioning mode enables the bootstrapping of peers where the 221 peer lacks strong credentials usable for mutual authentication with 222 the server. 224 Since the server is not authenticated in the Server-Unauthenticated 225 Provisioning Mode, it is possible that an attacker may intercept the 226 TLS tunnel. If an anonymous tunnel is used then the peer and server 227 MUST negotiate and successfully complete an EAP method supporting 228 mutual authentication and key derivation as described in Section 6. 229 The peer then uses the Crypto-Binding TLV to validate the integrity 230 of the TLS tunnel, thereby verifying that the exchange was not 231 subject to a man-in-the-middle attack. 233 Server-Authenticated Provisioning Mode protects against the man-in- 234 the-middle, however it requires provisioning the peer with 235 credentials necessary to authenticate the server. Environments 236 willing to trade off the security risk of a man-in-the-middle for 237 ease of deployment can choose to use the Server-Unauthenticated 238 Provisioning Mode. 240 Assuming that an inner EAP method and Crypto-Binding TLV exchange is 241 successful, the server will subsequently provide credential 242 information, such as a shared key using a PAC TLV or the trusted 243 certificate root(s) of the server using a Server-Trusted-Root TLV. 245 Once the EAP-FAST Provisioning conversation completes, the peer is 246 expected to use the provisioned credentials in subsequent EAP-FAST 247 authentications. 249 3. Dynamic Provisioning using EAP-FAST Conversation 251 The provisioning occurs in the following steps which are detailed in 252 the subsequent sections and in RFC 4851. First the EAP-FAST phase 1 253 TLS tunnel is established. During this process extra material is 254 extracted from the TLS key derivation for use as challenges in the 255 subsequent authentication exchange. Next, an inner EAP method, such 256 as EAP-MSCHAPv2, is executed within the EAP-FAST phase 2 TLS tunnel 257 to authenticate the client using the challenges derived from the 258 phase 1 TLS exchange. Following successful authentication and 259 Crypto-Binding TLV exchange, the server provisions the peer with PAC 260 information including the secret PAC-Key and the PAC-Opaque. 261 Finally, the EAP-FAST conversation completes with Result TLV 262 exchanges defined in RFC 4851. The exported EAP MSK and EMSK are 263 derived from a combination of the tunnel key material and key 264 material from the inner EAP method exchange. 266 3.1. Phase 1 TLS tunnel 268 3.1.1. Server-Authenticated Phase 1 270 The provisioning EAP-FAST exchange uses the same sequence as the EAP- 271 FAST authentication phase 1 to establish a protected TLS tunnel. 272 Implementations supporting this version of the Sever-Authenticated 273 Provisioning Mode MUST support the following TLS ciphersuites defined 274 in [RFC4346]: 276 TLS_RSA_WITH_RC4_128_SHA 277 TLS_RSA_WITH_AES_128_CBC_SHA 278 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 280 Other TLS ciphersuites that provide server authentication and 281 encryption MAY be supported. The server MAY authenticate the peer 282 during the TLS handshake in Server-Authenticated Provisioning Mode. 283 To adhere to best security practices, the peer MUST validate the 284 server's certificate chain when performing server-side authentication 285 to obtain the full security benefits of Server-Authenticated 286 provisioning. 288 3.1.2. Server-Unauthenticated Phase 1 290 Implementations supporting this version of the Sever-Unauthenticated 291 Provisioning Mode MUST support the following TLS ciphersuites defined 292 in [RFC4346]: 294 TLS_DH_anon_WITH_AES_128_CBC_SHA 296 Anonymous cipher suites SHOULD NOT be allowed outside of EAP-FAST 297 Server-Unauthenticated Provisioning Mode. Any cipher suites that are 298 used for Server-Unauthenticated Provisioning Mode MUST provide key 299 agreement contributed by both parties. Therefore, cipher suites 300 based on RSA key transport MUST NOT be used for this mode. Cipher 301 suites that are used for provisioning MUST provide encryption. 303 3.2. Phase 2 - Tunneled Authentication and Provisioning 305 Once a protected tunnel is established and the server is 306 unauthenticated, the peer and server MUST execute additional 307 authentication and perform integrity checks of the TLS tunnel. Even 308 if both parties are authenticated during TLS tunnel establishment the 309 peer and server MAY wish to perform additional authentication within 310 the tunnel. As defined in [RFC4851] the authentication exchange will 311 be followed by an Intermediate-Result TLV and a Crypto-Binding TLV if 312 the EAP method succeeded. The Crypto-Binding TLV provides a check on 313 the integrity of the tunnel with respect to the endpoints of the EAP 314 method. If the preceding is successful than a provisioning exchange 315 MAY take place. The provisioning exchange will use a PAC TLV 316 exchange if a PAC is being provisioned and a Server-Trusted-Root TLV 317 if a trusted root certificate is being provisioned. The provisioning 318 MAY be solicited by the peer or it MAY be unsolicited. The PAC TLV 319 exchange consists of the server distributing the PAC in a 320 corresponding PAC TLV to the peer and the peer confirming its receipt 321 in a final PAC TLV Acknowledgement message. The peer may also use 322 the PAC TLV to request that the server send a PAC. The provision 323 TLVs MAY be piggybacked on the Result TLV, following the Result TLV. 324 Many implementations process TLVs in the order they are received, 325 thus, for proper provisioning to occur, the Result TLV MUST precede 326 the TLVs to be provisioned (e.g. Tunnel PAC, Machine Authentication 327 PAC and User Authorization PAC). A PAC TLV MUST NOT be accepted if 328 it is not encapsulated in an encrypted TLS tunnel. 330 A fresh PAC MAY be distributed if the server detects that the PAC is 331 expiring soon. In-band PAC refreshing is through the PAC TLV 332 mechanism. The decision to refresh or not to refresh the PAC is 333 determined by the server. Based on the PAC-Opaque information, the 334 server MAY determine not to refresh a peer's PAC even if the PAC-Key 335 has expired. 337 3.2.1. Server-Authenticated Tunneled Authentication 339 If Server-Authenticated Provisioning Mode is in use then any EAP 340 method may be used within the TLS tunnel to authenticate the peer 341 that is allowed by the peer's policy. 343 3.2.2. Server-Unauthenticated Tunneled Authentication 345 If Server-Unauthenticated Provisioning Mode is in use then peer 346 authenticates the server and the server authenticates the peer within 347 the tunnel. The only method for performing authentication defined in 348 this version of EAP-FAST is EAP-MSCHAPv2 [EAP-MSCHAPv2] in a special 349 way as described in the following section. It is possible for other 350 methods to be defined to perform this authentication in the future. 352 3.2.3. Authenticating Using EAP-MSCHAPv2 354 Implementations of this version of the EAP-FAST Server- 355 Unauthenticated Provisioning Mode MUST support EAP-MSCHAPv2 356 [EAP-MSCHAPv2] as the inner authentication method. While other 357 authentication methods exist, EAP-MSCHAPv2 was chosen for several 358 reasons: 360 o Provide the ability of slowing an active attack by using a hash 361 based challenge-response protocol. 363 o The use of a challenge response protocol such as MSCHAPv2 provides 364 some ability to detect a man-in-the-middle attack during Server- 365 Unauthenticated Provisioning Mode. 367 o A large deployed base is already able to support MSCHAPv2. 369 o It allows support for password change during the EAP-FAST 370 provisioning modes. 372 When using an anonymous Diffie-Hellman key agreement and EAP- 373 MSCHAPv2, the challenges MUST be generated as defined in Section 3.3. 374 This forms a binding between the tunnel and the EAP-MSCHAPv2 375 exchanges by using keying material generated during the EAP-FAST 376 tunnel establishment as the EAP-MSCHAPv2 challenges instead of using 377 the challenges exchanged within the protocol itself. When EAP- 378 MSCHAPv2 is used within tunnel established using a cipher suite other 379 than one that provides anonymous key agreement the randomly generated 380 MSCHAPv2 challenges MUST be used. 382 The MSCHAPv2 [RFC2759] exchange forces the server to provide a valid 383 ServerChallengeResponse which must be a function of the server 384 challenge, peer challenge and password as part of its response. This 385 reduces the window of vulnerability of a man-in-the-middle spoofing 386 the server, by requiring the attacker to successfully break the 387 password within the peer's challenge response time limit. 389 3.2.4. Use of other Inner EAP Methods for EAP-FAST Provisioning 391 Once a protected tunnel is established, typically the peer 392 authenticates itself to the server before the server can provision 393 the peer. If the authentication mechanism does not support mutual 394 authentication and protection from man-in-the-middle attacks then 395 Server-Authenticated Provisioning Mode MUST be used. Within a server 396 side authenticated tunnel authentication mechanisms such as EAP-GTC 397 [I-D.zhou-emu-fast-gtc] MAY be used. This will enable peers using 398 other authentication mechanisms such as password database and one- 399 time passwords to be provisioned in-band as well. This version of 400 the EAP-FAST provisioning mode implementation MUST support both EAP- 401 GTC and EAP-MSCHAPv2 within the tunnel in Server-Authenticated 402 Provisioning Mode. 404 It should be noted that Server-Authenticated Provisioning Mode 405 provides significant security advantages over Server-Unauthenticated 406 Provisioning Mode even when EAP-MSCHAPv2 is being used as the inner 407 method. It protects the EAP-MSCHAPv2 exchanges from potential active 408 MitM attacks by verifying server's authenticity before exchanging 409 MSCHAPv2. Server-Authenticated Provisioning Mode is the recommended 410 provisioning mode. The EAP-FAST peer MUST use the Server- 411 Authenticated Provisioning Mode whenever it is configured with valid 412 trust root for a particular server. 414 3.3. Key Derivations Used in the EAP-FAST Provisioning Exchange 416 The TLS tunnel key is calculated according to the TLS version with an 417 extra 72 octets of key material derived from the end of the 418 key_block. Portions of the extra 72 octets are used for the EAP-FAST 419 provisioning exchange session key seed and as the random challenges 420 in the EAP-MSCHAPv2 exchange. 422 To generate the key material, compute 424 key_block = PRF(master_secret, 425 "key expansion", 426 server_random + 427 client_random); 429 until enough output has been generated. 431 For example, the key_block for TLS 1.0 [RFC2246] is partitioned as 432 follows: 434 client_write_MAC_secret[hash_size] 435 server_write_MAC_secret[hash_size] 436 client_write_key[Key_material_length] 437 server_write_key[key_material_length] 438 client_write_IV[IV_size] 439 server_write_IV[IV_size] 440 session_key_seed[40] 441 ServerChallenge[16] 442 ClientChallenge[16] 444 and the key_block for TLS 1.1 [RFC4346] is partitioned as follows: 446 client_write_MAC_secret[hash_size] 447 server_write_MAC_secret[hash_size] 448 client_write_key[Key_material_length] 449 server_write_key[key_material_length] 450 session_key_seed[40] 451 ServerChallenge[16] 452 ClientChallenge[16] 454 The extra key material, session_key_seed is used for the EAP-FAST 455 Crypto-Binding TLV exchange while the ServerChallenge and 456 ClientChallenge correspond to the authentication server's MSCHAPv2 457 challenge and the peer's MSCHAPv2 challenge respectively. The 458 ServerChallenge and ClientChallenge are only used for the MSCHAPv2 459 exchange when Diffie-Hellman anonymous key agreement is used in the 460 EAP-FAST tunnel establishment. 462 3.4. Peer-Id, Server-Id and Session-Id 464 The provisioning modes of EAP-FAST does not change the general EAP- 465 FAST protocol and thus how the Peer-Id, Server-Id and Session-Id are 466 determined is based on the [RFC4851] techniques. 468 [RFC4851] Section 3.4 describes how the Peer-Id and Server-Id are 469 determined; Section 3.5 describes how the Session-Id is generated. 471 3.5. Network Access after EAP-FAST Provisioning 473 After successful provisioning, network access MAY be granted or 474 denied depending upon server policy. For example, in the Server- 475 Authenticated Provisioning Mode, access can be granted after the EAP 476 server has authenticated the peer and provisioned the peer with a 477 Tunnel PAC (i.e. a PAC used to mutually authenticate and establish 478 the EAP-FAST tunnel). Additionally, peer policy MAY instruct the 479 peer to disconnect the current provisioning connection and initiate a 480 new EAP-FAST exchange for authentication utilizing the newly 481 provisioned information. At the end of the Server-Unauthenticated 482 Provisioning Mode, network access SHOULD NOT be granted as this 483 conversation is intended for provisioning only and thus no network 484 access is authorized. The server MAY grant access at the end of a 485 successful Server-Authenticated provisioning exchange. 487 If after successful provisioning access to the network is denied, the 488 EAP Server SHOULD conclude with an EAP Failure. The EAP Server SHALL 489 NOT grant network access or distribute any session keys to the NAS if 490 this exchange is not intended to provide network access. Even though 491 provisioning mode completes with a successful inner termination (e.g. 492 successful Result TLV), server policy defines whether the peer gains 493 network access or not. Thus, it is feasible for the server, while 494 providing a successful Result TLV may conclude that its 495 authentication policy was not satisfied and terminate the 496 conversation with an EAP Failure. 498 Denying network access after EAP-FAST Provisioning may cause 499 disruption in scenarios such as wireless devices (e.g. in IEEE 802.11 500 devices, an EAP Failure may trigger a full 802.11 disassociation). 501 While a full EAP restart can be performed, a smooth transition to the 502 subsequent EAP-FAST authentications to enable network access can be 503 achieved by the peer or server initiating TLS renegotiation, where 504 the newly provisioned credentials can be used to establish a server 505 authenticated or mutually authenticated TLS tunnel for 506 authentication. Either the peer or server may reject the request for 507 TLS renegotiation. Upon completion of the TLS negotiation and 508 subsequent authentication, normal network access policy on EAP-FAST 509 authentication can be applied. 511 4. Information Provisioned in EAP-FAST 513 Multiple types of credentials MAY be provisioned within EAP-FAST. 514 The most common credential is the Tunnel PAC that is used to 515 establish the EAP-FAST phase 1 tunnel. In addition to the Tunnel 516 PAC, other types of credentials and information can also be 517 provisioned through EAP-FAST. They may include trusted root 518 certificates, PACs for specific purposes, and user identities to name 519 a few. Typically, provisioning is invoked after both peer and server 520 authenticate each other and after a successful Crypto-Binding TLV 521 exchange. However, depending on the information being provisioned, 522 mutual authentication MAY not be needed. 524 At minimum, either the peer or server must prove authenticity before 525 credentials are provisioned to ensure that information is not freely 526 provisioned to or by adversaries. For example, the EAP server may 527 not need to authenticate the peer to provision the peer with trusted 528 root certificates. However, the peer SHOULD authenticate the server 529 before it can accept a trusted server root certificate. 531 4.1. Protected Access Credential 533 A Protected Access Credential (PAC) is a security credential 534 generated by the server that holds information specific to a peer. 535 The server distributes all PAC information through the use of a PAC 536 TLV. Different types of PAC information are identified through the 537 PAC Type and other PAC attributes defined in this section. This 538 document defines three types of PACs: a Tunnel PAC, a Machine 539 Authentication PAC and a User Authorization PAC. 541 4.1.1. Tunnel PAC 543 The server distributes the Tunnel PAC to the peer, which uses it in 544 subsequent attempts to establish a secure EAP-FAST TLS tunnel with 545 the server. The Tunnel PAC includes a secret key (PAC-Key), data 546 that is opaque to the peer (PAC-Opaque) and other information (PAC- 547 Info) which the peer can interpret. The opaque data is generated by 548 the server and cryptographically protected so it cannot be modified 549 or interpreted by the peer. The Tunnel PAC conveys the server policy 550 of what must and can occur in the protected phase 2 tunnel. It is up 551 to the server policy to include what is necessary in a PAC-Opaque to 552 enforce the policy in subsequent TLS handshakes. For example, user 553 identity, I-ID, can be included as the part of the server policy. 554 This I-ID information limits the inner EAP methods to be carried only 555 on the specified user identity. Other types of information can also 556 be included, such as which EAP method(s) and which TLS ciphersuites 557 are allowed. If the server policy is not included in a PAC-Opaque, 558 then there is no limitation imposed by the PAC on the usage of the 559 inner EAP methods or user identities inside the tunnel established by 560 the use of that PAC. 562 4.1.2. Machine Authentication PAC 564 The Machine Authentication PAC contains information in the PAC-Opaque 565 that identifies the machine. It is meant to be used by a machine 566 when network access is required and no user is logged in. Typically 567 a server will only grant the minimal amount of access required for a 568 machine without a user present based on the Machine Authentication 569 PAC. The Machine Authentication PAC MAY be provisioned during the 570 authentication of a user. It SHOULD be stored by the peer in a 571 location that is only accessible to the machine. This type of PAC 572 typically persists across sessions. 574 The peer can use the Machine Authentication PAC as the Tunnel PAC to 575 establish the TLS tunnel. The EAP server MAY have a policy to bypass 576 additional inner EAP method and grant limited network access based on 577 information in the Machine Authentication PAC. Server MAY request 578 additional exchanges to validate machine's other authorization 579 criteria, such as posture information etc., before granting network 580 access. 582 4.1.3. User Authorization PAC 584 The User Authorization PAC contains information in the PAC opaque 585 that identifies a user and provides authorization information. This 586 type of PAC does not contain a PAC-Key. It is presented within the 587 protected EAP-FAST TLS tunnel to provide user information during 588 stateless session resume so user authentication MAY be skipped. The 589 User Authorization PAC MAY be provisioned after user authentication. 590 It is meant to be short lived and not persisted across logon 591 sessions. The User Authorization PAC SHOULD only be available to the 592 user for which it is provisioned. The User Authorization PAC SHOULD 593 be deleted from the peer when the local authorization state of a 594 user's session changes, such as upon the user logs out. 596 Once the EAP-FAST phase 1 TLS tunnel is established the peer MAY 597 present a User Authorization PAC to the server in a PAC TLV. This is 598 sent as TLS application data, but it MAY be included in the same 599 message as the Finished Handshake message sent by the peer. The User 600 Authorization PAC MUST only be sent within the protection of an 601 encrypted tunnel to an authenticated entity. The server will decrypt 602 the PAC and evaluate the contents. If the contents are valid and the 603 server policy allows the session to be resumed based on this 604 information then the server will complete the session resumption and 605 grant access to the peer without requiring an inner authentication 606 method. This is called stateless session resume in EAP-FAST. In 607 this case the server sends the Result TLV indicating success without 608 the Crypto-Binding TLV and the peer sends back a Result TLV 609 indicating success. If the User Authorization PAC fails the server 610 validation or the server policy the server MAY either reject the 611 request or continue with performing full user authentication within 612 the tunnel. 614 4.1.4. PAC Provisioning 616 To request provisioning of a PAC, a peer sends a PAC TLV containing a 617 PAC attribute of PAC Type set to the appropriate value. For a Tunnel 618 PAC the value is '1', for a Machine Authentication PAC the value is 619 '2' and for a User Authorization PAC the value is '3'. The request 620 MAY be issued after the peer has determined that it has successfully 621 authenticated the EAP Server and validated the Crypto-Binding TLV to 622 ensure that the TLS tunnel's integrity is intact. Since anonymous DH 623 ciphersuites are only allowed for provisioning a Tunnel PAC, if an 624 anonymous ciphersuite is negotiated the Tunnel PAC MAY be provisioned 625 automatically by the server. The peer MUST send separate PAC TLVs 626 for each type of PAC they want to provision. Multiple PAC TLVs can 627 be sent in the same packet or different packets. When requesting the 628 Machine Authentication PAC the peer SHOULD include an I-ID TLV 629 containing the machine name prefixed by "host/". The EAP server will 630 send the PACs after its internal policy has been satisfied; or it MAY 631 ignore the request or request additional authentications if its 632 policy dictates. If a peer receives a PAC with unknown type, it MUST 633 ignore it. 635 A PAC-TLV containing PAC-Acknowledge Attribute MUST be sent by peer 636 to acknowledge the receipt of the Tunnel PAC. PAC-Acknowledge TLV 637 MUST NOT be used from peer to acknowledge the receipt of other types 638 of PACs. 640 Please see Appendix A.1 for an example of packet exchanges to 641 provision a Tunnel PAC. 643 4.2. PAC TLV Format 645 The PAC TLV provides support for provisioning the Protected Access 646 Credential (PAC) defined within [RFC4851]. The PAC TLV carries the 647 PAC and related information within PAC attribute fields. 648 Additionally, the PAC TLV MAY be used by the peer to request 649 provisioning of a PAC of the type specified in the PAC Type PAC 650 Attribute. The PAC TLV MUST only be used in a protected tunnel 651 providing encryption and integrity protection. A general PAC TLV 652 format is defined as follows: 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 |M|R| TLV Type | Length | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | PAC Attributes... 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 M 664 0 - Non-mandatory TLV 665 1 - Mandatory TLV 667 R 669 Reserved, set to zero (0) 671 TLV Type 673 11 - PAC TLV 675 Length 677 Two octets containing length of the PAC Attributes field in 678 octets 680 PAC Attributes 682 A list of PAC attributes in the TLV format 684 4.2.1. Formats for PAC Attributes 686 Each PAC Attribute in a PAC TLV is formatted as a TLV defined as 687 follows: 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Type | Length | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Value... 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Type 698 The type field is two octets, denoting the attribute type 699 Allocated Types include: 701 1 - PAC-Key 702 2 - PAC-Opaque 703 3 - PAC-Lifetime 704 4 - A-ID 705 5 - I-ID 706 6 - Reserved 707 7 - A-ID-Info 708 8 - PAC-Acknowledgement 709 9 - PAC-Info 710 10 - PAC-Type 712 Length 714 Two octets containing the length of the value field in 715 octets. 717 Value 719 The value of the PAC Attribute 721 4.2.2. PAC-Key 723 The PAC-Key is a secret key distributed in a PAC attribute of type 724 PAC-Key. The PAC-Key attribute is included within the PAC TLV 725 whenever the server wishes to issue or renew a PAC that is bound to a 726 key such as a Tunnel PAC. The key is a randomly generated octet 727 string 32 octets in length. The key is represented as an octet 728 string. The generator of this key is the issuer of the credential, 729 identified by the A-ID. 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Type | Length | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | | 737 ~ Key ~ 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Type 742 1 - PAC-Key 744 Length 746 2 octet length indicating a 32 octet long key 748 Key 750 The value of the PAC-key 752 4.2.3. PAC-Opaque 754 The PAC-Opaque attribute is included within the PAC TLV whenever the 755 server wishes to issue or renew a PAC. 757 The PAC-Opaque is opaque to the peer and thus the peer MUST NOT 758 attempt to interpret it. A peer that has been issued a PAC-Opaque by 759 a server stores that data, and presents it back to the server 760 according to its PAC Type. The Tunnel PAC is used in the ClientHello 761 SessionTicket extension field defined in [RFC5077]. If a peer has 762 opaque data issued to it by multiple servers, then it stores the data 763 issued by each server separately according to A-ID. This requirement 764 allows the peer to maintain and use each opaque data as an 765 independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque 766 identified by the A-ID. As there is a one to one correspondence 767 between PAC-Key and PAC-Opaque, the peer determines the PAC-Key and 768 corresponding PAC-Opaque based on the A-ID provided in the EAP-FAST/ 769 Start message and the A-ID provided in the PAC-Info when it was 770 provisioned with a PAC-Opaque. 772 The PAC-Opaque attribute format is summarized as follows: 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type | Length | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Value ... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Type 783 2 - PAC-Opaque 785 Length 787 The Length filed is two octets, which contains the length of 788 the value field in octets 790 Value 792 The value field contains the actual data for PAC-Opaque. It is 793 specific to the server implementation. 795 4.2.4. PAC-Info 797 PAC-Info is comprised of a set of PAC attributes as defined in 798 Section 4.2.1. The PAC-Info attribute MUST contain the A-ID, A-ID- 799 Info, and PAC-Type attributes. Other attributes MAY be included in 800 the PAC-Info to provide more information to the peer. The PAC-Info 801 attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC-Info 802 or PAC-Opaque attributes. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Length | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Attributes... 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Type 814 9 - PAC-Info 816 Length 818 Two octet length field containing the length of the Attributes 819 field in octets 821 Attributes 823 The Attributes field contains a list of PAC Attributes Each 824 mandatory and optional field type is defined as follows: 826 3 - PAC-LIFETIME 828 This is a 4 octet quantity representing the expiration time 829 of the credential expressed as the number of seconds, 830 excluding leap seconds, after midnight UTC, January 1, 1970. 831 This attribute MAY be provided to the peer as part of PAC- 832 Info. 834 4 - A-ID 836 A-ID is the identity of the authority that issued the PAC. 837 The A-ID is intended to be unique across all issuing servers 838 to avoid namespace collisions. The A-ID is used by the peer 839 to determine which PAC to employ. The A-ID is treated as an 840 opaque octet string. This attribute MUST be included in the 841 PAC-Info attribute. The A-ID MUST match the A-ID the server 842 used to establish the tunnel. Since many existing 843 implementations expect the A-ID to be 16 octets in length, 844 it is RECOMMENDED that length of an A-ID be 16 octets for 845 maximum interoperability. One method for generating the 846 A-ID is to use a high quality random number generator to 847 generate a 16-octet random number. An alternate method 848 would be to take the hash of the public key or public key 849 certificate belonging a server represented by the A-ID. 851 5 - I-ID 853 Initiator identifier (I-ID) is the peer identity associated 854 with the credential. This identity is derived from the 855 inner EAP exchange or from the client side authentication 856 during tunnel establishment if inner EAP method 857 authentication is not used. The server employs the I-ID in 858 the EAP-FAST Phase 2 conversation to validate that the same 859 peer identity used to execute EAP-FAST Phase 1 is also used 860 in at minimum one inner EAP method in EAP-FAST Phase 2. If 861 the server is enforcing the I-ID validation on inner EAP 862 method, then I-ID MUST be included in PAC-Info, to enable 863 the peer to also enforce a unique PAC for each unique user. 864 If I-ID is missing from the PAC-Info, it is assumed that the 865 Tunnel PAC can be used for multiple users and peer will not 866 enforce the unique Tunnel PAC per user policy. 868 7 - A-ID-Info 870 Authority Identifier Information is intended to provide a 871 user-friendly name for the A-ID. It may contain the 872 enterprise name and server name in a human-readable format. 873 This TLV serves as an aid to the peer to better inform the 874 end-user about the A-ID. The name is encoded as UTF-8 875 [RFC3629] format. This attribute MUST be included in the 876 PAC-Info. 878 10 - PAC-type 880 PAC-Type is intended to provide the type of PAC. This 881 attribute SHOULD be included in the PAC-Info. If PAC-Type 882 is not present, then it defaults to a Tunnel PAC (Type 1). 884 4.2.5. PAC-Acknowledgement TLV 886 The PAC-Acknowledgement is used to acknowledge the receipt of the 887 Tunnel PAC by the peer. The peer includes the PAC-Acknowledgement 888 TLV in a PAC-TLV sent to the server to indicate the result of the 889 processing and storing of a newly provisioned Tunnel PAC. This TLV 890 is only used when Tunnel PAC is provisioned. 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Type | Length | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Result | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Type 902 8 - PAC-Acknowledgement 904 Length 906 The length of this field is two octets containing a value of 2. 908 Result 910 The resulting value MUST be one of the following: 912 1 - Success 913 2 - Failure 915 4.2.6. PAC-Type TLV 917 The PAC-Type TLV is a TLV intended to specify the PAC type. It is 918 included in a PAC-TLV sent by the peer to request PAC provisioning 919 from the server. Its format is described below. 921 0 1 2 3 922 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Type | Length | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | PAC Type | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 Type 931 10 - PAC-Type 933 Length 935 Two Octet length field with a value of 2 937 PAC Type 939 This two octet field defined the type of PAC being requested or 940 provisioned. The following values are defined: 942 1 - Tunnel PAC 943 2 - Machine Authentication PAC 944 3 - User Authorization PAC 946 4.3. Trusted Server Root Certificate 948 Server-Trusted-Root TLV facilitates the request and delivery of a 949 trusted server root certificate. The Server-Trusted-Root TLV can be 950 exchanged in regular EAP-FAST Authentication mode or Provisioning 951 mode. The Server-Trusted-Root TLV is always marked as optional, and 952 cannot be responded to with a NAK TLV. The Server-Trusted-Root TLV 953 MUST only be sent as an inner TLV (inside the protection of the 954 tunnel). 956 After the peer has determined that it has successfully authenticated 957 the EAP server and validated the Crypto-Binding TLV, it MAY send one 958 or more Server-Trusted-Root TLVs (marked as optional) to request the 959 trusted server root certificates from from the EAP server. The EAP 960 server MAY send one or more root certificates with a PKCS#7 TLV 961 inside Server-Trusted-Root TLV. The EAP server MAY also choose not 962 to honor the request. Please see Section Appendix A.3 for an example 963 of a server provisioning a server trusted root certificate. 965 4.3.1. Server-Trusted-Root TLV 967 The Server-Trusted-Root TLV allows the peer to send a request to the 968 EAP server for a list of trusted roots. The server may respond with 969 one or more root certificates in PKCS#7 [RFC2315] format. 971 If the EAP server sets credential format to PKCS#7-Server- 972 Certificate-Root, then the Server-Trusted-Root TLV should contain the 973 root of the certificate chain of the certificate issued to the EAP 974 server packaged in a PKCS#7 TLV. If the Server certificate is a 975 self-signed certificate, then the root is the self-signed 976 certificate. 978 If the Server-Trusted-Root TLV credential format contains a value 979 unknown to the peer, then the EAP peer should ignore the TLV. 981 The Server-Trusted-Root TLV is defined as follows: 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 |M|R| TLV Type | Length | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Credential-Format | Cred TLVs... 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 991 M 993 0 - Non-mandatory TLV 995 R 997 Reserved, set to zero (0) 999 TLV Type 1001 18 - Server-Trusted-Root TLV [RFC4851] 1003 Length 1005 >=2 octets 1007 Credential-Format 1009 The Credential-Format field is two octets. Values include: 1011 1 - PKCS#7-Server-Certificate-Root 1013 Cred TLVs 1015 This field is of indefinite length. It contains TLVs 1016 associated with the credential format. The peer may leave 1017 this field empty when using this TLV to request server 1018 trust roots. 1020 4.3.2. PKCS#7 TLV 1022 The PKCS#7 TLV is sent by the EAP server to the peer inside the 1023 Server-Trusted-Root TLV. It contains PKCS #7 [RFC2315] wrapped X.509 1024 certificates. The format consists of a certificate or certificate 1025 chain in a Certificates-Only PKCS#7 SignedData message as defined in 1026 [RFC2311]. 1028 The PKCS#7 TLV is always marked as optional, which cannot be 1029 responded to with a NAK TLV. EAP-FAST server implementations that 1030 claim to support the dynamic provisioning defined in this document 1031 SHOULD support this TLV. EAP-FAST peer implementations MAY support 1032 this TLV. 1034 If the PKCS#7 TLV contains a certificate or certificate chain that is 1035 not acceptable to the peer, then peer MUST ignore the TLV. 1037 The PKCS#7 TLV is defined as follows: 1039 0 1 2 3 1040 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 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 |M|R| TLV Type | Length | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | PKCS #7 Data... 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1047 M 1049 0 - Optional TLV 1051 R 1053 Reserved, set to zero (0) 1055 TLV Type 1057 20 - PKCS#7 TLV [RFC4851] 1059 Length 1061 The length of the PKCS #7 Data field 1063 PKCS #7 Data 1065 This field contains the X.509 certificate or certificate chain 1066 in a Certificates-Only PKCS#7 SignedData message. 1068 5. IANA Considerations 1070 This section explains the criteria to be used by the IANA for 1071 assignment of Type value in PAC attribute, PAC Type value in PAC- 1072 Type TLV, Credential-Format value in Server-Trusted-Root TLV. The 1073 "Specification Required" policy is used here with the meaning defined 1074 in BCP 26 [RFC5226]. 1076 A registry of values, named "EAP-FAST PAC Attribute Types", is needed 1077 for the PAC Attribute types. The initial values to populate the 1078 registry are: 1080 1 - PAC-Key 1081 2 - PAC-Opaque 1082 3 - PAC-Lifetime 1083 4 - A-ID 1084 5 - I-ID 1085 6 - Reserved 1086 7 - A-ID-Info 1087 8 - PAC-Acknowledgement 1088 9 - PAC-Info 1089 10 - PAC-Type 1091 Values from 11 to 63 are allocated for management by Cisco. Values 1092 64 to 255 are assigned with a "Specification Required" policy. 1094 A registry of values, named "EAP-FAST PAC Types", is needed for PAC- 1095 Type values used in the PAC-Type TLV. The initial values to populate 1096 the registry are: 1098 1 - Tunnel PAC 1099 2 - Machine Authentication PAC 1100 3 - User Authorization PAC 1102 Values from 4 to 63 are allocated for management by Cisco. Values 64 1103 to 255 are assigned with a "Specification Required" policy. 1105 A registry of values, named "EAP-FAST Server-Trusted-Root Credential 1106 Format Types", is needed for Credential-Format values used in Server- 1107 Trusted-Root TLV. The initial values to populate the registry are: 1109 1 - PKCS#7-Server-Certificate-Root 1111 Values from 2 to 63 are allocated for management by Cisco. Values 64 1112 to 255 are assigned with a "Specification Required" policy. 1114 6. Security Considerations 1116 The Dynamic Provisioning EAP-FAST protocol shares the same security 1117 considerations outlined in [RFC4851]. Additionally, it also has its 1118 unique security considerations described below: 1120 6.1. Provisioning Modes and Man-in-the-middle Attacks 1122 EAP-FAST can be invoked in two different provisioning modes: Server- 1123 Authenticated Provisioning Mode and Server-Unauthenticated 1124 Provisioning Mode. Each mode provides different levels of resistance 1125 to man-in-the-middle attacks. The following list identifies some of 1126 the problems associated with a man-in-the-middle attack: 1128 o Disclosure of secret information such as keys, identities and 1129 credentials to an attacker 1131 o Spoofing of a valid server to a peer and the distribution of false 1132 credentials 1134 o Spoofing of a valid peer and receiving credentials generated for 1135 that peer 1137 o Denial of service 1139 6.1.1. Server-Authenticated Provisioning Mode and Man-in-the-middle 1140 Attacks 1142 In Server-Authenticated Provisioning Mode the TLS handshake assures 1143 protected communications with the server because the peer must have 1144 been securely pre-provisioned with the trust roots and/or other 1145 authentication information necessary to authenticate the server 1146 during the handshake. This pre-provisioning step prevents an 1147 attacker from inserting themselves as a man-in-the-middle of the 1148 communications. Unfortunately, secure pre-provisioning can be 1149 difficult to achieve in many environments. 1151 Cryptographic binding of inner authentication mechanisms to the TLS 1152 tunnel provides additional protection from man-in-the-middle attacks 1153 resulting from the tunneling of authentication mechanisms. 1155 Server-Authenticated Provisioning Mode provides a high degree of 1156 protection from man-in-the-middle attacks. 1158 6.1.2. Server-Unauthenticated Provisioning Mode and Man-in-the-middle 1159 Attacks 1161 In Server-Unauthenticated Provisioning Mode the TLS handshake does 1162 not assure protected communications with the server because either an 1163 anonymous handshake is negotiated or the peer lacks the necessary 1164 information to complete the authentication of the server. This 1165 allows an attacker to insert themselves in the middle of the TLS 1166 communications. 1168 EAP-FAST Server-Unauthenticated Provisioning Mode mitigates the man- 1169 in-the-middle attack through the following techniques: 1171 o Binding the phase 2 authentication method to secret values derived 1172 from the phase 1 TLS exchange: 1174 In the case of MSCHAPv2 used with an anonymous Diffie-Hellman 1175 ciphersuite the challenges for the MSCHAPv2 exchange are derived 1176 from the TLS handshake and are not transmitted within the MSCHAPv2 1177 exchange. Since the man-in-the-middle does not know these 1178 challenges it cannot successfully impersonate the server without 1179 cracking the MSCHAPv2 message from the peer before the peer times 1180 out. 1182 o Cryptographic binding of secret values derived from the phase 2 1183 authentication exchange with secret values derived from the phase 1184 1 TLS exchange: 1186 This makes use of the cryptographic binding exchange defined 1187 within EAP-FAST to discover the presence of a man-in-the-middle by 1188 binding secret information obtained from the phase 2 MSCHAPv2 1189 exchange with secret information from the phase 1 TLS exchange. 1191 While it would be sufficient to only support the cryptographic 1192 binding to mitigate the MitM; the binding of the MSCHAPv2 random 1193 challenge derivations to the TLS key agreement protocol enables early 1194 detection of a man-in-the-middle attack. This guards against 1195 adversaries who may otherwise relay the inner EAP authentication 1196 messages between the true peer and server and enforces that the 1197 adversary successfully respond with a valid challenge response. 1199 The cipher suite used to establish phase 1 of the Server- 1200 Unauthenticated provisioning mode MUST be one in which both the peer 1201 and server provide contribution to the derived TLS master key. 1202 Cipher suites that use RSA key transport do not meet this 1203 requirement. The authenticated and anonymous ephemeral Diffie- 1204 Hellman cipher suites provide this type of key agreement. 1206 This document specifies MSCHAPv2 as the inner authentication 1207 exchange, however it is possible that other inner authentications 1208 mechanisms to authenticate the tunnel may be developed in the future. 1209 Since the strength of the man-in-the-middle protection is directly 1210 dependent on the strength of the inner method it is RECOMMENDED that 1211 any inner method used provide at least as much resistance to attack 1212 as MSCHAPv2. Cleartext passwords MUST NOT be used in Server- 1213 Unauthenticated Provisioning Mode. Note that an active man-in-the- 1214 middle may observe phase 2 authentication method exchange until the 1215 point that the peer determines that authentication mechanism fails or 1216 is aborted. This allows for the disclosure of sensitive information 1217 such as identity or authentication protocol exchanges to the man-in- 1218 the-middle. 1220 6.2. Dictionary Attacks 1222 It is often the case that phase 2 authentication mechanisms are based 1223 on password credentials. These exchanges may be vulnerable to both 1224 online and offline dictionary attacks. The two provisioning modes 1225 provide various degrees of protection from these attacks. 1227 In online dictionary attacks the attacker attempts to discover the 1228 password by repeated attempts at authentication using a guessed 1229 password. Neither mode prevents this type of attack by itself. 1230 Implementations should provide controls that limit how often an 1231 attacker can execute authentication attempts. 1233 In offline dictionary attacks the attacker captures information which 1234 can be processed offline to recover the password. Server- 1235 Authenticated provisioning mode provides effecting mitigation because 1236 the peer will not engage in phase 2 authentication without first 1237 authenticating the server during phase 1. Server-Unauthenticated 1238 Provisioning Mode is vulnerable to this type of attack. If, during 1239 phase 2 authentication, a peer receives no response or an invalid 1240 response from the server then there is a possibility there is a man- 1241 in-the-middle attack in progress. Implementations SHOULD logs these 1242 events and, if possible, provide warnings to the user. 1243 Implementations are also encouraged to provide controls that limit 1244 how and where Server-Unauthenticated Provisioning Mode can be 1245 performed that are appropriate to their environment. For example, an 1246 implementation may limit this mode to be used only on certain 1247 interfaces or require user intervention before allowing this mode if 1248 provisioning has succeeded in the past. 1250 Another mitigation technique that should not be overlooked is the 1251 choice of good passwords that have sufficient complexity and length 1252 and a password changing policy that requires regular password 1253 changes. 1255 6.3. Considerations in Selecting a Provisioning Mode 1257 Since Server-Authenticated Provisioning Mode provides much better 1258 protection from attacks than Server-Unauthenticated Provisioning 1259 Mode, Server-Authenticated Provisioning Mode SHOULD be used whenever 1260 possible. The Server-Unauthenticated Provisioning Mode provides a 1261 viable option as there may be deployments that can physically confine 1262 devices during the provisioning or are willing to accept the risk of 1263 an active dictionary attack. Further, it is the only option that 1264 enables zero touch provisioning and facilitates simpler deployments 1265 requiring little to no peer configuration. The peer MAY choose to 1266 use alternative secure out-of-band mechanisms for PAC provisioning 1267 that afford better security than the Server Unauthenticated 1268 Provisioning Mode. 1270 6.4. Diffie-Hellman Groups 1272 To encourage interoperability implementations of EAP-FAST anonymous 1273 provisioning modes MUST support the 2048-bit group "14" in [RFC3526]. 1275 6.5. Tunnel PAC Usage 1277 The basic usage of the Tunnel PAC is to establish the TLS tunnel. In 1278 this operation it does not have to provide user authentication as it 1279 is expected for user authentication to be carried out in phase 2 of 1280 EAP-FAST. The EAP-FAST Tunnel PAC MAY contain information about the 1281 identity of a peer to prevent a particular Tunnel PAC from being used 1282 to establish a tunnel which can perform phase 2 authenticate other 1283 peers. While it is possible for the server to accept the Tunnel PAC 1284 as authentication for the peer many current implementations do not do 1285 this. The ability to use PAC to authenticate peers and provide 1286 authorizations will be the subject of a future document. [RFC5077] 1287 gives an example PAC-Opaque format in the Recommended Ticket 1288 Construction section. 1290 6.6. Machine Authentication PAC Usage 1292 In general the Machine Authorization PAC is expected to provide the 1293 minimum access required by a machine without a user. This will 1294 typically be a subset of the privilege a registered user has. The 1295 server provisioning the PAC should include information necessary to 1296 validate it at a later point in time. This would include expiration 1297 information. The Machine Authentication PAC includes a key so it can 1298 be used as a Tunnel PAC. The PAC-Key MUST be kept secret by the 1299 peer. 1301 6.7. User Authorization PAC Usage 1303 The User Authorization PAC provides the privilege associated with a 1304 user. The server provisioning the PAC should include the information 1305 necessary to validate it at a later point in time. This includes 1306 expiration and other information associated with the PAC. The User 1307 Authorization PAC is a bearer credential such that it does not have a 1308 key that used to authenticate its ownership. For this reason this 1309 type of PAC MUST NOT be sent in the clear. For additional protection 1310 the PAC MAY be bound to a Tunnel PAC used to establish the TLS 1311 tunnel. On the peer, the User Authorization PAC SHOULD only be 1312 accessible by the user for which it is provisioned. 1314 6.8. PAC Storage Considerations 1316 The main goal of EAP-FAST is to protect the authentication stream 1317 over the media link. However, host security is still an issue. Some 1318 care should be taken to protect the PAC on both the peer and server. 1319 The peer must store securely both the PAC-Key and PAC-Opaque, while 1320 the server must secure storage of its security association context 1321 used to consume the PAC-Opaque. Additionally, if alternate 1322 provisioning is employed, the transportation mechanism used to 1323 distribute the PAC must also be secured. 1325 Most of the attacks described here would require some level of effort 1326 to execute; conceivably greater than their value. The main focus 1327 therefore, should be to ensure that proper protections are used on 1328 both the peer and server. There are a number of potential attacks 1329 which can be considered against secure key storage such as: 1331 o Weak Passphrases 1333 On the peer side, keys are usually protected by a passphrase. On 1334 some environments, this passphrase may be associated with the 1335 user's password. In either case, if an attacker can obtain the 1336 encrypted key for a range of users, he may be able to successfully 1337 attack a weak passphrase. The tools are already in place today to 1338 enable an attacker to easily attack all users in an enterprise 1339 environment through the use of email viruses and other techniques. 1341 o Key Finding Attacks 1343 Key finding attacks are usually mentioned in reference to web 1344 servers, where the private SSL key may be stored securely, but at 1345 some point it must be decrypted and stored in system memory. An 1346 attacker with access to system memory can actually find the key by 1347 identifying their mathematical properties. To date, this attack 1348 appears to be purely theoretical and primarily acts to argue 1349 strongly for secure access controls on the server itself to 1350 prevent such unauthorized code from executing. 1352 o Key duplication, Key substitution, Key modification 1354 Once keys are accessible to an attacker on either the peer or 1355 server, they fall under three forms of attack: key duplication, 1356 key substitution and key modification. The first option would be 1357 the most common, allowing the attacker to masquerade as the user 1358 in question. The second option could have some use if an attacker 1359 could implement it on the server. Alternatively, an attacker 1360 could use one of the latter two attacks on either the peer or 1361 server to force a PAC re-key, and take advantage of the potential 1362 MitM/dictionary attack vulnerability of the EAP-FAST Server- 1363 Unauthenticated Provisioning Mode. 1365 Another consideration is the use of secure mechanisms afforded by the 1366 particular device. For instance, some laptops enable secure key 1367 storage through a special chip. It would be worthwhile for 1368 implementations to explore the use of such a mechanism. 1370 6.9. Security Claims 1372 The [RFC3748] security claims for EAP-FAST are given in Section 7.8 1373 of [RFC4851]. When using anonymous provisioning mode there is a 1374 greater risk of offline dictionary attack since it is possible for a 1375 man-in-the-middle to capture the beginning of the inner MSCHAPv2 1376 conversation. However as noted previously it is possible to detect 1377 the man-in-the-middle. 1379 7. Acknowledgements 1381 The EAP-FAST design and protocol specification is based on the ideas 1382 and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith, 1383 Ilan Frenkel, Max Pritikin, Jan Vilhuber and Jeremy Steiglitz. The 1384 authors would also like to thank Jouni Malinen, Pasi Eronen, Jari 1385 Arkko, Chris Newman, Ran Canetti and Vijay Gurbani for reviewing this 1386 document. 1388 8. References 1390 8.1. Normative References 1392 [EAP-MSCHAPv2] 1393 Microsoft Developer Network (MSDN), "[MS-CHAP]: Extensible 1394 Authentication Protocol Method for Microsoft Challenge 1395 Handshake Authentication Protocol (CHAP) Specification", 1396 January 2008. 1398 http://msdn2.microsoft.com/en-us/library/cc224612.aspx 1400 [I-D.zhou-emu-fast-gtc] 1401 Cam-Winget, N. and H. Zhou, "Basic Password Exchange 1402 within the Flexible Authentication via Secure Tunneling 1403 Extensible Authentication Protocol (EAP-FAST)", 1404 draft-zhou-emu-fast-gtc-04 (work in progress), July 2008. 1406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1407 Requirement Levels", BCP 14, RFC 2119, March 1997. 1409 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1410 RFC 2246, January 1999. 1412 [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 1413 L. Repka, "S/MIME Version 2 Message Specification", 1414 RFC 2311, March 1998. 1416 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 1417 Version 1.5", RFC 2315, March 1998. 1419 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1420 RFC 2759, January 2000. 1422 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1423 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1424 RFC 3526, May 2003. 1426 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1427 10646", STD 63, RFC 3629, November 2003. 1429 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1430 Levkowetz, "Extensible Authentication Protocol (EAP)", 1431 RFC 3748, June 2004. 1433 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1434 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1436 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 1437 Flexible Authentication via Secure Tunneling Extensible 1438 Authentication Protocol Method (EAP-FAST)", RFC 4851, 1439 May 2007. 1441 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1442 "Transport Layer Security (TLS) Session Resumption without 1443 Server-Side State", RFC 5077, January 2008. 1445 8.2. Informative References 1447 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1448 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1449 May 2008. 1451 Appendix A. Examples 1453 A.1. Example 1: Successful Tunnel PAC Provisioning 1455 The following exchanges show anonymous DH with a successful EAP- 1456 MSCHAPv2 exchange within Phase 2 to provision a Tunnel PAC, the 1457 conversation will appear as follows: 1459 Authenticating Peer Authenticator 1460 ------------------- ------------- 1461 <- EAP-Request/Identity 1462 EAP-Response/ 1463 Identity (MyID1) -> 1464 <- EAP-Request/EAP-FAST, 1465 (S=1, A-ID) 1467 EAP-Response/EAP-FAST 1468 (TLS Client Hello without 1469 PAC-Opaque in SessionTicket extension)-> 1471 <- EAP-Request/EAP-FAST 1472 (TLS Server Hello, 1473 TLS Server Key Exchange 1474 TLS Server Hello Done) 1476 EAP-Response/EAP-FAST 1477 (TLS Client Key Exchange 1478 TLS Change Cipher Spec 1479 TLS Finished) -> 1481 <- EAP-Request/EAP-FAST 1482 ( TLS change_cipher_spec, 1483 TLS finished, 1484 EAP-Payload-TLV 1485 (EAP-Request/Identity)) 1487 // TLS channel established 1488 (Subsequent messages sent within the TLS channel, 1489 encapsulated within EAP-FAST) 1491 // First EAP Payload TLV is piggybacked to the TLS Finished as 1492 Application Data and protected by the TLS tunnel 1494 EAP Payload TLV 1495 (EAP-Response/Identity) -> 1497 <- EAP Payload TLV 1498 (EAP-Request/EAP-MSCHAPV2 1499 (Challenge)) 1501 EAP Payload TLV 1502 (EAP-Response/EAP-MSCHAPV2 1503 (Response)) -> 1505 <- EAP Payload TLV 1506 (EAP-Request/EAP-MSCHAPV2) 1507 (Success)) 1508 EAP Payload TLV 1509 (EAP-Response/EAP-MSCHAPV2 1510 (Success)) -> 1511 <- Intermediate Result TLV(Success) 1512 Crypto-Binding-TLV (Version=1, 1513 EAP-FAST Version=1, Nonce, 1514 CompoundMAC) 1516 Intermediate Result TLV (Success) 1517 Crypto-Binding-TLV (Version=1, 1518 EAP-FAST Version=1, Nonce, 1519 CompoundMAC) 1520 PAC-TLV (Type=1) 1521 <- Result TLV (Success) 1522 PAC TLV 1524 Result TLV (Success) 1525 PAC Acknowledgment -> 1527 TLS channel torn down 1528 (messages sent in cleartext) 1530 <- EAP-Failure 1532 A.2. Example 2: Failed Provisioning 1534 The following exchanges show a failed EAP-MSCHAPV2 exchange within 1535 Phase 2, where the peer failed to authenticate the Server. The 1536 conversation will appear as follows: 1538 Authenticating Peer Authenticator 1539 ------------------- ------------- 1540 <- EAP-Request/Identity 1541 EAP-Response/ 1542 Identity (MyID1) -> 1543 <- EAP-Request/EAP-FAST 1544 (s=1, A-ID) 1546 EAP-Response/EAP-FAST 1547 (TLS Client Hello without 1548 SessionTicket extension)-> 1550 <- EAP-Request/EAP-FAST 1551 (TLS Server Hello 1552 TLS Server Key Exchange 1553 TLS Server Hello Done) 1554 EAP-Response/EAP-FAST 1555 (TLS Client Key Exchange 1556 TLS Change Cipher Spec, 1557 TLS Finished) -> 1559 <- EAP-Request/EAP-FAST 1560 ( TLS change_cipher_spec, 1561 TLS finished, 1562 EAP-Payload-TLV 1563 (EAP-Request/Identity)) 1565 // TLS channel established 1566 (Subsequent messages sent within the TLS channel, 1567 encapsulated within EAP-FAST) 1569 // First EAP Payload TLV is piggybacked to the TLS Finished as 1570 Application Data and protected by the TLS tunnel 1572 EAP Payload TLV 1573 (EAP-Response/Identity)-> 1575 <- EAP Payload TLV 1576 (EAP-Request/EAP-MSCHAPV2 1577 (Challenge)) 1579 EAP Payload TLV 1580 (EAP-Response/EAP-MSCHAPV2 1581 (Response)) -> 1583 <- EAP Payload TLV 1584 (EAP-Request EAP-MSCHAPV2 1585 (Success)) 1587 // peer failed to verify server MSCHAPv2 response 1588 EAP Payload TLV 1589 (EAP-Response/EAP-MSCHAPV2 1590 (Failure)) -> 1592 <- Result TLV (Failure) 1594 Result TLV (Failure) -> 1595 TLS channel torn down 1596 (messages sent in cleartext) 1598 <- EAP-Failure 1600 A.3. Example 3: Provisioning a Authentication Server's Trusted Root 1601 Certificate 1603 The following exchanges show a successful provisioning of a server 1604 trusted root certificate using anonymous DH and EAP-MSCHAPV2 exchange 1605 within Phase 2, the conversation will appear as follows: 1607 Authenticating Peer Authenticator 1608 ------------------- ------------- 1609 <- EAP-Request/ 1610 Identity 1611 EAP-Response/ 1612 Identity (MyID1) -> 1613 <- EAP-Requese/EAP-FAST 1614 (s=1, A-ID) 1616 EAP-Response/EAP-FAST 1617 (TLS Client Hello without 1618 SessionTicket extension)-> 1619 <- EAP-Request/EAP-FAST 1620 (TLS Server Hello, 1621 (TLS Server Key Exchange 1622 TLS Server Hello Done) 1624 EAP-Response/EAP-FAST 1625 (TLS Client Key Exchange 1626 TLS Change Cipher Spec, 1627 TLS Finished) -> 1629 <- EAP-Request/EAP-FAST 1630 (TLS Change Cipher Spec 1631 TLS Finished) 1632 (EAP-Payload-TLV( 1633 EAP-Request/Identity)) 1635 // TLS channel established 1636 (messages sent within the TLS channel) 1638 // First EAP Payload TLV is piggybacked to the TLS Finished as 1639 Application Data and protected by the TLS tunnel 1641 EAP-Payload TLV 1642 (EAP-Response/Identity) -> 1644 <- EAP Payload TLV 1645 (EAP-Request/EAP-MSCHAPV2 1646 (Challenge)) 1648 EAP Payload TLV 1649 (EAP-Response/EAP-MSCHAPV2 1650 (Response)) -> 1652 <- EAP Payload TLV 1653 (EAP-Request/EAP-MSCHAPV2 1654 (success)) 1656 EAP Payload TLV 1657 (EAP-Response/EAP-MSCHAPV2 1658 (Success) -> 1660 <- Intermediate Result TLV(Success) 1661 Crypto-Binding TLV (Version=1, 1662 EAP-FAST Version=1, Nonce, 1663 CompoundMAC), 1665 Intermediate Result TLV(Success) 1666 Crypto-Binding TLV (Version=1 1667 EAP-FAST Version=1, Nonce, 1668 CompoundMAC) 1669 Server-Trusted-Root TLV 1670 (Type = PKCS#7) -> 1671 <- Result TLV (Success) 1672 Server-Trusted-Root TLV 1673 (PKCS#7 TLV) 1675 Result TLV (Success) -> 1677 // TLS channel torn down 1678 (messages sent in cleartext) 1680 <- EAP-Failure 1682 Appendix B. Recent Changes 1684 changes in -07 1686 o Added definition for User Authorization PAC and Machine 1687 Authentication PAC 1689 o Added sections for User Authorization PAC (4.1.3) and Machine 1690 Authentication PAC (4.1.2). 1692 o Added security considerations for new types of PACs 1694 o Added recommendation for 16 octet A-ID 1696 changes in -08 1698 o Clarified that Server-Unauthenticated provisioning mode uses 1699 anonymous TLS ciphersuites 1701 o Editorial corrections 1703 changes in -09 1705 o Added text to section 3 to provide an overview of the provisioning 1706 process 1708 changes in -10 1710 o Clarified that user authorization PAC is not associated with a 1711 key. 1713 o Removed conflicting SHOULD requirement for inner method 1714 authentication. 1716 o In section 3.1.1 change cert validation to MUST. 1718 o Clarified that RSA ciphersuites MUST NOT be used with anonymous 1719 mode. 1721 o In section 3.2 added requirement for TLV order. 1723 o Clarified that the modified MSCHAPv2 is only used for 1724 provisioning. 1726 o Fixed TLS key block derivation 1728 o In section 3.5, made TLS renegotiation the optional method for 1729 continuing authentication after provisioning 1731 o define A-ID as opaque and included recommendations for generation 1733 o defined I-ID as derived from the inner EAP method 1735 o added details to PKCS encoding of certs 1737 o updated IANA considerations section 1739 o tightened specification to require 2048 DH group 1741 Authors' Addresses 1743 Nancy Cam-Winget 1744 Cisco Systems 1745 3625 Cisco Way 1746 San Jose, CA 95134 1747 US 1749 Email: ncamwing@cisco.com 1751 David McGrew 1752 Cisco Systems 1753 San Jose, CA 95134 1754 US 1756 Email: mcgrew@cisco.com 1758 Joseph Salowey 1759 Cisco Systems 1760 2901 3rd Ave 1761 Seattle, WA 98121 1762 US 1764 Email: jsalowey@cisco.com 1766 Hao Zhou 1767 Cisco Systems 1768 4125 Highlander Parkway 1769 Richfield, OH 44286 1770 US 1772 Email: hzhou@cisco.com 1774 Full Copyright Statement 1776 Copyright (C) The IETF Trust (2008). 1778 This document is subject to the rights, licenses and restrictions 1779 contained in BCP 78, and except as set forth therein, the authors 1780 retain all their rights. 1782 This document and the information contained herein are provided on an 1783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1790 Intellectual Property 1792 The IETF takes no position regarding the validity or scope of any 1793 Intellectual Property Rights or other rights that might be claimed to 1794 pertain to the implementation or use of the technology described in 1795 this document or the extent to which any license under such rights 1796 might or might not be available; nor does it represent that it has 1797 made any independent effort to identify any such rights. Information 1798 on the procedures with respect to rights in RFC documents can be 1799 found in BCP 78 and BCP 79. 1801 Copies of IPR disclosures made to the IETF Secretariat and any 1802 assurances of licenses to be made available, or the result of an 1803 attempt made to obtain a general license or permission for the use of 1804 such proprietary rights by implementers or users of this 1805 specification can be obtained from the IETF on-line IPR repository at 1806 http://www.ietf.org/ipr. 1808 The IETF invites any interested party to bring to its attention any 1809 copyrights, patents or patent applications, or other proprietary 1810 rights that may cover technology that may be required to implement 1811 this standard. Please address the information to the IETF at 1812 ietf-ipr@ietf.org. 1814 Acknowledgment 1816 Funding for the RFC Editor function is provided by the IETF 1817 Administrative Support Activity (IASA).