Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5281

Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)

Pages: 51
Informational
Errata
Part 3 of 3 – Pages 36 to 51
First   Prev   None

Top   ToC   RFC5281 - Page 36   prevText

14. Security Considerations

14.1. Security Claims

Pursuant to RFC 3748, security claims for EAP-TTLSv0 are as follows: Authentication mechanism: TLS plus arbitrary additional protected authentication(s) Ciphersuite negotiation: Yes Mutual authentication: Yes, in recommended implementation Integrity protection: Yes Replay protection: Yes Confidentiality: Yes Key derivation: Yes Key strength: Up to 384 bits Dictionary attack prot.: Yes Fast reconnect: Yes Cryptographic binding: No Session independence: Yes Fragmentation: Yes Channel binding: No

14.1.1. Authentication Mechanism

EAP-TTLSv0 utilizes negotiated underlying authentication protocols, both in the phase 1 TLS handshake and the phase 2 tunneled authentication. In a typical deployment, at a minimum the TTLS server authenticates to the client in phase 1, and the client authenticates to the AAA/H server in phase 2. Phase 1 authentication of the TTLS server to the client is typically by certificate; the client may optionally authenticate to the TTLS server by certificate
Top   ToC   RFC5281 - Page 37
   as well.  Phase 2 authentication of the client to the AAA/H server is
   typically by password or security token via an EAP or supported non-
   EAP authentication mechanism; this authentication mechanism may
   provide authentication of the AAA/H server to the client as well
   (mutual authentication).

14.1.2. Ciphersuite Negotiation

Ciphersuite negotiation is inherited from TLS.

14.1.3. Mutual Authentication

In the recommended minimum configuration, the TTLS server is authenticated to the client in phase 1, and the client and AAA/H server mutually authenticate in phase 2.

14.1.4. Integrity Protection

Integrity protection is inherited from TLS.

14.1.5. Replay Protection

Replay protection is inherited from TLS.

14.1.6. Confidentiality

Confidentiality is inherited from TLS. Note, however, that EAP- TTLSv0 contains no provision for encryption of success or failure EAP packets.

14.1.7. Key Derivation

Both MSK and EMSK are derived. The key derivation PRF is inherited from TLS, and cryptographic agility of this mechanism depends on the cryptographic agility of the TLS PRF.

14.1.8. Key Strength

Key strength is limited by the size of the TLS master secret, which for versions 1.0 and 1.1 is 48 octets (384 bits). Effective key strength may be less, depending on the attack resistance of the negotiated Diffie-Helman (DH) group, certificate RSA/DSA group, etc. BCP 86 [RFC3766], Section 5, offers advice on the required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
Top   ToC   RFC5281 - Page 38

14.1.9. Dictionary Attack Protection

Phase 2 password authentication is protected against eavesdropping and therefore against offline dictionary attack by TLS encryption.

14.1.10. Fast Reconnect

Fast reconnect is provided by TLS session resumption.

14.1.11. Cryptographic Binding

[MITM] describes a vulnerability that is characteristic of tunneled authentication protocols, in which an attacker authenticates as a client via a tunneled protocol by posing as an authenticator to a legitimate client using a non-tunneled protocol. When the same proof of credentials can be used in both authentications, the attacker merely shuttles the credential proof between them. EAP-TTLSv0 is vulnerable to such an attack. Care should be taken to avoid using authentication protocols and associated credentials both as inner TTLSv0 methods and as untunneled methods. Extensions to EAP-TTLSv0 or a future version of EAP-TTLS should be defined to perform a cryptographic binding of keying material generated by inner authentication methods and the keying material generated by the TLS handshake. This avoids the man-in-the-middle problem when used with key-generating inner methods. Such an extension mechanism has been proposed [TTLS-EXT].

14.1.12. Session Independence

TLS guarantees the session independence of its master secret, from which the EAP-TTLSv0 MSK/EMSK is derived.

14.1.13. Fragmentation

Provision is made for fragmentation of lengthy EAP packets.

14.1.14. Channel Binding

Support for channel binding may be added as a future extension, using appropriate AVPs.

14.2. Client Anonymity

