One document matched: draft-williams-tls-app-sasl-opt-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!-- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2818 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'>
<!ENTITY rfc2660 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2660.xml'>
<!ENTITY rfc2743 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY rfc4422 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml'>
<!ENTITY rfc4511 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4511.xml'>
<!ENTITY rfc4647 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4647.xml'>
<!ENTITY rfc5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY rfc5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc5646 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5646.xml'>
<!ENTITY rfc5746 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml'>
<!ENTITY rfc5801 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5801.xml'>
<!ENTITY rfc5929 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-williams-tls-app-sasl-opt-04.txt">
<front>
<title abbrev="TLS/SA">TLS Extension for Optimizing Application Protocols, Specifically SASL with GSS-API mechanisms</title>
<author initials='N.' surname="Williams" fullname='Nicolas
Williams'>
<organization>Oracle</organization>
<address>
<postal>
<street>5300 Riata Trace Ct</street>
<city>Austin</city> <region>TX</region>
<code>78727</code> <country>US</country>
</postal>
<email>Nicolas.Williams@oracle.com</email>
</address>
</author>
<date year="2010"/>
<area>Security</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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).</t>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Many applications use TLS <xref target='RFC5246'/> and
then Simple Authentication and Security Layers (SASL)
<xref target='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.</t>
<t>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.</t>
<t>Through the new SASL to GSS-API mechanism bridge, GS2
<xref target='RFC5801'/>, we obtain support for use of
GSS-API <xref target='RFC2743'/> security mechanisms.
Altogether we achieve up to a two round-trip reduction
for applications using SASL over TLS.</t>
<t>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
<xref target='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.</t>
<t>These extensions are motivated by:
<list style='symbols'>
<t>a desire to reduce the number of round trips
needed by SASL and GSS-API applications running
over TLS;</t>
<t>a desire to replace an earlier proposal for
"TLS/GSS" with one that passes muster at the TLS
implementor community;</t>
<t>a desire to provide a profile that new
applications may use for TLS with SASL and/or
GSS-API for user authentication.</t>
</list>
</t>
<t>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.</t>
<section title="Conventions used in this document">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
</section>
<section anchor='ext' title="TLS Extensions for Optimization of
Application protocols">
<t>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
<xref target='RFC5746'/> where the previous negotiation
established cipher suites that provide the required
protection or b) deferred integrity protection is
sufficient.</t>
<t>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.</t>
<t>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:
<list style='symbols'>
<t>app_hello (<TBD>)</t>
<t>sasl_sml (<TBD>)</t>
<t>early_start (<TBD>)</t>
</list>
</t>
<t>It is the application's responsibility to define the
contents of the app_hello Hello extension.</t>
<t>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 <xref
target='mech_nego'/> for details of the encoding of
the server's SASL mechanism list.</t>
<t>The early_start extension requests permission to
start the application data record protocol on the
client-side immediately after sending the client's
Finished message (which, in the case of initial TLS
connections, is sent before receiving the server's
Finished message). Servers that supports this
extension MUST include the same extension in its Hello
message with the same value. The value of early_start
consists of an encoded enum (EarlyStartProto) that
indicates the kind of application data that will be sent
early:</t>
<figure anchor='EarlyStartProto' title="EarlyStartProto TLS Hello extension">
<artwork>
enum { app_protocol (0), generic_sasl(1), (255)
} EarlyStartProto;
</artwork>
</figure>
<t>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 <xref
target='existing_sasl_apps'/> and <xref
target='non_sasl_apps'/>. 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 <xref target='generic-sasl'/>,
until authentication succeeds or fails, at which point
the actual application protocol will take over the TLS
application records.</t>
<t>A generic application protocol using these TLS extensions
might look like:</t>
<figure anchor='tlssa_init' title="Message flow for initial TLS connections with SASL mechanism negotiation and SASL authentication">
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
<figure anchor='tlssa_resume' title="Message flow for resumed TLS connections with SASL mechanism negotiation and SASL authentication">
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
</section>
<section title="Sending Application Data in TLS Hello Messages">
<t>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:
<list style='numbers'>
<t>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;</t>
<t>the application on the server side knows
unambiguously what data to expect in an
app_hello.</t>
</list>
</t>
<t>For example, SMTP could use the app_hello extension to
send its EHLO before the TLS handshake completes.</t>
<t>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.</t>
<section anchor='mech_nego' title="Optimizing SASL Mechanism Negotiation">
<t>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.</t>
<t>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).</t>
</section>
</section>
<section anchor='early_start' title="Application Data Protocol Early Start">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Use with StartTLS-like Protocols">
<t>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.</t>
<t>For example, the HyperText Transfer Protocol over TLS
(HTTPS) <xref target='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) <xref
target='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 <xref target='RFC4511'/>, IMAP4
[add ref], SMTP [add ref], etcetera.</t>
<t>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.</t>
<t>StartTLS applications might have performed SASL
authentication before starting TLS, in which case they
have to redo SASL authentication.</t>
<t>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.</t>
</section>
<section title="Using TLS with the GSS-API">
<t>By using the SASL framework known as "GS2" <xref
target='RFC5801'/>, applications can use GSS-API
mechanisms as SASL mechanisms.</t>
</section>
<section anchor='existing_sasl_apps' title="Using these Extensions with Existing SASL Applications">
<t>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 <xref target='mech_nego'/>,
b) start the application data protocol early as
described in <xref target='early_start'/>. Having
listed the server's SASL mechanism list early the
application can then immediately begin authentication
using its preferred SASL mechanism.</t>
<t>Application protocol designers SHOULD, however, opt for
the "TLS/SA" profile of TLS and SASL described in <xref
target='generic-sasl'/>. 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.</t>
<t>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 <xref target='RFC5801'/>
mechanisms using channel binding to TLS. Channel
binding to TLS is RECOMMENDED.</t>
</section>
<section anchor='generic-sasl' title="TLS/SA (TLS + SASL with generic framing of SASL authentication messages)">
<t>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.</t>
<t>In this section we describe a generic profile of TLS and
SASL <xref target='RFC4422'/>, using GS2 <xref
target='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 <xref
target='RFC4422'/> leaves to applications.</t>
<t>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.</t>
<t>TLS/SA defines the framing of SASL authentication
request, SASL mechanism and SASL outcome of
authentication messages.</t>
<t>SASL mechanism negotiation in TLS/SA is done as described
in <xref target='mech_nego'/>. 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.</t>
<section title="TLS/SA Exchanges">
<t>A client wishing to optimize a SASL/GS2 mechanism
MUST: a) negotiate a SASL mechanism to use using the
method described in <xref target='mech_nego'/>, 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.</t>
<t>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:
<list style='numbers'>
<t>the SASL name of the mechanism,
NUL-terminated;</t>
<t>a NUL-terminated, possibly-empty
comma-separated list of language tags <xref
target='RFC5646'/>;</t>
<t>a four octet, network byte order binary
message length.</t>
</list>
</t>
<t>Subsequent SASL mechanism authentication messages are
sent prefixed with a four octet, network byte order
binary message length.</t>
<t>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.</t>
<t>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 <xref target='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.]</t>
<t>Where empty messages are required by SASL the
application should send an empty message with
correspondingly set length octets.</t>
<t>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.</t>
<t>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.</t>
<t>If authentication succeeds then the application
protocol takes over the TLS record protocol
contents.</t>
<figure anchor='tlssa_1rt' title="Message flow for initial TLS connections with a one-round-trip SASL mechanism for authentication">
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
<figure anchor='tlssa_resume_1rt' title="Message flow for session resumption TLS connections with a one-round-trip SASL mechanism for authentication">
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
<figure anchor='tlssa_1.5rt' title="Message flow for initial TLS connections with one and a half round-trip SASL mechanisms for authentication">
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
<t>And with a two round trip mechanism the protocol
looks like:</t>
<figure anchor='tlssa_2rt' title="Message flow for initial TLS connections with two round-trip SASL mechanisms for authentication">
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
<t>The reader can figure out what the protocol looks
like for SASL mechanisms with more than two
round trips from the above..</t>
</section>
</section>
<section anchor='cbinding' title="Channel Binding">
<t>Existing TLS channel binding types that are suitable for
use with SASL in this facility are:
<list style='symbols'>
<t>tls-server-end-point <xref target='RFC5929'/></t>
<t>tls-unique <xref target='RFC5929'/></t>
</list>
</t>
<t>See <xref target='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.</t>
</section>
<section anchor='applicability' title="Application Control of
Authentication and Applicability of TLS/SA">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<!--
<section title="Using this Extension with Existing Application Protocols">
<t>[This section's sub-sections need to be separate I-Ds,
though each should be so small as to make that seem like
overkill.]</t>
<t>In this section and its sub-sections we NORMATIVELY
describe how a number of existing TLS and SASL
application protocols are modified to make use of this
extension.</t>
</section>
-->
<section anchor='non_sasl_apps' title="Contrived Examples of Non-SASL Optimizations of Existing Application Protocols">
<t>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.</t>
<t>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).</t>
<t>By starting the application protocol early these
applications can obtain a similar round-trip
optimization as for SASL in the TLS/SA case.</t>
<section title="Contrived Example: LDAP">
<t>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.</t>
<t>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.</t>
</section>
<section title="Contrived Example: SMTP">
<t>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.</t>
</section>
</section>
<section title="Impact on TLS Concentrators">
<t>This protocol is designed to have minimal impact on TLS
server-side proxies (a.k.a. concentrators).</t>
<t>The minimal changes to make to TLS concentrators in order
to support this protocol are:
<list style='symbols'>
<t>Add a configuration parameter through which the
administrator may list the SASL mechanisms
available to the application servers behind the
concentrator;</t>
<t>Add support for sasl_sml Hello extension,
using the server SASL mechanism list from the
configuration parameter mentioned in the
previous item;</t>
<t>Add a configuration parameter through which the
administrator may indicate whether the
application supports the 'generic-sasl' framing
defined in <xref target='generic-sasl'/>.</t>
<t>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.</t>
</list>
</t>
<t>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).</t>
<t>Implementors may also add a way to communicate
app_hello Hello extension to the application.</t>
</section>
<section title="IANA Considerations">
<t>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.)</t>
</section>
<section title="Security Considerations">
<t>The security considerations of <xref target='RFC4422'/>,
<xref target="RFC5246"/> and <xref target="RFC5056"/>
apply, as do those of <xref target='RFC2743'/> when used
via the SASL/GS2 bridge <xref target='RFC5801'/>.
Additionally, this document has security consideration
information throughout.</t>
<t>Needless to say, TLS applications that make use of TLS
renegotiation should ensure that they use the TLS
renegotiation indication extension <xref
target='RFC5746'/>.</t>
<t>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).</t>
<t>Non-SASL early_start application data should not be
considered protected by TLS until the TLS handshake
completes.</t>
<t>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.</t>
</section>
</middle>
<back>
<references
title="Normative References">
&rfc2119;&rfc4422;&rfc4647;&rfc5056;&rfc5246;&rfc5646;
&rfc5746;
&rfc5801;
&rfc5929;
</references>
<references title="Informative References">
&rfc2660;
&rfc2743;
&rfc2818;
&rfc4511;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:57:28 |