| TOC |
|
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 (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.
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.
1.
Introduction
1.1.
Conventions used in this document
2.
TLS Extensions for Optimization of
Application protocols
3.
Application 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)
8.1.
TLS/SA Exchanges
8.1.1.
Channel Binding
9.
Non-SASL Optimizations of Existing Application Protocols
9.1.
LDAP
9.2.
SMTP
10.
Impact on Concentrators
11.
IANA Considerations
12.
Security Considerations
13.
References
13.1.
Normative References
13.2.
Informative References
§
Author's Address
| TOC |
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. 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] (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.) we obtain support for use of GSS-API [RFC2743] (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.) mechanisms as well. [RFC2743] (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.) 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] (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.) can be made available at that time, thus no special considerations apply to how channel binding is done (but see Section 8.1.1 (Channel Binding) below). Use of channel binding protects against man-in-the-middle attacks, including downgrade attacks on mechanism negotiation.
This extension is motivated by:
The use of this extension to optimize SASL/GSS-API authentication is termed "TLS/SA".
| TOC |
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.).
| TOC |
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:
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;
We also define new Handshake messages that may be used after the Client Hello messages:
enum {
finished(20), app_hello(<TBD>),
sasl_sml(<TBD>), sasl_msg(<TBD>), (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:
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
| TOC |
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.
| TOC |
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).
| TOC |
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.
| TOC |
These extensions can be used over "raw TLS" and "StartTLS" protocols equally.
| TOC |
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] (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.) that maps GSS-API mechanisms onto SASL ones. See the next section.
| TOC |
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 (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.
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] (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.) mechanisms using channel binding to TLS. Channel binding to TLS is RECOMMENDED.
| TOC |
In this section we describe a generic way to use SASL/GS2 [I‑D.ietf‑sasl‑gs2] (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.) 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] (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; instead existing SASL applications SHOULD use the method described in Section 7 (Using these Extensions with Existing SASL Applications).
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 (Optimizing SASL Mechanism Negotiation). SASL mechanisms which are not SASL/GS2 mechanisms MUST NOT be used. Channel binding to TLS is REQUIRED.
| TOC |
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) 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:
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 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.
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:
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:
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:
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..
| TOC |
Existing TLS channel binding types that are suitable for use with SASL in this facility are:
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, N., “SASL And Channel Binding,” April 2009.).
| TOC |
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).
| TOC |
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.
| TOC |
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.
| TOC |
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:
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.
| TOC |
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.)
| TOC |
The security considerations of [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.), [I‑D.ietf‑sasl‑channel‑bindings] (Williams, N., “SASL And Channel Binding,” April 2009.), [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 [I‑D.ietf‑sasl‑gs2] (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.).
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.
| TOC |
| TOC |
| [I-D.ietf-sasl-channel-bindings] | Williams, N., “SASL And Channel Binding,” draft-ietf-sasl-channel-bindings-03 (work in progress), April 2009 (TXT). |
| [I-D.ietf-sasl-gs2] | Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” draft-ietf-sasl-gs2-20 (work in progress), January 2010 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC4422] | Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” RFC 4422, June 2006 (TXT). |
| [RFC4646] | Phillips, A. and M. Davis, “Tags for Identifying Languages,” RFC 4646, September 2006 (TXT). |
| [RFC4647] | Phillips, A. and M. Davis, “Matching of Language Tags,” BCP 47, RFC 4647, September 2006 (TXT). |
| [RFC5056] | Williams, N., “On the Use of Channel Bindings to Secure Channels,” RFC 5056, November 2007 (TXT). |
| [RFC5246] | Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT). |
| TOC |
| [RFC2743] | Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” RFC 2743, January 2000 (TXT). |
| [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. |
| TOC |
| Nicolas Williams | |
| Sun Microsystems | |
| 5300 Riata Trace Ct | |
| Austin, TX 78727 | |
| US | |
| Email: | Nicolas.Williams@sun.com |