Unlike other EAP methods, EAP-TTLS does not communicate a username in the clear in the initial EAP-Response/Identity. This feature is designed to support anonymity and location privacy from attackers eavesdropping the network path between the client and the TTLS
Top   ToC   RFC5281 - Page 39
   server.  However, implementers should be aware that other factors --
   both within EAP-TTLS and elsewhere -- may compromise a user's
   identity.  For example, if a user authenticates with a certificate
   during phase 1 of EAP-TTLS, the subject name in the certificate may
   reveal the user's identity.  Outside of EAP-TTLS, the client's fixed
   MAC address, or in the case of wireless connections, the client's
   radio signature, may also reveal information.  Additionally,
   implementers should be aware that a user's identity is not hidden
   from the EAP-TTLS server and may be included in the clear in AAA
   messages between the access point, the EAP-TTLS server, and the AAA/H
   server.

   Note that if a client authenticating with a certificate wishes to
   shield its certificate, and hence its identity, from eavesdroppers,
   it may use the technique described in Section 2.1.4 ("Privacy") of
   [RFC5216], in which the client sends an empty certificate list, the
   TTLS server issues a ServerHello upon completion of the TLS handshake
   to begin a second, encrypted handshake, during which the client will
   send its certificate list.  Note that for this feature to work the
   client must know in advance that the TTLS server supports it.

14.3. Server Trust

Trust of the server by the client is established via a server certificate conveyed during the TLS handshake. The client should have a means of determining which server identities are authorized to act as a TTLS server and may be trusted, and should refuse to authenticate with servers it does not trust. The consequence of pursuing authentication with a hostile server is exposure of the inner authentication to attack; e.g., offline dictionary attack against the client password.

14.4. Certificate Validation

When either client or server presents a certificate as part of the TLS handshake, it should include the entire certificate chain minus the root to facilitate certificate validation by the other party. When either client or server receives a certificate as part of the TLS handshake, it should validate the certification path to a trusted root. If intermediate certificates are not provided by the sender, the receiver may use cached or pre-configured copies if available, or may retrieve them from the Internet if feasible. Clients and servers should implement policies related to the Extended Key Usage (EKU) extension [RFC5280] of certificates it receives, to ensure that the other party's certificate usage conforms to the certificate's purpose. Typically, a client EKU, when present, would
Top   ToC   RFC5281 - Page 40
   be expected to include id-kp-clientAuth; a server EKU, when present,
   would be expected to include id-kp-serverAuth.  Note that absence of
   the EKU extension or a value of anyExtendedKeyUsage implies absence
   of constraint on the certificate's purpose.

14.5. Certificate Compromise

Certificates should be checked for revocation to reduce exposure to imposture using compromised certificates. Checking a server certificate against the most recent revocation list during authentication is not always possible for a client, as it may not have network access until completion of the authentication. This problem can be alleviated through the use of the Online Certificate Status Protocol (OCSP) [RFC2560] during the TLS handshake, as described in [RFC4366].

14.6. Forward Secrecy

With forward secrecy, revelation of a secret does not compromise session keys previously negotiated based on that secret. Thus, when the TLS key exchange algorithm provides forward secrecy, if a TTLS server certificate's private key is eventually stolen or cracked, tunneled user password information will remain secure as long as that certificate is no longer in use. Diffie-Hellman key exchange is an example of an algorithm that provides forward secrecy. A forward secrecy algorithm should be considered if attacks against recorded authentication or data sessions are considered to pose a significant threat.

14.7. Negotiating-Down Attacks

EAP-TTLS negotiates its own protocol version prior to, and therefore outside the security established by the TLS tunnel. In principle, therefore, it is subject to a negotiating-down attack, in which an intermediary modifies messages in transit to cause a lower version of the protocol to be agreed upon, each party assuming that the other does not support as high a version as it actually does. The version of the EAP-TTLS protocol described in this document is 0, and is therefore not subject to such an attack. However, any new version of the protocol using a higher number than 0 should define a mechanism to ensure against such an attack. One such mechanism might be the TTLS server's reiteration of the protocol version that it proposed in an AVP within the tunnel, such AVP to be inserted with M bit clear even when version 0 is agreed upon.
Top   ToC   RFC5281 - Page 41

15. Message Sequences

This section presents EAP-TTLS message sequences for various negotiation scenarios. These examples do not attempt to exhaustively depict all possible scenarios. It is assumed that RADIUS is the AAA carrier protocol both between access point and TTLS server, and between TTLS server and AAA/H. EAP packets that are passed unmodified between client and TTLS server by the access point are indicated as "passthrough". AVPs that are securely tunneled within the TLS record layer are enclosed in curly braces ({}). Items that are optional are suffixed with question mark (?). Items that may appear multiple times are suffixed with plus sign (+).

