idnits 2.17.1 draft-ietf-pppext-eap-ttls-03.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2003) is 7560 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) ** Obsolete normative reference: RFC 2716 (ref. '1') (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2284 (ref. '2') (Obsoleted by RFC 3748) ** 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) == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-07 ** 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') == Outdated reference: A later version (-06) exists of draft-ietf-tls-extensions-00 ** Obsolete normative reference: RFC 2560 (ref. '14') (Obsoleted by RFC 6960) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 August 2003 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). 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 Table of Contents 64 1. Introduction......................................................3 65 2. Motivation........................................................4 66 3. Terminology.......................................................5 67 4. Architectural Model...............................................8 68 4.1 Carrier Protocols.............................................8 69 4.2 Security Relationships........................................9 70 4.3 Messaging.....................................................9 71 4.4 Resulting Security...........................................10 72 5. Protocol Layering Model..........................................10 73 6. Protocol Overview................................................11 74 6.1 Phase 1: Handshake...........................................12 75 6.2 Phase 2: Tunnel..............................................13 76 6.3 Piggybacking.................................................14 77 6.4 Session Resumption...........................................14 78 6.4.1 TTLS Server Guidelines for Session Resumption............15 79 7. Generating Keying Material.......................................16 80 8. EAP-TTLS Encoding................................................16 81 8.1 EAP-TTLS Start Packet........................................17 82 8.2 EAP-TTLS Packets with No Data................................17 83 9. Encapsulation of AVPs within the TLS Record Layer................17 84 9.1 AVP Format...................................................18 85 9.2 AVP Sequences................................................19 86 9.3 Guidelines for Maximum Compatibility with AAA Servers........19 87 10. Tunneled Authentication..........................................20 88 10.1 Implicit challenge...........................................20 89 10.2 Tunneled Authentication Protocols............................21 90 10.2.1 EAP ......................................................21 91 10.2.2 CHAP .....................................................22 92 10.2.3 MS-CHAP..................................................23 93 10.2.4 MS-CHAP-V2...............................................23 94 10.2.5 PAP ......................................................25 95 10.3 Performing Multiple Authentications..........................26 96 11. Key Distribution.................................................26 97 11.1 AVPs for Key Distribution....................................27 98 11.1.1 XXX-Data-Cipher-Suite....................................27 99 11.1.2 XXX-Data-Keying-Material.................................28 100 12. Discussion of Certificates and PKI...............................29 101 13. Message Sequences................................................30 102 13.1 Successful authentication via tunneled CHAP..................30 103 13.2 Successful authentication via tunneled EAP/MD5-Challenge.....32 104 13.3 Successful session resumption................................35 105 14. Security Considerations..........................................37 106 15. Changes since previous drafts....................................38 107 16. References.......................................................39 108 17. Authors' Addresses...............................................40 109 18. Full Copyright Statement.........................................40 111 1. Introduction 113 Extensible Authentication Protocol (EAP) [2] defines a standard 114 message exchange that allows a server to authenticate a client based 115 on an authentication protocol agreed upon by both parties. EAP may 116 be extended with additional authentication protocols by registering 117 such protocols with IANA. 119 Transport Layer Security (TLS) [3] is an authentication protocol 120 that provides for client authentication of a server or mutual 121 authentication of client and server, as well as secure ciphersuite 122 negotiation and key exchange between the parties. TLS has been 123 defined as an authentication protocol for use within EAP (EAP-TLS) 124 [1]. 126 Other authentication protocols are also widely deployed. These are 127 typically password-based protocols, and there is a large installed 128 base of support for these protocols in the form of credential 129 databases that may be accessed by RADIUS, Diameter or other AAA 130 servers. These include non-EAP protocols such as PAP, CHAP, MS-CHAP 131 and MS-CHAP-V2, as well as EAP protocols such as MD5-Challenge. 133 EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS 134 handshake is used to mutually authenticate a client and server. EAP- 135 TTLS extends this authentication negotiation by using the secure 136 connection established by the TLS handshake to exchange additional 137 information between client and server. In EAP-TTLS, the TLS 138 handshake may be mutual; or it may be one-way, in which only the 139 server is authenticated to the client. The secure connection 140 established by the handshake may then be used to allow the server to 141 authenticate the client using existing, widely-deployed 142 authentication infrastructures such as RADIUS. The authentication of 143 the client may itself be EAP, or it may be another authentication 144 protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. 146 Thus, EAP-TTLS allows legacy password-based authentication protocols 147 to be used against existing authentication databases, while 148 protecting the security of these legacy protocols against 149 eavesdropping, man-in-the-middle and other cryptographic attacks. 151 EAP-TTLS also allows client and server to establish keying material 152 for use in the data connection between the client and access point. 153 The keying material is established implicitly between client and 154 server based on the TLS handshake. 156 In EAP-TTLS, client and server communicate using attribute-value 157 pairs encrypted within TLS. This generality allows arbitrary 158 functions beyond authentication and key exchange to be added to the 159 EAP negotiation, in a manner compatible with the AAA infrastructure. 161 2. Motivation 163 Most password-based protocols in use today rely on a hash of the 164 password with a random challenge. Thus, the server issues a 165 challenge, the client hashes that challenge with the password and 166 forwards a response to the server, and the server validates that 167 response against the user's password retrieved from its database. 168 This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5- 169 Challenge and EAP/One-Time Password. 171 An issue with such an approach is that an eavesdropper that observes 172 both challenge and response may be able to mount a dictionary 173 attack, in which random passwords are tested against the known 174 challenge to attempt to find one which results in the known 175 response. Because passwords typically have low entropy, such attacks 176 can in practice easily discover many passwords. 178 While this vulnerability has long been understood, it has not been 179 of great concern in environments where eavesdropping attacks are 180 unlikely in practice. For example, users with wired or dial-up 181 connections to their service providers have not been concerned that 182 such connections may be monitored. Users have also been willing to 183 entrust their passwords to their service providers, or at least to 184 allow their service providers to view challenges and hashed 185 responses which are then forwarded to their home authentication 186 servers using, for example, proxy RADIUS, without fear that the 187 service provider will mount dictionary attacks on the observed 188 credentials. Because a user typically has a relationship with a 189 single service provider, such trust is entirely manageable. 191 With the advent of wireless connectivity, however, the situation 192 changes dramatically: 194 - Wireless connections are considerably more susceptible to 195 eavesdropping and man-in-the-middle attacks. These attacks may 196 enable dictionary attacks against low-entropy passwords. In 197 addition, they may enable channel hijacking, in which an attacker 198 gains fraudulent access by seizing control of the communications 199 channel after authentication is complete. 201 - Existing authentication protocols often begin by exchanging the 202 client�s username in the clear. In the context of eavesdropping 203 on the wireless channel, this can compromise the client�s 204 anonymity and locational privacy. 206 - Often in wireless networks, the access point does not reside in 207 the administrative domain of the service provider with which the 208 user has a relationship. For example, the access point may reside 209 in an airport, coffee shop, or hotel in order to provide public 210 access via 802.11. Even if password authentications are protected 211 in the wireless leg, they may still be susceptible to 212 eavesdropping within the untrusted wired network of the access 213 point. 215 - In the traditional wired world, the user typically intentionally 216 connects with a particular service provider by dialing an 217 associated phone number; that service provider may be required to 218 route an authentication to the user's home domain. In a wireless 219 network, however, the user does not get to choose an access 220 domain, and must connect with whichever access point is nearby; 221 providing for the routing of the authentication from an arbitrary 222 access point to the user's home domain may pose a challenge. 224 Thus, the authentication requirements for a wireless environment 225 that EAP-TTLS attempts to address can be summarized as follows: 227 - Legacy password protocols must be supported, to allow easy 228 deployment against existing authentication databases. 230 - Password-based information must not be observable in the 231 communications channel between the client node and a trusted 232 service provider, to protect the user against dictionary attacks. 234 - The user's identity must not be observable in the communications 235 channel between the client node and a trusted service provider, 236 to protect the user's locational privacy against surveillance, 237 undesired acquisition of marketing information, and the like. 239 - The authentication process must result in the distribution of 240 shared keying information to the client and access point to 241 permit encryption and validation of the wireless data connection 242 subsequent to authentication, to secure it against eavesdroppers 243 and prevent channel hijacking. 245 - The authentication mechanism must support roaming among small 246 access domains with which the user has no relationship and which 247 will have limited capabilities for routing authentication 248 requests. 250 3. Terminology 252 AAA 253 Authentication, Authorization and Accounting - functions that are 254 generally required to control access to a network and support 255 billing and auditing. 257 AAA protocol 259 A network protocol used to communicate with AAA servers; examples 260 include RADIUS and Diameter. 262 AAA server 264 A server which performs one or more AAA functions: authenticating 265 a user prior to granting network service, providing authorization 266 (policy) information governing the type of network service the 267 user is to be granted, and accumulating accounting information 268 about actual usage. 270 AAA/H 272 A AAA server in the user's home domain, where authentication and 273 authorization for that user are administered. 275 access point 277 A network device providing users with a point of entry into the 278 network, and which may enforce access control and policy based on 279 information returned by a AAA server. For the purposes of this 280 document, "access point" and "NAS" are architecturally 281 equivalent. "Access point" is used throughout because it is 282 suggestive of devices used for wireless access; "NAS" is used 283 when more traditional forms of access, such as dial-up, are 284 discussed. 286 access domain 288 The domain, including access points and other devices, that 289 provides users with an initial point of entry into the network; 290 for example, a wireless hot spot. 292 client 294 A host or device that connects to a network through an access 295 point. 297 domain 299 A network and associated devices that are under the 300 administrative control of an entity such as a service provider or 301 the user's home organization. 303 link layer protocol 304 A protocol used to carry data between hosts that are connected 305 within a single network segment; examples include PPP and 306 Ethernet. 308 NAI 310 A Network Access Identifier [7], normally consisting of the name 311 of the user and, optionally, the user's home realm. 313 NAS 315 A network device providing users with a point of entry into the 316 network, and which may enforce access control and policy based on 317 information returned by a AAA server. For the purposes of this 318 document, "access point" and "NAS" are architecturally 319 equivalent. "Access point" is used throughout because it is 320 suggestive of devices used for wireless access; "NAS" is used 321 when more traditional forms of access, such as dial-up, are 322 discussed. 324 proxy 326 A server that is able to route AAA transactions to the 327 appropriate AAA server, possibly in another domain, typically 328 based on the realm portion of an NAI. 330 realm 332 The optional part of an NAI indicating the domain to which a AAA 333 transaction is to be routed, normally the user's home domain. 335 service provider 337 An organization with which a user has a business relationship, 338 that provides network or other services. The service provider may 339 provide the access equipment with which the user connects, may 340 perform authentication or other AAA functions, may proxy AAA 341 transactions to the user's home domain, etc. 343 TTLS server 345 A AAA server which implements EAP-TTLS. This server may also be 346 capable of performing user authentication, or it may proxy the 347 user authentication to a AAA/H. 349 user 351 The person operating the client device. Though the line is often 352 blurred, "user" is intended to refer to the human being who is 353 possessed of an identity (username), password or other 354 authenticating information, and "client" is intended to refer to 355 the device which makes use of this information to negotiate 356 network access. There may also be clients with no human 357 operators; in this case the term "user" is a convenient 358 abstraction. 360 4. Architectural Model 362 The network architectural model for EAP-TTLS usage and the type of 363 security it provides is shown below. 365 +----------+ +----------+ +----------+ +----------+ 366 | | | | | | | | 367 | client |<---->| access |<---->| TTLS AAA |<---->| AAA/H | 368 | | | point | | server | | server | 369 | | | | | | | | 370 +----------+ +----------+ +----------+ +----------+ 372 <---- secure password authentication tunnel ---> 374 <---- secure data tunnel ----> 376 The entities depicted above are logical entities and may or may not 377 correspond to separate network components. For example, the TTLS 378 server and AAA/H server might be a single entity; the access point 379 and TTLS server might be a single entity; or, indeed, the functions 380 of the access point, TTLS server and AAA/H server might be combined 381 into a single physical device. The above diagram illustrates the 382 division of labor among entities in a general manner and shows how a 383 distributed system might be constructed; however, actual systems 384 might be realized more simply. 386 Note also that one or more AAA proxy servers might be deployed 387 between access point and TTLS server, or between TTLS server and 388 AAA/H server. Such proxies typically perform aggregation or are 389 required for realm-based message routing. However, such servers play 390 no direct role in EAP-TTLS and are therefore not shown. 392 4.1 Carrier Protocols 394 The entities shown above communicate with each other using carrier 395 protocols capable of encapsulating EAP. The client and access point 396 communicate using a link layer carrier protocol such as PPP or 397 EAPOL. The access point, TTLS server and AAA/H server communicate 398 using a AAA carrier protocol such as RADIUS or Diameter. 400 EAP, and therefore EAP-TTLS, must be initiated via the link layer 401 protocol. In PPP or EAPOL, for example, EAP is initiated when the 402 access point sends an EAP-Request/Identity packet to the client. 404 The keying material used to encrypt and authenticate the data 405 connection between the client and access point is developed 406 implicitly between the client and TTLS server as a result of EAP- 407 TTLS negotiation. This keying material must be communicated to the 408 access point by the TTLS server using the AAA carrier protocol. 410 The client and access point must also agree on an 411 encryption/validation algorithm to be used based on the keying 412 material. In some systems, both these devices may be preconfigured 413 with this information, and distribution of the keying material alone 414 is sufficient. Or, the link layer protocol may provide a mechanism 415 for client and access point to negotiate an algorithm. 417 In the most general case, however, it may be necessary for both 418 client and access point to communicate their algorithm preferences 419 to the TTLS server, and for the TTLS server to select one and 420 communicate its choice to both parties. This information would be 421 transported between access point and TTLS server via the AAA 422 protocol, and between client and TTLS server via EAP-TTLS in 423 encrypted form. 425 4.2 Security Relationships 427 The client and access point have no pre-existing security 428 relationship. 430 The access point, TTLS server and AAA/H server are each assumed to 431 have a pre-existing security association with the adjacent entity 432 with which it communicates. With RADIUS, for example, this is 433 achieved using shared secrets. It is essential for such security 434 relationships to permit secure key distribution. 436 The client and AAA/H server have a security relationship based on 437 the user's credentials such as a password. 439 The client and TTLS server may have a one-way security relationship 440 based on the TTLS server's possession of a private key guaranteed by 441 a CA certificate which the user trusts, or may have a mutual 442 security relationship based on certificates for both parties. 444 4.3 Messaging 446 The client and access point initiate an EAP conversation to 447 negotiate the client's access to the network. Typically, the access 448 point issues an EAP-Request/Identity to the client, which responds 449 with an EAP-Response/Identity. Note that the client does not include 450 the user's actual identity in this EAP-Response/Identity packet; the 451 user's identity will not be transmitted until an encrypted channel 452 has been established. 454 The access point now acts as a passthrough device, allowing the TTLS 455 server to negotiate EAP-TTLS with the client directly. 457 During the first phase of the negotiation, the TLS handshake 458 protocol is used to authenticate the TTLS server to the client and, 459 optionally, to authenticate the client to the TTLS server, based on 460 public/private key certificates. As a result of the handshake, 461 client and TTLS server now have shared keying material and an agreed 462 upon TLS record layer cipher suite with which to secure subsequent 463 EAP-TTLS communication. 465 During the second phase of negotiation, client and TTLS server use 466 the secure TLS record layer channel established by the TLS handshake 467 as a tunnel to exchange information encapsulated in attribute-value 468 pairs, to perform additional functions such as client authentication 469 and key distribution for the subsequent data connection. 471 If a tunneled client authentication is performed, the TTLS server 472 de-tunnels and forwards the authentication information to the AAA/H. 473 If the AAA/H performs a challenge, the TTLS server tunnels the 474 challenge information to the client. The AAA/H server may be a 475 legacy device and needs to know nothing about EAP-TTLS; it only 476 needs to be able to authenticate the client based on commonly used 477 authentication protocols. 479 Keying material for the subsequent data connection between client 480 and access point may be generated based on secret information 481 developed during the TLS handshake between client and TTLS server. 482 At the conclusion of a successful authentication, the TTLS server 483 may transmit this keying material to the access point, encrypted 484 based on the existing security associations between those devices 485 (e.g., RADIUS). 487 The client and access point now share keying material which they can 488 use to encrypt data traffic between them. 490 4.4 Resulting Security 492 As the diagram above indicates, EAP-TTLS allows user identity and 493 password information to be securely transmitted between client and 494 TTLS server, and performs key distribution to allow network data 495 subsequent to authentication to be securely transmitted between 496 client and access point. 498 5. Protocol Layering Model 500 EAP-TTLS packets are encapsulated within EAP, and EAP in turn 501 requires a carrier protocol to transport it. EAP-TTLS packets 502 themselves encapsulate TLS, which is then used to encapsulate user 503 authentication information. Thus, EAP-TTLS messaging can be 504 described using a layered model, where each layer encapsulates the 505 layer beneath it. The following diagram clarifies the relationship 506 between protocols: 508 +--------------------------------------------------------+ 509 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | 510 +--------------------------------------------------------+ 511 | EAP | 512 +--------------------------------------------------------+ 513 | EAP-TTLS | 514 +--------------------------------------------------------+ 515 | TLS | 516 +--------------------------------------------------------+ 517 | User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.) | 518 +--------------------------------------------------------+ 520 When the user authentication protocol is itself EAP, the layering is 521 as follows: 523 +--------------------------------------------------------+ 524 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | 525 +--------------------------------------------------------+ 526 | EAP | 527 +--------------------------------------------------------+ 528 | EAP-TTLS | 529 +--------------------------------------------------------+ 530 | TLS | 531 +--------------------------------------------------------+ 532 | EAP | 533 +--------------------------------------------------------+ 534 | User EAP Authentication Protocol (MD-Challenge, etc.) | 535 +--------------------------------------------------------+ 537 Methods for encapsulating EAP within carrier protocols are already 538 defined. For example, PPP [5] or EAPOL [4] may be used to transport 539 EAP between client and access point; RADIUS [6] or Diameter [8] are 540 used to transport EAP between access point and TTLS server. 542 6. Protocol Overview 544 A EAP-TTLS negotiation comprises two phases: the TLS handshake phase 545 and the TLS tunnel phase. 547 During phase 1, TLS is used to authenticate the TTLS server to the 548 client and, optionally, the client to the TTLS server. Phase 1 549 results in the activation of a cipher suite, allowing phase 2 to 550 proceed securely using the TLS record layer. (Note that the type and 551 degree of security in phase 2 depends on the cipher suite negotiated 552 during phase 1; if the null cipher suite is negotiated, there will 553 be no security!) 554 During phase 2, the TLS record layer is used to tunnel information 555 between client and TTLS server to perform any of a number of 556 functions. These might include user authentication, negotiation of 557 data communication security capabilities, key distribution, 558 communication of accounting information, etc.. Information between 559 client and TTLS server is exchanged via attribute-value pairs (AVPs) 560 compatible with RADIUS and Diameter; thus, any type of function that 561 can be implemented via such AVPs may easily be performed. 563 EAP-TTLS specifies how user authentication may be performed during 564 phase 2. The user authentication may itself be EAP, or it may be a 565 legacy protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Phase 2 566 user authentication may not always be necessary, since the user may 567 already have been authenticated via the mutual authentication option 568 of the TLS handshake protocol. 570 EAP-TTLS is also intended for use in key distribution, and specifies 571 how keying material for the data connection between client and 572 access point is generated. The keying material is developed 573 implicitly between client and TTLS server based on the results of 574 the TLS handshake; the TTLS server will communicate the keying 575 material to the access point over the carrier protocol However, 576 EAP-TTLS does not specify particular key distribution AVPs and their 577 use, since the needs of various systems will be different. Instead, 578 a general model for key distribution is suggested. Organizations may 579 define their own AVPs for this use, possibly using vendor-specific 580 AVPs, either in conformance with the suggested model or otherwise. 582 6.1 Phase 1: Handshake 584 In phase 1, the TLS handshake protocol is used to authenticate the 585 TTLS server to the client and, optionally, to authenticate the 586 client to the TTLS server. 588 Phase 1 is initiated when the client sends an EAP-Response/Identity 589 packet to the TTLS server. This packet specifically should not 590 include the name of the user; however, it may include the name of 591 the realm of a trusted provider to which EAP-TTLS packets should be 592 forwarded; for example, "@myisp.com". 594 The TTLS server responds to the EAP-Response/Identity packet with a 595 EAP-TTLS/Start packet, which is an EAP-Request with Type = EAP-TTLS, 596 the S (Start) bit set, and no data. This indicates to the client 597 that it should begin TLS handshake by sending a ClientHello message. 599 EAP packets continue to be exchanged between client and TTLS server 600 to complete the TLS handshake, as described in [1]. Phase 1 is 601 completed when the client and TTLS server exchange ChangeCipherSpec 602 and Finished messages. At this point, additional information may be 603 securely tunneled. 605 As part of the TLS handshake protocol, the TTLS server will send its 606 certificate along with a chain of certificates leading to the 607 certificate of a trusted CA. The client will need to be configured 608 with the certificate of the trusted CA in order to perform the 609 authentication. 611 If certificate-based authentication of the client is desired, the 612 client must have been issued a certificate and must have the private 613 key associated with that certificate 615 6.2 Phase 2: Tunnel 617 In phase 2, the TLS Record Layer is used to securely tunnel 618 information between client and TTLS server. This information is 619 encapsulated in sequences of attribute-value pairs (AVPS), whose use 620 and format are described in later sections. 622 Any type of information may be exchanged during phase 2, according 623 to the requirements of the system. (It is expected that applications 624 utilizing EAP-TTLS will specify what information must be exchanged 625 and therefore which AVPs must be supported.) 627 The client begins the phase 2 exchange by encoding information in a 628 sequence of AVPs, passing this sequence to the TLS record layer for 629 encryption, and sending the resulting data to the TTLS server. 631 The TTLS server recovers the AVPs in clear text from the TLS record 632 layer. If the AVP sequence includes authentication information, it 633 forwards this information to the AAA/H server using the AAA carrier 634 protocol. Note that the EAP-TTLS and AAA/H servers may be one and 635 the same, in which case it simply processes the information locally. 637 The TTLS server may respond with its own sequence of AVPs. The TTLS 638 server passes the AVP sequence to the TLS record layer for 639 encryption and sends the resulting data to the client. For example, 640 the TTLS server may send key distribution information, or it may 641 forward an authentication challenge received from the AAA/H. 643 This process continues until the TTLS server has enough information 644 to issue either an EAP-Success or EAP-Failure. Thus, if the AAA/H 645 rejects the client based on forwarded authentication information, 646 the TTLS server would issue an EAP-Failure. If the AAA/H accepts the 647 client, the TTLS server would issue an EAP-Success. 649 The TTLS server distributes data connection keying information and 650 other authorization information to the access point in the same AAA 651 carrier protocol message that carries the EAP-Success. 653 6.3 Piggybacking 655 While it is convenient to describe EAP-TTLS messaging in terms of 656 two phases, it is sometimes required that a single EAP-TTLS packet 657 to contain both phase 1 and phase 2 TLS messages. 659 Such "piggybacking" occurs when the party that completes the 660 handshake also has AVPs to send. For example, when negotiating a 661 resumed TLS session, the TTLS server sends its ChangeCipherSpec and 662 Finished messages first, then the client sends its own 663 ChangeCipherSpec and Finished messages to conclude the handshake. If 664 the client has authentication or other AVPs to send to the TTLS 665 server, it must tunnel those AVPs within the same EAP-TTLS packet 666 immediately following its Finished message. If the client fails to 667 do this, the TTLS server will incorrectly assume that the client has 668 no AVPs to send, and the outcome of the negotiation could be 669 affected. 671 6.4 Session Resumption 673 When a client and TTLS server that have previously negotiated a EAP- 674 TTLS session begin a new EAP-TTLS negotiation, the client and TTLS 675 server may agree to resume the previous session. This significantly 676 reduces the time required to establish the new session. This could 677 occur when the client connects to a new access point, or when an 678 access point requires reauthentication of a connected client. 680 Session resumption is accomplished using the standard TLS mechanism. 681 The client signals its desire to resume a session by including the 682 session ID of the session it wishes to resume in the ClientHello 683 message; the TTLS server signals its willingness to resume that 684 session by echoing that session ID in its ServerHello message. 686 If the TTLS server elects not to resume the session, it simply does 687 not echo the session ID and a new session will be negotiated. This 688 could occur if the TTLS server is configured not to resume sessions, 689 if it has not retained the requested session's state, or if the 690 session is considered stale. A TTLS server may consider the session 691 stale based on its own configuration, or based on session-limiting 692 information received from the AAA/H (e.g., the RADIUS Session- 693 Timeout attribute). 695 Tunneled authentication is specifically not performed for resumed 696 sessions; the presumption is that the knowledge of the master secret 697 as evidenced by the ability to resume the session is authentication 698 enough. This allows session resumption to occur without any 699 messaging between the TTLS server and the AAA/H. If periodic 700 reauthentication to the AAA/H is desired, the AAA/H must indicate 701 this to the TTLS server when the original session is established, 702 for example, using the RADIUS Session-Timeout attribute. 704 The client must, however, send other required AVPs, in particular 705 key distribution AVPs, that are not associated with tunneled 706 authentication in its first EAP-TTLS packet to the server that is 707 capable of containing phase 2 TLS messages. The TTLS server does not 708 retain client AVPs or key distribution preferences as part of 709 session state, and the client is expected to resend those AVPs in 710 each negotiation. 712 Thus phase 2 of a resumed session proceeds just as would a new 713 session, minus tunneled authentication AVPs. For example, the client 714 would send its key distribution preferences, and the TTLS server 715 would respond with its key distribution selection. 717 While the TTLS server does not retain client AVPs from session to 718 session, it must retain authorization information returned by the 719 AAA/H for use in resumed sessions. A resumed session must operate 720 under the same authorizations as the original session, and the TTLS 721 server must be prepared to send the appropriate information back to 722 the access point. Authorization information might include the 723 maximum time for the session, the maximum allowed bandwidth, packet 724 filter information and the like. The TTLS server is responsible for 725 modifying time values, such as Session-Timeout, appropriately for 726 each resumed session. 728 A TTLS server must not permit a session to be resumed if that 729 session did not result in a successful authentication of the user 730 during phase 2. The consequence of incorrectly implementing this 731 aspect of session resumption would be catastrophic; any attacker 732 could easily gain network access by first initiating a session that 733 succeeds in the TLS handshake but fails during phase 2 734 authentication, and then resuming that session. 736 [Implementation note: Toolkits that implement TLS often cache 737 resumable TLS sessions automatically. Implementers must take care to 738 override such automatic behavior, and prevent sessions from being 739 cached for possible resumption until the user has been positively 740 authenticated during phase 2.] 742 6.4.1 TTLS Server Guidelines for Session Resumption 744 When a domain comprises multiple TTLS servers, a client's attempt to 745 resume a session may fail because each EAP-TTLS negotiation may be 746 routed to a different TTLS server. 748 One strategy to ensure that subsequent EAP-TTLS negotiations are 749 routed to the original TTLS server is for each TTLS server to encode 750 its own identifying information, for example, IP address, in the 751 session IDs that it generates. This would allow any TTLS server 752 receiving a session resumption request to forward the request to the 753 TTLS server that established the original session. 755 7. Generating Keying Material 757 When record layer security is instantiated at the end of a TLS 758 handshake, a pseudo-random function (PRF) is used to expand the 759 negotiated master secret, server random value and client random 760 value into a sequence of octets that is used as keying material for 761 the record layer. The length of this sequence depends on the 762 negotiated cipher suite, and contains the following components: 764 client_write_MAC_secret 765 server_write_MAC_secret 766 client_write_key 767 server_write_key 768 client_write_IV (optional) 769 server_write_IV (optional) 771 The ASCII-encoded constant string "key expansion" is used as input 772 to the pseudo-random function to generate this sequence. 774 EAP-TTLS leverages this technique to create keying material for use 775 in the data connection between client and access point. Exactly the 776 same PRF is used to generate as much keying material as required, 777 with the constant string set to "ttls keying material", as follows: 779 EAP-TTLS_keying_material = PRF(SecurityParameters.master_secret, 780 "ttls keying material", 781 SecurityParameters.client_random + 782 SecurityParameters.server_random); 784 The master secret, client random and server random used to generate 785 the data connection keying material must be those established during 786 the TLS handshake. Both client and TTLS server generate this keying 787 material, and they are guaranteed to be the same if the handshake 788 succeeded. The TTLS server distributes this keying material to the 789 access point via the AAA carrier protocol. 791 [Note that the order of client_random and server_random for EAP-TTLS 792 is reversed from that of the TLS protocol [3]. This ordering follows 793 the key derivation method of EAP-TLS [1]. Altering the order of 794 randoms avoids namespace collisions between constant strings defined 795 for EAP-TTLS and those defined for the TLS protocol.] 797 8. EAP-TTLS Encoding 799 EAP-TTLS is a protocol within EAP. Its assigned EAP number is 21. 801 Except as described in the subsections below, EAP-TTLS's encoding of 802 TLS messages within EAP is identical to EAP-TLS's encoding of TLS 803 messages within EAP. See [1] for details. 805 8.1 EAP-TTLS Start Packet 807 The EAP-TTLS Start packet (with S-bit set) may, in a future 808 specification, be allowed to contain data (the EAP-TLS Start packet 809 does not). 811 Thus, the data contents of an EAP-TTLS Start packet are reserved for 812 future standardization; in the meantime, servers must not include 813 any data in an EAP-TTLS Start packet, and clients must ignore such 814 data but must not reject a Start packet that contains data. 816 8.2 EAP-TTLS Packets with No Data 818 One point of clarification has to do with an EAP-TTLS packet (other 819 than a Start packet) that contains no data. 821 EAP-TLS defines the use of such a packet as a fragment ACK. When 822 either party must fragment an EAP-TLS packet, the other party 823 responds with a fragment ACK to allow the original party to send the 824 next fragment. 826 EAP-TTLS uses the fragment ACK in the same way. There are also other 827 instances where a EAP-TTLS packet with no data might be sent: 829 - When the final EAP packet of the EAP-TTLS negotiation is sent by 830 the TTLS server, the client must respond with a EAP-TTLS packet 831 with no data, to allow the TTLS server to issue its final EAP- 832 Success or EAP-Failure packet. 834 - It is possible for a EAP-TTLS packet with no data to be sent in 835 the middle of a negotiation. Such a packet is simply interpreted 836 as packet with no AVPs. For example, during session resumption, 837 the client sends its Finished message first, then the TTLS server 838 replies with its Finished message. The TTLS server cannot 839 piggyback key distribution AVPs within the Record Layer in the 840 same EAP-TTLS packet containing its Finished message, because it 841 must wait for the client to indicate its key distribution 842 preferences. But it is possible that the client has no 843 preferences, and thus has no AVPs to send. The client simply 844 sends a EAP-TTLS packet with no data, to allow the server to 845 continue the negotiation by sending its key distribution 846 selection. 848 9. Encapsulation of AVPs within the TLS Record Layer 850 Subsequent to the TLS handshake, information is tunneled between 851 client and TTLS server through the use of attribute-value pairs 852 (AVPs) encrypted within the TLS record layer. 854 The AVP format chosen for EAP-TTLS is compatible with the Diameter 855 AVP format. This does not at all represent a requirement that 856 Diameter be supported by any of the devices or servers participating 857 in a EAP-TTLS negotiation. Use of this format is merely a 858 convenience. Diameter is a superset of RADIUS and includes the 859 RADIUS attribute namespace by definition, though it does not limit 860 the size of an AVP as does RADIUS; RADIUS, in turn, is a widely 861 deployed AAA protocol and attribute definitions exist for all 862 commonly used password authentication protocols, including EAP. 864 Thus, Diameter is not considered normative except as specified in 865 this document. Specifically, the AVP Codes used in EAP-TTLS are 866 semantically equivalent to those defined for Diameter, and, by 867 extension, RADIUS. Also, the representation of the Data field of an 868 AVP in EAP-TTLS is identical to that of Diameter. 870 Use of the RADIUS/Diameter namespace allows a TTLS server to easily 871 translate between AVPs it uses to communicate to clients and the 872 protocol requirements of AAA servers that are widely deployed. Plus, 873 it provides a well-understood mechanism to allow vendors to extend 874 that namespace for their particular requirements. 876 9.1 AVP Format 878 The format of an AVP is shown below. All items are in network, or 879 big-endian, order; that is, they have most significant octet first. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | AVP Code | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 |V M r r r r r r| AVP Length | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Vendor-ID (opt) | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Data ... 891 +-+-+-+-+-+-+-+-+ 893 AVP Code 895 The AVP Code is four octets and, combined with the Vendor-ID 896 field if present, identifies the attribute uniquely. The first 897 256 AVP numbers represent attributes defined in RADIUS. AVP 898 numbers 256 and above are defined in Diameter. 900 AVP Flags 902 The AVP Flags field is one octet, and provides the receiver with 903 information necessary to interpret the AVP. 905 The 'V' (Vendor-Specific) bit indicates whether the optional 906 Vendor-ID field is present. When set to 1, the Vendor-ID field is 907 present and the AVP Code is interpreted according to the 908 namespace defined by the vendor indicated in the Vendor-ID field. 910 The 'M' (Mandatory) bit indicates whether support of the AVP is 911 required. If this bit is set to 0, this indicates that the AVP 912 may be safely ignored if the receiving party does not understand 913 or support it. If set to 1, this indicates that the receiving 914 party must fail the negotiation if it does not understand the 915 AVP; for a TTLS server, this would imply returning EAP-Failure, 916 for a client, this would imply abandoning the negotiation. 918 The 'r' (reserved) bits are unused and must be set to 0. 920 AVP Length 922 The AVP Length field is three octets, and indicates the length of 923 this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID 924 (if present) and Data. 926 Vendor-ID 928 The Vendor-ID field is present if the 'V' bit is set in the AVP 929 Flags field. It is four octets, and contains the vendor's IANA- 930 assigned "SMI Network Management Private Enterprise Codes" [9] 931 value. Vendors defining their own AVPs must maintain a consistent 932 namespace for use of those AVPs within RADIUS, Diameter and EAP- 933 TTLS. 935 A Vendor-ID value of zero is equivalent to absence of the Vendor- 936 ID field altogether. 938 9.2 AVP Sequences 940 Data encapsulated within the TLS Record Layer must consist entirely 941 of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet 942 boundary relative to the first AVP in the sequence. If an AVP is not 943 a multiple of 4 octets, it must be padded with 0s to the next 4- 944 octet boundary. 946 Note that the AVP Length does not include the padding. 948 9.3 Guidelines for Maximum Compatibility with AAA Servers 950 For maximum compatibility, the following guidelines for AVP usage 951 are suggested: 953 - Non-vendor-specific AVPs should be selected from the set of 954 attributes defined for RADIUS; that is, attributes with codes 955 less than 256. This provides compatibility with both RADIUS and 956 Diameter. 958 - Vendor-specific AVPs should be defined in terms of RADIUS. 959 Vendor-specific RADIUS attributes translate to Diameter (and, 960 hence, to EAP-TTLS) automatically; the reverse is not true. 961 RADIUS vendor-specific attributes use RADIUS attribute 26 and 962 include vendor ID, vendor-specific attribute code and length; see 963 [6] for details. 965 10. Tunneled Authentication 967 EAP-TTLS permits user authentication information to be tunneled 968 within the TLS record layer between client and TTLS server, 969 guaranteeing the security of the authentication information against 970 active and passive attack between the client and TTLS server. The 971 TTLS server decrypts and forwards this information to the AAA/H over 972 the AAA carrier protocol. 974 Any type of password or other authentication may be tunneled. Also, 975 multiple tunneled authentications may be performed. Normally, 976 tunneled authentication is used when the client has not been issued 977 a certificate and the TLS handshake provides only one-way 978 authentication of the TTLS server to the client; however, in certain 979 cases it may be desired to perform certificate authentication of the 980 client during the TLS handshake as well as tunneled user 981 authentication afterwards. 983 10.1 Implicit challenge 985 Certain authentication protocols that use a challenge/response 986 mechanism rely on challenge material that is not generated by the 987 authentication server, and therefore require special handling. 989 In CHAP, MS-CHAP and MS-CHAP-V2, for example, the NAS issues a 990 challenge to the client, the client then hashes the challenge with 991 the password and forwards the response to the NAS. The NAS then 992 forwards both challenge and response to a AAA server. But because 993 the AAA server did not itself generate the challenge, such protocols 994 are susceptible to replay attack. 996 If the client were able to create both challenge and response, 997 anyone able to observe a CHAP or MS-CHAP exchange could pose as that 998 user, even using EAP-TTLS. 1000 To make these protocols secure under EAP-TTLS, it is necessary to 1001 provide a mechanism to produce a challenge that the client cannot 1002 control or predict. This is accomplished using the same technique 1003 described above for generating data connection keying material. 1005 When a challenge-based authentication mechanism is used, both client 1006 and TTLS server use the pseudo-random function to generate as many 1007 octets as are required for the challenge, using the constant string 1008 "ttls challenge", based on the master secret and random values 1009 established during the handshake: 1011 EAP-TTLS_challenge = PRF(SecurityParameters.master_secret, 1012 "ttls challenge", 1013 SecurityParameters.client_random + 1014 SecurityParameters.server_random); 1016 10.2 Tunneled Authentication Protocols 1018 This section describes the methods for tunneling specific 1019 authentication protocols within EAP-TTLS. 1021 For the purpose of explication, it is assumed that the TTLS server 1022 and AAA/H use RADIUS as a AAA carrier protocol between them. 1023 However, this is not a requirement, and any AAA protocol capable of 1024 carrying the required information may be used. 1026 10.2.1 EAP 1028 When EAP is the tunneled authentication protocol, each tunneled EAP 1029 packet between the client and TTLS server is encapsulated in an EAP- 1030 Message AVP, prior to tunneling via the TLS record layer. 1032 The client's first tunneled EAP packet within phase 2 will contain 1033 the EAP-Response/Identity. The client places the actual username in 1034 this packet; the privacy of the user's identity is now guaranteed by 1035 the TLS encryption. This username must be a Network Access 1036 Identifier (NAI) [7]; that is, it must be in the following format: 1038 username@realm 1040 The @realm portion is optional, and is used to allow the TTLS server 1041 to forward the EAP packet to the appropriate AAA/H. 1043 Note that the client has two opportunities to specify realms. The 1044 first, in the initial EAP-Response/Identity packet, indicates the 1045 realm of the TTLS server. The second, in the tunneled 1046 authentication, indicates the realm of the client's home network. 1047 Thus, the access point need only know how to route to the realm of 1048 the TTLS server; the TTLS server is assumed to know how to route to 1049 the client's home realm. This serial routing architecture is 1050 anticipated to be useful in roaming environments, allowing access 1051 points or AAA proxies behind access points to be configured only 1052 with a small number of realms. 1054 Upon receipt of the tunneled EAP-Response/Identity, the TTLS server 1055 forwards it to the AAA/H in a RADIUS Access-Request. 1057 The AAA/H may immediately respond with an Access-Reject, in which 1058 case the TTLS server completes the negotiation by sending an EAP- 1059 Failure to the access point. This could occur if the AAA/H does not 1060 recognize the user's identity, or if it does not support EAP. 1062 If the AAA/H does recognize the user's identity and does support 1063 EAP, it responds with an Access-Challenge containing an EAP-Request, 1064 with the Type and Type-Data fields set according to the EAP protocol 1065 with which the AAA/H wishes to authenticate the client; for example 1066 MD-Challenge, OTP or Generic Token Card. 1068 The EAP authentication between client and AAA/H proceeds normally, 1069 as described in [2], with the TTLS server acting as a passthrough 1070 device. Each EAP-Request sent by the AAA/H in an Access-Challenge is 1071 tunneled by the TTLS server to the client, and each EAP-Response 1072 tunneled by the client is decrypted and forwarded by the TTLS server 1073 to the AAA/H in an Access-Request. 1075 This process continues until the AAA/H issues an Access-Accept or 1076 Access-Reject, at which point the TTLS server completes the 1077 negotiation by sending an EAP-Success or EAP-Failure to the access 1078 point using the AAA carrier protocol. 1080 10.2.2 CHAP 1082 The CHAP algorithm is described in [5]; RADIUS attribute formats are 1083 described in [6]. 1085 Both client and TTLS server generate 17 octets of challenge 1086 material, using the constant string "ttls challenge" as described 1087 above. These octets are used as follows: 1089 CHAP-Challenge [16 octets] 1090 CHAP Identifier [1 octet] 1092 The client tunnels User-Name, CHAP-Challenge and CHAP-Password AVPs 1093 to the TTLS server. The CHAP-Challenge value is taken from the 1094 challenge material. The CHAP-Password consists of CHAP Identifier, 1095 taken from the challenge material; and CHAP response, computed 1096 according to the CHAP algorithm. 1098 Upon receipt of these AVPs from the client, the TTLS server must 1099 verify that the value of the CHAP-Challenge AVP and the value of the 1100 CHAP Identifier in the CHAP-Password AVP are equal to the values 1101 generated as challenge material. If either item does not match 1102 exactly, the TTLS server must reject the client. Otherwise, it 1103 forwards the AVPs to the AAA/H in an Access-Request. 1105 The AAA/H will respond with an Access-Accept or Access-Reject. The 1106 TTLS server will then issue an EAP-Success or EAP-Failure to the 1107 access point. 1109 10.2.3 MS-CHAP 1111 The MS-CHAP algorithm is described in [10]; RADIUS attribute formats 1112 are described in [12]. 1114 Both client and TTLS server generate 9 octets of challenge material, 1115 using the constant string "ttls challenge" as described above. These 1116 octets are used as follows: 1118 MS-CHAP-Challenge [8 octets] 1119 Ident [1 octet] 1121 The client tunnels User-Name, MS-CHAP-Challenge and MS-CHAP-Response 1122 AVPs to the TTLS server. The MS-CHAP-Challenge value is taken from 1123 the challenge material. The MS-CHAP-Response consists of Ident, 1124 taken from the challenge material; Flags, set according the client 1125 preferences; and LM-Response and NT-Response, computed according to 1126 the MS-CHAP algorithm. 1128 Upon receipt of these AVPs from the client, the TTLS server must 1129 verify that the value of the MS-CHAP-Challenge AVP and the value of 1130 the Ident in the client's MS-CHAP-Response AVP are equal to the 1131 values generated as challenge material. If either item does not 1132 match exactly, the TTLS server must reject the client. Otherwise, it 1133 forwards the AVPs to the AAA/H in an Access-Request. 1135 The AAA/H will respond with an Access-Accept or Access-Reject. The 1136 TTLS server will then issue an EAP-Success or EAP-Failure to the 1137 access point. 1139 10.2.4 MS-CHAP-V2 1141 The MS-CHAP-V2 algorithm is described in [11]; RADIUS attribute 1142 formats are described in [12]. 1144 Both client and TTLS server generate 17 octets of challenge 1145 material, using the constant string "ttls challenge" as described 1146 above. These octets are used as follows: 1148 MS-CHAP-Challenge [16 octets] 1149 Ident [1 octet] 1151 The client tunnels User-Name, MS-CHAP-Challenge and MS-CHAP2- 1152 Response AVPs to the TTLS server. The MS-CHAP-Challenge value is 1153 taken from the challenge material. The MS-CHAP2-Response consists of 1154 Ident, taken from the challenge material; Flags, set to 0; Peer- 1155 Challenge, set to a random value; and Response, computed according 1156 to the MS-CHAP-V2 algorithm. 1158 Upon receipt of these AVPs from the client, the TTLS server must 1159 verify that the value of the MS-CHAP-Challenge AVP and the value of 1160 the Ident in the client's MS-CHAP2-Response AVP are equal to the 1161 values generated as challenge material. If either item does not 1162 match exactly, the TTLS server must reject the client. Otherwise, it 1163 forwards the AVPs to the AAA/H in an Access-Request. 1165 If the authentication is successful, the AAA/H will respond with an 1166 Access-Accept containing the MS-CHAP2-Success attribute. This 1167 attribute contains a 42-octet string that authenticates the AAA/H to 1168 the client based on the Peer-Challenge. The TTLS server tunnels this 1169 AVP to the client. Note that the authentication is not yet complete; 1170 the client must still accept the authentication response of the 1171 AAA/H. 1173 Upon receipt of the MS-CHAP2-Success AVP, the client is able to 1174 authenticate the AAA/H. If the authentication succeeds, the client 1175 sends an EAP-TTLS packet to the TTLS server containing no data. Upon 1176 receipt of the empty EAP-TTLS packet from the client, the TTLS 1177 server now issues an EAP-Success. 1179 If the authentication fails, the AAA/H will respond with an Access- 1180 Challenge containing the MS-CHAP2-Error attribute. This attribute 1181 contains a new Ident and a string with addition information such as 1182 error reason and whether a retry is allowed. If the error reason is 1183 an expired password and a retry is allowed, the client may proceed 1184 to change the user's password. If the error reason is not an expired 1185 password or if the client does not wish to change the user's 1186 password, it simply abandons the EAP-TTLS negotiation. 1188 If the client does wish to change the password, it tunnels MS-CHAP- 1189 NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS 1190 server. The MS-CHAP2-CPW AVP is derived from from the new Ident and 1191 Challenge received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge 1192 AVP simply echoes the new Challenge. 1194 Upon receipt of these AVPs from the client, the TTLS server must 1195 verify that the value of the MS-CHAP-Challenge AVP and the value of 1196 the Ident in the client's MS-CHAP2-CPW AVP match the values it sent 1197 in the MS-CHAP2-Error AVP. If either item does not match exactly, 1198 the TTLS server must reject the client. Otherwise, it forwards the 1199 AVPs to the AAA/H in an Access-Request. 1201 If the authentication is successful, the AAA/H will respond with an 1202 Access-Accept containing the MS-CHAP2-Success attribute. At this 1203 point, the negotiation proceeds as described above; the TTLS server 1204 tunnels the MS-CHAP2-Success to the client, the client authenticates 1205 the AAA/H based on this AVP, it either abandons the negotation on 1206 failure or sends an EAP-TTLS packet to the TTLS server containing no 1207 data, the TTLS server issues an EAP-Success. 1209 Note that additional AVPs associated with MS-CHAP-V2 may be sent by 1210 the AAA/H; for example, MS-CHAP-Domain. The TTLS server must tunnel 1211 such authentication-related attributes along with the MS-CHAP2- 1212 Success. 1214 10.2.5 PAP 1216 The client tunnels User-Name and User-Password AVPs to the TTLS 1217 server. 1219 Normally, in RADIUS, User-Password is padded with nulls to a 1220 multiple of 16 octets, then encrypted using a shared secret and 1221 other packet information. 1223 An EAP-TTLS client, however, does not RADIUS-encrypt the password 1224 since no such RADIUS variables are available; this is not a security 1225 weakness since the password will be encrypted via TLS anyway. The 1226 client should, however, null-pad the password to a multiple of 16 1227 octets, to obfuscate its length. 1229 Upon receipt of these AVPs from the client, the TTLS server forwards 1230 them to the AAA/H in a RADIUS Access-Request. (Note that in the 1231 Access-Request, the TTLS server must encrypt the User-Password 1232 attribute using the shared secret between the TTLS server and 1233 AAA/H.) 1235 The AAA/H may immediately respond with an Access-Accept or Access- 1236 Reject. The TTLS server then completes the negotiation by sending an 1237 EAP-Success or EAP-Failure to the access point using the AAA carrier 1238 protocol. 1240 The AAA/H may also respond with an Access-Challenge. The TTLS server 1241 then tunnels the AVPs from the AAA/H's challenge to the client. Upon 1242 receipt of these AVPs, the client tunnels User-Name and User- 1243 Password again, with User-Password containing new information in 1244 response to the challenge. This process continues until the AAA/H 1245 issues an Access-Accept or Access-Reject. 1247 At least one of the AVPs tunneled to the client upon challenge must 1248 be Reply-Message. Normally this is sent by the AAA/H as part of the 1249 challenge. However, if the AAA/H has not sent a Reply-Message, the 1250 TTLS server must issue one, with null value. This allows the client 1251 to determine that a challenge response is required. 1253 Note that if the AAA/H includes a Reply-Message as part of an 1254 Access-Accept or Access-Reject, the TTLS server does not tunnel this 1255 AVP to the client. Rather, this AVP and all other AVPs sent by the 1256 AAA/H as part of Access-Accept or Access-Reject are sent to the 1257 access point via the AAA carrier protocol. 1259 10.3 Performing Multiple Authentications 1261 In some cases, it is desirable to perform multiple user 1262 authentications. For example, a AAA/H may want first to authenticate 1263 the user by password, then by token card. 1265 The AAA/H may perform any number of additional user authentications 1266 using EAP, simply by issuing a EAP-Request with a new protocol type 1267 once the previous authentication succeeded but prior to issuing an 1268 EAP-Success or accepting the user via the AAA carrier protocol. 1270 For example, an AAA/H wishing to perform MD5-Challenge followed by 1271 Generic Token Card would first issue an EAP-Request/MD5-Challenge 1272 and receive a response. If the response is satisfactory, it would 1273 then issue EAP-Request/Generic Token Card and receive a response. If 1274 that response were also satisfactory, it would issue EAP-Success. 1276 11. Key Distribution 1278 Clients and access points will have their own requirements for the 1279 distribution of keying material and algorithms. EAP-TTLS is flexible 1280 enough to accommodate a variety of requirements. Because all keying 1281 information is distributed via AVPs, implementations may define 1282 their own AVPs through IANA registration or the vendor extension 1283 mechanism to provide information in whatever form is required. 1285 However, EAP-TTLS does suggest a model for exchange of keying 1286 information. Following the TLS example, keying information comprises 1287 two elements: the data cipher suite and the keying material. 1289 - The data cipher suite is a value which indicates the length and 1290 interpretation of the keying material, and the cryptographic 1291 algorithm used for data encryption and validation. 1293 - The keying material is a sequence of octets whose length and 1294 interpretation are governed by the data cipher suite. 1296 The data cipher suite is so named to avoid confusion with TLS cipher 1297 suites. The namespace of the data cipher suite is distinct from the 1298 namespace of cipher suites used in TLS. Note that, unlike TLS cipher 1299 suites, it is typically used for data transformation only and need 1300 not specify a key exchange algorithm. 1302 Note that the keying material may contain multiple keys, whose use 1303 is specified by the data cipher suite. 1305 Both client and access point communicate their data cipher suite 1306 preferences to the TTLS server, the TTLS server selects a cipher 1307 suite supported by both and communicates its selection to both 1308 parties. The TTLS server communicates the keying material to the 1309 access point only; the client derives the keying material 1310 implicitly. 1312 Key distribution information is communicated between access point 1313 and TTLS server over the AAA protocol. The access point communicates 1314 its data cipher suite preferences with the initial EAP-TTLS request; 1315 the TTLS server communicates the selected data cipher suite and 1316 keying material with the final EAP-TTLS success response (i.e., with 1317 the EAP-Success). 1319 Key distribution information is communicated between client and TTLS 1320 server within tunneled AVPs during phase 2. The client must 1321 communicate its data cipher suite preferences at the outset of phase 1322 2; that is, in the first EAP-Response/TTLS packet that can contain 1323 phase 2 TLS messages, possibly piggybacked with phase 1 TLS 1324 messages. Note that user authentication AVPs may also appear in this 1325 packet. 1327 The TTLS server communicates the selected data cipher suite in the 1328 subsequent phase 2 EAP-Request/TTLS packet to the client. 1330 Note that the client has exactly one opportunity to indicate its 1331 cipher suite preferences. If the client misses that opportunity, the 1332 TTLS server could specify a data cipher without taking client 1333 preferences into account. 1335 11.1 AVPs for Key Distribution 1337 The AVPs that follow should be understood as placeholders for AVPs 1338 that an organization might want to define for its own special 1339 requirements. The name of each AVP is prefixed with "XXX"; an 1340 organization adopting this model would replace the "XXX" with its 1341 own identifying text. 1343 11.1.1 XXX-Data-Cipher-Suite 1345 The XXX-Data-Cipher-Suite AVP contains the ID of a data cipher suite 1346 for use in the data connection, followed by the length, in octets, 1347 of the keying material required for this data cipher suite. Data 1348 cipher suite ID and keying material length are each four octets, 1349 with most significant octet first. 1351 Each data cipher suite ID must correspond to a pre-defined value. 1352 For example, a set of values might include the following: 1354 1 WEP 1355 2 WEP2 1356 3 AES-OCB 1358 One or more instances of this AVP may be sent by either the client 1359 or access point to the TTLS server to indicate its data cipher suite 1360 preferences. If multiple instances appear, they are ordered from 1361 most preferred to least preferred. 1363 A single instance of this AVP may be sent by the TTLS server to the 1364 client or access point to indicate its selection of data cipher 1365 suite and keying material length. 1367 The TTLS server will have two lists of data cipher suite 1368 preferences, one from the client and one from the access point. In 1369 general, it should give the client's list priority; that is, it 1370 should select the first data cipher suite from the client's list 1371 that also appears in the access point's list. Alternatively, the 1372 TTLS server may have its own policy that governs how it selects a 1373 data cipher suite from the intersection of the two lists. 1375 The TTLS server should return its selection of data cipher suite to 1376 client and access point only if both client and access point have 1377 indicated their preferences by sending one or more instances of this 1378 AVP. If either client or access point does not send this AVP, the 1379 TTLS server must assume that the AVP is not supported by that entity 1380 and that other (e.g. link layer) means of negotiating cipher suite 1381 will occur. 1383 The purpose of including the keying material length in this AVP is 1384 to allow the TTLS server to be ignorant of the meanings of the 1385 various data cipher suite IDs. Thus, the TTLS server simply collates 1386 client and access point preferences to return a selected data cipher 1387 suite and length, and returns keying material of the indicated 1388 length. Additionally, it allows data cipher suites to be defined 1389 with variable length keying material. 1391 11.1.2 XXX-Data-Keying-Material 1393 The XXX-Data-Keying-Material AVP contains the keying material to be 1394 used with the selected data cipher suite in the data connection. It 1395 must contain at least as many octets as needed to satisfy the 1396 requirements of the selected cipher suite. 1398 Both client and TTLS server use the pseudo-random function to 1399 generate as many octets as are required as keying material, using 1400 the constant string "ttls keying material", based on the master 1401 secret and random values established during the handshake: 1403 EAP-TTLS_keying_material = PRF(SecurityParameters.master_secret, 1404 "ttls keying material", 1405 SecurityParameters.client_random + 1406 SecurityParameters.server_random); 1408 This AVP may be sent by the TTLS server to the access point. It is 1409 not sent to the client; the client generates this keying material 1410 implicitly. 1412 The value of this AVP must be encrypted using techniques available 1413 within the AAA protocol. In RADIUS, for example, the value should be 1414 encrypted using salt-encryption as is used for Tunnel-Password. 1416 The TTLS server determines the length of keying material required 1417 for the selected data cipher suite from the corresponding XXX-Data- 1418 Cipher-Suite AVP sent by client or access point. If client and 1419 access point specify a different keying material length for the same 1420 data cipher suite ID, the higher length is chosen. 1422 12. Discussion of Certificates and PKI 1424 Public-key cryptography, certificates, and the associated PKI are 1425 used in EAP-TTLS to authenticate the EAP-TTLS server to the client, 1426 and optionally the client to the EAP-TTLS server. Previous 1427 experience with the deployment of PKI in applications has shown that 1428 its implementation requires care. This section provides a brief 1429 discussion of the issues implementers will face when deploying PKI 1430 for EAP-TTLS. 1432 The traditional use of TLS for securing e-commerce transactions over 1433 the Internet is perhaps the best-known deployment of PKI, and it 1434 serves to illustrate several of the issues relevant here. In the 1435 case of e-commerce: 1437 - The environment is many-to-many - many consumers do business with 1438 many merchants. Typically there is no relationship in advance 1439 between a consumer and a merchant. 1441 - Users are "notoriously bad" about following security guidelines. 1442 When presented with a dialogue saying "the name in the 1443 certificate is different from the name you requested", most users 1444 will simply continue with the transaction. 1446 - Support for revocation is limited. It is important to understand 1447 that the environments in which EAP-TTLS are likely to be deployed 1448 will typically be very different from e-commerce. 1450 In particular, many deployments will be comparable to deploying 1451 wireless LAN within an enterprise. In this case, the communications 1452 topology is essentially many-to-one or many-to-few - many employees 1453 talking to a few EAP-TTLS servers - and all clients are essentially 1454 governed by their employer rather than autonomous. 1456 This means: 1458 - It may be unnecessary to rely on a public CA. Instead the 1459 enterprise could choose to run its own CA (either insourced or 1460 outsourced). 1462 - The enterprise could choose to enforce stringent policies on 1463 certificate validation and processing - for example simply 1464 insisting connections are dropped if the correct name does not 1465 appear in the server certificate. Such policies could be enforced 1466 via extensions in the root certificate of the enterprise CA. 1468 However it also means: 1470 - EAP-TTLS servers may receive considerably less attention than the 1471 web servers of large e-commerce sites. As a result, compromise of 1472 EAP-TTLS servers may be more common, and therefore deployment and 1473 use of revocation solutions may be more relevant. 1475 One open question in the area of PKI on which the authors would like 1476 to promote discussion is the following: 1478 - Should EAP-TTLS enforce rules on name matching regarding the EAP- 1479 TTLS server? For example, EAP-TTLS could mandate that 1480 radius.xyz.realm or diameter.xyz.realm be used as the name in the 1481 EAP-TTLS server's certificate, and that the client must match 1482 this name with the realm it sent in the initial EAP- 1483 Response/Identity. 1485 13. Message Sequences 1487 This section presents EAP-TTLS message sequences for various 1488 negotiation scenarios. These examples do not attempt to exhaustively 1489 depict all possible scenarios. 1491 It is assumed that RADIUS is the AAA carrier protocol both between 1492 access point and TTLS server, and between TTLS server and AAA/H. 1494 EAP packets that are passed unmodified between client and TTLS 1495 server by the access point are indicated as "passthrough". AVPs that 1496 are securely tunneled within the TLS record layer are enclosed in 1497 curly braces ({}). Items that are optional are suffixed with 1498 question mark (?). Items that may appear multiple times are suffixed 1499 with plus sign (+). 1501 13.1 Successful authentication via tunneled CHAP 1503 In this example, the client performs one-way TLS authentication of 1504 the TTLS server, CHAP is used as a tunneled user authentication 1505 mechanism, and the TTLS server returns cipher suite and keying 1506 material. 1508 client access point TTLS server AAA/H 1509 ------ ------------ ----------- ----- 1511 EAP-Request/Identity 1512 <-------------------- 1513 EAP-Response/Identity 1514 --------------------> 1516 RADIUS Access-Request: 1517 XXX-Data-Cipher-Suite+ 1518 EAP-Response passthrough 1519 --------------------> 1521 RADIUS Access-Challenge: 1522 EAP-Request/TTLS-Start 1523 <-------------------- 1525 EAP-Request passthrough 1526 <-------------------- 1528 EAP-Response/TTLS: 1529 ClientHello 1530 --------------------> 1532 RADIUS Access-Request: 1533 EAP-Response passthrough 1534 --------------------> 1536 RADIUS Access-Challenge: 1537 EAP-Request/TTLS: 1538 ServerHello 1539 Certificate 1540 ServerKeyExchange 1541 ServerHelloDone 1542 <-------------------- 1544 EAP-Request passthrough 1545 <-------------------- 1547 EAP-Response/TTLS: 1548 ClientKeyExchange 1549 ChangeCipherSpec 1550 Finished 1551 --------------------> 1553 RADIUS Access-Request: 1554 EAP-Response passthrough 1555 --------------------> 1557 RADIUS Access-Challenge: 1558 EAP-Request/TTLS: 1559 ChangeCipherSpec 1560 Finished 1561 <-------------------- 1563 EAP-Request passthrough 1564 <-------------------- 1566 EAP-Response/TTLS: 1567 {User-Name} 1568 {CHAP-Challenge} 1569 {CHAP-Password} 1570 {XXX-Data-Cipher-Suite+} 1571 --------------------> 1573 RADIUS Access-Request: 1574 EAP-Response passthrough 1575 --------------------> 1577 RADIUS Access-Request: 1578 User-Name 1579 CHAP-Challenge 1580 CHAP-Password 1581 --------------------> 1583 RADIUS Access-Accept 1584 <-------------------- 1586 RADIUS Access-Challenge: 1587 EAP-Request/TTLS: 1588 {XXX-Data-Cipher-Suite} 1589 <-------------------- 1591 EAP-Request passthrough 1592 <-------------------- 1594 EAP-Response/TTLS: no data 1595 --------------------> 1597 RADIUS Access-Request: 1598 EAP-Response passthrough 1599 --------------------> 1601 RADIUS Access-Accept: 1602 XXX-Data-Cipher-Suite 1603 XXX-Data-Keying-Material 1604 EAP-Success 1605 <-------------------- 1607 EAP-Success passthrough 1608 <-------------------- 1610 13.2 Successful authentication via tunneled EAP/MD5-Challenge 1612 In this example, the client performs one-way TLS authentication of 1613 the TTLS server, EAP/MD5-Challenge is used as a tunneled user 1614 authentication mechanism, and the TTLS server returns cipher suite 1615 and keying material. 1617 client access point TTLS server AAA/H 1618 ------ ------------ ----------- ----- 1620 EAP-Request/Identity 1621 <-------------------- 1623 EAP-Response/Identity 1624 --------------------> 1626 RADIUS Access-Request: 1627 XXX-Data-Cipher-Suite+ 1628 EAP-Response passthrough 1629 --------------------> 1631 RADIUS Access-Challenge: 1632 EAP-Request/TTLS-Start 1633 <-------------------- 1635 EAP-Request passthrough 1636 <-------------------- 1638 EAP-Response/TTLS: 1639 ClientHello 1640 --------------------> 1642 RADIUS Access-Request: 1643 EAP-Response passthrough 1644 --------------------> 1646 RADIUS Access-Challenge: 1647 EAP-Request/TTLS: 1648 ServerHello 1649 Certificate 1650 ServerKeyExchange 1651 ServerHelloDone 1652 <-------------------- 1654 EAP-Request passthrough 1655 <-------------------- 1657 EAP-Response/TTLS: 1658 ClientKeyExchange 1659 ChangeCipherSpec 1660 Finished 1661 --------------------> 1662 RADIUS Access-Request: 1663 EAP-Response passthrough 1664 --------------------> 1666 RADIUS Access-Challenge: 1667 EAP-Request/TTLS: 1668 ChangeCipherSpec 1669 Finished 1670 <-------------------- 1672 EAP-Request passthrough 1673 <-------------------- 1675 EAP-Response/TTLS: 1676 {EAP-Response/Identity} 1677 {XXX-Data-Cipher-Suite+} 1678 --------------------> 1680 RADIUS Access-Request: 1681 EAP-Response passthrough 1682 --------------------> 1684 RADIUS Access-Request: 1685 EAP-Response/Identity 1686 --------------------> 1688 RADIUS Access-Challenge 1689 EAP-Request/ 1690 MD5-Challenge 1691 --------------------> 1693 RADIUS Access-Challenge: 1694 EAP-Request/TTLS: 1695 {EAP-Request/MD5-Challenge} 1696 {XXX-Data-Cipher-Suite} 1697 <-------------------- 1699 EAP-Request passthrough 1700 <-------------------- 1702 EAP-Response/TTLS: 1703 {EAP-Response/MD5-Challenge} 1704 --------------------> 1706 RADIUS Access-Request: 1707 EAP-Response passthrough 1708 --------------------> 1709 RADIUS Access-Challenge 1710 EAP-Response/ 1711 MD5-Challenge 1712 --------------------> 1714 RADIUS Access-Accept 1715 <-------------------- 1717 RADIUS Access-Accept: 1718 XXX-Data-Cipher-Suite 1719 XXX-Data-Keying-Material 1720 EAP-Success 1721 <-------------------- 1723 EAP-Success passthrough 1724 <-------------------- 1726 13.3 Successful session resumption 1728 In this example, the client and server resume a previous TLS 1729 session, and the TTLS server returns cipher suite and keying 1730 material. The ID of the session to be resumed is sent as part of the 1731 ClientHello, and the server agrees to resume this session by sending 1732 the same session ID as part of ServerHello. 1734 Note the piggybacking of tunneled XXX-Data-Cipher-Suite AVPs in the 1735 same EAP packet as handshake messages. 1737 client access point TTLS server AAA/H 1738 ------ ------------ ----------- ----- 1740 EAP-Request/Identity 1741 <-------------------- 1743 EAP-Response/Identity 1744 --------------------> 1746 RADIUS Access-Request: 1747 XXX-Data-Cipher-Suite+ 1748 EAP-Response passthrough 1749 --------------------> 1751 RADIUS Access-Challenge: 1752 EAP-Request/TTLS-Start 1753 <-------------------- 1755 EAP-Request passthrough 1756 <-------------------- 1757 EAP-Response/TTLS: 1758 ClientHello 1759 --------------------> 1761 RADIUS Access-Request: 1762 EAP-Response passthrough 1763 --------------------> 1765 RADIUS Access-Challenge: 1766 EAP-Request/TTLS: 1767 ServerHello 1768 ChangeCipherSpec 1769 Finished 1770 <-------------------- 1772 EAP-Request passthrough 1773 <-------------------- 1775 EAP-Response/TTLS: 1776 ChangeCipherSpec 1777 Finished 1778 {XXX-Data-Cipher-Suite+} 1779 --------------------> 1781 RADIUS Access-Request: 1782 EAP-Response passthrough 1783 --------------------> 1785 RADIUS Access-Challenge: 1786 EAP-Request/TTLS: 1787 {XXX-Data-Cipher-Suite} 1788 <-------------------- 1790 EAP-Request passthrough 1791 <-------------------- 1793 EAP-Response/TTLS: no data 1794 --------------------> 1796 RADIUS Access-Request: 1797 EAP-Response passthrough 1798 --------------------> 1800 RADIUS Access-Accept: 1801 XXX-Data-Cipher-Suite 1802 XXX-Data-Keying-Material 1803 EAP-Success 1804 <-------------------- 1806 EAP-Success passthrough 1807 <-------------------- 1809 14. Security Considerations 1811 This draft is entirely about security and the security 1812 considerations associated with the mechanisms employed in this 1813 document should be considered by implementers. 1815 The following additional issues are relevant: 1817 - Anonymity and privacy. Unlike other EAP methods, EAP-TTLS does 1818 not communicate a username in the clear in the initial EAP- 1819 Response/Identity. This feature is designed to support anonymity 1820 and location privacy from attackers eavesdropping the network 1821 path between the client and the TTLS server. However implementers 1822 should be aware that other factors - both within EAP-TTLS and 1823 elsewhere - may compromise a user's identity. For example, if a 1824 user authenticates with a certificate during phase 1 of EAP-TTLS, 1825 the subject name in the certificate may reveal the user's 1826 identity. Outside of EAP-TTLS, the client's fixed MAC address, or 1827 in the case of wireless connections, the client's radio 1828 signature, may also reveal information. Additionally, 1829 implementers should be aware that a user's identity is not hidden 1830 from the EAP-TTLS server and may be included in the clear in AAA 1831 messages between the access point, the EAP-TTLS server, and the 1832 AAA/H server. 1834 - Trust in the EAP-TTLS server. EAP-TTLS is designed to allow the 1835 use of legacy authentication methods to be extended to mediums 1836 like wireless in which eavesdropping the link between the client 1837 and the access point is easy. However implementers should be 1838 aware of the possibility of attacks by rogue EAP-TTLS servers - 1839 for example in the event that the phase 2 authentication method 1840 within EAP-TTLS is susceptible to dictionary attacks. These 1841 threats can be mitigated through the use of authentication 1842 methods like one-time passwords which are not susceptible to 1843 dictionary attacks, or by ensuring that clients connect only to 1844 trusted EAP-TTLS servers. 1846 - EAP-TTLS server certificate compromise. The use of EAP-TTLS 1847 server certificates within EAP-TTLS makes EAP-TTLS susceptible to 1848 attack in the event that an EAP-TTLS server's certificate is 1849 compromised. EAP-TTLS servers should therefore take care to 1850 protect their private key. In addition, certificate revocation 1851 methods may be used to mitigate against the possibility of key 1852 compromise. [13] describes a way to integrate one such method - 1853 OCSP [14] - into the TLS handshake - use of this approach may be 1854 appropriate within EAP-TTLS. 1856 - Negotiation of link encryption. EAP-TTLS includes a method to 1857 negotiate data cipher suites. It also allows data cipher suites 1858 to be negotiated by other means - for example by having client 1859 and access point exchange their preferences using the link layer 1860 protocol. However the use of the EAP-TTLS negotiation is strongly 1861 recommended because it provides a secured negotiation. In 1862 contrast, simple unsecured preference exchange over the link 1863 layer is susceptible to a man-in-the-middle attack that forces 1864 the parties to use the weakest, rather than the strongest, 1865 mutually acceptable data cipher suite. The potential of this 1866 problem is well-illustrated by wireless LAN where for 1867 interoperability purposes many entities will have to continue to 1868 support WEP encryption for some time. In the event that the data 1869 link protocol already includes a negotiation exchange, it is 1870 recommended that the EAP-TTLS exchange still be used, with the 1871 link layer exchange simply confirming the data cipher suite 1872 selected using EAP-TTLS. 1874 - Listing of data cipher preferences. EAP-TTLS negotiates data 1875 cipher suites by having the EAP-TTLS server select the first 1876 cipher suite appearing on the client list that also appears on 1877 the access point list. In order to maximize security, it is 1878 therefore recommended that the client order its list according to 1879 security - most secure acceptable cipher suite first, least 1880 secure acceptable cipher suite last. 1882 - Forward secrecy. With forward secrecy, revelation of a secret 1883 does not compromise session keys previously negotiated based on 1884 that secret. Thus, when the TLS key exchange algorithm provides 1885 forward secrecy, if a TTLS server certificate's private key is 1886 eventually stolen or cracked, tunneled user password information 1887 will remain secure as long as that certificate is no longer in 1888 use. Diffie-Hellman key exchange is an example of an algorithm 1889 that provides forward secrecy. A forward secrecy algorithm should 1890 be considered if attacks against recorded authentication or data 1891 sessions are considered to pose a significant threat. 1893 15. Changes since previous drafts 1895 Other than minor editorial changes, the following changes have been 1896 made to this draft: 1898 Since version 02: 1900 - Added password change for MS-CHAP-V2. 1902 Since version 01: 1904 - In section 11, the TTLS server's response with data cipher suites 1905 has been made conditional on receiving data cipher suite 1906 preferences from both client and access point. Also, implicit 1907 acceptance of the client's preferred data cipher suite has been 1908 eliminated in favor of explicitly returning the data cipher suite 1909 selection. 1911 Since version 00: 1913 - A Table of Contents has been added. 1915 - In section 3, a definition of "access domain" has been added. 1917 - In section 6.4, the requirement has been added that TLS session 1918 resumption must not be allowed for any negotiation that succeeds 1919 in phase 1 TLS handshake but does not successfully complete phase 1920 2 authentication. 1922 - In sections 7 and 10.1, reversed the order of randoms used in 1923 PRF, to follow EAP-TLS practice and avoid namespace collisions 1924 with TLS. 1926 - In section 8, specified the assigned EAP-TTLS number. 1928 - Added section 8.1, reserving for future standardization the 1929 ability to add data to an EAP-TTLS Start packet. 1931 16. References 1933 [1] Aboba, B., and D. Simon, "PPP EAP TLS Authentication 1934 Protocol", RFC 2716, October 1999. 1936 [2] Blunk, L., and J. Vollbrecht, "PPP Extensible Authentication 1937 Protocol (EAP)", RFC 2284, March 1998. 1939 [3] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0", RFC 1940 2246, November 1998. 1942 [4] Institute for Electrical and Electronics Engineers, "IEEE 1943 802.1X, Standard for Port Based Network Access Control", 2001. 1945 [5] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 1946 51, RFC 1661, July 1994. 1948 [6] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 1949 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1950 2000. 1952 [7] Aboba, B., and M. Beadles, "The Network Access Identifier", 1953 RFC 2486, January 1999. 1955 [8] Calhoun, P., et al.. "Diameter Base Protocol", AAA Working 1956 Group Internet-Draft, draft-ietf-aaa-diameter-07.txt, July 1957 2001 1959 [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 1960 October 1994. 1962 [10] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 1963 2433, October 1998. 1965 [11] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 1966 2759, January 2000. 1968 [12] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 1969 2548, March 1999. 1971 [13] Blake-Wilson, S., Hopwood, D., Mikkelson, J., Nystrom, M., and 1972 T. Wright, "TLS Extensions", TLS Working Group Internet-Draft, 1973 draft-ietf-tls-extensions-00.txt, June 2001. 1975 [14] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1976 Adams, "Internet X.509 Public Key Infrastructure: Online 1977 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1979 17. Authors' Addresses 1981 Questions about this memo can be directed to: 1983 Paul Funk 1984 Funk Software, Inc. 1985 222 Third Street 1986 Cambridge, MA 02142 1987 USA 1989 Phone: +1 617 497-6339 1990 E-mail: paul@funk.com 1992 Simon Blake-Wilson 1993 Basic Commerce & Industries, Inc. 1994 304 Harper Drive, Suite 203 1995 Moorestown, NJ 08057 1997 Phone: +1 856 778-1660 1998 E-mail: sblakewilson@bcisse.com 2000 18. Full Copyright Statement 2002 Copyright (C) The Internet Society (2001). All Rights Reserved. 2004 This document and translations of it may be copied and furnished to 2005 others, and derivative works that comment on or otherwise explain it 2006 or assist in its implementation may be prepared, copied, published 2007 and distributed, in whole or in part, without restriction of any 2008 kind, provided that the above copyright notice and this paragraph 2009 are included on all such copies and derivative works. However, this 2010 document itself may not be modified in any way, such as by removing 2011 the copyright notice or references to the Internet Society or other 2012 Internet organizations, except as needed for the purpose of 2013 developing Internet standards in which case the procedures for 2014 copyrights defined in the Internet Standards process must be 2015 followed, or as required to translate it into languages other than 2016 English. 2018 The limited permissions granted above are perpetual and will not be 2019 revoked by the Internet Society or its successors or assigns. 2021 This document and the information contained herein is provided on an 2022 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2023 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2024 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2025 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2026 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.