TLS Working Group Y. Nir Internet-Draft Y. Sheffer Intended status: Standards Track Check Point Expires: August 25, 2007 H. Tschofenig Siemens February 21, 2007 Protocol Model for TLS with EAP Authentication draft-nir-tee-pm-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Nir, et al. Expires August 25, 2007 [Page 1] Internet-Draft TEE PM February 2007 Abstract This document describes an extension to the TLS protocol to allow TLS clients to authenticate with legacy credentials using the Extensible Authentication Protocol (EAP). This work follows the example of IKEv2, where EAP has been added to the IKEv2 protocol to allow clients to use different credentials such as passwords, token cards, and shared secrets. When TLS is used with EAP, additional records are sent after the ChangeCipherSpec protocol message, effectively creating an extended handshake before the application layer data can be sent. Each EapMsg handshake record contains exactly one EAP message. Using EAP for client authentication allows TLS to be used with various AAA back-end servers such as RADIUS or Diameter. TLS with EAP may be used for securing a data connection such as HTTP or POP3, where the ability of EAP to work with backend servers can remove that burden from the application layer. This document is a protocol model, rather than a full protocol specification. Nir, et al. Expires August 25, 2007 [Page 2] Internet-Draft TEE PM February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8 3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 8 3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8 3.4. Calculating the Finished message . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10 4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10 5. Performance Considerations . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Nir, et al. Expires August 25, 2007 [Page 3] Internet-Draft TEE PM February 2007 1. Introduction This document describes a new extension to [TLS]. This extension allows a TLS client to authenticate using [EAP] instead of using a certificate, or alternatively performing the authentication at the application level. The extension follows [TLS-EXT]. For the remainder of this document we will refer to this extension as TEE (TLS with EAP Extension). The document is a protocol model as described in [RFC4101]. TEE extends the TLS handshake beyond the regular setup, to allow the EAP protocol to run between the TLS server (called an "authenticator" in EAP) and the TLS client (called a "supplicant"). This allows the TLS architecture to handle client authentication before exposing the server application software to an unauthenticated client. In doing this, we follow the approach taken for IKEv2 in [IKEv2]. However, similar to regular TLS, we protect the user identity by only sending the client identity after the server has authenticated. In this our solution defers from that of IKEv2. Currently used applications use TLS to authenticate the server only. After that, the application takes over, and presents a login screen where the user is expected to present their credentials. This creates several problems. It allows a client to access the application before authentication, thus creating a potential for anonymous attacks on non-hardened applications. Additionally, web pages are not particularly well suited for long shared secrets and for certain devices such as USB tokens. TEE allows full mutual authentication to occur for all these applications within the TLS exchange. The application receives control only when the user is identified and authenticated. The authentication can be built into the server infrastructure by connecting to an AAA server. The client side can be integrated into client software such as web browsers and mail clients. An EAP infrastructure is already built-in to some operating systems providing a user interface for each authentication method within EAP. We intend TEE to be used for various protocols that use TLS such as HTTPS, in cases where certificate based authentication is not practical. This includes web-based mail services, online banking, premium content websites and mail clients. Another class of applications that may see benefit from TEE are TLS based VPN clients used as part of so-called "SSL VPN" products. No such client protocols have so far been standardized. Nir, et al. Expires August 25, 2007 [Page 4] Internet-Draft TEE PM February 2007 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Nir, et al. Expires August 25, 2007 [Page 5] Internet-Draft TEE PM February 2007 2. Operating Environment TEE will work between a client application and a server application, taking care of all encryption and authentication. Client Server +-------------------------+ +------------------------+ | |GUI| | Client | |TLS+-+-----+-+TLS| |Server | | | +-^-+ |Software| +-^-+ | +-+-^-+ |Application | | | | +--------+ | | | | |Software | | | | | | | | +------------+ | | +-v----------------v-+ | | | | | | EAP | | +---|--------------------+ | | Infrastructure | | | | +--------------------+ | | +--------+ +-------------------------+ | | AAA | | | Server | +----- | +--------+ The above diagram shows the typical deployment. The client has software that either includes a UI for some EAP methods, or else is able to invoke some operating system EAP infrastructure that takes care of the user interaction. The server is configured with the address and protocol of the AAA server. Typically the AAA server communicates using the RADIUS protocol with EAP ([RADIUS] and [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]). As stated in the introduction, we expect TEE to be used in both browsers and applications. Further uses may be authentication and key generation for other protocols, and tunneling clients, which so far have not been standardized. Nir, et al. Expires August 25, 2007 [Page 6] Internet-Draft TEE PM February 2007 3. Protocol Overview The TEE extension defines the following: o A new extension type called tee_supported, used to indicate that the client supports this extension. o A new message type for the handshake protocol, called InterimAuth, which is used to sign previous messages. o A new message type for the handshake protocol, called EapMsg, which is used to carry a single EAP message. The diagram below outlines the protocol structure. For illustration purposes only, we use the [I-D.dpotter-pppext-eap-mschap] EAP method . Client Server ------ ------ ClientHello(*) --------> ServerHello(*) (Certificate) ServerKeyExchange EapMsg(Identity-Request) <-------- ServerHelloDone ClientKeyExchange (CertificateVerify) ChangeCipherSpec InterimAuth EapMsg(Identity-Reply) --------> ChangeCipherSpec InterimAuth EapMsg(MS-CHAP-v2-Request) <-------- EapMsg(MS-CHAP-v2-Reply) --------> EapMsg(Success) <-------- Finished Finished --------> (*) The ClientHello and ServerHello include the tee_supported extension to indicate support for TEE The client indicates in the first message its support for TEE. The server sends an EAP identity request in the reply. The client sends the identity reply after the handshake completion. The EAP request- response sequence continues until the client is either authenticated or rejected. Nir, et al. Expires August 25, 2007 [Page 7] Internet-Draft TEE PM February 2007 3.1. The tee_supported Extension The tee_supported extension is a ClientHello and ServerHello extension as defined in section 2.3 of [TLS-EXT]. The extension_type field is TBA by IANA. The extension_data is zero-length. 3.2. The InterimAuth Handshake Message The InterimAuth message is identical in syntax to the Finished message described in section 7.4.9 of [TLS]. It is calculated in exactly the same way. The semantics, however, are somewhat different. The "Finished" message indicates that application data may now be sent. The "InterimAuth" message does not indicate this. Instead, further handshake messages are needed. Depending on the EAP method used, the Finished message may be calculated differently. See Section 3.4 for details. The HandshakeType value for the InterimAuth handshake message is TBA by IANA. 3.3. The EapMsg Handshake Message The EapMsg handshake message carries exactly one EAP message as defined in [EAP]. The HandshakeType value for the EapMsg handshake message is TBA by IANA. The EapMsg message is used to tunnel EAP messages between the authentication server, which may be the co-located with the TLS server, or may be a separate AAA server, and the supplicant, which is co-located with the TLS client. TLS on either side receives the EAP data from the EAP infrastructure, and treats it as opaque. TLS does not make any changes to the EAP payload or make any decisions based on the contents of an EapMsg handshake message. 3.4. Calculating the Finished message If the EAP method is key-generating, the Finished message is calculated as follows: Nir, et al. Expires August 25, 2007 [Page 8] Internet-Draft TEE PM February 2007 struct { opaque verify_data[12]; } Finished; verify_data PRF(MSK, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; The finished_label is defined exactly as in section 7.4.9 of [TLS]. The handshake_messages, similar to regular TLS is all of the data from all messages in this handshake, including any EapMsg and InterimAuth messages, up to but not including this Finished message. This is the concatenation of all the Handshake structures, as defined in section 7.4 of [TLS] and here, exchanged thus far. The MSK is typically received from the AAA server over the RADIUS or Diameter protocol. If the EAP method is not key-generating, then the Finished message is calculated exactly as described in [TLS]. Such methods however, are NOT RECOMMENDED. See Section 4.1 for details. Nir, et al. Expires August 25, 2007 [Page 9] Internet-Draft TEE PM February 2007 4. Security Considerations 4.1. InterimAuth vs. Finished In regular TLS, the Finished message provides two functions: it signs all previous messages, and it signals that application data can now be used. In TEE, we sign the previous messages twice. Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate keys in addition to authenticating clients. Such methods are said to be resistant to MITM attacks as discussed in [MITM]. Such methods are called key-generating methods. To realize the benefit of such methods, we need to verify the key that was generated within the EAP method. This is referred to as the MSK in EAP. In TEE, the InterimAuth message signs all previous messages with the master_secret, just like the Finished message in regular TLS. The Finished message signs all previous messages using the MSK if such exists. If not, then the messages are signed with the master_secret as in regular TLS. The need for signing twice arises from the fact that we need to use both the master_secret and the MSK. It was possible to use just one Finished record and blend the MSK into the master_secret. However, this would needlessly complicate the protocol and make security analysis more difficult. Instead, we have decided to follow the example of IKEv2, where two AUTH payloads are exchanged. It should be noted that using non-key-generating methods may expose the client to a MITM attack if the same MITM method is used in some other situation, in which the EAP is done outside of a protected tunnel with an authenticated server. Unless it can be determined that the EAP method is never used in such a situation, non-key- generating methods SHOULD NOT be used. 4.2. Identity Protection Unlike [TLS-PSK], TEE provides identity protection for the client. The client's identity is hidden from a passive eavesdropper using TLS encryption, and it is not sent to the server until after the server's identity has been authenticated by verifying the certificate. Active attacks are thwarted by the server authentication using a certificate or by using a suitable EAP method. We could save one round-trip by having the client send its identity within the Client Hello message. This is similar to TLS-PSK. However, we believe that identity protection is a worthy enough goal, Nir, et al. Expires August 25, 2007 [Page 10] Internet-Draft TEE PM February 2007 so as to justify the extra round-trip. Nir, et al. Expires August 25, 2007 [Page 11] Internet-Draft TEE PM February 2007 5. Performance Considerations Regular TLS adds two round-trips to a TCP connection. However, because of the stream nature of TCP, the client does not really need to wait for the server's Finished message, and can begin sending application data immediately after its own Finished message. In practice, many clients do so, and TLS only adds one round-trip of delay. TEE adds as many round-trips as the EAP method requires. For example, EAP-MD5 requires 1 round-trip, while EAP-SIM requires 2 round-trips. Additionally, the client MUST wait for the EAP-Success message before sending its own Finished message, so we need at least 3 round-trips for the entire handshake. The best a client can do is two round-trips plus however many round-trips the EAP method requires. It should be noted, though, that these extra round-trips save processing time at the application level. Two extra round-trips take a lot less time than presenting a log-in web page and processing the user's input. It should also be noted, that TEE reverses the order of the Finished messages. In regular TLS the client sends the Finished message first. In TEE it is the server that sends the Finished message first. This should not affect performance, and it is clear that the client may send application data immediately after the Finished message. Nir, et al. Expires August 25, 2007 [Page 12] Internet-Draft TEE PM February 2007 6. IANA Considerations IANA is asked to assign an extension type value from the "ExtensionType Values" registry for the tee_supported extension. IANA is asked to assign two handshake message types from the "TLS HandshakeType Registry", one for "EapMsg" and one for "InterimAuth". Nir, et al. Expires August 25, 2007 [Page 13] Internet-Draft TEE PM February 2007 7. Acknowledgments The TLS Innel Application Extension work ([TLS/IA]) has inspired the authors to create this simplified work. TLS/IA provides a somewhat different approach to integrating non-certificate credentials into the TLS protocol, in addition to several other features available from the RADIUS namespace. The authors would also like to thanks the various contributors to [IKEv2] whose work inspired this one. Nir, et al. Expires August 25, 2007 [Page 14] Internet-Draft TEE PM February 2007 8. References 8.1. Normative References [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. 8.2. Informative References [Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [Diameter] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [I-D.dpotter-pppext-eap-mschap] Potter, D. and J. Zamick, "PPP EAP MS-CHAP-V2 Authentication Protocol", draft-dpotter-pppext-eap-mschap-01 (work in progress), January 2002. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunneled Authentication Protocols", October 2002. [RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Nir, et al. Expires August 25, 2007 [Page 15] Internet-Draft TEE PM February 2007 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005. [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and T. Hardjono, "TLS Inner Application Extension (TLS/IA)", draft-funk-tls-inner-application-extension-03 (work in progress), June 2006. Nir, et al. Expires August 25, 2007 [Page 16] Internet-Draft TEE PM February 2007 Authors' Addresses Yoav Nir Check Point Software Technologies Ltd. 3A Jabotinsky St. Ramat Gan 52520 Israel Email: ynir@checkpoint.com Yaron Sheffer Check Point Software Technologies Ltd. 3A Jabotinsky St. Ramat Gan 52520 Israel Email: yaronf at checkpoint dot com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Nir, et al. Expires August 25, 2007 [Page 17] Internet-Draft TEE PM February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nir, et al. Expires August 25, 2007 [Page 18]