Network Working Group N. Williams Internet-Draft Sun Intended status: Standards Track April 17, 2009 Expires: October 19, 2009 TLS Extension for Optimizing Application Protocols, Specifically SASL with GSS-API mechanisms draft-williams-tls-app-sasl-opt-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 October 19, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Williams Expires October 19, 2009 [Page 1] Internet-Draft TLS/SA April 2009 Abstract This document specifies an extension to Transport Layer Security (TLS) for carrying application data which is suitable for delayed integrity protection and does not require privacy protection. In particular we describe how to use this extension to reduce the number of round trips needed for application-layer authentication, specifically Simple Authentication (SASL), and through it, Generic Security Services (GSS-API). The use of this extension to optimize SASL/GSS-API authentication is termed "TLS/SA". This extension can also be used to optimize application protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3 2. TLS Extensions for Optimization of Application protocols . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Application Hello Messages . . . . . . . . . . . . . . . . 7 3.1. Optimizing SASL Mechanism Negotiation . . . . . . . . . . 7 4. Application Data Protocol Early Start . . . . . . . . . . 8 5. Use with StartTLS-like Protocols . . . . . . . . . . . . . 9 6. Using TLS with the GSS-API . . . . . . . . . . . . . . . . 10 7. Using these Extensions with Existing SASL Applications . . 11 8. TLS/SA (TLS + SASL) . . . . . . . . . . . . . . . . . . . 12 8.1. TLS/SA Exchanges . . . . . . . . . . . . . . . . . . . . . 12 8.1.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . 16 9. Non-SASL Optimizations of Existing Application Protocols . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Impact on Concentrators . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . 22 Williams Expires October 19, 2009 [Page 2] Internet-Draft TLS/SA April 2009 1. Introduction Many applications use TLS [RFC5246] and then Simple Authentication and Security Layers (SASL) [RFC4422] on top of TLS. This requires at least two round trips for TLS, then one round trip for SASL mechanism negotiation, then as many round trips as the negotiated SASL mechanism requires. One and a half of the TLS round trips can carry extensions such that we could piggyback some application data on those TLS messages to save up to two round trips. This document specifies how to take advantage of TLS extensions to reduce the number of round trips needed altogether. First we define a TLS extension for use in Client Hello and Handshake messages. This extension will carry typed application data. Then we describe how to reduce the number of round trips for SASL applications. And through the new SASL/GSS-API bridge [I-D.ietf-sasl-gs2] we obtain support for use of GSS-API [RFC2743] mechanisms as well. [RFC2743] applications. Altogether we achieve a one and a half round trip reduction for SASL applications. In the case of SASL applications we use the first TLS round trip to optimize the SASL mechanism negotiation. Then we use the client's handshake message to send the first authentication message of the selected SASL mechanism. Note that the TLS channel binding [RFC5056] can be made available at that time, thus no special considerations apply to how channel binding is done (but see Section 8.1.1 below). Use of channel binding protects against man-in-the-middle attacks, including downgrade attacks on mechanism negotiation. This extension is motivated by: o a desire to reduce the number of round trips needed by SASL and GSS-API applications running over TLS; o a desire to replace an earlier proposal for "TLS/GSS" with one that passes muster at the TLS WG; o a desire to provide a profile that new applications may use for TLS with GSS-API for user authentication. The use of this extension to optimize SASL/GSS-API authentication is termed "TLS/SA". 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]. Williams Expires October 19, 2009 [Page 3] Internet-Draft TLS/SA April 2009 2. TLS Extensions for Optimization of Application protocols When a client application wishes to exchange one or more application messages prior to the conclusion of a TLS exchange it uses the TLS Client Hello message extension to a) indicate its intention to the server, and b) optionally send the first application message to the server. These messages will not have any privacy or integrity protection applied by TLS unless a ChangeCipherSpec has been done earlier (i.e., unless the application has already done one TLS handshake). When this message is received the server MUST either ignore the extension or pass it to the application, which then MUST respond to that application data via a new handshake message (see below). If the server ignores it then the client will discover that the server does not support this extension when the client receives the server's handshake messages. Otherwise there must be a corresponding application data handshake message in the server's response, and that indicates that the server TLS and application implementations support this extension. The extension contents are defined by the application. In order to save the application having to encode application data types and lengths we define two application data extension types and we allow the Client Hello to carry one of each of these extensions: o app_hello () o sasl_sml_req () o early_start_req () It is the application's responsibility to define the contents of the app_hello client Hello extension. The sasl_sml_req (SASL server mechanism list request) message contains an empty payload. The early_start_req extension requests permission to start the application data record protocol before receiving the server's Finished message (but after sending the client's). A server that supports this extension MUST include the same extension in its Hello message with the same value. The value of early_start_req consists of an encoded enum that indicates the kind of application data that will be sent early: enum { app_protocol (0), generic_sasl(1), (255) } EarlyStartProto; Williams Expires October 19, 2009 [Page 4] Internet-Draft TLS/SA April 2009 We also define new Handshake messages that may be used after the Client Hello messages: enum { finished(20), app_hello(), sasl_sml(), sasl_msg(), (255) } HandshakeType; struct { HandshakeType msg_type; /* handshake type */ uint24 length; /* bytes in message */ select (HandshakeType) { case hello_request: HelloRequest; ... /* Application pre-Finished message data */ case app_hello: AppHello; /* SASL server mechanism list */ case sasl_sml: SaslSML; } body; } Handshake; opaque AppHello<2^16-1>; opaque SaslSML<2^16-1>; A generic application protocol using these extensions might look like: Williams Expires October 19, 2009 [Page 5] Internet-Draft TLS/SA April 2009 Client Server ClientHello w/ sasl_sml_req app_hello early_start_req --------> ServerHello w/ early_start_req AppHello* SaslSML* Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished SASL auth message as data --------> [ChangeCipherSpec] Finished <-------- SASL auth message SASL auth messages <-------> SASL auth messages <-------- Outcome of SASL authentication Application Data <-------> Application Data Williams Expires October 19, 2009 [Page 6] Internet-Draft TLS/SA April 2009 3. Application Hello Messages The app_hello client Hello message extension can be used to send arbitrary application-specific messages in the client Hello. The application MUST NOT use this extension unless both of these requirements are met: a) the application data being sent in the app_hello and the reply expected in the AppHello reply MUST NOT require privacy protection unless this is a secondary TLS handshake, b) the application on the server side knows unambiguously what data to expect in an app_hello or it is safe for the application on the server side to ignore the app_hello if it does not understand it. For example, SMTP could use the app_hello extension to send its EHLO before the TLS handshake completes. The app_hello extension data and AppHello handshake message are integrity protected once the TLS Finished message exchange completes. 3.1. Optimizing SASL Mechanism Negotiation A client wishing to optimize SASL mechanism negotiation MUST send a sasl_sml_req extension in the client's TLS Hello message. The client MUST NOT send a payload in its sasl_sml_req client hello extension. If the server supports SASL mechanism negotiation optimization and the server's mechanism list is shorter than 2^16 - 1 bytes then the server MUST include a SaslSML message in its reply to the client. The payload of the server's SaslSML message MUST be a comma-separated list of SASL mechanism names (note: no NUL terminator is needed, but if present the client MUST ignore the NUL). Williams Expires October 19, 2009 [Page 7] Internet-Draft TLS/SA April 2009 4. Application Data Protocol Early Start Applications may request that the TLS application data record protocol comment after the client's Finished message is sent but before the server's Finished message is received. To do this the client includes the client Hello extension 'early_start_req' in its Hello message with a value of 'app_protocol'. If the server responds with the same extension in its server Hello message then the server will allow the early start of the TLS application data record protocol. This extension MUST NOT be used if the nature of the application data to be sent early is such that the server must be authenticated to the client before sending the data. For example, passwords MUST NOT be sent early. Williams Expires October 19, 2009 [Page 8] Internet-Draft TLS/SA April 2009 5. Use with StartTLS-like Protocols These extensions can be used over "raw TLS" and "StartTLS" protocols equally. Williams Expires October 19, 2009 [Page 9] Internet-Draft TLS/SA April 2009 6. Using TLS with the GSS-API In order to use TLS with the GSS-API for user and/or server authentication an application must use "TLS/SA" as described below, using the SASL/GS2 family of SASL mechanisms [I-D.ietf-sasl-gs2] that maps GSS-API mechanisms onto SASL ones. See the next section. Williams Expires October 19, 2009 [Page 10] Internet-Draft TLS/SA April 2009 7. Using these Extensions with Existing SASL Applications Applications that already support SASL can be trivially reduce the number of round trips needed to authenticate by two (2) as follows: a) optimize the SASL mechanism negotiation as described in Section 3.1, b) start the application data protocol early as described in Section 4. Having listed the server's SASL mechanism list early the application can then immediately begin authentication using its preferred SASL mechanism. The application MUST NOT use any SASL mechanism that might send credentials (passwords) in cleartext or cleartext-equivalent ways before the TLS handshake completes (i.e., before the server's Finished message is received and validated). It is RECOMMENDED that applications use only SASL/GS2 [I-D.ietf-sasl-gs2] mechanisms using channel binding to TLS. Channel binding to TLS is RECOMMENDED. Williams Expires October 19, 2009 [Page 11] Internet-Draft TLS/SA April 2009 8. TLS/SA (TLS + SASL) In this section we describe a generic way to use SASL/GS2 [I-D.ietf-sasl-gs2] mechanisms in TLS applications in a round trip optimized manner. We call this protocol "TLS/SA". TLS/SA defines those parts of the SASL authentication process which SASL [RFC4422] leaves to applications. Existing SASL applications MAY, but need not use TLS/SA; instead existing SASL applications SHOULD use the method described in Section 7. TLS/SA defines the framing of SASL mechanism messages and the "outcome of authentication" messages. TLS/SA saves a round trip when the last authentication message is sent by the server, in which case the outcome of authentication message is sent in the same half round trip as the last authentication message. SASL mechanism negotiation in TLS/SA is done as described in Section 3.1. SASL mechanisms which are not SASL/GS2 mechanisms MUST NOT be used. Channel binding to TLS is REQUIRED. 8.1. TLS/SA Exchanges A client wishing to optimize a SASL/GS2 mechanism MUST: a) negotiate a SASL mechanism to use using the method described in Section 3.1, b) use channel binding from SASL authentication to the TLS channel, c) begin the SASL mechanism authentication message exchange immediately after the client's Finished message as application data without waiting for the server's Finished message. The first SASL mechanism authentication message (always sent by the client in the case of SASL/GS2 mechanisms) MUST be prefixed with, and in the following order: 1. the SASL name of the mechanism, NUL-terminated; 2. a NUL-terminated, comma-separated list of language tags [RFC4646]; 3. a four octet, network byte order binary message length. Authentication messages MUST NOT be longer than 2^24 octets (i.e., the 8 most significant bits of the message length MUST be zeros); if SASL produces such messages then authentication MUST FAIL. The server's "outcome of authentication exchange" message MUST consist of a UTF-8 string containing supplementary information Williams Expires October 19, 2009 [Page 12] Internet-Draft TLS/SA April 2009 prefixed with a network byte order four byte unsigned binary length of of that string, with the most significant bit of the length set to 1. The next most significant bit MUST be 1 to indicate success, 0 to indicate failure. The supplementary information MUST NOT be longer than 2^16-1 bytes. The supplementary information SHOULD be a human- readable message localized to a language selected from the client's language tags selected according to [RFC4647], or to one of the server's choice if the client sent no language tags or the server did not support localizations to any of them. Where empty messages are required by SASL the application should send a zero-valued length and an empty message. If the last SASL mechanism authentication message is to be sent by the server then the server's outcome of authentication message MUST immediately follow the last mechanism message. That is: there is no need for the client to send an empty message in response to the last mechanism message just to get the outcome of authentication message. This saves another round trip. If authentication fails then the client MAY retry authentication, and indicates this by sending four octets with all bits set, followed by the first SASL authentication message of the next exchange. Otherwise, the client MUST send four octets with all bits cleared prior to commencing the application protocol. The server MAY abort the TLS connection on re-authentication. If authentication succeeds then the application protocol takes over the TLS record protocol contents. With a one round trip SASL/GS2 mechanism the protocol then looks like: Williams Expires October 19, 2009 [Page 13] Internet-Draft TLS/SA April 2009 Client Server ClientHello w/ sasl_sml_req early_start_req --------> ServerHello w/ early_start_req SaslSML Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished SASL auth message as data --------> [ChangeCipherSpec] Finished SASL auth message <-------- Outcome of SASL authentication Application Data <-------> Application Data With a one and one half round trip mechanism the protocol looks like: Williams Expires October 19, 2009 [Page 14] Internet-Draft TLS/SA April 2009 Client Server ClientHello w/ sasl_sml_req early_start_req --------> ServerHello w/ early_start_req SaslSML Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished SASL auth message as data --------> [ChangeCipherSpec] Finished <-------- SASL auth message SASL auth message --------> <-------- Outcome of SASL authentication Application Data <-------> Application Data And with a two round trip mechanism the protocol looks like: Williams Expires October 19, 2009 [Page 15] Internet-Draft TLS/SA April 2009 Client Server ClientHello w/ sasl_sml_req early_start_req --------> ServerHello w/ early_start_req SaslSML Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished SASL auth message as data --------> [ChangeCipherSpec] Finished <-------- SASL auth message SASL auth message --------> SASL auth message <-------- Outcome of SASL authentication Application Data <-------> Application Data The reader can figure out what the protocol looks like for SASL mechanisms with more than two round trips from the above.. 8.1.1. Channel Binding Existing TLS channel binding types that are suitable for use with SASL in this facility are: o tls-server-end-point [tls-server-end-point] o tls-unique [tls-unique] See the IANA channel binding type registry for more information about these channel binding types. The channel binding type to use is to be selected as described in [I-D.ietf-sasl-channel-bindings]. Williams Expires October 19, 2009 [Page 16] Internet-Draft TLS/SA April 2009 9. Non-SASL Optimizations of Existing Application Protocols In this section and its sub-sections we INFORMATIVELY how a number of existing TLS application protocols might be modified to take advantage of the application data extension for optimization of the application protocol. It is crucial that clients only use the app_hello extension for operations that do not require that the user already be authenticated (the server application MUST reject such uses of app_hello) or that require privacy protection. There are no operations in IMAP and POP3, for example, which are suitable for optimization via app_hello, but there are for SMTP and LDAP. That's because IMAP and POP3 deal exclusively with user data, while SMTP and LDAP have some operations or objects which can be executed publicly and without user authentication (see below). 9.1. LDAP In the case of LDAP the app_hello extension can be used to send a single LDAP message, typically a search for the root DSE object. If the server supports this extension then the app_hello handshake message can be used to return the result. If the server does not support this extension then the client can repeat its search after the TLS handshake is completed and the TLS record protocol begins to operate. 9.2. SMTP Clients may use the app_hello extension to send a EHLO SMTP command to the server, and the server may send the SMTP reply to it in a app_hello handshake message. Williams Expires October 19, 2009 [Page 17] Internet-Draft TLS/SA April 2009 10. Impact on Concentrators This protocol is designed to have minimal impact on TLS server-side proxies (a.k.a. concentrators). The minimal changes to make to TLS concentrators in order to support this protocol are: o Add a configuration parameter through which the administrator may list the SASL mechanisms available to the application servers behind the concentrator; o Add a configuration parameter through which the administrator may indicate whether the application supports the 'generic-sasl' framing defined in Section 8. o Add support for sasl_sml_req and the corresponding SaslSML message using the server SASL mechanism list from the configuration parameter mentioned in the previous item; o Add support for early_start_req, which means that the concentrator MUST NOT consider it an error to receive TLS application data record messages prior to sending the concentrator's Finished message. Implementors may also want to add support for unique channel binding types, such as the 'tls-unique' channel binding type. This requires being able to communicate to the application server the tls-unique channel binding for each TLS connection, probably via an out of band mechanism (though if the application protocol is HTTP then perhaps the concentrator could use an HTTP request header to do this). Implementors may also add a way to communicate app_hello/AppHello messages to the application. Williams Expires October 19, 2009 [Page 18] Internet-Draft TLS/SA April 2009 11. IANA Considerations When this document is approved for the Standards-Track the &lgt;TBD> values above will be filled in and the IANA TLS ExtensionType and HandshakeType registries will have to be updated to reflect these assignments. (These registries require IETF Consensus and Standards action, respectively.) Williams Expires October 19, 2009 [Page 19] Internet-Draft TLS/SA April 2009 12. Security Considerations The security considerations of [RFC4422], [I-D.ietf-sasl-channel-bindings], [RFC5246] and [RFC5056] apply, as do those of [RFC2743] when used via the SASL/GS2 bridge [I-D.ietf-sasl-gs2]. The initial SASL authentication message is not protected by the TLS client's Finished message, but it is protected by the server's Finished message. Channel binding must be used in the optimized authentication case. Therefore the server can detect modifications to the initial SASL authentication message to the best of the selected SASL mechanism's ability, and the client, as usual, can abort the TLS session if the server's Finished message cannot be validation. The SASL mechanism negotiation is protected by the TLS Finished messages. Williams Expires October 19, 2009 [Page 20] Internet-Draft TLS/SA April 2009 13. References 13.1. Normative References [I-D.ietf-sasl-channel-bindings] Williams, N., "SASL And Channel Binding", draft-ietf-sasl-channel-bindings-02 (work in progress), April 2009. [I-D.ietf-sasl-gs2] Josefsson, S. and N. Williams, "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-11 (work in progress), March 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 13.2. Informative References [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [tls-server-end-point] Zhu, L., "Registration of TLS server end-point channel bindings", July 2008. [tls-unique] Zhu, L., "Registration of TLS unique channel binding (generic)", July 2008. Williams Expires October 19, 2009 [Page 21] Internet-Draft TLS/SA April 2009 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US Email: Nicolas.Williams@sun.com Williams Expires October 19, 2009 [Page 22]