TLS Extension for Optimizing Application Protocols, Specifically SASL with GSS-API mechanisms
draft-williams-tls-app-sasl-opt-04.txt

Abstract

This document specifies Hello extensions to Transport Layer Security (TLS). One extension is used for carrying application data which is suitable for delayed integrity protection and does not require privacy protection. Another extension is used to negotiate an early start to the application data protocol in the case of initial TLS connections (i.e., which do not resume sessions).

We describe how to use these extensions to reduce the number of round trips needed for application-layer authentication, by piggy-backing Simple Authentication (SASL) mechanism negotiation on the first leg of a TLS handshake and the first round of SASL authentication messages on the second leg of the same TLS handshake. Through SASL we get support for Generic Security Services (GSS-API) mechanisms. Channel binding is used from SASL authentication to the TLS channel. This results in a two round-trip optimization for applications that use SASL on top of TLS.

We also provide generic framing for SASL authentication messages which, combined with the use of these extensions, will be referred to as "TLS/SA". These extensions can also be used to optimize application protocols separately from SASL.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

This Internet-Draft will expire on January 28, 2011.

Copyright Notice

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
1.1.  Conventions used in this document
2.  TLS Extensions for Optimization of Application protocols
3.  Sending Application Data in TLS Hello Messages
3.1.  Optimizing SASL Mechanism Negotiation
4.  Application Data Protocol Early Start
5.  Use with StartTLS-like Protocols
6.  Using TLS with the GSS-API
7.  Using these Extensions with Existing SASL Applications
8.  TLS/SA (TLS + SASL with generic framing of SASL authentication messages)
8.1.  TLS/SA Exchanges
9.  Channel Binding
10.  Application Control of Authentication and Applicability of TLS/SA
11.  Contrived Examples of Non-SASL Optimizations of Existing Application Protocols
11.1.  Contrived Example: LDAP
11.2.  Contrived Example: SMTP
12.  Impact on TLS Concentrators
13.  IANA Considerations
14.  Security Considerations
15.  References
15.1.  Normative References
15.2.  Informative References
§  Author's Address

1.  Introduction

Many applications use TLS [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) and then Simple Authentication and Security Layers (SASL) [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) 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. The TLS Hello exchanges can can carry extensions bearing application data. We could also define additional non-Hello Handshake extensions to carry application data, but it suffices to be able to start using TLS application records as soon as the client's Finished message is sent, without waiting for a server reply (in the new TLS session case). Here we describe how to use such TLS extensions to reduce the number of round trips needed for SASL mechanism negotiation and authentication.

We define a TLS extension for use in Hello messages. This extension will carry typed application data. We also define a TLS Hello extension for negotiating an early start for the TLS application record protocol.

Through the new SASL to GSS-API mechanism bridge, GS2 [RFC5801] (Josefsson, S. and N. Williams, “Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family,” July 2010.), we obtain support for use of GSS-API [RFC2743] (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.) security mechanisms. Altogether we achieve up to a two round-trip reduction for applications using SASL over TLS.

We use the first TLS round trip to optimize the SASL mechanism negotiation by piggybacking the mechanism negotiation on TLS Hello messages. By negotiating an early start to the TLS application record protocol we can send the first authentication message of the selected SASL mechanism in the second leg of the TLS handshake, immediately after the client's Finished message is sent. Note that the TLS channel binding [RFC5929] (Altman, J., Williams, N., and L. Zhu, “Channel Bindings for TLS,” July 2010.) is available just in time to start the SASL authentication at that time, thus no special considerations apply to how channel binding is done. Use of channel binding protects against man-in-the-middle attacks as well as downgrade attacks on mechanism negotiation.

These extensions are motivated by:

• a desire to reduce the number of round trips needed by SASL and GSS-API applications running over TLS;
• a desire to replace an earlier proposal for "TLS/GSS" with one that passes muster at the TLS implementor community;
• a desire to provide a profile that new applications may use for TLS with SASL and/or GSS-API for user authentication.

