idnits 2.17.1 draft-ietf-pppext-eap-ttls-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 2 instances of lines with non-ascii characters in the document. 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1460: '...hed, and the client MUST echo the same...' RFC 2119 keyword, line 1508: '...r master secrets SHOULD be discarded w...' RFC 2119 keyword, line 1534: '...ation handshake phase, the server MUST...' RFC 2119 keyword, line 1537: '... MAY NOT initiate conclusion of an a...' RFC 2119 keyword, line 1539: '...d message} sequence; it MUST allow the...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: At the start of each application handshake phase, the server MUST wait for the client's opening ApplicationPayload message before it sends its own ApplicationPayload message to the client. The client MAY NOT initiate conclusion of an application handshake phase by sending the first {ChangeCipherSpec, PhaseFinished} or {ChangeCipherSpec, Finished message} sequence; it MUST allow the server to initiate the conclusion of the phase. -- 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 (July 2004) is 7224 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 1753, but not defined ** Obsolete normative reference: RFC 2716 (ref. '1') (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 3784 (ref. '2') (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2486 (ref. '7') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3588 (ref. '8') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 1700 (ref. '9') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 2433 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 2759 (ref. '11') ** Downref: Normative reference to an Informational RFC: RFC 2548 (ref. '12') ** Obsolete normative reference: RFC 3546 (ref. '13') (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 2560 (ref. '14') (Obsoleted by RFC 6960) -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Normative reference to a draft: ref. '16' Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group Paul Funk 3 Internet-Draft Funk Software, Inc. 4 Category: Standards Track Simon Blake-Wilson 5 Basic Commerce & 6 Industries, Inc. 7 July 2004 9 EAP Tunneled TLS Authentication Protocol 10 (EAP-TTLS) 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2001-2004). All Rights Reserved. 37 Abstract 39 EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS 40 handshake is used to mutually authenticate a client and server. EAP- 41 TTLS extends this authentication negotiation by using the secure 42 connection established by the TLS handshake to exchange additional 43 information between client and server. In EAP-TTLS, the TLS 44 handshake may be mutual; or it may be one-way, in which only the 45 server is authenticated to the client. The secure connection 46 established by the handshake may then be used to allow the server to 47 authenticate the client using existing, widely-deployed 48 authentication infrastructures such as RADIUS. The authentication of 49 the client may itself be EAP, or it may be another authentication 50 protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. 52 Thus, EAP-TTLS allows legacy password-based authentication protocols 53 to be used against existing authentication databases, while 54 protecting the security of these legacy protocols against 55 eavesdropping, man-in-the-middle and other cryptographic attacks. 57 EAP-TTLS also allows client and server to establish keying material 58 for use in the data connection between the client and access point. 59 The keying material is established implicitly between client and 60 server based on the TLS handshake. 62 This document describes two versions of EAP-TTLS - version 0 and 63 version 1. Most of the document concerns EAP-TTLS v0, a form of the 64 protocol that has been implemented by multiple vendors. Section 11 65 defines EAP-TTLS v1, an enhanced version of the protocol that 66 utilizes the TLS extensions mechanism to allow authentications to 67 occur within, rather than after, the TLS handshake. The TLS 68 extension that is defined is believed to useful in its own right, 69 and may be used in other contexts in addition to EAP-TTLS v1. 71 Table of Contents 73 1. Introduction......................................................3 74 2. Motivation........................................................4 75 3. Terminology.......................................................6 76 4. Architectural Model...............................................8 77 4.1 Carrier Protocols.............................................9 78 4.2 Security Relationships.......................................10 79 4.3 Messaging....................................................10 80 4.4 Resulting Security...........................................11 81 5. Protocol Layering Model..........................................11 82 6. EAP-TTLS version 0 Overview......................................12 83 6.1 Phase 1: Handshake...........................................13 84 6.2 Phase 2: Tunnel..............................................14 85 6.3 Piggybacking.................................................14 86 6.4 Session Resumption...........................................15 87 6.4.1 TTLS Server Guidelines for Session Resumption............16 88 7. Generating Keying Material.......................................16 89 8. EAP-TTLS Encoding................................................17 90 8.1 EAP-TTLS Start Packet........................................17 91 8.2 EAP-TTLS Packets with No Data................................18 92 9. Encapsulation of AVPs within the TLS Record Layer................18 93 9.1 AVP Format...................................................19 94 9.2 AVP Sequences................................................20 95 9.3 Guidelines for Maximum Compatibility with AAA Servers........20 96 10. Tunneled Authentication..........................................20 97 10.1 Implicit challenge...........................................21 98 10.2 Tunneled Authentication Protocols............................21 99 10.2.1 EAP ......................................................22 100 10.2.2 CHAP .....................................................23 101 10.2.3 MS-CHAP..................................................23 102 10.2.4 MS-CHAP-V2...............................................24 103 10.2.5 PAP ......................................................25 104 10.3 Performing Multiple Authentications..........................26 105 11. EAP-TTLS Version 1...............................................27 106 11.1 EAP-TTLS v1 Introduction.....................................27 107 11.2 Intentions Beyond EAP-TTLS...................................28 108 11.3 The InnerApplication Extension to TLS........................28 109 11.3.1 TLS/IA Overview..........................................29 110 11.3.2 Message Exchange.........................................31 111 11.3.3 Master Key Permutation...................................31 112 11.3.4 Session Resumption.......................................33 113 11.3.5 Error Termination........................................33 114 11.3.6 Application Session Key Material.........................33 115 11.3.7 Computing Verification Data..............................34 116 11.3.8 Attribute-Value Pairs (AVPs).............................36 117 11.3.9 TLS/IA Messages..........................................36 118 11.3.10 The InnerApplication Extension...........................37 119 11.3.11 The PhaseFinished Handshake Message......................37 120 11.3.12 The ApplicationPayload Handshake Message.................37 121 11.3.13 The InnerApplicationFailure Alert........................38 122 11.4 Binding of TLS/IA to EAP-TTLS v1.............................38 123 11.4.1 Flags Octet..............................................38 124 11.4.2 Version Negotiation......................................39 125 11.4.3 Acknowledgement Packets..................................39 126 11.4.4 Generating Keying Material...............................40 127 12. Discussion of Certificates and PKI...............................40 128 13. Message Sequences................................................42 129 13.1 Successful authentication via tunneled CHAP..................42 130 13.2 Successful authentication via tunneled EAP/MD5-Challenge.....44 131 13.3 Successful session resumption................................46 132 14. Security Considerations..........................................47 133 15. Changes since previous drafts....................................49 134 16. References.......................................................50 135 17. Authors' Addresses...............................................51 136 18. Full Copyright Statement.........................................51 138 1. Introduction 140 Extensible Authentication Protocol (EAP) [2] defines a standard 141 message exchange that allows a server to authenticate a client based 142 on an authentication protocol agreed upon by both parties. EAP may 143 be extended with additional authentication protocols by registering 144 such protocols with IANA or by defining vendor specific protocols. 146 Transport Layer Security (TLS) [3] is an authentication protocol 147 that provides for client authentication of a server or mutual 148 authentication of client and server, as well as secure ciphersuite 149 negotiation and key exchange between the parties. TLS has been 150 defined as an authentication protocol for use within EAP (EAP-TLS) 151 [1]. 153 Other authentication protocols are also widely deployed. These are 154 typically password-based protocols, and there is a large installed 155 base of support for these protocols in the form of credential 156 databases that may be accessed by RADIUS, Diameter or other AAA 157 servers. These include non-EAP protocols such as PAP, CHAP, MS-CHAP 158 and MS-CHAP-V2, as well as EAP protocols such as MD5-Challenge. 160 EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS 161 handshake is used to mutually authenticate a client and server. EAP- 162 TTLS extends this authentication negotiation by using the secure 163 connection established by the TLS handshake to exchange additional 164 information between client and server. In EAP-TTLS, the TLS 165 handshake may be mutual; or it may be one-way, in which only the 166 server is authenticated to the client. The secure connection 167 established by the handshake may then be used to allow the server to 168 authenticate the client using existing, widely-deployed 169 authentication infrastructures such as RADIUS. The authentication of 170 the client may itself be EAP, or it may be another authentication 171 protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. 173 Thus, EAP-TTLS allows legacy password-based authentication protocols 174 to be used against existing authentication databases, while 175 protecting the security of these legacy protocols against 176 eavesdropping, man-in-the-middle and other cryptographic attacks. 178 EAP-TTLS also allows client and server to establish keying material 179 for use in the data connection between the client and access point. 180 The keying material is established implicitly between client and 181 server based on the TLS handshake. 183 In EAP-TTLS, client and server communicate using attribute-value 184 pairs encrypted within TLS. This generality allows arbitrary 185 functions beyond authentication and key exchange to be added to the 186 EAP negotiation, in a manner compatible with the AAA infrastructure. 188 2. Motivation 190 Most password-based protocols in use today rely on a hash of the 191 password with a random challenge. Thus, the server issues a 192 challenge, the client hashes that challenge with the password and 193 forwards a response to the server, and the server validates that 194 response against the user's password retrieved from its database. 195 This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5- 196 Challenge and EAP/One-Time Password. 198 An issue with such an approach is that an eavesdropper that observes 199 both challenge and response may be able to mount a dictionary 200 attack, in which random passwords are tested against the known 201 challenge to attempt to find one which results in the known 202 response. Because passwords typically have low entropy, such attacks 203 can in practice easily discover many passwords. 205 While this vulnerability has long been understood, it has not been 206 of great concern in environments where eavesdropping attacks are 207 unlikely in practice. For example, users with wired or dial-up 208 connections to their service providers have not been concerned that 209 such connections may be monitored. Users have also been willing to 210 entrust their passwords to their service providers, or at least to 211 allow their service providers to view challenges and hashed 212 responses which are then forwarded to their home authentication 213 servers using, for example, proxy RADIUS, without fear that the 214 service provider will mount dictionary attacks on the observed 215 credentials. Because a user typically has a relationship with a 216 single service provider, such trust is entirely manageable. 218 With the advent of wireless connectivity, however, the situation 219 changes dramatically: 221 - Wireless connections are considerably more susceptible to 222 eavesdropping and man-in-the-middle attacks. These attacks may 223 enable dictionary attacks against low-entropy passwords. In 224 addition, they may enable channel hijacking, in which an attacker 225 gains fraudulent access by seizing control of the communications 226 channel after authentication is complete. 228 - Existing authentication protocols often begin by exchanging the 229 client�s username in the clear. In the context of eavesdropping 230 on the wireless channel, this can compromise the client�s 231 anonymity and locational privacy. 233 - Often in wireless networks, the access point does not reside in 234 the administrative domain of the service provider with which the 235 user has a relationship. For example, the access point may reside 236 in an airport, coffee shop, or hotel in order to provide public 237 access via 802.11. Even if password authentications are protected 238 in the wireless leg, they may still be susceptible to 239 eavesdropping within the untrusted wired network of the access 240 point. 242 - In the traditional wired world, the user typically intentionally 243 connects with a particular service provider by dialing an 244 associated phone number; that service provider may be required to 245 route an authentication to the user's home domain. In a wireless 246 network, however, the user does not get to choose an access 247 domain, and must connect with whichever access point is nearby; 248 providing for the routing of the authentication from an arbitrary 249 access point to the user's home domain may pose a challenge. 251 Thus, the authentication requirements for a wireless environment 252 that EAP-TTLS attempts to address can be summarized as follows: 254 - Legacy password protocols must be supported, to allow easy 255 deployment against existing authentication databases. 257 - Password-based information must not be observable in the 258 communications channel between the client node and a trusted 259 service provider, to protect the user against dictionary attacks. 261 - The user's identity must not be observable in the communications 262 channel between the client node and a trusted service provider, 263 to protect the user's locational privacy against surveillance, 264 undesired acquisition of marketing information, and the like. 266 - The authentication process must result in the distribution of 267 shared keying information to the client and access point to 268 permit encryption and validation of the wireless data connection 269 subsequent to authentication, to secure it against eavesdroppers 270 and prevent channel hijacking. 272 - The authentication mechanism must support roaming among small 273 access domains with which the user has no relationship and which 274 will have limited capabilities for routing authentication 275 requests. 277 3. Terminology 279 AAA 281 Authentication, Authorization and Accounting - functions that are 282 generally required to control access to a network and support 283 billing and auditing. 285 AAA protocol 287 A network protocol used to communicate with AAA servers; examples 288 include RADIUS and Diameter. 290 AAA server 292 A server which performs one or more AAA functions: authenticating 293 a user prior to granting network service, providing authorization 294 (policy) information governing the type of network service the 295 user is to be granted, and accumulating accounting information 296 about actual usage. 298 AAA/H 300 A AAA server in the user's home domain, where authentication and 301 authorization for that user are administered. 303 access point 305 A network device providing users with a point of entry into the 306 network, and which may enforce access control and policy based on 307 information returned by a AAA server. For the purposes of this 308 document, "access point" and "NAS" are architecturally 309 equivalent. "Access point" is used throughout because it is 310 suggestive of devices used for wireless access; "NAS" is used 311 when more traditional forms of access, such as dial-up, are 312 discussed. 314 access domain 316 The domain, including access points and other devices, that 317 provides users with an initial point of entry into the network; 318 for example, a wireless hot spot. 320 client 322 A host or device that connects to a network through an access 323 point. 325 domain 327 A network and associated devices that are under the 328 administrative control of an entity such as a service provider or 329 the user's home organization. 331 link layer protocol 333 A protocol used to carry data between hosts that are connected 334 within a single network segment; examples include PPP and 335 Ethernet. 337 NAI 339 A Network Access Identifier [7], normally consisting of the name 340 of the user and, optionally, the user's home realm. 342 NAS 344 A network device providing users with a point of entry into the 345 network, and which may enforce access control and policy based on 346 information returned by a AAA server. For the purposes of this 347 document, "access point" and "NAS" are architecturally 348 equivalent. "Access point" is used throughout because it is 349 suggestive of devices used for wireless access; "NAS" is used 350 when more traditional forms of access, such as dial-up, are 351 discussed. 353 proxy 354 A server that is able to route AAA transactions to the 355 appropriate AAA server, possibly in another domain, typically 356 based on the realm portion of an NAI. 358 realm 360 The optional part of an NAI indicating the domain to which a AAA 361 transaction is to be routed, normally the user's home domain. 363 service provider 365 An organization with which a user has a business relationship, 366 that provides network or other services. The service provider may 367 provide the access equipment with which the user connects, may 368 perform authentication or other AAA functions, may proxy AAA 369 transactions to the user's home domain, etc. 371 TTLS server 373 A AAA server which implements EAP-TTLS. This server may also be 374 capable of performing user authentication, or it may proxy the 375 user authentication to a AAA/H. 377 user 379 The person operating the client device. Though the line is often 380 blurred, "user" is intended to refer to the human being who is 381 possessed of an identity (username), password or other 382 authenticating information, and "client" is intended to refer to 383 the device which makes use of this information to negotiate 384 network access. There may also be clients with no human 385 operators; in this case the term "user" is a convenient 386 abstraction. 388 4. Architectural Model 390 The network architectural model for EAP-TTLS usage and the type of 391 security it provides is shown below. 393 +----------+ +----------+ +----------+ +----------+ 394 | | | | | | | | 395 | client |<---->| access |<---->| TTLS AAA |<---->| AAA/H | 396 | | | point | | server | | server | 397 | | | | | | | | 398 +----------+ +----------+ +----------+ +----------+ 400 <---- secure password authentication tunnel ---> 402 <---- secure data tunnel ----> 403 The entities depicted above are logical entities and may or may not 404 correspond to separate network components. For example, the TTLS 405 server and AAA/H server might be a single entity; the access point 406 and TTLS server might be a single entity; or, indeed, the functions 407 of the access point, TTLS server and AAA/H server might be combined 408 into a single physical device. The above diagram illustrates the 409 division of labor among entities in a general manner and shows how a 410 distributed system might be constructed; however, actual systems 411 might be realized more simply. 413 Note also that one or more AAA proxy servers might be deployed 414 between access point and TTLS server, or between TTLS server and 415 AAA/H server. Such proxies typically perform aggregation or are 416 required for realm-based message routing. However, such servers play 417 no direct role in EAP-TTLS and are therefore not shown. 419 4.1 Carrier Protocols 421 The entities shown above communicate with each other using carrier 422 protocols capable of encapsulating EAP. The client and access point 423 communicate using a link layer carrier protocol such as PPP or 424 EAPOL. The access point, TTLS server and AAA/H server communicate 425 using a AAA carrier protocol such as RADIUS or Diameter. 427 EAP, and therefore EAP-TTLS, must be initiated via the link layer 428 protocol. In PPP or EAPOL, for example, EAP is initiated when the 429 access point sends an EAP-Request/Identity packet to the client. 431 The keying material used to encrypt and authenticate the data 432 connection between the client and access point is developed 433 implicitly between the client and TTLS server as a result of EAP- 434 TTLS negotiation. This keying material must be communicated to the 435 access point by the TTLS server using the AAA carrier protocol. 437 The client and access point must also agree on an 438 encryption/validation algorithm to be used based on the keying 439 material. In some systems, both these devices may be preconfigured 440 with this information, and distribution of the keying material alone 441 is sufficient. Or, the link layer protocol may provide a mechanism 442 for client and access point to negotiate an algorithm. 444 In the most general case, however, it may be necessary for both 445 client and access point to communicate their algorithm preferences 446 to the TTLS server, and for the TTLS server to select one and 447 communicate its choice to both parties. This information would be 448 transported between access point and TTLS server via the AAA 449 protocol, and between client and TTLS server via EAP-TTLS in 450 encrypted form. 452 4.2 Security Relationships 454 The client and access point have no pre-existing security 455 relationship. 457 The access point, TTLS server and AAA/H server are each assumed to 458 have a pre-existing security association with the adjacent entity 459 with which it communicates. With RADIUS, for example, this is 460 achieved using shared secrets. It is essential for such security 461 relationships to permit secure key distribution. 463 The client and AAA/H server have a security relationship based on 464 the user's credentials such as a password. 466 The client and TTLS server may have a one-way security relationship 467 based on the TTLS server's possession of a private key guaranteed by 468 a CA certificate which the user trusts, or may have a mutual 469 security relationship based on certificates for both parties. 471 4.3 Messaging 473 The client and access point initiate an EAP conversation to 474 negotiate the client's access to the network. Typically, the access 475 point issues an EAP-Request/Identity to the client, which responds 476 with an EAP-Response/Identity. Note that the client does not include 477 the user's actual identity in this EAP-Response/Identity packet; the 478 user's identity will not be transmitted until an encrypted channel 479 has been established. 481 The access point now acts as a passthrough device, allowing the TTLS 482 server to negotiate EAP-TTLS with the client directly. 484 During the first phase of the negotiation, the TLS handshake 485 protocol is used to authenticate the TTLS server to the client and, 486 optionally, to authenticate the client to the TTLS server, based on 487 public/private key certificates. As a result of the handshake, 488 client and TTLS server now have shared keying material and an agreed 489 upon TLS record layer cipher suite with which to secure subsequent 490 EAP-TTLS communication. 492 During the second phase of negotiation, client and TTLS server use 493 the secure TLS record layer channel established by the TLS handshake 494 as a tunnel to exchange information encapsulated in attribute-value 495 pairs, to perform additional functions such as client authentication 496 and key distribution for the subsequent data connection. 498 If a tunneled client authentication is performed, the TTLS server 499 de-tunnels and forwards the authentication information to the AAA/H. 500 If the AAA/H performs a challenge, the TTLS server tunnels the 501 challenge information to the client. The AAA/H server may be a 502 legacy device and needs to know nothing about EAP-TTLS; it only 503 needs to be able to authenticate the client based on commonly used 504 authentication protocols. 506 Keying material for the subsequent data connection between client 507 and access point may be generated based on secret information 508 developed during the TLS handshake between client and TTLS server. 509 At the conclusion of a successful authentication, the TTLS server 510 may transmit this keying material to the access point, encrypted 511 based on the existing security associations between those devices 512 (e.g., RADIUS). 514 The client and access point now share keying material which they can 515 use to encrypt data traffic between them. 517 4.4 Resulting Security 519 As the diagram above indicates, EAP-TTLS allows user identity and 520 password information to be securely transmitted between client and 521 TTLS server, and performs key distribution to allow network data 522 subsequent to authentication to be securely transmitted between 523 client and access point. 525 5. Protocol Layering Model 527 EAP-TTLS packets are encapsulated within EAP, and EAP in turn 528 requires a carrier protocol to transport it. EAP-TTLS packets 529 themselves encapsulate TLS, which is then used to encapsulate user 530 authentication information. Thus, EAP-TTLS messaging can be 531 described using a layered model, where each layer is encapsulated by 532 the layer beneath it. The following diagram clarifies the 533 relationship between protocols: 535 +--------------------------------------------------------+ 536 | User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.)| 537 +--------------------------------------------------------+ 538 | TLS | 539 +--------------------------------------------------------+ 540 | EAP-TTLS | 541 +--------------------------------------------------------+ 542 | EAP | 543 +--------------------------------------------------------+ 544 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | 545 +--------------------------------------------------------+ 547 When the user authentication protocol is itself EAP, the layering is 548 as follows: 550 +--------------------------------------------------------+ 551 | User EAP Authentication Protocol (MD-Challenge, etc.) | 552 +--------------------------------------------------------+ 553 | EAP | 554 +--------------------------------------------------------+ 555 | TLS | 556 +--------------------------------------------------------+ 557 | EAP-TTLS | 558 +--------------------------------------------------------+ 559 | EAP | 560 +--------------------------------------------------------+ 561 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | 562 +--------------------------------------------------------+ 564 Methods for encapsulating EAP within carrier protocols are already 565 defined. For example, PPP [5] or EAPOL [4] may be used to transport 566 EAP between client and access point; RADIUS [6] or Diameter [8] are 567 used to transport EAP between access point and TTLS server. 569 6. EAP-TTLS version 0 Overview 571 [Authors' note: This section as well as sections 7, 8, 9 and 10, 572 describe version 0 of the EAP-TTLS protocol. Section 11 describes 573 version 1 of EAP-TTLS. Much of the material describing version 0 574 also applies to version 1; the version 1 documentation will refer to 575 the version 0 material as required. The intention is to provide a 576 separate draft for each of the two versions in the near future.] 578 A EAP-TTLS negotiation comprises two phases: the TLS handshake phase 579 and the TLS tunnel phase. 581 During phase 1, TLS is used to authenticate the TTLS server to the 582 client and, optionally, the client to the TTLS server. Phase 1 583 results in the activation of a cipher suite, allowing phase 2 to 584 proceed securely using the TLS record layer. (Note that the type and 585 degree of security in phase 2 depends on the cipher suite negotiated 586 during phase 1; if the null cipher suite is negotiated, there will 587 be no security!) 589 During phase 2, the TLS record layer is used to tunnel information 590 between client and TTLS server to perform any of a number of 591 functions. These might include user authentication, negotiation of 592 data communication security capabilities, key distribution, 593 communication of accounting information, etc.. Information between 594 client and TTLS server is exchanged via attribute-value pairs (AVPs) 595 compatible with RADIUS and Diameter; thus, any type of function that 596 can be implemented via such AVPs may easily be performed. 598 EAP-TTLS specifies how user authentication may be performed during 599 phase 2. The user authentication may itself be EAP, or it may be a 600 legacy protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Phase 2 601 user authentication may not always be necessary, since the user may 602 already have been authenticated via the mutual authentication option 603 of the TLS handshake protocol. 605 EAP-TTLS is also intended for use in key distribution, and specifies 606 how keying material for the data connection between client and 607 access point is generated. The keying material is developed 608 implicitly between client and TTLS server based on the results of 609 the TLS handshake; the TTLS server will communicate the keying 610 material to the access point over the carrier protocol However, 611 EAP-TTLS does not specify particular key distribution AVPs and their 612 use, since the needs of various systems will be different. Instead, 613 a general model for key distribution is suggested. Organizations may 614 define their own AVPs for this use, possibly using vendor-specific 615 AVPs, either in conformance with the suggested model or otherwise. 617 6.1 Phase 1: Handshake 619 In phase 1, the TLS handshake protocol is used to authenticate the 620 TTLS server to the client and, optionally, to authenticate the 621 client to the TTLS server. 623 Phase 1 is initiated when the client sends an EAP-Response/Identity 624 packet to the TTLS server. This packet specifically should not 625 include the name of the user; however, it may include the name of 626 the realm of a trusted provider to which EAP-TTLS packets should be 627 forwarded; for example, "@myisp.com". 629 The TTLS server responds to the EAP-Response/Identity packet with a 630 EAP-TTLS/Start packet, which is an EAP-Request with Type = EAP-TTLS, 631 the S (Start) bit set, and no data. This indicates to the client 632 that it should begin TLS handshake by sending a ClientHello message. 634 EAP packets continue to be exchanged between client and TTLS server 635 to complete the TLS handshake, as described in [1]. Phase 1 is 636 completed when the client and TTLS server exchange ChangeCipherSpec 637 and Finished messages. At this point, additional information may be 638 securely tunneled. 640 As part of the TLS handshake protocol, the TTLS server will send its 641 certificate along with a chain of certificates leading to the 642 certificate of a trusted CA. The client will need to be configured 643 with the certificate of the trusted CA in order to perform the 644 authentication. 646 If certificate-based authentication of the client is desired, the 647 client must have been issued a certificate and must have the private 648 key associated with that certificate 650 6.2 Phase 2: Tunnel 652 In phase 2, the TLS Record Layer is used to securely tunnel 653 information between client and TTLS server. This information is 654 encapsulated in sequences of attribute-value pairs (AVPS), whose use 655 and format are described in later sections. 657 Any type of information may be exchanged during phase 2, according 658 to the requirements of the system. (It is expected that applications 659 utilizing EAP-TTLS will specify what information must be exchanged 660 and therefore which AVPs must be supported.) 662 The client begins the phase 2 exchange by encoding information in a 663 sequence of AVPs, passing this sequence to the TLS record layer for 664 encryption, and sending the resulting data to the TTLS server. 666 The TTLS server recovers the AVPs in clear text from the TLS record 667 layer. If the AVP sequence includes authentication information, it 668 forwards this information to the AAA/H server using the AAA carrier 669 protocol. Note that the EAP-TTLS and AAA/H servers may be one and 670 the same, in which case it simply processes the information locally. 672 The TTLS server may respond with its own sequence of AVPs. The TTLS 673 server passes the AVP sequence to the TLS record layer for 674 encryption and sends the resulting data to the client. For example, 675 the TTLS server may send key distribution information, or it may 676 forward an authentication challenge received from the AAA/H. 678 This process continues until the TTLS server has enough information 679 to issue either an EAP-Success or EAP-Failure. Thus, if the AAA/H 680 rejects the client based on forwarded authentication information, 681 the TTLS server would issue an EAP-Failure. If the AAA/H accepts the 682 client, the TTLS server would issue an EAP-Success. 684 The TTLS server distributes data connection keying information and 685 other authorization information to the access point in the same AAA 686 carrier protocol message that carries the EAP-Success. 688 6.3 Piggybacking 690 While it is convenient to describe EAP-TTLS messaging in terms of 691 two phases, it is sometimes required that a single EAP-TTLS packet 692 to contain both phase 1 and phase 2 TLS messages. 694 Such "piggybacking" occurs when the party that completes the 695 handshake also has AVPs to send. For example, when negotiating a 696 resumed TLS session, the TTLS server sends its ChangeCipherSpec and 697 Finished messages first, then the client sends its own 698 ChangeCipherSpec and Finished messages to conclude the handshake. If 699 the client has authentication or other AVPs to send to the TTLS 700 server, it must tunnel those AVPs within the same EAP-TTLS packet 701 immediately following its Finished message. If the client fails to 702 do this, the TTLS server will incorrectly assume that the client has 703 no AVPs to send, and the outcome of the negotiation could be 704 affected. 706 6.4 Session Resumption 708 When a client and TTLS server that have previously negotiated a EAP- 709 TTLS session begin a new EAP-TTLS negotiation, the client and TTLS 710 server may agree to resume the previous session. This significantly 711 reduces the time required to establish the new session. This could 712 occur when the client connects to a new access point, or when an 713 access point requires reauthentication of a connected client. 715 Session resumption is accomplished using the standard TLS mechanism. 716 The client signals its desire to resume a session by including the 717 session ID of the session it wishes to resume in the ClientHello 718 message; the TTLS server signals its willingness to resume that 719 session by echoing that session ID in its ServerHello message. 721 If the TTLS server elects not to resume the session, it simply does 722 not echo the session ID and a new session will be negotiated. This 723 could occur if the TTLS server is configured not to resume sessions, 724 if it has not retained the requested session's state, or if the 725 session is considered stale. A TTLS server may consider the session 726 stale based on its own configuration, or based on session-limiting 727 information received from the AAA/H (e.g., the RADIUS Session- 728 Timeout attribute). 730 Tunneled authentication is specifically not performed for resumed 731 sessions; the presumption is that the knowledge of the master secret 732 as evidenced by the ability to resume the session is authentication 733 enough. This allows session resumption to occur without any 734 messaging between the TTLS server and the AAA/H. If periodic 735 reauthentication to the AAA/H is desired, the AAA/H must indicate 736 this to the TTLS server when the original session is established, 737 for example, using the RADIUS Session-Timeout attribute. 739 The client must, however, send other required AVPs, in particular 740 key distribution AVPs, that are not associated with tunneled 741 authentication in its first EAP-TTLS packet to the server that is 742 capable of containing phase 2 TLS messages. The TTLS server does not 743 retain client AVPs or key distribution preferences as part of 744 session state, and the client is expected to resend those AVPs in 745 each negotiation. 747 Thus phase 2 of a resumed session proceeds just as would a new 748 session, minus tunneled authentication AVPs. For example, the client 749 would send its key distribution preferences, and the TTLS server 750 would respond with its key distribution selection. 752 While the TTLS server does not retain client AVPs from session to 753 session, it must retain authorization information returned by the 754 AAA/H for use in resumed sessions. A resumed session must operate 755 under the same authorizations as the original session, and the TTLS 756 server must be prepared to send the appropriate information back to 757 the access point. Authorization information might include the 758 maximum time for the session, the maximum allowed bandwidth, packet 759 filter information and the like. The TTLS server is responsible for 760 modifying time values, such as Session-Timeout, appropriately for 761 each resumed session. 763 A TTLS server must not permit a session to be resumed if that 764 session did not result in a successful authentication of the user 765 during phase 2. The consequence of incorrectly implementing this 766 aspect of session resumption would be catastrophic; any attacker 767 could easily gain network access by first initiating a session that 768 succeeds in the TLS handshake but fails during phase 2 769 authentication, and then resuming that session. 771 [Implementation note: Toolkits that implement TLS often cache 772 resumable TLS sessions automatically. Implementers must take care to 773 override such automatic behavior, and prevent sessions from being 774 cached for possible resumption until the user has been positively 775 authenticated during phase 2.] 777 6.4.1 TTLS Server Guidelines for Session Resumption 779 When a domain comprises multiple TTLS servers, a client's attempt to 780 resume a session may fail because each EAP-TTLS negotiation may be 781 routed to a different TTLS server. 783 One strategy to ensure that subsequent EAP-TTLS negotiations are 784 routed to the original TTLS server is for each TTLS server to encode 785 its own identifying information, for example, IP address, in the 786 session IDs that it generates. This would allow any TTLS server 787 receiving a session resumption request to forward the request to the 788 TTLS server that established the original session. 790 7. Generating Keying Material 792 When record layer security is instantiated at the end of a TLS 793 handshake, a pseudo-random function (PRF) is used to expand the 794 negotiated master secret, server random value and client random 795 value into a sequence of octets that is used as keying material for 796 the record layer. The length of this sequence depends on the 797 negotiated cipher suite, and contains the following components: 799 client_write_MAC_secret 800 server_write_MAC_secret 801 client_write_key 802 server_write_key 803 client_write_IV (optional) 804 server_write_IV (optional) 806 The ASCII-encoded constant string "key expansion" is used as input 807 to the pseudo-random function to generate this sequence. 809 EAP-TTLS leverages this technique to create keying material for use 810 in the data connection between client and access point. Exactly the 811 same PRF is used to generate as much keying material as required, 812 with the constant string set to "ttls keying material", as follows: 814 EAP-TTLS_keying_material = PRF(SecurityParameters.master_secret, 815 "ttls keying material", 816 SecurityParameters.client_random + 817 SecurityParameters.server_random); 819 The master secret, client random and server random used to generate 820 the data connection keying material must be those established during 821 the TLS handshake. Both client and TTLS server generate this keying 822 material, and they are guaranteed to be the same if the handshake 823 succeeded. The TTLS server distributes this keying material to the 824 access point via the AAA carrier protocol. 826 [Note that the order of client_random and server_random for EAP-TTLS 827 is reversed from that of the TLS protocol [3]. This ordering follows 828 the key derivation method of EAP-TLS [1]. Altering the order of 829 randoms avoids namespace collisions between constant strings defined 830 for EAP-TTLS and those defined for the TLS protocol.] 832 8. EAP-TTLS Encoding 834 EAP-TTLS is a protocol within EAP. Its assigned EAP number is 21. 836 Except as described in the subsections below, EAP-TTLS's encoding of 837 TLS messages within EAP is identical to EAP-TLS's encoding of TLS 838 messages within EAP. See [1] for details. 840 8.1 EAP-TTLS Start Packet 842 The EAP-TTLS Start packet (with S-bit set) may, in a future 843 specification, be allowed to contain data (the EAP-TLS Start packet 844 does not). 846 Thus, the data contents of an EAP-TTLS Start packet are reserved for 847 future standardization; in the meantime, servers must not include 848 any data in an EAP-TTLS Start packet, and clients must ignore such 849 data but must not reject a Start packet that contains data. 851 8.2 EAP-TTLS Packets with No Data 853 One point of clarification has to do with an EAP-TTLS packet (other 854 than a Start packet) that contains no data. 856 EAP-TLS defines the use of such a packet as a fragment ACK. When 857 either party must fragment an EAP-TLS packet, the other party 858 responds with a fragment ACK to allow the original party to send the 859 next fragment. 861 EAP-TTLS uses the fragment ACK in the same way. There are also other 862 instances where a EAP-TTLS packet with no data might be sent: 864 - When the final EAP packet of the EAP-TTLS negotiation is sent by 865 the TTLS server, the client must respond with a EAP-TTLS packet 866 with no data, to allow the TTLS server to issue its final EAP- 867 Success or EAP-Failure packet. 869 - It is possible for a EAP-TTLS packet with no data to be sent in 870 the middle of a negotiation. Such a packet is simply interpreted 871 as packet with no AVPs. For example, during session resumption, 872 the client sends its Finished message first, then the TTLS server 873 replies with its Finished message. The TTLS server cannot 874 piggyback key distribution AVPs within the Record Layer in the 875 same EAP-TTLS packet containing its Finished message, because it 876 must wait for the client to indicate its key distribution 877 preferences. But it is possible that the client has no 878 preferences, and thus has no AVPs to send. The client simply 879 sends a EAP-TTLS packet with no data, to allow the server to 880 continue the negotiation by sending its key distribution 881 selection. 883 9. Encapsulation of AVPs within the TLS Record Layer 885 Subsequent to the TLS handshake, information is tunneled between 886 client and TTLS server through the use of attribute-value pairs 887 (AVPs) encrypted within the TLS record layer. 889 The AVP format chosen for EAP-TTLS is compatible with the Diameter 890 AVP format. This does not at all represent a requirement that 891 Diameter be supported by any of the devices or servers participating 892 in a EAP-TTLS negotiation. Use of this format is merely a 893 convenience. Diameter is a superset of RADIUS and includes the 894 RADIUS attribute namespace by definition, though it does not limit 895 the size of an AVP as does RADIUS; RADIUS, in turn, is a widely 896 deployed AAA protocol and attribute definitions exist for all 897 commonly used password authentication protocols, including EAP. 899 Thus, Diameter is not considered normative except as specified in 900 this document. Specifically, the AVP Codes used in EAP-TTLS are 901 semantically equivalent to those defined for Diameter, and, by 902 extension, RADIUS. Also, the representation of the Data field of an 903 AVP in EAP-TTLS is identical to that of Diameter. 905 Use of the RADIUS/Diameter namespace allows a TTLS server to easily 906 translate between AVPs it uses to communicate to clients and the 907 protocol requirements of AAA servers that are widely deployed. Plus, 908 it provides a well-understood mechanism to allow vendors to extend 909 that namespace for their particular requirements. 911 9.1 AVP Format 913 The format of an AVP is shown below. All items are in network, or 914 big-endian, order; that is, they have most significant octet first. 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | AVP Code | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 |V M r r r r r r| AVP Length | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Vendor-ID (opt) | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Data ... 926 +-+-+-+-+-+-+-+-+ 928 AVP Code 930 The AVP Code is four octets and, combined with the Vendor-ID 931 field if present, identifies the attribute uniquely. The first 932 256 AVP numbers represent attributes defined in RADIUS. AVP 933 numbers 256 and above are defined in Diameter. 935 AVP Flags 937 The AVP Flags field is one octet, and provides the receiver with 938 information necessary to interpret the AVP. 940 The 'V' (Vendor-Specific) bit indicates whether the optional 941 Vendor-ID field is present. When set to 1, the Vendor-ID field is 942 present and the AVP Code is interpreted according to the 943 namespace defined by the vendor indicated in the Vendor-ID field. 945 The 'M' (Mandatory) bit indicates whether support of the AVP is 946 required. If this bit is set to 0, this indicates that the AVP 947 may be safely ignored if the receiving party does not understand 948 or support it. If set to 1, this indicates that the receiving 949 party must fail the negotiation if it does not understand the 950 AVP; for a TTLS server, this would imply returning EAP-Failure, 951 for a client, this would imply abandoning the negotiation. 953 The 'r' (reserved) bits are unused and must be set to 0. 955 AVP Length 957 The AVP Length field is three octets, and indicates the length of 958 this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID 959 (if present) and Data. 961 Vendor-ID 963 The Vendor-ID field is present if the 'V' bit is set in the AVP 964 Flags field. It is four octets, and contains the vendor's IANA- 965 assigned "SMI Network Management Private Enterprise Codes" [9] 966 value. Vendors defining their own AVPs must maintain a consistent 967 namespace for use of those AVPs within RADIUS, Diameter and EAP- 968 TTLS. 970 A Vendor-ID value of zero is equivalent to absence of the Vendor- 971 ID field altogether. 973 9.2 AVP Sequences 975 Data encapsulated within the TLS Record Layer must consist entirely 976 of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet 977 boundary relative to the first AVP in the sequence. If an AVP is not 978 a multiple of 4 octets, it must be padded with 0s to the next 4- 979 octet boundary. 981 Note that the AVP Length does not include the padding. 983 9.3 Guidelines for Maximum Compatibility with AAA Servers 985 For maximum compatibility, the following guidelines for AVP usage 986 are suggested: 988 - Non-vendor-specific AVPs should be selected from the set of 989 attributes defined for RADIUS; that is, attributes with codes 990 less than 256. This provides compatibility with both RADIUS and 991 Diameter. 993 - Vendor-specific AVPs should be defined in terms of RADIUS. 994 Vendor-specific RADIUS attributes translate to Diameter (and, 995 hence, to EAP-TTLS) automatically; the reverse is not true. 996 RADIUS vendor-specific attributes use RADIUS attribute 26 and 997 include vendor ID, vendor-specific attribute code and length; see 998 [6] for details. 1000 10. Tunneled Authentication 1002 EAP-TTLS permits user authentication information to be tunneled 1003 within the TLS record layer between client and TTLS server, 1004 guaranteeing the security of the authentication information against 1005 active and passive attack between the client and TTLS server. The 1006 TTLS server decrypts and forwards this information to the AAA/H over 1007 the AAA carrier protocol. 1009 Any type of password or other authentication may be tunneled. Also, 1010 multiple tunneled authentications may be performed. Normally, 1011 tunneled authentication is used when the client has not been issued 1012 a certificate and the TLS handshake provides only one-way 1013 authentication of the TTLS server to the client; however, in certain 1014 cases it may be desired to perform certificate authentication of the 1015 client during the TLS handshake as well as tunneled user 1016 authentication afterwards. 1018 10.1 Implicit challenge 1020 Certain authentication protocols that use a challenge/response 1021 mechanism rely on challenge material that is not generated by the 1022 authentication server, and therefore require special handling. 1024 In CHAP, MS-CHAP and MS-CHAP-V2, for example, the NAS issues a 1025 challenge to the client, the client then hashes the challenge with 1026 the password and forwards the response to the NAS. The NAS then 1027 forwards both challenge and response to a AAA server. But because 1028 the AAA server did not itself generate the challenge, such protocols 1029 are susceptible to replay attack. 1031 If the client were able to create both challenge and response, 1032 anyone able to observe a CHAP or MS-CHAP exchange could pose as that 1033 user, even using EAP-TTLS. 1035 To make these protocols secure under EAP-TTLS, it is necessary to 1036 provide a mechanism to produce a challenge that the client cannot 1037 control or predict. This is accomplished using the same technique 1038 described above for generating data connection keying material. 1040 When a challenge-based authentication mechanism is used, both client 1041 and TTLS server use the pseudo-random function to generate as many 1042 octets as are required for the challenge, using the constant string 1043 "ttls challenge", based on the master secret and random values 1044 established during the handshake: 1046 EAP-TTLS_challenge = PRF(SecurityParameters.master_secret, 1047 "ttls challenge", 1048 SecurityParameters.client_random + 1049 SecurityParameters.server_random); 1051 10.2 Tunneled Authentication Protocols 1053 This section describes the methods for tunneling specific 1054 authentication protocols within EAP-TTLS. 1056 For the purpose of explication, it is assumed that the TTLS server 1057 and AAA/H use RADIUS as a AAA carrier protocol between them. 1058 However, this is not a requirement, and any AAA protocol capable of 1059 carrying the required information may be used. 1061 10.2.1 EAP 1063 When EAP is the tunneled authentication protocol, each tunneled EAP 1064 packet between the client and TTLS server is encapsulated in an EAP- 1065 Message AVP, prior to tunneling via the TLS record layer. 1067 The client's first tunneled EAP packet within phase 2 will contain 1068 the EAP-Response/Identity. The client places the actual username in 1069 this packet; the privacy of the user's identity is now guaranteed by 1070 the TLS encryption. This username must be a Network Access 1071 Identifier (NAI) [7]; that is, it must be in the following format: 1073 username@realm 1075 The @realm portion is optional, and is used to allow the TTLS server 1076 to forward the EAP packet to the appropriate AAA/H. 1078 Note that the client has two opportunities to specify realms. The 1079 first, in the initial EAP-Response/Identity packet, indicates the 1080 realm of the TTLS server. The second, in the tunneled 1081 authentication, indicates the realm of the client's home network. 1082 Thus, the access point need only know how to route to the realm of 1083 the TTLS server; the TTLS server is assumed to know how to route to 1084 the client's home realm. This serial routing architecture is 1085 anticipated to be useful in roaming environments, allowing access 1086 points or AAA proxies behind access points to be configured only 1087 with a small number of realms. 1089 Upon receipt of the tunneled EAP-Response/Identity, the TTLS server 1090 forwards it to the AAA/H in a RADIUS Access-Request. 1092 The AAA/H may immediately respond with an Access-Reject, in which 1093 case the TTLS server completes the negotiation by sending an EAP- 1094 Failure to the access point. This could occur if the AAA/H does not 1095 recognize the user's identity, or if it does not support EAP. 1097 If the AAA/H does recognize the user's identity and does support 1098 EAP, it responds with an Access-Challenge containing an EAP-Request, 1099 with the Type and Type-Data fields set according to the EAP protocol 1100 with which the AAA/H wishes to authenticate the client; for example 1101 MD-Challenge, OTP or Generic Token Card. 1103 The EAP authentication between client and AAA/H proceeds normally, 1104 as described in [2], with the TTLS server acting as a passthrough 1105 device. Each EAP-Request sent by the AAA/H in an Access-Challenge is 1106 tunneled by the TTLS server to the client, and each EAP-Response 1107 tunneled by the client is decrypted and forwarded by the TTLS server 1108 to the AAA/H in an Access-Request. 1110 This process continues until the AAA/H issues an Access-Accept or 1111 Access-Reject, at which point the TTLS server completes the 1112 negotiation by sending an EAP-Success or EAP-Failure to the access 1113 point using the AAA carrier protocol. 1115 10.2.2 CHAP 1117 The CHAP algorithm is described in [5]; RADIUS attribute formats are 1118 described in [6]. 1120 Both client and TTLS server generate 17 octets of challenge 1121 material, using the constant string "ttls challenge" as described 1122 above. These octets are used as follows: 1124 CHAP-Challenge [16 octets] 1125 CHAP Identifier [1 octet] 1127 The client tunnels User-Name, CHAP-Challenge and CHAP-Password AVPs 1128 to the TTLS server. The CHAP-Challenge value is taken from the 1129 challenge material. The CHAP-Password consists of CHAP Identifier, 1130 taken from the challenge material; and CHAP response, computed 1131 according to the CHAP algorithm. 1133 Upon receipt of these AVPs from the client, the TTLS server must 1134 verify that the value of the CHAP-Challenge AVP and the value of the 1135 CHAP Identifier in the CHAP-Password AVP are equal to the values 1136 generated as challenge material. If either item does not match 1137 exactly, the TTLS server must reject the client. Otherwise, it 1138 forwards the AVPs to the AAA/H in an Access-Request. 1140 The AAA/H will respond with an Access-Accept or Access-Reject. The 1141 TTLS server will then issue an EAP-Success or EAP-Failure to the 1142 access point. 1144 10.2.3 MS-CHAP 1146 The MS-CHAP algorithm is described in [10]; RADIUS attribute formats 1147 are described in [12]. 1149 Both client and TTLS server generate 9 octets of challenge material, 1150 using the constant string "ttls challenge" as described above. These 1151 octets are used as follows: 1153 MS-CHAP-Challenge [8 octets] 1154 Ident [1 octet] 1156 The client tunnels User-Name, MS-CHAP-Challenge and MS-CHAP-Response 1157 AVPs to the TTLS server. The MS-CHAP-Challenge value is taken from 1158 the challenge material. The MS-CHAP-Response consists of Ident, 1159 taken from the challenge material; Flags, set according the client 1160 preferences; and LM-Response and NT-Response, computed according to 1161 the MS-CHAP algorithm. 1163 Upon receipt of these AVPs from the client, the TTLS server must 1164 verify that the value of the MS-CHAP-Challenge AVP and the value of 1165 the Ident in the client's MS-CHAP-Response AVP are equal to the 1166 values generated as challenge material. If either item does not 1167 match exactly, the TTLS server must reject the client. Otherwise, it 1168 forwards the AVPs to the AAA/H in an Access-Request. 1170 The AAA/H will respond with an Access-Accept or Access-Reject. The 1171 TTLS server will then issue an EAP-Success or EAP-Failure to the 1172 access point. 1174 10.2.4 MS-CHAP-V2 1176 The MS-CHAP-V2 algorithm is described in [11]; RADIUS attribute 1177 formats are described in [12]. 1179 Both client and TTLS server generate 17 octets of challenge 1180 material, using the constant string "ttls challenge" as described 1181 above. These octets are used as follows: 1183 MS-CHAP-Challenge [16 octets] 1184 Ident [1 octet] 1186 The client tunnels User-Name, MS-CHAP-Challenge and MS-CHAP2- 1187 Response AVPs to the TTLS server. The MS-CHAP-Challenge value is 1188 taken from the challenge material. The MS-CHAP2-Response consists of 1189 Ident, taken from the challenge material; Flags, set to 0; Peer- 1190 Challenge, set to a random value; and Response, computed according 1191 to the MS-CHAP-V2 algorithm. 1193 Upon receipt of these AVPs from the client, the TTLS server must 1194 verify that the value of the MS-CHAP-Challenge AVP and the value of 1195 the Ident in the client's MS-CHAP2-Response AVP are equal to the 1196 values generated as challenge material. If either item does not 1197 match exactly, the TTLS server must reject the client. Otherwise, it 1198 forwards the AVPs to the AAA/H in an Access-Request. 1200 If the authentication is successful, the AAA/H will respond with an 1201 Access-Accept containing the MS-CHAP2-Success attribute. This 1202 attribute contains a 42-octet string that authenticates the AAA/H to 1203 the client based on the Peer-Challenge. The TTLS server tunnels this 1204 AVP to the client. Note that the authentication is not yet complete; 1205 the client must still accept the authentication response of the 1206 AAA/H. 1208 Upon receipt of the MS-CHAP2-Success AVP, the client is able to 1209 authenticate the AAA/H. If the authentication succeeds, the client 1210 sends an EAP-TTLS packet to the TTLS server containing no data. Upon 1211 receipt of the empty EAP-TTLS packet from the client, the TTLS 1212 server now issues an EAP-Success. 1214 If the authentication fails, the AAA/H will respond with an Access- 1215 Challenge containing the MS-CHAP2-Error attribute. This attribute 1216 contains a new Ident and a string with addition information such as 1217 error reason and whether a retry is allowed. If the error reason is 1218 an expired password and a retry is allowed, the client may proceed 1219 to change the user's password. If the error reason is not an expired 1220 password or if the client does not wish to change the user's 1221 password, it simply abandons the EAP-TTLS negotiation. 1223 If the client does wish to change the password, it tunnels MS-CHAP- 1224 NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS 1225 server. The MS-CHAP2-CPW AVP is derived from from the new Ident and 1226 Challenge received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge 1227 AVP simply echoes the new Challenge. 1229 Upon receipt of these AVPs from the client, the TTLS server must 1230 verify that the value of the MS-CHAP-Challenge AVP and the value of 1231 the Ident in the client's MS-CHAP2-CPW AVP match the values it sent 1232 in the MS-CHAP2-Error AVP. If either item does not match exactly, 1233 the TTLS server must reject the client. Otherwise, it forwards the 1234 AVPs to the AAA/H in an Access-Request. 1236 If the authentication is successful, the AAA/H will respond with an 1237 Access-Accept containing the MS-CHAP2-Success attribute. At this 1238 point, the negotiation proceeds as described above; the TTLS server 1239 tunnels the MS-CHAP2-Success to the client, the client authenticates 1240 the AAA/H based on this AVP, it either abandons the negotation on 1241 failure or sends an EAP-TTLS packet to the TTLS server containing no 1242 data, the TTLS server issues an EAP-Success. 1244 Note that additional AVPs associated with MS-CHAP-V2 may be sent by 1245 the AAA/H; for example, MS-CHAP-Domain. The TTLS server must tunnel 1246 such authentication-related attributes along with the MS-CHAP2- 1247 Success. 1249 10.2.5 PAP 1251 The client tunnels User-Name and User-Password AVPs to the TTLS 1252 server. 1254 Normally, in RADIUS, User-Password is padded with nulls to a 1255 multiple of 16 octets, then encrypted using a shared secret and 1256 other packet information. 1258 An EAP-TTLS client, however, does not RADIUS-encrypt the password 1259 since no such RADIUS variables are available; this is not a security 1260 weakness since the password will be encrypted via TLS anyway. The 1261 client should, however, null-pad the password to a multiple of 16 1262 octets, to obfuscate its length. 1264 Upon receipt of these AVPs from the client, the TTLS server forwards 1265 them to the AAA/H in a RADIUS Access-Request. (Note that in the 1266 Access-Request, the TTLS server must encrypt the User-Password 1267 attribute using the shared secret between the TTLS server and 1268 AAA/H.) 1270 The AAA/H may immediately respond with an Access-Accept or Access- 1271 Reject. The TTLS server then completes the negotiation by sending an 1272 EAP-Success or EAP-Failure to the access point using the AAA carrier 1273 protocol. 1275 The AAA/H may also respond with an Access-Challenge. The TTLS server 1276 then tunnels the AVPs from the AAA/H's challenge to the client. Upon 1277 receipt of these AVPs, the client tunnels User-Name and User- 1278 Password again, with User-Password containing new information in 1279 response to the challenge. This process continues until the AAA/H 1280 issues an Access-Accept or Access-Reject. 1282 At least one of the AVPs tunneled to the client upon challenge must 1283 be Reply-Message. Normally this is sent by the AAA/H as part of the 1284 challenge. However, if the AAA/H has not sent a Reply-Message, the 1285 TTLS server must issue one, with null value. This allows the client 1286 to determine that a challenge response is required. 1288 Note that if the AAA/H includes a Reply-Message as part of an 1289 Access-Accept or Access-Reject, the TTLS server does not tunnel this 1290 AVP to the client. Rather, this AVP and all other AVPs sent by the 1291 AAA/H as part of Access-Accept or Access-Reject are sent to the 1292 access point via the AAA carrier protocol. 1294 10.3 Performing Multiple Authentications 1296 In some cases, it is desirable to perform multiple user 1297 authentications. For example, a AAA/H may want first to authenticate 1298 the user by password, then by token card. 1300 The AAA/H may perform any number of additional user authentications 1301 using EAP, simply by issuing a EAP-Request with a new protocol type 1302 once the previous authentication succeeded but prior to issuing an 1303 EAP-Success or accepting the user via the AAA carrier protocol. 1305 For example, an AAA/H wishing to perform MD5-Challenge followed by 1306 Generic Token Card would first issue an EAP-Request/MD5-Challenge 1307 and receive a response. If the response is satisfactory, it would 1308 then issue EAP-Request/Generic Token Card and receive a response. If 1309 that response were also satisfactory, it would issue EAP-Success. 1311 11. EAP-TTLS Version 1 1313 Version 1 of EAP-TTLS improves upon the original version 0 protocol 1314 in several ways. 1316 - Session keys developed from inner authentications are mixed with 1317 the master secret developed during the initial TLS handshake. 1318 This eliminates the Man-in-the-Middle (MitM) attack against 1319 tunneled protocols for inner authentications that generate 1320 session keys. See [15] and [16] for information about this 1321 attack. 1323 - A secure final exchange of the result of inner authentication is 1324 exchanged between client and server to conclude the EAP-TTLS 1325 exchange. This precludes any possibility of truncation attack 1326 that could occur when the client relies solely on an unprotected 1327 EAP-Success message to determine that the server has completed 1328 its authentication. 1330 - Inner authentication occurs within the TLS handshake, rather than 1331 after it. Thus, the TLS handshake itself includes both a standard 1332 TLS authentication as well as tunneled inner authentication(s) 1333 using EAP or legacy protocols, as well as any other tunneled 1334 communications required between client and server. 1336 11.1 EAP-TTLS v1 Introduction 1338 Version 1 of EAP-TTLS utilizes the TLS extensions mechanism to 1339 extend the TLS handshake to include exchange of inner AVPs prior to 1340 completion of the TLS handshake by exchange of Finished messages. 1342 The TLS protocol provides a handshake phase and a data phase. EAP- 1343 TTLS v0, as well as other proposed tunneled EAP types such as EAP- 1344 PEAP and EAP-FAST, share a common strategy of utilizing the 1345 handshake phase to establish a tunnel and the data phase to perform 1346 protected authentication. 1348 In EAP-TTLS v1, the AVP exchange is folded into the TLS handshake 1349 itself; in other words, the inner authentication precedes the 1350 conclusion of the TLS handshake, rather following it. 1352 An advantage of this arrangement is a certain amount of 1353 cryptographic integration of inner authentication with standard TLS 1354 mechanisms. For example, mixing of inner session keys to thwart MitM 1355 attacks is easily performed in such a way that both the 1356 authentication result and the final session key is conditioned upon 1357 these inner session keys. 1359 The definition of EAP-TTLS v1 proceeds by first defining the 1360 InnerApplication extension to TLS, and then by defining the binding 1361 of the extended TLS to EAP via EAP-TTLS v1, which in effect serves 1362 as a carrier protocol. 1364 11.2 Intentions Beyond EAP-TTLS 1366 The use of TLS for EAP is a relative newcomer. TLS has long used for 1367 many other purposes, most notably for protecting HTTP traffic. 1368 However, TLS used in these contexts has no mechanism for 1369 authentication beyond the certificate mechanisms that have been 1370 defined. Any additional authentication, say in HTTP, must use 1371 relatively primitive mechanisms defined in the HTTP protocol. It 1372 would be very useful for the TLS protocol to provide more general 1373 authentication mechanisms for subsequent authentication, for example 1374 EAP. 1376 The InnerApplication extension allows TLS to provide inner 1377 authentication during the handshake, rather than after it. The EAP- 1378 TTLS version 1 protocol is in fact just a binding of this extended 1379 TLS to EAP; that it, EAP-TTLS is a carrier protocol for the extended 1380 TLS. TLS with the InnerApplication extension can just as easily be 1381 bound to TCP, to enable its use in HTTP. 1383 The applicability of TLS with the InnerApplication extension 1384 includes setting up HTTP connections (including SSL VPN 1385 connections), establishing IPsec connections as an alternative to 1386 IKE, obtaining credentials for single sign-on, providing for client 1387 integrity verification, etc. The inner AVP mechanism offers both 1388 legacy and EAP authentication capabilities, natural compatibility 1389 with RADIUS and Diameter servers, and the flexibility to allow 1390 arbitrary client-server exchanges for various purposes. 1392 The authors' intention is to separately propose the TLS 1393 InnerApplication extension as an enhancement to TLS, and then define 1394 EAP-TTLS version 1 as a carrier protocol, or binding, of that 1395 extended TLS to EAP. For reasons of timing, the TLS InnerApplication 1396 extension is defined in this draft for now. 1398 11.3 The InnerApplication Extension to TLS 1400 The InnerApplication extension to TLS follows the guidelines of RFC 1401 3546. The client proposes use of this extension by including an 1402 InnerApplication message in its ClientHello handshake message, and 1403 the server confirms its use by including an InnerApplication message 1404 in its ServerHello handshake message. 1406 In this document, the term "TLS/IA" shall refer to TLS with the 1407 InnerApplication extension. 1409 Two new handshake messages are defined for use in TLS/IA: 1411 - The PhaseFinished message. This message is similar to the 1412 standard TLS Finished message; it allows the TLS/IA handshake to 1413 operate in phases, with message and key confirmation occurring at 1414 the end of each phase. 1416 - The ApplicationPayload message. This message is used to carry AVP 1417 (Attribute-Value Pair) sequences within the TLS/IA handshake, in 1418 support of client-server applications such as authentication. 1420 A new alert code is also defined for use in TLS/IA: 1422 - The InnerApplicationFailure alert. This error alert allows either 1423 party to terminate the handshake due to a failure in an 1424 application implemented via AVP sequences carried in 1425 ApplicationPayload messages. 1427 11.3.1 TLS/IA Overview 1429 In TLS/IA, the handshake is divided into phases. 1431 The first phase is called the "initial phase", and consists of a 1432 standard TLS handshake with PhaseFinished substituted for Finished 1433 as the concluding message. 1435 There are one or more subsequent phases, called "application 1436 phases". The last application phase is called the "final phase"; any 1437 application phase prior to the final phase is called an 1438 "intermediate phase". 1440 Each application phase consists of ApplicationPayload messages 1441 exchanged by client and server to implement applications such as 1442 authentication, plus concluding messages for cryptographic 1443 confirmation. 1445 Thus, the entire handshake consists of a initial phase, zero or more 1446 intermediate phases, and a final phase. Intermediate phases are only 1447 necessary if interim confirmation of key material generated during 1448 an application phase is desired. 1450 In each application phase, the client sends the first 1451 ApplicationPayload message. ApplicationPayload messages are then 1452 traded one at a time between client and server, until the server 1453 concludes the phase by sending a ChangeCipherSpec and PhaseFinished 1454 sequence to conclude an intermediate phase, or a ChangeCipherSpec 1455 and Finished sequence to conclude the final phase. The client then 1456 responds with its own ChangeCipherSpec and PhaseFinished sequence, 1457 or ChangeCipherSpec and Finished sequence. 1459 The server determines which type of concluding message is used, 1460 either PhaseFinished or Finished, and the client MUST echo the same 1461 type of concluding message. Each PhaseFinished or Finished message 1462 provides cryptographic confirmation of the integrity of all 1463 handshake messages and keys generated from the start of the 1464 handshake through the current phase. 1466 Each ApplicationPayload message contains opaque data interpreted as 1467 an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence 1468 contains a typed data element. The exchanged AVPs allow client and 1469 server to implement "applications" within a secure tunnel. An 1470 application may be any procedure that someone may usefully define. A 1471 typical application might be authentication; for example, the server 1472 may authenticate the client based on password credentials using EAP. 1473 Other possible applications include distribution of keys, validating 1474 client integrity, setting up IPsec parameters, setting up SSL VPNs, 1475 and so on. 1477 In TLS/IA, the TLS master secret undergoes multiple permutations 1478 until a final master secret is computed at the end of the entire 1479 handshake. Each phase of the handshake results in a new master 1480 secret; the master secret for each phase is confirmed by the 1481 PhaseFinished or Finished message exchange that concludes that 1482 phase. 1484 The initial master secret is computed during the initial phase of 1485 the handshake, using the usual TLS algorithm, namely, that a 1486 premaster secret is established and the TLS PRF function is used to 1487 compute the initial master secret. This initial master secret is 1488 confirmed via the first exchange of ChangeCipherSpec and 1489 PhaseFinished messages. 1491 Each subsequent master secret for an application phase is computed 1492 using a PRF based on the current master secret, then mixing into the 1493 result any session key material generated during authentications 1494 during that phase. Each party computes a new master secret prior to 1495 the conclusion of each application phase, and uses that new master 1496 secret is to compute fresh keying material (that is, a TLS 1497 "key_block", consisting of client and server MAC secrets, write keys 1498 and IVs). The new master secret and keying material become part of 1499 the pending read and write connection states. Following standard TLS 1500 procedures, these connection states become current states upon 1501 sending or receiving ChangeCipherSpec, and are confirmed via the 1502 PhaseFinished or Finished message. 1504 The final master secret, computed during the final handshake phase 1505 and confirmed by an exchange of ChangeCipherSpec and Finished 1506 messages, becomes the actual TLS master secret that defines the 1507 session. This final master secret is the surviving master secret, 1508 and each prior master secrets SHOULD be discarded when a new 1509 connection state is instantiated. The final master secret is used 1510 for session resumption, as well as for any session key derivation 1511 that protocols defined over TLS may require. 1513 11.3.2 Message Exchange 1515 Each intermediate handshake phase consists of ApplicationPayload 1516 messages sent alternately by client and server, and a concluding 1517 exchange of {ChangeCipherSpec, PhaseFinished} messages. The first 1518 ApplicationPayload message in the each intermediate phase is sent by 1519 the client; the first {ChangeCipherSpec, PhaseFinished} message 1520 sequence is sent by the server. Thus the client begins the exchange 1521 with an ApplicationPayload message and the server determines when to 1522 conclude it by sending {ChangeCipherSpec, PhaseFinished}. When it 1523 receives the server's {ChangeCipherSpec, PhaseFinished} messages, 1524 the client sends its own {ChangeCipherSpec, PhaseFinished} messages. 1525 The client then sends an ApplicationPayload message to begin the 1526 next handshake phase. 1528 The final handshake proceeds in the same manner as the intermediate 1529 handshake, except that the Finished message is used rather than the 1530 PhaseFinished message, and the client does not send an 1531 ApplicationPayload message for the next phase because there is no 1532 next phase. 1534 At the start of each application handshake phase, the server MUST 1535 wait for the client's opening ApplicationPayload message before it 1536 sends its own ApplicationPayload message to the client. The client 1537 MAY NOT initiate conclusion of an application handshake phase by 1538 sending the first {ChangeCipherSpec, PhaseFinished} or 1539 {ChangeCipherSpec, Finished message} sequence; it MUST allow the 1540 server to initiate the conclusion of the phase. 1542 11.3.3 Master Key Permutation 1544 Each permutation of the master secret from one phase to the next 1545 begins with the calculation of a preliminary 48 octet vector based 1546 on the current master secret: 1548 preliminary_vector = PRF(master_secret, 1549 "InnerApplication preliminary vector", 1550 server_random + client_random) [0..48]; 1552 Session key material generated by applications during the current 1553 application phase are mixed into the preliminary vector by 1554 arithmetically adding each session key to the preliminary vector to 1555 compute the new master secret. The preliminary vector is treated as 1556 a 48-octet integer in big-endian order; that is, the first octet is 1557 of the highest significance. Each session key is also treated as a 1558 big-endian integer of whatever size it happens to be. Arithmetic 1559 carry past the most significant octet is discarded; that is, the 1560 addition is performed modulo 2 ^ 384. 1562 Thus, the logical procedure for computing the next master secret 1563 (which may also be a convenient implementation procedure) is as 1564 follows: 1566 1 At the start of each application handshake phase, use the current 1567 master secret to compute the preliminary vector for the next 1568 master secret. 1570 2 Each time session key material is generated from an 1571 authentication or other exchange, arithmetically add that session 1572 key material to the preliminary vector. 1574 3 At the conclusion of the application handshake phase, copy the 1575 current contents of the preliminary vector (which now includes 1576 addition of all session key material) into the new master secret, 1577 prior to computing verify_data. 1579 The purpose of using a PRF to compute a preliminary vector is to 1580 ensure that, even in the absence of session keys, the master secret 1581 is cryptographically distinct in each phase of the handshake. 1583 The purpose of adding session keys into the preliminary vector is to 1584 ensure that the same client entity that negotiated the original 1585 master secret also negotiated the inner authentication(s). In the 1586 absence of such mixing of keys generated from the standard TLS 1587 handshake with keys generated from inner authentication, it is 1588 possible for a hostile agent to mount a man-in-the-middle attack, 1589 acting as server to an unsuspecting client to induce it to perform 1590 an authentication with it, which it can then pass through the TLS 1591 tunnel to allow it to pose as that client. 1593 An application phase may include no authentications that produce a 1594 session key, may include one such authentication, or may include 1595 several. Arithmetic addition was chosen as the mixing method because 1596 it is commutative, that is, it does not depend on the order of 1597 operations. This allows multiple authentications to proceed 1598 concurrently if desired, without having to synchronize the order of 1599 master secret updates between client and server. 1601 Addition was chosen rather than XOR in order to avoid what is 1602 probably a highly unlikely problem; namely, that two separate 1603 authentications produce the same session key, which, if XORed, would 1604 mutually cancel. This might occur, for example, if two instances of 1605 an authentication method were to be applied against different forms 1606 of a user identity that turn out in a some cases to devolve to the 1607 same identity. 1609 Finally, it was decided that a more complex mixing mechanism for 1610 session key material, such as hashing, besides not being 1611 commutative, would not provide any additional security, due to the 1612 effectively random character of the preliminary vector and the 1613 powerful PRF function which is applied to create derivative keys. 1615 11.3.4 Session Resumption 1617 A TLS/IA handshake may be resumed using standard mechanisms defined 1618 in RFC 2246. In TLS/IA, session resumption is simply an alternative 1619 form of the initial handshake phase, after which subsequent 1620 application phases proceed. 1622 When the initial handshake phase is resumed, client and server may 1623 not deem it necessary to perform the same type of AVP exchange that 1624 they might after a full handshake. In fact, the resumption itself 1625 might provide all the security needed and no AVPs need be exchanged 1626 at all. 1628 If the client determines that it has no need for AVP negotiation, it 1629 sends an ApplicationPayload message with no data as its first 1630 application phase message. If the server concurs, it may conclude 1631 the handshake with ChangeCipherSpec and Finished immediately upon 1632 receiving the empty ApplicationPayload message. 1634 Alternatively, either party may initiate AVP exchange if inner 1635 applications must execute upon session resumption. For example, 1636 authentication exchanges might be omitted but key distribution for 1637 some purpose might still occur. 1639 [Author's note: A future draft may provide a mechanism to avoid the 1640 extra round trip incurred when neither party has a requirement to 1641 send AVPs after session resumption.] 1643 11.3.5 Error Termination 1645 The TLS/IA handshake may be terminated by either party sending a 1646 fatal alert, following standard TLS procedures. 1648 11.3.6 Application Session Key Material 1650 Many authentication mechanisms generate session keying material as a 1651 by-product of authentication. Such keying material is normally 1652 intended for use in a subsequent data connection for encryption and 1653 validation. For example, EAP-TLS, MS-CHAP-V2 and its alter ego EAP- 1654 MS-CHAP-V2 each generate keying material. 1656 When encapsulated within TLS/IA, such keying material MUST NOT be 1657 used to set up data connections; the TLS/IA master secret is a 1658 better basis for this use. 1660 However, such keying material generated during an application phase 1661 MUST be used to permute the TLS/IA master secret between on phase 1662 and the next. The purpose of this is to preclude man-in-the-middle 1663 attacks, in which an unsuspecting client is induced to perform an 1664 authentication outside a tunnel with an attacker posing as a server; 1665 the attacker can then introduce the authentication protocol into a 1666 tunnel such as provided by TLS/IA, fooling an authentic server into 1667 believing that the attacker is the authentic user. 1669 By mixing keying material generating during application phase 1670 authentication into the master secret, such attacks are thwarted, 1671 since only a single client identity could both authenticate 1672 successfully and have derived the session keying material. 1674 Note that the keying material generated during authentication must 1675 be cryptographically related to the authentication and not derivable 1676 from data exchanged during authentication in order for the keying 1677 material to be useful in thwarting such attacks. 1679 The RECOMMENDED amount of keying material to mix into the master 1680 secret is 32 octets. Up to 48 octets MAY be used. 1682 Each authentication protocol may define how the keying material it 1683 generates is mapped to an octet sequence of some length for the 1684 purpose of TLS/IA mixing. However, for protocols which do not 1685 specify this (including the multitude of protocols that pre-date 1686 TLS/IA) the following rules are defined. The first rule that applies 1687 SHALL be the method for determining keying material: 1689 - If the authentication protocol maps its keying material to the 1690 RADIUS attributes MS-MPPE-Receive-Key and MS-MPPE-Send-Key, then 1691 the keying material for those attributes are concatenated (with 1692 MS-MPPE-Receive-Key first), the concatenated sequence is 1693 truncated to 32 octets if longer, and the result is used as 1694 keying material. (Note that this rule applies to MS-CHAP-V2 and 1695 EAP-MS-CHAP-V2.) 1697 - If the authentication protocol uses a pseudo-random function to 1698 generate keying material, that function is used to generate 32 1699 octets for use as keying material. 1701 11.3.7 Computing Verification Data 1703 In standard TLS, the "verify_data" vector of the Finished message is 1704 computed as follows: 1706 PRF(master_secret, finished_label, MD5(handshake_messages) + 1707 SHA-1(handshake_messages)) [0..11]; 1709 This allows both parties to confirm the master secret as well as the 1710 integrity of all handshake messages that have been exchanged. 1712 In TLS/IA, verify_data for the initial handshake phase is computed 1713 in exactly the same manner, though verify_data is encapsulated in a 1714 PhaseFinished, rather than Finished, message. 1716 In the subsequent application phases, a slight variation to this 1717 formula is used. For each hash, the handshake messages of the 1718 current phase are appended to the hash of the handshake messages of 1719 the previous phase. Thus, for each application phase, the MD5 hash 1720 input to the PRF is a hash of the MD5 hash computed for the previous 1721 phase concatenated with the handshake messages of the current phase; 1722 the SHA-1 hash is computed in the same way, but using the SHA-1 hash 1723 computed for the previous phase. 1725 Also, the master secret used in the PRF computation in each 1726 application phase is the new master secret generated at the 1727 conclusion of that phase. 1729 For clarity, this is best expressed in formal notation. 1731 Let phases be numbered from 0, where phase 0 is the initial phase. 1733 Let: 1735 Secret[n] be the master secret determined at the conclusion of 1736 phase n. 1738 Messages[n] be the handshake messages in phase n. 1740 MD5[n] be the MD5 hash of handshake message material in phase n. 1742 SHA-1[n] be the SHA-1 hash of handshake message material in phase 1743 n. 1745 PRF[n] be the verify_data generated via PRF in phase n. 1747 Hash computations for phase 0 are as follows: 1749 MD5[0] = MD5(Messages[0]) 1751 SHA-1[0] = SHA-1(Messages[0]) 1753 PRF[0] = PRF(master_secret, finished_label, MD5[0] + SHA-1[0]) 1754 [0..11] 1756 Hash computations for phase i, where i > 0 (i.e. application phases) 1757 are as follows: 1759 MD5[i] = MD5(MD5[i-1] + Messages[i]) 1761 SHA-1[i] = SHA-1(SHA-1[i-1] + Messages[i]) 1763 The PRF computation to generate verify_data for any phase i 1764 (including i = 0) is as follows: 1766 PRF[i] = PRF(Secret[i], finished_label, MD5[i] + SHA-1[i]) 1767 [0..11] 1769 Note that for phase 0, the PRF computation is identical to the 1770 standard TLS computation. Variations to the algorithm occur only in 1771 application phases, in the use of new master secrets and the 1772 inclusion of hashes of previous handshake messages as input to the 1773 hashing algorithms. 1775 Note that the only handshake messages that appear in an application 1776 phase are InnerApplication messages and Finished or Phase Finished 1777 messages. During an application phase, the handshake messages input 1778 to the hashing algorithm by the server will include all 1779 InnerApplication messages exchanged during that phase; the handshake 1780 messages input to the hashing algorithm by the client will include 1781 all InnerApplication messages exchanged during that phase plus the 1782 server's PhaseFinished or Finished message. 1784 11.3.8 Attribute-Value Pairs (AVPs) 1786 AVPs used in InnerApplication messages are exactly as defined in 1787 Section 9 of this document; that is, they are Diameter-style AVPs 1788 and use the RADIUS-Diameter namespace. 1790 Rules for performing authentications using these AVPs are exactly as 1791 defined in Section 10 of this document. This includes rules for 1792 creating implicit challenges, and rules for use of inner EAP 1793 authentications as well as legacy protocols such as PAP, CHAP and 1794 MS-CHAP-V1/V2. Note that all implicit challenges are based on the 1795 then-current master secret. 1797 11.3.9 TLS/IA Messages 1799 All specifications of TLS/IA messages follow the usage defined in 1800 RFC 2246. 1802 TLS/IA defines a new TLS extension - "InnerApplication"; two new 1803 handshake messages - "PhaseFinished" and "ApplicationPayload"; and a 1804 new alert code - "InnerApplicationFailure". 1806 The InnerApplication extension type is 9347 (hex). 1808 In order to avoid potential type-assignment problems, the new 1809 handshake message types and alert code are dynamically defined 1810 within the InnerApplication extension message. Client and server 1811 independently specify the values they will send. Thus, the client 1812 assigns its own message type and alert code values for use in its 1813 own transmissions, and includes these values in its InnerApplication 1814 message within ClientHello. Similarly, the server assigns its own 1815 message type and alert code values for use in its own transmissions, 1816 and includes these values in its InnerApplication message within 1817 ServerHello. Each party must note the message type and alert code 1818 values assigned by the other party and interpret messages from the 1819 other party accordingly. Both client and server assign message types 1820 and alert code so as not to conflict with values that that it might 1821 otherwise send. There is no requirement that client and server 1822 assign identical values for these items. 1824 11.3.10 The InnerApplication Extension 1826 Use of the InnerApplication extension follows RFC 3546. The client 1827 proposes use of this extension by including the InnerApplication 1828 extension in the client_hello_extension_list vector of the extended 1829 ClientHello. If the extension is included in the ClientHello, the 1830 server MAY accept the proposal by including the InnerApplication 1831 extension in the server_hello_extension_list of the extended 1832 ServerHello. If use of this extension is either not proposed by the 1833 client or not confirmed by the server, the variations to the TLS 1834 handshake described here MUST NOT be used. 1836 The "extension_data" field of the Extension structure for the 1837 InnerApplication extension SHALL contain "InnerApplication" where: 1839 struct { 1840 uint8 PhaseFinishedType; 1841 uint8 ApplicationPayloadType; 1842 uint8 InnerApplicationFailureAlertCode; 1843 } InnerApplication; 1845 11.3.11 The PhaseFinished Handshake Message 1847 The PhaseFinished message concludes the initial handshake phase and 1848 each intermediate handshake phase. It MUST be immediately preceded 1849 by a ChangeCipherSpec message. It is defined as follows: 1851 struct { 1852 opaque verify_data[12]; 1853 } PhaseFinished; 1855 11.3.12 The ApplicationPayload Handshake Message 1857 The ApplicationPayload message carries an AVP sequence during an 1858 application handshake phase. It is defined as follows: 1860 struct { 1861 opaque avps[Handshake.length]; 1862 } ApplicationPayload; 1863 where Handshake.length is the 24-bit length field in the 1864 encapsulating Handshake message. 1866 Note that the "avps" element has its length defined in square 1867 bracket rather than angle bracket notation, implying a fixed rather 1868 than variable length vector. This avoids the having the length of 1869 the AVP sequence specified redundantly both in the encapsulating 1870 Handshake message and as a length prefix in the avps element itself. 1872 11.3.13 The InnerApplicationFailure Alert 1874 An InnerApplicationFailure error alert may be sent by either party 1875 during an application phase. This indicates that the sending party 1876 considers the negotiation to have failed due to an application 1877 carried in the AVP sequences, for example, a failed authentication. 1879 The AlertLevel for an InnerApplicationFailure alert MUST be set to 1880 "fatal". 1882 Note that other alerts are possible during an application phase; for 1883 example, decrypt_error. The InnerApplicationFailure alert relates 1884 specifically to the failure of an application implemented via AVP 1885 sequences; for example, failure of an EAP or other authentication 1886 method, or information passed within the AVP sequence that is found 1887 unsatisfactory. 1889 11.4 Binding of TLS/IA to EAP-TTLS v1 1891 EAP-TTLS v1 encapsulates a TLS handshake with the InnerApplication 1892 extension (TLS/IA). EAP-TTLS v1 acts as a carrier protocol for 1893 TLS/IA, and uses cryptographic information developed during the 1894 TLS/IA exchange to create session keys for encrypting subsequent 1895 data transmission between client and access point. 1897 The format for encapsulated TLS/IA messages in EAP-TTLS v1 is 1898 identical to the formats described for EAP-TTLS v0 in Section 8, 1899 unless otherwise specified 1901 11.4.1 Flags Octet 1903 Use of version 1 of EAP-TTLS is negotiated through a new 3-bit 1904 "Version" field in the Flags octet of the EAP-TTLS request/response 1905 header. The Flags octet is the first octet of each EAP-TTLS message, 1906 following immediately after the EAP type. The Version field uses 1907 bits of the Flags octet that were formerly reserved and required to 1908 be 0. 1910 The new bit field definitions for the Flags octet are as follows: 1912 0 1 2 3 4 5 6 7 1913 +---+---+---+---+---+---+---+---+ 1914 | L M S R R | Version | 1915 +---+---+---+---+---+---+---+---+ 1917 where: 1919 L = Length included 1921 M = More fragments 1923 S = Start 1925 R = Reserved 1927 Version = EAP-TTLS version number 1929 For EAP-TTLS v1, Version is set to 1; that is, the bit sequence 001. 1931 Interpretation of L, M and S are as in EAP-TTLS v0. 1933 11.4.2 Version Negotiation 1935 The version of EAP-TTLS is negotiated in the first exchange between 1936 server and client. The server sets the highest version number of 1937 EAP-TTLS that it supports in the Version field of its Start message 1938 (in the case of EAP-TTLS v1, this is 1). In its first EAP message in 1939 response, the client sets the Version field to the highest version 1940 number that it supports that is no higher than the version number 1941 offered by the server. If the client version is not acceptable to 1942 the server, it sends an EAP-Failure to terminate the EAP session. 1943 Otherwise, the version sent by the client is the version of EAP-TTLS 1944 that MUST be used, and both server and client set the version field 1945 to that version number in all subsequent EAP messages. 1947 11.4.3 Acknowledgement Packets 1949 An Acknowledgement packet is an EAP-TTLS v1 packet with no 1950 additional data beyond the Flags octet, and with the L, M and S bits 1951 of the Flags octet set to 0. (Note, however, that the Version field 1952 MUST still be set to the appropriate version number.) 1954 An Acknowledgement packet is sent for the following purposes: 1956 - Fragment acknowledgement 1958 - Error alert acknowledgement 1960 Note that in EAP-TTLS v0 there are other cases in which a packet 1961 with no data must be sent by the client for the simple reason that 1962 the client has no AVPs to send. This situation does not arise in 1963 EAP-TTLS v1. If no AVPs are to be sent, there will nevertheless be 1964 an ApplicationPayload message containing no data, which the client 1965 must send. 1967 - Fragment Acknowledgement 1969 Each EAP-TTLS v1 message contains a sequence of TLS/IA messages 1970 that represent a single leg of a half-duplex conversation. The 1971 EAP carrier protocol (e.g., PPP, EAPOL, RADIUS) may impose 1972 constraints on the length of of an EAP message. Therefore it may 1973 be necessary to fragment an EAP-TTLS v1 message across multiple 1974 EAP messages. 1976 Each fragment except for the last MUST have the M bit set, to 1977 indicate that more data is to follow; the final fragment MUST NOT 1978 have the M bit set. The party that receives a message with the M 1979 bit set MUST respond with an Acknowledgement packet. 1981 - Error Alert Acknowledgement 1983 Either party may at any time send a TLS error alert to fail the 1984 TLS/IA handshake. 1986 If the client sends an error alert to the server, no further EAP- 1987 TTLS messages are exchanged, and the server sends an EAP-Failure 1988 to terminate the conversation. 1990 If the server sends an error alert to the client, the client MUST 1991 respond with an Acknowledgement packet to allow the conversation 1992 to continue. Upon receipt of the Acknowledgement packet, the 1993 server sends an EAP-Failure to terminate the conversation. 1995 11.4.4 Generating Keying Material 1997 EAP-TTLS v1 uses the same mechanism as EAP-TTLS v0 to generate 1998 keying material (session keys) for use in the data connection 1999 between client and access point. 2001 Note that it is the final master secret of the TLS/IA exchange that 2002 is used to generate keying material for use in the subsequent data 2003 connection. 2005 12. Discussion of Certificates and PKI 2007 Public-key cryptography, certificates, and the associated PKI are 2008 used in EAP-TTLS to authenticate the EAP-TTLS server to the client, 2009 and optionally the client to the EAP-TTLS server. Previous 2010 experience with the deployment of PKI in applications has shown that 2011 its implementation requires care. This section provides a brief 2012 discussion of the issues implementers will face when deploying PKI 2013 for EAP-TTLS. 2015 The traditional use of TLS for securing e-commerce transactions over 2016 the Internet is perhaps the best-known deployment of PKI, and it 2017 serves to illustrate several of the issues relevant here. In the 2018 case of e-commerce: 2020 - The environment is many-to-many - many consumers do business with 2021 many merchants. Typically there is no relationship in advance 2022 between a consumer and a merchant. 2024 - Users are "notoriously bad" about following security guidelines. 2025 When presented with a dialogue saying "the name in the 2026 certificate is different from the name you requested", most users 2027 will simply continue with the transaction. 2029 - Support for revocation is limited. It is important to understand 2030 that the environments in which EAP-TTLS are likely to be deployed 2031 will typically be very different from e-commerce. 2033 In particular, many deployments will be comparable to deploying 2034 wireless LAN within an enterprise. In this case, the communications 2035 topology is essentially many-to-one or many-to-few - many employees 2036 talking to a few EAP-TTLS servers - and all clients are essentially 2037 governed by their employer rather than autonomous. 2039 This means: 2041 - It may be unnecessary to rely on a public CA. Instead the 2042 enterprise could choose to run its own CA (either insourced or 2043 outsourced). 2045 - The enterprise could choose to enforce stringent policies on 2046 certificate validation and processing - for example simply 2047 insisting connections are dropped if the correct name does not 2048 appear in the server certificate. Such policies could be enforced 2049 via extensions in the root certificate of the enterprise CA. 2051 However it also means: 2053 - EAP-TTLS servers may receive considerably less attention than the 2054 web servers of large e-commerce sites. As a result, compromise of 2055 EAP-TTLS servers may be more common, and therefore deployment and 2056 use of revocation solutions may be more relevant. 2058 One open question in the area of PKI on which the authors would like 2059 to promote discussion is the following: 2061 - Should EAP-TTLS enforce rules on name matching regarding the EAP- 2062 TTLS server? For example, EAP-TTLS could mandate that 2063 radius.xyz.realm or diameter.xyz.realm be used as the name in the 2064 EAP-TTLS server's certificate, and that the client must match 2065 this name with the realm it sent in the initial EAP- 2066 Response/Identity. 2068 13. Message Sequences 2070 [Author's note: The message sequences in these sections apply to 2071 version 0 of the EAP-TTLS protocol. Messages sequences for version 1 2072 have not yet been completed.] 2074 This section presents EAP-TTLS message sequences for various 2075 negotiation scenarios. These examples do not attempt to exhaustively 2076 depict all possible scenarios. 2078 It is assumed that RADIUS is the AAA carrier protocol both between 2079 access point and TTLS server, and between TTLS server and AAA/H. 2081 EAP packets that are passed unmodified between client and TTLS 2082 server by the access point are indicated as "passthrough". AVPs that 2083 are securely tunneled within the TLS record layer are enclosed in 2084 curly braces ({}). Items that are optional are suffixed with 2085 question mark (?). Items that may appear multiple times are suffixed 2086 with plus sign (+). 2088 13.1 Successful authentication via tunneled CHAP 2090 In this example, the client performs one-way TLS authentication of 2091 the TTLS server nad CHAP is used as a tunneled user authentication 2092 mechanism. 2094 client access point TTLS server AAA/H 2095 ------ ------------ ----------- ----- 2097 EAP-Request/Identity 2098 <-------------------- 2100 EAP-Response/Identity 2101 --------------------> 2103 RADIUS Access-Request: 2104 EAP-Response passthrough 2105 --------------------> 2107 RADIUS Access-Challenge: 2108 EAP-Request/TTLS-Start 2109 <-------------------- 2111 EAP-Request passthrough 2112 <-------------------- 2114 EAP-Response/TTLS: 2115 ClientHello 2116 --------------------> 2117 RADIUS Access-Request: 2118 EAP-Response passthrough 2119 --------------------> 2121 RADIUS Access-Challenge: 2122 EAP-Request/TTLS: 2123 ServerHello 2124 Certificate 2125 ServerKeyExchange 2126 ServerHelloDone 2127 <-------------------- 2129 EAP-Request passthrough 2130 <-------------------- 2132 EAP-Response/TTLS: 2133 ClientKeyExchange 2134 ChangeCipherSpec 2135 Finished 2136 --------------------> 2138 RADIUS Access-Request: 2139 EAP-Response passthrough 2140 --------------------> 2142 RADIUS Access-Challenge: 2143 EAP-Request/TTLS: 2144 ChangeCipherSpec 2145 Finished 2146 <-------------------- 2148 EAP-Request passthrough 2149 <-------------------- 2151 EAP-Response/TTLS: 2152 {User-Name} 2153 {CHAP-Challenge} 2154 {CHAP-Password} 2155 --------------------> 2157 RADIUS Access-Request: 2158 EAP-Response passthrough 2159 --------------------> 2161 RADIUS Access-Request: 2162 User-Name 2163 CHAP-Challenge 2164 CHAP-Password 2165 --------------------> 2166 RADIUS Access-Accept 2167 <-------------------- 2169 RADIUS Access-Accept: 2170 EAP-Success 2171 <-------------------- 2173 EAP-Success passthrough 2174 <-------------------- 2176 13.2 Successful authentication via tunneled EAP/MD5-Challenge 2178 In this example, the client performs one-way TLS authentication of 2179 the TTLS server and EAP/MD5-Challenge is used as a tunneled user 2180 authentication mechanism. 2182 client access point TTLS server AAA/H 2183 ------ ------------ ----------- ----- 2185 EAP-Request/Identity 2186 <-------------------- 2188 EAP-Response/Identity 2189 --------------------> 2191 RADIUS Access-Request: 2192 EAP-Response passthrough 2193 --------------------> 2195 RADIUS Access-Challenge: 2196 EAP-Request/TTLS-Start 2197 <-------------------- 2199 EAP-Request passthrough 2200 <-------------------- 2202 EAP-Response/TTLS: 2203 ClientHello 2204 --------------------> 2206 RADIUS Access-Request: 2207 EAP-Response passthrough 2208 --------------------> 2210 RADIUS Access-Challenge: 2211 EAP-Request/TTLS: 2212 ServerHello 2213 Certificate 2214 ServerKeyExchange 2215 ServerHelloDone 2216 <-------------------- 2218 EAP-Request passthrough 2219 <-------------------- 2221 EAP-Response/TTLS: 2222 ClientKeyExchange 2223 ChangeCipherSpec 2224 Finished 2225 --------------------> 2227 RADIUS Access-Request: 2228 EAP-Response passthrough 2229 --------------------> 2231 RADIUS Access-Challenge: 2232 EAP-Request/TTLS: 2233 ChangeCipherSpec 2234 Finished 2235 <-------------------- 2237 EAP-Request passthrough 2238 <-------------------- 2240 EAP-Response/TTLS: 2241 {EAP-Response/Identity} 2242 --------------------> 2244 RADIUS Access-Request: 2245 EAP-Response passthrough 2246 --------------------> 2248 RADIUS Access-Request: 2249 EAP-Response/Identity 2250 --------------------> 2252 RADIUS Access-Challenge 2253 EAP-Request/ 2254 MD5-Challenge 2255 --------------------> 2257 RADIUS Access-Challenge: 2258 EAP-Request/TTLS: 2259 {EAP-Request/MD5-Challenge} 2260 <-------------------- 2262 EAP-Request passthrough 2263 <-------------------- 2265 EAP-Response/TTLS: 2266 {EAP-Response/MD5-Challenge} 2267 --------------------> 2268 RADIUS Access-Request: 2269 EAP-Response passthrough 2270 --------------------> 2272 RADIUS Access-Challenge 2273 EAP-Response/ 2274 MD5-Challenge 2275 --------------------> 2277 RADIUS Access-Accept 2278 <-------------------- 2280 RADIUS Access-Accept: 2281 EAP-Success 2282 <-------------------- 2284 EAP-Success passthrough 2285 <-------------------- 2287 13.3 Successful session resumption 2289 In this example, the client and server resume a previous TLS 2290 session. The ID of the session to be resumed is sent as part of the 2291 ClientHello, and the server agrees to resume this session by sending 2292 the same session ID as part of ServerHello. 2294 client access point TTLS server AAA/H 2295 ------ ------------ ----------- ----- 2297 EAP-Request/Identity 2298 <-------------------- 2300 EAP-Response/Identity 2301 --------------------> 2303 RADIUS Access-Request: 2304 EAP-Response passthrough 2305 --------------------> 2307 RADIUS Access-Challenge: 2308 EAP-Request/TTLS-Start 2309 <-------------------- 2311 EAP-Request passthrough 2312 <-------------------- 2314 EAP-Response/TTLS: 2315 ClientHello 2316 --------------------> 2317 RADIUS Access-Request: 2318 EAP-Response passthrough 2319 --------------------> 2321 RADIUS Access-Challenge: 2322 EAP-Request/TTLS: 2323 ServerHello 2324 ChangeCipherSpec 2325 Finished 2326 <-------------------- 2328 EAP-Request passthrough 2329 <-------------------- 2331 EAP-Response/TTLS: 2332 ChangeCipherSpec 2333 Finished 2334 --------------------> 2336 RADIUS Access-Request: 2337 EAP-Response passthrough 2338 --------------------> 2340 RADIUS Access-Accept: 2341 EAP-Success 2342 <-------------------- 2344 EAP-Success passthrough 2345 <-------------------- 2347 14. Security Considerations 2349 This draft is entirely about security and the security 2350 considerations associated with the mechanisms employed in this 2351 document should be considered by implementers. 2353 The following additional issues are relevant: 2355 - Anonymity and privacy. Unlike other EAP methods, EAP-TTLS does 2356 not communicate a username in the clear in the initial EAP- 2357 Response/Identity. This feature is designed to support anonymity 2358 and location privacy from attackers eavesdropping the network 2359 path between the client and the TTLS server. However implementers 2360 should be aware that other factors - both within EAP-TTLS and 2361 elsewhere - may compromise a user's identity. For example, if a 2362 user authenticates with a certificate during phase 1 of EAP-TTLS, 2363 the subject name in the certificate may reveal the user's 2364 identity. Outside of EAP-TTLS, the client's fixed MAC address, or 2365 in the case of wireless connections, the client's radio 2366 signature, may also reveal information. Additionally, 2367 implementers should be aware that a user's identity is not hidden 2368 from the EAP-TTLS server and may be included in the clear in AAA 2369 messages between the access point, the EAP-TTLS server, and the 2370 AAA/H server. 2372 - Trust in the EAP-TTLS server. EAP-TTLS is designed to allow the 2373 use of legacy authentication methods to be extended to mediums 2374 like wireless in which eavesdropping the link between the client 2375 and the access point is easy. However implementers should be 2376 aware of the possibility of attacks by rogue EAP-TTLS servers - 2377 for example in the event that the phase 2 authentication method 2378 within EAP-TTLS is susceptible to dictionary attacks. These 2379 threats can be mitigated through the use of authentication 2380 methods like one-time passwords which are not susceptible to 2381 dictionary attacks, or by ensuring that clients connect only to 2382 trusted EAP-TTLS servers. 2384 - EAP-TTLS server certificate compromise. The use of EAP-TTLS 2385 server certificates within EAP-TTLS makes EAP-TTLS susceptible to 2386 attack in the event that an EAP-TTLS server's certificate is 2387 compromised. EAP-TTLS servers should therefore take care to 2388 protect their private key. In addition, certificate revocation 2389 methods may be used to mitigate against the possibility of key 2390 compromise. [13] describes a way to integrate one such method - 2391 OCSP [14] - into the TLS handshake - use of this approach may be 2392 appropriate within EAP-TTLS. 2394 - Negotiation of link encryption. EAP-TTLS includes a method to 2395 negotiate data cipher suites. It also allows data cipher suites 2396 to be negotiated by other means - for example by having client 2397 and access point exchange their preferences using the link layer 2398 protocol. However the use of the EAP-TTLS negotiation is strongly 2399 recommended because it provides a secured negotiation. In 2400 contrast, simple unsecured preference exchange over the link 2401 layer is susceptible to a man-in-the-middle attack that forces 2402 the parties to use the weakest, rather than the strongest, 2403 mutually acceptable data cipher suite. The potential of this 2404 problem is well-illustrated by wireless LAN where for 2405 interoperability purposes many entities will have to continue to 2406 support WEP encryption for some time. In the event that the data 2407 link protocol already includes a negotiation exchange, it is 2408 recommended that the EAP-TTLS exchange still be used, with the 2409 link layer exchange simply confirming the data cipher suite 2410 selected using EAP-TTLS. 2412 - Listing of data cipher preferences. EAP-TTLS negotiates data 2413 cipher suites by having the EAP-TTLS server select the first 2414 cipher suite appearing on the client list that also appears on 2415 the access point list. In order to maximize security, it is 2416 therefore recommended that the client order its list according to 2417 security - most secure acceptable cipher suite first, least 2418 secure acceptable cipher suite last. 2420 - Forward secrecy. With forward secrecy, revelation of a secret 2421 does not compromise session keys previously negotiated based on 2422 that secret. Thus, when the TLS key exchange algorithm provides 2423 forward secrecy, if a TTLS server certificate's private key is 2424 eventually stolen or cracked, tunneled user password information 2425 will remain secure as long as that certificate is no longer in 2426 use. Diffie-Hellman key exchange is an example of an algorithm 2427 that provides forward secrecy. A forward secrecy algorithm should 2428 be considered if attacks against recorded authentication or data 2429 sessions are considered to pose a significant threat. 2431 15. Changes since previous drafts 2433 Other than minor editorial changes, the following changes have been 2434 made to this draft: 2436 Since version 04: 2438 - An enhanced version of EAP-TTLS, called version 1, has been 2439 defined in section 11. 2441 Since version 03: 2443 - Removed section on keying information. 2445 Since version 02: 2447 - Added password change for MS-CHAP-V2. 2449 Since version 01: 2451 - In section 11, the TTLS server's response with data cipher suites 2452 has been made conditional on receiving data cipher suite 2453 preferences from both client and access point. Also, implicit 2454 acceptance of the client's preferred data cipher suite has been 2455 eliminated in favor of explicitly returning the data cipher suite 2456 selection. 2458 Since version 00: 2460 - A Table of Contents has been added. 2462 - In section 3, a definition of "access domain" has been added. 2464 - In section 6.4, the requirement has been added that TLS session 2465 resumption must not be allowed for any negotiation that succeeds 2466 in phase 1 TLS handshake but does not successfully complete phase 2467 2 authentication. 2469 - In sections 7 and 10.1, reversed the order of randoms used in 2470 PRF, to follow EAP-TLS practice and avoid namespace collisions 2471 with TLS. 2473 - In section 8, specified the assigned EAP-TTLS number. 2475 - Added section 8.1, reserving for future standardization the 2476 ability to add data to an EAP-TTLS Start packet. 2478 16. References 2480 [1] Aboba, B., and D. Simon, "PPP EAP TLS Authentication 2481 Protocol", RFC 2716, October 1999. 2483 [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2484 Levkowetz, "PPP Extensible Authentication Protocol (EAP)", RFC 2485 3784, June 2004. 2487 [3] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0", RFC 2488 2246, November 1998. 2490 [4] Institute for Electrical and Electronics Engineers, "IEEE 2491 802.1X, Standard for Port Based Network Access Control", 2001. 2493 [5] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 2494 51, RFC 1661, July 1994. 2496 [6] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 2497 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2498 2000. 2500 [7] Aboba, B., and M. Beadles, "The Network Access Identifier", 2501 RFC 2486, January 1999. 2503 [8] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 2504 Arkko, "Diameter Base Protocol", RFC 3588, July 2001. 2506 [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 2507 October 1994. 2509 [10] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2510 2433, October 1998. 2512 [11] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2513 2759, January 2000. 2515 [12] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2516 2548, March 1999. 2518 [13] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 2519 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 2520 3546, June 2003. 2522 [14] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 2523 Adams, "Internet X.509 Public Key Infrastructure: Online 2524 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 2526 [15] Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the-Middle in 2527 Tunneled Authentication", 2528 http://www.saunalahti.fi/~asokan/research/mitm.html, Nokia 2529 Research Center, Finland, October 24 2002. 2531 [16] Puthenkulam, J., "The Compound Authentication Binding 2532 Problem", draft-puthenkulam-eap-binding-04.txt, October 2003. 2534 17. Authors' Addresses 2536 Questions about this memo can be directed to: 2538 Paul Funk 2539 Funk Software, Inc. 2540 222 Third Street 2541 Cambridge, MA 02142 2542 USA 2544 Phone: +1 617 497-6339 2545 E-mail: paul@funk.com 2547 Simon Blake-Wilson 2548 Basic Commerce & Industries, Inc. 2549 304 Harper Drive, Suite 203 2550 Moorestown, NJ 08057 2552 Phone: +1 856 778-1660 2553 E-mail: sblakewilson@bcisse.com 2555 18. Full Copyright Statement 2557 Copyright (C) The Internet Society (2001-2004). All Rights Reserved. 2559 This document and translations of it may be copied and furnished to 2560 others, and derivative works that comment on or otherwise explain it 2561 or assist in its implementation may be prepared, copied, published 2562 and distributed, in whole or in part, without restriction of any 2563 kind, provided that the above copyright notice and this paragraph 2564 are included on all such copies and derivative works. However, this 2565 document itself may not be modified in any way, such as by removing 2566 the copyright notice or references to the Internet Society or other 2567 Internet organizations, except as needed for the purpose of 2568 developing Internet standards in which case the procedures for 2569 copyrights defined in the Internet Standards process must be 2570 followed, or as required to translate it into languages other than 2571 English. 2573 The limited permissions granted above are perpetual and will not be 2574 revoked by the Internet Society or its successors or assigns. 2576 This document and the information contained herein is provided on an 2577 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2578 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2579 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2580 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2581 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.