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 (<TBD>)
o sasl_sml_req (<TBD>)
o early_start_req (<TBD>)
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(<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:
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]