The use of these extensions to optimize SASL/GSS-API authentication is hereby termed "Transport Layer Security with Simple Authentication", or "TLS/SA" for short.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 TLS client Hello message extensions to a) request permission to start the application record protocol early, and b) optionally send the first application message to the server. Such application data MUST NOT require privacy or integrity protection, unless either a) the current TLS handshake is part of a renegotiation [RFC5746] (Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, “Transport Layer Security (TLS) Renegotiation Indication Extension,” February 2010.) where the previous negotiation established cipher suites that provide the required protection or b) deferred integrity protection is sufficient.

When an application data bearing Hello message is received the server will either ignore the extension or pass it to the application, which then may respond to that application data via the server's Hello message. If the server or server application ignores the client's Hello extension then the client will discover that the server does not support this extension when the client receives the server's Hello.

The extension contents are defined by the application. In order to save the application having to encode application "type" information we define application data extension types and we allow the Client Hello to carry one of each of these extensions:

• app_hello (<TBD>)
• sasl_sml (<TBD>)
• early_start (<TBD>)

It is the application's responsibility to define the contents of the app_hello Hello extension.

The sasl_sml Hello extension represents a SASL server mechanism list request. The server returns this list, if it can, via the same Hello extension in its Hello. The client's sasl_sml MUST be have an empty value. The client will use this server's SASL mechanism list to pick a suitable SASL mechanism. See Section 3.1 (Optimizing SASL Mechanism Negotiation) for details of the encoding of the server's SASL mechanism list.

The early_start extension requests permission to start the application data record protocol on the client-side immediately after sending the client's Finished message (which, in the case of initial TLS connections, is sent before receiving the server's Finished message). Servers that supports this extension MUST include the same extension in its Hello message with the same value. The value of early_start consists of an encoded enum (EarlyStartProto) that indicates the kind of application data that will be sent early:

      enum { app_protocol (0), generic_sasl(1), (255)
      } EarlyStartProto;

If the value of early_start is app_protocol (0), then the contents of format of the early start application data is defined by the application; see Section 7 (Using these Extensions with Existing SASL Applications) and Section 11 (Contrived Examples of Non-SASL Optimizations of Existing Application Protocols). If the value of early_start is generic_sasl(1) then the application is said to be a "TLS/SA" application, and SASL messages will be exchanged as application records, with generic framing described in Section 8 (TLS/SA (TLS + SASL with generic framing of SASL authentication messages)), until authentication succeeds or fails, at which point the actual application protocol will take over the TLS application records.

A generic application protocol using these TLS extensions might look like:

   Client                                               Server

   ClientHello w/ sasl_sml
               early_start     -------->
                                                ServerHello w/
                                                      sasl_sml
                                                   early_start
                                                  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

   Client                                               Server

   ClientHello w/ sasl_sml
               early_start     -------->
                                                ServerHello w/
                                                      sasl_sml
                                                   early_start
                                            [ChangeCipherSpec]
                                <--------             Finished
   [ChangeCipherSpec]
   Finished
   SASL auth message as data    -------->
                                <--------    SASL auth message
   SASL auth messages           <------->   SASL auth messages
                                <--------      Outcome of SASL
                                                authentication
   Application Data             <------->     Application Data

3.  Sending Application Data in TLS 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:

1. the application data being sent in the app_hello and the reply expected in the app_hello reply MUST NOT require privacy protection unless either the TLS connection is part of a renegotiation of another that provides the required protection and/or deferred integrity protetion is sufficient;
2. the application on the server side knows unambiguously what data to expect in an app_hello.

For example, SMTP could use the app_hello extension to send its EHLO before the TLS handshake completes.

The app_hello extension data and early-start application records are ultimately integrity-protected once the TLS Finished message exchange completes, if the TLS connection uses a non-null TLS ciphersuite.

3.1.  Optimizing SASL Mechanism Negotiation

