7 Network Working Group P. Funk
8 Request for Comments: 5281 Unaffiliated
9 Category: Informational S. Blake-Wilson
14 Extensible Authentication Protocol Tunneled Transport Layer Security
15 Authenticated Protocol Version 0 (EAP-TTLSv0)
19 This memo provides information for the Internet community. It does
20 not specify an Internet standard of any kind. Distribution of this
25 EAP-TTLS is an EAP (Extensible Authentication Protocol) method that
26 encapsulates a TLS (Transport Layer Security) session, consisting of
27 a handshake phase and a data phase. During the handshake phase, the
28 server is authenticated to the client (or client and server are
29 mutually authenticated) using standard TLS procedures, and keying
30 material is generated in order to create a cryptographically secure
31 tunnel for information exchange in the subsequent data phase. During
32 the data phase, the client is authenticated to the server (or client
33 and server are mutually authenticated) using an arbitrary
34 authentication mechanism encapsulated within the secure tunnel. The
35 encapsulated authentication mechanism may itself be EAP, or it may be
36 another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-
37 CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication
38 protocols to be used against existing authentication databases, while
39 protecting the security of these legacy protocols against
40 eavesdropping, man-in-the-middle, and other attacks. The data phase
41 may also be used for additional, arbitrary data exchange.
58 Funk & Blake-Wilson Informational [Page 1]
60 RFC 5281 EAP-TTLSv0 August 2008
65 1. Introduction ....................................................4
66 2. Motivation ......................................................5
67 3. Requirements Language ...........................................7
68 4. Terminology .....................................................7
69 5. Architectural Model .............................................9
70 5.1. Carrier Protocols .........................................10
71 5.2. Security Relationships ....................................10
72 5.3. Messaging .................................................11
73 5.4. Resulting Security ........................................12
74 6. Protocol Layering Model ........................................12
75 7. EAP-TTLS Overview ..............................................13
76 7.1. Phase 1: Handshake ........................................14
77 7.2. Phase 2: Tunnel ...........................................14
78 7.3. EAP Identity Information ..................................15
79 7.4. Piggybacking ..............................................15
80 7.5. Session Resumption ........................................16
81 7.6. Determining Whether to Enter Phase 2 ......................17
82 7.7. TLS Version ...............................................18
83 7.8. Use of TLS PRF ............................................18
84 8. Generating Keying Material .....................................19
85 9. EAP-TTLS Protocol ..............................................20
86 9.1. Packet Format .............................................20
87 9.2. EAP-TTLS Start Packet .....................................21
88 9.2.1. Version Negotiation ................................21
89 9.2.2. Fragmentation ......................................22
90 9.2.3. Acknowledgement Packets ............................22
91 10. Encapsulation of AVPs within the TLS Record Layer .............23
92 10.1. AVP Format ...............................................23
93 10.2. AVP Sequences ............................................25
94 10.3. Guidelines for Maximum Compatibility with AAA Servers ....25
95 11. Tunneled Authentication .......................................26
96 11.1. Implicit Challenge .......................................26
97 11.2. Tunneled Authentication Protocols ........................27
98 11.2.1. EAP ...............................................27
99 11.2.2. CHAP ..............................................29
100 11.2.3. MS-CHAP ...........................................30
101 11.2.4. MS-CHAP-V2 ........................................30
102 11.2.5. PAP ...............................................32
103 11.3. Performing Multiple Authentications ......................33
104 11.4. Mandatory Tunneled Authentication Support ................34
105 11.5. Additional Suggested Tunneled Authentication Support .....34
106 12. Keying Framework ..............................................35
107 12.1. Session-Id ...............................................35
108 12.2. Peer-Id ..................................................35
109 12.3. Server-Id ................................................35
110 13. AVP Summary ...................................................35
114 Funk & Blake-Wilson Informational [Page 2]
116 RFC 5281 EAP-TTLSv0 August 2008
119 14. Security Considerations .......................................36
120 14.1. Security Claims ..........................................36
121 14.1.1. Authentication Mechanism ..........................36
122 14.1.2. Ciphersuite Negotiation ...........................37
123 14.1.3. Mutual Authentication .............................37
124 14.1.4. Integrity Protection ..............................37
125 14.1.5. Replay Protection .................................37
126 14.1.6. Confidentiality ...................................37
127 14.1.7. Key Derivation ....................................37
128 14.1.8. Key Strength ......................................37
129 14.1.9. Dictionary Attack Protection ......................38
130 14.1.10. Fast Reconnect ...................................38
131 14.1.11. Cryptographic Binding ............................38
132 14.1.12. Session Independence .............................38
133 14.1.13. Fragmentation ....................................38
134 14.1.14. Channel Binding ..................................38
135 14.2. Client Anonymity .........................................38
136 14.3. Server Trust .............................................39
137 14.4. Certificate Validation ...................................39
138 14.5. Certificate Compromise ...................................40
139 14.6. Forward Secrecy ..........................................40
140 14.7. Negotiating-Down Attacks .................................40
141 15. Message Sequences .............................................41
142 15.1. Successful Authentication via Tunneled CHAP ..............41
143 15.2. Successful Authentication via Tunneled
144 EAP/MD5-Challenge ........................................43
145 15.3. Successful Session Resumption ............................46
146 16. IANA Considerations ...........................................47
147 17. Acknowledgements ..............................................48
148 18. References ....................................................48
149 18.1. Normative References .....................................48
150 18.2. Informative References ...................................49
170 Funk & Blake-Wilson Informational [Page 3]
172 RFC 5281 EAP-TTLSv0 August 2008
177 Extensible Authentication Protocol (EAP) [RFC3748] defines a standard
178 message exchange that allows a server to authenticate a client using
179 an authentication method agreed upon by both parties. EAP may be
180 extended with additional authentication methods by registering such
181 methods with IANA or by defining vendor-specific methods.
183 Transport Layer Security (TLS) [RFC4346] is an authentication
184 protocol that provides for client authentication of a server or
185 mutual authentication of client and server, as well as secure
186 ciphersuite negotiation and key exchange between the parties. TLS
187 has been defined as an authentication protocol for use within EAP
190 Other authentication protocols are also widely deployed. These are
191 typically password-based protocols, and there is a large installed
192 base of support for these protocols in the form of credential
193 databases that may be accessed by RADIUS [RFC2865], Diameter
194 [RFC3588], or other AAA servers. These include non-EAP protocols
195 such as PAP [RFC1661], CHAP [RFC1661], MS-CHAP [RFC2433], or MS-
196 CHAP-V2 [RFC2759], as well as EAP protocols such as MD5-Challenge
199 EAP-TTLS is an EAP method that provides functionality beyond what is
200 available in EAP-TLS. EAP-TTLS has been widely deployed and this
201 specification documents what existing implementations do. It has
202 some limitations and vulnerabilities, however. These are addressed
203 in EAP-TTLS extensions and ongoing work in the creation of
204 standardized tunneled EAP methods at the IETF. Users of EAP-TTLS are
205 strongly encouraged to consider these in their deployments.
207 In EAP-TLS, a TLS handshake is used to mutually authenticate a client
208 and server. EAP-TTLS extends this authentication negotiation by
209 using the secure connection established by the TLS handshake to
210 exchange additional information between client and server. In EAP-
211 TTLS, the TLS authentication may be mutual; or it may be one-way, in
212 which only the server is authenticated to the client. The secure
213 connection established by the handshake may then be used to allow the
214 server to authenticate the client using existing, widely deployed
215 authentication infrastructures. The authentication of the client may
216 itself be EAP, or it may be another authentication protocol such as
217 PAP, CHAP, MS-CHAP or MS-CHAP-V2.
219 Thus, EAP-TTLS allows legacy password-based authentication protocols
220 to be used against existing authentication databases, while
221 protecting the security of these legacy protocols against
222 eavesdropping, man-in-the-middle, and other attacks.
226 Funk & Blake-Wilson Informational [Page 4]
228 RFC 5281 EAP-TTLSv0 August 2008
231 EAP-TTLS also allows client and server to establish keying material
232 for use in the data connection between the client and access point.
233 The keying material is established implicitly between client and
234 server based on the TLS handshake.
236 In EAP-TTLS, client and server communicate using attribute-value
237 pairs encrypted within TLS. This generality allows arbitrary
238 functions beyond authentication and key exchange to be added to the
239 EAP negotiation, in a manner compatible with the AAA infrastructure.
241 The main limitation of EAP-TTLS is that its base version lacks
242 support for cryptographic binding between the outer and inner
243 authentication. Please refer to Section 14.1.11 for details and the
244 conditions where this vulnerability exists. It should be noted that
245 an extension for EAP-TTLS [TTLS-EXT] fixed this vulnerability. Users
246 of EAP-TTLS are strongly encouraged to adopt this extension.
250 Most password-based protocols in use today rely on a hash of the
251 password with a random challenge. Thus, the server issues a
252 challenge, the client hashes that challenge with the password and
253 forwards a response to the server, and the server validates that
254 response against the user's password retrieved from its database.
255 This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5-
256 Challenge, and EAP/One-Time Password.
258 An issue with such an approach is that an eavesdropper that observes
259 both challenge and response may be able to mount a dictionary attack,
260 in which random passwords are tested against the known challenge to
261 attempt to find one which results in the known response. Because
262 passwords typically have low entropy, such attacks can in practice
263 easily discover many passwords.
265 While this vulnerability has long been understood, it has not been of
266 great concern in environments where eavesdropping attacks are
267 unlikely in practice. For example, users with wired or dial-up
268 connections to their service providers have not been concerned that
269 such connections may be monitored. Users have also been willing to
270 entrust their passwords to their service providers, or at least to
271 allow their service providers to view challenges and hashed responses
272 which are then forwarded to their home authentication servers using,
273 for example, proxy RADIUS, without fear that the service provider
274 will mount dictionary attacks on the observed credentials. Because a
275 user typically has a relationship with a single service provider,
276 such trust is entirely manageable.
282 Funk & Blake-Wilson Informational [Page 5]
284 RFC 5281 EAP-TTLSv0 August 2008
287 With the advent of wireless connectivity, however, the situation
288 changes dramatically:
290 - Wireless connections are considerably more susceptible to
291 eavesdropping and man-in-the-middle attacks. These attacks may
292 enable dictionary attacks against low-entropy passwords. In
293 addition, they may enable channel hijacking, in which an attacker
294 gains fraudulent access by seizing control of the communications
295 channel after authentication is complete.
297 - Existing authentication protocols often begin by exchanging the
298 client's username in the clear. In the context of eavesdropping
299 on the wireless channel, this can compromise the client's
300 anonymity and locational privacy.
302 - Often in wireless networks, the access point does not reside in
303 the administrative domain of the service provider with which the
304 user has a relationship. For example, the access point may reside
305 in an airport, coffee shop, or hotel in order to provide public
306 access via 802.11 [802.11]. Even if password authentications are
307 protected in the wireless leg, they may still be susceptible to
308 eavesdropping within the untrusted wired network of the access
311 - In the traditional wired world, the user typically intentionally
312 connects with a particular service provider by dialing an
313 associated phone number; that service provider may be required to
314 route an authentication to the user's home domain. In a wireless
315 network, however, the user does not get to choose an access
316 domain, and must connect with whichever access point is nearby;
317 providing for the routing of the authentication from an arbitrary
318 access point to the user's home domain may pose a challenge.
320 Thus, the authentication requirements for a wireless environment that
321 EAP-TTLS attempts to address can be summarized as follows:
323 - Legacy password protocols must be supported, to allow easy
324 deployment against existing authentication databases.
326 - Password-based information must not be observable in the
327 communications channel between the client node and a trusted
328 service provider, to protect the user against dictionary attacks.
330 - The user's identity must not be observable in the communications
331 channel between the client node and a trusted service provider, to
332 protect the user against surveillance, undesired acquisition of
333 marketing information, and the like.
338 Funk & Blake-Wilson Informational [Page 6]
340 RFC 5281 EAP-TTLSv0 August 2008
343 - The authentication process must result in the distribution of
344 shared keying information to the client and access point to permit
345 encryption and validation of the wireless data connection
346 subsequent to authentication, to secure it against eavesdroppers
347 and prevent channel hijacking.
349 - The authentication mechanism must support roaming among access
350 domains with which the user has no relationship and which will
351 have limited capabilities for routing authentication requests.
353 3. Requirements Language
355 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
356 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
357 document are to be interpreted as described in [RFC2119].
363 Authentication, Authorization, and Accounting - functions that are
364 generally required to control access to a network and support
365 billing and auditing.
369 A network protocol used to communicate with AAA servers; examples
370 include RADIUS and Diameter.
374 A server which performs one or more AAA functions: authenticating
375 a user prior to granting network service, providing authorization
376 (policy) information governing the type of network service the
377 user is to be granted, and accumulating accounting information
382 A AAA server in the user's home domain, where authentication and
383 authorization for that user are administered.
387 A network device providing users with a point of entry into the
388 network, and which may enforce access control and policy based on
389 information returned by a AAA server. Since the access point
390 terminates the server side of the EAP conversation, for the
394 Funk & Blake-Wilson Informational [Page 7]
396 RFC 5281 EAP-TTLSv0 August 2008
399 purposes of this document it is therefore equivalent to the
400 "authenticator", as used in the EAP specification [RFC3748].
401 Since the access point acts as a client to a AAA server, for the
402 purposes of this document it is therefore also equivalent to the
403 "Network Access Server (NAS)", as used in AAA specifications such
408 The domain, including access points and other devices, that
409 provides users with an initial point of entry into the network;
410 for example, a wireless hot spot.
414 A host or device that connects to a network through an access
415 point. Since it terminates the client side of the EAP
416 conversation, for the purposes of this document, it is therefore
417 equivalent to the "peer", as used in the EAP specification
422 A network and associated devices that are under the administrative
423 control of an entity such as a service provider or the user's home
428 A protocol used to carry data between hosts that are connected
429 within a single network segment; examples include PPP and
434 A Network Access Identifier [RFC4282], normally consisting of the
435 name of the user and, optionally, the user's home realm.
439 A server that is able to route AAA transactions to the appropriate
440 AAA server, possibly in another domain, typically based on the
441 realm portion of an NAI.
445 The optional part of an NAI indicating the domain to which a AAA
446 transaction is to be routed, normally the user's home domain.
450 Funk & Blake-Wilson Informational [Page 8]
452 RFC 5281 EAP-TTLSv0 August 2008
457 An organization (with which a user has a business relationship)
458 that provides network or other services. The service provider may
459 provide the access equipment with which the user connects, may
460 perform authentication or other AAA functions, may proxy AAA
461 transactions to the user's home domain, etc.
465 A AAA server which implements EAP-TTLS. This server may also be
466 capable of performing user authentication, or it may proxy the
467 user authentication to a AAA/H.
471 The person operating the client device. Though the line is often
472 blurred, "user" is intended to refer to the human being who is
473 possessed of an identity (username), password, or other
474 authenticating information, and "client" is intended to refer to
475 the device which makes use of this information to negotiate
476 network access. There may also be clients with no human
477 operators; in this case, the term "user" is a convenient
480 5. Architectural Model
482 The network architectural model for EAP-TTLS usage and the type of
483 security it provides is shown below.
485 +----------+ +----------+ +----------+ +----------+
487 | client |<---->| access |<---->| TTLS AAA |<---->| AAA/H |
488 | | | point | | server | | server |
490 +----------+ +----------+ +----------+ +----------+
492 <---- secure password authentication tunnel --->
494 <---- secure data tunnel ---->
496 The entities depicted above are logical entities and may or may not
497 correspond to separate network components. For example, the TTLS
498 server and AAA/H server might be a single entity; the access point
499 and TTLS server might be a single entity; or, indeed, the functions
500 of the access point, TTLS server and AAA/H server might be combined
501 into a single physical device. The above diagram illustrates the
502 division of labor among entities in a general manner and shows how a
506 Funk & Blake-Wilson Informational [Page 9]
508 RFC 5281 EAP-TTLSv0 August 2008
511 distributed system might be constructed; however, actual systems
512 might be realized more simply.
514 Note also that one or more AAA proxy servers might be deployed
515 between access point and TTLS server, or between TTLS server and
516 AAA/H server. Such proxies typically perform aggregation or are
517 required for realm-based message routing. However, such servers play
518 no direct role in EAP-TTLS and are therefore not shown.
520 5.1. Carrier Protocols
522 The entities shown above communicate with each other using carrier
523 protocols capable of encapsulating EAP. The client and access point
524 communicate typically using a link layer carrier protocol such as PPP
525 or EAPOL (EAP over LAN). The access point, TTLS server, and AAA/H
526 server communicate using a AAA carrier protocol such as RADIUS or
529 EAP, and therefore EAP-TTLS, must be initiated via the carrier
530 protocol between client and access point. In PPP or EAPOL, for
531 example, EAP is initiated when the access point sends an EAP-
532 Request/Identity packet to the client.
534 The keying material used to encrypt and authenticate the data
535 connection between the client and access point is developed
536 implicitly between the client and TTLS server as a result of the
537 EAP-TTLS negotiation. This keying material must be communicated to
538 the access point by the TTLS server using the AAA carrier protocol.
540 5.2. Security Relationships
542 The client and access point have no pre-existing security
545 The access point, TTLS server, and AAA/H server are each assumed to
546 have a pre-existing security association with the adjacent entity
547 with which it communicates. With RADIUS, for example, this is
548 achieved using shared secrets. It is essential for such security
549 relationships to permit secure key distribution.
551 The client and AAA/H server have a security relationship based on the
552 user's credentials such as a password.
554 The client and TTLS server may have a one-way security relationship
555 based on the TTLS server's possession of a private key guaranteed by
556 a CA certificate which the user trusts, or may have a mutual security
557 relationship based on certificates for both parties.
562 Funk & Blake-Wilson Informational [Page 10]
564 RFC 5281 EAP-TTLSv0 August 2008
569 The client and access point initiate an EAP conversation to negotiate
570 the client's access to the network. Typically, the access point
571 issues an EAP-Request/Identity to the client, which responds with an
572 EAP-Response/Identity. Note that the client need not include the
573 user's actual identity in this EAP-Response/Identity packet other
574 than for routing purposes (e.g., realm information; see Section 7.3
575 and [RFC3748], Section 5.1); the user's actual identity need not be
576 transmitted until an encrypted channel has been established.
578 The access point now acts as a passthrough device, allowing the TTLS
579 server to negotiate EAP-TTLS with the client directly.
581 During the first phase of the negotiation, the TLS handshake protocol
582 is used to authenticate the TTLS server to the client and,
583 optionally, to authenticate the client to the TTLS server, based on
584 public/private key certificates. As a result of the handshake,
585 client and TTLS server now have shared keying material and an agreed
586 upon TLS record layer cipher suite with which to secure subsequent
587 EAP-TTLS communication.
589 During the second phase of negotiation, client and TTLS server use
590 the secure TLS record layer channel established by the TLS handshake
591 as a tunnel to exchange information encapsulated in attribute-value
592 pairs, to perform additional functions such as authentication (one-
593 way or mutual), validation of client integrity and configuration,
594 provisioning of information required for data connectivity, etc.
596 If a tunneled client authentication is performed, the TTLS server
597 de-tunnels and forwards the authentication information to the AAA/H.
598 If the AAA/H issues a challenge, the TTLS server tunnels the
599 challenge information to the client. The AAA/H server may be a
600 legacy device and needs to know nothing about EAP-TTLS; it only needs
601 to be able to authenticate the client based on commonly used
602 authentication protocols.
604 Keying material for the subsequent data connection between client and
605 access point (Master Session Key / Extended Master Session Key
606 (MSK/EMSK); see Section 8) is generated based on secret information
607 developed during the TLS handshake between client and TTLS server.
608 At the conclusion of a successful authentication, the TTLS server may
609 transmit this keying material to the access point, encrypted based on
610 the existing security associations between those devices (e.g.,
613 The client and access point now share keying material that they can
614 use to encrypt data traffic between them.
618 Funk & Blake-Wilson Informational [Page 11]
620 RFC 5281 EAP-TTLSv0 August 2008
623 5.4. Resulting Security
625 As the diagram above indicates, EAP-TTLS allows user identity and
626 password information to be securely transmitted between client and
627 TTLS server, and generates keying material to allow network data
628 subsequent to authentication to be securely transmitted between
629 client and access point.
631 6. Protocol Layering Model
633 EAP-TTLS packets are encapsulated within EAP, and EAP in turn
634 requires a carrier protocol to transport it. EAP-TTLS packets
635 themselves encapsulate TLS, which is then used to encapsulate
636 attribute-value pairs (AVPs) which may carry user authentication or
637 other information. Thus, EAP-TTLS messaging can be described using a
638 layered model, where each layer is encapsulated by the layer beneath
639 it. The following diagram clarifies the relationship between
642 +-----------------------------------------------------------+
643 | AVPs, including authentication (PAP, CHAP, MS-CHAP, etc.) |
644 +-----------------------------------------------------------+
646 +-----------------------------------------------------------+
648 +-----------------------------------------------------------+
650 +-----------------------------------------------------------+
651 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
652 +-----------------------------------------------------------+
654 When the user authentication protocol is itself EAP, the layering is
657 +-----------------------------------------------------------+
658 | EAP Method (MD-Challenge, etc.) |
659 +-----------------------------------------------------------+
660 | AVPs, including EAP |
661 +-----------------------------------------------------------+
663 +-----------------------------------------------------------+
665 +-----------------------------------------------------------+
667 +-----------------------------------------------------------+
668 | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
669 +-----------------------------------------------------------+
674 Funk & Blake-Wilson Informational [Page 12]
676 RFC 5281 EAP-TTLSv0 August 2008
679 Methods for encapsulating EAP within carrier protocols are already
680 defined. For example, PPP [RFC1661] or EAPOL [802.1X] may be used to
681 transport EAP between client and access point; RADIUS [RFC2865] or
682 Diameter [RFC3588] are used to transport EAP between access point and
687 A EAP-TTLS negotiation comprises two phases: the TLS handshake phase
688 and the TLS tunnel phase.
690 During phase 1, TLS is used to authenticate the TTLS server to the
691 client and, optionally, the client to the TTLS server. Phase 1
692 results in the activation of a cipher suite, allowing phase 2 to
693 proceed securely using the TLS record layer. (Note that the type and
694 degree of security in phase 2 depends on the cipher suite negotiated
695 during phase 1; if the null cipher suite is negotiated, there will be
698 During phase 2, the TLS record layer is used to tunnel information
699 between client and TTLS server to perform any of a number of
700 functions. These might include user authentication, client integrity
701 validation, negotiation of data communication security capabilities,
702 key distribution, communication of accounting information, etc.
703 Information between client and TTLS server is exchanged via
704 attribute-value pairs (AVPs) compatible with RADIUS and Diameter;
705 thus, any type of function that can be implemented via such AVPs may
708 EAP-TTLS specifies how user authentication may be performed during
709 phase 2. The user authentication may itself be EAP, or it may be a
710 legacy protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Phase 2
711 user authentication may not always be necessary, since the user may
712 already have been authenticated via the mutual authentication option
713 of the TLS handshake protocol.
715 Functions other than authentication MAY also be performed during
716 phase 2. This document does not define any such functions; however,
717 any organization or standards body is free to specify how additional
718 functions may be performed through the use of appropriate AVPs.
720 EAP-TTLS specifies how keying material for the data connection
721 between client and access point is generated. The keying material is
722 developed implicitly between client and TTLS server based on the
723 results of the TLS handshake; the TTLS server will communicate the
724 keying material to the access point over the carrier protocol.
730 Funk & Blake-Wilson Informational [Page 13]
732 RFC 5281 EAP-TTLSv0 August 2008
735 7.1. Phase 1: Handshake
737 In phase 1, the TLS handshake protocol is used to authenticate the
738 TTLS server to the client and, optionally, to authenticate the client
741 The TTLS server initiates the EAP-TTLS method with an EAP-TTLS/Start
742 packet, which is an EAP-Request with Type = EAP-TTLS and the S
743 (Start) bit set. This indicates to the client that it should begin
744 the TLS handshake by sending a ClientHello message.
746 EAP packets continue to be exchanged between client and TTLS server
747 to complete the TLS handshake, as described in [RFC5216]. Phase 1 is
748 completed when the client and TTLS server exchange ChangeCipherSpec
749 and Finished messages. At this point, additional information may be
752 As part of the TLS handshake protocol, the TTLS server will send its
753 certificate along with a chain of certificates leading to the
754 certificate of a trusted CA. The client will need to be configured
755 with the certificate of the trusted CA in order to perform the
758 If certificate-based authentication of the client is desired, the
759 client must have been issued a certificate and must have the private
760 key associated with that certificate.
764 In phase 2, the TLS record layer is used to securely tunnel
765 information between client and TTLS server. This information is
766 encapsulated in sequences of attribute-value pairs (AVPs), whose use
767 and format are described in later sections.
769 Any type of information may be exchanged during phase 2, according to
770 the requirements of the system. (It is expected that applications
771 utilizing EAP-TTLS will specify what information must be exchanged
772 and therefore which AVPs must be supported.) The client begins the
773 phase 2 exchange by encoding information in a sequence of AVPs,
774 passing this sequence to the TLS record layer for encryption, and
775 sending the resulting data to the TTLS server.
777 The TTLS server recovers the AVPs in clear text from the TLS record
778 layer. If the AVP sequence includes authentication information, it
779 forwards this information to the AAA/H server using the AAA carrier
780 protocol. Note that the EAP-TTLS and AAA/H servers may be one and
781 the same; in which case, it simply processes the information locally.
786 Funk & Blake-Wilson Informational [Page 14]
788 RFC 5281 EAP-TTLSv0 August 2008
791 The TTLS server may respond with its own sequence of AVPs. The TTLS
792 server passes the AVP sequence to the TLS record layer for encryption
793 and sends the resulting data to the client. For example, the TTLS
794 server may forward an authentication challenge received from the
797 This process continues until the AAA/H either accepts or rejects the
798 client, resulting in the TTLS server completing the EAP-TTLS
799 negotiation and indicating success or failure to the encapsulating
800 EAP protocol (which normally results in a final EAP-Success or EAP-
801 Failure being sent to the client).
803 The TTLS server distributes data connection keying information and
804 other authorization information to the access point in the same AAA
805 carrier protocol message that carries the final EAP-Success or other
808 7.3. EAP Identity Information
810 The identity of the user is provided during phase 2, where it is
811 protected by the TLS tunnel. However, prior to beginning the EAP-
812 TTLS authentication, the client will typically issue an EAP-
813 Response/Identity packet as part of the EAP protocol, containing a
814 username in clear text. To preserve user anonymity against
815 eavesdropping, this packet specifically SHOULD NOT include the actual
816 name of the user; instead, it SHOULD use a blank or placeholder such
817 as "anonymous". However, this privacy constraint is not intended to
818 apply to any information within the EAP-Response/Identity that is
819 required for routing; thus, the EAP-Response/Identity packet MAY
820 include the name of the realm of a trusted provider to which EAP-TTLS
821 packets should be forwarded; for example, "anonymous@myisp.com".
823 Note that at the time the initial EAP-Response/Identity packet is
824 sent the EAP method is yet to be negotiated. If, in addition to EAP-
825 TTLS, the client is willing to negotiate use of EAP methods that do
826 not support user anonymity, then the client MAY include the name of
827 the user in the EAP-Response/Identity to meet the requirements of the
828 other candidate EAP methods.
832 While it is convenient to describe EAP-TTLS messaging in terms of two
833 phases, it is sometimes required that a single EAP-TTLS packet
834 contain both phase 1 and phase 2 TLS messages.
836 Such "piggybacking" occurs when the party that completes the
837 handshake also has AVPs to send. For example, when negotiating a
838 resumed TLS session, the TTLS server sends its ChangeCipherSpec and
842 Funk & Blake-Wilson Informational [Page 15]
844 RFC 5281 EAP-TTLSv0 August 2008
847 Finished messages first, then the client sends its own
848 ChangeCipherSpec and Finished messages to conclude the handshake. If
849 the client has authentication or other AVPs to send to the TTLS
850 server, it MUST tunnel those AVPs within the same EAP-TTLS packet
851 immediately following its Finished message. If the client fails to
852 do this, the TTLS server will incorrectly assume that the client has
853 no AVPs to send, and the outcome of the negotiation could be
856 7.5. Session Resumption
858 When a client and TTLS server that have previously negotiated an
859 EAP-TTLS session begin a new EAP-TTLS negotiation, the client and
860 TTLS server MAY agree to resume the previous session. This
861 significantly reduces the time required to establish the new session.
862 This could occur when the client connects to a new access point, or
863 when an access point requires reauthentication of a connected client.
865 Session resumption is accomplished using the standard TLS mechanism.
866 The client signals its desire to resume a session by including the
867 session ID of the session it wishes to resume in the ClientHello
868 message; the TTLS server signals its willingness to resume that
869 session by echoing that session ID in its ServerHello message.
871 If the TTLS server elects not to resume the session, it simply does
872 not echo the session ID, causing a new session to be negotiated.
873 This could occur if the TTLS server is configured not to resume
874 sessions, if it has not retained the requested session's state, or if
875 the session is considered stale. A TTLS server may consider the
876 session stale based on its own configuration, or based on session-
877 limiting information received from the AAA/H (e.g., the RADIUS
878 Session-Timeout attribute).
880 Tunneled authentication is specifically not performed for resumed
881 sessions; the presumption is that the knowledge of the master secret
882 (as evidenced by the ability to resume the session) is authentication
883 enough. This allows session resumption to occur without any
884 messaging between the TTLS server and the AAA/H. If periodic
885 reauthentication to the AAA/H is desired, the AAA/H must indicate
886 this to the TTLS server when the original session is established, for
887 example, using the RADIUS Session-Timeout attribute.
889 The client MAY send other AVPs in its first phase 2 message of a
890 session resumption, to initiate non-authentication functions. If it
891 does not, the TTLS server, at its option, MAY send AVPs to the client
892 to initiate non-authentication functions, or MAY simply complete the
893 EAP-TTLS negotiation and indicate success or failure to the
894 encapsulating EAP protocol.
898 Funk & Blake-Wilson Informational [Page 16]
900 RFC 5281 EAP-TTLSv0 August 2008
903 The TTLS server MUST retain authorization information returned by the
904 AAA/H for use in resumed sessions. A resumed session MUST operate
905 under the same authorizations as the original session, and the TTLS
906 server must be prepared to send the appropriate information back to
907 the access point. Authorization information might include the
908 maximum time for the session, the maximum allowed bandwidth, packet
909 filter information, and the like. The TTLS server is responsible for
910 modifying time values, such as Session-Timeout, appropriately for
911 each resumed session.
913 A TTLS server MUST NOT permit a session to be resumed if that session
914 did not result in a successful authentication of the user during
915 phase 2. The consequence of incorrectly implementing this aspect of
916 session resumption would be catastrophic; any attacker could easily
917 gain network access by first initiating a session that succeeds in
918 the TLS handshake but fails during phase 2 authentication, and then
919 resuming that session.
921 [Implementation note: Toolkits that implement TLS often cache
922 resumable TLS sessions automatically. Implementers must take care to
923 override such automatic behavior, and prevent sessions from being
924 cached for possible resumption until the user has been positively
925 authenticated during phase 2.]
927 7.6. Determining Whether to Enter Phase 2
929 Entering phase 2 is optional, and may be initiated by either client
930 or TTLS server. If no further authentication or other information
931 exchange is required upon completion of phase 1, it is possible to
932 successfully complete the EAP-TTLS negotiation without ever entering
933 phase 2 or tunneling any AVPs.
935 Scenarios in which phase 2 is never entered include:
937 - Successful session resumption, with no additional information
940 - Authentication of the client via client certificate during phase
941 1, with no additional authentication or information exchange
944 The client always has the first opportunity to initiate phase 2 upon
945 completion of phase 1. If the client has no AVPs to send, it either
946 sends an Acknowledgement (see Section 9.2.3) if the TTLS server sends
947 the final phase 1 message, or simply does not piggyback a phase 2
948 message when it issues the final phase 1 message (as will occur
949 during session resumption).
954 Funk & Blake-Wilson Informational [Page 17]
956 RFC 5281 EAP-TTLSv0 August 2008
959 If the client does not initiate phase 2, the TTLS server, at its
960 option, may either complete the EAP-TTLS negotiation without entering
961 phase 2 or initiate phase 2 by tunneling AVPs to the client.
963 For example, suppose a successful session resumption occurs in phase
964 1. The following sequences are possible:
966 - Neither the client nor TTLS server has additional information to
967 exchange. The client completes phase 1 without piggybacking phase
968 2 AVPs, and the TTLS server indicates success to the encapsulating
969 EAP protocol without entering phase 2.
971 - The client has no additional information to exchange, but the TTLS
972 server does. The client completes phase 1 without piggybacking
973 phase 2 AVPs, but the TTLS server extends the EAP-TTLS negotiation
974 into phase 2 by tunneling AVPs in its next EAP-TTLS message.
976 - The client has additional information to exchange, and piggybacks
977 phase 2 AVPs with its final phase 1 message, thus extending the
978 negotiation into phase 2.
982 TLS version 1.0 [RFC2246], 1.1 [RFC4346], or any subsequent version
983 MAY be used within EAP-TTLS. TLS provides for its own version
984 negotiation mechanism.
986 For maximum interoperability, EAP-TTLS implementations SHOULD support
991 EAP-TTLSv0 utilizes a pseudo-random function (PRF) to generate keying
992 material (Section 8) and to generate implicit challenge material for
993 certain authentication methods (Section 11.1). The PRF used in these
994 computations is the TLS PRF used in the TLS handshake negotiation
995 that initiates the EAP-TTLS exchange.
997 TLS versions 1.0 [RFC2246] and 1.1 [RFC4346] define the same PRF
998 function, and any EAP-TTLSv0 implementation based on these versions
999 of TLS must use the PRF defined therein. It is expected that future
1000 versions of or extensions to the TLS protocol will permit alternative
1001 PRF functions to be negotiated. If an alternative PRF function is
1002 specified for the underlying TLS version or has been negotiated
1003 during the TLS handshake negotiation, then that alternative PRF
1004 function must be used in EAP-TTLSv0 computations instead of the TLS
1010 Funk & Blake-Wilson Informational [Page 18]
1012 RFC 5281 EAP-TTLSv0 August 2008
1015 The TLS PRF function used in this specification is denoted as
1018 PRF-nn(secret, label, seed)
1022 nn is the number of generated octets
1024 secret is a secret key
1026 label is a string (without null-terminator)
1028 seed is a binary sequence.
1030 The TLS 1.0/1.1 PRF has invariant output regardless of how many
1031 octets are generated. However, it is possible that alternative PRF
1032 functions will include the size of the output sequence as input to
1033 the PRF function; this means generating 32 octets and generating 64
1034 octets from the same input parameters will no longer result in the
1035 first 32 octets being identical. For this reason, the PRF is always
1036 specified with an "nn", indicating the number of generated octets.
1038 8. Generating Keying Material
1040 Upon successful conclusion of an EAP-TTLS negotiation, 128 octets of
1041 keying material are generated and exported for use in securing the
1042 data connection between client and access point. The first 64 octets
1043 of the keying material constitute the MSK, the second 64 octets
1044 constitute the EMSK.
1046 The keying material is generated using the TLS PRF function
1047 [RFC4346], with inputs consisting of the TLS master secret, the
1048 ASCII-encoded constant string "ttls keying material", the TLS client
1049 random, and the TLS server random. The constant string is not null-
1052 Keying Material = PRF-128(SecurityParameters.master_secret, "ttls
1053 keying material", SecurityParameters.client_random +
1054 SecurityParameters.server_random)
1056 MSK = Keying Material [0..63]
1058 EMSK = Keying Material [64..127]
1066 Funk & Blake-Wilson Informational [Page 19]
1068 RFC 5281 EAP-TTLSv0 August 2008
1071 Note that the order of client_random and server_random for EAP-TTLS
1072 is reversed from that of the TLS protocol [RFC4346]. This ordering
1073 follows the key derivation method of EAP-TLS [RFC5216]. Altering the
1074 order of randoms avoids namespace collisions between constant strings
1075 defined for EAP-TTLS and those defined for the TLS protocol.
1077 The TTLS server distributes this keying material to the access point
1078 via the AAA carrier protocol. When RADIUS is the AAA carrier
1079 protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes [RFC2548]
1080 may be used to distribute the first 32 octets and second 32 octets of
1081 the MSK, respectively.
1083 9. EAP-TTLS Protocol
1087 The EAP-TTLS packet format is shown below. The fields are
1088 transmitted left to right.
1091 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
1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1093 | Code | Identifier | Length |
1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1095 | Type | Flags | Message Length
1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1097 Message Length | Data...
1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1101 1 for request, 2 for response.
1104 The Identifier field is one octet and aids in matching responses
1105 with requests. The Identifier field MUST be changed for each
1106 request packet and MUST be echoed in each response packet.
1109 The Length field is two octets and indicates the number of octets
1110 in the entire EAP packet, from the Code field through the Data
1122 Funk & Blake-Wilson Informational [Page 20]
1124 RFC 5281 EAP-TTLSv0 August 2008
1129 +---+---+---+---+---+---+---+---+
1130 | L | M | S | R | R | V |
1131 +---+---+---+---+---+---+---+---+
1137 V = Version (000 for EAP-TTLSv0)
1139 The L bit is set to indicate the presence of the four-octet TLS
1140 Message Length field. The M bit indicates that more fragments are
1141 to come. The S bit indicates a Start message. The V field is set
1142 to the version of EAP-TTLS, and is set to 000 for EAP-TTLSv0.
1145 The Message Length field is four octets, and is present only if
1146 the L bit is set. This field provides the total length of the raw
1147 data message sequence prior to fragmentation.
1150 For all packets other than a Start packet, the Data field consists
1151 of the raw TLS message sequence or fragment thereof. For a Start
1152 packet, the Data field may optionally contain an AVP sequence.
1154 9.2. EAP-TTLS Start Packet
1156 The S bit MUST be set on the first packet sent by the server to
1157 initiate the EAP-TTLS protocol. It MUST NOT be set on any other
1160 This packet MAY contain additional information in the form of AVPs,
1161 which may provide useful hints to the client; for example, the server
1162 identity may be useful to the client to allow it to pick the correct
1163 TLS session ID for session resumption. Each AVP must begin on a
1164 four-octet boundary relative to the first AVP in the sequence. If an
1165 AVP is not a multiple of four octets, it must be padded with zeros to
1166 the next four-octet boundary.
1168 9.2.1. Version Negotiation
1170 The version of EAP-TTLS is negotiated in the first exchange between
1171 server and client. The server sets the highest version number of
1172 EAP-TTLS that it supports in the V field of its Start message (in the
1173 case of EAP-TTLSv0, this is 0). In its first EAP message in
1174 response, the client sets the V field to the highest version number
1178 Funk & Blake-Wilson Informational [Page 21]
1180 RFC 5281 EAP-TTLSv0 August 2008
1183 that it supports that is no higher than the version number offered by
1184 the server. If the client version is not acceptable to the server,
1185 it sends an EAP-Failure to terminate the EAP session. Otherwise, the
1186 version sent by the client is the version of EAP-TTLS that MUST be
1187 used, and both server and client MUST set the V field to that version
1188 number in all subsequent EAP messages.
1190 9.2.2. Fragmentation
1192 Each EAP-TTLS message contains a single leg of a half-duplex
1193 conversation. The EAP carrier protocol (e.g., PPP, EAPOL, RADIUS)
1194 may impose constraints on the length of an EAP message. Therefore it
1195 may be necessary to fragment an EAP-TTLS message across multiple EAP
1198 Each fragment except for the last MUST have the M bit set, to
1199 indicate that more data is to follow; the final fragment MUST NOT
1202 If there are multiple fragments, the first fragment MUST have the L
1203 bit set and include the length of the entire raw message prior to
1204 fragmentation. Fragments other than the first MUST NOT have the L
1205 bit set. Unfragmented messages MAY have the L bit set and include
1206 the length of the message (though this information is redundant).
1208 Upon receipt of a packet with the M bit set, the receiver MUST
1209 transmit an Acknowledgement packet. The receiver is responsible for
1210 reassembly of fragmented packets.
1212 9.2.3. Acknowledgement Packets
1214 An Acknowledgement packet is an EAP-TTLS packet with no additional
1215 data beyond the Flags octet, and with the L, M, and S bits of the
1216 Flags octet set to 0. (Note, however, that the V field MUST still be
1217 set to the appropriate version number.)
1219 An Acknowledgement packet is sent for the following purposes:
1221 - A Fragment Acknowledgement is sent in response to an EAP packet
1224 - When the final EAP packet of the EAP-TTLS negotiation is sent by
1225 the TTLS server, the client must respond with an Acknowledgement
1226 packet, to allow the TTLS server to proceed with the EAP protocol
1227 upon completion of EAP-TTLS (typically by sending or causing to be
1228 sent a final EAP-Success or EAP-Failure to the client).
1234 Funk & Blake-Wilson Informational [Page 22]
1236 RFC 5281 EAP-TTLSv0 August 2008
1239 10. Encapsulation of AVPs within the TLS Record Layer
1241 Subsequent to the TLS handshake, information may be tunneled between
1242 client and TTLS server through the use of attribute-value pairs
1243 (AVPs) encrypted within the TLS record layer.
1245 The AVP format chosen for EAP-TTLS is compatible with the Diameter
1246 AVP format. This does not represent a requirement that Diameter be
1247 supported by any of the devices or servers participating in an EAP-
1248 TTLS negotiation. Use of this format is merely a convenience.
1249 Diameter is a superset of RADIUS and includes the RADIUS attribute
1250 namespace by definition, though it does not limit the size of an AVP
1251 as does RADIUS; RADIUS, in turn, is a widely deployed AAA protocol
1252 and attribute definitions exist for all commonly used password
1253 authentication protocols, including EAP.
1255 Thus, Diameter is not considered normative except as specified in
1256 this document. Specifically, the representation of the Data field of
1257 an AVP in EAP-TTLS is identical to that of Diameter.
1259 Use of the RADIUS/Diameter namespace allows a TTLS server to easily
1260 translate between AVPs it uses to communicate to clients and the
1261 protocol requirements of AAA servers that are widely deployed. Plus,
1262 it provides a well-understood mechanism to allow vendors to extend
1263 that namespace for their particular requirements.
1265 It is expected that the AVP Codes used in EAP-TTLS will carry roughly
1266 the same meaning in EAP-TTLS as they do in Diameter and, by
1267 extension, RADIUS. However, although EAP-TTLS uses the same AVP
1268 Codes and syntax as Diameter, the semantics may differ, and most
1269 Diameter AVPs do not have any well-defined semantics in EAP-TTLS. A
1270 separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be
1271 used within EAP-TTLS and their semantics in this context (see Section
1272 16 for details). A TTLS server copying AVPs between an EAP-TTLS
1273 exchange and a Diameter or RADIUS exchange with a backend MUST NOT
1274 make assumptions about AVPs whose usage in either EAP-TTLS or the
1275 backend protocol it does not understand. Therefore, a TTLS server
1276 MUST NOT copy an AVP between an EAP-TTLS exchange and a Diameter or
1277 RADIUS exchange unless the semantics of the AVP are understood and
1278 defined in both contexts.
1282 The format of an AVP is shown below. All items are in network, or
1283 big-endian, order; that is, they have the most significant octet
1290 Funk & Blake-Wilson Informational [Page 23]
1292 RFC 5281 EAP-TTLSv0 August 2008
1296 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
1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1300 |V M r r r r r r| AVP Length |
1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1308 The AVP Code is four octets and, combined with the Vendor-ID field
1309 if present, identifies the attribute uniquely. The first 256 AVP
1310 numbers represent attributes defined in RADIUS [RFC2865]. AVP
1311 numbers 256 and above are defined in Diameter [RFC3588].
1315 The AVP Flags field is one octet and provides the receiver with
1316 information necessary to interpret the AVP.
1318 The 'V' (Vendor-Specific) bit indicates whether the optional
1319 Vendor-ID field is present. When set to 1, the Vendor-ID field is
1320 present and the AVP Code is interpreted according to the namespace
1321 defined by the vendor indicated in the Vendor-ID field.
1323 The 'M' (Mandatory) bit indicates whether support of the AVP is
1324 required. If this bit is set to 0, this indicates that the AVP
1325 may be safely ignored if the receiving party does not understand
1326 or support it. If set to 1, this indicates that the receiving
1327 party MUST fail the negotiation if it does not understand the AVP;
1328 for a TTLS server, this would imply returning EAP-Failure, for a
1329 client, this would imply abandoning the negotiation.
1331 The 'r' (reserved) bits are unused and MUST be set to 0 by the
1332 sender and MUST be ignored by the receiver.
1336 The AVP Length field is three octets and indicates the length of
1337 this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
1338 (if present), and Data.
1346 Funk & Blake-Wilson Informational [Page 24]
1348 RFC 5281 EAP-TTLSv0 August 2008
1353 The Vendor-ID field is present if the V bit is set in the AVP
1354 Flags field. It is four octets and contains the vendor's IANA-
1355 assigned "SMI Network Management Private Enterprise Codes"
1356 [RFC3232] value. Vendors defining their own AVPs must maintain a
1357 consistent namespace for use of those AVPs within RADIUS,
1358 Diameter, and EAP-TTLS.
1360 A Vendor-ID value of zero is equivalent to absence of the Vendor-
1361 ID field altogether.
1363 Note that the M bit provides a means for extending the functionality
1364 of EAP-TTLS while preserving backward compatibility when desired. By
1365 setting the M bit of the appropriate AVP(s) to 0 or 1, the party
1366 initiating the function indicates that support of the function by the
1367 other party is either optional or required.
1371 Data encapsulated within the TLS record layer must consist entirely
1372 of a sequence of zero or more AVPs. Each AVP must begin on a four-
1373 octet boundary relative to the first AVP in the sequence. If an AVP
1374 is not a multiple of four octets, it must be padded with zeros to the
1375 next four-octet boundary.
1377 Note that the AVP Length does not include the padding.
1379 10.3. Guidelines for Maximum Compatibility with AAA Servers
1381 For maximum compatibility with AAA servers, the following guidelines
1382 for AVP usage are suggested:
1384 - Non-vendor-specific AVPs intended for use with AAA servers should
1385 be selected from the set of attributes defined for RADIUS; that
1386 is, attributes with codes less than 256. This provides
1387 compatibility with both RADIUS and Diameter.
1389 - Vendor-specific AVPs intended for use with AAA servers should be
1390 defined in terms of RADIUS. Vendor-specific RADIUS attributes
1391 translate to Diameter (and, hence, to EAP-TTLS) automatically; the
1392 reverse is not true. RADIUS vendor-specific attributes use RADIUS
1393 attribute 26 and include Vendor-ID, vendor-specific attribute
1394 code, and length; see [RFC2865] for details.
1402 Funk & Blake-Wilson Informational [Page 25]
1404 RFC 5281 EAP-TTLSv0 August 2008
1407 11. Tunneled Authentication
1409 EAP-TTLS permits user authentication information to be tunneled
1410 within the TLS record layer between client and TTLS server, ensuring
1411 the security of the authentication information against active and
1412 passive attack between the client and TTLS server. The TTLS server
1413 decrypts and forwards this information to the AAA/H over the AAA
1416 Any type of password or other authentication may be tunneled. Also,
1417 multiple tunneled authentications may be performed. Normally,
1418 tunneled authentication is used when the client has not been issued a
1419 certificate, and the TLS handshake provides only one-way
1420 authentication of the TTLS server to the client; however, in certain
1421 cases it may be desired to perform certificate authentication of the
1422 client during the TLS handshake as well as tunneled user
1423 authentication afterwards.
1425 11.1. Implicit Challenge
1427 Certain authentication protocols that use a challenge/response
1428 mechanism rely on challenge material that is not generated by the
1429 authentication server, and therefore the material requires special
1432 In CHAP, MS-CHAP, and MS-CHAP-V2, for example, the access point
1433 issues a challenge to the client, the client then hashes the
1434 challenge with the password and forwards the response to the access
1435 point. The access point then forwards both challenge and response to
1436 a AAA server. But because the AAA server did not itself generate the
1437 challenge, such protocols are susceptible to replay attack.
1439 If the client were able to create both challenge and response, anyone
1440 able to observe a CHAP or MS-CHAP exchange could pose as that user,
1441 even using EAP-TTLS.
1443 To make these protocols secure under EAP-TTLS, it is necessary to
1444 provide a mechanism to produce a challenge that the client cannot
1445 control or predict. This is accomplished using the same technique
1446 described above for generating data connection keying material.
1448 When a challenge-based authentication mechanism is used, both client
1449 and TTLS server use the pseudo-random function to generate as many
1450 octets as are required for the challenge, using the constant string
1451 "ttls challenge", based on the master secret and random values
1452 established during the handshake:
1458 Funk & Blake-Wilson Informational [Page 26]
1460 RFC 5281 EAP-TTLSv0 August 2008
1463 EAP-TTLS_challenge = PRF-nn(SecurityParameters.master_secret,
1465 SecurityParameters.client_random +
1466 SecurityParameters.server_random);
1468 The number of octets to be generated (nn) depends on the
1469 authentication method, and is indicated below for each authentication
1470 method requiring implicit challenge generation.
1472 11.2. Tunneled Authentication Protocols
1474 This section describes the methods for tunneling specific
1475 authentication protocols within EAP-TTLS.
1477 For the purpose of explication, it is assumed that the TTLS server
1478 and AAA/H use RADIUS as a AAA carrier protocol between them.
1479 However, this is not a requirement, and any AAA protocol capable of
1480 carrying the required information may be used.
1482 The client determines which authentication protocol will be used via
1483 the initial AVPs it sends to the server, as described in the
1486 Note that certain of the authentication protocols described below
1487 utilize vendor-specific AVPs originally defined for RADIUS. RADIUS
1488 and Diameter differ in the encoding of vendor-specific AVPs: RADIUS
1489 uses the vendor-specific attribute (code 26), while Diameter uses
1490 setting of the V bit to indicate the presence of Vendor-ID. The
1491 RADIUS form of the vendor-specific attribute is always convertible to
1492 a Diameter AVP with V bit set. All vendor-specific AVPs described
1493 below MUST be encoded using the preferred Diameter V bit mechanism;
1494 that is, the AVP Code of 26 MUST NOT be used to encode vendor-
1495 specific AVPs within EAP-TTLS.
1499 When EAP is the tunneled authentication protocol, each tunneled EAP
1500 packet between the client and TTLS server is encapsulated in an EAP-
1501 Message AVP, prior to tunneling via the TLS record layer.
1503 Note that because Diameter AVPs are not limited to 253 octets of
1504 data, as are RADIUS attributes, the RADIUS mechanism of concatenating
1505 multiple EAP-Message attributes to represent a longer-than-253-octet
1506 EAP packet is not appropriate in EAP-TTLS. Thus, a tunneled EAP
1507 packet within a single EAP-TTLS message MUST be contained in a single
1514 Funk & Blake-Wilson Informational [Page 27]
1516 RFC 5281 EAP-TTLSv0 August 2008
1519 The client initiates EAP by tunneling EAP-Response/Identity to the
1520 TTLS server. Depending on the requirements specified for the inner
1521 method, the client MAY now place the actual username in this packet;
1522 the privacy of the user's identity is now guaranteed by the TLS
1523 encryption. This username is typically a Network Access Identifier
1524 (NAI) [RFC4282]; that is, it is typically in the following format:
1528 The @realm portion is optional, and is used to allow the TTLS server
1529 to forward the EAP packet to the appropriate AAA/H.
1531 Note that the client has two opportunities to specify realms. The
1532 first, in the initial, untunneled EAP-Response/Identity packet prior
1533 to starting EAP-TTLS, indicates the realm of the TTLS server. The
1534 second, occurring as part of the EAP exchange within the EAP-TTLS
1535 tunnel, indicates the realm of the client's home network. Thus, the
1536 access point need only know how to route to the realm of the TTLS
1537 server; the TTLS server is assumed to know how to route to the
1538 client's home realm. This serial routing architecture is anticipated
1539 to be useful in roaming environments, allowing access points or AAA
1540 proxies behind access points to be configured only with a small
1541 number of realms. (Refer to Section 7.3 for additional information
1542 distinguishing the untunneled and tunneled versions of the EAP-
1543 Response/Identity packets.)
1545 Note that TTLS processing of the initial identity exchange is
1546 different from plain EAP. The state machine of TTLS is different.
1547 However, it is expected that the server side is capable of dealing
1548 with client initiation, because even normal EAP protocol runs are
1549 client-initiated over AAA. On the client side, there are various
1550 implementation techniques to deal with the differences. Even a
1551 TTLS-unaware EAP protocol run could be used, if TTLS makes it appear
1552 as if an EAP-Request/Identity message was actually received. This is
1553 similar to what authenticators do when operating between a client and
1556 Upon receipt of the tunneled EAP-Response/Identity, the TTLS server
1557 forwards it to the AAA/H in a RADIUS Access-Request.
1559 The AAA/H may immediately respond with an Access-Reject; in which
1560 case, the TTLS server completes the negotiation by sending an EAP-
1561 Failure to the access point. This could occur if the AAA/H does not
1562 recognize the user's identity, or if it does not support EAP.
1564 If the AAA/H does recognize the user's identity and does support EAP,
1565 it responds with an Access-Challenge containing an EAP-Request, with
1566 the Type and Type-Data fields set according to the EAP protocol with
1570 Funk & Blake-Wilson Informational [Page 28]
1572 RFC 5281 EAP-TTLSv0 August 2008
1575 which the AAA/H wishes to authenticate the client; for example MD5-
1576 Challenge, One-Time Password (OTP), or Generic Token Card.
1578 The EAP authentication between client and AAA/H proceeds normally, as
1579 described in [RFC3748], with the TTLS server acting as a passthrough
1580 device. Each EAP-Request sent by the AAA/H in an Access-Challenge is
1581 tunneled by the TTLS server to the client, and each EAP-Response
1582 tunneled by the client is decrypted and forwarded by the TTLS server
1583 to the AAA/H in an Access-Request.
1585 This process continues until the AAA/H issues an Access-Accept or
1588 Note that EAP-TTLS does not impose special rules on EAP Notification
1589 packets; such packets MAY be used within a tunneled EAP exchange
1590 according to the rules specified in [RFC3748].
1592 EAP-TTLS provides a reliable transport for the tunneled EAP exchange.
1593 However, [RFC3748] assumes an unreliable transport for EAP messages
1594 (see Section 3.1), and provides for silent discard of any EAP packet
1595 that violates the protocol or fails a method-specific integrity
1596 check, on the assumption that such a packet is likely a counterfeit
1597 sent by an attacker. But since the tunnel provides a reliable
1598 transport for the inner EAP authentication, errors that would result
1599 in silent discard according to [RFC3748] presumably represent
1600 implementation errors when they occur within the tunnel, and SHOULD
1601 be treated as such in preference to being silently discarded.
1602 Indeed, silently discarding an EAP message within the tunnel
1603 effectively puts a halt to the progress of the exchange, and will
1604 result in long timeouts in cases that ought to result in immediate
1609 The CHAP algorithm is described in [RFC1661]; RADIUS attribute
1610 formats are described in [RFC2865].
1612 Both client and TTLS server generate 17 octets of challenge material,
1613 using the constant string "ttls challenge" as described above. These
1614 octets are used as follows:
1616 CHAP-Challenge [16 octets]
1617 CHAP Identifier [1 octet]
1619 The client initiates CHAP by tunneling User-Name, CHAP-Challenge, and
1620 CHAP-Password AVPs to the TTLS server. The CHAP-Challenge value is
1621 taken from the challenge material. The CHAP-Password consists of
1626 Funk & Blake-Wilson Informational [Page 29]
1628 RFC 5281 EAP-TTLSv0 August 2008
1631 CHAP Identifier, taken from the challenge material; and CHAP
1632 response, computed according to the CHAP algorithm.
1634 Upon receipt of these AVPs from the client, the TTLS server must
1635 verify that the value of the CHAP-Challenge AVP and the value of the
1636 CHAP Identifier in the CHAP-Password AVP are equal to the values
1637 generated as challenge material. If either item does not match
1638 exactly, the TTLS server must reject the client. Otherwise, it
1639 forwards the AVPs to the AAA/H in an Access-Request.
1641 The AAA/H will respond with an Access-Accept or Access-Reject.
1645 The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
1646 formats are described in [RFC2548].
1648 Both client and TTLS server generate 9 octets of challenge material,
1649 using the constant string "ttls challenge" as described above. These
1650 octets are used as follows:
1652 MS-CHAP-Challenge [8 octets]
1655 The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-
1656 Challenge and MS-CHAP-Response AVPs to the TTLS server. The MS-
1657 CHAP-Challenge value is taken from the challenge material. The MS-
1658 CHAP-Response consists of Ident, taken from the challenge material;
1659 Flags, set according the client preferences; and LM-Response and NT-
1660 Response, computed according to the MS-CHAP algorithm.
1662 Upon receipt of these AVPs from the client, the TTLS server MUST
1663 verify that the value of the MS-CHAP-Challenge AVP and the value of
1664 the Ident in the client's MS-CHAP-Response AVP are equal to the
1665 values generated as challenge material. If either item does not
1666 match exactly, the TTLS server MUST reject the client. Otherwise, it
1667 forwards the AVPs to the AAA/H in an Access-Request.
1669 The AAA/H will respond with an Access-Accept or Access-Reject.
1673 The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute
1674 formats are described in [RFC2548].
1676 Both client and TTLS server generate 17 octets of challenge material,
1677 using the constant string "ttls challenge" as described above. These
1678 octets are used as follows:
1682 Funk & Blake-Wilson Informational [Page 30]
1684 RFC 5281 EAP-TTLSv0 August 2008
1687 MS-CHAP-Challenge [16 octets]
1690 The client initiates MS-CHAP-V2 by tunneling User-Name, MS-CHAP-
1691 Challenge, and MS-CHAP2-Response AVPs to the TTLS server. The MS-
1692 CHAP-Challenge value is taken from the challenge material. The MS-
1693 CHAP2-Response consists of Ident, taken from the challenge material;
1694 Flags, set to 0; Peer-Challenge, set to a random value; and Response,
1695 computed according to the MS-CHAP-V2 algorithm.
1697 Upon receipt of these AVPs from the client, the TTLS server MUST
1698 verify that the value of the MS-CHAP-Challenge AVP and the value of
1699 the Ident in the client's MS-CHAP2-Response AVP are equal to the
1700 values generated as challenge material. If either item does not
1701 match exactly, the TTLS server MUST reject the client. Otherwise, it
1702 forwards the AVPs to the AAA/H in an Access-Request.
1704 If the authentication is successful, the AAA/H will respond with an
1705 Access-Accept containing the MS-CHAP2-Success attribute. This
1706 attribute contains a 42-octet string that authenticates the AAA/H to
1707 the client based on the Peer-Challenge. The TTLS server tunnels this
1708 AVP to the client. Note that the authentication is not yet complete;
1709 the client must still accept the authentication response of the
1712 Upon receipt of the MS-CHAP2-Success AVP, the client is able to
1713 authenticate the AAA/H. If the authentication succeeds, the client
1714 sends an EAP-TTLS packet to the TTLS server containing no data (that
1715 is, with a zero-length Data field). Upon receipt of the empty EAP-
1716 TTLS packet from the client, the TTLS server considers the MS-CHAP-
1717 V2 authentication to have succeeded.
1719 If the authentication fails, the AAA/H will respond with an Access-
1720 Challenge containing the MS-CHAP-Error attribute. This attribute
1721 contains a new Ident and a string with additional information such as
1722 the error reason and whether a retry is allowed. The TTLS server
1723 tunnels this AVP to the client. If the error reason is an expired
1724 password and a retry is allowed, the client may proceed to change the
1725 user's password. If the error reason is not an expired password or
1726 if the client does not wish to change the user's password, it simply
1727 abandons the EAP-TTLS negotiation.
1729 If the client does wish to change the password, it tunnels MS-CHAP-
1730 NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS
1731 server. The MS-CHAP2-CPW AVP is derived from the new Ident and
1732 Challenge received in the MS-CHAP-Error AVP. The MS-CHAP-Challenge
1733 AVP simply echoes the new Challenge.
1738 Funk & Blake-Wilson Informational [Page 31]
1740 RFC 5281 EAP-TTLSv0 August 2008
1743 Upon receipt of these AVPs from the client, the TTLS server MUST
1744 verify that the value of the MS-CHAP-Challenge AVP and the value of
1745 the Ident in the client's MS-CHAP2-CPW AVP match the values it sent
1746 in the MS-CHAP-Error AVP. If either item does not match exactly, the
1747 TTLS server MUST reject the client. Otherwise, it forwards the AVPs
1748 to the AAA/H in an Access-Request.
1750 If the authentication is successful, the AAA/H will respond with an
1751 Access-Accept containing the MS-CHAP2-Success attribute. At this
1752 point, the negotiation proceeds as described above; the TTLS server
1753 tunnels the MS-CHAP2-Success to the client, and the client
1754 authenticates the AAA/H based on this AVP. Then, the client either
1755 abandons the negotiation on failure or sends an EAP-TTLS packet to
1756 the TTLS server containing no data (that is, with a zero-length Data
1757 field), causing the TTLS server to consider the MS-CHAP-V2
1758 authentication to have succeeded.
1760 Note that additional AVPs associated with MS-CHAP-V2 may be sent by
1761 the AAA/H; for example, MS-CHAP-Domain. The TTLS server MUST tunnel
1762 such authentication-related attributes along with the MS-CHAP2-
1767 The client initiates PAP by tunneling User-Name and User-Password
1768 AVPs to the TTLS server.
1770 Normally, in RADIUS, User-Password is padded with nulls to a multiple
1771 of 16 octets, then encrypted using a shared secret and other packet
1774 An EAP-TTLS client, however, does not RADIUS-encrypt the password
1775 since no such RADIUS variables are available; this is not a security
1776 weakness since the password will be encrypted via TLS anyway. The
1777 client SHOULD, however, null-pad the password to a multiple of 16
1778 octets, to obfuscate its length.
1780 Upon receipt of these AVPs from the client, the TTLS server forwards
1781 them to the AAA/H in a RADIUS Access-Request. (Note that in the
1782 Access-Request, the TTLS server must encrypt the User-Password
1783 attribute using the shared secret between the TTLS server and AAA/H.)
1785 The AAA/H may immediately respond with an Access-Accept or Access-
1786 Reject. The TTLS server then completes the negotiation by sending an
1787 EAP-Success or EAP-Failure to the access point using the AAA carrier
1794 Funk & Blake-Wilson Informational [Page 32]
1796 RFC 5281 EAP-TTLSv0 August 2008
1799 The AAA/H may also respond with an Access-Challenge. The TTLS server
1800 then tunnels the AVPs from the AAA/H's challenge to the client. Upon
1801 receipt of these AVPs, the client tunnels User-Name and User-
1802 Password again, with User-Password containing new information in
1803 response to the challenge. This process continues until the AAA/H
1804 issues an Access-Accept or Access-Reject.
1806 At least one of the AVPs tunneled to the client upon challenge MUST
1807 be Reply-Message. Normally, this is sent by the AAA/H as part of the
1808 challenge. However, if the AAA/H has not sent a Reply-Message, the
1809 TTLS server MUST issue one, with null value. This allows the client
1810 to determine that a challenge response is required.
1812 Note that if the AAA/H includes a Reply-Message as part of an
1813 Access-Accept or Access-Reject, the TTLS server does not tunnel this
1814 AVP to the client. Rather, this AVP and all other AVPs sent by the
1815 AAA/H as part of Access-Accept or Access-Reject are sent to the
1816 access point via the AAA carrier protocol.
1818 11.3. Performing Multiple Authentications
1820 In some cases, it is desirable to perform multiple user
1821 authentications. For example, a AAA/H may want first to authenticate
1822 the user by password, then by token card.
1824 The AAA/H may perform any number of additional user authentications
1825 using EAP, simply by issuing a EAP-Request with a new EAP type once
1826 the previous authentication completes. Note that each new EAP method
1827 is subject to negotiation; that is, the client may respond to the EAP
1828 request for a new EAP type with an EAP-Nak, as described in
1831 For example, a AAA/H wishing to perform an MD5-Challenge followed by
1832 Generic Token Card would first issue an EAP-Request/MD5-Challenge and
1833 receive a response. If the response is satisfactory, it would then
1834 issue an EAP-Request/Generic Token Card and receive a response. If
1835 that response were also satisfactory, it would accept the user.
1837 The entire inner EAP exchange comprising multiple authentications is
1838 considered a single EAP sequence, in that each subsequent request
1839 MUST contain distinct a EAP Identifier from the previous request,
1840 even as one authentication completes and another begins.
1842 The peer identity indicated in the original EAP-Response/Identity
1843 that initiated the EAP sequence is intended to apply to each of the
1844 sequential authentications. In the absence of an application profile
1845 standard specifying otherwise, additional EAP-Identity exchanges
1850 Funk & Blake-Wilson Informational [Page 33]
1852 RFC 5281 EAP-TTLSv0 August 2008
1855 The conditions for overall success or failure when multiple
1856 authentications are used are a matter of policy on client and server;
1857 thus, either party may require that all inner authentications
1858 succeed, or that at least one inner authentication succeed, as a
1859 condition for success of the overall authentication.
1861 Each EAP method is intended to run to completion. Should the TTLS
1862 server abandon a method and start a new one, client behavior is not
1863 defined in this document and is a matter of client policy.
1865 Note that it is not always feasible to use the same EAP method twice
1866 in a row, since it may not be possible to determine when the first
1867 authentication completes and the new authentication begins if the EAP
1868 type does not change. Certain EAP methods, such as EAP-TLS, use a
1869 Start bit to distinguish the first request, thus allowing each new
1870 authentication using that type to be distinguished from the previous.
1871 Other methods, such as EAP-MS-CHAP-V2, terminate in a well-defined
1872 manner, allowing a second authentication of the same type to commence
1873 unambiguously. While use of the same EAP method for multiple
1874 authentications is relatively unlikely, implementers should be aware
1875 of the issues and avoid cases that would result in ambiguity.
1877 Multiple authentications using non-EAP methods or a mixture of EAP
1878 and non-EAP methods is not defined in this document, nor is it known
1879 whether such an approach has been implemented.
1881 11.4. Mandatory Tunneled Authentication Support
1883 To ensure interoperability, in the absence of an application profile
1884 standard specifying otherwise, an implementation compliant with this
1885 specification MUST implement EAP as a tunneled authentication method
1886 and MUST implement MD5-Challenge as an EAP type. However, such an
1887 implementation MAY allow the use of EAP, any EAP type, or any other
1888 tunneled authentication method to be enabled or disabled by
1889 administrative action on either client or TTLS server.
1891 In addition, in the absence of an application profile standard
1892 specifying otherwise, an implementation compliant with this
1893 specification MUST allow an administrator to configure the use of
1894 tunneled authentication without the M (Mandatory) bit set on any AVP.
1896 11.5. Additional Suggested Tunneled Authentication Support
1898 The following information is provided as non-normative guidance based
1899 on the experience of the authors and reviewers of this specification
1900 with existing implementations of EAP-TTLSv0.
1906 Funk & Blake-Wilson Informational [Page 34]
1908 RFC 5281 EAP-TTLSv0 August 2008
1911 The following authentication methods are commonly used, and servers
1912 wishing for broad interoperability across multiple media should
1913 consider implementing them:
1915 - PAP (both for password and token authentication)
1923 12. Keying Framework
1925 In compliance with [RFC5247], Session-Id, Peer-Id, and Server-Id are
1930 The Session-Id uniquely identifies an authentication exchange between
1931 the client and TTLS server. It is defined as follows:
1933 Session-Id = 0x15 || client.random || server.random
1937 The Peer-Id represents the identity to be used for access control and
1938 accounting purposes. When the client presents a certificate as part
1939 of the TLS handshake, the Peer-Id is determined based on information
1940 in the certificate, as specified in Section 5.2 of [RFC5216].
1941 Otherwise, the Peer-Id is null.
1945 The Server-Id identifies the TTLS server. When the TTLS server
1946 presents a certificate as part of the TLS handshake, the Server-Id is
1947 determined based on information in the certificate, as specified in
1948 Section 5.2 of [RFC5216]. Otherwise, the Server-Id is null.
1952 The following table lists each AVP defined in this document, whether
1953 the AVP may appear in a packet from server to client ("Request")
1954 and/or in a packet from client to server ("Response"), and whether
1955 the AVP MUST be implemented ("MI").
1962 Funk & Blake-Wilson Informational [Page 35]
1964 RFC 5281 EAP-TTLSv0 August 2008
1967 Name Request Response MI
1968 ---------------------------------------------------
1984 14. Security Considerations
1986 14.1. Security Claims
1988 Pursuant to RFC 3748, security claims for EAP-TTLSv0 are as follows:
1990 Authentication mechanism: TLS plus arbitrary additional protected
1992 Ciphersuite negotiation: Yes
1993 Mutual authentication: Yes, in recommended implementation
1994 Integrity protection: Yes
1995 Replay protection: Yes
1996 Confidentiality: Yes
1998 Key strength: Up to 384 bits
1999 Dictionary attack prot.: Yes
2001 Cryptographic binding: No
2002 Session independence: Yes
2006 14.1.1. Authentication Mechanism
2008 EAP-TTLSv0 utilizes negotiated underlying authentication protocols,
2009 both in the phase 1 TLS handshake and the phase 2 tunneled
2010 authentication. In a typical deployment, at a minimum the TTLS
2011 server authenticates to the client in phase 1, and the client
2012 authenticates to the AAA/H server in phase 2. Phase 1 authentication
2013 of the TTLS server to the client is typically by certificate; the
2014 client may optionally authenticate to the TTLS server by certificate
2018 Funk & Blake-Wilson Informational [Page 36]
2020 RFC 5281 EAP-TTLSv0 August 2008
2023 as well. Phase 2 authentication of the client to the AAA/H server is
2024 typically by password or security token via an EAP or supported non-
2025 EAP authentication mechanism; this authentication mechanism may
2026 provide authentication of the AAA/H server to the client as well
2027 (mutual authentication).
2029 14.1.2. Ciphersuite Negotiation
2031 Ciphersuite negotiation is inherited from TLS.
2033 14.1.3. Mutual Authentication
2035 In the recommended minimum configuration, the TTLS server is
2036 authenticated to the client in phase 1, and the client and AAA/H
2037 server mutually authenticate in phase 2.
2039 14.1.4. Integrity Protection
2041 Integrity protection is inherited from TLS.
2043 14.1.5. Replay Protection
2045 Replay protection is inherited from TLS.
2047 14.1.6. Confidentiality
2049 Confidentiality is inherited from TLS. Note, however, that EAP-
2050 TTLSv0 contains no provision for encryption of success or failure EAP
2053 14.1.7. Key Derivation
2055 Both MSK and EMSK are derived. The key derivation PRF is inherited
2056 from TLS, and cryptographic agility of this mechanism depends on the
2057 cryptographic agility of the TLS PRF.
2059 14.1.8. Key Strength
2061 Key strength is limited by the size of the TLS master secret, which
2062 for versions 1.0 and 1.1 is 48 octets (384 bits). Effective key
2063 strength may be less, depending on the attack resistance of the
2064 negotiated Diffie-Helman (DH) group, certificate RSA/DSA group, etc.
2065 BCP 86 [RFC3766], Section 5, offers advice on the required RSA or DH
2066 module and DSA subgroup size in bits, for a given level of attack
2067 resistance in bits. For example, a 2048-bit RSA key is recommended
2068 to provide 128-bit equivalent key strength. The National Institute
2069 for Standards and Technology (NIST) also offers advice on appropriate
2070 key sizes in [SP800-57].
2074 Funk & Blake-Wilson Informational [Page 37]
2076 RFC 5281 EAP-TTLSv0 August 2008
2079 14.1.9. Dictionary Attack Protection
2081 Phase 2 password authentication is protected against eavesdropping
2082 and therefore against offline dictionary attack by TLS encryption.
2084 14.1.10. Fast Reconnect
2086 Fast reconnect is provided by TLS session resumption.
2088 14.1.11. Cryptographic Binding
2090 [MITM] describes a vulnerability that is characteristic of tunneled
2091 authentication protocols, in which an attacker authenticates as a
2092 client via a tunneled protocol by posing as an authenticator to a
2093 legitimate client using a non-tunneled protocol. When the same proof
2094 of credentials can be used in both authentications, the attacker
2095 merely shuttles the credential proof between them. EAP-TTLSv0 is
2096 vulnerable to such an attack. Care should be taken to avoid using
2097 authentication protocols and associated credentials both as inner
2098 TTLSv0 methods and as untunneled methods.
2100 Extensions to EAP-TTLSv0 or a future version of EAP-TTLS should be
2101 defined to perform a cryptographic binding of keying material
2102 generated by inner authentication methods and the keying material
2103 generated by the TLS handshake. This avoids the man-in-the-middle
2104 problem when used with key-generating inner methods. Such an
2105 extension mechanism has been proposed [TTLS-EXT].
2107 14.1.12. Session Independence
2109 TLS guarantees the session independence of its master secret, from
2110 which the EAP-TTLSv0 MSK/EMSK is derived.
2112 14.1.13. Fragmentation
2114 Provision is made for fragmentation of lengthy EAP packets.
2116 14.1.14. Channel Binding
2118 Support for channel binding may be added as a future extension, using
2121 14.2. Client Anonymity
2123 Unlike other EAP methods, EAP-TTLS does not communicate a username in
2124 the clear in the initial EAP-Response/Identity. This feature is
2125 designed to support anonymity and location privacy from attackers
2126 eavesdropping the network path between the client and the TTLS
2130 Funk & Blake-Wilson Informational [Page 38]
2132 RFC 5281 EAP-TTLSv0 August 2008
2135 server. However, implementers should be aware that other factors --
2136 both within EAP-TTLS and elsewhere -- may compromise a user's
2137 identity. For example, if a user authenticates with a certificate
2138 during phase 1 of EAP-TTLS, the subject name in the certificate may
2139 reveal the user's identity. Outside of EAP-TTLS, the client's fixed
2140 MAC address, or in the case of wireless connections, the client's
2141 radio signature, may also reveal information. Additionally,
2142 implementers should be aware that a user's identity is not hidden
2143 from the EAP-TTLS server and may be included in the clear in AAA
2144 messages between the access point, the EAP-TTLS server, and the AAA/H
2147 Note that if a client authenticating with a certificate wishes to
2148 shield its certificate, and hence its identity, from eavesdroppers,
2149 it may use the technique described in Section 2.1.4 ("Privacy") of
2150 [RFC5216], in which the client sends an empty certificate list, the
2151 TTLS server issues a ServerHello upon completion of the TLS handshake
2152 to begin a second, encrypted handshake, during which the client will
2153 send its certificate list. Note that for this feature to work the
2154 client must know in advance that the TTLS server supports it.
2158 Trust of the server by the client is established via a server
2159 certificate conveyed during the TLS handshake. The client should
2160 have a means of determining which server identities are authorized to
2161 act as a TTLS server and may be trusted, and should refuse to
2162 authenticate with servers it does not trust. The consequence of
2163 pursuing authentication with a hostile server is exposure of the
2164 inner authentication to attack; e.g., offline dictionary attack
2165 against the client password.
2167 14.4. Certificate Validation
2169 When either client or server presents a certificate as part of the
2170 TLS handshake, it should include the entire certificate chain minus
2171 the root to facilitate certificate validation by the other party.
2173 When either client or server receives a certificate as part of the
2174 TLS handshake, it should validate the certification path to a trusted
2175 root. If intermediate certificates are not provided by the sender,
2176 the receiver may use cached or pre-configured copies if available, or
2177 may retrieve them from the Internet if feasible.
2179 Clients and servers should implement policies related to the Extended
2180 Key Usage (EKU) extension [RFC5280] of certificates it receives, to
2181 ensure that the other party's certificate usage conforms to the
2182 certificate's purpose. Typically, a client EKU, when present, would
2186 Funk & Blake-Wilson Informational [Page 39]
2188 RFC 5281 EAP-TTLSv0 August 2008
2191 be expected to include id-kp-clientAuth; a server EKU, when present,
2192 would be expected to include id-kp-serverAuth. Note that absence of
2193 the EKU extension or a value of anyExtendedKeyUsage implies absence
2194 of constraint on the certificate's purpose.
2196 14.5. Certificate Compromise
2198 Certificates should be checked for revocation to reduce exposure to
2199 imposture using compromised certificates.
2201 Checking a server certificate against the most recent revocation list
2202 during authentication is not always possible for a client, as it may
2203 not have network access until completion of the authentication. This
2204 problem can be alleviated through the use of the Online Certificate
2205 Status Protocol (OCSP) [RFC2560] during the TLS handshake, as
2206 described in [RFC4366].
2208 14.6. Forward Secrecy
2210 With forward secrecy, revelation of a secret does not compromise
2211 session keys previously negotiated based on that secret. Thus, when
2212 the TLS key exchange algorithm provides forward secrecy, if a TTLS
2213 server certificate's private key is eventually stolen or cracked,
2214 tunneled user password information will remain secure as long as that
2215 certificate is no longer in use. Diffie-Hellman key exchange is an
2216 example of an algorithm that provides forward secrecy. A forward
2217 secrecy algorithm should be considered if attacks against recorded
2218 authentication or data sessions are considered to pose a significant
2221 14.7. Negotiating-Down Attacks
2223 EAP-TTLS negotiates its own protocol version prior to, and therefore
2224 outside the security established by the TLS tunnel. In principle,
2225 therefore, it is subject to a negotiating-down attack, in which an
2226 intermediary modifies messages in transit to cause a lower version of
2227 the protocol to be agreed upon, each party assuming that the other
2228 does not support as high a version as it actually does.
2230 The version of the EAP-TTLS protocol described in this document is 0,
2231 and is therefore not subject to such an attack. However, any new
2232 version of the protocol using a higher number than 0 should define a
2233 mechanism to ensure against such an attack. One such mechanism might
2234 be the TTLS server's reiteration of the protocol version that it
2235 proposed in an AVP within the tunnel, such AVP to be inserted with M
2236 bit clear even when version 0 is agreed upon.
2242 Funk & Blake-Wilson Informational [Page 40]
2244 RFC 5281 EAP-TTLSv0 August 2008
2247 15. Message Sequences
2249 This section presents EAP-TTLS message sequences for various
2250 negotiation scenarios. These examples do not attempt to exhaustively
2251 depict all possible scenarios.
2253 It is assumed that RADIUS is the AAA carrier protocol both between
2254 access point and TTLS server, and between TTLS server and AAA/H.
2256 EAP packets that are passed unmodified between client and TTLS server
2257 by the access point are indicated as "passthrough". AVPs that are
2258 securely tunneled within the TLS record layer are enclosed in curly
2259 braces ({}). Items that are optional are suffixed with question mark
2260 (?). Items that may appear multiple times are suffixed with plus
2263 15.1. Successful Authentication via Tunneled CHAP
2265 In this example, the client performs one-way TLS authentication of
2266 the TTLS server. CHAP is used as a tunneled user authentication
2269 client access point TTLS server AAA/H
2270 ------ ------------ ----------- -----
2272 EAP-Request/Identity
2273 <--------------------
2275 EAP-Response/Identity
2276 -------------------->
2278 RADIUS Access-Request:
2279 EAP-Response passthrough
2280 -------------------->
2282 RADIUS Access-Challenge:
2283 EAP-Request/TTLS-Start
2284 <--------------------
2286 EAP-Request passthrough
2287 <--------------------
2291 -------------------->
2298 Funk & Blake-Wilson Informational [Page 41]
2300 RFC 5281 EAP-TTLSv0 August 2008
2303 RADIUS Access-Request:
2304 EAP-Response passthrough
2305 -------------------->
2307 RADIUS Access-Challenge:
2313 <--------------------
2315 EAP-Request passthrough
2316 <--------------------
2322 -------------------->
2324 RADIUS Access-Request:
2325 EAP-Response passthrough
2326 -------------------->
2328 RADIUS Access-Challenge:
2332 <--------------------
2334 EAP-Request passthrough
2335 <--------------------
2341 -------------------->
2343 RADIUS Access-Request:
2344 EAP-Response passthrough
2345 -------------------->
2354 Funk & Blake-Wilson Informational [Page 42]
2356 RFC 5281 EAP-TTLSv0 August 2008
2359 RADIUS Access-Request:
2363 -------------------->
2365 RADIUS Access-Accept
2366 <--------------------
2368 RADIUS Access-Accept:
2370 <--------------------
2373 <--------------------
2375 15.2. Successful Authentication via Tunneled EAP/MD5-Challenge
2377 In this example, the client performs one-way TLS authentication of
2378 the TTLS server and EAP/MD5-Challenge is used as a tunneled user
2379 authentication mechanism.
2381 client access point TTLS server AAA/H
2382 ------ ------------ ----------- -----
2384 EAP-Request/Identity
2385 <--------------------
2387 EAP-Response/Identity
2388 -------------------->
2390 RADIUS Access-Request:
2391 EAP-Response passthrough
2392 -------------------->
2394 RADIUS Access-Challenge:
2395 EAP-Request/TTLS-Start
2396 <--------------------
2398 EAP-Request passthrough
2399 <--------------------
2403 -------------------->
2410 Funk & Blake-Wilson Informational [Page 43]
2412 RFC 5281 EAP-TTLSv0 August 2008
2415 RADIUS Access-Request:
2416 EAP-Response passthrough
2417 -------------------->
2419 RADIUS Access-Challenge:
2425 <--------------------
2427 EAP-Request passthrough
2428 <--------------------
2434 -------------------->
2436 RADIUS Access-Request:
2437 EAP-Response passthrough
2438 -------------------->
2440 RADIUS Access-Challenge:
2444 <--------------------
2446 EAP-Request passthrough
2447 <--------------------
2450 {EAP-Response/Identity}
2451 -------------------->
2453 RADIUS Access-Request:
2454 EAP-Response passthrough
2455 -------------------->
2457 RADIUS Access-Request:
2458 EAP-Response/Identity
2459 -------------------->
2466 Funk & Blake-Wilson Informational [Page 44]
2468 RFC 5281 EAP-TTLSv0 August 2008
2471 RADIUS Access-Challenge
2474 <--------------------
2476 RADIUS Access-Challenge:
2478 {EAP-Request/MD5-Challenge}
2479 <--------------------
2481 EAP-Request passthrough
2482 <--------------------
2485 {EAP-Response/MD5-Challenge}
2486 -------------------->
2488 RADIUS Access-Request:
2489 EAP-Response passthrough
2490 -------------------->
2492 RADIUS Access-Challenge
2495 -------------------->
2497 RADIUS Access-Accept
2498 <--------------------
2500 RADIUS Access-Accept:
2502 <--------------------
2505 <--------------------
2522 Funk & Blake-Wilson Informational [Page 45]
2524 RFC 5281 EAP-TTLSv0 August 2008
2527 15.3. Successful Session Resumption
2529 In this example, the client and server resume a previous TLS session.
2530 The ID of the session to be resumed is sent as part of the
2531 ClientHello, and the server agrees to resume this session by sending
2532 the same session ID as part of ServerHello.
2534 client access point TTLS server AAA/H
2535 ------ ------------ ----------- -----
2537 EAP-Request/Identity
2538 <--------------------
2540 EAP-Response/Identity
2541 -------------------->
2543 RADIUS Access-Request:
2544 EAP-Response passthrough
2545 -------------------->
2547 RADIUS Access-Challenge:
2548 EAP-Request/TTLS-Start
2549 <--------------------
2551 EAP-Request passthrough
2552 <--------------------
2556 -------------------->
2558 RADIUS Access-Request:
2559 EAP-Response passthrough
2560 -------------------->
2562 RADIUS Access-Challenge:
2567 <--------------------
2569 EAP-Request passthrough
2570 <--------------------
2578 Funk & Blake-Wilson Informational [Page 46]
2580 RFC 5281 EAP-TTLSv0 August 2008
2586 -------------------->
2588 RADIUS Access-Request:
2589 EAP-Response passthrough
2590 -------------------->
2592 RADIUS Access-Accept:
2594 <--------------------
2597 <--------------------
2599 16. IANA Considerations
2601 IANA has assigned the number 21 (decimal) as the method type of the
2602 EAP-TTLS protocol. Mechanisms for defining new RADIUS and Diameter
2603 AVPs and AVP values are outlined in [RFC2865] and [RFC3588],
2604 respectively. No additional IANA registrations are specifically
2605 contemplated in this document.
2607 Section 11 of this document specifies how certain authentication
2608 mechanisms may be performed within the secure tunnel established by
2609 EAP-TTLS. New mechanisms and other functions MAY also be performed
2610 within this tunnel. Where such extensions use AVPs that are not
2611 vendor-specific, their semantics must be specified in new RFCs; that
2612 is, there are TTLS-specific processing rules related to the use of
2613 each individual AVP, even though such AVPs have already been defined
2614 for RADIUS or DIAMETER.
2616 This specification requires the creation of a new registry -- EAP-
2617 TTLS AVP Usage -- to be managed by IANA, listing each non-vendor-
2618 specific RADIUS/Diameter AVP that has been defined for use within
2619 EAP-TTLS, along with a reference to the RFC or other document that
2620 specifies its semantics. The initial list of AVPs shall be those
2621 listed in Section 13 of this document. The purpose of this registry
2622 is to avoid potential ambiguity resulting from the same AVP being
2623 utilized in different functional contexts. This registry does not
2624 assign numbers to AVPs, as the AVP numbers are assigned out of the
2625 RADIUS and Diameter namespaces as outlined in [RFC2865] and
2626 [RFC3588]. Only top-level AVPs -- that is, AVPs not encapsulated
2627 within Grouped AVPs -- will be registered. AVPs should be added to
2628 this registry based on IETF Review as defined in [RFC5226].
2634 Funk & Blake-Wilson Informational [Page 47]
2636 RFC 5281 EAP-TTLSv0 August 2008
2639 17. Acknowledgements
2641 Thanks to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen
2642 Hanna, Ryan Hurst, Avi Lior, and Gabriel Montenegro for careful
2643 reviews and useful comments.
2647 18.1. Normative References
2649 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
2650 STD 51, RFC 1661, July 1994.
2652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2653 Requirement Levels", BCP 14, RFC 2119, March 1997.
2655 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
2656 RFC 2246, January 1999.
2658 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
2659 RFC 2433, October 1998.
2661 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2662 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2665 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
2666 RFC 2548, March 1999.
2668 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
2671 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
2672 "Remote Authentication Dial In User Service (RADIUS)",
2673 RFC 2865, June 2000.
2675 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is
2676 Replaced by an On-line Database", RFC 3232, January 2002.
2678 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
2679 Arkko, "Diameter Base Protocol", RFC 3588, September
2682 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
2683 Levkowetz, Ed., "Extensible Authentication Protocol
2684 (EAP)", RFC 3748, June 2004.
2690 Funk & Blake-Wilson Informational [Page 48]
2692 RFC 5281 EAP-TTLSv0 August 2008
2695 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
2696 Network Access Identifier", RFC 4282, December 2005.
2698 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
2699 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
2701 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
2702 Authentication Protocol", RFC 5216, March 2008.
2704 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
2705 Authentication Protocol (EAP) Key Management Framework",
2706 RFC 5247, August 2008.
2708 18.2. Informative References
2710 [802.1X] Institute of Electrical and Electronics Engineers, "Local
2711 and Metropolitan Area Networks: Port-Based Network Access
2712 Control", IEEE Standard 802.1X-2004, December 2004.
2714 [802.11] Institute of Electrical and Electronics Engineers,
2715 "Information technology - Telecommunications and
2716 information exchange between systems - Local and
2717 metropolitan area networks - Specific Requirements Part
2718 11: Wireless LAN Medium Access Control (MAC) and
2719 Physical Layer (PHY) Specifications", IEEE Standard
2722 [TTLS-EXT] Hanna, S. and P. Funk, "Key Agility Extensions for EAP-
2723 TTLSv0", Work in Progress, September 2007.
2725 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
2726 Adams, "X.509 Internet Public Key Infrastructure Online
2727 Certificate Status Protocol - OCSP", RFC 2560, June 1999.
2729 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
2730 Housley, R., and W. Polk, "Internet X.509 Public Key
2731 Infrastructure Certificate and Certificate Revocation
2732 List (CRL) Profile", RFC 5280, May 2008.
2734 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
2735 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
2736 RFC 3766, April 2004.
2738 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
2739 J., and T. Wright, "Transport Layer Security (TLS)
2740 Extensions", RFC 4366, April 2006.
2746 Funk & Blake-Wilson Informational [Page 49]
2748 RFC 5281 EAP-TTLSv0 August 2008
2751 [MITM] Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the-
2752 Middle in Tunneled Authentication",
2753 http://www.saunalahti.fi/~asokan/research/mitm.html,
2754 Nokia Research Center, Finland, October 24, 2002.
2756 [SP800-57] National Institute of Standards and Technology,
2757 "Recommendation for Key Management", Special Publication
2765 EMail: PaulFunk@alum.mit.edu
2769 Amstelveenseweg 88-90
2772 EMail: sblakewilson@nl.safenet-inc.com
2802 Funk & Blake-Wilson Informational [Page 50]
2804 RFC 5281 EAP-TTLSv0 August 2008
2807 Full Copyright Statement
2809 Copyright (C) The IETF Trust (2008).
2811 This document is subject to the rights, licenses and restrictions
2812 contained in BCP 78, and except as set forth therein, the authors
2813 retain all their rights.
2815 This document and the information contained herein are provided on an
2816 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2817 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2818 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2819 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2820 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2821 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2823 Intellectual Property
2825 The IETF takes no position regarding the validity or scope of any
2826 Intellectual Property Rights or other rights that might be claimed to
2827 pertain to the implementation or use of the technology described in
2828 this document or the extent to which any license under such rights
2829 might or might not be available; nor does it represent that it has
2830 made any independent effort to identify any such rights. Information
2831 on the procedures with respect to rights in RFC documents can be
2832 found in BCP 78 and BCP 79.
2834 Copies of IPR disclosures made to the IETF Secretariat and any
2835 assurances of licenses to be made available, or the result of an
2836 attempt made to obtain a general license or permission for the use of
2837 such proprietary rights by implementers or users of this
2838 specification can be obtained from the IETF on-line IPR repository at
2839 http://www.ietf.org/ipr.
2841 The IETF invites any interested party to bring to its attention any
2842 copyrights, patents or patent applications, or other proprietary
2843 rights that may cover technology that may be required to implement
2844 this standard. Please address the information to the IETF at
2858 Funk & Blake-Wilson Informational [Page 51]
projects / freeradius.git / blob