[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04
Network Working Group N. Williams
Internet-Draft Oracle
Intended status: Standards Track July 26, 2010
Expires: January 27, 2011
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 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."
Williams Expires January 27, 2011 [Page 1]
Internet-Draft TLS/SA July 2010
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 January 27, 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 BSD License.
Williams Expires January 27, 2011 [Page 2]
Internet-Draft TLS/SA July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . . 5
2. TLS Extensions for Optimization of Application protocols . . 6
3. Sending Application Data in TLS Hello Messages . . . . . . . 9
3.1. Optimizing SASL Mechanism Negotiation . . . . . . . . . . . 9
4. Application Data Protocol Early Start . . . . . . . . . . . 10
5. Use with StartTLS-like Protocols . . . . . . . . . . . . . . 11
6. Using TLS with the GSS-API . . . . . . . . . . . . . . . . . 12
7. Using these Extensions with Existing SASL Applications . . . 13
8. TLS/SA (TLS + SASL with generic framing of SASL
authentication messages) . . . . . . . . . . . . . . . . . . 14
8.1. TLS/SA Exchanges . . . . . . . . . . . . . . . . . . . . . . 14
9. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 20
10. Application Control of Authentication and Applicability
of TLS/SA . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Contrived Examples of Non-SASL Optimizations of Existing
Application Protocols . . . . . . . . . . . . . . . . . . . 22
11.1. Contrived Example: LDAP . . . . . . . . . . . . . . . . . . 22
11.2. Contrived Example: SMTP . . . . . . . . . . . . . . . . . . 22
12. Impact on TLS Concentrators . . . . . . . . . . . . . . . . 23
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
14. Security Considerations . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . . . 26
15.2. Informative References . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . 27
Williams Expires January 27, 2011 [Page 3]
Internet-Draft TLS/SA July 2010
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. 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], we
obtain support for use of GSS-API [RFC2743] 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] 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:
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 implementor community;
o a desire to provide a profile that new applications may use for
TLS with SASL and/or GSS-API for user authentication.
Williams Expires January 27, 2011 [Page 4]
Internet-Draft TLS/SA July 2010
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].
Williams Expires January 27, 2011 [Page 5]
Internet-Draft TLS/SA July 2010
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] 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:
o app_hello (<TBD>)
o sasl_sml (<TBD>)
o 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 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
Williams Expires January 27, 2011 [Page 6]
Internet-Draft TLS/SA July 2010
indicates the kind of application data that will be sent early:
enum { app_protocol (0), generic_sasl(1), (255)
} EarlyStartProto;
Figure 1: EarlyStartProto TLS Hello extension
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 and Section 11. 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,
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
Figure 2: Message flow for initial TLS connections with SASL
mechanism negotiation and SASL authentication
Williams Expires January 27, 2011 [Page 7]
Internet-Draft TLS/SA July 2010
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
Figure 3: Message flow for resumed TLS connections with SASL
mechanism negotiation and SASL authentication
Williams Expires January 27, 2011 [Page 8]
Internet-Draft TLS/SA July 2010
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).
Williams Expires January 27, 2011 [Page 9]
Internet-Draft TLS/SA July 2010
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.
Williams Expires January 27, 2011 [Page 10]
Internet-Draft TLS/SA July 2010
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] 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] 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], 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.
Williams Expires January 27, 2011 [Page 11]
Internet-Draft TLS/SA July 2010
6. Using TLS with the GSS-API
By using the SASL framework known as "GS2" [RFC5801], applications
can use GSS-API mechanisms as SASL mechanisms.
Williams Expires January 27, 2011 [Page 12]
Internet-Draft TLS/SA July 2010
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,
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.
Application protocol designers SHOULD, however, opt for the "TLS/SA"
profile of TLS and SASL described in Section 8. 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] mechanisms using channel binding to TLS. Channel binding
to TLS is RECOMMENDED.
Williams Expires January 27, 2011 [Page 13]
Internet-Draft TLS/SA July 2010
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], using GS2 [RFC5801] 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] 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. 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, 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];
Williams Expires January 27, 2011 [Page 14]
Internet-Draft TLS/SA July 2010
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], 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.
Williams Expires January 27, 2011 [Page 15]
Internet-Draft TLS/SA July 2010
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
Figure 4: Message flow for initial TLS connections with a one-round-
trip SASL mechanism for authentication
Williams Expires January 27, 2011 [Page 16]
Internet-Draft TLS/SA July 2010
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
Figure 5: Message flow for session resumption TLS connections with a
one-round-trip SASL mechanism for authentication
Williams Expires January 27, 2011 [Page 17]
Internet-Draft TLS/SA July 2010
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
Figure 6: Message flow for initial TLS connections with one and a
half round-trip SASL mechanisms for authentication
And with a two round trip mechanism the protocol looks like:
Williams Expires January 27, 2011 [Page 18]
Internet-Draft TLS/SA July 2010
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
Figure 7: Message flow for initial TLS connections with two round-
trip SASL mechanisms for authentication
The reader can figure out what the protocol looks like for SASL
mechanisms with more than two round trips from the above..
Williams Expires January 27, 2011 [Page 19]
Internet-Draft TLS/SA July 2010
9. Channel Binding
Existing TLS channel binding types that are suitable for use with
SASL in this facility are:
o tls-server-end-point [RFC5929]
o tls-unique [RFC5929]
See [RFC5929] 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.
Williams Expires January 27, 2011 [Page 20]
Internet-Draft TLS/SA July 2010
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.
Williams Expires January 27, 2011 [Page 21]
Internet-Draft TLS/SA July 2010
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.
Williams Expires January 27, 2011 [Page 22]
Internet-Draft TLS/SA July 2010
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:
o Add a configuration parameter through which the administrator may
list the SASL mechanisms available to the application servers
behind the concentrator;
o Add support for sasl_sml Hello extension, using the server SASL
mechanism list from the configuration parameter mentioned in the
previous item;
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 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.
Williams Expires January 27, 2011 [Page 23]
Internet-Draft TLS/SA July 2010
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.)
Williams Expires January 27, 2011 [Page 24]
Internet-Draft TLS/SA July 2010
14. Security Considerations
The security considerations of [RFC4422], [RFC5246] and [RFC5056]
apply, as do those of [RFC2743] when used via the SASL/GS2 bridge
[RFC5801]. 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].
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.
Williams Expires January 27, 2011 [Page 25]
Internet-Draft TLS/SA July 2010
15. References
15.1. Normative References
[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.
[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.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010.
[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", RFC 5801, July 2010.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010.
15.2. Informative References
[RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText
Transfer Protocol", RFC 2660, August 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
Williams Expires January 27, 2011 [Page 26]
Internet-Draft TLS/SA July 2010
Author's Address
Nicolas Williams
Oracle
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@oracle.com
Williams Expires January 27, 2011 [Page 27]
Html markup produced by rfcmarkup 1.127, available from
https://tools.ietf.org/tools/rfcmarkup/