A client wishing to optimize SASL mechanism negotiation MUST send a sasl_sml extension in the client's TLS Hello message. The client MUST NOT send a payload in its sasl_sml 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 sasl_sml Hello extension in its reply to the client. The payload of the server's sasl_sml MUST be a string of ASCII characters representing a comma-separated list of SASL mechanism names (note: servers SHOULD NOT send a NUL string terminator is needed, but if present the client MUST ignore the NUL).

4.  Application Data Protocol Early Start

Applications may request that the TLS application data record protocol commence immediately after the client's Finished message is sent (which can be before the server's Finished message is received in the case of initial TLS connections). To do this the client includes the client Hello extension 'early_start' in its Hello message. If the server responds with the same extension and extension value 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.

Note that in the case of TLS session resumption the early_start feature has no effect as in that case the TLS handshake is already abbreviated. Because the decision to abbreviate a TLS handshake depends on client and server choices, clients that want an early start of the application record protocol should use the early_start extension even when requesting TLS session resumption.

5.  Use with StartTLS-like Protocols

These extensions can be used in "raw TLS" and "StartTLS" application protocols both. This section gives INFORMATIVE guidance to application protocol developers regarding how to integrate TLS/SA into their applications.

For example, the HyperText Transfer Protocol over TLS (HTTPS) [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) is a "raw TLS" application protocol: clients initiate TCP connections to servers, then they initiate TLS connections immediately, then they run the application protocol (HTTP in this case) over TLS. Whereas the Secure HyperText Transfer Protocol (S-HTTP) [RFC2660] (Rescorla, E. and A. Schiffman, “The Secure HyperText Transfer Protocol,” August 1999.) allows TLS to be "started" from within HTTP, at which point the application protocol (HTTP) is run over TLS-over-HTTP. The latter is commonly known as the "StartTLS" pattern. Other examples of application protocols using raw TLS and StartTLS include LDAP [RFC4511] (Sermersheim, J., “Lightweight Directory Access Protocol (LDAP): The Protocol,” June 2006.), IMAP4 [add ref], SMTP [add ref], etcetera.

Raw TLS applications need only use these optimizations to negotiate and optimize SASL authentication, and as soon as SASL authentication is complete they can begin the application protocol. We can call these "raw TLS/SA" applications.

StartTLS applications might have performed SASL authentication before starting TLS, in which case they have to redo SASL authentication.

StartTLS applications should treat the TLS handshake messages and any subsequent SASL authentication messages as a TLS handshake messages and frame them accordingly. When the TLS/SA authentication completes the application should then consider the TLS handshake complete, and the application may then start using the TLS record protocol for the application protocol's needs.

6.  Using TLS with the GSS-API

By using the SASL framework known as "GS2" [RFC5801] (Josefsson, S. and N. Williams, “Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family,” July 2010.), applications can use GSS-API mechanisms as SASL mechanisms.

7.  Using these Extensions with Existing SASL Applications

Applications that already use TLS and SASL can be trivially updated to use the sasl_sml and early_start extensions as follows: a) optimize the SASL mechanism negotiation as described in Section 3.1 (Optimizing SASL Mechanism Negotiation), b) start the application data protocol early as described in Section 4 (Application Data Protocol Early Start). Having listed the server's SASL mechanism list early the application can then immediately begin authentication using its preferred SASL mechanism.

Application protocol designers SHOULD, however, opt for the "TLS/SA" profile of TLS and SASL described in Section 8 (TLS/SA (TLS + SASL with generic framing of SASL authentication messages)). The rationale for this SHOULD is that the fewer ways to combine TLS and SASL, the more likely it is that developer frameworks will be produced to abstract the combination for programmers.

Non-TLS/SA applications 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) unless the server has already been authenticated by the TLS connection being renegotiated. It is RECOMMENDED that non-TLS/SA applications use only SASL/GS2 [RFC5801] (Josefsson, S. and N. Williams, “Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family,” July 2010.) mechanisms using channel binding to TLS. Channel binding to TLS is RECOMMENDED.