15.1. Successful Authentication via Tunneled CHAP

In this example, the client performs one-way TLS authentication of the TTLS server. CHAP is used as a tunneled user authentication mechanism. client access point TTLS server AAA/H ------ ------------ ----------- ----- EAP-Request/Identity <-------------------- EAP-Response/Identity --------------------> RADIUS Access-Request: EAP-Response passthrough --------------------> RADIUS Access-Challenge: EAP-Request/TTLS-Start <-------------------- EAP-Request passthrough <-------------------- EAP-Response/TTLS: ClientHello -------------------->
Top   ToC   RFC5281 - Page 42
                           RADIUS Access-Request:
                             EAP-Response passthrough
                           -------------------->

                           RADIUS Access-Challenge:
                             EAP-Request/TTLS:
                               ServerHello
                               Certificate
                               ServerKeyExchange
                               ServerHelloDone
                           <--------------------

     EAP-Request passthrough
     <--------------------

     EAP-Response/TTLS:
       ClientKeyExchange
       ChangeCipherSpec
       Finished
     -------------------->

                           RADIUS Access-Request:
                             EAP-Response passthrough
                           -------------------->

                           RADIUS Access-Challenge:
                             EAP-Request/TTLS:
                               ChangeCipherSpec
                               Finished
                           <--------------------

     EAP-Request passthrough
     <--------------------

     EAP-Response/TTLS:
       {User-Name}
       {CHAP-Challenge}
       {CHAP-Password}
     -------------------->

                           RADIUS Access-Request:
                             EAP-Response passthrough
                           -------------------->
Top   ToC   RFC5281 - Page 43
                                             RADIUS Access-Request:
                                               User-Name
                                               CHAP-Challenge
                                               CHAP-Password
                                             -------------------->

                                             RADIUS Access-Accept
                                             <--------------------

                           RADIUS Access-Accept:
                             EAP-Success
                           <--------------------

     EAP-Success
     <--------------------

15.2. Successful Authentication via Tunneled EAP/MD5-Challenge

In this example, the client performs one-way TLS authentication of the TTLS server and EAP/MD5-Challenge is used as a tunneled user authentication mechanism. client access point TTLS server AAA/H ------ ------------ ----------- ----- EAP-Request/Identity <-------------------- EAP-Response/Identity --------------------> RADIUS Access-Request: EAP-Response passthrough --------------------> RADIUS Access-Challenge: EAP-Request/TTLS-Start <-------------------- EAP-Request passthrough <-------------------- EAP-Response/TTLS: ClientHello -------------------->
Top   ToC   RFC5281 - Page 44
                           RADIUS Access-Request:
                             EAP-Response passthrough
                           -------------------->

                           RADIUS Access-Challenge:
                             EAP-Request/TTLS:
                               ServerHello
                               Certificate
                               ServerKeyExchange
                               ServerHelloDone
                           <--------------------

     EAP-Request passthrough
     <--------------------

     EAP-Response/TTLS:
       ClientKeyExchange
       ChangeCipherSpec
       Finished
     -------------------->

                           RADIUS Access-Request:
                             EAP-Response passthrough
                           -------------------->

                           RADIUS Access-Challenge:
                             EAP-Request/TTLS:
                               ChangeCipherSpec
                               Finished
                           <--------------------

     EAP-Request passthrough
     <--------------------

     EAP-Response/TTLS:
       {EAP-Response/Identity}
     -------------------->

                           RADIUS Access-Request:
                             EAP-Response passthrough
                           -------------------->

                                             RADIUS Access-Request:
                                               EAP-Response/Identity
                                             -------------------->
Top   ToC   RFC5281 - Page 45
                                             RADIUS Access-Challenge
                                               EAP-Request/
                                                   MD5-Challenge
                                             <--------------------

                           RADIUS Access-Challenge:
                             EAP-Request/TTLS:
                               {EAP-Request/MD5-Challenge}
                           <--------------------

     EAP-Request passthrough
     <--------------------

     EAP-Response/TTLS:
       {EAP-Response/MD5-Challenge}
     -------------------->

                           RADIUS Access-Request:
                             EAP-Response passthrough
                           -------------------->

                                             RADIUS Access-Challenge
                                               EAP-Response/
                                                   MD5-Challenge
                                             -------------------->

                                             RADIUS Access-Accept
                                             <--------------------

                           RADIUS Access-Accept:
                             EAP-Success
                           <--------------------

     EAP-Success
     <--------------------
