[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.123, available from https://tools.ietf.org/tools/rfcmarkup/