One document matched: draft-williams-tls-app-sasl-opt-00.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 symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-williams-tls-app-sasl-opt-00.txt">
<front>
<title abbrev="TLS-SA">TLS Extension for Optimizing Application Protocols, Specifically SASL</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).</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. 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'/> is available 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, including downgrade attacks
on mechanism negotiation.</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 title="The Extension and Optimization of SASL">
<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;
...
case pfapp_data: PFAppData;
case sasl_sml: SaslSML;
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*
SaslMsg*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SASL auth messages <-------> SASL auth messages
Application Data <-------> Application Data
]]>
</artwork>
</figure>
<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 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 use of SASL mechanisms that do not provide channel
binding support is NOT RECOMMENDED, but if they are used
then the application MUST ensure that the server
identity authenticated by TLS corresponds to the server
identity authenticated by SASL if any, and to the server
name provided by the user.</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. If channel
binding is used, as it should be, the initial SASL
authentication message will be bound to the TLS channel.
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:59:12 |