8.  TLS/SA (TLS + SASL with generic framing of SASL authentication messages)

Application protocols can use the sasl_sml and early_start extensions to optimize SASL authentication. Each application would have to provide the details of how to request SASL authentication start, how to frame SASL authentication messages, and how to convey the outcome of authentication to the client. A generic profile of TLS and the sasl_sml and early_start extensions would allow many applications to share a single TLS + SASL sub-protocol.

In this section we describe a generic profile of TLS and SASL [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.), using GS2 [RFC5801] (Josefsson, S. and N. Williams, “Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family,” July 2010.) mechanisms in TLS applications in a round trip optimized manner. We call this generic profile "TLS/SA", or "Transport Layer Security with Simple Authentication". TLS/SA defines those parts of the SASL authentication process which SASL [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) leaves to applications.

Existing SASL applications may, but need not use TLS/SA. New application protocols that would otherwise use TLS and/or SASL SHOULD use TLS/SA.

TLS/SA defines the framing of SASL authentication request, SASL mechanism and SASL outcome of authentication messages.

SASL mechanism negotiation in TLS/SA is done as described in Section 3.1 (Optimizing SASL Mechanism Negotiation). Channel binding to TLS is REQUIRED. The channel binding type MUST be 'tls-unique'. Note that as of today there exist no SASL mechanisms that support channel binding but which are not SASL/GS2 mechanisms.

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 (Optimizing SASL Mechanism Negotiation), b) 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, and using the TLS connection's channel binding data for channel binding.

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, possibly-empty comma-separated list of language tags [RFC5646] (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.);
3. a four octet, network byte order binary message length.

Subsequent SASL mechanism authentication messages are sent prefixed with 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 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 next most significant bit MUST be 1 to indicate that authentication can be re-tried, otherwise it must be set to 0, and MUST be 0 in the case of authentication success. 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] (Phillips, A. and M. Davis, “Matching of Language Tags,” September 2006.), 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. [Question: should this message also include the language tag chosen by the server? That could be done using UTF-8 language tag codepoints, but IIRC those are deprecated and hard to use.]

Where empty messages are required by SASL the application should send an empty message with correspondingly set length octets.

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 authentication failure and/or re-authentication.

If authentication succeeds then the application protocol takes over the TLS record protocol contents.

   Client                                               Server

   ClientHello w/ sasl_sml
               early_start      -------->
                                                ServerHello w/
                                                   early_start
                                                      sasl_sml
                                                  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

   Client                                               Server

   ClientHello w/ sasl_sml
               early_start      -------->
                                                ServerHello w/
                                                   early_start
                                                      sasl_sml
                                            [ChangeCipherSpec]
                                <--------             Finished
   Certificate*
   ClientKeyExchange
   CertificateVerify*
   [ChangeCipherSpec]
   Finished
   SASL auth message as data    -------->
                                             SASL auth message
                                <--------      Outcome of SASL
                                                authentication
   Application Data             <------->     Application Data

   Client                                               Server

   ClientHello w/ sasl_sml
               early_start      -------->
                                                ServerHello w/
                                                   early_start
                                                      sasl_sml
                                                  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:

   Client                                               Server

   ClientHello w/ sasl_sml
               early_start      -------->
                                                ServerHello w/
                                                   early_start
                                                      sasl_sml
                                                  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..

9.  Channel Binding

Existing TLS channel binding types that are suitable for use with SASL in this facility are:

• tls-server-end-point [RFC5929] (Altman, J., Williams, N., and L. Zhu, “Channel Bindings for TLS,” July 2010.)
• tls-unique [RFC5929] (Altman, J., Williams, N., and L. Zhu, “Channel Bindings for TLS,” July 2010.)

See [RFC5929] (Altman, J., Williams, N., and L. Zhu, “Channel Bindings for TLS,” July 2010.) and the IANA channel binding type registry for more information about these channel binding types. TLS/SA applications MUST use the 'tls-unique' channel binding type.

