One document matched: draft-williams-tls-app-sasl-opt-01.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-01.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 title='Using SASL'>
<t>In order to use SASL in this extension it's important
to define how the client requests authentication,
how it sends its first message when the mechanism is
a client-speaks-first mechanism, 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.</t>
<t>For SASL mechanisms where the first message is sent
by the server the client MUST send an empty SaslMsg
handshake message. For SASL mechanisms where the
first message is sent by the client the MUST send
the mechanism's first message in the client's
SaslMsg handshake message, and it MUST prefix the
mechanism's first message with the name of the
mechanism and a zero-valued byte:
"<mech-name><NUL><mech-message>.</t>
<t>After the TLS handshake finishes the application must
conitnue 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
SHOULD send a network byte order, four byte unsigned
binary length of the mechanism message followed by
the mechanism message as-is. 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 SHOULD consist of four bytes with
all bits set followed by a network byte order four
byte unsigned binary length of supplementary
information to be defined by the application.
Whereas a server's failed authentication message
SHOULD 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. 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 the encoding SHOULD
default to 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. 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>
</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 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:56:29 |