Network Working Group N. Williams
Internet-Draft Sun
Intended status: Standards Track April 14, 2009
Expires: October 16, 2009
TLS Extension for Optimizing Application Protocols, Specifically SASL
with GSS-API mechanisms
draft-williams-tls-app-sasl-opt-02.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 16, 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 16, 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.
Optimizations for Simple Mail transfer Protocol (SMTP) and Light-
weight Directory Access Protocol (LDAP) are described.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3
2. TLS Extensions for Optimization of SASL and
Application protocols . . . . . . . . . . . . . . . . . . 4
3. Using TLS/SA . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Optimizing SASL Mechanism Negotiation . . . . . . . . . . 7
3.2. Optimizing Authentication . . . . . . . . . . . . . . . . 7
3.2.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . 10
4. Non-SASL Optimizations of Existing Application
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . 16
Williams Expires October 16, 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 3.2.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 16, 2009 [Page 3]
Internet-Draft TLS/SA April 2009
2. TLS Extensions for Optimization of SASL and 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 pfapp_data (<TBD>)
o sasl_sml_req (<TBD>)
The "pf" prefix indicates "pre-Finished message exchange". It is the
application's responsibility to define the contents of the pfapp_data
extension.
The sasl_sml_req (SASL server mechanism list request) message
contains an empty payload.
We also define new Handshake messages that may be used after the
Client Hello messages:
Williams Expires October 16, 2009 [Page 4]
Internet-Draft TLS/SA April 2009
enum {
finished(20), pfapp_data(<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 pfapp_data: PFAppData;
/* SASL server mechanism list */
case sasl_sml: SaslSML;
/* SASL mechanism message */
case sasl_msg: SaslMsg;
} body;
} Handshake;
opaque PFAppData<2^16-1>;
opaque SaslSML<2^16-1>;
opaque SaslMsg<2^16-1>;
A generic application protocol using these extensions might look
like:
Client Server
ClientHello w/ sasl_sml_req -------->
ServerHello
SaslSML*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
SaslMsg*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SASL auth messages <-------> SASL auth messages
Application Data <-------> Application Data
Williams Expires October 16, 2009 [Page 5]
Internet-Draft TLS/SA April 2009
Note that the SaslMsg in the client's handshake MUST NOT be included
in the client's Finisshed message construction. See Section 3.2.1
for more information. [An alternative to this oddity would be to
allow application data to be sent by the client after sending the
client's Finished message but before receiving the server's Finished
message. I'm not sure which of these two options might be the most
controversial, but I'd be happy with either. -Nico]
Williams Expires October 16, 2009 [Page 6]
Internet-Draft TLS/SA April 2009
3. Using TLS/SA
"TLS/SA" is the name given to the use of the sasl_sml_req, SaslSML
and SaslMsg TLS extensions to perform SASL authentication in a round-
trip optimized manner over TLS. Only SASL/GS2 [I-D.ietf-sasl-gs2]
mechanisms may be optimized.
In order to use SASL via this extension it's important to define how
the client requests authentication, how it sends its first message
(SASL/GS2 mechanisms are always client-speaks-first mechanisms), and
how the SASL exchange continues after the TLS handshake finishes. It
is also important to explain how existing SASL applications, such as
IMAP, POP3, SMTP, LDAP, etcetera, will use this extension. We do
this in the following two sections.
Application protocols may differ from the protocol described below
where specifically allowed, but all of the following is NORMATIVE for
IMAP, POP3, SMTP, and LDAP.
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 mechanisl 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).
3.2. Optimizing Authentication
A client wishing to optimize a SASL/GS2 mechanism whose first message
is shorter than 2^16 - 2 - length of SASL mechanism name bytes MUST:
a) use channel binding, b) send the mechanism's first message in the
client's SaslMsg handshake message, and c) it MUST prefix the
mechanism's first message with the SASL name of the mechanism and a
zero-valued byte: "<mech-name><NUL><mech-message>. Note that any
replies to this message will be in the form of application data in
the record protocol, the form of which may differ by application,
though below we define a generic form.
After the TLS handshake finishes the application must continue
exchanging SASL messages: any mechanism messages and, finally, the
outcome of authentication exchange message. SASL requires that
applications define how to frame and encode these messages. Here we
Williams Expires October 16, 2009 [Page 7]
Internet-Draft TLS/SA April 2009
provide an example of how applications SHOULD do it, though
applications are free to use their own framing and encoding. IMAP,
POP3, SMTP and LDAP MUST, when using this extension, do as described
below.
For any SASL mechanism authentication messages subsequent to the
initial message the application MUST send a network byte order, four
byte unsigned binary length of the mechanism message followed by the
mechanism message as-is. Messages longer than 2^24 MUST NOT be sent.
Where empty messages are required by the SASL mechanism the
application should send a zero-valued length and an empty message.
The server's successful "outcome of authentication exchange" message
MUST consist of four bytes with all bits set followed by a network
byte order four byte unsigned binary length of supplementary
information to be defined by the application.
Whereas a server's failed authentication message MUST consist of four
bytes in network byte order with the high bit set and the remaining
bits cleared, followed by a network byte order four byte unsigned
binary length of supplementary information to be defined by the
application.
If the last message of the SASL mechanism used is 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.
Typically the supplementary information will be a character string
meant for the user to read; the language and encoding may be
application dependent or negotiated by the SASL mechanism but, unless
specified otherwise by the application, the encoding MUST be UTF-8.
If the SASL authentication exchange ends successfully then the
application protocol takes over as it is normally specified, but with
the user already authenticated, thus there should be no need to use
SASL authentication as normally specified for the application (unless
there is a need to re-authenticate, possibly as a different user).
If the SASL authentication exchange ends unsuccessfully then the
application protocol takes over as it is normally specified, with the
user not authenticated, at which point the client MAY re-try
authentication.
With a one round trip SASL/GS2 mechanism the protocol then looks
like:
Williams Expires October 16, 2009 [Page 8]
Internet-Draft TLS/SA April 2009
Client Server
ClientHello w/ sasl_sml_req -------->
ServerHello
SaslSML
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
SaslMsg
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
<-------- SASL auth msg
as app data
<-------- 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 -------->
ServerHello
SaslSML
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
SaslMsg
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
<-------- SASL auth msg
as app data
SASL auth msg as app data -------->
<-------- Outcome of SASL
Williams Expires October 16, 2009 [Page 9]
Internet-Draft TLS/SA April 2009
authentication
Application Data <-------> Application Data
And with a two round trip mechanism the protocol looks like:
Client Server
ClientHello w/ sasl_sml_req -------->
ServerHello
SaslSML
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
SaslMsg
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
<-------- SASL auth msg
as app data
SASL auth msg as app data -------->
<-------- SASL auth msg
as app data
<-------- Outcome of SASL
authentication
Application Data <-------> Application Data
3.2.1. Channel Binding
The TLS channel binding types that are suitable for use with SASL in
this facility are:
o tls-server-end-point
o 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] (namely:
if there is a server certificate, then use tls-server-end-point, else
use tls-unique).
Williams Expires October 16, 2009 [Page 10]
Internet-Draft TLS/SA April 2009
Note that the application has to construct its first SASL
authentication message for sending in the same half-round trip as the
client's Finished message, yet the client's Finished message is used
in the tls-unique channel binding type. This means that the Finished
message MUST be constructed before the client's SaslMsg, and the
SaslMsg is not integrity protected by the client's Finished message,
though it will be integrity protected by the server's Finished
message.
Williams Expires October 16, 2009 [Page 11]
Internet-Draft TLS/SA April 2009
4. 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 pfapp_data extension for
operations that do not require that the user already be authenticated
(the server application MUST reject such uses of pfapp_data) or that
require privacy protection. There are no operations in IMAP and
POP3, for example, which are suitable for optimization via
pfapp_data, 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).
4.1. LDAP
In the case of LDAP the pfapp_data 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 pfapp_data 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.
4.2. SMTP
Clients may use the pfapp_data extension to send a EHLO SMTP command
to the server, and the server may send the SMTP reply to it in a
pfapp_data handshake message.
Williams Expires October 16, 2009 [Page 12]
Internet-Draft TLS/SA April 2009
5. 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 16, 2009 [Page 13]
Internet-Draft TLS/SA April 2009
6. 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].
As usual with TLS there is no privacy protection of client identity
unless the client first completes a handshake without authenticating
itself, changes the cipher spec, then initiates a new handshake where
it does authenticate itself. In this case, client authentication
being done via SASL, this means not sending a SaslMsg until after the
initial ChangeCipherSpec exchange.
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 can detect
modifications to its initial SASL authentication message through the
server's TLS Finished message.
The SASL mechanism negotiation is protected by the TLS Finished
messages.
Williams Expires October 16, 2009 [Page 14]
Internet-Draft TLS/SA April 2009
7. References
7.1. Normative References
[I-D.ietf-sasl-channel-bindings]
Williams, N., "SASL And Channel Binding",
draft-ietf-sasl-channel-bindings-00 (work in progress),
April 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.
[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.
7.2. Informative References
[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.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
Williams Expires October 16, 2009 [Page 15]
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 16, 2009 [Page 16]