tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5281

 
 
 

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

Part 3 of 3, p. 36 to 51
Prev RFC Part

 


prevText      Top      Up      ToC       Page 36 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.