One document matched: draft-williams-tls-app-sasl-opt-02.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 rfc5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.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 rfc5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY sasl-channel-bindings PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sasl-channel-bindings.xml'>
<!ENTITY gs2 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sasl-gs2.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-02.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 abbrev="Sun">Sun Microsystems</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@sun.com</email>
</address>
</author>
<date month="April" year="2009"/>
<area>Security</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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".</t>
<t>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.</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. 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.</t>
<t>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 <xref
target='I-D.ietf-sasl-gs2'/> we obtain support for
use of GSS-API <xref target='RFC2743'/> mechanisms as
well. <xref target='RFC2743'/> applications.
Altogether we achieve a one and a half round-trip
reduction for SASL applications.</t>
<t>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 <xref
target='RFC5056'/> can be made available at that
time, thus no special considerations apply to how
channel binding is done (but see <xref
target='cbinding'/> below). Use of channel binding
protects against man-in-the-middle attacks, including
downgrade attacks on mechanism negotiation.</t>
<t>This extension is 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
WG;</t>
<t>a desire to provide a profile that new
applications may use for TLS with GSS-API for
user authentication.</t>
</list>
</t>
<t>The use of this extension to optimize SASL/GSS-API
authentication is termed "TLS/SA".</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
SASL and 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 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).</t>
<t>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.</t>
<t>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:
<list style='symbols'>
<t>pfapp_data (<TBD>)</t>
<t>sasl_sml_req (<TBD>)</t>
</list>
</t>
<t>The "pf" prefix indicates "pre-Finished message
exchange". It is the application's responsibility to
define the contents of the pfapp_data extension.</t>
<t>The sasl_sml_req (SASL server mechanism list request)
message contains an empty payload.</t>
<t>We also define new Handshake messages that may be used
after the Client Hello messages:</t>
<figure>
<artwork>
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>;
</artwork>
</figure>
<t>A generic application protocol using these extensions
might look like:</t>
<figure>
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
<t>Note that the SaslMsg in the client's handshake MUST NOT
be included in the client's Finisshed message
construction. See <xref target='cbinding'/> 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]</t>
</section>
<section title="Using TLS/SA">
<t>"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 <xref
target='I-D.ietf-sasl-gs2'/> mechanisms may be
optimized.</t>
<t>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.</t>
<t>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.</t>
<section title="Optimizing SASL Mechanism Negotiation">
<t>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.</t>
<t>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).</t>
</section>
<section title="Optimizing Authentication">
<t>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.</t>
<t>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>With a one round trip SASL/GS2 mechanism the protocol
then looks like:</t>
<figure>
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
<t>With a one and one half round trip mechanism the
protocol looks like:</t>
<figure>
<artwork>
<![CDATA[
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
authentication
Application Data <-------> Application Data
]]>
</artwork>
</figure>
<t>And with a two round trip mechanism the protocol
looks like:</t>
<figure>
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
<section anchor='cbinding' title="Channel Binding">
<t>The TLS channel binding types that are suitable
for use with SASL in this facility are:
<list style='symbols'>
<t>tls-server-end-point</t>
<t>tls-unique</t>
</list>
</t>
<t>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 <xref
target='I-D.ietf-sasl-channel-bindings'/>
(namely: if there is a server certificate, then
use tls-server-end-point, else use
tls-unique).</t>
<t>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.</t>
</section>
</section>
</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 title="Non-SASL Optimizations of Existing Application Protocols">
<t>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.</t>
<t>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).</t>
<section title="LDAP">
<t>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.</t>
</section>
<section title="SMTP">
<t>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.</t>
</section>
</section>
<section title="IANA Considerations">
<t>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.)</t>
</section>
<section title="Security Considerations">
<t>The security considerations of <xref target='RFC4422'/>,
<xref target='I-D.ietf-sasl-channel-bindings'/>, <xref
target="RFC5246"/> and <xref target="RFC5056"/>
apply, as do those of <xref target='RFC2743'/> when used
via the SASL/GS2 bridge <xref
target='I-D.ietf-sasl-gs2'/>.</t>
<t>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.</t>
<t>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.</t>
<t>The SASL mechanism negotiation is protected by the TLS
Finished messages.</t>
</section>
</middle>
<back>
<references
title="Normative References">
&rfc2119;&rfc5246;&rfc4422;&rfc5056;&sasl-channel-bindings;
</references>
<references title="Informative References">
&gs2;&rfc2743;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:57:54 |