idnits 2.17.1 draft-funk-eap-ttls-v0-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2353. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5216]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2008) is 5817 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul Funk 3 Internet-Draft Unaffiliated 4 Intended status: Informational Simon Blake-Wilson 5 SafeNet 6 Expires: October 2008 April 2008 8 EAP Tunneled TLS Authentication Protocol Version 0 9 (EAP-TTLSv0) 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). All Rights Reserved. 38 Abstract 40 EAP-TTLS is an EAP method that provides additional functionality 41 beyond what is available in EAP-TLS [RFC5216]. In EAP-TLS, a TLS 42 handshake is used to mutually authenticate a client and server. EAP- 43 TTLS extends this authentication negotiation by using the secure 44 connection established by the TLS handshake to exchange additional 45 information between client and server. In EAP-TTLS, the TLS 46 handshake may be mutual; or it may be one-way, in which only the 47 server is authenticated to the client. The secure connection 48 established by the handshake may then be used to allow the server to 49 authenticate the client using existing, widely-deployed 50 authentication mechanisms. The authentication of the client may 51 itself be EAP, or it may be another authentication protocol such as 52 PAP, CHAP, MS-CHAP or MS-CHAP-V2. 54 Thus, EAP-TTLS allows legacy password-based authentication protocols 55 to be used against existing authentication databases, while 56 protecting the security of these legacy protocols against 57 eavesdropping, man-in-the-middle and other attacks. 59 EAP-TTLS also allows client and server to establish keying material 60 for use in the data connection between the client and access point. 61 The keying material is established implicitly between client and 62 server based on the TLS handshake. 64 This document describes EAP-TTLSv0; that is, the original version 0 65 of the EAP-TTLS protocol, which has been widely deployed. 67 Table of Contents 69 1. Introduction .....................................................4 70 2. Motivation .......................................................5 71 3. Requirements Language ............................................6 72 4. Terminology ......................................................6 73 5. Architectural Model ..............................................9 74 5.1 Carrier Protocols .............................................9 75 5.2 Security Relationships .......................................10 76 5.3 Messaging ....................................................10 77 5.4 Resulting Security ...........................................11 78 6. Protocol Layering Model .........................................11 79 7. EAP-TTLS Overview ...............................................12 80 7.1 Phase 1: Handshake ...........................................13 81 7.2 Phase 2: Tunnel ..............................................13 82 7.3 EAP Identity Information .....................................14 83 7.4 Piggybacking .................................................15 84 7.5 Session Resumption ...........................................15 85 7.6 Determining Whether to Enter Phase 2 .........................16 86 7.7 TLS Version ..................................................17 87 7.8 Use of TLS PRF ...............................................17 88 8. Generating Keying Material ......................................18 89 9. EAP-TTLS Protocol ...............................................19 90 9.1 Packet Format ................................................19 91 9.2 EAP-TTLS Start Packet ........................................20 92 9.2.1 Version Negotiation ......................................20 93 9.2.2 Fragmentation ............................................21 94 9.2.3 Acknowledgement Packets ..................................21 95 10. Encapsulation of AVPs within the TLS Record Layer ...............21 96 10.1 AVP Format ...................................................22 97 10.2 AVP Sequences ................................................24 98 10.3 Guidelines for Maximum Compatibility with AAA Servers ........24 99 11. Tunneled Authentication .........................................24 100 11.1 Implicit challenge ...........................................24 101 11.2 Tunneled Authentication Protocols ............................25 102 11.2.1 EAP ......................................................26 103 11.2.2 CHAP .....................................................27 104 11.2.3 MS-CHAP ..................................................28 105 11.2.4 MS-CHAP-V2 ...............................................29 106 11.2.5 PAP ......................................................30 107 11.3 Performing Multiple Authentications ..........................31 108 11.4 Mandatory Tunneled Authentication Support ....................32 109 11.5 Additional Suggested Tunneled Authentication Support .........32 110 12. Keying Framework ................................................33 111 12.1 Session-Id ...................................................33 112 12.2 Peer-Id ......................................................33 113 12.3 Server-Id ....................................................33 114 13. AVP Summary .....................................................33 115 14. Security Considerations .........................................34 116 14.1 Security Claims ..............................................34 117 14.1.1 Authentication mechanism .................................34 118 14.1.2 Ciphersuite negotiation ..................................35 119 14.1.3 Mutual authentication ....................................35 120 14.1.4 Integrity protection .....................................35 121 14.1.5 Replay protection ........................................35 122 14.1.6 Confidentiality ..........................................35 123 14.1.7 Key derivation ...........................................35 124 14.1.8 Key strength .............................................35 125 14.1.9 Dictionary attack protection .............................35 126 14.1.10 Fast reconnect ...........................................35 127 14.1.11 Cryptographic binding ....................................36 128 14.1.12 Session independence .....................................36 129 14.1.13 Fragmentation ............................................36 130 14.1.14 Channel binding ..........................................36 131 14.2 Client Anonymity .............................................36 132 14.3 Server Trust .................................................37 133 14.4 Certificate Validation .......................................37 134 14.5 Certificate Compromise .......................................37 135 14.6 Forward secrecy. .............................................38 136 14.7 Negotiating-Down Attacks .....................................38 137 15. Message Sequences ...............................................38 138 15.1 Successful authentication via tunneled CHAP ..................39 139 15.2 Successful authentication via tunneled EAP/MD5-Challenge .....40 140 15.3 Successful session resumption ................................43 141 16. IANA Considerations .............................................44 142 17. Acknowledgements ................................................44 143 18. References ......................................................45 144 18.1 Normative References .........................................45 145 18.2 Informative References .......................................46 146 19. Authors' Addresses ..............................................47 147 20. Intellectual Property Statement .................................47 148 21. Disclaimer of Validity ..........................................47 149 22. Copyright Statement .............................................48 150 23. Acknowledgement .................................................48 151 1. Introduction 153 Extensible Authentication Protocol (EAP) [RFC3748] defines a 154 standard message exchange that allows a server to authenticate a 155 client using an authentication method agreed upon by both parties. 156 EAP may be extended with additional authentication methods by 157 registering such methods with IANA or by defining vendor specific 158 methods. 160 Transport Layer Security (TLS) [RFC4346] is an authentication 161 protocol that provides for client authentication of a server or 162 mutual authentication of client and server, as well as secure 163 ciphersuite negotiation and key exchange between the parties. TLS 164 has been defined as an authentication protocol for use within EAP 165 (EAP-TLS) [RFC5216]. 167 Other authentication protocols are also widely deployed. These are 168 typically password-based protocols, and there is a large installed 169 base of support for these protocols in the form of credential 170 databases that may be accessed by RADIUS [RFC2865], Diameter 171 [RFC3588] or other AAA servers. These include non-EAP protocols such 172 as PAP [RFC1661], CHAP [RFC1661], MS-CHAP [RFC2433] or MS-CHAP-V2 173 [RFC2759], as well as EAP protocols such as MD5-Challenge [RFC3748]. 175 EAP-TTLS is an EAP method that provides functionality beyond what is 176 available in EAP-TLS. In EAP-TLS, a TLS handshake is used to 177 mutually authenticate a client and server. EAP-TTLS extends this 178 authentication negotiation by using the secure connection 179 established by the TLS handshake to exchange additional information 180 between client and server. In EAP-TTLS, the TLS handshake may be 181 mutual; or it may be one-way, in which only the server is 182 authenticated to the client. The secure connection established by 183 the handshake may then be used to allow the server to authenticate 184 the client using existing, widely-deployed authentication 185 infrastructures. The authentication of the client may itself be EAP, 186 or it may be another authentication protocol such as PAP, CHAP, MS- 187 CHAP or MS-CHAP-V2. 189 Thus, EAP-TTLS allows legacy password-based authentication protocols 190 to be used against existing authentication databases, while 191 protecting the security of these legacy protocols against 192 eavesdropping, man-in-the-middle and other attacks. 194 EAP-TTLS also allows client and server to establish keying material 195 for use in the data connection between the client and access point. 196 The keying material is established implicitly between client and 197 server based on the TLS handshake. 199 In EAP-TTLS, client and server communicate using attribute-value 200 pairs encrypted within TLS. This generality allows arbitrary 201 functions beyond authentication and key exchange to be added to the 202 EAP negotiation, in a manner compatible with the AAA infrastructure. 204 2. Motivation 206 Most password-based protocols in use today rely on a hash of the 207 password with a random challenge. Thus, the server issues a 208 challenge, the client hashes that challenge with the password and 209 forwards a response to the server, and the server validates that 210 response against the user's password retrieved from its database. 211 This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5- 212 Challenge and EAP/One-Time Password. 214 An issue with such an approach is that an eavesdropper that observes 215 both challenge and response may be able to mount a dictionary 216 attack, in which random passwords are tested against the known 217 challenge to attempt to find one which results in the known 218 response. Because passwords typically have low entropy, such attacks 219 can in practice easily discover many passwords. 221 While this vulnerability has long been understood, it has not been 222 of great concern in environments where eavesdropping attacks are 223 unlikely in practice. For example, users with wired or dial-up 224 connections to their service providers have not been concerned that 225 such connections may be monitored. Users have also been willing to 226 entrust their passwords to their service providers, or at least to 227 allow their service providers to view challenges and hashed 228 responses which are then forwarded to their home authentication 229 servers using, for example, proxy RADIUS, without fear that the 230 service provider will mount dictionary attacks on the observed 231 credentials. Because a user typically has a relationship with a 232 single service provider, such trust is entirely manageable. 234 With the advent of wireless connectivity, however, the situation 235 changes dramatically: 237 - Wireless connections are considerably more susceptible to 238 eavesdropping and man-in-the-middle attacks. These attacks may 239 enable dictionary attacks against low-entropy passwords. In 240 addition, they may enable channel hijacking, in which an attacker 241 gains fraudulent access by seizing control of the communications 242 channel after authentication is complete. 244 - Existing authentication protocols often begin by exchanging the 245 client's username in the clear. In the context of eavesdropping 246 on the wireless channel, this can compromise the client's 247 anonymity and locational privacy. 249 - Often in wireless networks, the access point does not reside in 250 the administrative domain of the service provider with which the 251 user has a relationship. For example, the access point may reside 252 in an airport, coffee shop, or hotel in order to provide public 253 access via 802.11 [802.11]. Even if password authentications are 254 protected in the wireless leg, they may still be susceptible to 255 eavesdropping within the untrusted wired network of the access 256 point. 258 - In the traditional wired world, the user typically intentionally 259 connects with a particular service provider by dialing an 260 associated phone number; that service provider may be required to 261 route an authentication to the user's home domain. In a wireless 262 network, however, the user does not get to choose an access 263 domain, and must connect with whichever access point is nearby; 264 providing for the routing of the authentication from an arbitrary 265 access point to the user's home domain may pose a challenge. 267 Thus, the authentication requirements for a wireless environment 268 that EAP-TTLS attempts to address can be summarized as follows: 270 - Legacy password protocols must be supported, to allow easy 271 deployment against existing authentication databases. 273 - Password-based information must not be observable in the 274 communications channel between the client node and a trusted 275 service provider, to protect the user against dictionary attacks. 277 - The user's identity must not be observable in the communications 278 channel between the client node and a trusted service provider, 279 to protect the user against surveillance, undesired acquisition 280 of marketing information, and the like. 282 - The authentication process must result in the distribution of 283 shared keying information to the client and access point to 284 permit encryption and validation of the wireless data connection 285 subsequent to authentication, to secure it against eavesdroppers 286 and prevent channel hijacking. 288 - The authentication mechanism must support roaming among access 289 domains with which the user has no relationship and which will 290 have limited capabilities for routing authentication requests. 292 3. Requirements Language 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 296 document are to be interpreted as described in [RFC2119]. 298 4. Terminology 300 AAA 301 Authentication, Authorization and Accounting - functions that are 302 generally required to control access to a network and support 303 billing and auditing. 305 AAA protocol 307 A network protocol used to communicate with AAA servers; examples 308 include RADIUS and Diameter. 310 AAA server 312 A server which performs one or more AAA functions: authenticating 313 a user prior to granting network service, providing authorization 314 (policy) information governing the type of network service the 315 user is to be granted, and accumulating accounting information 316 about actual usage. 318 AAA/H 320 A AAA server in the user's home domain, where authentication and 321 authorization for that user are administered. 323 access point 325 A network device providing users with a point of entry into the 326 network, and which may enforce access control and policy based on 327 information returned by a AAA server. Since the access point 328 terminates the server side of the EAP conversation, for the 329 purposes of this document it is therefore equivalent to the 330 "authenticator", as used in the EAP specification [RFC3748]. 331 Since the access point acts as a client to a AAA server, for the 332 purposes of this document it is therefore also equivalent to the 333 "NAS", as used in AAA specifications such as [RFC2865]. 335 access domain 337 The domain, including access points and other devices, that 338 provides users with an initial point of entry into the network; 339 for example, a wireless hot spot. 341 client 343 A host or device that connects to a network through an access 344 point. Since it terminates the client side of the EAP 345 conversation, for the purposes of this document, it is therefore 346 equivalent to the "peer", as used in the EAP specification 347 [RFC3748]. 349 domain 350 A network and associated devices that are under the 351 administrative control of an entity such as a service provider or 352 the user's home organization. 354 link layer 356 A protocol used to carry data between hosts that are connected 357 within a single network segment; examples include PPP and 358 Ethernet. 360 NAI 362 A Network Access Identifier [RFC4282], normally consisting of the 363 name of the user and, optionally, the user's home realm. 365 proxy 367 A server that is able to route AAA transactions to the 368 appropriate AAA server, possibly in another domain, typically 369 based on the realm portion of an NAI. 371 realm 373 The optional part of an NAI indicating the domain to which a AAA 374 transaction is to be routed, normally the user's home domain. 376 service provider 378 An organization with which a user has a business relationship, 379 that provides network or other services. The service provider may 380 provide the access equipment with which the user connects, may 381 perform authentication or other AAA functions, may proxy AAA 382 transactions to the user's home domain, etc. 384 TTLS server 386 A AAA server which implements EAP-TTLS. This server may also be 387 capable of performing user authentication, or it may proxy the 388 user authentication to a AAA/H. 390 user 392 The person operating the client device. Though the line is often 393 blurred, "user" is intended to refer to the human being who is 394 possessed of an identity (username), password or other 395 authenticating information, and "client" is intended to refer to 396 the device which makes use of this information to negotiate 397 network access. There may also be clients with no human 398 operators; in this case the term "user" is a convenient 399 abstraction. 401 5. Architectural Model 403 The network architectural model for EAP-TTLS usage and the type of 404 security it provides is shown below. 406 +----------+ +----------+ +----------+ +----------+ 407 | | | | | | | | 408 | client |<---->| access |<---->| TTLS AAA |<---->| AAA/H | 409 | | | point | | server | | server | 410 | | | | | | | | 411 +----------+ +----------+ +----------+ +----------+ 413 <---- secure password authentication tunnel ---> 415 <---- secure data tunnel ----> 417 The entities depicted above are logical entities and may or may not 418 correspond to separate network components. For example, the TTLS 419 server and AAA/H server might be a single entity; the access point 420 and TTLS server might be a single entity; or, indeed, the functions 421 of the access point, TTLS server and AAA/H server might be combined 422 into a single physical device. The above diagram illustrates the 423 division of labor among entities in a general manner and shows how a 424 distributed system might be constructed; however, actual systems 425 might be realized more simply. 427 Note also that one or more AAA proxy servers might be deployed 428 between access point and TTLS server, or between TTLS server and 429 AAA/H server. Such proxies typically perform aggregation or are 430 required for realm-based message routing. However, such servers play 431 no direct role in EAP-TTLS and are therefore not shown. 433 5.1 Carrier Protocols 435 The entities shown above communicate with each other using carrier 436 protocols capable of encapsulating EAP. The client and access point 437 communicate typically using a link layer carrier protocol such as 438 PPP or EAPOL. The access point, TTLS server and AAA/H server 439 communicate using a AAA carrier protocol such as RADIUS or Diameter. 441 EAP, and therefore EAP-TTLS, must be initiated via the carrier 442 protocol between client and access point. In PPP or EAPOL, for 443 example, EAP is initiated when the access point sends an EAP- 444 Request/Identity packet to the client. 446 The keying material used to encrypt and authenticate the data 447 connection between the client and access point is developed 448 implicitly between the client and TTLS server as a result of EAP- 449 TTLS negotiation. This keying material must be communicated to the 450 access point by the TTLS server using the AAA carrier protocol. 452 5.2 Security Relationships 454 The client and access point have no pre-existing security 455 relationship. 457 The access point, TTLS server and AAA/H server are each assumed to 458 have a pre-existing security association with the adjacent entity 459 with which it communicates. With RADIUS, for example, this is 460 achieved using shared secrets. It is essential for such security 461 relationships to permit secure key distribution. 463 The client and AAA/H server have a security relationship based on 464 the user's credentials such as a password. 466 The client and TTLS server may have a one-way security relationship 467 based on the TTLS server's possession of a private key guaranteed by 468 a CA certificate which the user trusts, or may have a mutual 469 security relationship based on certificates for both parties. 471 5.3 Messaging 473 The client and access point initiate an EAP conversation to 474 negotiate the client's access to the network. Typically, the access 475 point issues an EAP-Request/Identity to the client, which responds 476 with an EAP-Response/Identity. Note that the client need not include 477 the user's actual identity in this EAP-Response/Identity packet 478 other than for routing purposes (e.g. realm information; see section 479 7.3 and [RFC3748] section 5.1); the user's actual identity need not 480 be transmitted until an encrypted channel has been established. 482 The access point now acts as a passthrough device, allowing the TTLS 483 server to negotiate EAP-TTLS with the client directly. 485 During the first phase of the negotiation, the TLS handshake 486 protocol is used to authenticate the TTLS server to the client and, 487 optionally, to authenticate the client to the TTLS server, based on 488 public/private key certificates. As a result of the handshake, 489 client and TTLS server now have shared keying material and an agreed 490 upon TLS record layer cipher suite with which to secure subsequent 491 EAP-TTLS communication. 493 During the second phase of negotiation, client and TTLS server use 494 the secure TLS record layer channel established by the TLS handshake 495 as a tunnel to exchange information encapsulated in attribute-value 496 pairs, to perform additional functions such as authentication (one- 497 way or mutual), validation of client integrity and configuration, 498 provisioning of information required for data connectivity, etc. 500 If a tunneled client authentication is performed, the TTLS server 501 de-tunnels and forwards the authentication information to the AAA/H. 502 If the AAA/H performs a challenge, the TTLS server tunnels the 503 challenge information to the client. The AAA/H server may be a 504 legacy device and needs to know nothing about EAP-TTLS; it only 505 needs to be able to authenticate the client based on commonly used 506 authentication protocols. 508 Keying material for the subsequent data connection between client 509 and access point (MSK/EMSK; see section 8) is generated based on 510 secret information developed during the TLS handshake between client 511 and TTLS server. At the conclusion of a successful authentication, 512 the TTLS server may transmit this keying material to the access 513 point, encrypted based on the existing security associations between 514 those devices (e.g., RADIUS). 516 The client and access point now share keying material which they can 517 use to encrypt data traffic between them. 519 5.4 Resulting Security 521 As the diagram above indicates, EAP-TTLS allows user identity and 522 password information to be securely transmitted between client and 523 TTLS server, and generates keying material to allow network data 524 subsequent to authentication to be securely transmitted between 525 client and access point. 527 6. Protocol Layering Model 529 EAP-TTLS packets are encapsulated within EAP, and EAP in turn 530 requires a carrier protocol to transport it. EAP-TTLS packets 531 themselves encapsulate TLS, which is then used to encapsulate 532 attribute-value pairs (AVPs) which may carry user authentication or 533 other information. Thus, EAP-TTLS messaging can be described using a 534 layered model, where each layer is encapsulated by the layer beneath 535 it. The following diagram clarifies the relationship between 536 protocols: 538 +-----------------------------------------------------------+ 539 | AVPs, including authentication (PAP, CHAP, MS-CHAP, etc.) | 540 +-----------------------------------------------------------+ 541 | TLS | 542 +-----------------------------------------------------------+ 543 | EAP-TTLS | 544 +-----------------------------------------------------------+ 545 | EAP | 546 +-----------------------------------------------------------+ 547 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | 548 +-----------------------------------------------------------+ 550 When the user authentication protocol is itself EAP, the layering is 551 as follows: 553 +-----------------------------------------------------------+ 554 | EAP Method (MD-Challenge, etc.) | 555 +-----------------------------------------------------------+ 556 | AVPs, including EAP | 557 +-----------------------------------------------------------+ 558 | TLS | 559 +-----------------------------------------------------------+ 560 | EAP-TTLS | 561 +-----------------------------------------------------------+ 562 | EAP | 563 +-----------------------------------------------------------+ 564 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | 565 +-----------------------------------------------------------+ 567 Methods for encapsulating EAP within carrier protocols are already 568 defined. For example, PPP [RFC1661] or EAPOL [802.1X] may be used to 569 transport EAP between client and access point; RADIUS [RFC2865] or 570 Diameter [RFC3588] are used to transport EAP between access point 571 and TTLS server. 573 7. EAP-TTLS Overview 575 A EAP-TTLS negotiation comprises two phases: the TLS handshake phase 576 and the TLS tunnel phase. 578 During phase 1, TLS is used to authenticate the TTLS server to the 579 client and, optionally, the client to the TTLS server. Phase 1 580 results in the activation of a cipher suite, allowing phase 2 to 581 proceed securely using the TLS record layer. (Note that the type and 582 degree of security in phase 2 depends on the cipher suite negotiated 583 during phase 1; if the null cipher suite is negotiated, there will 584 be no security!) 586 During phase 2, the TLS record layer is used to tunnel information 587 between client and TTLS server to perform any of a number of 588 functions. These might include user authentication, client integrity 589 validation, negotiation of data communication security capabilities, 590 key distribution, communication of accounting information, etc. 591 Information between client and TTLS server is exchanged via 592 attribute-value pairs (AVPs) compatible with RADIUS and Diameter; 593 thus, any type of function that can be implemented via such AVPs may 594 easily be performed. 596 EAP-TTLS specifies how user authentication may be performed during 597 phase 2. The user authentication may itself be EAP, or it may be a 598 legacy protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Phase 2 599 user authentication may not always be necessary, since the user may 600 already have been authenticated via the mutual authentication option 601 of the TLS handshake protocol. 603 Functions other than authentication MAY also be performed during 604 phase 2. This document does not define any such functions; however, 605 any organization or standards body is free to specify how additional 606 functions may be performed through the use of appropriate AVPs. 608 EAP-TTLS specifies how keying material for the data connection 609 between client and access point is generated. The keying material is 610 developed implicitly between client and TTLS server based on the 611 results of the TLS handshake; the TTLS server will communicate the 612 keying material to the access point over the carrier protocol. 614 7.1 Phase 1: Handshake 616 In phase 1, the TLS handshake protocol is used to authenticate the 617 TTLS server to the client and, optionally, to authenticate the 618 client to the TTLS server. 620 The TTLS server initiates the EAP-TTLS method with an EAP-TTLS/Start 621 packet, which is an EAP-Request with Type = EAP-TTLS and the S 622 (Start) bit set. This indicates to the client that it should begin 623 TLS handshake by sending a ClientHello message. 625 EAP packets continue to be exchanged between client and TTLS server 626 to complete the TLS handshake, as described in [RFC5216]. Phase 1 is 627 completed when the client and TTLS server exchange ChangeCipherSpec 628 and Finished messages. At this point, additional information may be 629 securely tunneled. 631 As part of the TLS handshake protocol, the TTLS server will send its 632 certificate along with a chain of certificates leading to the 633 certificate of a trusted CA. The client will need to be configured 634 with the certificate of the trusted CA in order to perform the 635 authentication. 637 If certificate-based authentication of the client is desired, the 638 client must have been issued a certificate and must have the private 639 key associated with that certificate. 641 7.2 Phase 2: Tunnel 643 In phase 2, the TLS Record Layer is used to securely tunnel 644 information between client and TTLS server. This information is 645 encapsulated in sequences of attribute-value pairs (AVPs), whose use 646 and format are described in later sections. 648 Any type of information may be exchanged during phase 2, according 649 to the requirements of the system. (It is expected that applications 650 utilizing EAP-TTLS will specify what information must be exchanged 651 and therefore which AVPs must be supported.) 652 The client begins the phase 2 exchange by encoding information in a 653 sequence of AVPs, passing this sequence to the TLS record layer for 654 encryption, and sending the resulting data to the TTLS server. 656 The TTLS server recovers the AVPs in clear text from the TLS record 657 layer. If the AVP sequence includes authentication information, it 658 forwards this information to the AAA/H server using the AAA carrier 659 protocol. Note that the EAP-TTLS and AAA/H servers may be one and 660 the same, in which case it simply processes the information locally. 662 The TTLS server may respond with its own sequence of AVPs. The TTLS 663 server passes the AVP sequence to the TLS record layer for 664 encryption and sends the resulting data to the client. For example, 665 the TTLS server may forward an authentication challenge received 666 from the AAA/H. 668 This process continues until the AAA/H either accepts or rejects the 669 client, resulting in the TTLS server completing the EAP-TTLS 670 negotiation and indicating success or failure to the encapsulating 671 EAP protocol (which normally results in a final EAP-Success or EAP- 672 Failure being sent to the client). 674 The TTLS server distributes data connection keying information and 675 other authorization information to the access point in the same AAA 676 carrier protocol message that carries the final EAP-Success or other 677 success indication. 679 7.3 EAP Identity Information 681 The identity of the user is provided during phase 2, where it is 682 protected by the TLS tunnel. However, prior to beginning the EAP- 683 TTLS authentication, the client will typically issue an EAP- 684 Response/Identity packet as part of the EAP protocol, containing a 685 username in clear text. To preserve user anonymity against 686 eavesdropping, this packet specifically SHOULD NOT include the 687 actual name of the user; instead, it SHOULD use a blank or 688 placeholder such as "anonymous". However, this privacy constraint is 689 not intended to apply to any information within the EAP- 690 Response/Identity that is required for routing; thus, the EAP- 691 Response/Identity packet MAY include the name of the realm of a 692 trusted provider to which EAP-TTLS packets should be forwarded; for 693 example, "anonymous@myisp.com". 695 Note that at the time the initial EAP-Response/Identity packet is 696 sent the EAP method is yet to be negotiated. If, in addition to EAP- 697 TTLS, the client is willing to negotiate use of EAP methods that do 698 not support user anonymity, then the client MAY include the name of 699 the user in the EAP-Response/Identity to meet the requirements of 700 the other candidate EAP methods. 702 7.4 Piggybacking 704 While it is convenient to describe EAP-TTLS messaging in terms of 705 two phases, it is sometimes required that a single EAP-TTLS packet 706 contain both phase 1 and phase 2 TLS messages. 708 Such "piggybacking" occurs when the party that completes the 709 handshake also has AVPs to send. For example, when negotiating a 710 resumed TLS session, the TTLS server sends its ChangeCipherSpec and 711 Finished messages first, then the client sends its own 712 ChangeCipherSpec and Finished messages to conclude the handshake. If 713 the client has authentication or other AVPs to send to the TTLS 714 server, it MUST tunnel those AVPs within the same EAP-TTLS packet 715 immediately following its Finished message. If the client fails to 716 do this, the TTLS server will incorrectly assume that the client has 717 no AVPs to send, and the outcome of the negotiation could be 718 affected. 720 7.5 Session Resumption 722 When a client and TTLS server that have previously negotiated an 723 EAP-TTLS session begin a new EAP-TTLS negotiation, the client and 724 TTLS server MAY agree to resume the previous session. This 725 significantly reduces the time required to establish the new 726 session. This could occur when the client connects to a new access 727 point, or when an access point requires reauthentication of a 728 connected client. 730 Session resumption is accomplished using the standard TLS mechanism. 731 The client signals its desire to resume a session by including the 732 session ID of the session it wishes to resume in the ClientHello 733 message; the TTLS server signals its willingness to resume that 734 session by echoing that session ID in its ServerHello message. 736 If the TTLS server elects not to resume the session, it simply does 737 not echo the session ID, causing a new session to be negotiated. 738 This could occur if the TTLS server is configured not to resume 739 sessions, if it has not retained the requested session's state, or 740 if the session is considered stale. A TTLS server may consider the 741 session stale based on its own configuration, or based on session- 742 limiting information received from the AAA/H (e.g., the RADIUS 743 Session-Timeout attribute). 745 Tunneled authentication is specifically not performed for resumed 746 sessions; the presumption is that the knowledge of the master secret 747 as evidenced by the ability to resume the session is authentication 748 enough. This allows session resumption to occur without any 749 messaging between the TTLS server and the AAA/H. If periodic 750 reauthentication to the AAA/H is desired, the AAA/H must indicate 751 this to the TTLS server when the original session is established, 752 for example, using the RADIUS Session-Timeout attribute. 754 The client MAY send other AVPs in its first phase 2 message of a 755 session resumption, to initiate non-authentication functions. If it 756 does not, the TTLS server, at its option, MAY send AVPs to the 757 client to initiate non-authentication functions, or MAY simply 758 complete the EAP-TTLS negotiation and indicate success or failure to 759 the encapsulating EAP protocol. 761 The TTLS server MUST retain authorization information returned by 762 the AAA/H for use in resumed sessions. A resumed session MUST 763 operate under the same authorizations as the original session, and 764 the TTLS server must be prepared to send the appropriate information 765 back to the access point. Authorization information might include 766 the maximum time for the session, the maximum allowed bandwidth, 767 packet filter information and the like. The TTLS server is 768 responsible for modifying time values, such as Session-Timeout, 769 appropriately for each resumed session. 771 A TTLS server MUST NOT permit a session to be resumed if that 772 session did not result in a successful authentication of the user 773 during phase 2. The consequence of incorrectly implementing this 774 aspect of session resumption would be catastrophic; any attacker 775 could easily gain network access by first initiating a session that 776 succeeds in the TLS handshake but fails during phase 2 777 authentication, and then resuming that session. 779 [Implementation note: Toolkits that implement TLS often cache 780 resumable TLS sessions automatically. Implementers must take care to 781 override such automatic behavior, and prevent sessions from being 782 cached for possible resumption until the user has been positively 783 authenticated during phase 2.] 785 7.6 Determining Whether to Enter Phase 2 787 Entering phase 2 is optional, and may be initiated by either client 788 or TTLS server. If no further authentication or other information 789 exchange is required upon completion of phase 1, it is possible to 790 successfully complete the EAP-TTLS negotiation without ever entering 791 phase 2 or tunneling any AVPs. 793 Scenarios in which phase 2 is never entered include: 795 - Successful session resumption, with no additional information 796 exchange required, 798 - Authentication of the client via client certificate during phase 799 1, with no additional authentication or information exchange 800 required. 802 The client always has the first opportunity to initiate phase 2 upon 803 completion of phase 1. If the client has no AVPs to send, it either 804 sends an Acknowledgement (see section 9.2.3) if the TTLS server 805 sends the final phase 1 message, or simply does not piggyback a 806 phase 2 message when it issues the final phase 1 message (as will 807 occur during session resumption). 809 If the client does not initiate phase 2, the TTLS server, at its 810 option, may either complete the EAP-TTLS negotiation without 811 entering phase 2 or initiate phase 2 by tunneling AVPs to the 812 client. 814 For example, suppose a successful session resumption occurs in phase 815 1. The following sequences are possible: 817 - Neither client nor TTLS server has additional information to 818 exchange. The client completes phase 1 without piggybacking phase 819 2 AVPs, and the TTLS server indicates success to the 820 encapsulating EAP protocol without entering phase 2. 822 - The client has no additional information to exchange, but the 823 TTLS server does. The client completes phase 1 without 824 piggybacking phase 2 AVPs, but the TTLS server extends the EAP- 825 TTLS negotiation into phase 2 by tunneling AVPs in its next EAP- 826 TTLS message. 828 - The client has additional information to exchange, and piggybacks 829 phase 2 AVPs with its final phase 1 message, thus extending the 830 negotiation into phase 2. 832 7.7 TLS Version 834 TLS version 1.0 [RFC2246], 1.1 [RFC4346], or any subsequent version 835 MAY be used within EAP-TTLS. TLS provides for its own version 836 negotiation mechanism. 838 For maximum interoperability, EAP-TTLS implementations SHOULD 839 support TLS version 1.0. 841 7.8 Use of TLS PRF 843 EAP-TTLSv0 utilizes a pseudo-random function (PRF) to generate 844 keying material (section 8) and to generate implicit challenge 845 material for certain authentication methods (section 11.1). The PRF 846 used in these computations is the TLS PRF used in the TLS handshake 847 negotiation that initiates the EAP-TTLS exchange. 849 TLS versions 1.0 [RFC2246] and 1.1 [RFC4346] define the same PRF 850 function, and any EAP-TTLSv0 implementation based on these versions 851 of TLS must use the PRF defined therein. It is expected that future 852 versions of or extensions to the TLS protocol will permit 853 alternative PRF functions to be negotiated. If an alternative PRF 854 function is specified for the underlying TLS version or has been 855 negotiated during the TLS handshake negotiation, then that 856 alternative PRF function must be used in EAP-TTLSv0 computations 857 instead of the TLS 1.0/1.1 PRF. 859 The TLS PRF function used in this specification is denoted as 860 follows: 862 PRF-nn(secret, label, seed) 864 where: 866 nn is the number of generated octets 868 secret is a secret key 870 label is a string (without null-terminator) 872 seed is a binary sequence. 874 The TLS 1.0/1.1 PRF has invariant output regardless of how many 875 octets are generated. However, it is possible that alternative PRF 876 functions will include the size of the output sequence as input to 877 the PRF function; this means generating 32 octets and generating 64 878 octets from the same input parameters will no longer result in the 879 first 32 octets being identical. For this reason, the PRF is always 880 specified with an "nn", indicating the number of generated octets. 882 8. Generating Keying Material 884 Upon successful conclusion of an EAP-TTLS negotiation, 128 octets of 885 keying material is generated and exported for use in securing the 886 data connection between client and access point. The first 64 octets 887 of the keying material constitutes the MSK, the second 64 octets 888 constitutes the EMSK. 890 The keying material is generated using the TLS PRF function 891 [RFC4346], with inputs consisting of the TLS master secret, the 892 ASCII-encoded constant string "ttls keying material", the TLS client 893 random, and the TLS server random. The constant string is not null- 894 terminated. 896 Keying Material = PRF-128(SecurityParameters.master_secret, 897 "ttls keying material", 898 SecurityParameters.client_random + 899 SecurityParameters.server_random) 901 MSK = Keying Material [0..63] 903 EMSK = Keying Material [64..127] 905 Note that the order of client_random and server_random for EAP-TTLS 906 is reversed from that of the TLS protocol [RFC4346]. This ordering 907 follows the key derivation method of EAP-TLS [RFC5216]. Altering the 908 order of randoms avoids namespace collisions between constant 909 strings defined for EAP-TTLS and those defined for the TLS protocol. 911 The TTLS server distributes this keying material to the access point 912 via the AAA carrier protocol. When RADIUS is the AAA carrier 913 protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes [RFC2548] 914 may be used to distribute the first 32 octets and second 32 octets 915 of the MSK, respectively. 917 9. EAP-TTLS Protocol 919 9.1 Packet Format 921 The EAP-TTLS packet format is shown below. The fields are 922 transmitted left to right. 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Code | Identifier | Length | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Type | Flags | Message Length 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Message Length | Data... 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Code 935 1 for request, 2 for response. 937 Identifier 938 The Identifier field is one octet and aids in matching responses 939 with requests. The Identifier field MUST be changed for each 940 request packet and MUST be echoed in each response packet. 942 Length 943 The Length field is two octets and indicates the number of octets 944 in the entire EAP packet, from the Code field through the Data 945 field. 947 Type 948 21 (EAP-TTLS) 950 Flags 951 0 1 2 3 4 5 6 7 952 +---+---+---+---+---+---+---+---+ 953 | L | M | S | R | R | V | 954 +---+---+---+---+---+---+---+---+ 956 L = Length included 957 M = More fragments 958 S = Start 959 R = Reserved 960 V = Version (000 for EAP-TTLSv0) 962 The L bit is set to indicate the presence of the four octet TLS 963 Message Length field. The M bit indicates that more fragments are 964 to come. The S bit indicates a Start message. The V field is set 965 to the version of EAP-TTLS, and is set to 000 for EAP-TTLSv0. 967 Message Length 968 The Message Length field is four octets, and is present only if 969 the L bit is set. This field provides the total length of the raw 970 data message sequence prior to fragmentation. 972 Data 973 For all packets other than a Start packet, the Data field 974 consists of the raw TLS message sequence or fragment thereof. For 975 a Start packet, the Data field may optionally contain an AVP 976 sequence. 978 9.2 EAP-TTLS Start Packet 980 The S bit MUST be set on the first packet sent by the server to 981 initiate the EAP-TTLS protocol. It MUST NOT be set on any other 982 packet. 984 This packet MAY contain additional information in the form of AVPs, 985 which may provide useful hints to the client; for example, the 986 server identity may be useful to the client to allow it to pick the 987 correct TLS session ID for session resumption. Each AVP must begin 988 on a 4-octet boundary relative to the first AVP in the sequence. If 989 an AVP is not a multiple of 4 octets, it must be padded with 0s to 990 the next 4-octet boundary. 992 9.2.1 Version Negotiation 994 The version of EAP-TTLS is negotiated in the first exchange between 995 server and client. The server sets the highest version number of 996 EAP-TTLS that it supports in the V field of its Start message (in 997 the case of EAP-TTLSv0, this is 0). In its first EAP message in 998 response, the client sets the V field to the highest version number 999 that it supports that is no higher than the version number offered 1000 by the server. If the client version is not acceptable to the 1001 server, it sends an EAP-Failure to terminate the EAP session. 1002 Otherwise, the version sent by the client is the version of EAP-TTLS 1003 that MUST be used, and both server and client MUST set the V field 1004 to that version number in all subsequent EAP messages. 1006 9.2.2 Fragmentation 1008 Each EAP-TTLS message contains a single leg of a half-duplex 1009 conversation. The EAP carrier protocol (e.g., PPP, EAPOL, RADIUS) 1010 may impose constraints on the length of an EAP message. Therefore it 1011 may be necessary to fragment an EAP-TTLS message across multiple EAP 1012 messages. 1014 Each fragment except for the last MUST have the M bit set, to 1015 indicate that more data is to follow; the final fragment MUST NOT 1016 have the M bit set. 1018 If there are multiple fragments, the first fragment MUST have the L 1019 bit set and include the length of the entire raw message prior to 1020 fragmentation. Fragments other than the first MUST NOT have the L 1021 bit set. Unfragmented messages MAY have the L bit set and include 1022 the length of the message (though this information is redundant). 1024 Upon receipt of a packet with M bit set, the receiver MUST transmit 1025 an Acknowledgement packet. The receiver is responsible for 1026 reassembly of fragmented packets. 1028 9.2.3 Acknowledgement Packets 1030 An Acknowledgement packet is an EAP-TTLS packet with no additional 1031 data beyond the Flags octet, and with the L, M and S bits of the 1032 Flags octet set to 0. (Note, however, that the V field MUST still be 1033 set to the appropriate version number.) 1035 An Acknowledgement packet is sent for the following purposes: 1037 - Fragment Acknowledgement 1039 A Fragment Acknowledgement is sent in response to an EAP packet 1040 with M bit set. 1042 - When the final EAP packet of the EAP-TTLS negotiation is sent by 1043 the TTLS server, the client must respond with an Acknowledgement 1044 packet, to allow the TTLS server to proceed with the EAP protocol 1045 upon completion of EAP-TTLS (typically by sending or causing to 1046 be sent a final EAP-Success or EAP-Failure to the client). 1048 10. Encapsulation of AVPs within the TLS Record Layer 1050 Subsequent to the TLS handshake, information may be tunneled between 1051 client and TTLS server through the use of attribute-value pairs 1052 (AVPs) encrypted within the TLS record layer. 1054 The AVP format chosen for EAP-TTLS is compatible with the Diameter 1055 AVP format. This does not at all represent a requirement that 1056 Diameter be supported by any of the devices or servers participating 1057 in an EAP-TTLS negotiation. Use of this format is merely a 1058 convenience. Diameter is a superset of RADIUS and includes the 1059 RADIUS attribute namespace by definition, though it does not limit 1060 the size of an AVP as does RADIUS; RADIUS, in turn, is a widely 1061 deployed AAA protocol and attribute definitions exist for all 1062 commonly used password authentication protocols, including EAP. 1064 Thus, Diameter is not considered normative except as specified in 1065 this document. Specifically, the representation of the Data field of 1066 an AVP in EAP-TTLS is identical to that of Diameter. 1068 Use of the RADIUS/Diameter namespace allows a TTLS server to easily 1069 translate between AVPs it uses to communicate to clients and the 1070 protocol requirements of AAA servers that are widely deployed. Plus, 1071 it provides a well-understood mechanism to allow vendors to extend 1072 that namespace for their particular requirements. 1074 It is expected that the AVP Codes used in EAP-TTLS will carry 1075 roughly the same meaning in EAP-TTLS as they do in Diameter and, by 1076 extension, RADIUS. However, although EAP-TTLS uses the same AVP 1077 Codes and syntax as Diameter, the semantics may differ, and most 1078 Diameter AVPs do not have any well-defined semantics in EAP-TTLS. A 1079 separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be 1080 used within EAP-TTLS and their semantics in this context (see 1081 Section 16 for details). A TTLS server copying AVPs between an EAP- 1082 TTLS exchange and a Diameter or RADIUS exchange with a backend MUST 1083 NOT make assumptions about AVPs whose usage in either EAP-TTLS or 1084 the backend protocol it does not understand and therefore MUST NOT 1085 copy an AVP between an EAP-TTLS exchange and a Diameter or RADIUS 1086 exchange unless the semantics of the AVP are understood and defined 1087 in both contexts. 1089 10.1 AVP Format 1091 The format of an AVP is shown below. All items are in network, or 1092 big-endian, order; that is, they have most significant octet first. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | AVP Code | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 |V M r r r r r r| AVP Length | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Vendor-ID (opt) | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Data ... 1104 +-+-+-+-+-+-+-+-+ 1106 AVP Code 1107 The AVP Code is four octets and, combined with the Vendor-ID 1108 field if present, identifies the attribute uniquely. The first 1109 256 AVP numbers represent attributes defined in RADIUS {RFC2865]. 1110 AVP numbers 256 and above are defined in Diameter [RFC3588]. 1112 AVP Flags 1114 The AVP Flags field is one octet, and provides the receiver with 1115 information necessary to interpret the AVP. 1117 The 'V' (Vendor-Specific) bit indicates whether the optional 1118 Vendor-ID field is present. When set to 1, the Vendor-ID field is 1119 present and the AVP Code is interpreted according to the 1120 namespace defined by the vendor indicated in the Vendor-ID field. 1122 The 'M' (Mandatory) bit indicates whether support of the AVP is 1123 required. If this bit is set to 0, this indicates that the AVP 1124 may be safely ignored if the receiving party does not understand 1125 or support it. If set to 1, this indicates that the receiving 1126 party MUST fail the negotiation if it does not understand the 1127 AVP; for a TTLS server, this would imply returning EAP-Failure, 1128 for a client, this would imply abandoning the negotiation. 1130 The 'r' (reserved) bits are unused and MUST be set to 0 by the 1131 sender and MUST be ignored by the receiver. 1133 AVP Length 1135 The AVP Length field is three octets, and indicates the length of 1136 this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID 1137 (if present) and Data. 1139 Vendor-ID 1141 The Vendor-ID field is present if the 'V' bit is set in the AVP 1142 Flags field. It is four octets, and contains the vendor's IANA- 1143 assigned "SMI Network Management Private Enterprise Codes" 1144 [RFC3232] value. Vendors defining their own AVPs must maintain a 1145 consistent namespace for use of those AVPs within RADIUS, 1146 Diameter and EAP-TTLS. 1148 A Vendor-ID value of zero is equivalent to absence of the Vendor- 1149 ID field altogether. 1151 Note that the 'M' (Mandatory) bit provides a means for extending the 1152 functionality of EAP-TTLS while preserving backward compatibility 1153 when desired. By setting the 'M' bit of the appropriate AVP(s) to 0 1154 or 1, the party initiating the function indicates that support of 1155 the function by the other party is either optional or required. 1157 10.2 AVP Sequences 1159 Data encapsulated within the TLS Record Layer must consist entirely 1160 of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet 1161 boundary relative to the first AVP in the sequence. If an AVP is not 1162 a multiple of 4 octets, it must be padded with 0s to the next 4- 1163 octet boundary. 1165 Note that the AVP Length does not include the padding. 1167 10.3 Guidelines for Maximum Compatibility with AAA Servers 1169 For maximum compatibility with AAA servers, the following guidelines 1170 for AVP usage are suggested: 1172 - Non-vendor-specific AVPs intended for use with AAA servers should 1173 be selected from the set of attributes defined for RADIUS; that 1174 is, attributes with codes less than 256. This provides 1175 compatibility with both RADIUS and Diameter. 1177 - Vendor-specific AVPs intended for use with AAA servers should be 1178 defined in terms of RADIUS. Vendor-specific RADIUS attributes 1179 translate to Diameter (and, hence, to EAP-TTLS) automatically; 1180 the reverse is not true. RADIUS vendor-specific attributes use 1181 RADIUS attribute 26 and include vendor ID, vendor-specific 1182 attribute code and length; see [RFC2865] for details. 1184 11. Tunneled Authentication 1186 EAP-TTLS permits user authentication information to be tunneled 1187 within the TLS record layer between client and TTLS server, ensuring 1188 the security of the authentication information against active and 1189 passive attack between the client and TTLS server. The TTLS server 1190 decrypts and forwards this information to the AAA/H over the AAA 1191 carrier protocol. 1193 Any type of password or other authentication may be tunneled. Also, 1194 multiple tunneled authentications may be performed. Normally, 1195 tunneled authentication is used when the client has not been issued 1196 a certificate and the TLS handshake provides only one-way 1197 authentication of the TTLS server to the client; however, in certain 1198 cases it may be desired to perform certificate authentication of the 1199 client during the TLS handshake as well as tunneled user 1200 authentication afterwards. 1202 11.1 Implicit challenge 1204 Certain authentication protocols that use a challenge/response 1205 mechanism rely on challenge material that is not generated by the 1206 authentication server, and therefore require special handling. 1208 In CHAP, MS-CHAP and MS-CHAP-V2, for example, the access point 1209 issues a challenge to the client, the client then hashes the 1210 challenge with the password and forwards the response to the access 1211 point. The access point then forwards both challenge and response to 1212 a AAA server. But because the AAA server did not itself generate the 1213 challenge, such protocols are susceptible to replay attack. 1215 If the client were able to create both challenge and response, 1216 anyone able to observe a CHAP or MS-CHAP exchange could pose as that 1217 user, even using EAP-TTLS. 1219 To make these protocols secure under EAP-TTLS, it is necessary to 1220 provide a mechanism to produce a challenge that the client cannot 1221 control or predict. This is accomplished using the same technique 1222 described above for generating data connection keying material. 1224 When a challenge-based authentication mechanism is used, both client 1225 and TTLS server use the pseudo-random function to generate as many 1226 octets as are required for the challenge, using the constant string 1227 "ttls challenge", based on the master secret and random values 1228 established during the handshake: 1230 EAP-TTLS_challenge = PRF-nn(SecurityParameters.master_secret, 1231 "ttls challenge", 1232 SecurityParameters.client_random + 1233 SecurityParameters.server_random); 1235 The number of octets to be generated (nn) depends on the 1236 authentication method, and is indicated below for each 1237 authentication method requiring implicit challenge generation. 1239 11.2 Tunneled Authentication Protocols 1241 This section describes the methods for tunneling specific 1242 authentication protocols within EAP-TTLS. 1244 For the purpose of explication, it is assumed that the TTLS server 1245 and AAA/H use RADIUS as a AAA carrier protocol between them. 1246 However, this is not a requirement, and any AAA protocol capable of 1247 carrying the required information may be used. 1249 The client determines which authentication protocol will be used via 1250 the initial AVPs it sends to the server, as described in the 1251 following sections. 1253 Note that certain of the authentication protocols described below 1254 utilize vendor-specific AVPs originally defined for RADIUS. RADIUS 1255 and Diameter differ in the encoding of vendor-specific AVPs: RADIUS 1256 uses the Vendor-Specific attribute (code 26), while Diameter uses 1257 setting of the V-bit to indicate the presence of Vendor-ID. The 1258 RADIUS form of the vendor-specific attribute is always convertible 1259 to a Diameter AVP with V-bit set. All vendor-specific AVPs described 1260 below MUST be encoded using the preferred Diameter V-bit mechanism; 1261 that is, the AVP code of 26 MUST NOT be used to encode vendor- 1262 specific AVPs within EAP-TTLS. 1264 11.2.1 EAP 1266 When EAP is the tunneled authentication protocol, each tunneled EAP 1267 packet between the client and TTLS server is encapsulated in an EAP- 1268 Message AVP, prior to tunneling via the TLS record layer. 1270 Note that because Diameter AVPs are not limited to 253 octets of 1271 data, as are RADIUS attributes, the RADIUS mechanism of 1272 concatenating multiple EAP-Message attributes to represent a longer- 1273 than-253-octet EAP packet is not appropriate in EAP-TTLS. Thus, a 1274 tunneled EAP packet within a single EAP-TTLS message MUST be 1275 contained in a single EAP-Message AVP. 1277 The client initiates EAP by tunneling EAP-Response/Identity to the 1278 TTLS server. Depending on the requirements specified for the inner 1279 method, the client MAY now place the actual username in this packet; 1280 the privacy of the user's identity is now guaranteed by the TLS 1281 encryption. This username is typically a Network Access Identifier 1282 (NAI) [RFC4282]; that is, it is typically in the following format: 1284 username@realm 1286 The @realm portion is optional, and is used to allow the TTLS server 1287 to forward the EAP packet to the appropriate AAA/H. 1289 Note that the client has two opportunities to specify realms. The 1290 first, in the initial, untunneled EAP-Response/Identity packet prior 1291 to starting EAP-TTLS, indicates the realm of the TTLS server. The 1292 second, occurring as part of the EAP exchange within the EAP-TTLS 1293 tunnel, indicates the realm of the client's home network. Thus, the 1294 access point need only know how to route to the realm of the TTLS 1295 server; the TTLS server is assumed to know how to route to the 1296 client's home realm. This serial routing architecture is anticipated 1297 to be useful in roaming environments, allowing access points or AAA 1298 proxies behind access points to be configured only with a small 1299 number of realms. (Refer to section 7.3 for additional information 1300 distinguishing the untunneled and tunneled versions of the EAP- 1301 Response/Identity packets.) 1303 Note that TTLS processing of the initial identity exchange is 1304 different from plain EAP. The state machine of TTLS is different. 1305 However, it is expected that the server side is capable of dealing 1306 with client initiation, because even normal EAP protocol runs are 1307 client-initiated over AAA. On the client side there are various 1308 implementation techniques to deal with the differences. Even a TTLS- 1309 unaware EAP protocol run could be used, if TTLS makes it appear as 1310 if EAP-Request/Identity message was actually received. This is 1311 similar to what authenticators do when operating between a client 1312 and a AAA server. 1314 Upon receipt of the tunneled EAP-Response/Identity, the TTLS server 1315 forwards it to the AAA/H in a RADIUS Access-Request. 1317 The AAA/H may immediately respond with an Access-Reject, in which 1318 case the TTLS server completes the negotiation by sending an EAP- 1319 Failure to the access point. This could occur if the AAA/H does not 1320 recognize the user's identity, or if it does not support EAP. 1322 If the AAA/H does recognize the user's identity and does support 1323 EAP, it responds with an Access-Challenge containing an EAP-Request, 1324 with the Type and Type-Data fields set according to the EAP protocol 1325 with which the AAA/H wishes to authenticate the client; for example 1326 MD5-Challenge, OTP or Generic Token Card. 1328 The EAP authentication between client and AAA/H proceeds normally, 1329 as described in [RFC3748], with the TTLS server acting as a 1330 passthrough device. Each EAP-Request sent by the AAA/H in an Access- 1331 Challenge is tunneled by the TTLS server to the client, and each 1332 EAP-Response tunneled by the client is decrypted and forwarded by 1333 the TTLS server to the AAA/H in an Access-Request. 1335 This process continues until the AAA/H issues an Access-Accept or 1336 Access-Reject. 1338 Note that EAP-TTLS does not impose special rules on EAP Notification 1339 packets; such packets MAY be used within a tunneled EAP exchange 1340 according to the rules specified in [RFC3748]. 1342 EAP-TTLS provides a reliable transport for the tunneled EAP 1343 exchange. However, [RFC3748] assumes an unreliable transport for EAP 1344 messages (see section 3.1), and provides for silent discard of any 1345 EAP packet that violates the protocol or fails a method-specific 1346 integrity check, on the assumption that such a packet is likely a 1347 counterfeit sent by an attacker. But since the tunnel provides a 1348 reliable transport for the inner EAP authentication, errors that 1349 would result in silent discard according to [RFC3748] presumably 1350 represent implementation errors when they occur within the tunnel, 1351 and SHOULD be treated as such in preference to being silently 1352 discarded. Indeed, silently discarding an EAP message within the 1353 tunnel effectively puts a halt to the progress of the exchange, and 1354 will result in long timeouts in cases that ought to result in 1355 immediate failures. 1357 11.2.2 CHAP 1359 The CHAP algorithm is described in [RFC1661]; RADIUS attribute 1360 formats are described in [RFC2865]. 1362 Both client and TTLS server generate 17 octets of challenge 1363 material, using the constant string "ttls challenge" as described 1364 above. These octets are used as follows: 1366 CHAP-Challenge [16 octets] 1367 CHAP Identifier [1 octet] 1369 The client initiates CHAP by tunneling User-Name, CHAP-Challenge and 1370 CHAP-Password AVPs to the TTLS server. The CHAP-Challenge value is 1371 taken from the challenge material. The CHAP-Password consists of 1372 CHAP Identifier, taken from the challenge material; and CHAP 1373 response, computed according to the CHAP algorithm. 1375 Upon receipt of these AVPs from the client, the TTLS server must 1376 verify that the value of the CHAP-Challenge AVP and the value of the 1377 CHAP Identifier in the CHAP-Password AVP are equal to the values 1378 generated as challenge material. If either item does not match 1379 exactly, the TTLS server must reject the client. Otherwise, it 1380 forwards the AVPs to the AAA/H in an Access-Request. 1382 The AAA/H will respond with an Access-Accept or Access-Reject. 1384 11.2.3 MS-CHAP 1386 The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute 1387 formats are described in [RFC2548]. 1389 Both client and TTLS server generate 9 octets of challenge material, 1390 using the constant string "ttls challenge" as described above. These 1391 octets are used as follows: 1393 MS-CHAP-Challenge [8 octets] 1394 Ident [1 octet] 1396 The client initiates MS-CHAP by tunneling User-Name, MS-CHAP- 1397 Challenge and MS-CHAP-Response AVPs to the TTLS server. The MS-CHAP- 1398 Challenge value is taken from the challenge material. The MS-CHAP- 1399 Response consists of Ident, taken from the challenge material; 1400 Flags, set according the client preferences; and LM-Response and NT- 1401 Response, computed according to the MS-CHAP algorithm. 1403 Upon receipt of these AVPs from the client, the TTLS server MUST 1404 verify that the value of the MS-CHAP-Challenge AVP and the value of 1405 the Ident in the client's MS-CHAP-Response AVP are equal to the 1406 values generated as challenge material. If either item does not 1407 match exactly, the TTLS server MUST reject the client. Otherwise, it 1408 forwards the AVPs to the AAA/H in an Access-Request. 1410 The AAA/H will respond with an Access-Accept or Access-Reject. 1412 11.2.4 MS-CHAP-V2 1414 The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute 1415 formats are described in [RFC2548]. 1417 Both client and TTLS server generate 17 octets of challenge 1418 material, using the constant string "ttls challenge" as described 1419 above. These octets are used as follows: 1421 MS-CHAP-Challenge [16 octets] 1422 Ident [1 octet] 1424 The client initiates MS-CHAP-V2 by tunneling User-Name, MS-CHAP- 1425 Challenge and MS-CHAP2-Response AVPs to the TTLS server. The MS- 1426 CHAP-Challenge value is taken from the challenge material. The MS- 1427 CHAP2-Response consists of Ident, taken from the challenge material; 1428 Flags, set to 0; Peer-Challenge, set to a random value; and 1429 Response, computed according to the MS-CHAP-V2 algorithm. 1431 Upon receipt of these AVPs from the client, the TTLS server MUST 1432 verify that the value of the MS-CHAP-Challenge AVP and the value of 1433 the Ident in the client's MS-CHAP2-Response AVP are equal to the 1434 values generated as challenge material. If either item does not 1435 match exactly, the TTLS server MUST reject the client. Otherwise, it 1436 forwards the AVPs to the AAA/H in an Access-Request. 1438 If the authentication is successful, the AAA/H will respond with an 1439 Access-Accept containing the MS-CHAP2-Success attribute. This 1440 attribute contains a 42-octet string that authenticates the AAA/H to 1441 the client based on the Peer-Challenge. The TTLS server tunnels this 1442 AVP to the client. Note that the authentication is not yet complete; 1443 the client must still accept the authentication response of the 1444 AAA/H. 1446 Upon receipt of the MS-CHAP2-Success AVP, the client is able to 1447 authenticate the AAA/H. If the authentication succeeds, the client 1448 sends an EAP-TTLS packet to the TTLS server containing no data (that 1449 is, with a zero-length Data field). Upon receipt of the empty EAP- 1450 TTLS packet from the client, the TTLS server considers the MS-CHAP- 1451 V2 authentication to have succeeded. 1453 If the authentication fails, the AAA/H will respond with an Access- 1454 Challenge containing the MS-CHAP-Error attribute. This attribute 1455 contains a new Ident and a string with addition information such as 1456 error reason and whether a retry is allowed. The TTLS server tunnels 1457 this AVP to the client. If the error reason is an expired password 1458 and a retry is allowed, the client may proceed to change the user's 1459 password. If the error reason is not an expired password or if the 1460 client does not wish to change the user's password, it simply 1461 abandons the EAP-TTLS negotiation. 1463 If the client does wish to change the password, it tunnels MS-CHAP- 1464 NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS 1465 server. The MS-CHAP2-CPW AVP is derived from the new Ident and 1466 Challenge received in the MS-CHAP-Error AVP. The MS-CHAP-Challenge 1467 AVP simply echoes the new Challenge. 1469 Upon receipt of these AVPs from the client, the TTLS server MUST 1470 verify that the value of the MS-CHAP-Challenge AVP and the value of 1471 the Ident in the client's MS-CHAP2-CPW AVP match the values it sent 1472 in the MS-CHAP-Error AVP. If either item does not match exactly, the 1473 TTLS server MUST reject the client. Otherwise, it forwards the AVPs 1474 to the AAA/H in an Access-Request. 1476 If the authentication is successful, the AAA/H will respond with an 1477 Access-Accept containing the MS-CHAP2-Success attribute. At this 1478 point, the negotiation proceeds as described above; the TTLS server 1479 tunnels the MS-CHAP2-Success to the client, the client authenticates 1480 the AAA/H based on this AVP, it either abandons the negotiation on 1481 failure or sends an EAP-TTLS packet to the TTLS server containing no 1482 data (that is, with a zero-length Data field), causing the TTLS 1483 server to consider the MS-CHAP-V2 authentication to have succeeded. 1485 Note that additional AVPs associated with MS-CHAP-V2 may be sent by 1486 the AAA/H; for example, MS-CHAP-Domain. The TTLS server MUST tunnel 1487 such authentication-related attributes along with the MS-CHAP2- 1488 Success. 1490 11.2.5 PAP 1492 The client initiates PAP by tunneling User-Name and User-Password 1493 AVPs to the TTLS server. 1495 Normally, in RADIUS, User-Password is padded with nulls to a 1496 multiple of 16 octets, then encrypted using a shared secret and 1497 other packet information. 1499 An EAP-TTLS client, however, does not RADIUS-encrypt the password 1500 since no such RADIUS variables are available; this is not a security 1501 weakness since the password will be encrypted via TLS anyway. The 1502 client SHOULD, however, null-pad the password to a multiple of 16 1503 octets, to obfuscate its length. 1505 Upon receipt of these AVPs from the client, the TTLS server forwards 1506 them to the AAA/H in a RADIUS Access-Request. (Note that in the 1507 Access-Request, the TTLS server must encrypt the User-Password 1508 attribute using the shared secret between the TTLS server and 1509 AAA/H.) 1511 The AAA/H may immediately respond with an Access-Accept or Access- 1512 Reject. The TTLS server then completes the negotiation by sending an 1513 EAP-Success or EAP-Failure to the access point using the AAA carrier 1514 protocol. 1516 The AAA/H may also respond with an Access-Challenge. The TTLS server 1517 then tunnels the AVPs from the AAA/H's challenge to the client. Upon 1518 receipt of these AVPs, the client tunnels User-Name and User- 1519 Password again, with User-Password containing new information in 1520 response to the challenge. This process continues until the AAA/H 1521 issues an Access-Accept or Access-Reject. 1523 At least one of the AVPs tunneled to the client upon challenge MUST 1524 be Reply-Message. Normally this is sent by the AAA/H as part of the 1525 challenge. However, if the AAA/H has not sent a Reply-Message, the 1526 TTLS server MUST issue one, with null value. This allows the client 1527 to determine that a challenge response is required. 1529 Note that if the AAA/H includes a Reply-Message as part of an 1530 Access-Accept or Access-Reject, the TTLS server does not tunnel this 1531 AVP to the client. Rather, this AVP and all other AVPs sent by the 1532 AAA/H as part of Access-Accept or Access-Reject are sent to the 1533 access point via the AAA carrier protocol. 1535 11.3 Performing Multiple Authentications 1537 In some cases, it is desirable to perform multiple user 1538 authentications. For example, a AAA/H may want first to authenticate 1539 the user by password, then by token card. 1541 The AAA/H may perform any number of additional user authentications 1542 using EAP, simply by issuing a EAP-Request with a new EAP type once 1543 the previous authentication completes. Note that each new EAP method 1544 is subject to negotiation; that is, the client may respond to the 1545 EAP request for a new EAP type with an EAP-Nak, as described in 1546 [RFC3748]. 1548 For example, an AAA/H wishing to perform MD5-Challenge followed by 1549 Generic Token Card would first issue an EAP-Request/MD5-Challenge 1550 and receive a response. If the response is satisfactory, it would 1551 then issue EAP-Request/Generic Token Card and receive a response. If 1552 that response were also satisfactory, it would accept the user. 1554 The entire inner EAP exchange comprising multiple authentications is 1555 considered a single EAP sequence, in that each subsequent request 1556 MUST contain distinct a EAP Identifier from the previous, even as 1557 one authentication completes and another begins. 1559 The peer identity indicated in the original EAP-Response/Identity 1560 that initiated the EAP sequence is intended to apply to each of the 1561 sequential authentications, and in the absence of an application 1562 profile standard specifying otherwise, additional EAP-Identity 1563 exchanges SHOULD NOT occur. 1565 The conditions for overall success or failure when multiple 1566 authentications are used are a matter of policy on client and 1567 server; thus, either party may require that all inner 1568 authentications succeed, or that at least one inner authentication 1569 succeed, as a condition for success of the overall authentication. 1571 Each EAP method is intended to run to completion. Should the TTLS 1572 server abandon a method and start a new one, client behavior is not 1573 defined in this document and is a matter of client policy. 1575 Note that it is not always feasible to use the same EAP method twice 1576 in a row, since it may not be possible to determine when the first 1577 authentication completes and the new authentication begins if the 1578 EAP type does not change. Certain EAP methods, such as EAP-TLS, use 1579 a Start bit to distinguish the first request, thus allowing each new 1580 authentication using that type to be distinguished from the 1581 previous. Other methods, such as EAP-MS-CHAP-V2, terminate in a 1582 well-defined manner, allowing a second authentication of the same 1583 type to commence unambiguously. While use of the same EAP method for 1584 multiple authentications is relatively unlikely, implementers should 1585 be aware of the issues and avoid cases that would result in 1586 ambiguity. 1588 Multiple authentications using non-EAP methods or a mixture of EAP 1589 and non-EAP methods is not defined in this document, nor is it known 1590 whether such an approach has been implemented. 1592 11.4 Mandatory Tunneled Authentication Support 1594 To ensure interoperability, in the absence of an application profile 1595 standard specifying otherwise, an implementation compliant with this 1596 specification MUST implement EAP as a tunneled authentication method 1597 and MUST implement MD5-Challenge as an EAP type, though such an 1598 implementation MAY allow the use of EAP, any EAP type, or any other 1599 tunneled authentication method to be enabled or disabled by 1600 administrative action on either client or TTLS server. 1602 In addition, in the absence of an application profile standard 1603 specifying otherwise, an implementation compliant with this 1604 specification MUST allow an administrator to configure the use of 1605 tunneled authentication without the M (Mandatory) bit set on any 1606 AVP. 1608 11.5 Additional Suggested Tunneled Authentication Support 1610 The following information is provided as non-normative guidance 1611 based on the experience of the authors and reviewers of this 1612 specification with existing implementations of EAP-TTLSv0. 1614 The following authentication methods are commonly used, and servers 1615 wishing for broad interoperability across multiple media should 1616 consider implementing them: 1618 - PAP (both for password and token authentication) 1620 - MS-CHAP-V2 1622 - EAP-MS-CHAP-V2 1624 - EAP-GTC 1626 12. Keying Framework 1628 In compliance with [KEYFRAME], Session-Id, Peer-Id and Server-Id are 1629 here defined. 1631 12.1 Session-Id 1633 The Session-Id uniquely identifies an authentication exchange 1634 between the client and TTLS server. It is defined as follows: 1636 Session-Id = 0x015 || client.random || server.random 1638 12.2 Peer-Id 1640 The Peer-Id represents the identity to be used for access control 1641 and accounting purposes. When the client presents a certificate as 1642 part of the TLS handshake, the Peer-Id is determined based on 1643 information in the certificate, as specified in section 5.2 of 1644 [RFC5216]. Otherwise, the Peer-Id is null. 1646 12.3 Server-Id 1648 The Server-Id identifies the TTLS server. When the TTLS server 1649 presents a certificate as part of the TLS handshake, the Server-Id 1650 is determined based on information in the certificate, as specified 1651 in section 5.2 of [RFC5216]. Otherwise, the Server-Id is null. 1653 13. AVP Summary 1655 The following table lists each AVP defined in this document, whether 1656 the AVP may appear in a packet from server to client ("Request") 1657 and/or in a packet from client to server ("Response"), and whether 1658 the AVP MUST be implemented ("MI"). 1660 Name Request Response MI 1661 --------------------------------------------------- 1662 User-Name X 1663 User-Password X 1664 CHAP-Password X 1665 Reply-Message X 1666 CHAP-Challenge X 1667 EAP-Message X X X 1668 MS-CHAP-Response X 1669 MS-CHAP-Error X 1670 MS-CHAP-NT-Enc-PW X 1671 MS-CHAP-Domain X 1672 MS-CHAP-Challenge X 1673 MS-CHAP2-Response X 1674 MS-CHAP2-Success X 1675 MS-CHAP2-CPW X 1677 14. Security Considerations 1679 14.1 Security Claims 1681 Pursuant to RFC3748, security claims for EAP-TTLSv0 are as follows: 1683 Authentication mechanism: TLS plus arbitrary additional protected 1684 authentication(s) 1685 Ciphersuite negotiation: Yes 1686 Mutual authentication: Yes, in recommended implementation 1687 Integrity protection: Yes 1688 Replay protection: Yes 1689 Confidentiality: Yes 1690 Key derivation: Yes 1691 Key strength: Up to 384 bits 1692 Dictionary attack prot.: Yes 1693 Fast reconnect: Yes 1694 Cryptographic binding: No 1695 Session independence: Yes 1696 Fragmentation: Yes 1697 Channel binding: No 1699 14.1.1 Authentication mechanism 1701 EAP-TTLSv0 utilizes negotiated underlying authentication protocols, 1702 both in the phase 1 TLS handshake and the phase 2 tunneled 1703 authentication. In a typical deployment, at a minimum the TTLS 1704 server authenticates to the client in phase 1, and the client 1705 authenticates to the AAA/H server in phase 2. Phase 1 authentication 1706 of the TTLS server to the client is typically by certificate; the 1707 client may optionally authenticate to the TTLS server by certificate 1708 as well. Phase 2 authentication of the client to the AAA/H server is 1709 typically by password or security token via an EAP or supported non- 1710 EAP authentication mechanism; this authentication mechanism may 1711 provide authentication of AAA/H server to the client as well (mutual 1712 authentication). 1714 14.1.2 Ciphersuite negotiation 1716 Ciphersuite negotiation is inherited from TLS. 1718 14.1.3 Mutual authentication 1720 In the recommended minimum configuration, the TTLS server is 1721 authenticated to the client in phase 1, and the client and AAA/H 1722 server mutually authenticate in phase 2. 1724 14.1.4 Integrity protection 1726 Integrity protection is inherited from TLS. 1728 14.1.5 Replay protection 1730 Replay protection is inherited from TLS. 1732 14.1.6 Confidentiality 1734 Confidentiality is inherited from TLS. Note, however, that EAP- 1735 TTLSv0 contains no provision for encryption of success or failure 1736 EAP packets. 1738 14.1.7 Key derivation 1740 Both MSK and EMSK are derived. Key derivation PRF is inherited from 1741 TLS, and cryptographic agility of this mechanism depends on the 1742 cryptographic agility of the TLS PRF. 1744 14.1.8 Key strength 1746 Key strength is limited by the size of the TLS master secret, which 1747 for versions 1.0 and 1.1 is 48 octets (384 bits). Effective key 1748 strength may be less, depending on the attack resistance of the 1749 negotiated DH group, certificate RSA/DSA group, etc. BCP 86 1750 [RFC3766] Section 5 offers advice on the required RSA or DH module 1751 and DSA subgroup size in bits, for a given level of attack 1752 resistance in bits. For example, a 2048-bit RSA key is recommended 1753 to provide 128-bit equivalent key strength. The National Institute 1754 for Standards and Technology (NIST) also offers advice on 1755 appropriate key sizes in [SP800-57]. 1757 14.1.9 Dictionary attack protection 1759 Phase 2 password authentication is protected against eavesdropping 1760 and therefore against offline dictionary attack by TLS encryption. 1762 14.1.10 Fast reconnect 1764 Fast reconnect is provided by TLS session resumption. 1766 14.1.11 Cryptographic binding 1768 [MITM] describes a vulnerability that is characteristic of tunneled 1769 authentication protocols, in which an attacker authenticates as a 1770 client via a tunneled protocol by posing as an authenticator to a 1771 legitimate client using a non-tunneled protocol. When the same proof 1772 of credentials can be used in both authentications, the attacker 1773 merely shuttles the credential proof between them. EAP-TTLSv0 is 1774 vulnerable to such an attack. Care should be taken to avoid using 1775 authentication protocols and associated credentials both as inner 1776 TTLSv0 methods and as untunneled methods. 1778 Extensions to EAP-TTLSv0 or a future version of EAP-TTLS should be 1779 defined to perform a cryptographic binding of keying material 1780 generated by inner authentication methods and the keying material 1781 generated by the TLS handshake. This avoids the Man-in-the-Middle 1782 problem when used with key-generating inner methods. Such an 1783 extension mechanism has been proposed [TTLS-EXT]. 1785 14.1.12 Session independence 1787 TLS guarantees the session independence of its master secret, from 1788 which the EAP-TTLSv0 MSK/EMSK is derived. 1790 14.1.13 Fragmentation 1792 Provision is made for fragmentation of lengthy EAP packets. 1794 14.1.14 Channel binding 1796 Support for channel binding may be added as a future extension, 1797 using appropriate AVPs. 1799 14.2 Client Anonymity 1801 Unlike other EAP methods, EAP-TTLS does not communicate a username 1802 in the clear in the initial EAP-Response/Identity. This feature is 1803 designed to support anonymity and location privacy from attackers 1804 eavesdropping the network path between the client and the TTLS 1805 server. However implementers should be aware that other factors - 1806 both within EAP-TTLS and elsewhere - may compromise a user's 1807 identity. For example, if a user authenticates with a certificate 1808 during phase 1 of EAP-TTLS, the subject name in the certificate may 1809 reveal the user's identity. Outside of EAP-TTLS, the client's fixed 1810 MAC address, or in the case of wireless connections, the client's 1811 radio signature, may also reveal information. Additionally, 1812 implementers should be aware that a user's identity is not hidden 1813 from the EAP-TTLS server and may be included in the clear in AAA 1814 messages between the access point, the EAP-TTLS server, and the 1815 AAA/H server. 1817 Note that if a client authenticating with a certificate wishes to 1818 shield its certificate, and hence its identity, from eavesdroppers, 1819 it may use the technique described in the "Privacy" section of 1820 [RFC5216], in which the client sends an empty certificate list, the 1821 TTLS server issues a ServerHello upon completion of the TLS 1822 handshake to begin a second, encrypted handshake, during which the 1823 client will send its certificate list. Note that for this feature to 1824 work the client must know in advance that the TTLS server supports 1825 it. 1827 14.3 Server Trust 1829 Trust of the server by the client is established via a server 1830 certificate conveyed during the TLS handshake. The client should 1831 have a means of determining which server identities are authorized 1832 to act as a TTLS server and may be trusted, and should refuse to 1833 authenticate with servers it does not trust. The consequence of 1834 pursuing authentication with a hostile server is exposure of the 1835 inner authentication to attack; e.g. offline dictionary attack 1836 against the client password. 1838 14.4 Certificate Validation 1840 When either client or server presents a certificate as part of the 1841 TLS handshake, it should include the entire certificate chain minus 1842 the root to facilitate certificate validation by the other party. 1844 When either client or server receives a certificate as part of the 1845 TLS handshake, it should validate the certification path to a 1846 trusted root. If intermediate certificates are not provided by the 1847 sender, the receiver may use cached or pre-configured copies if 1848 available, or may retrieve them from the Internet if feasible. 1850 Clients and servers should implement policies related to the 1851 Extended Key Usage (EKU) extension [RFC3280] of certificates it 1852 receives, to ensure that the other party's certificate usage 1853 conforms to the certificate's purpose. Typically, a client EKU, when 1854 present, would be expected to include id-kp-clientAuth; a server 1855 EKU, when present, would be expected to include id-kp-serverAuth. 1856 Note that absence of the EKU extension or a value of 1857 anyExtendedKeyUsage implies absence of constraint on the 1858 certificate's purpose. 1860 14.5 Certificate Compromise 1862 Certificates should be checked for revocation to reduce exposure to 1863 imposture using compromised certificates. 1865 Checking a server certificate against the most recent revocation 1866 list during authentication is not always possible for a client, as 1867 it may not have network access until completion of the 1868 authentication. This problem can be alleviated through the use of 1869 OCSP [RFC2560] during the TLS handshake, as described in [RFC4366]. 1871 14.6 Forward secrecy. 1873 With forward secrecy, revelation of a secret does not compromise 1874 session keys previously negotiated based on that secret. Thus, when 1875 the TLS key exchange algorithm provides forward secrecy, if a TTLS 1876 server certificate's private key is eventually stolen or cracked, 1877 tunneled user password information will remain secure as long as 1878 that certificate is no longer in use. Diffie-Hellman key exchange is 1879 an example of an algorithm that provides forward secrecy. A forward 1880 secrecy algorithm should be considered if attacks against recorded 1881 authentication or data sessions are considered to pose a significant 1882 threat. 1884 14.7 Negotiating-Down Attacks 1886 EAP-TTLS negotiates its own protocol version prior to, and therefore 1887 outside the security established by the TLS tunnel. In principle, 1888 therefore, it is subject to a negotiating-down attack, in which an 1889 intermediary modifies messages in transit to cause a lower version 1890 of the protocol to be agreed upon, each party assuming that the 1891 other does not support as high a version as it actually does. 1893 The version of the EAP-TTLS protocol described in this document is 1894 0, and is therefore not subject to such an attack. However, any new 1895 version of the protocol using a higher number than 0 should define a 1896 mechanism to ensure against such an attack. One such mechanism might 1897 be the TTLS server's reiteration of the protocol version that it 1898 proposed in an AVP within the tunnel, such AVP to be inserted with 1899 M-bit clear even when version 0 is agreed upon. 1901 15. Message Sequences 1903 This section presents EAP-TTLS message sequences for various 1904 negotiation scenarios. These examples do not attempt to exhaustively 1905 depict all possible scenarios. 1907 It is assumed that RADIUS is the AAA carrier protocol both between 1908 access point and TTLS server, and between TTLS server and AAA/H. 1910 EAP packets that are passed unmodified between client and TTLS 1911 server by the access point are indicated as "passthrough". AVPs that 1912 are securely tunneled within the TLS record layer are enclosed in 1913 curly braces ({}). Items that are optional are suffixed with 1914 question mark (?). Items that may appear multiple times are suffixed 1915 with plus sign (+). 1917 15.1 Successful authentication via tunneled CHAP 1919 In this example, the client performs one-way TLS authentication of 1920 the TTLS server. CHAP is used as a tunneled user authentication 1921 mechanism. 1923 client access point TTLS server AAA/H 1924 ------ ------------ ----------- ----- 1926 EAP-Request/Identity 1927 <-------------------- 1929 EAP-Response/Identity 1930 --------------------> 1932 RADIUS Access-Request: 1933 EAP-Response passthrough 1934 --------------------> 1936 RADIUS Access-Challenge: 1937 EAP-Request/TTLS-Start 1938 <-------------------- 1940 EAP-Request passthrough 1941 <-------------------- 1943 EAP-Response/TTLS: 1944 ClientHello 1945 --------------------> 1947 RADIUS Access-Request: 1948 EAP-Response passthrough 1949 --------------------> 1951 RADIUS Access-Challenge: 1952 EAP-Request/TTLS: 1953 ServerHello 1954 Certificate 1955 ServerKeyExchange 1956 ServerHelloDone 1957 <-------------------- 1959 EAP-Request passthrough 1960 <-------------------- 1962 EAP-Response/TTLS: 1963 ClientKeyExchange 1964 ChangeCipherSpec 1965 Finished 1966 --------------------> 1967 RADIUS Access-Request: 1968 EAP-Response passthrough 1969 --------------------> 1971 RADIUS Access-Challenge: 1972 EAP-Request/TTLS: 1973 ChangeCipherSpec 1974 Finished 1975 <-------------------- 1977 EAP-Request passthrough 1978 <-------------------- 1980 EAP-Response/TTLS: 1981 {User-Name} 1982 {CHAP-Challenge} 1983 {CHAP-Password} 1984 --------------------> 1986 RADIUS Access-Request: 1987 EAP-Response passthrough 1988 --------------------> 1990 RADIUS Access-Request: 1991 User-Name 1992 CHAP-Challenge 1993 CHAP-Password 1994 --------------------> 1996 RADIUS Access-Accept 1997 <-------------------- 1999 RADIUS Access-Accept: 2000 EAP-Success 2001 <-------------------- 2003 EAP-Success 2004 <-------------------- 2006 15.2 Successful authentication via tunneled EAP/MD5-Challenge 2008 In this example, the client performs one-way TLS authentication of 2009 the TTLS server and EAP/MD5-Challenge is used as a tunneled user 2010 authentication mechanism. 2012 client access point TTLS server AAA/H 2013 ------ ------------ ----------- ----- 2015 EAP-Request/Identity 2016 <-------------------- 2017 EAP-Response/Identity 2018 --------------------> 2020 RADIUS Access-Request: 2021 EAP-Response passthrough 2022 --------------------> 2024 RADIUS Access-Challenge: 2025 EAP-Request/TTLS-Start 2026 <-------------------- 2028 EAP-Request passthrough 2029 <-------------------- 2031 EAP-Response/TTLS: 2032 ClientHello 2033 --------------------> 2035 RADIUS Access-Request: 2036 EAP-Response passthrough 2037 --------------------> 2039 RADIUS Access-Challenge: 2040 EAP-Request/TTLS: 2041 ServerHello 2042 Certificate 2043 ServerKeyExchange 2044 ServerHelloDone 2045 <-------------------- 2047 EAP-Request passthrough 2048 <-------------------- 2050 EAP-Response/TTLS: 2051 ClientKeyExchange 2052 ChangeCipherSpec 2053 Finished 2054 --------------------> 2056 RADIUS Access-Request: 2057 EAP-Response passthrough 2058 --------------------> 2060 RADIUS Access-Challenge: 2061 EAP-Request/TTLS: 2062 ChangeCipherSpec 2063 Finished 2064 <-------------------- 2066 EAP-Request passthrough 2067 <-------------------- 2068 EAP-Response/TTLS: 2069 {EAP-Response/Identity} 2070 --------------------> 2072 RADIUS Access-Request: 2073 EAP-Response passthrough 2074 --------------------> 2076 RADIUS Access-Request: 2077 EAP-Response/Identity 2078 --------------------> 2080 RADIUS Access-Challenge 2081 EAP-Request/ 2082 MD5-Challenge 2083 <-------------------- 2085 RADIUS Access-Challenge: 2086 EAP-Request/TTLS: 2087 {EAP-Request/MD5-Challenge} 2088 <-------------------- 2090 EAP-Request passthrough 2091 <-------------------- 2093 EAP-Response/TTLS: 2094 {EAP-Response/MD5-Challenge} 2095 --------------------> 2097 RADIUS Access-Request: 2098 EAP-Response passthrough 2099 --------------------> 2101 RADIUS Access-Challenge 2102 EAP-Response/ 2103 MD5-Challenge 2104 --------------------> 2106 RADIUS Access-Accept 2107 <-------------------- 2109 RADIUS Access-Accept: 2110 EAP-Success 2111 <-------------------- 2113 EAP-Success 2114 <-------------------- 2116 15.3 Successful session resumption 2118 In this example, the client and server resume a previous TLS 2119 session. The ID of the session to be resumed is sent as part of the 2120 ClientHello, and the server agrees to resume this session by sending 2121 the same session ID as part of ServerHello. 2123 client access point TTLS server AAA/H 2124 ------ ------------ ----------- ----- 2126 EAP-Request/Identity 2127 <-------------------- 2129 EAP-Response/Identity 2130 --------------------> 2132 RADIUS Access-Request: 2133 EAP-Response passthrough 2134 --------------------> 2136 RADIUS Access-Challenge: 2137 EAP-Request/TTLS-Start 2138 <-------------------- 2140 EAP-Request passthrough 2141 <-------------------- 2143 EAP-Response/TTLS: 2144 ClientHello 2145 --------------------> 2147 RADIUS Access-Request: 2148 EAP-Response passthrough 2149 --------------------> 2151 RADIUS Access-Challenge: 2152 EAP-Request/TTLS: 2153 ServerHello 2154 ChangeCipherSpec 2155 Finished 2156 <-------------------- 2158 EAP-Request passthrough 2159 <-------------------- 2161 EAP-Response/TTLS: 2162 ChangeCipherSpec 2163 Finished 2164 --------------------> 2165 RADIUS Access-Request: 2166 EAP-Response passthrough 2167 --------------------> 2169 RADIUS Access-Accept: 2170 EAP-Success 2171 <-------------------- 2173 EAP-Success 2174 <-------------------- 2176 16. IANA Considerations 2178 IANA has assigned the number 21 (decimal) as the method type of the 2179 EAP-TTLS protocol. Mechanisms for defining new RADIUS and Diameter 2180 AVPs and AVP values are outlined in [RFC2865] and [RFC3588], 2181 respectively. No additional IANA registrations are specifically 2182 contemplated in this document. 2184 Section 11 of this document specifies how certain authentication 2185 mechanisms may be performed within the secure tunnel established by 2186 EAP-TTLS. New mechanisms and other functions MAY also be performed 2187 within this tunnel. Where such extensions use AVPs that are not 2188 vendor-specific, their semantics must be specified in new RFCs; that 2189 is, there are TTLS-specific processing rules related to the use of 2190 each individual AVP, even though such AVPs have already been defined 2191 for RADIUS or DIAMETER. 2193 This specification requires the creation of a new registry -- EAP- 2194 TTLS AVP Usage -- to be managed by IANA, listing each non-vendor- 2195 specific RADIUS/Diameter AVP that has been defined for use within 2196 EAP-TTLS, along with a reference to the RFC or other document which 2197 specifies its semantics. The initial list of AVPs shall be those 2198 listed in section 13 of this document. The purpose of this registry 2199 is to avoid potential ambiguity resulting from the same AVP being 2200 utilized in different functional contexts. This registry does not 2201 assign numbers to AVPs, as the AVP numbers are assigned out of the 2202 RADIUS and Diameter namespaces as outlined in [RFC2865] and 2203 [RFC3588]. Only top-level AVPs -- that is, AVPs not encapsulated 2204 within Grouped AVPs -- will be registered. AVPs should be added to 2205 this registry based on IETF Consensus as defined in [RFC2434]. 2207 17. Acknowledgements 2209 Thanks to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen 2210 Hanna, Ryan Hurst, Avi Lior and Gabriel Montenegro for careful 2211 reviews and useful comments. 2213 18. References 2215 18.1 Normative References 2217 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol 2218 (PPP)", STD 51, RFC 1661, July 1994. 2220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2221 Requirement Levels", BCP 14, RFC 2119, March 1997. 2223 [RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version 2224 1.0", RFC 2246, November 1998. 2226 [RFC2433] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", 2227 RFC 2433, October 1998. 2229 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 2230 an IANA Considerations Section in RFCs", BCP 26, RFC 2231 2434, October 1998. 2233 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS 2234 Attributes", RFC 2548, March 1999. 2236 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 2237 RFC 2759, January 2000. 2239 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 2240 "Remote Authentication Dial In User Service (RADIUS)", 2241 RFC 2865, June 2000. 2243 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced 2244 by an On-line Database", RFC 3232, January 2002. 2246 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and 2247 J. Arkko, "Diameter Base Protocol", RFC 3588, September 2248 2003. 2250 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 2251 H. Levkowetz, "PPP Extensible Authentication Protocol 2252 (EAP)", RFC 3748, June 2004. 2254 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 2255 Network Access Identifier", RFC 4282, December 2005. 2257 [RFC4346] Dierks, T., and E. Rescorla, "The Transport Layer 2258 Security (TLS) Protocol Version 1.1", RFC 4346, April 2259 2006. 2261 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP TLS 2262 Authentication Protocol", RFC 5216, March 2008. 2264 [KEYFRAME] Aboba, B., Simon, D. and P. Eronen, "Extensible 2265 Authentication Protocol (EAP) Key Management 2266 Framework", Internet Draft (work in progress), draft- 2267 ietf-eap-keying-22.txt, November 2007. 2269 18.2 Informative References 2271 [802.1X] Institute of Electrical and Electronics Engineers, 2272 "Local and Metropolitan Area Networks: Port-Based 2273 Network Access Control", IEEE Standard 802.1X-2004, 2274 December 2004. 2276 [802.11] Institute of Electrical and Electronics Engineers, 2277 "Information technology - Telecommunications and 2278 information exchange between systems - Local and 2279 metropolitan area networks - Specific Requirements Part 2280 11: Wireless LAN Medium Access Control (MAC) and 2281 Physical Layer (PHY) Specifications", IEEE Standard 2282 802.11, 2007. 2284 [TTLS-EXT] Hanna, S, and P. Funk, "Key Agility Extensions for EAP- 2285 TTLSv0", Internet Draft (work in progress), draft- 2286 hanna-eap-ttls-agility-00.txt, September 24, 2007. 2288 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and 2289 C. Adams, "Internet X.509 Public Key Infrastructure: 2290 Online Certificate Status Protocol - OCSP", RFC 2560, 2291 June 1999. 2293 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 2294 X.509 Public Key Infrastructure Certificate and 2295 Certificate Revocation List (CRL) Profile", RFC 3280, 2296 April 2002. 2298 [RFC3766] Orman. H. and P. Hoffman, "Determining Strengths for 2299 Public Keys Used for Exchanging Symmetric Keys", RFC 2300 3766, April 2004. 2302 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 2303 J., and T. Wright, "Transport Layer Security (TLS) 2304 Extensions", RFC 4366, April 2006. 2306 [MITM] Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the- 2307 Middle in Tunneled Authentication", 2308 http://www.saunalahti.fi/~asokan/research/mitm.html, 2309 Nokia Research Center, Finland, October 24 2002. 2311 [SP800-57] National Institute of Standards and Technology, 2312 "Recommendation for Key Management", Special 2313 Publication 800-57, May 2006. 2315 19. Authors' Addresses 2317 Questions about this memo can be directed to: 2319 Paul Funk 2320 43 Linnaean St. 2321 Cambridge, MA 02138 2322 E-mail: PaulFunk@alum.mit.edu 2324 Simon Blake-Wilson 2325 SafeNet 2326 Amstelveenseweg 88-90 2327 1054XV, Amsterdam 2328 The Netherlands 2329 E-mail: sblakewilson@nl.safenet-inc.com 2331 20. Intellectual Property Statement 2333 The IETF takes no position regarding the validity or scope of any 2334 Intellectual Property Rights or other rights that might be claimed 2335 to pertain to the implementation or use of the technology described 2336 in this document or the extent to which any license under such 2337 rights might or might not be available; nor does it represent that 2338 it has made any independent effort to identify any such rights. 2339 Information on the procedures with respect to rights in RFC 2340 documents can be found in BCP 78 and BCP 79. 2342 Copies of IPR disclosures made to the IETF Secretariat and any 2343 assurances of licenses to be made available, or the result of an 2344 attempt made to obtain a general license or permission for the use 2345 of such proprietary rights by implementers or users of this 2346 specification can be obtained from the IETF on-line IPR repository 2347 at http://www.ietf.org/ipr. 2349 The IETF invites any interested party to bring to its attention any 2350 copyrights, patents or patent applications, or other proprietary 2351 rights that may cover technology that may be required to implement 2352 this standard. Please address the information to the IETF at ietf- 2353 ipr@ietf.org. 2355 21. Disclaimer of Validity 2357 This document and the information contained herein are provided on 2358 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2359 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2360 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2361 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2362 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2363 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2364 FOR A PARTICULAR PURPOSE. 2366 22. Copyright Statement 2368 Copyright (C) The IETF Trust (2008). This document is subject to 2369 the rights, licenses and restrictions contained in BCP 78, and 2370 except as set forth therein, the authors retain all their rights. 2372 23. Acknowledgement 2374 Funding for the RFC Editor function is currently provided by the 2375 Internet Society.