Top   ToC   RFC5281 - Page 46

15.3. Successful Session Resumption

In this example, the client and server resume a previous TLS session. The ID of the session to be resumed is sent as part of the ClientHello, and the server agrees to resume this session by sending the same session ID as part of ServerHello. client access point TTLS server AAA/H ------ ------------ ----------- ----- EAP-Request/Identity <-------------------- EAP-Response/Identity --------------------> RADIUS Access-Request: EAP-Response passthrough --------------------> RADIUS Access-Challenge: EAP-Request/TTLS-Start <-------------------- EAP-Request passthrough <-------------------- EAP-Response/TTLS: ClientHello --------------------> RADIUS Access-Request: EAP-Response passthrough --------------------> RADIUS Access-Challenge: EAP-Request/TTLS: ServerHello ChangeCipherSpec Finished <-------------------- EAP-Request passthrough <--------------------
Top   ToC   RFC5281 - Page 47
     EAP-Response/TTLS:
       ChangeCipherSpec
       Finished
     -------------------->

                           RADIUS Access-Request:
                             EAP-Response passthrough
                           -------------------->

                           RADIUS Access-Accept:
                             EAP-Success
                           <--------------------

     EAP-Success
     <--------------------

16. IANA Considerations

IANA has assigned the number 21 (decimal) as the method type of the EAP-TTLS protocol. Mechanisms for defining new RADIUS and Diameter AVPs and AVP values are outlined in [RFC2865] and [RFC3588], respectively. No additional IANA registrations are specifically contemplated in this document. Section 11 of this document specifies how certain authentication mechanisms may be performed within the secure tunnel established by EAP-TTLS. New mechanisms and other functions MAY also be performed within this tunnel. Where such extensions use AVPs that are not vendor-specific, their semantics must be specified in new RFCs; that is, there are TTLS-specific processing rules related to the use of each individual AVP, even though such AVPs have already been defined for RADIUS or DIAMETER. This specification requires the creation of a new registry -- EAP- TTLS AVP Usage -- to be managed by IANA, listing each non-vendor- specific RADIUS/Diameter AVP that has been defined for use within EAP-TTLS, along with a reference to the RFC or other document that specifies its semantics. The initial list of AVPs shall be those listed in Section 13 of this document. The purpose of this registry is to avoid potential ambiguity resulting from the same AVP being utilized in different functional contexts. This registry does not assign numbers to AVPs, as the AVP numbers are assigned out of the RADIUS and Diameter namespaces as outlined in [RFC2865] and [RFC3588]. Only top-level AVPs -- that is, AVPs not encapsulated within Grouped AVPs -- will be registered. AVPs should be added to this registry based on IETF Review as defined in [RFC5226].
Top   ToC   RFC5281 - Page 48

17. Acknowledgements

Thanks to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen Hanna, Ryan Hurst, Avi Lior, and Gabriel Montenegro for careful reviews and useful comments.

18. References

18.1. Normative References

[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
Top   ToC   RFC5281 - Page 49
   [RFC4282]   Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
               Network Access Identifier", RFC 4282, December 2005.

   [RFC4346]   Dierks, T. and E. Rescorla, "The Transport Layer Security
               (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC5216]   Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
               Authentication Protocol", RFC 5216, March 2008.

   [RFC5247]   Aboba, B., Simon, D., and P. Eronen, "Extensible
               Authentication Protocol (EAP) Key Management Framework",
               RFC 5247, August 2008.

18.2. Informative References

[802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004. [802.11] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2007. [TTLS-EXT] Hanna, S. and P. Funk, "Key Agility Extensions for EAP- TTLSv0", Work in Progress, September 2007. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
Top   ToC   RFC5281 - Page 50
   [MITM]      Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the-
               Middle in Tunneled Authentication",
               http://www.saunalahti.fi/~asokan/research/mitm.html,
               Nokia Research Center, Finland, October 24, 2002.

   [SP800-57]  National Institute of Standards and Technology,
               "Recommendation for Key Management", Special Publication
               800-57, May 2006.

Authors' Addresses

Paul Funk 43 Linnaean St. Cambridge, MA 02138 EMail: PaulFunk@alum.mit.edu Simon Blake-Wilson SafeNet Amstelveenseweg 88-90 1054XV, Amsterdam The Netherlands EMail: sblakewilson@nl.safenet-inc.com
Top   ToC   RFC5281 - Page 51
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.