10.  Application Control of Authentication and Applicability of TLS/SA

Applications that should best be able to make use of these extensions to optimize authentication are those where clients can be expected to know a priori that authentication will be required. For example: LDAP, SMTP, IMAP4, XMPP and non-browser HTTP applications.

TLS/SA is inapplicable to applications where decisions about when authentication is required are made in context-specific manners by the application, rather than by the TLS layer. Web browser-based HTTP applications are a good example of this. For such applications TLS/SA will not be usable, either at all or without HTTP extensions that allow the server application to indicate that authentication is required, letting the client re-try. Moreover, for applications that make multiple short-lived TLS connections there is the need to bind each TLS connection in an "application session" to the initial authentication, and we do not provide a method for doing this other than to authenticate each TLS connection. Different methods of applying SASL/GSS-API authentication mechanisms will be needed for web applications.

Even where full TLS/SA is not applicable, the sasl_sml extension can be used to pre-negotiate SASL mechanisms in case that the application later decides that SASL authentication is required.

11.  Contrived Examples of Non-SASL Optimizations of Existing Application Protocols

In this section and its sub-sections we INFORMATIVELY describe 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. Implementors MUST NOT implement anything described in this section, except for experimental purposes only.

It is crucial that clients only use the app_hello 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 likely 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).

By starting the application protocol early these applications can obtain a similar round-trip optimization as for SASL in the TLS/SA case.

11.1.  Contrived Example: LDAP

In the case of LDAP the app_hello extension could be used to send a single LDAP message, typically a search for the root DSE object. If the server supports this extension then the server's app_hello Hello extension 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.

LDAP applications could also use an early_start request with value app_protocol and begin the LDAP protocol early. If the first operation performed were an LDAP Bind then the application will obtain the same round-trip optimization that we get for SASL using TLS/SA.

11.2.  Contrived Example: SMTP

Clients could use the app_hello 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 Hello extension.

12.  Impact on TLS 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:

• Add a configuration parameter through which the administrator may list the SASL mechanisms available to the application servers behind the concentrator;
• Add support for sasl_sml Hello extension, using the server SASL mechanism list from the configuration parameter mentioned in the previous item;
• Add a configuration parameter through which the administrator may indicate whether the application supports the 'generic-sasl' framing defined in Section 8 (TLS/SA (TLS + SASL with generic framing of SASL authentication messages)).
• Add support for early_start, 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 Hello extension to the application.

13.  IANA Considerations

By the time this document is published, the values for the 'sasl_sml' and 'early_start' TLS Hello extensions will be assined by the IANA. The ExtensionType registry will have to be updated to reflect these assignments. (These registries require IETF Consensus.)

14.  Security Considerations

The security considerations of [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.), [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) and [RFC5056] (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.) apply, as do those of [RFC2743] (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.) when used via the SASL/GS2 bridge [RFC5801] (Josefsson, S. and N. Williams, “Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family,” July 2010.). Additionally, this document has security consideration information throughout.

Needless to say, TLS applications that make use of TLS renegotiation should ensure that they use the TLS renegotiation indication extension [RFC5746] (Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, “Transport Layer Security (TLS) Renegotiation Indication Extension,” February 2010.).

The initial SASL authentication message should not be considered protected by TLS until the TLS handshake completes. If a TLS cipher suite is used that does not authenticate the server, but a SASL mechanism is used that does authenticate the server, then the SASL exchanges should not be considered protected until authentication completes and succeeds. Channel binding MUST be used in the optimized authentication case (but then, channel binding should always be used when SASL is used over TLS).

Non-SASL early_start application data should not be considered protected by TLS until the TLS handshake completes.

The SASL mechanism negotiation and app_hello data should not be considered protected by TLS until the TLS handshake completes, and, if the application uses SASL, should not be considered protected until SASL authentication completes successfully.

15.  References

15.1. Normative References

15.2. Informative References

Author's Address