idnits 2.17.1 draft-cam-winget-eap-fast-06.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 on line 2840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2851. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2864. ** 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. 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 RFC 3978 Section 5.4 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 (January 12, 2007) is 6304 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NOTE1' is mentioned on line 1439, but not defined == Missing Reference: 'Note1' is mentioned on line 1442, but not defined -- Looks like a reference, but probably isn't: '20' on line 1481 -- Looks like a reference, but probably isn't: '16' on line 1483 -- Looks like a reference, but probably isn't: '0' on line 1524 -- Looks like a reference, but probably isn't: '40' on line 1486 -- Looks like a reference, but probably isn't: '1' on line 1938 == Missing Reference: 'SIMCK 1' is mentioned on line 2752, but not defined == Missing Reference: 'Crypto-Binding TLV' is mentioned on line 2781, but not defined == Missing Reference: 'Compound MAC' is mentioned on line 2790, but not defined ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3268 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4507 (Obsoleted by RFC 5077) == Outdated reference: A later version (-10) exists of draft-cam-winget-eap-fast-provisioning-03 -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 15 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: July 16, 2007 H. Zhou 6 Cisco Systems 7 January 12, 2007 9 The Flexible Authentication via Secure Tunneling Extensible 10 Authentication Protocol Method (EAP-FAST) 11 draft-cam-winget-eap-fast-06.txt 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 July 16, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2007). 42 Abstract 44 This document defines the Extensible Authentication Protocol (EAP) 45 based Flexible Authentication via Secure Tunneling (EAP-FAST) 46 protocol. EAP-FAST is an EAP method that enables secure 47 communication between a peer and a server by using the Transport 48 Layer Security (TLS) to establish a mutually authenticated tunnel. 50 Within the tunnel, Type-Length-Value (TLV) objects are used to convey 51 authentication related data between the peer and the EAP server. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Specification Requirements . . . . . . . . . . . . . . . . 5 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Architectural Model . . . . . . . . . . . . . . . . . . . 6 60 2.2. Protocol Layering Model . . . . . . . . . . . . . . . . . 7 61 3. EAP-FAST Protocol . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 8 63 3.2. EAP-FAST Authentication Phase 1: Tunnel Establishment . . 9 64 3.2.1. TLS Session Resume using Server State . . . . . . . . 10 65 3.2.2. TLS Session Resume Using a PAC . . . . . . . . . . . . 10 66 3.2.3. Transition between Abbreviated and Full TLS 67 Handshake . . . . . . . . . . . . . . . . . . . . . . 12 68 3.3. EAP-FAST Authentication Phase 2: Tunneled 69 Authentication . . . . . . . . . . . . . . . . . . . . . . 12 70 3.3.1. EAP Sequences . . . . . . . . . . . . . . . . . . . . 12 71 3.3.2. Protected Termination and Acknowledged Result 72 Indication . . . . . . . . . . . . . . . . . . . . . . 13 73 3.4. Determining Peer-Id and Server-Id . . . . . . . . . . . . 14 74 3.5. EAP-FAST Session Identifier . . . . . . . . . . . . . . . 15 75 3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 15 76 3.6.1. TLS Layer Errors . . . . . . . . . . . . . . . . . . . 15 77 3.6.2. Phase 2 Errors . . . . . . . . . . . . . . . . . . . . 16 78 3.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 16 79 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 80 4.1. EAP-FAST Message Format . . . . . . . . . . . . . . . . . 17 81 4.1.1. Authority ID Data . . . . . . . . . . . . . . . . . . 19 82 4.2. EAP-FAST TLV Format and Support . . . . . . . . . . . . . 20 83 4.2.1. General TLV Format . . . . . . . . . . . . . . . . . . 21 84 4.2.2. Result TLV . . . . . . . . . . . . . . . . . . . . . . 22 85 4.2.3. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 23 86 4.2.4. Error TLV . . . . . . . . . . . . . . . . . . . . . . 24 87 4.2.5. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 25 88 4.2.6. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 26 89 4.2.7. Intermediate-Result TLV . . . . . . . . . . . . . . . 27 90 4.2.8. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 28 91 4.2.9. Request-Action TLV . . . . . . . . . . . . . . . . . . 31 92 4.3. Table of TLVs . . . . . . . . . . . . . . . . . . . . . . 31 93 5. Cryptographic Calculations . . . . . . . . . . . . . . . . . . 32 94 5.1. EAP-FAST Authentication Phase 1: Key Derivations . . . . . 32 95 5.2. Intermediate Compound Key Derivations . . . . . . . . . . 33 96 5.3. Computing the Compound MAC . . . . . . . . . . . . . . . . 34 97 5.4. EAP Master Session Key Generation . . . . . . . . . . . . 34 98 5.5. T-PRF . . . . . . . . . . . . . . . . . . . . . . . . . . 35 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 101 7.1. Mutual Authentication and Integrity Protection . . . . . . 37 102 7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . . 37 103 7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 38 104 7.4. Mitigation of Known Vulnerabilities and Protocol 105 Deficiencies . . . . . . . . . . . . . . . . . . . . . . . 38 106 7.4.1. User Identity Protection and Verification . . . . . . 39 107 7.4.2. Dictionary Attack Resistance . . . . . . . . . . . . . 40 108 7.4.3. Protection against man-in-the-middle Attacks . . . . . 40 109 7.4.4. PAC binding to User Identity . . . . . . . . . . . . . 40 110 7.5. Protecting against Forged Clear Text EAP Packets . . . . . 40 111 7.6. Server Certificate Validation . . . . . . . . . . . . . . 41 112 7.7. Tunnel PAC Considerations . . . . . . . . . . . . . . . . 41 113 7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 42 114 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 115 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 116 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43 117 9.2. Informative References . . . . . . . . . . . . . . . . . . 44 118 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 45 119 A.1. Successful Authentication . . . . . . . . . . . . . . . . 45 120 A.2. Failed Authentication . . . . . . . . . . . . . . . . . . 46 121 A.3. Full TLS Handshake using Certificate-based Cipher Suite . 48 122 A.4. Client authentication during Phase 1 with identity 123 privacy . . . . . . . . . . . . . . . . . . . . . . . . . 49 124 A.5. Fragmentation and Reassembly . . . . . . . . . . . . . . . 51 125 A.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 53 126 A.7. Failed Crypto-binding . . . . . . . . . . . . . . . . . . 55 127 A.8. Sequence of EAP Method with Vendor-Specific TLV 128 Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 57 129 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 59 130 B.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 59 131 B.2. Crypto-Binding MIC . . . . . . . . . . . . . . . . . . . . 61 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 133 Intellectual Property and Copyright Statements . . . . . . . . . . 63 135 1. Introduction 137 Network access solutions requiring user friendly and easily 138 deployable secure authentication mechanisms highlight the need for 139 strong mutual authentication protocols that enable the of use weaker 140 user credentials. This document defines an Extensible Authentication 141 Protocol (EAP) which consists of establishing a Transport Layer 142 Security (TLS) tunnel using TLS 1.0 [RFC2246], TLS 1.1 143 [RFC4346][RFC4346], or a successor version of TLS, using the latest 144 version supported by both parties. Once the tunnel is established, 145 the protocol further exchanges data in the form of type, length, 146 value objects (TLV) to perform further authentication. EAP-FAST 147 supports the TLS extension defined in [RFC4507] to support fast re- 148 establishment of the secure tunnel without having to maintain per- 149 session state on the server. [I-D.cam-winget-eap-fast-provisioning] 150 defines EAP-FAST based mechanisms to provision the credential for 151 this extension which is called a Protected Access Credential (PAC). 153 EAP-FAST's design motivations included: 155 o Mutual Authentication: an EAP Server must be able to verify the 156 identity and authenticity of the peer, and the peer must be able 157 to verify the authenticity of the EAP server. 159 o Immunity to passive dictionary attacks: many authentication 160 protocols require a password to be explicitly provided (either as 161 cleartext or hashed) by the peer to the EAP server; at minimum, 162 the communication of the weak credential (e.g. password) must be 163 immune from eavesdropping. 165 o Immunity to man-in-the-middle (MitM) attacks: in establishing a 166 mutually authenticated protected tunnel, the protocol must prevent 167 adversaries from successfully interjecting information into the 168 conversation between the peer and the EAP server. 170 o Flexibility to enable support for most password authentication 171 interfaces: as many different password interfaces (e.g. MSCHAP, 172 LDAP, OTP, etc) exist to authenticate a peer, the protocol must 173 provide this support seamlessly. 175 o Efficiency: specifically when using wireless media, peers will be 176 limited in computational and power resources. The protocol must 177 enable the network access communication to be computationally 178 lightweight. 180 With these motivational goals defined, further secondary design 181 criteria are imposed: 183 o Flexibility to extend the communications inside the tunnel: with 184 the growing complexity in network infrastructures the need to gain 185 authentication, authorization and accounting is also evolving. 186 For instance, there may be instances in which multiple existing 187 authentication protocols are required to achieve mutual 188 authentication. Similarly, different protected conversations may 189 be required to achieve the proper authorization once a peer has 190 successfully authenticated. 192 o Minimize the authentication server's per user authentication state 193 requirements: with large deployments, it is typical to have many 194 servers acting as the authentication servers for many peers. It 195 is also highly desirable for a peer to use the same shared secret 196 to secure a tunnel much the same way it uses the username and 197 password to gain access to the network. The protocol must 198 facilitate the use of a single strong shared secret by the peer 199 while enabling the servers to minimize the per user and device 200 state it must cache and manage. 202 1.1. Specification Requirements 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119] . 208 1.2. Terminology 210 Much of the terminology in this document comes from [RFC3748]. 211 Additional terms are defined below: 213 Protected Access Credential (PAC) 215 Credentials distributed to a peer for future optimized network 216 authentication. The PAC consists of at most three components: a 217 shared secret, an opaque element and optionally other information. 218 The shared secret component contains the pre-shared key between 219 the peer and the authentication server. The opaque part is 220 provided to the peer and is presented to the authentication server 221 when the peer wishes to obtain access to network resources. 222 Finally, a PAC may optionally include other information that may 223 be useful to the peer. The opaque part of the PAC is the same 224 type of data as the ticket in [RFC4507] and the shared secret is 225 used to derive the TLS master secret. 227 2. Protocol Overview 229 EAP-FAST is an authentication protocol similar to EAP-TLS [RFC2716] 230 that enables mutual authentication and cryptographic context 231 establishment by using the TLS handshake protocol. EAP-FAST allows 232 for the established TLS tunnel to be used for further authentication 233 exchanges. EAP-FAST makes use of TLVs to carry out the inner 234 authentication exchanges. The tunnel is then used to protect weaker 235 inner authentication methods, which may be based on passwords, and to 236 communicate the results of the authentication. 238 EAP-FAST makes use of the TLS enhancements in [RFC4507] to enable an 239 optimized TLS tunnel session resume while minimizing server state. 240 The secret key used in EAP-FAST is referred to as the Protected 241 Access Credential key (or PAC-Key); the PAC-Key is used to mutually 242 authenticate the peer and the server when securing a tunnel. The 243 ticket is referred to as the Protected Access Credential opaque data 244 (or PAC-Opaque). The secret key and ticket used to establish the 245 tunnel may be provisioned through mechanisms that do not involve the 246 TLS handshake. It is RECOMMENDED that implementations support the 247 capability to distribute the ticket and secret key within the EAP- 248 FAST tunnel as specified in [I-D.cam-winget-eap-fast-provisioning]. 250 The EAP-FAST conversation is used to establish or resume an existing 251 session to typically establish network connectivity between a peer 252 and the network. Upon successful execution of EAP-FAST both EAP Peer 253 and EAP Server derive strong session key material which can then be 254 communicated to the network access server (NAS) for use in 255 establishing a link layer security association. 257 2.1. Architectural Model 259 The network architectural model for EAP-FAST usage is shown below: 261 +----------+ +----------+ +----------+ +----------+ 262 | | | | | | | Inner | 263 | Peer |<---->| Authen- |<---->| EAP-FAST |<---->| Method | 264 | | | ticator | | server | | server | 265 | | | | | | | | 266 +----------+ +----------+ +----------+ +----------+ 268 EAP-FAST Architectural Model 270 The entities depicted above are logical entities and may or may not 271 correspond to separate network components. For example, the EAP-FAST 272 server and inner method server might be a single entity; the 273 authenticator and EAP-FAST server might be a single entity; or, the 274 functions of the authenticator, EAP-FAST server and inner method 275 server might be combined into a single physical device. For example, 276 typical 802.11 deployments place the Authenticator in an access point 277 (AP) while a Radius Server may provide the EAP-FAST and inner method 278 server components. The above diagram illustrates the division of 279 labor among entities in a general manner and shows how a distributed 280 system might be constructed; however, actual systems might be 281 realized more simply. The security considerations Section 7.3 282 provides an additional discussion of the implications of separating 283 EAP-FAST server from the inner method server. 285 2.2. Protocol Layering Model 287 EAP-FAST packets are encapsulated within EAP, and EAP in turn, 288 requires a carrier protocol for transport. EAP-FAST packets 289 encapsulate TLS, which is then used to encapsulate user 290 authentication information. Thus, EAP-FAST messaging can be 291 described using a layered model, where each layer encapsulates the 292 layer beneath it. The following diagram clarifies the relationship 293 between protocols: 295 +---------------------------------------------------------------+ 296 | Inner EAP Method | Other TLV information | 297 |---------------------------------------------------------------| 298 | TLV Encapsulation (TLVs) | 299 |---------------------------------------------------------------| 300 | TLS | 301 |---------------------------------------------------------------| 302 | EAP-FAST | 303 |---------------------------------------------------------------| 304 | EAP | 305 |---------------------------------------------------------------| 306 | Carrier Protocol (EAPOL, RADIUS, Diameter, etc.) | 307 +---------------------------------------------------------------+ 309 Protocol Layering Model 311 The TLV layer is a payload with Type-Length-Value (TLV) Objects 312 defined in Section 4.2. The TLV objects are used to carry arbitrary 313 parameters between an EAP peer and an EAP server. All conversations 314 in the EAP-FAST protected tunnel must be encapsulated in a TLV layer. 316 Methods for encapsulating EAP within carrier protocols are already 317 defined. For example, IEEE 802.1X [IEEE.802-1X.2004] may be used to 318 transport EAP between the peer and the authenticator; RADIUS 319 [RFC3579] or Diameter [RFC4072] may be used to transport EAP between 320 the authenticator and the EAP-FAST server. 322 3. EAP-FAST Protocol 324 EAP-FAST authentication occurs in two phases. In the first phase, 325 EAP-FAST employs the TLS handshake to provide an authenticated key 326 exchange and to establish a protected tunnel. Once the tunnel is 327 established the second phase begins with the peer and server engaging 328 in further conversations to establish the required authentication and 329 authorization policies. The operation of the protocol including 330 phase 1 and phase 2 are the topic of this section. The format of 331 EAP-FAST messages is given in Section 4 and the cryptographic 332 calculations are given in Section 5. 334 3.1. Version Negotiation 336 EAP-FAST packets contain a three bit version field, following the TLS 337 Flags field, which enables EAP-FAST implementations to be backward 338 compatible with previous versions of the protocol. This 339 specification documents the EAP-FAST version 1 protocol; 340 implementations of this specification MUST use a version field set to 341 1. 343 Version negotiation proceeds as follows: 345 In the first EAP-Request sent with EAP type=EAP-FAST, the EAP 346 server must set the version field to the highest supported version 347 number. 349 If the EAP peer supports this version of the protocol, it MUST 350 respond with an EAP-Response of EAP type=EAP-FAST, and the version 351 number proposed by the EAP-FAST server. 353 If the EAP-FAST peer does not support this version, it responds 354 with an EAP-Response of EAP type=EAP-FAST and the highest 355 supported version number. 357 If the EAP-FAST server does not support the version number 358 proposed by the EAP-FAST peer, it terminates the conversation. 359 Otherwise the EAP-FAST conversation continues. 361 The version negotiation procedure guarantees that the EAP-FAST peer 362 and server will agree to the latest version supported by both 363 parties. If version negotiation fails, then use of EAP-FAST will not 364 be possible, and another mutually acceptable EAP method will need to 365 be negotiated if authentication is to proceed. 367 The EAP-FAST version is not protected by TLS; and hence can be 368 modified in transit. In order to detect modification of EAP-FAST 369 version, the peers MUST exchange the EAP-FAST version number received 370 during version negotiation using the Crypto-Binding TLV described in 371 Section 4.2.8. The receiver of the Crypto-Binding TLV MUST verify 372 that the version received in the Crypto-Binding TLV matches the 373 version sent by the receiver in the EAP-FAST version negotiation. 375 3.2. EAP-FAST Authentication Phase 1: Tunnel Establishment 377 EAP-FAST is based on TLS handshake [RFC2246] to establish an 378 authenticated and protected tunnel. The TLS version offered by the 379 peer and server MUST be TLS v1.0 or later. This version of the EAP- 380 FAST implementation MUST support the following TLS ciphersuites: 382 TLS_RSA_WITH_RC4_128_SHA 383 TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268] 384 TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC3268] 386 Other ciphersuites MAY be supported. It is RECOMMENDED that 387 anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only 388 be used in the context of the provisioning described in 389 [I-D.cam-winget-eap-fast-provisioning]. Care must be taken to 390 address potential man-in-the-middle attacks when cipher suites that 391 do not provide authenticated tunnel establishment are used. During 392 the EAP-FAST Phase 1 conversation the EAP-FAST endpoints MAY 393 negotiate TLS compression. 395 The EAP server initiates the EAP-FAST conversation with an EAP 396 request containing an EAP-FAST/Start packet. This packet includes a 397 set Start (S) bit, the EAP-FAST version as specified in Section 3.1, 398 and an authority identity. The TLS payload in the initial packet is 399 empty. The authority identity (A-ID) is used to provide the peer a 400 hint of the server's identity which may be useful in helping the peer 401 select the appropriate credential to use. Assuming that the peer 402 supports EAP-FAST the conversation continues with the peer sending an 403 EAP-Response packet with EAP type of EAP-FAST with the start (s) bit 404 clear and the version as specified in Section 3.1. This message 405 encapsulates one or more TLS records containing the TLS handshake 406 messages. If the EAP-FAST version negotiation is successful then the 407 EAP-FAST conversation continues until the EAP server and EAP peer are 408 ready to enter phase 2. When the full TLS handshake is performed, 409 then the first payload of EAP-FAST Phase 2 MAY be sent along with 410 server finished handshake message to reduce the number of round 411 trips. 413 After the TLS session is established, another EAP exchange MAY occur 414 within the tunnel to authenticate the EAP peer. EAP-FAST 415 implementations MUST support client authentication during tunnel 416 establishment using the specified TLS ciphersuites specified in 417 Section 3.2. EAP-FAST implementations SHOULD also support the 418 immediate re-negotiation of a TLS session to initiate a new handshake 419 message exchange under the protection of the current ciphersuite. 420 This allows support for protection of the peer's identity. Note that 421 the EAP peer does not need to authenticate as part of the TLS 422 exchange, but can alternatively be authenticated through additional 423 EAP exchanges carried out in phase 2. 425 The EAP-FAST tunnel protects peer identity information from 426 disclosure outside the tunnel. Implementations that wish to provide 427 identity privacy for the peer identity must carefully consider what 428 information is disclosed outside the tunnel. 430 The following sections describe resuming a TLS session based on 431 server side or client side state. 433 3.2.1. TLS Session Resume using Server State 435 EAP-FAST session resumption is achieved in the same manner TLS 436 achieves session resume. To support session resumption, the server 437 and peer must minimally cache the sessionID, master secret and 438 ciphersuite. The peer attempts to resume a session by including a 439 valid Session ID from a previous handshake in its ClientHello 440 message. If the server finds a match for the sessionID and is 441 willing to establish a new connection using the specified session 442 state, the server will respond with the same sessionID and proceed 443 with the EAP-FAST Authentication Phase 1 tunnel establishment based 444 on a TLS abbreviated handshake. After a successful conclusion of the 445 EAP-FAST Authentication Phase 1 conversation, the conversation then 446 continues on to phase 2. 448 3.2.2. TLS Session Resume Using a PAC 450 EAP-FAST supports the resumption of sessions based on client side 451 state using techniques described in [RFC4507]. This version of EAP- 452 FAST does not support the provisioning of a ticket through the use of 453 the SessionTicket handshake message. Instead it supports the 454 provisioning of a ticket called a Protected Access Credential (PAC) 455 as described in [I-D.cam-winget-eap-fast-provisioning]. 456 Implementations may provide additional ways to provision the PAC, 457 such as manual configuration. Since the PAC mentioned here is used 458 for establishing the TLS Tunnel, it is more specifically referred to 459 as the Tunnel PAC. The Tunnel PAC is a security credential provided 460 by the EAP server to a peer and comprised of: 462 1. PAC-Key: this is a 32-octet key used by the peer to establish the 463 EAP-FAST Phase 1 tunnel. This key is used to derive the TLS 464 premaster secret as described in Section 5.1. The PAC-Key is 465 randomly generated by the EAP Server to produce a strong entropy 466 32-octet key. The PAC-Key is a secret and MUST be treated 467 accordingly. For example as the PAC-Key is a separate component 468 provisioned by the server to establish a secure tunnel, the 469 server by deliver this component protected by a secure channel 470 and must be stored securely by the peer. 472 2. PAC-Opaque: this is a variable length field that is sent to the 473 EAP Server during the EAP-FAST Phase 1 tunnel establishment. The 474 PAC-Opaque can only be interpreted by the EAP Server to recover 475 the required information for the server to validate the peer's 476 identity and authentication. For example, the PAC-Opaque 477 includes the PAC-Key and may contain the PAC's peer identity. 478 The PAC-Opaque format and contents are specific to the PAC 479 issuing server. The PAC-Opaque may be presented in the clear, so 480 an attacker MUST NOT be able to gain useful information from the 481 PAC-Opaque itself. The server issuing the PAC-Opaque must ensure 482 it is protected with strong cryptographic keys and algorithms. 484 3. PAC-Info: this is a variable length field used to provide at 485 minimum, the authority identity of PAC issuer. Other useful but 486 not mandatory information, such as the PAC-Key lifetime, may also 487 be conveyed by the PAC issuing server to the peer during PAC 488 provisioning or refreshment. 490 The use of the PAC is based on the SessionTicket extension defined in 491 [RFC4507]. The EAP Server initiates the EAP-FAST conversation as 492 normal. Upon receiving the A-ID from the server the peer checks to 493 see if it has an existing valid PAC-Key and PAC-Opaque for the 494 server. If it does then it obtains the PAC-Opaque and puts it in the 495 SessionTicket extension in the ClientHello. It is RECOMMENDED in 496 EAP-FAST that the peer include an empty session ID in a ClientHello 497 containing a PAC-Opaque. EAP-FAST does not currently support the 498 SessionTicket Handshake message so an empty SessionTicket extension 499 MUST NOT be included in the ClientHello. If the PAC-Opaque included 500 in SessionTicket extension is valid and EAP server permits the 501 abbreviated TLS handshake, it will select the ciphersuite allowed to 502 be used from information within the PAC and finish with the 503 abbreviated TLS handshake. If the server receives a Session ID and a 504 PAC-Opaque in the SessionTicket extension in a ClientHello it should 505 place the same Session ID in the ServerHello if it is resuming a 506 session based on the PAC-Opaque. The conversation then proceeds as 507 described in [RFC4507] until the handshake completes or a fatal error 508 occurs. After the abbreviated handshake completes the peer and 509 server are ready to commence phase 2. Note that when a PAC is used 510 the TLS master secret is calculated from the PAC-Key, client random 511 and server random as described in Section 5.1. 513 Specific details for the Tunnel PAC format, provisioning and security 514 considerations are best described in 515 [I-D.cam-winget-eap-fast-provisioning] 517 3.2.3. Transition between Abbreviated and Full TLS Handshake 519 If session resumption based on server side or client side state fails 520 the server can gracefully fall back to a full TLS handshake. If the 521 ServerHello received by the peer contains a empty Session ID or a 522 Session ID that is different than in the ClientHello the server may 523 be falling back to a full handshake. The peer can distinguish 524 Server's intent of negotiating full or abbreviated TLS handshake by 525 checking the next TLS handshake messages in the server response to 526 ClientHello. If ChangeCipherSpec follows the ServerHello in response 527 to the ClientHello, then the Server has accepted the session 528 resumption and intends to negotiate the abbreviated handshake. 529 Otherwise, the Server intends to negotiate the full TLS handshake. A 530 peer can request for a new PAC to be provisioned after the full TLS 531 handshake and mutual authentication of the peer and the server. In 532 order to facilitate the fall back to a full handshake the peer SHOULD 533 include ciphersuites that allow for a full handshake and possibly PAC 534 provisioning so the server can select one of this in case session 535 resumption fails. An example of the transition is shown in 536 Appendix A. 538 3.3. EAP-FAST Authentication Phase 2: Tunneled Authentication 540 The second portion of the EAP-FAST Authentication occurs immediately 541 after successful completion of phase 1. Phase 2 occurs even if both 542 peer and authenticator are authenticated in the phase 1 TLS 543 negotiation. Phase 2 MUST NOT occur if the Phase 1 TLS handshake 544 fails. Phase 2 consists of a series of requests and responses 545 encapsulated in TLV objects defined in Section 4.2. Phase 2 MUST 546 always end with a protected termination exchange described in 547 Section 3.3.2. The TLV exchange may include the execution of zero or 548 more EAP methods within the protected tunnel as described in 549 Section 3.3.1. A server MAY proceed directly to the protected 550 termination exchange if it does not wish to request further 551 authentication from the peer. However, the peer and server must not 552 assume that either will skip inner EAP methods or other TLV 553 exchanges. The peer may have roamed to a network which requires 554 conformance with a different authentication policy or the peer may 555 request the server take additional action through the use of the 556 Request-Action TLV. 558 3.3.1. EAP Sequences 560 EAP [RFC3748] prohibits use of multiple authentication methods within 561 a single EAP conversation in order to limit vulnerabilities to man- 562 in-the-middle attacks. EAP-FAST addresses man-in-the-middle attacks 563 through support for cryptographic protection of the inner EAP 564 exchange and cryptographic binding of the inner authentication 565 method(s) to the protected tunnel. EAP methods are executed serially 566 in a sequence. This version of EAP-FAST does not support initiating 567 multiple EAP methods simultaneously in parallel. The methods need 568 not be distinct. For example, EAP-TLS could be run twice as an inner 569 method, first using machine credentials followed by a second instance 570 using user credentials. 572 EAP method messages are carried within EAP-Payload TLVs defined in 573 Section 4.2.6. If more than one method is going to be executed in 574 the tunnel then upon method completion of a method a server MUST send 575 an Intermediate-Result TLV indicating the result. The peer MUST 576 respond to the Intermediate-Result TLV indicating its result. If the 577 result indicates success the Intermediate-Result TLV MUST be 578 accompanied by a Crypto-Binding TLV. The Crypto-Binding TLV is 579 further discussed in Section 4.2.8 and Section 5.3. The 580 Intermediate-Result TLVs can be included with other TLVs such as EAP- 581 Payload TLVs starting a new EAP conversation or with the Result TLV 582 used in the protected termination exchange. In the case of only one 583 EAP method is executed in the tunnel, the Intermediate-Result TLV 584 MUST NOT be sent with the Result TLV. In this case, the status of 585 the inner EAP method is represented by the final Result TLV, which 586 also represents the result of the whole EAP-FAST conversation. This 587 is to maintain backward compatibility with existing implementations. 589 If both peer and server indicate success then the method is 590 considered complete. If either indicates failure then the method is 591 considered failed. The result of failure of a EAP method does not 592 always imply a failure of the overall authentication. If one 593 authentication method fails the server may attempt to authenticate 594 the peer with a different method. 596 3.3.2. Protected Termination and Acknowledged Result Indication 598 A successful EAP-FAST phase 2 conversation MUST always end in a 599 successful Result TLV exchange. An EAP-FAST server may initiate the 600 Result TLV exchange without initiating any EAP conversation in EAP- 601 FAST Phase 2. After the final Result TLV exchange the TLS tunnel is 602 terminated and a clear text EAP-Success or EAP-Failure is sent by the 603 server. The format of the Result TLV is described in Section 4.2.2. 605 A server initiates a successful protected termination exchange by 606 sending a Result TLV indicating success. The server may send the 607 Result TLV along with an Intermediate-Result TLV and a Crypto-Binding 608 TLV. If the peer requires nothing more from the server it will 609 respond with a Result TLV indicating success accompanied by an 610 Intermediate-Result TLV and Crypto-Binding TLV if necessary. The 611 server then tears down the tunnel and sends a clear text EAP-Success. 613 If the peer receives a Result TLV indicating success from the server, 614 but its authentication policies are not satisfied (for example it 615 requires a particular authentication mechanism be run or it wants to 616 request a PAC) it may request further action from the server using 617 the Request-Action TLV. The Request-Action TLV is sent along with 618 the Result TLV indicating what EAP Success/Failure result peer would 619 expect if the requested action is not granted. The value of the 620 Request-Action TLV indicates what the peer would like to do next. 621 The format and values for the Request-Action TLV are defined in 622 Section 4.2.9. 624 Upon receiving the Request-Action TLV the server may process the 625 request or ignore it, based on its policy. If the server ignores the 626 request, it proceeds with termination of the tunnel and send the 627 clear text EAP Success or Failure message based on the value of the 628 peer's result TLV. If server honors and processes the request, it 629 continues with the requested action. The conversation completes with 630 a Result TLV exchange. The Result TLV may be included with the TLV 631 that completes the requested action. 633 Error handling for phase 2 is discussed in Section 3.6.2. 635 3.4. Determining Peer-Id and Server-Id 637 The Peer-Id and Server-Id may be determined based on the types of 638 credentials used during either the EAP-FAST tunnel creation or 639 authentication. 641 When X.509 certificates are used for peer authentication, the Peer-Id 642 is determined by the subject or altSubjectName fields in the peer 643 certificate. As noted in [RFC3280]: 645 The subject field identifies the entity associated with the public 646 key stored in the subject public key field. The subject name MAY 647 be carried in the subject field and/or the subjectAltName 648 extension... If subject naming information is present only in the 649 subjectAltName extension (e.g., a key bound only to an email 650 address or URI), then the subject name MUST be an empty sequence 651 and the subjectAltName extension MUST be critical. 652 Where it is non-empty, the subject field MUST contain an X.500 653 distinguished name (DN). 655 If an inner EAP method is run, then the Peer-Id is obtained from the 656 inner method. 658 When the server uses an X.509 certificate to establish the TLS 659 tunnel, the Server-Id is determined in a similar fashion as stated 660 above for the Peer-Id; e.g. the subject or altSubjectName field in 661 the server certificate defines the Server-Id. 663 3.5. EAP-FAST Session Identifier 665 The EAP session identifier is constructed using the random values 666 provided by the peer and server during the TLS tunnel establishment. 667 The Session-Id is defined as follows: 669 Session-Id = 0x2B || client_random || server_random) 670 client_random = 32 byte nonce generated by the peer 671 server_random = 32 byte nonce generated by the server 673 3.6. Error Handling 675 EAP-FAST uses the following error handling rules summarized below: 677 1. Errors in TLS layer are communicated via TLS alert messages in 678 all phases of EAP-FAST. 679 2. The Intermediate-Result TLVs indicate success or failure 680 indications of the individual EAP methods in EAP-FAST Phase 2. 681 Errors within the EAP conversation in Phase 2 are expected to be 682 handled by individual EAP methods. 683 3. Violations of the TLV rules are handled using Result TLVs 684 together with Error TLVs. 685 4. Tunnel compromised errors (errors caused by Crypto-Binding failed 686 or missing) are handled using Result TLVs and Error TLVs. 688 3.6.1. TLS Layer Errors 690 If the EAP-FAST server detects an error at any point in the TLS 691 Handshake or the TLS layer, the server SHOULD send an EAP-FAST 692 request encapsulating a TLS record containing the appropriate TLS 693 alert message rather than immediately terminating the conversation so 694 as to allow the peer to inform the user of the cause of the failure 695 and possibly allow for a restart of the conversation. The peer MUST 696 send an EAP-FAST response to an alert message. The EAP-Response 697 packet sent by the peer may encapsulate a TLS ClientHello handshake 698 message, in which case the EAP-FAST server MAY allow the EAP-FAST 699 conversation to be restarted, or it MAY contain an EAP-FAST response 700 with a zero length message, in which case the server MUST terminate 701 the conversation with an EAP-Failure packet. It is up to the EAP- 702 FAST server whether to allow restarts, and if so, how many times the 703 conversation can be restarted. An EAP-FAST Server implementing 704 restart capability SHOULD impose a limit on the number of restarts, 705 so as to protect against denial of service attacks. 707 If the EAP-FAST peer detects an error at any point in the TLS layer, 708 the EAP-FAST peer should send an EAP-FAST response encapsulating a 709 TLS record containing the appropriate TLS alert message. The server 710 may restart the conversation by sending an EAP-FAST request packet 711 encapsulating the TLS HelloRequest handshake message. The peer may 712 allow the EAP-FAST conversation to be restarted or it may terminate 713 the conversation by sending an EAP-FAST response with an zero length 714 message. 716 3.6.2. Phase 2 Errors 718 Any time the peer or the server finds a fatal error outside of the 719 TLS layer during phase 2 TLV processing it MUST send a Result TLV of 720 failure and an Error TLV with the appropriate error code. For errors 721 involving the processing the sequence of exchanges, such as a 722 violation of TLV rules (e.g., multiple EAP-Payload TLVs) the error 723 code is Unexpected_TLVs_Exchanged. For errors involving a tunnel 724 compromise the error-code is Tunnel_Compromise_Error. Upon sending a 725 Result TLV with a fatal Error TLV the sender terminates the TLS 726 tunnel. Note that a server will still wait for a message from the 727 peer after it sends a failure, however the server does not need to 728 process the contents of the response message. 730 If a server receives a Result TLV of failure with a fatal Error TLV 731 it SHOULD send a clear text EAP-Failure. If a peer receives a Result 732 TLV of failure it MUST respond with a Result TLV indicating failure. 733 If the server has sent a Result TLV of failure it ignores the peer 734 response and it SHOULD send a clear text EAP-Failure. 736 3.7. Fragmentation 738 A single TLS record may be up to 16384 octets in length, but a TLS 739 message may span multiple TLS records, and a TLS certificate message 740 may in principle be as long as 16MB. This is larger than the maximum 741 size for a message on most media types, therefore it is desirable to 742 support fragmentation. Note that in order to protect against 743 reassembly lockup and denial of service attacks, it may be desirable 744 for an implementation to set a maximum size for one such group of TLS 745 messages. Since a typical certificate chain is rarely longer than a 746 few thousand octets, and no other field is likely to be anywhere near 747 as long, a reasonable choice of maximum acceptable message length 748 might be 64 KB. This is still a fairly large message packet size so 749 an EAP-FAST implementation MUST provide its own support for 750 fragmentation and reassembly. 752 Since EAP is an lock-step protocol, fragmentation support can be 753 added in a simple manner. In EAP, fragments that are lost or damaged 754 in transit will be retransmitted, and since sequencing information is 755 provided by the Identifier field in EAP, there is no need for a 756 fragment offset field. 758 EAP-FAST fragmentation support is provided through addition of flag 759 bits within the EAP-Response and EAP-Request packets, as well as a 760 TLS Message Length field of four octets. Flags include the Length 761 included (L), More fragments (M), and EAP-FAST Start (S) bits. The L 762 flag is set to indicate the presence of the four octet TLS Message 763 Length field, and MUST be set for the first fragment of a fragmented 764 TLS message or set of messages. The M flag is set on all but the 765 last fragment. The S flag is set only within the EAP-FAST start 766 message sent from the EAP server to the peer. The TLS Message Length 767 field is four octets, and provides the total length of the TLS 768 message or set of messages that is being fragmented; this simplifies 769 buffer allocation. 771 When an EAP-FAST peer receives an EAP-Request packet with the M bit 772 set, it MUST respond with an EAP-Response with EAP-Type of EAP-FAST 773 and no data. This serves as a fragment ACK. The EAP server must 774 wait until it receives the EAP-Response before sending another 775 fragment. In order to prevent errors in processing of fragments, the 776 EAP server MUST increment the Identifier field for each fragment 777 contained within an EAP-Request, and the peer must include this 778 Identifier value in the fragment ACK contained within the EAP- 779 Response. Retransmitted fragments will contain the same Identifier 780 value. 782 Similarly, when the EAP-FAST server receives an EAP-Response with the 783 M bit set, it must respond with an EAP-Request with EAP-Type of EAP- 784 FAST and no data. This serves as a fragment ACK. The EAP peer MUST 785 wait until it receives the EAP-Request before sending another 786 fragment. In order to prevent errors in the processing of fragments, 787 the EAP server MUST increment the Identifier value for each fragment 788 ACK contained within an EAP-Request, and the peer MUST include this 789 Identifier value in the subsequent fragment contained within an EAP- 790 Response. 792 4. Message Formats 794 The following sections describe the message formats used in EAP-FAST. 795 The fields are transmitted from left to right in network byte order. 797 4.1. EAP-FAST Message Format 799 A summary of the EAP-FAST Request/Response packet format is shown 800 below. 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Code | Identifier | Length | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Flags | Ver | Message Length + 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Message Length | Data... + 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Code 814 The code field is one octet in length defined as follows: 816 1 Request 817 2 Response 819 Identifier 821 The Identifier field is one octet and aids in matching 822 responses with requests. The Identifier field MUST be changed 823 on each Request packet. The Identifier field in the Response 824 packet MUST match the Identifier field from the corresponding 825 request. 827 Length 829 The Length field is two octets and indicates the length of the 830 EAP packet including the Code, Identifier, Length, Type, Flags, 831 Ver, Message Length and Data fields. Octets outside the range 832 of the Length field should be treated as Data Link Layer 833 padding and should be ignored on reception. 835 Type 837 43 for EAP-FAST 839 Flags 841 0 1 2 3 4 842 +-+-+-+-+-+ 843 |L M S R R| 844 +-+-+-+-+-+ 845 L Length included 846 M More fragments 847 S EAP-FAST start 848 R Reserved (must be zero) 850 L bit (length included) is set to indicate the presence of 851 the four octet Message Length field, and MUST be set for the 852 first fragment of a fragmented TLS message or set of 853 messages. The M bit (more fragments) is set on all but the 854 last fragment. The S bit (EAP-FAST Start) is set in an EAP- 855 FAST Start message. 857 Ver 859 This field contains the version of the protocol. This document 860 describes version 1 (001 in binary) of EAP-FAST. 862 Message Length 864 The Message Length field is four octets, and is present only if 865 the L bit is set. This field provides the total length of the 866 message that may be fragmented over the data fields of multiple 867 packets. 869 Data 871 In the case of a EAP-FAST Start request (i.e. when the S bit is 872 set) the Data field consists of the A-ID described in 873 Section 4.1.1. In other cases when the Data field is present 874 it consists of an encapsulated TLS packet in TLS record format. 875 An EAP-FAST packet with Flags and Version fields but with zero 876 length data field to used to indicate EAP-FAST acknowledgement 877 for either a fragmented message, a TLS Alert message or a TLS 878 Finished message. 880 4.1.1. Authority ID Data 882 0 1 2 3 883 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 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Type (0x04) | Length | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | ID 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 Type 891 The type field is two octets. It is set to 0x0004 for 892 Authority ID 894 Length 896 The Length filed is two octets, which contains the length of 897 the ID field in octets. 899 ID 901 Hint of the identity of the server. It should be unique across 902 the deployment. 904 4.2. EAP-FAST TLV Format and Support 906 The TLVs defined here are standard Type-Length-Value (TLV) objects. 907 The TLV objects could be used to carry arbitrary parameters between 908 EAP peer and EAP server within the protected TLS tunnel. 910 The EAP peer may not necessarily implement all the TLVs supported by 911 the EAP server. To allow for interoperability, TLVs are designed to 912 allow an EAP server to discover if a TLV is supported by the EAP 913 peer, using the NAK TLV. The mandatory bit in a TLV indicates 914 whether support of the TLV is required. If the peer or server does 915 not support a TLV marked mandatory, then it MUST send a NAK TLV in 916 the response, and all the other TLVs in the message MUST be ignored. 917 If an EAP peer or server finds an unsupported TLV which is marked as 918 optional, it can ignore the unsupported TLV. It MUST NOT send an NAK 919 TLV for a TLV that is not marked mandatory. 921 Note that a peer or server may support a TLV with the mandatory bit 922 set, but may not understand the contents. The appropriate response 923 to a supported TLV with content that is not understood is defined by 924 the individual TLV specification. 926 EAP implementations compliant with this specification MUST support 927 TLV exchanges, as well as processing of mandatory/optional settings 928 on the TLV. Implementations conforming to this specification MUST 929 support the following TLVs: 931 Result TLV 932 NAK TLV 933 Error TLV 934 EAP-Payload TLV 935 Intermediate-Result TLV 936 Crypto-Binding TLV 937 Request-Action TLV 939 4.2.1. General TLV Format 941 TLVs are defined as described below. The fields are transmitted from 942 left to right. 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 |M|R| TLV Type | Length | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Value... 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 M 954 0 Optional TLV 955 1 Mandatory TLV 957 R 959 Reserved, set to zero (0) 961 TLV Type 963 A 14-bit field, denoting the TLV type. Allocated Types 964 include: 966 0 Reserved 967 1 Reserved 968 2 Reserved 969 3 Result TLV 970 4 NAK TLV 971 5 Error TLV 972 7 Vendor-Specific TLV 973 9 EAP-Payload TLV 974 10 Intermediate-Result TLV 975 11 PAC TLV [I-D.cam-winget-eap-fast-provisioning] 976 12 Crypto-Binding TLV 977 18 Server-Trusted-Root TLV 978 [I-D.cam-winget-eap-fast-provisioning] 979 19 Request-Action TLV 980 20 PKCS#7 TLV [I-D.cam-winget-eap-fast-provisioning] 982 Length 984 The length of the Value field in octets. 986 Value 988 The value of the TLV. 990 4.2.2. Result TLV 992 The Result TLV provides support for acknowledged success and failure 993 messages for protected termination within EAP-FAST. If the Status 994 field does not contain one of the known values, then the peer or EAP 995 server MUST treat this as a fatal error of Unexpected_TLVs_Exchanged. 996 The behavior of the Result TLV is further discussed in Section 3.3.2 997 and Section 3.6.2. An Result TLV indicating failure MUST NOT be 998 accompanied by the following TLVs: NAK, EAP-Payload TLV, or Crypto- 999 Binding TLV. Result TLV is defined as follows: 1001 0 1 2 3 1002 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 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 |M|R| TLV Type | Length | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Status | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 M 1011 Mandatory, set to one (1) 1013 R 1015 Reserved, set to zero (0) 1017 TLV Type 1019 3 for Result TLV 1021 Length 1023 2 1025 Status 1027 The Status field is two octets. Values include: 1029 1 Success 1030 2 Failure 1032 4.2.3. NAK TLV 1034 The NAK TLV allows a peer to detect TLVs that are not supported by 1035 the other peer. An EAP-FAST packet can contain 0 or more NAK TLVs. 1036 A NAK TLV should not be accompanied by other TLVs. A NAK TLV MUST 1037 NOT be sent in response to a message containing a Result TLV, instead 1038 a Result TLV of failure should be sent indicating failure and an 1039 Error TLV of Unexpected_TLVs_Exchanged. The NAK TLV is defined as 1040 follows: 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 |M|R| TLV Type | Length | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Vendor-Id | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | NAK-Type | TLVs.... 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 M 1054 Mandatory, set to one (1) 1056 R 1058 Reserved, set to zero (0) 1060 TLV Type 1062 4 for NAK TLV 1064 Length 1066 >=6 1068 Vendor-Id 1070 The Vendor-Id field is four octets, and contains the Vendor-Id 1071 of the TLV that was not supported. The high-order octet is 0 1072 and the low-order 3 octets are the SMI Network Management 1073 Private Enterprise Code of the Vendor in network byte order. 1074 The Vendor-Id field MUST be zero for TLVs that are not Vendor- 1075 Specific TLVs. 1077 NAK-Type 1079 The NAK-Type field is two octets. The field contains the Type 1080 of the TLV that was not supported. A TLV of this Type MUST 1081 have been included in the previous packet. 1083 TLVs 1085 This field contains a list of TLVs, each of which MUST NOT have 1086 the mandatory bit set. These optional TLVs are for future 1087 extensibility to communicate why the offending TLV was 1088 determined to be unsupported. 1090 4.2.4. Error TLV 1092 The Error TLV allows an EAP peer or server to indicate errors to the 1093 other party. An EAP-FAST packet can contain 0 or more Error TLVs. 1094 The Error-Code field describes the type of error. Error Codes 1-999 1095 represent successful outcomes (informative messages), 1000-1999 1096 represent warnings, and codes 2000-2999 represent fatal errors. A 1097 fatal Error TLV MUST be accompanied by a Result TLV indicating 1098 failure and the conversation must be terminated as described in 1099 Section 3.6.2. The Error TLV is defined as follows: 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 |M|R| TLV Type | Length | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Error-Code | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 M 1110 Mandatory, set to one (1) 1112 R 1114 Reserved, set to zero (0) 1116 TLV Type 1118 5 for Error TLV 1120 Length 1122 4 1124 Error-Code 1126 The Error-Code field is four octets. Currently defined values 1127 for Error-Code include: 1129 2001 Tunnel_Compromise_Error 1130 2002 Unexpected_TLVs_Exchanged 1132 4.2.5. Vendor-Specific TLV 1134 The Vendor-Specific TLV is available to allow vendors to support 1135 their own extended attributes not suitable for general usage. A 1136 Vendor-Specific TLV attribute can contain one or more TLVs, referred 1137 to as Vendor TLVs. The TLV-type of a Vendor-TLV is defined by the 1138 vendor. All the Vendor TLVs inside a single Vendor-Specific TLV 1139 belong to the same vendor. The can be multiple Vendor-Specific TLVs 1140 from different vendors in the same message. 1142 Vendor TLVs may be optional or mandatory. Vendor TLVs sent with 1143 Result TLVs MUST be marked as optional. 1145 The Vendor-Specific TLV is defined as follows: 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 |M|R| TLV Type | Length | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Vendor-Id | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Vendor TLVs.... 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 M 1160 0 or 1 1162 R 1164 Reserved, set to zero (0) 1166 TLV Type 1168 7 for Vendor Specific TLV 1170 Length 1172 >=4 1174 Vendor-Id 1176 The Vendor-Id field is four octets, and contains the Vendor-Id 1177 of the TLV. The high-order octet is 0 and the low-order 3 1178 octets are the SMI Network Management Private Enterprise Code 1179 of the Vendor in network byte order. 1181 Vendor TLVs 1183 This field is of indefinite length. It contains vendor- 1184 specific TLVs, in a format defined by the vendor. 1186 4.2.6. EAP-Payload TLV 1188 To allow piggybacking EAP request and response with other TLVs, the 1189 EAP-Payload TLV is defined, which includes an encapsulated EAP packet 1190 and a list of optional TLVs. The optional TLVs are provided for 1191 future extensibility to provide hints about the current EAP 1192 authentication. Only one EAP-Payload TLV is allowed in a message. 1193 The EAP-Payload TLV is defined as follows: 1195 0 1 2 3 1196 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 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 |M|R| TLV Type | Length | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | EAP packet... 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | TLVs... 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 M 1208 Mandatory, set to (1) 1210 R 1212 Reserved, set to zero (0) 1214 TLV Type 1216 9 for EAP-Payload TLV 1218 Length 1220 >=0 1222 EAP packet 1224 This field contains a complete EAP packet, including the EAP 1225 header (Code, Identifier, Length, Type) fields. The length of 1226 this field is determined by the Length field of the 1227 encapsulated EAP packet. 1229 TLVs 1231 This (optional) field contains a list of TLVs associated with 1232 the EAP packet field. The TLVs MUST NOT have the mandatory bit 1233 set. The total length of this field is equal to the Length 1234 field of the EAP-Payload TLV, minus the Length field in the EAP 1235 header of the EAP packet field. 1237 4.2.7. Intermediate-Result TLV 1239 The Intermediate-Result TLV provides support for acknowledged 1240 intermediate Success and Failure messages between multiple inner EAP 1241 methods within EAP. An Intermediate-Result TLV indicating success 1242 MUST be accompanied by a Crypto-Binding TLV. The optional TLVs 1243 associated with this TLV are provided for future extensibility to 1244 provide hints about the current result. The Intermediate-Result TLV 1245 is defined as follows: 1247 0 1 2 3 1248 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 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 |M|R| TLV Type | Length | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Status | TLVs... 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 M 1257 Mandatory, set to (1) 1259 R 1261 Reserved, set to zero (0) 1263 TLV Type 1265 10 for Intermediate-Result TLV 1267 Length 1269 >=2 1271 Status 1273 The Status field is two octets. Values include: 1275 1 Success 1276 2 Failure 1278 TLVs 1280 This (optional) field is of indeterminate length, and contains 1281 the TLVs associated with the Intermediate Result TLV. The TLVs 1282 in this field MUST NOT have the mandatory bit set. 1284 4.2.8. Crypto-Binding TLV 1286 The Crypto-Binding TLV is used to prove that both the peer and server 1287 participated in the tunnel establishment and sequence of 1288 authentications. It also provides verification of the EAP-FAST 1289 version negotiated before TLS tunnel establishment, see Section 3.1. 1291 The Crypto-Binding TLV MUST be included with Intermediate-Result TLV 1292 to perform Cryptographic Binding after each successful EAP method in 1293 a sequence of EAP methods. The Crypto-Binding TLV can be issued at 1294 other times as well. 1296 The Crypto-Binding TLV is valid only if the following checks pass: 1298 o The Crypto-Binding TLV version is supported 1299 o The MAC verifies correctly 1300 o The received version in the Crypto-Binding TLV matches the version 1301 sent by the receiver during the EAP version negotiation 1302 o The subtype is set to the correct value 1304 If any of the above checks fail then the TLV is invalid. An invalid 1305 Crypto-Binding TLV is a fatal error and is handled as described in 1306 Section 3.6.2 1308 The Crypto-Binding TLV is defined as follows: 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 |M|R| TLV Type | Length | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Reserved | Version | Received Ver. | Sub-Type | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | | 1318 ~ Nonce ~ 1319 | | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | | 1322 ~ Compound MAC ~ 1323 | | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 M 1328 Mandatory, set to (1) 1330 R 1332 Reserved, set to zero (0) 1334 TLV Type 1336 12 for Crypto-Binding TLV 1338 Length 1340 56 1342 Reserved 1344 Reserved, set to zero (0) 1346 Version 1348 The Version field is a single octet, which is set to the 1349 version of Crypto-Binding TLV the EAP method is using. For 1350 implementation compliant with this version of EAP-FAST, the 1351 version number MUST set to 1. 1353 Received Version 1355 The Received Version field is a single octet and MUST be set to 1356 the EAP version number received during version negotiation. 1357 Note that this field only provides protection against downgrade 1358 attacks where a version of EAP requiring support for this TLV 1359 is required on both sides. 1361 Sub-Type 1363 The Sub-Type field is one octet. Defined values are 1365 0 Binding Request 1366 1 Binding Response 1368 Nonce 1370 The Nonce field is 32 octets. It contains a 256 bit nonce that 1371 is temporally unique, used for compound MAC key derivation at 1372 each end. The nonce in a request MUST have its least 1373 significant bit set to 0 and the nonce in a response MUST have 1374 the same value as the request nonce except the least 1375 significant bit MUST be set to 1. 1377 Compound MAC 1379 The Compound MAC field is 20 octets. This can be the Server 1380 MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of 1381 the MAC is described in Section 5.3 1383 4.2.9. Request-Action TLV 1385 The Request-Action TLV MAY be sent by the peer along with a Result 1386 TLV in response to a server's successful Result TLV. It allows the 1387 peer to request the EAP server to negotiate additional EAP methods or 1388 process TLVs specified in the response packet. The server MAY ignore 1389 this TLV. 1391 The Request-Action TLV is defined as follows: 1393 0 1 2 3 1394 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 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 |M|R| TLV Type | Length | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Action | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 M 1403 Mandatory set to one (1) 1405 R 1407 Reserved, set to zero (0) 1409 TLV Type 1411 19 for Request-Action TLV 1413 Length 1415 2 1417 Action 1419 The Action field is two octets. Values include: 1421 1 Process-TLV 1422 2 Negotiate-EAP 1424 4.3. Table of TLVs 1426 The following table provides a guide to which TLVs may be found in 1427 which kinds of messages, and in what quantity. The messages are as 1428 follows: Request is an EAP-FAST Request, Response is an EAP-FAST 1429 Response, Success is a message containing a successful Result TLV, 1430 and Failure is a message containing a failed Result TLV. 1432 Request Response Success Failure TLVs 1433 0-1 0-1 0-1 0-1 Intermediate-Result 1434 0-1 0-1 0 0 EAP-Payload 1435 0-1 0-1 1 1 Result 1436 0-1 0-1 0-1 0-1 Crypto-Binding 1437 0+ 0+ 0+ 0+ Error 1438 0+ 0+ 0 0 NAK 1439 0+ 0+ 0+ 0+ Vendor-Specific [NOTE1] 1440 0 0-1 0-1 0-1 Request-Action 1442 [Note1] Vendor TLVs (included in Vendor-Specific TLVs) sent with a 1443 Result TLV MUST be marked as optional. 1445 The following table defines the meaning of the table entries in the 1446 sections below: 1448 0 This TLV MUST NOT be present in the message. 1450 0+ Zero or more instances of this TLV MAY be present in the message. 1452 0-1 Zero or one instance of this TLV MAY be present in the message. 1454 1 Exactly one instance of this TLV MUST be present in the message. 1456 5. Cryptographic Calculations 1458 5.1. EAP-FAST Authentication Phase 1: Key Derivations 1460 The EAP-FAST Authentication tunnel key is calculated similarly to the 1461 TLS key calculation with an additional 40 octets (referred to, as the 1462 session_key_seed) generated. The additional session_key_seed is used 1463 in the Session Key calculation in the EAP-FAST Tunneled 1464 Authentication conversation. 1466 To generate the key material required for EAP-FAST Authentication 1467 tunnel, the following construction from [RFC4346] is used: 1469 key_block = PRF(master_secret, "key expansion", 1470 server_random + client_random) 1472 where '+' denotes concatenation. 1474 The PRF function used to generate keying material is defined by 1475 [RFC4346]. 1477 For example, if the EAP-FAST Authentication employs 128bit RC4 and 1478 SHA1, the key_block is 112 octets long and is partitioned as follows: 1480 client_write_MAC_secret[20] 1481 server_write_MAC_secret[20] 1482 client_write_key[16] 1483 server_write_key[16] 1484 client_write_IV[0] 1485 server_write_IV[0] 1486 session_key_seed[40] 1488 The session_key_seed is used by the EAP-FAST Authentication Phase 2 1489 conversation to both cryptographically bind the inner method(s) to 1490 the tunnel as well as generate the resulting EAP-FAST session keys. 1491 The other quantities are used as they are defined in [RFC4346]. 1493 The master_secret is generated as specified in TLS unless a PAC is 1494 used to establish the TLS tunnel. When a PAC is used to establish 1495 the TLS tunnel, the master_secret is calculated from the specified 1496 client_random, server_random and PAC-Key as follows: 1498 master_secret = T-PRF(PAC-Key, "PAC to master secret label hash", 1499 server_random + client_random, 48) 1501 where T-PRF is described in Section 5.5. 1503 5.2. Intermediate Compound Key Derivations 1505 The session_key_seed derived as part of EAP-FAST phase 2 is used in 1506 EAP-FAST phase 2 to generate an Intermediate Compound Key (IMCK) used 1507 to verify the integrity of the TLS tunnel after each successful inner 1508 authentication and in the generation of Master Session Key (MSK) and 1509 Extended Master Session Key (EMSK) defined in [RFC3748]. Note that 1510 the IMCK must be recalculated after each successful inner EAP method. 1512 The first step in these calculations is the generation of the base 1513 compound key, IMCK[n] from the session_key_seed and any session keys 1514 derived from the successful execution of n inner EAP methods. The 1515 inner EAP method(s) may provide Master Session Keys, MSK1..MSKn, 1516 corresponding to inner methods 1 through n. The MSK is truncated at 1517 32 octets if it is longer than 32 octets or padded to a length of 32 1518 octets with zeros if it is less than 32 octets. If the ith inner 1519 method does not generate an MSK, then MSKi is set to zero (e.g. MSKi 1520 = 32 octets of 0x00s). If an inner method fails then it is not 1521 included in this calculation. The derivations of S-IMSK is as 1522 follow: 1524 S-IMCK[0] = session_key_seed 1525 For j = 1 to n-1 do 1526 IMCK[j] = T-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", 1527 MSK[j], 60) 1528 S-IMCK[j] = first 40 octets of IMCK[j] 1529 CMK[j] = last 20 octets of IMCK[j] 1531 where T-PRF is described in Section 5.5. 1533 5.3. Computing the Compound MAC 1535 For authentication methods that generate keying material, further 1536 protection against man-in-the-middle attacks is provided through 1537 cryptographically binding keying material established by both EAP- 1538 FAST Phase 1 and EAP-FAST Phase 2 conversations. After each 1539 successful inner EAP authentication, EAP MSKs are cryptographically 1540 combined with key material from EAP-FAST phase 1 to generate a 1541 compound session key, CMK. The CMK is used to calculate the Compound 1542 MAC as part of the Crypto-Binding TLV described in Section 4.2.8, 1543 which helps provide assurance that the same entities are involved all 1544 communications in EAP-FAST. During the calculation of the Compound- 1545 MAC the MAC field is filled with zeros. 1547 The Compound MAC computation is as follows: 1549 CMK = CMK[j] 1550 Compound-MAC = HMAC-SHA1( CMK, Crypto-Binding TLV ) 1552 where j is the number of the last successfully executed inner EAP 1553 method. 1555 5.4. EAP Master Session Key Generation 1557 EAP-FAST Authentication assures the master session key (MSK) and 1558 Extended Master Session Key (EMSK) output from the EAP method are the 1559 result of all authentication conversations by generating an 1560 intermediate compound session key (IMCK). The IMCK is mutually 1561 derived by the peer and the server as described in Section 5.2 by 1562 combining the MSKs from inner EAP methods with key material from EAP- 1563 FAST phase 1. The resulting MSK and EMSK are generated as part of 1564 the IMCKn key hierarchy as follows: 1566 MSK = T-PRF(S-IMCK[j], "Session Key Generating Function", 64) 1567 EMSK = T-PRF(S-IMCK[j], 1568 "Extended Session Key Generating Function", 64) 1570 where j is the number of the last successfully executed inner EAP 1571 method. 1573 The EMSK is typically only known to the EAP-FAST peer and server and 1574 is not provided to a third party. The derivation of additional keys 1575 and transportation of these keys to third party is outside the scope 1576 of this document. 1578 If no EAP methods have been negotiated inside the tunnel or no EAP 1579 methods have been successfully completed inside the tunnel, the MSK 1580 and EMSK will be generated directly from the session_key_seed meaning 1581 S-IMCK = session_key_seed. 1583 5.5. T-PRF 1585 EAP-FAST employs the following PRF prototype and definition: 1587 T-PRF = F(key, label, seed, outputlength) 1589 Where label is intended to be a unique label for each different use 1590 of the T-PRF. The outputlength parameter is a two octet value that 1591 is represented in big endian order. Also note that the seed value 1592 may be optional and may be omitted as in the case of the MSK 1593 derivation described in Section 5.4. 1595 To generate the desired outputlength octet length of key material, 1596 the T-PRF is calculated as follows: 1598 S = label + 0x00 + seed 1599 T-PRF output = T1 + T2 + T3 + ... + Tn 1600 T1 = HMAC-SHA1 (key, S + outputlength + 0x01) 1601 T2 = HMAC-SHA1 (key, T1 + S + outputlength + 0x02) 1602 T3 = HMAC-SHA1 (key, T2 + S + outputlength + 0x03) 1603 Tn = HMAC-SHA1 (key, Tn-1 + S + outputlength + 0xnn) 1605 Where '+' indicates concatenation. Each Ti generates 20-octets of 1606 keying material, the last Tn may be truncated to accommodate the 1607 desired length specified by outputlength. 1609 6. IANA Considerations 1611 This section provides guidance to the Internet Assigned Numbers 1612 Authority (IANA) regarding registration of values related to the EAP- 1613 FAST protocol, in accordance with BCP 26, [RFC2434]. 1615 EAP-FAST has already been assigned the EAP Method Type number 43. 1617 The document defines a registry for EAP-FAST TLV types, which may be 1618 assigned by Specification Required as defined in [RFC2434]. 1619 Section 4.2 defines the TLV types that initially populate the 1620 registry. A summary of the EAP-FAST TLV types is given below: 1622 0 Reserved 1623 1 Reserved 1624 2 Reserved 1625 3 Result TLV 1626 4 NAK TLV 1627 5 Error TLV 1628 7 Vendor-Specific TLV 1629 9 EAP-Payload TLV 1630 10 Intermediate-Result TLV 1631 11 PAC TLV [I-D.cam-winget-eap-fast-provisioning] 1632 12 Crypto-Binding TLV 1633 18 Server-Trusted-Root TLV [I-D.cam-winget-eap-fast-provisioning] 1634 19 Request-Action TLV 1635 20 PKCS#7 TLV [I-D.cam-winget-eap-fast-provisioning] 1637 The Error-TLV defined in section Section 4.2.4 requires an error- 1638 code. EAP-FAST Error-TLV error-codes are assigned based on 1639 specification required as defined in [RFC2434]. The initial list of 1640 error codes is as follows: 1642 2001 Tunnel_Compromise_Error 1643 2002 Unexpected_TLVs_Exchanged 1645 The Request-Action TLV defined in section Section 4.2.9 contains an 1646 action code which is assigned on a specification required basis as 1647 defined in [RFC2434]. The initial actions defined are: 1649 1 Process-TLV 1650 2 Negotiate-EAP 1652 The various values under Vendor-Specific TLV are assigned by Private 1653 Use and do not need to be assigned by IANA. 1655 7. Security Considerations 1657 EAP-FAST is designed with a focus on wireless media, where the medium 1658 itself is inherent to eavesdropping. Whereas in wired media, an 1659 attacker would have to gain physical access to the wired medium; 1660 wireless media enables anyone to capture information as it is 1661 transmitted over the air, enabling passive attacks. Thus, physical 1662 security can not be assumed and security vulnerabilities are far 1663 greater. The threat model used for the security evaluation of EAP- 1664 FAST is that defined in the EAP [RFC3748]. 1666 7.1. Mutual Authentication and Integrity Protection 1668 EAP-FAST as a whole, provides message and integrity protection by 1669 establishing a secure tunnel for protecting the authentication 1670 method(s). The confidentiality and integrity protection is that 1671 defined by TLS and provides the same security strengths afforded by 1672 TLS employing a strong entropy shared master secret. The integrity 1673 of the key generating authentication methods executed within the EAP- 1674 FAST tunnel is verified through the calculation of the Crypto-Binding 1675 TLV. This ensures that the tunnel endpoints are the same as the 1676 inner method endpoints. 1678 The Result TLV is protected and conveys the true Success or Failure 1679 of EAP-FAST and should be used as the indicator of its success or 1680 failure respectively. However, as EAP must terminate with a clear 1681 text EAP Success or Failure, a peer will also receive a clear text 1682 EAP success or failure. The received clear text EAP success or 1683 failure must match that received in the Result TLV; the peer SHOULD 1684 silently discard those clear text EAP success or failure messages 1685 that do not coincide with the status sent in the protected Result 1686 TLV. 1688 7.2. Method Negotiation 1690 As is true for any negotiated EAP protocol, NAK packets used to 1691 suggest an alternate authentication method are sent unprotected and 1692 as such, are subject to spoofing. During unprotected EAP method 1693 negotiation, NAK packets may be interjected as active attacks to 1694 negotiate down to a weaker form of authentication, such as EAP-MD5 1695 (which only provides one way authentication and does not derive a 1696 key). Both the peer and server should have a method selection policy 1697 that prevents them from negotiating down to weaker methods. Inner 1698 method negotiation resists attacks because it is protected by the 1699 mutually authenticated TLS tunnel established. Selection of EAP-FAST 1700 as an authentication method does not limit the potential inner 1701 authentication methods, so EAP-FAST should be selected when 1702 available. 1704 An attacker cannot readily determine the inner EAP method used, 1705 except perhaps by traffic analysis. It is also important that peer 1706 implementations limit the use of credentials with an unauthenticated 1707 or unauthorized server. 1709 7.3. Separation of Phase 1 and Phase 2 Servers 1711 Separation of the EAP-FAST Phase 1 from the Phase 2 conversation is 1712 not recommended. Allowing the Phase 1 conversation to be terminated 1713 at a different server than the Phase 2 conversation can introduce 1714 vulnerabilities if there is not a proper trust relationship and 1715 protection for the protocol between the two servers. Some 1716 vulnerabilities include: 1718 o Loss of identity protection 1719 o Offline dictionary attacks 1720 o Lack of policy enforcement 1722 There may be cases where a trust relationship exists between the 1723 phase 1 and phase 2 servers, such as on a campus or between two 1724 offices within the same company, where there is no danger in 1725 revealing the inner identity and credentials of the peer to entities 1726 between the two servers. In these cases, using a proxy solution 1727 without end to end protection of EAP-FAST MAY be used. The EAP-FAST 1728 encrypting/decrypting gateway SHOULD, at a minimum, provide support 1729 for IPsec or similar protection in order to provide confidentiality 1730 for the portion of the conversation between the gateway and the EAP 1731 server. 1733 7.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies 1735 EAP-FAST addresses the known deficiencies and weaknesses in the EAP 1736 method. By employing a shared secret between the peer and server to 1737 establish a secured tunnel, EAP-FAST enables: 1739 o Per packet confidentiality and integrity protection 1740 o User identity protection 1741 o Better support for notification messages 1742 o Protected EAP inner method negotiation 1743 o Sequencing of EAP methods 1744 o Strong mutually derived master session keys 1745 o Acknowledged success/failure indication 1746 o Faster re-authentications through session resumption 1747 o Mitigation of dictionary attacks 1748 o Mitigation of man-in-the-middle attacks 1749 o Mitigation of some denial of service attacks 1751 It should be noted that EAP-FAST as in many other authentication 1752 protocols, a denial of service attack can be mounted by adversaries 1753 sending erroneous traffic to disrupt the protocol. This is a problem 1754 in many authentication or key agreement protocols and is so noted for 1755 EAP-FAST as well. 1757 EAP-FAST was designed with a focus on protected authentication 1758 methods that typically rely on weak credentials, such as password 1759 based secrets. To that extent, the EAP-FAST Authentication mitigates 1760 several vulnerabilities such as dictionary attacks by protecting the 1761 weak credential based authentication method. The protection is based 1762 on strong cryptographic algorithms in TLS to provide message 1763 confidentiality and integrity respectively. The keys derived for the 1764 protection relies on strong random challenges provided by both peer 1765 and server as well as an established key with strong entropy. 1766 Implementations should follow the recommendation in [RFC4086] when 1767 generating random numbers. 1769 7.4.1. User Identity Protection and Verification 1771 The initial identity request response exchange is sent in cleartext 1772 outside the protection of EAP-FAST. Typically the NAI [RFC4282] in 1773 the identity response is useful only for the realm information which 1774 is used to route the authentication requests to the right EAP server. 1775 This means that the identity response may contain an anonymous 1776 identity and just contain realm information. In other cases the 1777 identity exchange may be eliminated all together if there other means 1778 for establishing the destination realm of the request. In no case 1779 should an intermediary place any trust in the identity information in 1780 the identity response since it is unauthenticated an may not have any 1781 relevance to the authenticated identity. EAP-FAST implementations 1782 should not attempt to compare any identity disclosed in the initial 1783 cleartext EAP Identity response packet with those Identities 1784 authenticated in Phase 2 1786 Identity request-response exchanges send after the EAP-FAST tunnel is 1787 established are protected from modification and eavesdropping by 1788 attackers. 1790 Note that since TLS client certificates are sent in the clear, if 1791 identity protection is required, then it is possible for the TLS 1792 authentication to be re-negotiated after the first server 1793 authentication. To accomplish this, the server will typically not 1794 request a certificate in the server_hello, then after the 1795 server_finished message is sent, and before EAP-FAST Phase 2, the 1796 server MAY send a TLS hello_request. This allows the client to 1797 perform client authentication by sending a client_hello if it wants 1798 to, or send a no_renegotiation alert to the server indicating that it 1799 wants to continue with EAP-FAST Phase 2 instead. Assuming that the 1800 client permits renegotiation by sending a client_hello, then the 1801 server will respond with server_hello, a certificate and 1802 certificate_request messages. The client replies with certificate, 1803 client_key_exchange and certificate_verify messages. Since this re- 1804 negotiation occurs within the encrypted TLS channel, it does not 1805 reveal client certificate details. It is possible to perform 1806 certificate authentication using an EAP method (for example: EAP-TLS) 1807 within the TLS session in EAP-FAST Phase 2 instead of using TLS 1808 handshake renegotiation. 1810 7.4.2. Dictionary Attack Resistance 1812 EAP-FAST was designed with a focus on protected authentication 1813 methods that typically rely on weak credentials, such as password 1814 based secrets. EAP-FAST mitigates dictionary attacks by allowing the 1815 establishment of a mutually authenticated encrypted TLS tunnel 1816 providing confidentiality and integrity to protect the weak 1817 credential based authentication method. 1819 7.4.3. Protection against man-in-the-middle Attacks 1821 Allowing methods to be executed both with and without the protection 1822 of a secure tunnel opens up a possibility of a man-in-the-middle 1823 attack. To avoid man-in-the-middle attacks it is recommended to 1824 always deploy authentication methods with protection of EAP-FAST. 1825 EAP-FAST provides protection from man-in-the-middle attacks even if a 1826 deployment chooses to execute inner EAP methods both with and without 1827 EAP-FAST protection, EAP-FAST prevents this attack in two ways: 1829 1. By using the PAC-Key to mutually authenticate the peer and server 1830 during EAP-FAST authentication Phase 1 establishment of a secure 1831 tunnel 1832 2. By using the keys generated by the inner authentication method 1833 (if the inner methods are key generating) in the crypto-binding 1834 exchange and in the generation of the key material exported by 1835 the EAP method described in Section 5. 1837 7.4.4. PAC binding to User Identity 1839 A PAC may be bound to a user identity. A compliant implementation of 1840 EAP-FAST MUST validate that an identity obtained in the PAC-Opaque 1841 field matches at minimum one of the identities provided in the EAP- 1842 FAST Phase 2 authentication method. This validation provides another 1843 binding to ensure that the intended peer (based on identity) has 1844 successfully completed the EAP-FAST Phase 1 and proved identity in 1845 the Phase 2 conversations. 1847 7.5. Protecting against Forged Clear Text EAP Packets 1849 EAP Success and EAP Failure packets are in general sent in clear text 1850 and may be forged by an attacker without detection. Forged EAP 1851 Failure packets can be used to attempt to convince an EAP peer to 1852 disconnect. Forged EAP Success packets may be used to attempt to 1853 convince a peer that authentication has succeeded, even though the 1854 authenticator has not authenticated itself to the peer. 1856 By providing message confidentiality and integrity, EAP-FAST provides 1857 protection against these attacks. Once the peer and AS initiate the 1858 EAP-FAST Authentication Phase 2, compliant EAP-FAST implementations 1859 must silently discard all clear text EAP messages unless both the 1860 EAP-FAST peer and server have indicated success or failure using a 1861 protected mechanism. Protected mechanisms include TLS alert 1862 mechanism and the protected termination mechanism described in 1863 Section 3.3.2. 1865 The success/failure decisions within the EAP-FAST tunnel indicate the 1866 final decision of the EAP-FAST authentication conversation. After a 1867 success/failure result has been indicated by a protected mechanism, 1868 the EAP-FAST peer can process unprotected EAP success and EAP failure 1869 message; however the peer MUST ignore any unprotected EAP success or 1870 failure messages where the result does not match the result of the 1871 protected mechanism. 1873 To abide by [RFC3748], the server must send a clear text EAP Success 1874 or EAP Failure packet to terminate the EAP conversation. However, 1875 since EAP Success and EAP Failure packets are not retransmitted, the 1876 final packet may be lost. While an EAP-FAST protected EAP Success or 1877 EAP Failure packet should not be a final packet in an EAP-FAST 1878 conversation, it may occur based on the conditions stated above so an 1879 EAP peer should not rely upon the unprotected EAP success and failure 1880 messages. 1882 7.6. Server Certificate Validation 1884 As part of the TLS negotiation, the server presents a certificate to 1885 the peer. The peer MUST verify the validity of the EAP server 1886 certificate, and SHOULD also examine the EAP server name presented in 1887 the certificate, in order to determine whether the EAP server can be 1888 trusted. Please note that in the case where the EAP authentication 1889 is remoted, the EAP server will not reside on the same machine as the 1890 authenticator, and therefore the name in the EAP server's certificate 1891 cannot be expected to match that of the intended destination. In 1892 this case, a more appropriate test might be whether the EAP server's 1893 certificate is signed by a CA controlling the intended domain and 1894 whether the authenticator can be authorized by a server in that 1895 domain. 1897 7.7. Tunnel PAC Considerations 1899 Since the Tunnel PAC is stored by the peer, special care should be 1900 given to the overall security of the peer. The Tunnel PAC must be 1901 securely stored by the peer to prevent theft or forgery of any of the 1902 Tunnel PAC components. 1904 In particular, the peer must securely store the PAC-Key and protect 1905 it from disclosure or modification. Disclosure of the PAC-Key 1906 enables an attacker to establish the EAP-FAST tunnel; however, 1907 disclosure of the PAC-Key does not reveal the peer or server identity 1908 or compromise any other peer's PAC credentials. Modification of the 1909 PAC-Key or PAC-Opaque components of the Tunnel PAC may also lead to 1910 denial of service as the tunnel establishment will fail. 1912 The PAC-Opaque component is the effective TLS ticket extension used 1913 to establish the tunnel using the techniques of [RFC4507]. Thus, the 1914 security considerations defined by [RFC4507] also apply to the PAC- 1915 Opaque. 1917 The PAC-Info may contain information about the Tunnel PAC such as the 1918 identity of the PAC issuer and the Tunnel PAC lifetime for use in the 1919 management of the Tunnel PAC. The PAC-Info should be securely stored 1920 by the peer to protect it from disclosure and modification. 1922 7.8. Security Claims 1924 This section provides needed security claim requirement for EAP 1925 [RFC3748]. 1927 Auth. mechanism: Certificate based, shared secret based and 1928 various tunneled authentication mechanisms. 1929 Ciphersuite negotiation: Yes 1930 Mutual authentication: Yes 1931 Integrity protection: Yes, Any method executed within the EAP-FAST 1932 tunnel is integrity protected. The 1933 cleartext EAP headers outside the tunnel are 1934 not integrity protected. 1935 Replay protection: Yes 1936 Confidentiality: Yes 1937 Key derivation: Yes 1938 Key strength: [1] 1939 Dictionary attack prot.: Yes 1940 Fast reconnect: Yes 1941 Cryptographic binding: Yes 1942 Session independence: Yes 1943 Fragmentation: Yes 1944 Key Hierarchy: Yes 1945 Channel binding: No, but TLVs could be defined for this. 1947 Notes 1949 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The 1950 National Institute for Standards and Technology (NIST) also 1951 offers advice on appropriate key sizes in [SP800-57]. [RFC3766] 1952 Section 5 advises use of the following required RSA or DH module 1953 and DSA subgroup size in bits, for a given level of attack 1954 resistance in bits. Based on the table below, a 2048-bit RSA key 1955 is required to provide 128-bit equivalent key strength: 1957 Attack Resistance RSA or DH Modulus DSA subgroup 1958 (bits) size (bits) size (bits) 1959 ----------------- ----------------- ------------ 1960 70 947 129 1961 80 1228 148 1962 90 1553 167 1963 100 1926 186 1964 150 4575 284 1965 200 8719 383 1966 250 14596 482 1968 8. Acknowledgements 1970 The EAP-FAST design and protocol specification is based on the ideas 1971 and hard efforts of Pad Jakkahalli, Mark Krischer, Doug Smith, and 1972 Glen Zorn of Cisco Systems, Inc. 1974 The TLV processing was inspired from work on PEAPv2 with Ashwin 1975 Palekar, Dan Smith and Simon Josefsson. Helpful review comments were 1976 provided by Russ Housley, Jari Arkko, Ilan Frenkel and Jeremy 1977 Steiglitz. 1979 9. References 1981 9.1. Normative References 1983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1984 Requirement Levels", BCP 14, RFC 2119, March 1997. 1986 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1987 RFC 2246, January 1999. 1989 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1990 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1991 October 1998. 1993 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 1994 Ciphersuites for Transport Layer Security (TLS)", 1995 RFC 3268, June 2002. 1997 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1998 Levkowetz, "Extensible Authentication Protocol (EAP)", 1999 RFC 3748, June 2004. 2001 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2002 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2004 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2005 "Transport Layer Security (TLS) Session Resumption without 2006 Server-Side State", RFC 4507, May 2006. 2008 9.2. Informative References 2010 [I-D.cam-winget-eap-fast-provisioning] 2011 Cam-Winget, N., "Dynamic Provisioning using EAP-FAST", 2012 draft-cam-winget-eap-fast-provisioning-03 (work in 2013 progress), January 2007. 2015 [IEEE.802-1X.2004] 2016 "Local and Metropolitan Area Networks: Port-Based Network 2017 Access Control", IEEE Standard 802.1X, December 2004. 2019 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2020 Protocol", RFC 2716, October 1999. 2022 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2023 X.509 Public Key Infrastructure Certificate and 2024 Certificate Revocation List (CRL) Profile", RFC 3280, 2025 April 2002. 2027 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2028 Dial In User Service) Support For Extensible 2029 Authentication Protocol (EAP)", RFC 3579, September 2003. 2031 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 2032 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 2033 RFC 3766, April 2004. 2035 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 2036 Authentication Protocol (EAP) Application", RFC 4072, 2037 August 2005. 2039 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2040 Requirements for Security", BCP 106, RFC 4086, June 2005. 2042 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 2043 Network Access Identifier", RFC 4282, December 2005. 2045 [SP800-57] 2046 "National Institute of Standards and Technology, 2047 "Recommendation for Key Management", Special Publication 2048 800-57", IEEE Standard 802.1X, May 2006. 2050 Appendix A. Examples 2052 A.1. Successful Authentication 2054 The following exchanges show a successful EAP-FAST authentication 2055 with optional PAC refreshment, the conversation will appear as 2056 follows: 2058 Authenticating Peer Authenticator 2059 ------------------- ------------- 2060 <- EAP-Request/ 2061 Identity 2062 EAP-Response/ 2063 Identity (MyID1) -> 2065 <- EAP-Request/ 2066 EAP-Type=EAP-FAST, V=1 2067 (EAP-FAST Start, S bit set, A-ID) 2069 EAP-Response/ 2070 EAP-Type=EAP-FAST, V=1 2071 (TLS client_hello with 2072 PAC-Opaque in SessionTicket extension)-> 2074 <- EAP-Request/ 2075 EAP-Type=EAP-FAST, V=1 2076 (TLS server_hello, 2077 (TLS change_cipher_spec, 2078 TLS finished) 2080 EAP-Response/ 2081 EAP-Type=EAP-FAST, V=1 -> 2082 (TLS change_cipher_spec, 2083 TLS finished) 2085 TLS channel established 2086 (messages sent within the TLS channel) 2088 <- EAP Payload TLV, EAP-Request, 2089 EAP-GTC, Challenge 2091 EAP Payload TLV, EAP-Response, 2092 EAP-GTC, Response with both 2093 user name and password) -> 2095 optional additional exchanges (new pin mode, 2096 password change etc.) ... 2098 <- Intermediate-Result TLV (Success) 2099 Crypto-Binding TLV (Request) 2101 Intermediate-Result TLV (Success) 2102 Crypto-Binding TLV(Response) -> 2104 <- Result TLV (Success) 2105 (Optional PAC TLV) 2107 Result TLV (Success) 2108 (PAC TLV Acknowledgment) -> 2110 TLS channel torn down 2111 (messages sent in clear text) 2113 <- EAP-Success 2115 A.2. Failed Authentication 2117 The following exchanges show a failed EAP-FAST authentication due to 2118 wrong user credentials, the conversation will appear as follows: 2120 Authenticating Peer Authenticator 2121 ------------------- ------------- 2122 <- EAP-Request/ 2123 Identity 2125 EAP-Response/ 2126 Identity (MyID1) -> 2127 <- EAP-Request/ 2128 EAP-Type=EAP-FAST, V=1 2129 (EAP-FAST Start, S bit set, A-ID) 2131 EAP-Response/ 2132 EAP-Type=EAP-FAST, V=1 2133 (TLS client_hello with 2134 PAC-Opaque in SessionTicket extension)-> 2136 <- EAP-Request/ 2137 EAP-Type=EAP-FAST, V=1 2138 (TLS server_hello, 2139 (TLS change_cipher_spec, 2140 TLS finished) 2142 EAP-Response/ 2143 EAP-Type=EAP-FAST, V=1 -> 2144 (TLS change_cipher_spec, 2145 TLS finished) 2147 TLS channel established 2148 (messages sent within the TLS channel) 2150 <- EAP Payload TLV, EAP-Request, 2151 EAP-GTC, Challenge 2153 EAP Payload TLV, EAP-Response, 2154 EAP-GTC, Response with both 2155 user name and password) -> 2157 <- EAP Payload TLV, EAP-Request, 2158 EAP-GTC, error message 2160 EAP Payload TLV, EAP-Response, 2161 EAP-GTC, empty data packet to 2162 acknowledge unrecoverable error) -> 2164 <- Result TLV (Failure) 2166 Result TLV (Failure) -> 2168 TLS channel torn down 2169 (messages sent in clear text) 2171 <- EAP-Failure 2173 A.3. Full TLS Handshake using Certificate-based Cipher Suite 2175 In the case where an abbreviated TLS handshake is tried and failed 2176 and falls back to certificate based full TLS handshake occurs within 2177 EAP-FAST Phase 1, the conversation will appear as follows: 2179 Authenticating Peer Authenticator 2180 ------------------- ------------- 2181 <- EAP-Request/Identity 2182 EAP-Response/ 2183 Identity (MyID1) -> 2185 // Identity sent in the clear. May be a hint to help route 2186 the authentication request to EAP server, instead of the 2187 full user identity. 2189 <- EAP-Request/ 2190 EAP-Type=EAP-FAST, V=1 2191 (EAP-FAST Start, S bit set, A-ID) 2192 EAP-Response/ 2193 EAP-Type=EAP-FAST, V=1 2194 (TLS client_hello 2195 [PAC-Opaque extension])-> 2197 // Peer sends PAC-Opaque of Tunnel PAC along with a list of 2198 ciphersuites supported. If Server rejects the PAC- 2199 Opaque, if falls through to the full TLS handshake 2201 <- EAP-Request/ 2202 EAP-Type=EAP-FAST, V=1 2203 (TLS server_hello, 2204 TLS certificate, 2205 [TLS server_key_exchange,] 2206 [TLS certificate_request,] 2207 TLS server_hello_done) 2208 EAP-Response/ 2209 EAP-Type=EAP-FAST, V=1 2210 ([TLS certificate,] 2211 TLS client_key_exchange, 2212 [TLS certificate_verify,] 2213 TLS change_cipher_spec, 2214 TLS finished) -> 2215 <- EAP-Request/ 2216 EAP-Type=EAP-FAST, V=1 2217 (TLS change_cipher_spec, 2218 TLS finished, 2219 EAP-Payload-TLV[EAP-Request/ 2220 Identity]) 2222 // TLS channel established 2223 (messages sent within the TLS channel) 2225 // First EAP Payload TLV is piggybacked to the TLS Finished as 2226 Application Data and protected by the TLS tunnel 2228 EAP-Payload-TLV 2229 [EAP-Response/Identity (MyID2)]-> 2231 // identity protected by TLS. 2233 <- EAP-Payload-TLV 2234 [EAP-Request/EAP-Type=X] 2236 EAP-Payload-TLV 2237 [EAP-Response/EAP-Type=X] -> 2239 // Method X exchanges followed by Protected Termination 2241 <- Crypto-Binding TLV (Version=1, 2242 EAP-FAST Version=1, Nonce, 2243 CompoundMAC), 2244 Result TLV (Success) 2246 Crypto-Binding TLV (Version=1, 2247 EAP-FAST Version=1, Nonce, 2248 CompoundMAC), 2249 Result-TLV (Success) -> 2251 // TLS channel torn down 2252 (messages sent in clear text) 2254 <- EAP-Success 2256 A.4. Client authentication during Phase 1 with identity privacy 2258 In the case where a certificate based TLS handshake occurs within 2259 EAP-FAST Phase 1, and client certificate authentication and identity 2260 privacy is desired, the conversation will appear as follows: 2262 Authenticating Peer Authenticator 2263 ------------------- ------------- 2264 <- EAP-Request/Identity 2265 EAP-Response/ 2266 Identity (MyID1) -> 2268 // Identity sent in the clear. May be a hint to help route 2269 the authentication request to EAP server, instead of the 2270 full user identity. 2272 <- EAP-Request/ 2273 EAP-Type=EAP-FAST, V=1 2274 (EAP-FAST Start, S bit set, A-ID) 2275 EAP-Response/ 2276 EAP-Type=EAP-FAST, V=1 2277 (TLS client_hello)-> 2278 <- EAP-Request/ 2279 EAP-Type=EAP-FAST, V=1 2280 (TLS server_hello, 2281 TLS certificate, 2282 [TLS server_key_exchange,] 2283 [TLS certificate_request,] 2284 TLS server_hello_done) 2285 EAP-Response/ 2286 EAP-Type=EAP-FAST, V=1 2287 (TLS client_key_exchange, 2288 TLS change_cipher_spec, 2289 TLS finished) -> 2290 <- EAP-Request/ 2291 EAP-Type=EAP-FAST, V=1 2292 (TLS change_cipher_spec, 2293 TLS finished,TLS Hello-Request) 2295 // TLS channel established 2296 (messages sent within the TLS channel) 2298 // TLS Hello-Request is piggybacked to the TLS Finished as 2299 Handshake Data and protected by the TLS tunnel 2301 TLS client_hello -> 2303 <- TLS server_hello, 2304 TLS certificate, 2305 [TLS server_key_exchange,] 2306 [TLS certificate_request,] 2307 TLS server_hello_done 2308 [TLS certificate,] 2309 TLS client_key_exchange, 2310 [TLS certificate_verify,] 2311 TLS change_cipher_spec, 2312 TLS finished -> 2314 <- TLS change_cipher_spec, 2315 TLS finished, 2316 Result TLV (Success) 2318 Result-TLV (Success)) -> 2320 //TLS channel torn down 2321 (messages sent in clear text) 2323 <- EAP-Success 2325 A.5. Fragmentation and Reassembly 2327 In the case where EAP-FAST fragmentation is required, the 2328 conversation will appear as follows: 2330 Authenticating Peer Authenticator 2331 ------------------- ------------- 2332 <- EAP-Request/ 2333 Identity 2334 EAP-Response/ 2335 Identity (MyID) -> 2336 <- EAP-Request/ 2337 EAP-Type=EAP-FAST, V=1 2338 (EAP-FAST Start, S bit set, A-ID) 2340 EAP-Response/ 2341 EAP-Type=EAP-FAST, V=1 2342 (TLS client_hello)-> 2343 <- EAP-Request/ 2344 EAP-Type=EAP-FAST, V=1 2345 (TLS server_hello, 2346 TLS certificate, 2347 [TLS server_key_exchange,] 2348 [TLS certificate_request,] 2349 TLS server_hello_done) 2350 (Fragment 1: L, M bits set) 2352 EAP-Response/ 2353 EAP-Type=EAP-FAST, V=1 -> 2355 <- EAP-Request/ 2356 EAP-Type=EAP-FAST, V=1 2357 (Fragment 2: M bit set) 2358 EAP-Response/ 2359 EAP-Type=EAP-FAST, V=1 -> 2360 <- EAP-Request/ 2361 EAP-Type=EAP-FAST, V=1 2362 (Fragment 3) 2363 EAP-Response/ 2364 EAP-Type=EAP-FAST, V=1 2365 ([TLS certificate,] 2366 TLS client_key_exchange, 2367 [TLS certificate_verify,] 2368 TLS change_cipher_spec, 2369 TLS finished) 2370 (Fragment 1: L, M bits set)-> 2372 <- EAP-Request/ 2373 EAP-Type=EAP-FAST, V=1 2374 EAP-Response/ 2375 EAP-Type=EAP-FAST, V=1 2376 (Fragment 2)-> 2377 <- EAP-Request/ 2378 EAP-Type=EAP-FAST, V=1 2379 (TLS change_cipher_spec, 2380 TLS finished, 2381 [EAP-Payload-TLV[ 2382 EAP-Request/Identity]]) 2384 // TLS channel established 2385 (messages sent within the TLS channel) 2387 // First EAP Payload TLV is piggybacked to the TLS Finished as 2388 Application Data and protected by the TLS tunnel 2390 EAP-Payload-TLV 2391 [EAP-Response/Identity (MyID2)]-> 2393 // identity protected by TLS. 2395 <- EAP-Payload-TLV 2396 [EAP-Request/EAP-Type=X] 2398 EAP-Payload-TLV 2399 [EAP-Response/EAP-Type=X] -> 2401 // Method X exchanges followed by Protected Termination 2403 <- Crypto-Binding TLV (Version=1, 2404 EAP-FAST Version=1, Nonce, 2405 CompoundMAC), 2406 Result TLV (Success) 2408 Crypto-Binding TLV (Version=1, 2409 EAP-FAST Version=1, Nonce, 2410 CompoundMAC), 2411 Result-TLV (Success) -> 2412 // TLS channel torn down 2413 (messages sent in clear text) 2415 <- EAP-Success 2417 A.6. Sequence of EAP Methods 2419 Where EAP-FAST is negotiated, with a sequence of EAP method X 2420 followed by method Y, the conversation will occur as follows: 2422 Authenticating Peer Authenticator 2423 ------------------- ------------- 2424 <- EAP-Request/ 2425 Identity 2426 EAP-Response/ 2427 Identity (MyID1) -> 2428 <- EAP-Request/ 2429 EAP-Type=EAP-FAST, V=1 2430 (EAP-FAST Start, S bit set, A-ID) 2432 EAP-Response/ 2433 EAP-Type=EAP-FAST, V=1 2434 (TLS client_hello)-> 2435 <- EAP-Request/ 2436 EAP-Type=EAP-FAST, V=1 2437 (TLS server_hello, 2438 TLS certificate, 2439 [TLS server_key_exchange,] 2440 [TLS certificate_request,] 2441 TLS server_hello_done) 2442 EAP-Response/ 2443 EAP-Type=EAP-FAST, V=1 2444 ([TLS certificate,] 2445 TLS client_key_exchange, 2446 [TLS certificate_verify,] 2447 TLS change_cipher_spec, 2448 TLS finished) -> 2449 <- EAP-Request/ 2450 EAP-Type=EAP-FAST, V=1 2451 (TLS change_cipher_spec, 2452 TLS finished, 2453 EAP-Payload-TLV[ 2454 EAP-Request/Identity]) 2456 // TLS channel established 2457 (messages sent within the TLS channel) 2459 // First EAP Payload TLV is piggybacked to the TLS Finished as 2460 Application Data and protected by the TLS tunnel 2462 EAP-Payload-TLV 2463 [EAP-Response/Identity] -> 2465 <- EAP-Payload-TLV 2466 [EAP-Request/EAP-Type=X] 2468 EAP-Payload-TLV 2469 [EAP-Response/EAP-Type=X] -> 2471 // Optional additional X Method exchanges... 2473 <- EAP-Payload-TLV 2474 [EAP-Request/EAP-Type=X] 2476 EAP-Payload-TLV 2477 [EAP-Response/EAP-Type=X]-> 2479 <- Intermediate Result TLV (Success), 2480 Crypto-Binding TLV (Version=1 2481 EAP-FAST Version=1, Nonce, 2482 CompoundMAC), 2483 EAP Payload TLV [EAP-Type=Y], 2485 // Next EAP conversation started after successful completion 2486 of previous method X. The Intermediate-Result and Crypto- 2487 Binding TLVs are sent in next packet to minimize round- 2488 trips. In this example, identity request is not sent 2489 before negotiating EAP-Type=Y. 2491 // Compound MAC calculated using Keys generated from 2492 EAP methods X and the TLS tunnel. 2494 Intermediate Result TLV (Success), 2495 Crypto-Binding TLV (Version=1, 2496 EAP-FAST Version=1, Nonce, 2497 CompoundMAC), 2498 EAP-Payload-TLV [EAP-Type=Y] -> 2500 // Optional additional Y Method exchanges... 2502 <- EAP Payload TLV [ 2503 EAP-Type=Y] 2505 EAP Payload TLV 2506 [EAP-Type=Y] -> 2507 <- Intermediate-Result-TLV (Success), 2508 Crypto-Binding TLV (Version=1 2509 EAP-FAST Version=1, Nonce, 2510 CompoundMAC), 2511 Result TLV (Success) 2513 Intermediate-Result-TLV (Success), 2514 Crypto-Binding TLV (Version=1, 2515 EAP-FAST Version=1, Nonce, 2516 CompoundMAC), 2517 Result-TLV (Success) -> 2519 // Compound MAC calculated using Keys generated from EAP 2520 methods X and Y and the TLS tunnel. Compound Keys 2521 generated using Keys generated from EAP methods X and Y; 2522 and the TLS tunnel. 2524 // TLS channel torn down (messages sent in clear text) 2526 <- EAP-Success 2528 A.7. Failed Crypto-binding 2530 The following exchanges show a failed crypto-binding validation. The 2531 conversation will appear as follows: 2533 Authenticating Peer Authenticator 2534 ------------------- ------------- 2535 <- EAP-Request/ 2536 Identity 2537 EAP-Response/ 2538 Identity (MyID1) -> 2539 <- EAP-Request/ 2540 EAP-Type=EAP-FAST, V=1 2541 (EAP-FAST Start, S bit set, A-ID) 2543 EAP-Response/ 2544 EAP-Type=EAP-FAST, V=1 2545 (TLS client_hello without 2546 PAC-Opaque extension)-> 2547 <- EAP-Request/ 2548 EAP-Type=EAP-FAST, V=1 2549 (TLS Server Key Exchange 2550 TLS Server Hello Done) 2551 EAP-Response/ 2552 EAP-Type=EAP-FAST, V=1 -> 2553 (TLS Client Key Exchange 2554 TLS change_cipher_spec, 2555 TLS finished) 2557 <- EAP-Request/ 2558 EAP-Type=EAP-FAST, V=1 2559 (TLS change_cipher_spec 2560 TLS finished) 2561 EAP-Payload-TLV[ 2562 EAP-Request/Identity]) 2564 // TLS channel established 2565 (messages sent within the TLS channel) 2567 // First EAP Payload TLV is piggybacked to the TLS Finished as 2568 Application Data and protected by the TLS tunnel 2570 EAP-Payload TLV/ 2571 EAP Identity Response -> 2573 <- EAP Payload TLV, EAP-Request, 2574 (EAP-MSCHAPV2, Challenge) 2576 EAP Payload TLV, EAP-Response, 2577 (EAP-MSCHAPV2, Response) -> 2579 <- EAP Payload TLV, EAP-Request, 2580 (EAP-MSCHAPV2, Success Request) 2582 EAP Payload TLV, EAP-Response, 2583 (EAP-MSCHAPV2, Success Response) -> 2585 <- Crypto-Binding TLV (Version=1, 2586 EAP-FAST Version=1, Nonce, 2587 CompoundMAC), 2588 Result TLV (Success) 2590 Result TLV (Failure) 2591 Error TLV with 2592 (Error Code = 2001) -> 2594 // TLS channel torn down 2595 (messages sent in clear text) 2597 <- EAP-Failure 2599 A.8. Sequence of EAP Method with Vendor-Specific TLV Exchange 2601 Where EAP-FAST is negotiated, with a sequence of EAP method followed 2602 by Vendor-Specific TLV exchange, the conversation will occur as 2603 follows: 2605 Authenticating Peer Authenticator 2606 ------------------- ------------- 2607 <- EAP-Request/ 2608 Identity 2609 EAP-Response/ 2610 Identity (MyID1) -> 2611 <- EAP-Request/ 2612 EAP-Type=EAP-FAST, V=1 2613 (EAP-FAST Start, S bit set, A-ID) 2615 EAP-Response/ 2616 EAP-Type=EAP-FAST, V=1 2617 (TLS client_hello)-> 2618 <- EAP-Request/ 2619 EAP-Type=EAP-FAST, V=1 2620 (TLS server_hello, 2621 TLS certificate, 2622 [TLS server_key_exchange,] 2623 [TLS certificate_request,] 2624 TLS server_hello_done) 2626 EAP-Response/ 2627 EAP-Type=EAP-FAST, V=1 2628 ([TLS certificate,] 2629 TLS client_key_exchange, 2630 [TLS certificate_verify,] 2631 TLS change_cipher_spec, 2632 TLS finished) -> 2633 <- EAP-Request/ 2634 EAP-Type=EAP-FAST, V=1 2635 (TLS change_cipher_spec, 2636 TLS finished, 2637 EAP-Payload-TLV[ 2638 EAP-Request/Identity]) 2640 // TLS channel established 2641 (messages sent within the TLS channel) 2643 // First EAP Payload TLV is piggybacked to the TLS Finished as 2644 Application Data and protected by the TLS tunnel 2646 EAP-Payload-TLV 2648 [EAP-Response/Identity] -> 2650 <- EAP-Payload-TLV 2651 [EAP-Request/EAP-Type=X] 2653 EAP-Payload-TLV 2654 [EAP-Response/EAP-Type=X] -> 2656 <- EAP-Payload-TLV 2657 [EAP-Request/EAP-Type=X] 2659 EAP-Payload-TLV 2660 [EAP-Response/EAP-Type=X]-> 2662 <- Intermediate Result TLV (Success), 2663 Crypto-Binding TLV (Version=1 2664 EAP-FAST Version=1, Nonce, 2665 CompoundMAC), 2666 Vendor-Specific TLV, 2668 // Vendor Specific TLV exchange started after successful 2669 completion of previous method X. The Intermediate-Result 2670 and Crypto-Binding TLVs are sent with Vendor Specific TLV 2671 in next packet to minimize round-trips. 2673 // Compound MAC calculated using Keys generated from 2674 EAP methods X and the TLS tunnel. 2676 Intermediate Result TLV (Success), 2677 Crypto-Binding TLV (Version=1, 2678 EAP-FAST Version=1, Nonce, 2679 CompoundMAC), 2680 Vendor-Specific TLV -> 2682 // Optional additional Vendor-Specific TLV exchanges... 2684 <- Vendor-Specific TLV 2686 Vendor Specific TLV -> 2687 <- Result TLV (Success) 2689 Result-TLV (Success) -> 2691 // TLS channel torn down (messages sent in clear text) 2693 <- EAP-Success 2695 Appendix B. Test Vectors 2697 B.1. Key Derivation 2699 PAC KEY: 2701 0B 97 39 0F 37 51 78 09 81 1E FD 9C 6E 65 94 2B 2702 63 2C E9 53 89 38 08 BA 36 0B 03 7C D1 85 E4 14 2704 Server_hello Random 2706 3F FB 11 C4 6C BF A5 7A 54 40 DA E8 22 D3 11 D3 2707 F7 6D E4 1D D9 33 E5 93 70 97 EB A9 B3 66 F4 2A 2709 Client_hello Random 2711 00 00 00 02 6A 66 43 2A 8D 14 43 2C EC 58 2D 2F 2712 C7 9C 33 64 BA 04 AD 3A 52 54 D6 A5 79 AD 1E 00 2714 Master_secret = T-PRF(PAC-Key, 2715 "PAC to master secret label hash", 2716 server_random + Client_random, 2717 48) 2719 4A 1A 51 2C 01 60 BC 02 3C CF BC 83 3F 03 BC 64 2720 88 C1 31 2F 0B A9 A2 77 16 A8 D8 E8 BD C9 D2 29 2721 38 4B 7A 85 BE 16 4D 27 33 D5 24 79 87 B1 C5 A2 2723 Key_block = PRF(Master_secret, 2724 "key expansion", 2725 server_random + Client_random) 2727 59 59 BE 8E 41 3A 77 74 8B B2 E5 D3 60 AC 4D 35 2728 DF FB C8 1E 9C 24 9C 8B 0E C3 1D 72 C8 84 9D 57 2729 48 51 2E 45 97 6C 88 70 BE 5F 01 D3 64 E7 4C BB 2730 11 24 E3 49 E2 3B CD EF 7A B3 05 39 5D 64 8A 44 2731 11 B6 69 88 34 2E 8E 29 D6 4B 7D 72 17 59 28 05 2732 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 2733 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71 2735 Session Key Seed 2737 D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 2738 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 2739 FF 92 A8 B4 C6 42 28 71 2740 IMCK = T-PRF(SKS, 2741 "Inner Methods Compound Keys", 2742 ISK, 2743 60) 2745 Note: ISK is 32 octets 0's. 2747 16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80 2748 4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1 2749 18 40 7B 56 BE EA A7 C5 76 5D 8F 0B C5 07 C6 B9 2750 04 D0 69 56 72 8B 6B B8 15 EC 57 7B 2752 [SIMCK 1] 2753 16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80 2754 4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1 2755 18 40 7B 56 BE EA A7 C5 2757 MSK = T-PRF(S-IMCKn, 2758 "Session Key Generating Function", 2759 64); 2761 4D 83 A9 BE 6F 8A 74 ED 6A 02 66 0A 63 4D 2C 33 2762 C2 DA 60 15 C6 37 04 51 90 38 63 DA 54 3E 14 B9 2763 27 99 18 1E 07 BF 0F 5A 5E 3C 32 93 80 8C 6C 49 2764 67 ED 24 FE 45 40 A0 59 5E 37 C2 E9 D0 5D 0A E3 2766 EMSK = T-PRF(S-IMCKn, 2767 "Extended Session Key Generating Function", 2768 64); 2770 3A D4 AB DB 76 B2 7F 3B EA 32 2C 2B 74 F4 28 55 2771 EF 2D BA 78 C9 57 2F 0D 06 CD 51 7C 20 93 98 A9 2772 76 EA 70 21 D7 0E 25 54 97 ED B2 8A F6 ED FD 0A 2773 2A E7 A1 58 90 10 50 44 B3 82 85 DB 06 14 D2 F9 2775 B.2. Crypto-Binding MIC 2777 [Compound MAC Key 1] 2778 76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8 2779 15 EC 57 7B 2781 [Crypto-Binding TLV] 2782 80 0C 00 38 00 01 01 00 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 2783 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 43 24 6E 30 2784 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7 2786 [Server Nonce] 2787 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 2788 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 2790 [Compound MAC] 2791 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 2792 05 C5 5B B7 2794 Authors' Addresses 2796 Nancy Cam-Winget 2797 Cisco Systems 2798 3625 Cisco Way 2799 San Jose, CA 95134 2800 US 2802 Email: ncamwing@cisco.com 2804 David McGrew 2805 Cisco Systems 2806 San Jose, CA 95134 2807 US 2809 Email: mcgrew@cisco.com 2811 Joseph Salowey 2812 Cisco Systems 2813 2901 3rd Ave 2814 Seattle, WA 98121 2815 US 2817 Email: jsalowey@cisco.com 2818 Hao Zhou 2819 Cisco Systems 2820 4125 Highlander Parkway 2821 Richfield, OH 44286 2822 US 2824 Email: hzhou@cisco.com 2826 Full Copyright Statement 2828 Copyright (C) The Internet Society (2007). 2830 This document is subject to the rights, licenses and restrictions 2831 contained in BCP 78, and except as set forth therein, the authors 2832 retain all their rights. 2834 This document and the information contained herein are provided on an 2835 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2836 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2837 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2838 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2839 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2840 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2842 Intellectual Property 2844 The IETF takes no position regarding the validity or scope of any 2845 Intellectual Property Rights or other rights that might be claimed to 2846 pertain to the implementation or use of the technology described in 2847 this document or the extent to which any license under such rights 2848 might or might not be available; nor does it represent that it has 2849 made any independent effort to identify any such rights. Information 2850 on the procedures with respect to rights in RFC documents can be 2851 found in BCP 78 and BCP 79. 2853 Copies of IPR disclosures made to the IETF Secretariat and any 2854 assurances of licenses to be made available, or the result of an 2855 attempt made to obtain a general license or permission for the use of 2856 such proprietary rights by implementers or users of this 2857 specification can be obtained from the IETF on-line IPR repository at 2858 http://www.ietf.org/ipr. 2860 The IETF invites any interested party to bring to its attention any 2861 copyrights, patents or patent applications, or other proprietary 2862 rights that may cover technology that may be required to implement 2863 this standard. Please address the information to the IETF at 2864 ietf-ipr@ietf.org. 2866 Acknowledgment 2868 Funding for the RFC Editor function is provided by the IETF 2869 Administrative Support Activity (IASA).