idnits 2.17.1 draft-cam-winget-eap-fast-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2642. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2660), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' IANA Considerations Section in RFCs", RFC 2434, October' ) ** The document seems to lack an Authors' Addresses Section. 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 (April 25, 2005) is 6939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'PEAP' on line 2302 looks like a reference -- Missing reference section? 'EAP-TTLS' on line 2325 looks like a reference -- Missing reference section? 'TLS-PSK' on line 2330 looks like a reference -- Missing reference section? 'TICKET' on line 2269 looks like a reference -- Missing reference section? 'RFC2119' on line 2261 looks like a reference -- Missing reference section? 'EAP' on line 2253 looks like a reference -- Missing reference section? 'IEEE-802.1x' on line 230 looks like a reference -- Missing reference section? 'RFC2548' on line 2321 looks like a reference -- Missing reference section? 'RFC3546' on line 2265 looks like a reference -- Missing reference section? 'RFC 2246' on line 1816 looks like a reference -- Missing reference section? 'RFC 2716' on line 2289 looks like a reference -- Missing reference section? '0' on line 723 looks like a reference -- Missing reference section? '2' on line 1015 looks like a reference -- Missing reference section? 'RFC1990' on line 1028 looks like a reference -- Missing reference section? 'IEEE80211' on line 1030 looks like a reference -- Missing reference section? 'RFC2486' on line 1911 looks like a reference -- Missing reference section? 'RFC3162' on line 1923 looks like a reference -- Missing reference section? 'MITM' on line 2311 looks like a reference -- Missing reference section? 'RFC2246' on line 2249 looks like a reference -- Missing reference section? 'RFC2716' on line 2231 looks like a reference -- Missing reference section? 'RFC2434' on line 2276 looks like a reference -- Missing reference section? 'RFC3268' on line 2257 looks like a reference -- Missing reference section? 'RFC2279' on line 2281 looks like a reference -- Missing reference section? 'RFC2631' on line 2285 looks like a reference -- Missing reference section? 'IKEv2' on line 2297 looks like a reference -- Missing reference section? 'RFC3526' on line 2307 looks like a reference -- Missing reference section? 'RFC2486BIS' on line 2316 looks like a reference -- Missing reference section? 'SIMCK 1' on line 2587 looks like a reference -- Missing reference section? 'Crypto-Binding TLV' on line 2607 looks like a reference -- Missing reference section? 'Compound MAC' on line 2616 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 37 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group N. Cam-Winget 2 Internet-Draft D. McGrew 3 Category: Informational J. Salowey 4 Expires: October 25, 2005 H. Zhou 5 Cisco Systems 6 April 25, 2005 8 EAP Flexible Authentication via Secure Tunneling (EAP-FAST) 9 draft-cam-winget-eap-fast-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This document defines the Extensible Authentication Protocol (EAP) 42 based Flexible Authentication via Secure Tunneling (EAP-FAST) 43 protocol. EAP-FAST is an EAP method that enables secure 44 communication between a client and a server by using the Transport 45 Layer Security (TLS) to establish a mutually authenticated tunnel. 46 However, unlike current existing tunneled authentication protocols, 47 EAP-FAST also enables the establishment of a mutually authenticated 48 tunnel by means of symmetric cryptography. Furthermore, within the 49 secure tunnel, EAP encapsulated methods can ensue to either 50 facilitate further provision of credentials, authentication or 51 authorization policies by the server to the client. 53 Table of Contents 55 1. Introduction..................................................3 56 1.1 Specification Requirements................................4 57 1.2 Terminology...............................................4 58 2. Protocol Overview.............................................6 59 3. Architectural Model...........................................7 60 4. Protocol Layering Model.......................................7 61 5. Protected Access Credential (PAC) for EAP-FAST Authentication.8 62 6. EAP-FAST Authentication.......................................9 63 6.1 EAP-FAST Authentication Phase 1: Tunnel Establishment.....9 64 6.2 EAP-FAST Authentication Phase 1: Key Derivations.........11 65 6.3 EAP-FAST Authentication Phase 2: Tunneled Authentication.12 66 6.4 Protected EAP Conversation...............................12 67 6.5 Protected Termination and Acknowledged Result Indication.13 68 6.6 EAP-FAST Authentication Phase 2: Key Derivations.........14 69 6.7 Cryptographic Binding: Computing the Compound MAC........15 70 6.8 EAP-FAST Authentication: Session Key Generation..........16 71 6.9 PAC Distribution and Refreshing..........................16 72 7. Version Negotiation..........................................17 73 8. Error Handling...............................................18 74 8.1 Error Alerts.............................................19 75 9. Session Resume...............................................19 76 10. Fragmentation...............................................20 77 11. EAP-FAST Detailed Description...............................22 78 11.1 EAP-FAST Packet Format..................................22 79 11.2 EAP-FAST TLV Format.....................................23 80 11.3 TLV format..............................................24 81 11.4 Result TLV..............................................25 82 11.5 NAK TLV.................................................26 83 11.6 Crypto-Binding TLV......................................27 84 11.7 EAP-Payload TLV.........................................29 85 11.8 Intermediate-Result TLV.................................30 86 11.9 PAC TLV.................................................31 87 11.9.1 Formats for PAC TLV attributes.....................32 88 11.9.2 PAC-Key............................................32 89 11.9.3 PAC-Opaque.........................................33 90 11.9.4 PAC-Info...........................................34 91 11.9.5 PAC-Acknowledgement TLV............................35 92 11.10 TLS SessionTicket Extension............................36 93 12. Security Considerations.....................................36 94 12.1 Mutual Authentication and Integrity Protection..........37 95 12.2 Method Negotiation......................................37 96 12.3 Separation of the EAP Server and the Authenticator......38 97 12.4 Separation of Phase 1 and Phase 2 Servers...............38 98 12.5 Mitigation of Known Vulnerabilities and Protocol 99 Deficiencies............................................39 100 12.5.1 User Identity Protection and Verification..........40 101 12.5.2 Dictionary Attack Resistance.......................41 102 12.5.3 Protection against MitM Attacks....................41 103 12.5.4 PAC Validation with User Credentials...............42 104 12.6 PAC Storage Considerations..............................43 105 12.7 Protecting against Forged Clear Text EAP Packets........44 106 12.8 Implementation..........................................44 107 12.9 Security Claims.........................................45 108 13. IANA Considerations.........................................45 109 14. References..................................................45 110 14.1 Normative...............................................45 111 14.2 Informative.............................................46 112 15. Acknowledgments.............................................47 113 16. Authors' Addresses..........................................47 114 17. Appendix A: Examples........................................48 115 17.1 Successful Authentication...............................48 116 17.2 Failed Authentication...................................49 117 18. Appendix B: EAP-FAST PRF (T-PRF)............................51 118 19. Appendix C: Test Vectors....................................51 119 19.1 Key derivation..........................................51 120 19.2 Crypto-Binding MIC:.....................................53 121 20. Intellectual Property Statement.............................53 122 21. Disclaimer of Validity......................................54 123 22. Copyright Statement.........................................54 124 23. Expiration Date.............................................54 126 1. Introduction 128 The need to provide user friendly and easily deployable network 129 access solutions has heightened the need to enable strong mutual 130 authentication protocols that internally use weak user credentials. 131 While several such authentication protocols [PEAP] [EAP-TTLS] exist 132 today, they are encumbered by the use of asymmetric cryptographic 133 operations that often render such protocols prohibitive on very low 134 end peer devices. 136 Like [TLS-PSK], EAP-FAST employs symmetric cryptography to allay 137 the PKI requirements of [PEAP] or [EAP-TTLS]. Additionally, EAP- 138 FAST employs the TLS SessionTicket extension [TICKET] as a further 139 optimization to minimize the state maintained by the server. EAP- 140 FAST's design motivations included: 142 * Mutual Authentication: an Authentication Server (AS) must verify 143 the identity and authenticity of the peer, and the peer must 144 verify the authenticity of an AS. 146 * Immunity to passive dictionary attacks: as many authentication 147 protocols require the password to be explicitly provided (either 148 in the clear or hashed) by the peer to the AS; at minimum, the 149 communication of the weak credential (e.g. password) must be 150 immune from eavesdropping. 152 * Immunity to man-in-the-middle (MitM) attacks: in establishing a 153 mutually authenticated protected tunnel, the protocol must 154 prevent adversaries from successfully interjecting the 155 conversation between peer and AS. 157 * Flexibility to enable support for most password authentication 158 interfaces: as many different password interfaces (e.g. MSCHAP, 159 LDAP, OTP, etc) exist to authenticate a peer, the protocol must 160 provide this support seamlessly. 162 * Efficiency: specifically when using wireless media, peers will 163 be limited in computational and power resources. The protocol 164 must enable the network access communication to be 165 computationally lightweight. 167 With these motivational goals defined, further secondary design 168 criteria are imposed: 170 * Flexibility to extend the communications inside the tunnel: 171 with the growing complexity in network infrastructures the need 172 to gain authentication, authorization and accounting is also 173 evolving. For instance, there may be instances in which multiple 174 (already existent) authentication protocols are required to 175 achieve mutual authentication. Similarly, different protected 176 conversations may be required to achieve the proper authorization 177 once a peer has successfully authenticated. This capability is 178 similar to [PEAP]. 180 * Minimize the authentication server's per user authentication 181 state requirements: with large deployments, it is typical to have 182 many servers acting as the AS for many peers. It is also highly 183 desirable for a peer to use the same shared secret to secure a 184 tunnel much the same way it uses the username and password to 185 gain access to the network. The protocol must facilitate the 186 use of a single strong shared secret by the peer while enabling 187 the servers to minimize the per user and device state it must 188 cache and manage. 190 1.1 Specification Requirements 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 194 this document are to be interpreted as described in [RFC2119]. 196 1.2 Terminology 198 Some of the following terms are taken from RFC3748 [EAP]: 200 EAP Server 202 The entity that terminates the EAP authentication with the peer. 203 In the case where there is no back end authentication server, 204 this term refers to the authenticator. Where the authenticator 205 operates in pass-through, it refers to the back end 206 authentication server. 208 Authenticator 210 The end of the link initiating EAP authentication. The term 211 Authenticator is used in [IEEE-802.1x], and authenticator has 212 the same meaning in this document. 214 Peer 216 The end of the link that responds to the authenticator. In 217 [IEEE-802.1x], this end is known as the Supplicant. 219 Supplicant 221 The end of the link that responds to the authenticator in [IEEE- 222 802.1x]. In this document, this end of the link is called the 223 peer. 225 Back end Authentication Server 227 A back end authentication server is an entity that provides an 228 authentication service to an authenticator. When used, this 229 server typically executes EAP methods for the authenticator. 230 This terminology is also used in [IEEE-802.1x]. 232 Master Session Key (MSK) 234 Keying material exported by an EAP method. 236 Man in the Middle (MitM) 238 An adversary that can successfully inject itself between a peer 239 and EAP server. The MitM succeeds by impersonating itself as a 240 valid peer, authenticator or authentication server. 242 Message Authentication Code (MAC) 244 A MAC is a function that takes a variable length input and a key 245 to produce a fixed-length output to carry authentication and 246 integrity protection of data. 248 Message Integrity Check (MIC) 250 A keyed hash function used for authentication and integrity 251 protection of data. This is usually called a Message 252 Authentication Code (MAC), but IEEE 802 specifications (and this 253 document) use the acronym MIC to avoid confusion with Medium 254 Access Control. 256 Protected Access Credential (PAC) 258 Credentials distributed to users for future optimized network 259 authentication, which always consists of a secret part and an 260 opaque part. The secret part is secret key material that can be 261 used in future transactions. The opaque part is presented when 262 the client wishes to obtain access to network resources. It 263 aids the server in validating that the client possesses the 264 secret part. 266 Silently Discard 268 This means the implementation discards the packet without 269 further processing. The implementation SHOULD provide the 270 capability of logging the event, including the contents of the 271 silently discarded packet, and SHOULD record the event in a 272 statistics counter. 274 Successful Authentication 276 In the context of this document, "successful authentication" is 277 an exchange of EAP messages, as a result of which the 278 authenticator decides to allow access by the peer, and the peer 279 decides to use this access. The authenticator's decision 280 typically involves both authentication and authorization 281 aspects; the peer may successfully authenticate to the 282 authenticator but access may be denied by the authenticator due 283 to policy reasons. 285 2. Protocol Overview 287 EAP-FAST is an extensible framework that enables mutual 288 authentication by using a pre-shared secret to establish a 289 protected tunnel. Like [PEAP] [EAP-TTLS], the protocol is based on 290 TLS; however, enhancements are made to TLS to enable EAP-FAST to 291 initiate the tunnel establishment exchange using symmetric 292 cryptography while minimizing server state. The tunnel is then used 293 to protect weaker authentication methods, typically based on 294 passwords. 296 The pre-shared secret used in EAP-FAST is referred to as the 297 Protected Access Credential key (or PAC-Key); the PAC-Key is used 298 to mutually authenticate the client and server when securing a 299 tunnel. Furthermore, the PAC-Key is refreshed and managed as part 300 of the EAP-FAST protocol. EAP-FAST allays server state by the use 301 of a PAC-Opaque, which contains the PAC-Key encrypted by a strong 302 key only known to the server and sent to the server with the TLS 303 ClientHello SessionTicket extension [TICKET]. With the use of 304 PAC-Opaque and SessionTicket extension, EAP-FAST alleviates the 305 server's need to store per user PAC and state. 307 The EAP-FAST conversation is used to establish or resume an 308 existing session to typically establish network connectivity 309 between a peer and the network. A peer and AS achieve mutual 310 authentication by invoking a symmetric authenticated key agreement 311 to protect the communications that further authenticates and 312 authorizes the client to use the network. A successful result is a 313 mutual derivation of strong session keys which can then be 314 provisioned (by the AS) to the network access server (NAS, 315 typically these are the access points in 802.11 or 802.1x 316 authenticators). 318 3. Architectural Model 320 The network architectural model for EAP-FAST usage is shown below: 322 +----------+ +----------+ +----------+ +----------+ 323 | | | | | | | Inner | 324 | Peer |<---->| Authen- |<---->| EAP-FAST |<---->| Method | 325 | | | ticator | | server | | server | 326 | | | | | | | | 327 +----------+ +----------+ +----------+ +----------+ 329 The entities depicted above are logical entities and may or may not 330 correspond to separate network components. For example, the EAP- 331 FAST server and Inner Method server might be a single entity; the 332 authenticator and EAP-FAST server might be a single entity; or, 333 indeed, the functions of the authenticator, EAP-FAST server and 334 Inner Method server might be combined into a single physical 335 device. For example, typical 802.11 deployments place the 336 Authenticator in an access point (AP) while a Radius Server may 337 provide the EAP-FAST and Inner Method server components. The above 338 diagram illustrates the division of labor among entities in a 339 general manner and shows how a distributed system might be 340 constructed; however, actual systems might be realized more simply. 341 The security considerations (Section 12) provides an additional 342 discussion of the implications of separating EAP-FAST from the 343 inner method. 345 4. Protocol Layering Model 347 EAP-FAST packets are encapsulated within EAP, and EAP in turn, 348 requires a carrier protocol for transport. EAP-FAST packets 349 encapsulate TLS, which is then used to encapsulate user 350 authentication information. Thus, EAP-FAST messaging can be 351 described using a layered model, where each layer encapsulates the 352 layer beneath it. The following diagram clarifies the relationship 353 between protocols: 354 +---------------------------------------------------------------+ 355 | | | 356 | Lower | TLV Encapsulation (TLVs) | 357 | to |---------------------------------------------------| 358 | Upper | TLS | 359 | Layer |---------------------------------------------------| 360 | | EAP-FAST | 361 | |---------------------------------------------------| 362 | | EAP | 363 | |---------------------------------------------------| 364 | | Carrier Protocol (EAPOL, RADIUS, Diameter, etc.) | 365 +---------------------------------------------------------------+ 366 The TLV layer is a payload with standard Type-Length-Value (TLV) 367 objects. The TLV objects are used to carry arbitrary parameters 368 between an EAP peer and an EAP server. All conversations in the 369 EAP-FAST protected tunnel must be encapsulated in a TLV layer. 370 When the user authentication protocol is itself EAP, the layering 371 is as follows: 373 +---------------------------------------------------------------+ 374 | | Inner EAP Method | 375 | |---------------------------------------------------| 376 | Lower | TLV Encapsulation (TLVs) | 377 | to |---------------------------------------------------| 378 | Upper | TLS | 379 | Layer |---------------------------------------------------| 380 | | EAP-FAST | 381 | |---------------------------------------------------| 382 | | EAP | 383 | |---------------------------------------------------| 384 | | Carrier Protocol (EAPOL, RADIUS, Diameter, etc.) | 385 +---------------------------------------------------------------+ 387 Methods for encapsulating EAP within carrier protocols are already 388 defined. For example, 802.1x EAPOL may be used to transport EAP 389 between client and access point; RADIUS or Diameter are used to 390 transport EAP between authenticator and EAP-FAST server. 392 5. Protected Access Credential (PAC) for EAP-FAST Authentication 394 A pre-shared secret mutually and uniquely shared between the peer 395 and AS is used to secure a tunnel during EAP-FAST Authentication. 396 EAP-FAST uses a Protected Access Credential (PAC) to facilitate the 397 use of a single shared secret by the peer and minimize the per user 398 state management on the AS. The PAC is a security credential 399 provided by the AS to a peer and comprised of: 401 1. PAC-Key: this is a 32-octet key used by the peer to establish 402 the EAP-FAST Phase 1 tunnel. This key maps as the TLS pre- 403 master-secret. The PAC-Key is randomly generated by the AS to 404 produce a strong entropy 32-octet key. 406 2. PAC-Opaque: this is a variable length field that is sent to 407 the AS during the EAP-FAST Phase 1 tunnel establishment. The 408 PAC-Opaque can only be interpreted by the AS to recover the 409 required information for the server to validate the peer's 410 identity and authentication. For example, the PAC-Opaque may 411 include the PAC-Key and the PAC's peer identity. The PAC- 412 Opaque format and contents are specific to the issuing PAC 413 server. 415 3. PAC-Info: this is a variable length field used to provide at 416 minimum, the authority identity of PAC issuer. Other useful 417 but not mandatory information, such as the PAC-Key lifetime, 418 may also be conveyed by the AS to the peer during PAC 419 provisioning or refreshment. 421 As the focus of this draft is to define the EAP-FAST protected 422 tunneling and authentication mechanism, it does not address 423 provisioning. That is, provisioning of the PAC may be achieved 424 using the same mechanisms as the provisioning of any other 425 credential such as certificates or username/password credential 426 types. 428 6. EAP-FAST Authentication 430 To establish a new session, EAP-FAST employs the PAC to invoke an 431 authenticated key agreement exchange to establish a protected 432 tunnel. Once the tunnel is established, the peer and AS can ensue 433 in further conversations to establish the required authentication 434 and authorization policies. Part of the authorization policy is 435 the generation of the Master Session Keys (MSKs). Portions of the 436 MSKs may be distributed to the NAS using the RADIUS MS-MPPE 437 [RFC2548] attribute. Finally, the server may also update the PAC 438 as part of the EAP-FAST protocol conclusion. This section 439 describes the two phases of EAP-FAST Authentication: Phase 1, the 440 tunnel establishment and Phase 2, the tunneled authentication. 442 6.1 EAP-FAST Authentication Phase 1: Tunnel Establishment 444 This conversation is similar to establishing a new EAP-TLS session 445 except it uses new EAP type (EAP-FAST) and new TLS SessionTicket 446 extension in TLS ClientHello. The SessionTicket extension is 447 modeled after [RFC3546] and described in [TICKET]. 449 The initial conversation begins with the authenticator and the peer 450 negotiating EAP. The authenticator will typically send an EAP- 451 Request/Identity packet to the peer, and the peer will respond with 452 an EAP-Response/Identity packet to the authenticator, containing 453 the username. If the client desires to protect its identity, it 454 may use an anonymous username. 456 Once the initial Identity Request/Response exchange is completed, 457 while the EAP conversation typically occurs between the 458 authenticator and the peer, the authenticator may act as a pass- 459 through device, with the EAP packets received from the peer being 460 encapsulated for transmission to a back end authentication server. 461 In the discussion that follows, the term "EAP server" or "server" 462 is used to denote the ultimate endpoint conversing with the peer. 464 Once having received the peer's Identity, and determined that EAP- 465 FAST Authentication is to occur, the EAP server must respond with a 466 EAP-FAST/Start packet, which is an EAP-Request packet with EAP- 467 Type=EAP-FAST and the Start (S) bit set. The EAP-FAST/Start packet 468 shall also include an authority identity (A-ID) TLV to better 469 inform the peer the server's identity. Assuming that the peer 470 supports EAP-FAST, the EAP-FAST conversation will then begin, with 471 the peer sending an EAP-Response packet with EAP-Type=EAP-FAST. 473 The data field of the EAP-Response packet contains an EAP-FAST 474 encapsulated TLS ClientHello handshake message. 476 The ClientHello message contains the peer's challenge (also called 477 the client_random) and PAC-Opaque in TLS SessionTicket extension. 478 As there may be different EAP-FAST servers a peer may encounter, a 479 peer may be provisioned with unique PACs uniquely identified by the 480 A-ID corresponding to the EAP-FAST server. A peer may choose to 481 cache the different PACs and determine based on the A-ID the 482 corresponding PAC to employ. While EAP-FAST is capable of 483 supporting any ciphersuite, in this version, the ClientHello uses 484 the TLS_RSA_WITH_RC4_128_SHA ciphersuite. As EAP-FAST uses the PAC 485 to establish the keys, the RSA key exchange is not executed, but 486 the specification of RC4 and SHA signals the EAP server that the 487 tunnel must be protected using 128bit RC4 for confidentiality and 488 SHA1 for authenticity. 490 The EAP server will then respond with an EAP-Request packet with 491 EAP-Type=EAP-FAST. The data field of this packet will encapsulate 492 three TLS records, ServerHello, ChangeCipherSpec and Finished 493 messages. The ServerHello will contain a server_random and 494 ChangeCipherSpec. The TLS Finished message, sent immediately after 495 the ChangeCipherSpec message, contains the first protected message 496 with the negotiated algorithm, keys, and secrets. 498 The server generates the master_secret prior to composing the EAP- 499 FAST TLS ServerHello message to properly generate the TLS Finished 500 message contents. The server must compute the Tunnel Keys as 501 described in Section 6.2 at this time to properly respond and 502 generate its TLS Finished message. 504 The peer in turn, must consume the ServerHello to extract the 505 server_random before it can generate the master_secret and Tunnel 506 Keys, as described in Section 6.2. 508 After verifying the server Finished message, the peer responds back 509 with two TLS records, a ChangeCipherSpec and the peer's TLS 510 Finished message. At this state, the client is ready to receive 511 and transmit protected messages with the server. 513 Upon verifying the peer's Finished message, the EAP server 514 establishes the tunnel and is ready for the receiving and 515 transmitting protected messages with the peer. The messages are 516 protected using the Tunnel Keys described in Section 6.2. 518 6.2 EAP-FAST Authentication Phase 1: Key Derivations 520 The EAP-FAST Authentication tunnel key is calculated similarly to 521 the TLS key calculation with an additional 40 octets (referred to, 522 as the session_key_seed) generated. The additional 523 session_key_seed is used in the Session Key calculation in the EAP- 524 FAST Tunneled Authentication conversation. 526 An EAP-FAST specific PRF function, T-PRF described in Appendix B 527 (Section 18) is used to generate a fresh master_secret from the 528 specified client_random, server_random and PAC-Key. 530 The PRF function used to generate keying material is defined by 531 [RFC 2246]. 533 Since a PAC may be used as a credential for other applications 534 beyond EAP-FAST, the PAC-Key is further hashed using T-PRF to 535 generate a fresh TLS master_secret. Additionally, the hash of 536 PAC-Key is required to stretch it to the required 48 octet 537 master_secret: 539 master_secret = T-PRF(PAC-Key, "PAC to master secret label hash", 540 server_random + client_random, 48) 542 To generate the key material required for EAP-FAST Authentication, 543 the following TLS construction is used: 545 key_block = PRF(master_secret, "key expansion", server_random + 546 client_random) 548 where '+' denotes concatenation. 550 Since this version of EAP-FAST Authentication employs 128bit RC4 551 and SHA1, the key_block is partitioned as follows: 553 client_write_MAC_secret[hash_size=20] 554 server_write_MAC_secret[hash_size=20] 555 client_write_key[Key_material_length=16] 556 server_write_key[key_material_length=16] 557 client_write_IV[IV_size=0] 558 server_write_IV[IV_size=0] 559 session_key_seed[seed_size= 40] 561 The client_write_MAC_secret and server_write_MAC_secret are the 562 keys used by the client and server to authenticate subsequent 563 messages respectively. Similarly, the client_write_key and 564 client_write_IV are used by the client to provide message 565 confidentiality while the server uses the server_write_key and 566 server_write_IV to achieve confidentiality. The session_key_seed 567 is later used by the EAP-FAST Authentication Phase 2 conversation 568 to both cryptographically bind the inner method(s) to the tunnel as 569 well as generate the resulting EAP-FAST session keys. 571 6.3 EAP-FAST Authentication Phase 2: Tunneled Authentication 573 The second portion of the EAP-FAST Authentication conversation 574 consists of at least one complete EAP conversation occurring within 575 the TLS session negotiated in EAP-FAST Authentication Phase 1; 576 ending with protected termination using the Result-TLV and Crypto- 577 Binding TLV. All EAP messages are encapsulated in the EAP Message 578 TLV. 580 EAP-FAST Phase 2 will occur only if establishment of a new TLS 581 session in Phase 1 is successful or a TLS session is successfully 582 resumed in Phase 1. 584 Phase 2 must not occur if the EAP Peer or EAP Server fails 585 authentication during Phase 1. That is, if the tunnel 586 establishment fails and a TLS alert is provided prior to a 587 clear text EAP failure. 589 Additionally, Phase 2 must not occur if a protected EAP-Failure has 590 been sent by the EAP Server to the peer, terminating the 591 conversation. Since all packets sent within the EAP-FAST Phase 2 592 conversation occur after TLS session establishment, they are 593 protected using the negotiated TLS cipher suite. For example, if 594 the cipher suite negotiated is TLS_RSA_WITH_RC4_128_SHA, all EAP- 595 TLV packets of the conversation in Phase 2 including the EAP-TLV 596 header are protected using 128bit RC4 and SHA1 as defined by the 597 TLS protocol [RFC 2246]. 599 6.4 Protected EAP Conversation 601 Phase 2 of the EAP-FAST Authentication conversation consists of at 602 least one protected EAP authentication, typically using the peer's 603 credentials (typically username and password). This entire EAP 604 conversation including the user identity and EAP type are protected 605 from eavesdropping and modification by the tunnel encapsulation. A 606 hacker cannot readily determine the EAP method used (except perhaps 607 by traffic analysis) nor can the hacker inject/modify packets to 608 subvert the authentication. 610 Phase 2 of the EAP-FAST conversation begins with the EAP server 611 sending an EAP-Request/Identity packet to the peer, protected by 612 the TLS ciphersuite negotiated in EAP-FAST Phase 1. The peer 613 responds with an EAP-Response/Identity packet to the EAP server, 614 containing the peer's userID. 616 After the protected Identity exchange, the EAP server will send an 617 EAP-Request with the supported EAP type, for example, EAP-Type=EAP- 618 GTC. EAP-FAST enables the use of any (EAP) method to ensue inside 619 the tunnel, the EAP-GTC type is used in this specification as an 620 example. 622 The EAP conversation within the TLS protected session may involve 623 zero or more EAP authentication methods, including the TLV 624 exchanges; and completes with protected termination shown in Section 625 6.5. 627 After any EAP method, the EAP-FAST server or peer may request the 628 EAP-FAST peer or server respectively, to prove that it has 629 participated in the sequence of authentications successfully 630 completed until that point. The server also concludes the EAP-FAST 631 Phase 2 conversation by invoking a final Result TLV with a Crypto- 632 Binding TLV. The Crypto-Binding TLV is sent in the protected TLS 633 channel. If the EAP-FAST server sends a valid Crypto-Binding TLV 634 to the EAP-FAST peer, the peer MUST respond with a Crypto-Binding 635 TLV in an EAP Response. If the Crypto-Binding TLV is invalid, it 636 MUST be considered failed authentication by EAP-FAST peer and a 637 Result TLV with a failure status should follow. If the peer does 638 not respond with an EAP-FAST packet containing the Crypto-Binding 639 TLV, it MUST be considered failed authentication by the EAP-FAST 640 server. Once the EAP-FAST peer and EAP-FAST server considers them 641 as failed authentications, they are the last packets inside the 642 protected tunnel. 644 6.5 Protected Termination and Acknowledged Result Indication 646 The EAP-FAST server and EAP-FAST peer indicate success/failure of a 647 conversation ensued inside the TLS tunnel. Either an Intermediate- 648 Result TLV is used if further conversations will occur, or a final 649 Result TLV if it is the concluding success/failure indication. The 650 inclusion of a Crypto-Binding TLV exchange is used to prove that 651 both peers participated in the sequence of authentications 652 (specifically the TLS session and inner authentication methods that 653 generate keys). The Crypto-Binding TLV exchange is only needed 654 with a Success Result TLV to verify the integrity of the tunnel. If 655 the inner EAP method fails, then no Crypto-Binding TLV exchange is 656 needed. 658 If the PAC needs to be updated, the Crypto-Binding TLV must precede 659 the final Result TLV as the final Result TLV exchange may also 660 include the distribution of the PAC in a PAC TLV. Following a 661 successful Intermediate-Result TLV and Crypto-Binding TLV exchange, 662 the Result TLV will be the next subsequent TLV exchange that also 663 includes a PAC TLV to update the PAC. 665 Both Intermediate and final Result TLVs are sent protected within 666 the TLS channel. The EAP-FAST peer then replies with a 667 corresponding Intermediate or final Result TLV inside protected 668 channel. The conversation concludes with a final Result TLV 669 exchange followed by the EAP-FAST server sending a clear text EAP- 670 Success/Failure indication. 672 The only outcome which should be considered as a successful EAP- 673 FAST Authentication is when the final Result TLV of Status=Success 674 and a valid concluding Crypto-Binding TLV, is answered by a final 675 Result TLV of Status=Success and a valid Crypto-Binding-TLV. 677 All other combinations of the (request, response) Result TLVs such 678 as (Failure, Success), (Failure, Failure), (no Result TLV exchange, 679 no Crypto-Binding TLVs or where the Crypto-Binding TLV validation 680 is not successful) MUST be considered failed authentications, both 681 by the EAP-FAST peer and EAP-FAST server. Once the EAP-FAST peer 682 and EAP-FAST server considers them as failed authentications, they 683 are the last packets inside the protected tunnel. These are 684 considered failed authentications regardless of whether a clear text 685 EAP Success or EAP Failure packet is subsequently sent. 687 In support for session resumption, an EAP-FAST server may send the 688 success indication and Crypto-Binding TLV, without initiating any 689 EAP conversation in EAP-FAST Phase 2. The EAP-FAST peer is 690 allowed to refuse to accept a success message from the EAP-FAST 691 server since the peer's policy may require completion of certain 692 authentication methods. If session resume is invoked and the 693 EAP-FAST server has sent Result-TLV with Status=Success; and the 694 response from the EAP peer is Status=Failure, then the server MUST 695 continue with the EAP-FAST Phase 2 authentication conversation. 697 6.6 EAP-FAST Authentication Phase 2: Key Derivations 699 Keying material resulting from all successful conversations ensued 700 in both phases of EAP-FAST Authentication are used to both prove 701 tunnel integrity and generate session keys. A base compound key is 702 the resulting key generated as follows: 704 EAP-FAST session_key_seed(SKS) is a 40 octet value obtained from 705 the EAP-FAST Authentication Phase 1 described in Section 6.2. 707 The inner authentication method(s) provide session keys: ISK1..ISKn 708 corresponding to inner methods 1 through n. Only the MSKs from the 709 inner methods are required. If the inner method (i) does not 710 generate an ISK, then ISKi is set to zero (e.g. ISKi = 32 octets of 711 0x00s). If the inner method generates keying material, EAP-FAST 712 presumes that a minimum of 32 octets are provided. Otherwise, the 713 resulting ISK is padded with zeroes to generate a 32 octet value. 714 Thus, the first 32 octets generated as the encryption keying 715 material by the inner method is used and assigned as the ISK. For 716 example, if EAP-TLS [RFC 2716] is used as an inner method, the 717 resulting first 32 bytes described as the "peer encryption key" in 718 Section 3.5 of [RFC 2716] is assigned as the ISK. 720 The algorithm uses the EAP-FAST T-PRF as described in Appendix B 721 (Section 18) to generate the following: 723 S-IMCK[0] = SKS 725 For j = 1 to n-1 do 726 IMCK[j] = T-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", ISK[j], 727 60); 728 Where S-IMCK[j] are the first 40 octets of IMCK[j] 730 ICMK[j] may generate up to 60 octets of keying material. The first 731 40 octets are used as the key input to the succeeding ICMK[j+1] 732 derivation and the latter 20 octets are used as the key, CMK[j], 733 used to generate the intermediate Crypto-Binding Compound MAC 734 value. 736 6.7 Cryptographic Binding: Computing the Compound MAC 738 For authentication methods that generate keying material, further 739 protection against man-in-the-middle attacks are mitigated through 740 the enforcement of cryptographically binding keying material 741 established by both EAP-FAST Phase 1 and EAP-FAST Phase 2 742 conversations. 744 For a successful EAP-FAST Authentication, inner methods are 745 cryptographically combined to generate a compound session key, CMK, 746 used to generate an authentication tag referred to as a Compound 747 MAC and transported in a Crypto-Binding TLV. The Crypto-Binding 748 TLV is used to assure that the same peers invoked all methods in 749 EAP-FAST. 751 EAP-FAST optionally enables the server or peer to invoke 752 Intermediate-Result TLV request/response exchanges with Crypto- 753 Binding TLVs to verify the integrity of the tunnel between methods 754 inside the EAP-FAST Phase 2 conversation. 756 Similarly, EAP-FAST enforces a mandatory inclusion of a Crypto- 757 Binding TLV after a final method has completed. In both instances, 758 a Crypto-Binding TLV is included when either an Intermediate-Result 759 TLV or a final Result TLV is used. The Crypto-Binding TLV includes 760 a 20 octet authentication tag that represents the HMAC-SHA1 hash of 761 the entire Crypto-Binding TLV. The Compound MAC field is zeroed 762 out prior to the computation of the HMAC-SHA1 and subsequently 763 populated with the resulting hash value. 765 The requesting server shall provide a 32-octet random server_nonce 766 with its last bit set to 0 and compute the Compound MAC field as 767 follows: 768 HMAC-SHA1( CMK, [Crypto-Binding TLV with Compound MAC field= 769 zeroes]) 771 The responding peer shall respond with the same 32-octet 772 server_nonce value provided by the requestor with its last bit set 773 to 1 and computes the responding Compound MAC field as described 774 above. 776 6.8 EAP-FAST Authentication: Session Key Generation 778 EAP-FAST Authentication assures the master session keys are a 779 result of all conversations ensued by generating a compound session 780 key (IMCK). The IMCK is mutually derived by the peer and server 781 using the T-PRF; the IMCK calculation is defined in Section 6.6. 782 The resulting master session key, MSK, is generated as part of the 783 IMCKn key hierarchy. Where the S-IMCKn is used to generate the 784 session keys as follows: 786 MSK = T-PRF(S-IMCKn, "Session Key Generating Function", 787 OutputLength) 789 The first version of EAP-FAST generates 64 octets to serve as the 790 successful EAP-FAST authentication master session keys. 791 Interpretation and assignment of these 64 octets of the master 792 session key is specific to each link layer ciphersuite. 794 EAP-FAST implementations MAY generate EMSK as follows: 796 EMSK = T-PRF(S-IMCKn, "Extended Session Key Generating Function", 797 64) 799 The Extended Master Session Key (EMSK) is only known to the EAP- 800 FAST peer and server and is not provided to a third party. 802 6.9 PAC Distribution and Refreshing 804 The server may distribute or refresh a peer's PAC after a 805 successful EAP-FAST Authentication. A PAC TLV is created to 806 facilitate the distribution and update. A fresh PAC may be 807 distributed after a successful Intermediate-Result TLV and Crypto- 808 Binding TLV exchange. A successful EAP-FAST authentication, 809 including a successful Crypto-Binding exchange must ensue before an 810 EAP-FAST server can distribute a fresh PAC. A PAC TLV should not 811 be accepted if it is not TLS tunnel-encapsulated. The fresh PAC is 812 encapsulated in a PAC TLV containing the PAC-Key, PAC-Opaque and 813 PAC-Info TLVs. The PAC-Key is the shared secret key the peer uses 814 to mutually authenticate with the server and establish the tunnel. 815 The PAC-Opaque contains data that is opaque to the recipient, the 816 peer is not the intended consumer of PAC-Opaque and thus should not 817 attempt to interpret it. A peer that has been issued a PAC-Opaque 818 by a server must store that data, and present it back to the server 819 as is, in the TLS ClientHello SessionTicket extension [TICKET]. 820 PAC-Info provides the peer information about the PAC, at minimum, 821 it provides the information about the authority identity issuing 822 the PAC. 824 Once the EAP-FAST peer receives a PAC TLV, it needs to securely 825 save the new PAC-Key, PAC-Opaque and optionally, the PAC-Info. 826 Additionally, upon receipt of a new PAC, the peer must respond with 827 a successful PAC-Acknowledgement TLV. If the peer responds with a 828 PAC-Acknowledgement failure, the EAP-FAST server may invoke another 829 Result TLV failure resulting in a failed EAP-FAST authentication. 831 The server may refresh a PAC only after a successful exchange of 832 the concluding Intermediate-Result TLV and Crypto-Binding TLV. The 833 peer must use the new PAC-Key and PAC-Info in subsequent EAP-FAST 834 Authentication sessions. 836 N.B. In-band PAC refreshing is enforced by server policy. The 837 server, based on the PAC-Opaque information, may determine not to 838 refresh a peer's PAC through the PAC TLV mechanism even if the PAC- 839 Key has expired. 841 7. Version Negotiation 843 EAP-FAST packets contain a three bit version field, following the 844 TLS Flags field, which enables EAP-FAST implementations to be 845 backward compatible with previous versions of the protocol. 847 Version negotiation proceeds as follows: 849 In the first EAP-Request sent with EAP type=EAP-FAST, the EAP 850 server must set the version field to the highest supported version 851 number. 853 If the EAP peer supports this version of the protocol, it MUST 854 respond with an EAP-Response of EAP type=EAP-FAST, and the version 855 number proposed by the EAP-FAST server. 857 If the EAP-FAST peer does not support this version, it responds 858 with an EAP-Response of EAP type=EAP-FAST and the highest supported 859 version number. 861 If the EAP-FAST server does not support the version number proposed 862 by the EAP-FAST client, it terminates the conversation. 864 The version negotiation procedure guarantees that the EAP-FAST 865 client and server will agree to the latest version supported by 866 both parties. If version negotiation fails, then use of EAP-FAST 867 will not be possible, and another mutually acceptable EAP method 868 will need to be negotiated if authentication is to proceed. 870 The EAP-FAST version is not protected by TLS; and hence can be 871 modified in transit. In order to detect modification of EAP-FAST 872 version and specifically downgrade of a EAP-FAST version 873 negotiated, the peers MUST exchange information on the EAP-FAST 874 version negotiated using the Crypto-Binding TLV. The concluding 875 Intermediate or final Result TLV comes with a mandatory Crypto- 876 Binding TLV that includes the EAP-FAST version which MUST be 877 consistent to that specified in the EAP-FAST Start message. 879 8. Error Handling 881 The EAP-FAST protocol uses TLS alert messages to communicate and 882 handle error conditions in all phases of EAP-FAST. Errors during 883 the tunnel establishment or protection in EAP-FAST Authentication 884 are handled via TLS alert messages, while errors during the 885 protected tunnel are expected to be handled by the individual EAP 886 methods. Intermediate-Result TLVs are also used as status 887 indications of the individual EAP methods in EAP-FAST Phase 2. 888 If the EAP-FAST server detects an error at any point in the TLS 889 conversation, the EAP-FAST server should send an EAP-Request 890 packet with EAP-Type=EAP-FAST, encapsulating a TLS record 891 containing the appropriate TLS alert message. 893 The EAP-FAST server should send a TLS alert message rather than 894 immediately terminating the conversation so as to allow the peer to 895 inform the user of the cause of the failure and possibly allow for 896 a restart of the conversation. To ensure that the peer receives 897 the TLS alert message, the EAP server must wait for the peer to 898 reply with an EAP-Response packet before terminating the 899 connection. 901 The EAP-Response packet sent by the peer may encapsulate a TLS 902 client_hello handshake message, in which case the EAP-FAST server 903 MAY allow the EAP-FAST conversation to be restarted, or it MAY 904 contain an EAP-Response packet with EAP-Type=EAP-FAST and Flags and 905 Version fields without any additional data , in which case the EAP- 906 FAST Server MUST send an EAP-Failure packet, and terminate the 907 conversation. 909 It is up to the EAP-FAST server whether to allow restarts, and if 910 so, how many times the conversation can be restarted. An EAP-FAST 911 Server implementing restart capability SHOULD impose a limit on the 912 number of restarts, so as to protect against denial of service 913 attacks. 915 If the EAP-FAST client detects an error at any point in the TLS 916 conversation, the EAP-FAST client should send an EAP-Response 917 packet with EAP-Type=EAP-FAST, encapsulating a TLS record 918 containing the appropriate TLS alert message. The EAP-FAST server 919 may restart the conversation by sending an EAP-Request packet 920 encapsulating the TLS server_hello handshake message, in which case 921 the EAP-FAST client may allow the EAP-FAST conversation to be 922 restarted; or terminate the conversation. 924 If during the EAP-FAST Authentication Phase 1 session 925 establishment, EAP-FAST servers cannot obtain or verify the PAC, 926 the server should send an EAP-Request packet with EAP-Type=EAP- 927 FAST, encapsulating a TLS record containing the appropriate TLS 928 alert message, before terminating the conversation. The EAP-FAST 929 peer should inform the use of the mismatching PAC and terminating 930 the conversation. 932 8.1 Error Alerts 934 EAP-FAST uses TLS-Alert to handle errors in the EAP-TLS handshake. 935 EAP-FAST employs the standard TLS error alerts described in TLS 936 Protocol Specification [RFC 2246]. In addition, it reuses the 937 following TLS alert to support EAP-FAST specific error conditions: 939 bad certificate 941 Server cannot find an acceptable PAC-Opaque in the ClientHello 942 message. This can be a result of either the peer not sending the 943 PAC-Opaque or the PAC-Opaque provided cannot be decrypted by the 944 server or expired. This message is always a fatal error. 946 decrypt_error 948 If PAC-Key doesn't match between the peer and server and either 949 peer or server fails to validate Finished message, decrypt_error 950 Alert should be used. This message is always a fatal error. 952 9. Session Resume 954 EAP-FAST offers a means to bypass further conversations such as 955 inner EAP authentication methods when a peer has an established 956 session identified by Session ID. This enables a peer to 957 optimally generate fresh master session keys without having to re- 958 invoke the inner EAP authentication method in EAP-FAST 959 Authentication Phase 2. Applications that require user 960 intervention for the inner authentication method (e.g. OTP) can 961 benefit from this feature when service has been established but 962 believes it must refresh its master session keys. 964 EAP-FAST session resumption is achieved in the same manner TLS 965 achieves session resume. Session Resume is achieved by the peer 966 responding with a known Session ID in its ClientHello record. The 967 EAP-FAST Authentication Phase 1 conversation proceeds in a similar 968 fashion as described in Section 6 with the exception of the use of 969 the PAC-Opaque in the ClientHello. That is, a session resumption 970 is distinguished by the client's indication of a valid (e.g. non- 971 zero) SessionID and omission of the PAC-Opaque in its ClientHello 972 message. To support session resumption, the server must minimally 973 cache the client's SessionID, master_secret and CipherSpec. If 974 the server finds a match for the SessionID and is willing to 975 establish a new connection using the specified session state, the 976 server will respond with the same SessionID and proceed with the 977 EAP-FAST Authentication Phase 1 tunnel establishment described in 978 Section 6.1. The key derivations used in the EAP-FAST 979 Authentication Phase 1 employ the corresponding SessionID's 980 master_secret in accordance to the TLS [RFC 2246] session 981 resumption specification. 983 After a successful conclusion of the EAP-FAST Authentication Phase 984 1 conversation, the server then decides whether to honor session 985 resumption based on the Session ID value. It may reject and 986 initiate the inner EAP authentication method to signal the start of 987 a full EAP-FAST Authentication Phase 2 conversation. The server 988 may accept a session resumption based on the Session ID specified 989 by the peer as well as the time elapsed since the previous 990 authentication. 992 The server may accept a session resumption and bypass the inner EAP 993 authentication method by immediately requesting a final Result TLV 994 without a Crypto-Binding TLV. The concluding Result TLV exchange 995 is the same as that described in Section 6.5. The EAP-FAST master 996 session keys are generated as described in Section 6.8, with the 997 exception that S-IMCK[n] is SKS without going through the compound 998 key derivation, as in this case no inner EAP method has run. 1000 Even if the session is successfully resumed, the peer and EAP-FAST 1001 server must not assume that either will skip inner EAP methods. The 1002 peer may have roamed to a network which may use the same EAP 1003 server, but may require conformance with a different authentication 1004 policy. After a session is successfully resumed, the EAP-Server may 1005 start a full Phase 2 of the EAP-FAST Authentication conversation. 1007 10. Fragmentation 1009 A single TLS record may be up to 16384 octets in length, but a TLS 1010 message may span multiple TLS records, and a TLS certificate 1011 message may in principle be as long as 16MB. The group of EAP-FAST 1012 messages sent in a single round may thus be larger than the PPP MTU 1013 size, the maximum RADIUS packet size of 4096 octets, or even the 1014 Multilink Maximum Received Reconstructed Unit (MRRU). As described 1015 in [2], the multilink MRRU is negotiated via the Multilink MRRU LCP 1016 option, which includes an MRRU length field of two octets, and thus 1017 can support MRRUs as large as 64 KB. 1019 However, note that in order to protect against reassembly lockup 1020 and denial of service attacks, it may be desirable for an 1021 implementation to set a maximum size for one such group of TLS 1022 messages. Since a typical certificate chain is rarely longer than a 1023 few thousand octets, and no other field is likely to be anywhere 1024 near as long, a reasonable choice of maximum acceptable message 1025 length might be 64 KB. 1027 If this value is chosen, then fragmentation can be handled via the 1028 multilink PPP fragmentation mechanisms described in [RFC1990]. 1029 While this is desirable, EAP methods are used in other applications 1030 such as [IEEE80211] and there may be cases in which multilink or 1031 the MRRU LCP option cannot be negotiated. As a result, an EAP-FAST 1032 implementation MUST provide its own support for fragmentation and 1033 reassembly. 1035 Since EAP is an ACK-NAK protocol, fragmentation support can be 1036 added in a simple manner. In EAP, fragments that are lost or 1037 damaged in transit will be retransmitted, and since sequencing 1038 information is provided by the Identifier field in EAP, there is no 1039 need for a fragment offset field as is provided in IPv4. 1041 EAP-FAST fragmentation support is provided through addition of flag 1042 bits within the EAP-Response and EAP-Request packets, as well as a 1043 TLS Message Length field of four octets. Flags include the Length 1044 included (L), More fragments (M), and EAP-FAST Start (S) bits. The 1045 L flag is set to indicate the presence of the four octet TLS 1046 Message Length field, and MUST be set for the first fragment of a 1047 fragmented TLS message or set of messages. The M flag is set on all 1048 but the last fragment. The S flag is set only within the EAP-FAST 1049 start message sent from the EAP server to the peer. The TLS Message 1050 Length field is four octets, and provides the total length of the 1051 TLS message or set of messages that is being fragmented; this 1052 simplifies buffer allocation. 1054 When an EAP-FAST peer receives an EAP-Request packet with the M bit 1055 set, it MUST respond with an EAP-Response with EAP-Type=EAP-FAST 1056 and no data. This serves as a fragment ACK. The EAP server must 1057 wait until it receives the EAP-Response before sending another 1058 fragment. In order to prevent errors in processing of fragments, 1059 the EAP server MUST increment the Identifier field for each 1060 fragment contained within an EAP-Request, and the peer must include 1061 this Identifier value in the fragment ACK contained within the EAP- 1062 Response. Retransmitted fragments will contain the same Identifier 1063 value. 1065 Similarly, when the EAP-FAST server receives an EAP-Response with 1066 the M bit set, it must respond with an EAP-Request with EAP- 1067 Type=EAP-FAST and no data. This serves as a fragment ACK. The EAP 1068 peer MUST wait until it receives the EAP-Request before sending 1069 another fragment. In order to prevent errors in the processing of 1070 fragments, the EAP server MUST increment the Identifier value for 1071 each fragment ACK contained within an EAP-Request, and the peer 1072 MUST include this Identifier value in the subsequent fragment 1073 contained within an EAP-Response. 1075 11. EAP-FAST Detailed Description 1077 11.1 EAP-FAST Packet Format 1079 A summary of the EAP-FAST Request/Response packet format is shown 1080 below. 1082 The fields are transmitted from left to right. 1084 0 1 2 3 1085 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 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Code | Identifier | Length | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | Type | Flags | Ver | TLS Message Length + 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | TLS Message Length | TLS Data... + 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 Code 1096 1 - Request 1097 2 - Response 1099 Identifier 1101 The Identifier field is one octet and aids in matching responses 1102 with requests. The Identifier field MUST be changed on each 1103 Request packet. 1105 Length 1107 The Length field is two octets and indicates the length of the 1108 EAP packet including the Code, Identifier, Length, Type, and Data 1109 fields. Octets outside the range of the Length field should be 1110 treated as Data Link Layer padding and should be ignored on 1111 reception. 1113 Type 1115 43 - EAP-FAST 1117 Flags 1119 0 1 2 3 4 1120 +-+-+-+-+-+ 1121 |L M S R R| 1122 +-+-+-+-+-+ 1123 L = Length included 1124 M = More fragments 1125 S = EAP-FAST start 1126 R = Reserved (must be zero) 1128 The L bit (length included) is set to indicate the presence of 1129 the four octet TLS Message Length field, and MUST be set for the 1130 first fragment of a fragmented TLS message or set of messages. 1131 The M bit (more fragments) is set on all but the last fragment. 1132 The S bit (EAP-FAST Start) is set in an EAP-FAST Start message. 1133 This differentiates the EAP-FAST Start message from a fragment 1134 acknowledgement. 1136 Version 1138 0 1 2 1139 +-+-+-+ 1140 |R|R|1| 1141 +-+-+-+ 1143 R = Reserved (must be zero) 1145 TLS Message Length 1147 The TLS Message Length field is four octets, and is present only 1148 if the L bit is set. This field provides the total length of the 1149 TLS message or set of messages that is being fragmented. 1151 TLS data 1153 The TLS data consists of the encapsulated packet in TLS record 1154 format. An EAP-FAST packet with Flags and Version fields but with 1155 empty data field to used to indicate EAP-FAST acknowledgement for 1156 either TLS Alert or TLS Finished. 1158 11.2 EAP-FAST TLV Format 1160 The EAP-FAST TLV is a payload with standard Type-Length-Value (TLV) 1161 objects similar to those defined by [PEAP]. The TLV objects could 1162 be used to carry arbitrary parameters between EAP peer and EAP 1163 server. Possible uses for TLV objects include: language and 1164 character set for Notification messages; cryptographic binding; 1165 IPv6 Binding Update. 1167 The EAP peer may not necessarily implement all the TLVs supported 1168 by the EAP server; and hence to allow for interoperability, the TLV 1169 method allows an EAP server to discover if a TLV is supported by 1170 the EAP peer, using the NAK TLV. 1172 The mandatory bit in a TLV indicates that the peer must understand 1173 the TLV. A peer can determine that a TLV is unknown when it does 1174 not support the TLV; or when the TLV is corrupted. The mandatory 1175 bit does not indicate that the peer successfully applied the value 1176 of the TLV. The specification of a TLV could define additional 1177 conditions under which the TLV can be determined to be unknown. 1179 If an EAP peer finds an unknown TLV which is marked as mandatory; 1180 it must indicate a failure to the EAP server using the NAK TLV; and 1181 all the other TLVs in the message MUST be ignored. 1183 If an EAP peer finds an unknown TLV which is marked as optional; 1184 then it must ignore the TLV. The EAP peer is not required to inform 1185 the EAP server of unknown TLVs which are marked as optional. If the 1186 EAP peer finds that the packet has no TLVs, then it must send a 1187 response with EAP-TLV Response Packet. The Response packet may 1188 contain no TLVs. 1190 If an EAP server finds an unknown TLV which is marked as mandatory; 1191 the other TLVs in the message MUST be ignored. The EAP server can 1192 drop the connection or send an EAP-TLV request packet with NAK-TLV 1193 to the EAP client. 1195 An EAP-FAST TLV packet can be sequenced before or after any other 1196 EAP method. The packet does not have to contain any mandatory TLVs. 1198 Compliant EAP-FAST implementations must support the EAP-FAST TLV 1199 exchange, including processing of mandatory/optional settings on 1200 the TLV, the NAK TLV, the Crypto-Binding TLV, EAP Payload TLV, PAC 1201 TLV, Intermediate-Result TLV and the Result TLV. 1203 11.3 TLV format 1205 EAP-FAST TLVs are defined as follows: 1207 0 1 2 3 1208 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 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 |M|R| TLV Type | Length | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Value... 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 M 1217 0 - Non-mandatory TLV 1218 1 - Mandatory TLV 1220 R 1222 Reserved, set to zero (0) 1224 TLV Type 1226 A 14-bit field, denoting the TLV type. Allocated Types include: 1228 0 - Reserved 1229 1 - Reserved 1230 2 - Reserved 1231 3 - Result TLV 1232 4 - NAK TLV 1233 5 - Reserved 1234 6 - Reserved 1235 7 - Reserved 1236 8 - Reserved 1237 9 - EAP-Payload TLV 1238 10 - Intermediate-Result TLV 1239 11 - PAC TLV 1240 12 - Crypto-Binding TLV 1242 Length 1244 The length of the Value field in octets. 1246 Value 1248 The value of the TLV. 1250 11.4 Result TLV 1252 The Result TLV provides support for acknowledged Success and 1253 Failure messages within EAP-FAST. It is defined as follows: 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 |M|R| TLV Type | Length | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Status | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 M 1265 1 - Mandatory TLV 1267 R 1269 Reserved, set to zero (0) 1271 TLV Type 1273 3 - Result TLV 1275 Length 1277 2 1279 Status 1281 The status field is two octets. Values include: 1283 1 - Success 1284 2 - Failure 1286 11.5 NAK TLV 1288 The NAK TLV allows a peer to detect when TLVs that are not 1289 supported by the other peer. It is defined as follows: 1291 0 1 2 3 1292 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 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 |M|R| TLV Type | Length | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | Vendor-Id | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | NAK-Type | TLVs... 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 M 1303 1 - Mandatory TLV 1305 R 1307 Reserved, set to zero (0) 1309 TLV Type 1311 4 - NAK TLV 1313 Length 1315 Variable 1317 Vendor-Id 1319 The Vendor-Id field is four octets and contains the Vendor-Id of 1320 the TLV that was not supported. The high-order octet is 0 and 1321 the low-order 3 octets are the SMI Network Management Private 1322 Enterprise Code of the Vendor in network byte order. The Vendor- 1323 Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. 1324 For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI 1325 code. 1327 NAK-Type 1329 The NAK-Type field is two octets. The field contains the Type of 1330 the TLV that was not supported. A TLV of this Type MUST have 1331 been included in the previous packet. 1333 TLVs 1335 This field contains a list of TLVs, each of which MUST NOT have 1336 the mandatory bit set. These optional TLVs can be used in the 1337 future to communicate why the offending TLV was determined to be 1338 unsupported. 1340 11.6 Crypto-Binding TLV 1342 The Crypto-Binding TLV is used to prove that both peers 1343 participated in the sequence of authentications (specifically the 1344 TLS session and inner EAP methods that generate keys). 1346 Both the Binding Request and Binding Response use the same packet 1347 format; with the SubType field indicating whether it is a request 1348 or response. 1350 The Crypto-Binding TLV can be used to perform Cryptographic Binding 1351 after each EAP method in a sequence of EAP methods completes within 1352 the EAP-FAST Authentication Phase 2. The Crypto-Binding TLV MUST be 1353 used once during or before a Protected Termination along with a 1354 Result or Intermediate-Result TLV. 1356 This message format is used for the Binding Request and also the 1357 Binding Response. This uses TLV type CRYPTO-BINDING TLV. The format 1358 is as given below, with fields transmitted from left to right: 1360 0 1 2 3 1361 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 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 |M|R| TLV Type | Length | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Reserved | Version | Received Ver. | SubType | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | | 1368 ~ NONCE ~ 1369 | | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | | 1372 ~ Compound MAC ~ 1373 | | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 M 1378 1 - Mandatory TLV 1380 R 1382 Reserved, set to zero (0) 1384 TLV Type 1386 12 - Crypto-Binding TLV. 1388 Length 1390 56 1392 Reserved 1394 The Reserved field is a single octet and must be set to all 1395 zeros. 1397 Version 1399 The Version field is a single octet, which is set to the version 1400 of Crypto Binding TLV. For the crypto-binding TLV defined in 1401 this specification, it is set to 1. 1403 Received Version 1405 The Received Version field is a single octet and MUST be set to 1406 the EAP-FAST version number received during version negotiation. 1408 SubType 1410 The SubType field is 1 octet. 1411 0 - Binding Request 1412 1 - Binding Response 1414 Nonce 1416 The Nonce field is 32 octets. It contains a 256 bit random number 1417 generated by the server on request. The peer responds with the 1418 server nonce incremented by 1. 1420 Compound MAC 1422 The Compound MAC field is 20 octets. It contains an 1423 authentication tag for this TLV. It is calculated over entire 1424 Crypto-Binding TLV with Compound MAC field filled with zero. 1426 11.7 EAP-Payload TLV 1428 EAP-Payload TLV is used to encapsulate all the inner EAP messages. 1429 It is defined as follows: 1431 0 1 2 3 1432 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 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 |M|R| TLV Type | Length | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | EAP Packet... 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | TLVs... 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 M 1443 1 - Mandatory TLV 1445 R 1447 Reserved, set to zero (0) 1449 TLV Type 1451 9 1453 Length 1455 >=0 1457 EAP Packet 1459 This field contains a complete EAP packet, including the EAP 1460 header (Code, Identifier, Length, Type) fields. The length of 1461 this field is determined by the Length field of the encapsulated 1462 EAP packet. 1464 TLVs... 1466 This (optional) field contains a list of TLVs associated with the 1467 EAP packet field. The TLVs utilize the same format described 1468 Section 11.3, and MUST NOT have the mandatory bit set. The total 1469 length of this field is equal to the Length field of the EAP- 1470 Payload TLV, minus the Length field in the EAP header of the EAP 1471 packet field. 1473 11.8 Intermediate-Result TLV 1475 The Intermediate-Result TLV provides support for acknowledged 1476 intermediate Success and Failure messages within EAP-FAST. EAP-FAST 1477 implementations MUST support this TLV; and this TLV cannot be 1478 responded to with a NAK TLV. It is defined as follows: 1480 0 1 2 3 1481 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 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 |M|R| TLV Type | Length | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Status | TLVs... 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 M 1489 1 - Mandatory TLV 1491 R 1493 Reserved, set to zero (0) 1495 TLV Type 1497 10 1499 Length 1501 >=2 1503 Status 1505 The Status field is two octets. Values include: 1507 1 - Success 1508 2 - Failure 1510 TLVs 1512 This (optional) field is of indeterminate length, and contains 1513 the TLVs associated with the Intermediate-Result TLV, in the same 1514 format as described in Section 11.3. The TLVs in this field MUST 1515 NOT have the mandatory bit set. 1517 11.9 PAC TLV 1519 The PAC TLV provides support for acknowledged refreshing from the 1520 server side within EAP-FAST. A consistent PAC format will allow it 1521 to be used by multiple applications beyond EAP-FAST. A general PAC 1522 TLV format is defined as follows: 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 |M|R| TLV Type | Length | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | PAC Attributes... 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 M 1534 0 - Non-mandatory TLV 1535 1 - Mandatory TLV 1537 R 1539 Reserved, set to zero (0) 1541 TLV Type 1543 11- PAC TLV: 1545 Length 1547 The length of the PAC Attributes field in octets. 1549 PAC Attributes 1551 A list of PAC attributes in the TLV format. 1553 A PAC attribute is comprised of three general PAC fields 1554 encapsulated in a common format. The contents of these fields 1555 are described in succeeding sections. The PAC TLV contains all 1556 of the required information to appropriately distribute the 1557 peer with a PAC. 1559 11.9.1 Formats for PAC TLV attributes 1561 A common encapsulating format is used to convey the different 1562 fields that comprise a PAC attribute. The common encapsulation is 1563 defined as follows: 1565 0 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Type | Length | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Value... 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 Type 1575 The type field is two octets, denoting the attribute type. 1576 Allocated Types include: 1578 1 - PAC-Key 1579 2 - PAC-Opaque 1580 3 - CRED_LIFETIME 1581 4 - A-ID 1582 5 - I-ID 1583 6 - SERVER_PROTECTED_DATA 1584 7 - A-ID-Info 1585 8 - PAC-Acknowledgement 1586 9 - PAC-Info 1588 Length 1590 The Length filed is two octets, which contains the length of the 1591 Value field in octets. 1593 Value 1595 The value of the PAC Attribute. 1597 11.9.2 PAC-Key 1599 The PAC-Key is distributed as an attribute of type PAC-Key 1600 (Type=1). The key is a randomly generated octet string. The key 1601 is represented as an octet string whose length is determined by the 1602 length field. The generator of this key is the issuer of the 1603 credential, identified by the A-ID. 1605 0 1 2 3 1606 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | Type | Length | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | | 1611 ~ Key ~ 1612 | | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 Type 1617 1 - PAC-Key 1619 Length 1621 The Length filed is two octets. For this version of EAP-FAST, 1622 PAC-Key is 32 octets. 1624 Key 1626 The Key field contains the PAC-Key. 1628 11.9.3 PAC-Opaque 1630 The PAC-Opaque section contains data that is opaque to the 1631 recipient, the peer is not the intended consumer of PAC-Opaque and 1632 thus should not attempt to interpret it. A peer that has been 1633 issued a PAC-Opaque by a server MUST store that data, and present 1634 it back to the server as is, in the ClientHello SessionTicket 1635 extension field [TICKET]. If a client has opaque data issued to it 1636 by multiple servers, then it MUST store the data issued by each 1637 server separately. This requirement allows the client to maintain 1638 and use each opaque data as an independent PAC pairing, with a 1639 PAC-Key mapping to a PAC-Opaque identified by the A-ID. As there 1640 is a one to one correspondence between PAC-Key and PAC-Opaque, a 1641 peer must determine the PAC-Key and corresponding PAC-Opaque based 1642 on the A-ID provided in the EAP-FAST/Start message and the A-ID 1643 provided in the PAC-Info when it was provisioned with a PAC-Opaque. 1644 Each client must not parse any PAC-Opaque data given to it. 1646 As the PAC-Opaque is server specific, its contents and definition 1647 are specific to the issuer of the PAC, e.g. the PAC server. 1649 The PAC-Opaque field is embedded as part of the PAC TLV when the 1650 server has determined that the PAC must be refreshed and sends a 1651 new PAC. 1653 The PAC-Opaque field format is summarized as follows: 1655 0 1 2 3 1656 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 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Type | Length | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | Value ... 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 Type 1665 2 - PAC-Opaque 1667 Length 1669 The Length filed is two octets, which contains the length of the 1670 value field in octets. 1672 Value 1674 The Value field contains the actual data for PAC-Opaque 1676 The PAC-Opaque field is also passed from the peer to the server 1677 during the EAP-FAST Authentication Phase 1 conversation to enable 1678 the server to validate and recreate the PAC-Key. When it is passed 1679 from the peer, it is encapsulated as defined above in the 1680 ClientHello SessionTicket Extension [TICKET]. 1682 11.9.4 PAC-Info 1684 PAC-Info is comprised of a set of PAC attributes. At minimum, the 1685 A-ID TLV is required to convey the issuing identity to the peer. 1686 Other optional fields may be included in the PAC to provide more 1687 information to the peer. It is a container attribute for various 1688 types of information each of which is encoded in conformance to the 1689 PAC TLV field format as defined in Section 11.9.1. 1691 0 1 2 3 1692 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 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Type | Length | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Attributes... 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 Type 1701 9 - PAC-Info 1703 Length 1705 The Length filed is two octets, which contains the length of the 1706 Attributes field in octets. 1708 Attributes 1710 The Attributes field contains a list of PAC Attributes. 1712 Each mandatory and optional field type is defined as follows: 1714 CRED_LIFETIME (type 3) 1716 This is a 4 octet quantity representing the expiration time of the 1717 credential in UNIX UTC time. This is a mandatory field contained 1718 in the PAC-Opaque field to enable the server to validate the PAC. 1719 This field may also be optionally provided to the peer as part of 1720 PAC-Info. 1722 A-ID (type 4) 1724 Authority identifier is the name of the authority that issued the 1725 token. The A-ID is intended to be unique across all issuing 1726 servers to avoid namespace collisions. Server implementations 1727 should use measures to ensure the A-ID used is globally unique to 1728 avoid name collisions. The A-ID is used by the peer to determine 1729 which PAC to employ. Similarly, the server uses the A-ID to both 1730 authenticate the PAC-Opaque and determine which master key was 1731 used to issue the PAC. This field is mandatory and included in 1732 both the PAC-Opaque and as the first TLV comprising PAC-Info. 1734 I-ID (type 5) 1736 Initiator identifier is the peer identity associated with the 1737 credential. The server employs the I-ID in the EAP-FAST Phase 2 1738 conversation to validate that the same peer identity used to 1739 execute EAP-FAST Phase 1 is also used in at minimum one inner EAP 1740 method in EAP-FAST Phase 2. This field is a mandatory field in 1741 PAC-Opaque and may optionally be included in the PAC-Info. If the 1742 AS is enforcing the I-ID validation on inner EAP method, then I-ID 1743 is mandatory in PAC-Info, to enable the client to also enforce a 1744 unique PAC for each unique user. If I-ID is missing from the PAC- 1745 Info, it is assumed that the PAC can be used for multiple users 1746 and client will not enforce the unique PAC per user policy. 1748 A-ID-Info (type 7) 1750 Authority Identifier Information is a mandatory TLV intended to 1751 provide a user-friendly name for the A-ID. It may contain the 1752 enterprise name and server name in a more human-readable format. 1753 This TLV serves as an aid to the peer to better inform the end- 1754 user about the A-ID. This field is a mandatory field in the 1755 PAC-Info. 1757 11.9.5 PAC-Acknowledgement TLV 1759 The PAC-Acknowledgement TLV is used to acknowledge the receipt of 1760 the PAC TLV by the peer. Peer sends this TLV in response to the PAC 1761 TLV to indicate the result of the retrieving and storing of the new 1762 PAC. 1764 0 1 2 3 1765 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 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | Type | Length | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | Result | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 Type 1774 8 - PAC-Acknowledgement 1776 Length 1778 2 1780 Result 1782 1 - Success 1783 2 - Failure 1785 11.10 TLS SessionTicket Extension 1787 EAP-FAST employs the TLS SessionTicket extension (as defined in 1788 [TICKET]) to enable the client to convey the opaque credential, 1789 PAC-Opaque, to the server for the server to restore its session 1790 state. The SessionTicket extension format follows the [RFC3546] 1791 syntax and is defined in [TICKET] and duplicated as follows: 1793 struct { 1794 opaque _ticket<0..2^16-1> 1795 } SessionTicket; 1797 The extension type number for the TLS SessionTicket extension used 1798 in EAP-FAST is 35. 1800 12. Security Considerations 1802 EAP-FAST is designed with a focus on wireless media, where the 1803 medium itself is inherent to eavesdropping. Whereas in wired 1804 media, an attacker would have to gain physical access to the wired 1805 medium; wireless media enables anyone to capture information as it 1806 is transmitted over the air, enabling passive attacks. Thus, 1807 physical security can not be assumed and security vulnerabilities 1808 are far greater. The threat model used for the security evaluation 1809 of EAP-FAST is that defined in the RFC 3748 [EAP]. 1811 12.1 Mutual Authentication and Integrity Protection 1813 EAP-FAST as a whole, provides message and integrity protection by 1814 establishing a secure tunnel for protecting the authentication 1815 method(s). The confidentiality and integrity protection is that 1816 defined by TLS [RFC 2246] and provides the same security strengths 1817 afforded by TLS employing a strong entropy shared master secret. 1819 When EAP-FAST is invoked for enabling network access, mutual 1820 authentication is first achieved by proof of a mutually shared 1821 unique PAC-Key during the tunnel establishment. Further, the 1822 Result TLV is enforced to be run after any EAP method that supports 1823 (mutual) authentication ensuring that it was the same peer and AS 1824 that communicated in all transpired methods (including tunnel 1825 establishment). 1827 The Result TLV is protected and conveys the true Success or Failure 1828 of EAP-FAST and should be used as the indicator of its success or 1829 failure respectively. However, as EAP must terminate with a 1830 clear text EAP Success or Failure, a peer will also receive a 1831 clear text EAP success or failure. The received clear text EAP 1832 success or failure must match that received in the Result TLV; the 1833 peer may silently discard those clear text EAP success or failure 1834 messages that do not coincide with the status sent in the protected 1835 Result TLV. 1837 12.2 Method Negotiation 1839 As is true for any negotiated EAP protocol, NAK packets used to 1840 suggest an alternate authentication method are sent unprotected and 1841 as such, are subject to spoofing. During EAP method negotiation, 1842 NAK packets may be interjected as active attacks to negotiate 1843 down to a weaker form of authentication, such as EAP-MD5 (which 1844 only provides one way authentication and does not derive a key). 1845 Since a subsequent protected EAP conversation can take place within 1846 the TLS session, selection of EAP-FAST as an authentication method 1847 does not limit the potential secondary authentication methods. As a 1848 result, the only legitimate reason for a peer to NAK EAP-FAST as an 1849 authentication method is that it does not support it. Where the 1850 additional security of EAP-FAST is required, the server shall best 1851 determine how to respond to a NAK as this is beyond the scope of 1852 this specification. 1854 Inner method negotiation is protected by the mutually authenticated 1855 TLS tunnel established in EAP-FAST and immune to attacks. 1857 12.3 Separation of the EAP Server and the Authenticator 1859 When EAP-FAST is successfully invoked to gain network access, the 1860 EAP endpoints will mutually authenticate, and derive a session key 1861 for subsequent use in link layer security. Since it is presumed 1862 that the peer and EAP client reside on the same machine, it is 1863 necessary for the EAP client module to pass the session key to the 1864 link layer encryption module. 1866 As EAP-FAST is defined to achieve mutual authentication between a 1867 peer and AS, it will not achieve direct authentication to the 1868 Authenticator (which is true for most if not all currently 1869 specified EAP methods). 1871 It is implied that there is an established trust between 1872 Authenticator and AS before the AS securely distributes the session 1873 keys to the authenticator. Using the transitive property and the 1874 authenticator to AS trust assumption, if the AS trusts the 1875 authenticator and distributes the session key to the authenticator, 1876 and the peer has successfully gained authorization by mutually 1877 deriving fresh session keys, the peer may then presume trust with 1878 the authenticator who can prove it has those session keys. Note 1879 however, that this presumed trust does not authenticate the 1880 authenticator to the peer, it merely proves that the AS has a trust 1881 relationship with said authenticator. Further, it is presumed that 1882 a secure mechanism is used by the AS to distribute the session key 1883 to the authenticator. 1885 In the case of the AS and the home AAA server logical model, 1886 similar security properties hold as that between the AS and 1887 authenticator. Though in general, it is highly recommended that 1888 the AAA server be reside on the same host as the AS. 1889 In both cases, the presumed trust between authenticator and AS as 1890 well as AS and AAA server as well as the security in the transport 1891 (such as IPsec) and key delivery (such as NIST approved key 1892 wrapping) mechanisms for these links are outside the scope of the 1893 EAP-FAST specification. Without these presumed trusts and secure 1894 transport mechanisms, security vulnerabilities will exist. 1896 12.4 Separation of Phase 1 and Phase 2 Servers 1898 Separation of the EAP-FAST Phase 1 from the Phase 2 conversation is 1899 not recommended. Without a trust relationship and proper 1900 protection (such as IPsec) for RADIUS, by allowing a the Phase 1 1901 conversation to be terminated at a different (proxy) AS (AS1) than 1902 the Phase 2 conversation (terminated at AS2), vulnerabilities are 1903 introduced since clear text transmission between AS1 and AS2 ensue. 1904 Some vulnerabilities include: 1906 * Loss of identity protection 1907 * Offline dictionary attacks 1908 * Lack of policy enforcement 1910 In order to find the proper EAP-FAST destination, the peer SHOULD 1911 place a Network Access Identifier (NAI) conforming to [RFC2486] in 1912 the clear-text Identity Response. 1914 There may be cases where a natural trust relationship exists 1915 between the (foreign) authentication server and final EAP server, 1916 such as on a campus or between two offices within the same company, 1917 where there is no danger in revealing the identity of the station 1918 to the authentication server. In these cases, using a proxy 1919 solution without end to end protection of EAP-FAST MAY be used. The 1920 EAP-FAST encrypting/decrypting gateway SHOULD provide support for 1921 IPsec protection of RADIUS in order to provide confidentiality for 1922 the portion of the conversation between the gateway and the EAP 1923 server, as described in [RFC3162]. 1925 12.5 Mitigation of Known Vulnerabilities and Protocol Deficiencies 1927 EAP-FAST addresses the known deficiencies and weaknesses in the EAP 1928 method. By employing a shared secret between the peer and server 1929 to establish a secured tunnel, EAP-FAST enables: 1931 * Per packet confidentiality and integrity protection 1932 * User identity protection 1933 * Better support for notification messages 1934 * Protected EAP inner method negotiation 1935 * Sequencing of EAP methods 1936 * Strong mutually derived master session keys 1937 * Support for fragmentation and reassembly 1938 * Acknowledged success/failure indication 1939 * Faster re-authentications through session resumption 1940 * Mitigation of dictionary attacks 1941 * Mitigation of man-in-the-middle attacks 1942 * Mitigation of some denial of service attacks 1944 It should be noted that EAP-FAST as in many other authentication 1945 protocols, a denial of service attack can be easily mounted by 1946 adversaries imposing as either peer or AS and failing to present 1947 the proper credential. This is an inherent problem in most 1948 authentication or key agreement protocols and is so noted for EAP- 1949 FAST as well. 1951 EAP-FAST protection addresses a number of weaknesses present in 1952 LEAP, PEAPv1, EAP-TTLS and the inner EAP methods used in the EAP- 1953 FAST Authentication Phase 2 conversation. These weaknesses have 1954 been described in draft-puthenkulam-eap-binding-03.txt. 1956 EAP-FAST was designed with a focus on protected authentication 1957 methods that typically rely on weak credentials, such as password 1958 based secrets. To that extent, the EAP-FAST Authentication 1959 mitigates several vulnerabilities such as dictionary attacks by 1960 protecting the weak credential based authentication method. The 1961 protection is based on strong cryptographic algorithms such as RC4 1962 and HMAC-SHA1 to provide message confidentiality and integrity 1963 respectively. The keys derived for the protection relies on strong 1964 random challenges provided by both peer and AS as well as a shared 1965 secret with strong entropy (minimally 32 octets). It is 1966 recommended that peers provide strong random number generators that 1967 can satisfy the criteria as that described by NIST Special 1968 Publication 800-22b (e.g. NIST SP800-22b). The AS acting as the 1969 PAC distributor must generate unique and randomly generated 32 1970 octet keys for each peer. 1972 12.5.1 User Identity Protection and Verification 1974 As EAP-FAST employs TLS to establish a secure tunnel, the initial 1975 Identity request/response may be omitted as it must be transmitted 1976 in the clear and thus subject to snooping and forgery. It may be 1977 omitted also in deployments where it is known that all users are 1978 required to authenticate with EAP-FAST. Alternately, an anonymous 1979 identity may be used in the Identity response. 1981 If the initial Identity request/response has been tampered with, 1982 the AS may be unable to verify the peer's identity. For example, 1983 the peer's userID may not be valid or may not be within a realm 1984 handled by the AS. Rather than attempting to proxy the 1985 authentication to the server within the correct realm, the AS 1986 should terminate the conversation. 1988 The EAP-FAST peer can present the server with multiple identities. 1989 This includes the claim of identity within the initial EAP- 1990 Response/Identity (MyID) packet, which is typically used to route 1991 the EAP conversation to the appropriate home back end AS. There may 1992 also be subsequent EAP-Response/Identity packets sent by the peer 1993 once the secure tunnel has been established. 1995 The PAC-Opaque field conveyed by the peer to the AS contains the 1996 peer's identity that should be validated with at least one identity 1997 presented in the EAP-FAST Authentication Phase 2 conversation. 1998 This ensures that the PAC-Key is employed by the intended peer. 1999 Though EAP-FAST implementations should not attempt to compare the 2000 EAP-FAST Authentication Phase 1 Identity disclosed in the EAP 2001 Identity response packet with those Identities claimed in Phase 2; 2002 the AS should match the identity disclosed in the PAC-Opaque field 2003 with at least one identity disclosed in EAP-FAST Authentication 2004 Phase 2. 2006 12.5.2 Dictionary Attack Resistance 2008 EAP-FAST was designed with a focus on protected authentication 2009 methods that typically rely on weak credentials, such as password 2010 based secrets. To that extent, by establishing a mutually 2011 authenticated protected tunnel, EAP-FAST mitigates dictionary 2012 attacks by protecting the weak credential based authentication 2013 method. The protection is based on strong cryptographic algorithms 2014 such as RC4 and HMAC-SHA1 to provide message confidentiality and 2015 integrity respectively. The keys derived for the protection relies 2016 on strong random challenges provided by both peer and AS as well as 2017 a strong entropy (minimally 32 octet) shared secret. The AS acting 2018 as the PAC distributor MUST generate unique and randomly generated 2019 32 octet keys for each peer. 2021 12.5.3 Protection against MitM Attacks 2023 The recommended solution is to always deploy authentication methods 2024 with protection of EAP-FAST. If a deployment chooses to allow an 2025 EAP method protected by EAP-FAST without protection of EAP-FAST at 2026 the same time, then this opens up a possibility of a Compound 2027 Authentication Binding man-in-the-middle attack [MITM]. 2029 A man-in-the-middle can spoof the client to authenticate to it 2030 instead of the real EAP server; and forward the authentication to 2031 the real server over a protected tunnel. Since the attacker has 2032 access to the keys derived from the tunnel, it can gain access to 2033 the network. 2035 EAP-FAST prevents this attack in two ways: 2037 1. An adversary must have the corresponding peer's PAC-Key to 2038 mutually authenticate during EAP-FAST Authentication Phase 1 2039 establishment of a secure tunnel; and 2041 2. By using the keys generated by the inner authentication method 2042 in the crypto-binding exchange described in above protected 2043 termination section 6.5. 2045 Both compound MAC and compound session key approaches are used to 2046 prevent the aforementioned man-in-the-middle attack. Both the peer 2047 and the EAP server MUST derive compound MAC and compound session 2048 keys using the procedure described in Section 6.7. 2049 As a strong PAC-Key is used to establish mutual authentication in 2050 EAP-FAST Phase 1, this attack is also prevented if the inner 2051 authentication method does not generate keys. Thus, most EAP 2052 authentication methods are protected from these MitM attacks when 2053 protected by EAP-FAST. 2055 To summarize, EAP-FAST Authentication mitigates most MitM attacks 2056 in the following way: 2058 * Identity binding with PAC-Key: in presenting the PAC-Opaque 2059 field to the AS, a peer is presenting an authenticated credential. 2060 With the user identity serving as another validation point for the 2061 inner EAP authentication method, a MitM may not interject and 2062 impersonate itself as the peer unless it has recovered the PAC-Key 2063 as well as the PAC-Opaque field. Thus, the PAC-Key binding to an 2064 Identity prevents an adversary from interjection regardless of 2065 whether the authentication method generates session keys, 2067 * Cryptographic binding of EAP-FAST Phase 1 and all methods within 2068 Phase 2: by cryptographically binding key material generated in 2069 all methods, peer and AS are assured that they were the sole 2070 participants of all transpired methods. 2072 12.5.4 PAC Validation with User Credentials 2074 The PAC-Opaque field is consumed by the AS during a network access 2075 EAP-FAST invocation to both acquire and validate the authenticity 2076 of the PAC credential. However, during the EAP-FAST Phase 1 2077 conversation it validates the peer based on the secret, PAC-Key and 2078 not on the identity. Further, since the EAP-FAST Phase 1 2079 conversation occurs in clear text, it is feasible for an adversary 2080 to acquire a PAC-Opaque credential. 2082 While a PAC-Opaque credential can be easily acquired, the shared 2083 secret, PAC-Key is not discernible from the PAC-Opaque field. Thus, 2084 an adversary must resort to a brute force attack to gain the PAC- 2085 Key from PAC-Opaque information. 2087 Another feasible scenario due to the clear text transmission is the 2088 spoofing of the PAC-Opaque field. While the PAC-Opaque is 2089 authenticated to mitigate forgery, a denial of service and 2090 potential user lockout (based on deployment configurations that may 2091 choose to lock a peer after a configurable number of failed 2092 attempts) is feasible. 2094 The final validation and binding of the PAC credential is the 2095 identity validation in the EAP-FAST Phase 2 conversation. A 2096 compliant implementation of EAP-FAST MUST match the identity 2097 presented to the AS in the PAC-Opaque field with at minimum one of 2098 the identities provided in the EAP-FAST Phase 2 authentication 2099 method. This validation provides another binding to ensure that 2100 the intended peer (based on identity) has successfully completed 2101 the EAP-FAST Phase 1 and proved identity in the Phase 2 2102 conversations. This validation helps mitigate the MitM attack as 2103 described in Section 12.5.3. 2105 12.6 PAC Storage Considerations 2107 The main premise behind EAP-FAST is to protect the authentication 2108 stream over the media link. However, physical security is still an 2109 issue. Some care should be taken to protect the PAC on both the 2110 peer and server. The peer must store securely both the PAC-Key and 2111 PAC-Opaque, while the server must secure storage of its security 2112 association context used to consume the PAC-Opaque. Additionally, 2113 if manual provisioning is employed, the transportation mechanism 2114 used to distribute the PAC must also be secured. 2116 Most of the attacks described here would require some level of 2117 effort to execute; conceivably greater than their value. The main 2118 focus therefore, should be to ensure that proper protections are 2119 used on both the client and server. There are a number of 2120 potential attacks which can be considered against secure key 2121 storage such as: 2123 * weak passphrases 2124 On the client side, keys are usually protected by a passphrase. 2125 On some environments, this passphrase may be associated with the 2126 user's password. In either case, if an attacker can obtain the 2127 encrypted key for a range of users, he may be able to 2128 successfully attack a weak passphrase. The tools are already in 2129 place today to allow an attacker to easily attack all Outlook or 2130 Outlook Express users in an enterprise environment. Most viruses 2131 or worms of this sort attract attention to themselves by their 2132 action, but that need not be the case. A simple, genuine 2133 appearing e-mail could surreptitiously access keys from known 2134 locations and e-mail them directly to the attacker, attracting 2135 little notice. 2137 * key finding attacks 2138 Key finding attacks are usually mentioned in reference to web 2139 servers, where the private SSL key may be stored securely, but at 2140 some point it must be decrypted and stored in system memory. An 2141 attacker with access to system memory can actually find the key 2142 by identifying their mathematical properties. To date, this 2143 attack appears to be purely theoretical and primarily acts to 2144 argue strongly for secure access controls on the server itself to 2145 prevent such unauthorized code from executing. 2147 * key duplication, key substitution, key modification 2148 Once keys are accessible to an attacker on either the client or 2149 server, they fall under three forms of attack: key duplication, 2150 key substitution and key modification. The first option would be 2151 the most common, allowing the attacker to masquerade as the user 2152 in question. The second option could have some use if an 2153 attacker could implement it on the server. 2155 Another consideration is the use of secure mechanisms afforded by 2156 the particular device. For instance, some laptops enable secure 2157 key storage through a special chip. It would be worthwhile for 2158 implementations to explore the use of such a mechanism. 2160 12.7 Protecting against Forged Clear Text EAP Packets 2162 As described earlier, EAP Success and EAP Failure packets are in 2163 general sent in clear text and may be forged by an attacker without 2164 fear of detection. Forged EAP Failure packets can be used to 2165 convince an EAP peer to disconnect. Forged EAP Success packets may 2166 be used by any rogue to convince a peer to let itself access the 2167 network, even though the authenticator has not authenticated itself 2168 to the peer. 2170 By providing message confidentiality and integrity, EAP-FAST 2171 provides protection against these attacks. Once the peer and AS 2172 initiate the EAP-FAST Authentication Phase 2, compliant EAP-FAST 2173 implementations must silently discard all clear text EAP messages 2174 unless both the EAP-FAST peer and server have indicated success or 2175 failure using a protected mechanism. Protected mechanisms include 2176 TLS alert mechanism and the protected termination mechanism 2177 described in Section 6.5. 2179 The success/failure decisions sent by a protected mechanism 2180 indicate the final decision of the EAP-FAST authentication 2181 conversation. After a success/failure result has been indicated by 2182 a protected mechanism, the EAP-FAST peer can process unprotected 2183 EAP success and EAP failure message; however the peer must ignore 2184 any unprotected EAP success or failure messages where the result 2185 does not match the result of the protected mechanism. 2187 To abide by RFC 3748, the AS must send a clear text EAP Success or 2188 EAP Failure packet to terminate the EAP conversation, so that no 2189 response is possible. However, since EAP Success and EAP Failure 2190 packets are not retransmitted, if the final packet is lost, then 2191 authentication will fail. As a result, where packet loss is 2192 expected to be non-negligible, unacknowledged success/failure 2193 indications lack robustness. 2195 While an EAP-FAST protected EAP Success or EAP Failure packet 2196 should not be a final packet in an EAP-FAST conversation, it may be 2197 feasible based on the conditions stated above and construed as an 2198 optimization savings of a full round-trip in low packet loss 2199 environments. 2201 12.8 Implementation 2203 Both server and in particular, client implementations must provide 2204 a suitably strong PRNG to ensure good entropy challenges. Suitable 2205 recommendations for PRNGs can be found in PKCS#5, PKCS#11 and 2206 criteria for suitable PRNGS are also defined by NIST Special 2207 Publication 800-22b. 2209 12.9 Security Claims 2211 This section provides needed security claim requirement for 2212 RFC 3748 [EAP]. 2214 Auth. mechanism: Tunneled authentication as well as 2215 pre-shared key. 2216 Ciphersuite negotiation:Yes. See [RFC2246]. 2217 Mutual authentication: Yes. See Section 12.1. 2218 Integrity protection: Yes. See Section 12.1. Only EAP Type 2219 Data field and inner EAP methods 2220 contained in this field are 2221 protected. 2222 Replay protection: Yes. See [RFC2246]. 2223 Confidentiality: Yes. See [RFC2246]. 2224 Key derivation: Yes. See Section 6.6. 2225 Key strength: TLS key strength, may be enhanced by 2226 binding keys with inner methods 2227 Dictionary attack prot.:Yes. See Section 12.5.2. 2228 Key hierarchy: Yes. See Section 6.6. 2229 Fast reconnect: Yes. See Section 9. 2230 Cryptographic binding: Yes. See Section 6.7. 2231 Session independence: Yes. See [RFC2716]. 2232 Fragmentation: Yes. See Section 10. 2233 Channel binding: No. 2235 13. IANA Considerations 2237 This section provides guidance to the Internet Assigned Numbers 2238 Authority (IANA) regarding registration of values related to the 2239 EAP protocol, in accordance with BCP 26, [RFC2434]. 2241 There is a namespace in EAP-FAST that requires registration: TLV 2242 Types. These numbers may be assigned by First Come First Served 2243 [RFC2434]. 2245 14. References 2247 14.1 Normative 2249 [RFC2246] 2250 Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2251 2246, January 1999. 2253 [EAP] 2254 Blunk, L., et. al., "Extensible Authentication Protocol 2255 (EAP)", RFC 3748, June 2004. 2257 [RFC3268] 2258 Chown, P., "Advanced Encryption Standard (AES) Ciphersuites 2259 for Transport Layer Security (TLS)", RFC 3268, June 2002. 2261 [RFC2119] 2262 Bradner, S., "Key words for use in RFCs to indicate 2263 Requirement Levels", RFC 2119, March 1997. 2265 [RFC3546] 2266 Blake-Wilson, S., et al, "Transport Layer Security (TLS) 2267 Extensions", RFC 3546, June 2003. 2269 [TICKET] 2270 Salowey, J., et al, "TLS Session Resumption without 2271 Server-Side State", draft-salowey-tls-ticket-02.txt, 2272 February 2005 2274 14.2 Informative 2276 [RFC2434] 2277 Narten, T., and H. Alvestrand, "Guidelines for Writing an 2278 IANA Considerations Section in RFCs", RFC 2434, October 2279 1998. 2281 [RFC2279] 2282 Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2283 RFC 2279, January 1998. 2285 [RFC2631] 2286 Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2287 2631, January 1999. 2289 [RFC 2716] 2290 Aboba, B. and Simon, D, "PPP EAP TLS Authentication 2291 Protocol", RFC 2716, October 1999. 2293 [SHARED KEYS IN TLS] 2294 Gutmann, P., "Use of Shared Keys in the TLS Protocol", 2295 draft-ietf-tls-sharedkeys-02.txt (expired), October 2003. 2297 [IKEv2] 2298 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2299 draft-ietf-ipsec-ikev2-17 (work in progress), September 2300 2004. 2302 [PEAP] 2303 Palekar, et. al., "Protected EAP Protocol (PEAP) Version 2", 2304 draft-josefsson-pppext-eap-tls-eap-10 (work in progress), 2305 October 2004 2307 [RFC3526] 2308 Kivinen, T., "More Modular Exponential (MODP) DIffie-Hellman 2309 groups for Internet Key Exchange (IKE)", RFC 3526, May 2003 2311 [MITM] 2312 Puthenkulam, J., "The Compound Authentication Binding 2313 Problem", draft-puthenkulam-eap-binding-04 (expired), 2314 October 2003. 2316 [RFC2486BIS] 2317 Aboba, et. al., "The Network Access Identifier", draft- 2318 ietf-radext-rfc2486bis-05.txt (work in progress), 2319 February, 2005. 2321 [RFC2548] 2322 Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2323 2548, March 1999. 2325 [EAP-TTLS] 2326 Funk & Blake-Wilson, "EAP Tunneled TLS Authentication 2327 Protocol", draft-funk-eap-ttls-v0-00.txt (work in 2328 progress), February 2005 2330 [TLS-PSK] 2331 Eronen & Tschofenig, "Pre-Shared Key Ciphersuites for 2332 Transport Layer Security (TLS)", draft-ietf-tls-psk-07, 2333 March 2005 2335 15. Acknowledgments 2337 The EAP-FAST design and protocol specification is based on the 2338 ideas and hard efforts of Pad Jakkahalli, Mark Krischer, Doug 2339 Smith, Ilan Frenkel and Jeremy Steiglitz of Cisco Systems, Inc. 2341 16. Authors' Addresses 2343 Nancy Cam-Winget 2344 Cisco Systems 2345 3625 Cisco Way 2346 San Jose, CA 95134 2347 US 2348 Phone: +1 408 853 0532 2349 E-mail: ncamwing@cisco.com 2350 David McGrew 2351 Cisco Systems 2352 San Jose, CA 95134 2353 US 2354 E-mail: mcgrew@cisco.com 2356 Joseph Salowey 2357 Cisco Systems 2358 2901 3rd Ave 2359 Seattle, WA 98121 2360 US 2361 Phone: +1 206 256 3380 2362 E-mail: jsalowey@cisco.com 2364 Hao Zhou 2365 Cisco Systems 2366 4125 Highlander Parkway 2367 Richfield, OH 44286 2368 US 2369 Phone : +1 330 523 2132 2370 E-mail: hzhou@cisco.com 2372 17. Appendix A: Examples 2374 17.1 Successful Authentication 2376 The following exchanges show a successful EAP-FAST authentication 2377 with PAC refreshment, the conversation will appear as follows: 2379 Authenticating Peer Authenticator 2380 ------------------- ------------- 2381 <- EAP-Request/ 2382 Identity 2383 EAP-Response/ 2384 Identity (MyID1) -> 2386 <- EAP-Request/ 2387 EAP-Type=EAP-FAST, V=1 2388 (EAP-FAST Start, S bit set, A-ID) 2390 EAP-Response/ 2391 EAP-Type=EAP-FAST, V=1 2392 (TLS client_hello with 2393 PAC-Opaque)-> 2395 <- EAP-Request/ 2396 EAP-Type=EAP-FAST, V=1 2397 (TLS server_hello, 2398 (TLS change_cipher_spec, 2399 TLS finished) 2401 EAP-Response/ 2402 EAP-Type=EAP-FAST, V=1 -> 2403 (TLS change_cipher_spec, 2404 TLS finished) 2406 TLS channel established 2407 (messages sent within the TLS channel) 2409 <- EAP Payload TLV, EAP-Request, 2410 EAP-GTC, Challenge 2412 EAP Payload TLV, EAP-Response, 2413 EAP-GTC, Response with both 2414 user name and password) -> 2416 optional additional exchanges (new pin mode, 2417 password change etc.) ... 2419 <- Intermediate-Result TLV (Success) 2420 Crypto-Binding TLV(Version=0,SNonce, 2421 CompoundMAC) 2423 Intermediate-Result TLV (Success) 2424 Crypto-Binding TLV(Version=0, 2425 CNonce, CompoundMAC) -> 2427 <- Result TLV (Success) 2428 (Optional PAC TLV) 2430 Result TLV (Success) 2431 (PAC TLV Acknowledgment) -> 2433 TLS channel torn down 2434 (messages sent in clear text) 2436 <- EAP-Success 2438 17.2 Failed Authentication 2440 The following exchanges show a failed EAP-FAST authentication due 2441 to wrong user credentials, the conversation will appear as follows: 2443 Authenticating Peer Authenticator 2444 ------------------- ------------- 2445 <- EAP-Request/ 2446 Identity 2448 EAP-Response/ 2449 Identity (MyID1) -> 2450 <- EAP-Request/ 2451 EAP-Type=EAP-FAST, V=1 2452 (EAP-FAST Start, S bit set, A-ID) 2454 EAP-Response/ 2455 EAP-Type=EAP-FAST, V=1 2456 (TLS client_hello with 2457 PAC-Opaque)-> 2459 <- EAP-Request/ 2460 EAP-Type=EAP-FAST, V=1 2461 (TLS server_hello, 2462 (TLS change_cipher_spec, 2463 TLS finished) 2465 EAP-Response/ 2466 EAP-Type=EAP-FAST, V=1 -> 2467 (TLS change_cipher_spec, 2468 TLS finished) 2470 TLS channel established 2471 (messages sent within the TLS channel) 2473 <- EAP Payload TLV, EAP-Request, 2474 EAP-GTC, Challenge 2476 EAP Payload TLV, EAP-Response, 2477 EAP-GTC, Response with both 2478 user name and password) -> 2480 <- EAP Payload TLV, EAP-Request, 2481 EAP-GTC, error 2483 EAP Payload TLV, EAP-Response, 2484 EAP-GTC, empty data packet to 2485 acknowledge unrecoverable error) -> 2487 <- Result TLV (Failure) 2489 Result TLV (Failure) -> 2491 TLS channel torn down 2492 (messages sent in clear text) 2494 <- EAP-Failure 2496 18. Appendix B: EAP-FAST PRF (T-PRF) 2498 EAP-FAST employs a simpler PRF than the TLS PRF where possible. 2499 For instance, when generating the master_secret, master session 2500 keys and cryptographic binding keys and computations, EAP-FAST 2501 employs the following PRF construction: 2503 PRF(key, label, seed) = HMAC-SHA1(key, label + "\0" + seed) 2505 Where '+' indicates concatenation and "\0" is a NULL character. 2506 Label is intended to be a unique label for each different use of 2507 the T-PRF. 2509 To generate the desired OutputLength octet length of key material, 2510 the T-PRF is iterated as follows: 2512 T-PRF (Key, S, OutputLength) = T1 + T2 + T3 + T4 + ... 2513 Where S = label + 0x00 + seed; and 2515 T1 = HMAC-SHA1 (Key, S + OutputLength + 0x01) 2516 T2 = HMAC-SHA1 (Key, T1 + S + OutputLength + 0x02) 2517 T3 = HMAC-SHA1 (Key, T2 + S + OutputLength + 0x03) 2518 T4 = HMAC-SHA1 (Key, T3 + S + OutputLength + 0x04) 2520 OutputLength is a two octet value that is represented in big endian 2521 order. The NULL character, 0x00 shall be present when a label 2522 string is provided. Also note that the seed value may be optional 2523 and may be omitted as in the case of the MSK derivation described 2524 in Section 6.8. 2526 Where each Ti generates 20-octets of keying material, the last Tn 2527 may be truncated to accommodate the desired length specified by 2528 OutputLength. 2530 19. Appendix C: Test Vectors 2532 19.1 Key derivation 2534 PAC KEY: 2536 0B 97 39 0F 37 51 78 09 81 1E FD 9C 6E 65 94 2B 2537 63 2C E9 53 89 38 08 BA 36 0B 03 7C D1 85 E4 14 2539 Server_hello Random 2541 3F FB 11 C4 6C BF A5 7A 54 40 DA E8 22 D3 11 D3 2542 F7 6D E4 1D D9 33 E5 93 70 97 EB A9 B3 66 F4 2A 2544 Client_hello Random 2546 00 00 00 02 6A 66 43 2A 8D 14 43 2C EC 58 2D 2F 2547 C7 9C 33 64 BA 04 AD 3A 52 54 D6 A5 79 AD 1E 00 2548 Master_secret = T-PRF(PAC-Key, 2549 "PAC to master secret label hash", 2550 server_random + Client_random, 2551 48) 2553 4A 1A 51 2C 01 60 BC 02 3C CF BC 83 3F 03 BC 64 2554 88 C1 31 2F 0B A9 A2 77 16 A8 D8 E8 BD C9 D2 29 2555 38 4B 7A 85 BE 16 4D 27 33 D5 24 79 87 B1 C5 A2 2557 Key_block = PRF(Master_secret, 2558 "key expansion", 2559 server_random + Client_random) 2561 59 59 BE 8E 41 3A 77 74 8B B2 E5 D3 60 AC 4D 35 2562 DF FB C8 1E 9C 24 9C 8B 0E C3 1D 72 C8 84 9D 57 2563 48 51 2E 45 97 6C 88 70 BE 5F 01 D3 64 E7 4C BB 2564 11 24 E3 49 E2 3B CD EF 7A B3 05 39 5D 64 8A 44 2565 11 B6 69 88 34 2E 8E 29 D6 4B 7D 72 17 59 28 05 2566 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 2567 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71 2569 Session Key Seed 2571 D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 2572 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 2573 FF 92 A8 B4 C6 42 28 71 2575 IMCK = T-PRF(SKS, 2576 "Inner Methods Compound Keys", 2577 ISK, 2578 60) 2580 Note: ISK is 32 bytes 0's. 2582 16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80 2583 4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1 2584 18 40 7B 56 BE EA A7 C5 76 5D 8F 0B C5 07 C6 B9 2585 04 D0 69 56 72 8B 6B B8 15 EC 57 7B 2587 [SIMCK 1] 2588 16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80 2589 4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1 2590 18 40 7B 56 BE EA A7 C5 2592 MSK = T-PRF(S-IMCKn, 2593 "Session Key Generating Function", 2594 64); 2596 4D 83 A9 BE 6F 8A 74 ED 6A 02 66 0A 63 4D 2C 33 2597 C2 DA 60 15 C6 37 04 51 90 38 63 DA 54 3E 14 B9 2598 27 99 18 1E 07 BF 0F 5A 5E 3C 32 93 80 8C 6C 49 2599 67 ED 24 FE 45 40 A0 59 5E 37 C2 E9 D0 5D 0A E3 2601 19.2 Crypto-Binding MIC 2603 [Compound MAC Key 1] 2604 76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8 2605 15 EC 57 7B 2607 [Crypto-Binding TLV] 2608 80 0C 00 38 00 01 01 00 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 2609 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 43 24 6E 30 2610 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7 2612 [Server Nonce] 2613 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 2614 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 2616 [Compound MAC] 2617 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 2618 05 C5 5B B7 2620 20. Intellectual Property Statement 2622 The IETF takes no position regarding the validity or scope of any 2623 Intellectual Property Rights or other rights that might be claimed 2624 to pertain to the implementation or use of the technology 2625 described in this document or the extent to which any license 2626 under such rights might or might not be available; nor does it 2627 represent that it has made any independent effort to identify any 2628 such rights. Information on the procedures with respect to rights 2629 in RFC documents can be found in BCP 78 and BCP 79. 2631 Copies of IPR disclosures made to the IETF Secretariat and any 2632 assurances of licenses to be made available, or the result of an 2633 attempt made to obtain a general license or permission for the use of 2634 such proprietary rights by implementers or users of this 2635 specification can be obtained from the IETF on-line IPR repository at 2636 http://www.ietf.org/ipr. 2638 The IETF invites any interested party to bring to its attention any 2639 copyrights, patents or patent applications, or other proprietary 2640 rights that may cover technology that may be required to implement 2641 this standard. Please address the information to the IETF at 2642 ietf-ipr@ietf.org. 2644 21. Disclaimer of Validity 2646 This document and the information contained herein are provided on 2647 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2648 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 2649 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 2650 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2651 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2652 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2653 PARTICULAR PURPOSE. 2655 22. Copyright Statement 2657 Copyright (C) The Internet Society (2005). This document is 2658 subject to the rights, licenses and restrictions contained in BCP 2659 78, and except as set forth therein, the authors retain all their 2660 rights. 2662 23. Expiration Date 2664 This memo is filed as , and 2665 expires October 25, 2005.