Subject: [CHANNEL-BINDING] Updates to draft-altman-tls-channel-bindings (PLEASE REVIEW)

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Mar 2010 18:15:22 -0500

Now that TLS re-negotiation security (RFC5746) is done we need to finish
draft-altman-tls-channel-bindings.

It's become clear that MSFT implemented and deployed something slightly
different than the 'tls-unique' binding description that had been
registered.  They seem to be the only implementors to date; their
implementation is secure, therefore I propose that we simply modify the
description of 'tls-unique' and be done.

The differences are:

 - it's not always the client's Finished message, but the _first_
   Finished message in the relevant handshake (in a session resumption
   handshake the server sends its Finished message first);

 - the Finished message is taken from the latest/inner-most TLS
   handshake, rather than the outer-most one

For the most common case, where there's no TLS re-negotiation and no TLS
session resumption, there is no difference.

It's past the I-D submission cut-off, so I can't submit an updated I-D.
Below are the full diffs from -07 to the -08 to-be.

Please review,

Nico

--- altman-tls-channel-bindings-07.unpg	Wed Mar 17 13:32:15 2010
+++ altman-tls-channel-bindings-08.unpg	Wed Mar 17 13:32:51 2010
@@ -1,594 +1,603 @@

 NETWORK WORKING GROUP                                          J. Altman
 Internet-Draft                                          Secure Endpoints
 Intended status: Standards Track                             N. Williams
-Expires: April 4, 2010                                               Sun
+Expires: September 18, 2010                                       Oracle
                                                                   L. Zhu
                                                    Microsoft Corporation
-                                                            October 2009
+                                                          March 17, 2010

                         Channel Bindings for TLS
-                draft-altman-tls-channel-bindings-07.txt
+                draft-altman-tls-channel-bindings-08.txt
 
 Status of this Memo
 
    This Internet-Draft is submitted to IETF in full conformance with the
    provisions of BCP 78 and BCP 79.  This document may contain material
    from IETF Documents or IETF Contributions published or made publicly
    available before November 10, 2008.  The person(s) controlling the
    copyright in some of this material may not have granted the IETF
    Trust the right to allow modifications of such material outside the
    IETF Standards Process.  Without obtaining an adequate license from
    the person(s) controlling the copyright in such materials, this
    document may not be modified outside the IETF Standards Process, and
    derivative works of it may not be created outside the IETF Standards
    Process, except to format it for publication as an RFC or to
    translate it into languages other than English.
 
    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."
 
    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 April 4, 2010.
+   This Internet-Draft will expire on September 18, 2010.
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   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 in effect on the date of
    publication of this document (http://trustee.ietf.org/license-info).
    Please review these documents carefully, as they describe your rights
    and restrictions with respect to this document.
 
 Abstract
 
    This document defines three channel binding types for Transport Layer
    Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-
    telnet, in accordance with RFC 5056 (On Channel Binding).

 Table of Contents
 
    1.    Conventions used in this document
    2.    Introduction
    3.    The 'tls-unique' Channel Binding Type
    3.1.  Description
    3.2.  Registration
    4.    The 'tls-server-end-point' Channel Binding Type
    4.1.  Description
    4.2.  Registration
    5.    The 'tls-unique-for-telnet' Channel Binding Type
    5.1.  Description
    5.2.  Registration
    6.    Applicability of TLS Channel Binding Types
    7.    Required Application Programming Interfaces
    8.    IANA Considerations
    9.    Security Considerations
    9.1.  Cryptographic Algorithm Agility
    9.2.  On Disclosure of Channel Bindings Data by Authentication
          Mechanisms
    10.   References
    10.1. Normative References
    10.2. Normative References for 'tls-server-end-point'
    10.3. Informative References
          Authors' Addresses

 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].

 2.  Introduction
 
    Subsequent to the publication of "On Channel Bindings" [RFC5246],
    three channel binding types for Transport Layer Security (TLS) were
    proposed, reviewed and added to the IANA channel binding type
    registry, all in accordance with [RFC5246].  Those channel binding
    types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for-
    telnet'.  It has become desirable to have these channel binding types
    re-registered through an RFC so as to make it easier to reference
-   them.  This document does just that.  The authors of those three
-   channel binding types have, or have indicated that they will,
-   transferred "ownership" of those channel binding types to the IESG.
+   them, and to correct them to describe actual implementations.  This
+   document does just that.  The authors of those three channel binding
+   types have, or have indicated that they will, transferred "ownership"
+   of those channel binding types to the IESG.
 
    We also provide some advice on the applicability of these channel
    binding types, as well as advice on when to use which.  And we
    provide an abstract API that TLS implementors should provide, by
    which to obtain channel bindings data for a TLS connection.

 3.  The 'tls-unique' Channel Binding Type
 
    IANA is hereby directed to update the registration of the 'tls-
-   unique' channel binding type to match the following.  Note that the
-   only material changes from the original registration should be: the
-   "owner" (now the IESG), contacts, the published specfication, and a
-   clarification to the description by the addition of a parenthetical
-   note (that is, the first such note in the descritption is a new
-   addition).  We also added a note indicating that this specification
-   contains applicability advice, and we moved security considerations
-   notes to the security considerations section of this document.  All
-   other fields of the registration are copied here for the convenience
-   of readers.
+   unique' channel binding type to match the following.  There are
+   material changes from the original registration, both in the
+   description as well as registration meta-data (such as registration
+   ownership).
 
 3.1.  Description
 
-   Description: The client's TLS Finished message (note: the Finished
-   struct) from the first handshake of the connection (note: connection,
-   not session, so that the channel binding is specific to each
-   connection regardless of whether session resumption is used).
+   Description: The first TLS Finished message sent (note: the Finished
+   struct) in the most recent TLS handshake of the TLS connection being
+   bound to (note: TLS connection, not session, so that the channel
+   binding is specific to each connection regardless of whether session
+   resumption is used).  If TLS re-negotiation takes place before the
+   channel binding operation, then the first TLS Finished message sent
+   of the latest/inner-most TLS connection is used.  Note that for full
+   TLS handshakes the first Finished message is sent by the client,
+   while for abbreviated TLS handshakes the first Finished message is
+   sent by the server.
 
 3.2.  Registration
 
    o  Channel binding unique prefix: tls-unique
 
    o  Channel binding type: unique
 
    o  Channel type: TLS [RFC5246]
 
    o  Published specification: <this document>
 
    o  Channel binding is secret: no
 
    o  Description: <See specification>
 
    o  Intended usage: COMMON
 
    o  Person and email address to contact for further information: Larry
       Zhu ([email-masked]), Nicolas Williams
       ([email-masked]).
 
    o  Owner/Change controller name and email address: IESG.
 
    o  Expert reviewer name and contact information: IETF TLS WG
       ([email-masked], failing that, [email-masked])
 
    o  Note: see the published specification for advice on the
       applicability of this channel binding type.

 4.  The 'tls-server-end-point' Channel Binding Type
 
    IANA is hereby directed to update the registration of the 'tls-
    server-end-point' channel binding type to match the following.  Note
    that the only material changes from the original registration should
    be: the "owner" (now the IESG), the contacts, the published
    specfication, and a note indicating that the published specification
    should be consulted for applicability advice.  References were added
    to the description.  All other fields of the registration are copied
    here for the convenience of readers.
 
 4.1.  Description
 
    Description: The hash of the TLS server's certificate [RFC5280] as it
    appears, octet for octet, in the server's Certificate message (note
    that the Certificate message contains a certificate_list, the first
    element of which is the server's certificate).
 
    The hash function is to be selected as follows:
 
    o  if the certificate's signatureAlgorithm uses a single hash
       function, and that hash function is either MD5 [RFC1321] or SHA-1
       [RFC3174] then use SHA-256 [FIPS-180-2];
 
    o  if the certificate's signatureAlgorithm uses a single hash
       function and that hash function neither MD5 nor SHA-1, then use
       the hash function associated with the certificate's
       signatureAlgorithm;
 
    o  if the certificate's signatureAlgorithm uses no hash functions or
       multiple hash functions, then this channel binding type's channel
       bindings are undefined at this time (updates to is channel binding
       type may occur to address this issue if it ever arises).
 
    The reason for using a hash of the certificate is that some
    implementations need to track the channel binding of a TLS session in
    kernel-mode memory, which is often at a premium.
 
 4.2.  Registration
 
    o  Channel binding unique prefix: tls-server-end-point
 
    o  Channel binding type: end-point
 
    o  Channel type: TLS [RFC5246]
 
    o  Published specification: <this document>
 
    o  Channel binding is secret: no
 
    o  Description: <See specification>
 
    o  Intended usage: COMMON
 
    o  Person and email address to contact for further information: Larry
       Zhu ([email-masked]), Nicolas Williams
       ([email-masked]).
 
    o  Owner/Change controller name and email address: IESG.
 
    o  Expert reviewer name and contact information: IETF TLS WG
       ([email-masked], failing that, [email-masked])
 
    o  Note: see the published specification for advice on the
       applicability of this channel binding type.

 5.  The 'tls-unique-for-telnet' Channel Binding Type
 
    IANA is hereby directed to update the registration of the 'tls-
    unique-for-telnet' channel binding type to match the following.  Note
    that the only material changes from the original registration should
    be: the "owner" (now the IESG), the contacts, the published
    specfication, and a note indicating that the published specification
    should be consulted for applicability advice.  The description is
    also clarified.  We also moved security considerations notes to the
    security considerations section of this document.  All other fields
    of the registration are copied here for the convenience of readers.
 
 5.1.  Description
 
    Description: There is a proposal for adding a "StartTLS" extension to
    TELNET, and a channel binding extension for the various TELNET AUTH
    mechanisms whereby each side sends the other a "checksum" (MAC) of
-   their view of the channel's bindings.  The client uses the first TLS
-   Finished messages (note: the Finished struct) from the client and
-   server, each concatenated in that order and in their clear text form.
-   The server does the same but in the opposite concatenation order
-   (server, then client).
+   their view of the channel's bindings.  The client uses the TLS
+   Finished messages (note: the Finished struct) sent by the client and
+   server, each concatenated in that order and in their clear text form,
+   of the first TLS handshake of the connection being bound to.  The
+   server does the same but in the opposite concatenation order (server,
+   then client).
 
 5.2.  Registration
 
    o  Channel binding unique prefix: tls-unique-for-telnet
 
    o  Channel binding type: unique
 
    o  Channel type: TLS [RFC5246]
 
    o  Published specification: <this document>
 
    o  Channel binding is secret: no
 
    o  Description: <See specification>
 
    o  Intended usage: COMMON
 
    o  Person and email address to contact for further information: Jeff
       Altman ([email-masked]), Nicolas Williams
       ([email-masked]).
 
    o  Owner/Change controller name and email address: IESG.
 
    o  Expert reviewer name and contact information: IETF TLS WG
       ([email-masked], failing that, [email-masked])
 
    o  Note: see the published specification for advice on the
       applicability of this channel binding type.

 6.  Applicability of TLS Channel Binding Types
 
    The 'tls-unique-for-telnet' channel binding type is only applicable
    to TELNET [RFC0854], and is available for all TLS connections.
 
    The 'tls-unique' channel binding type is available for all TLS
    connections, while 'tls-server-end-point' is only available when TLS
    cipher suites with server certificates are used, specifically: cipher
    suites that use the Certificate handshake message, which typically
    involve the use of PKIX [RFC5280].  For example, 'tls-server-end-
    point' is available when using TLS ciphers suites such as (this is
    not an exhaustive list):
 
    o  TLS_DHE_DSS_WITH_*
 
    o  TLS_DHE_RSA_WITH_*
 
    o  TLS_DH_DSS_WITH_*
 
    o  TLS_DH_RSA_WITH_*
 
    o  TLS_ECDHE_ECDSA_WITH_*
 
    o  TLS_ECDHE_RSA_WITH_*
 
    o  TLS_ECDH_ECDSA_WITH_*
 
    o  TLS_ECDH_RSA_WITH_*
 
    o  TLS_RSA_PSK_WITH_*
 
    o  TLS_RSA_WITH_*
 
    o  TLS_SRP_SHA_DSS_WITH_*
 
    o  TLS_SRP_SHA_RSA_WITH_*
 
    but is not available when using TLS cipher suites such as (this is
    not an exhaustive list):
 
    o  TLS_DHE_PSK_WITH_*
 
    o  TLS_DH_anon_WITH_*
 
    o  TLS_ECDHE_PSK_WITH_*
 
    o  TLS_ECDH_anon_WITH_*
 
    o  TLS_KRB5_WITH_*
 
    o  TLS_PSK_WITH_*
 
    o  TLS_SRP_SHA_WITH_*
 
    Nor is this channel binding type available for use with OpenPGP
    server certificates [RFC5081] [RFC4880] (since these don't use the
    Certificate handshake message).
 
    Therefore 'tls-unique' is generally better than 'tls-server-end-
    point'.  However, 'tls-server-end-point' may be used with existing
    TLS server-side proxies ("concentrators") without modification to the
    proxies, whereas 'tls-unique' may require firmware or software
    updates to server-side proxies.  Therefore there may be cases where
    'tls-server-end-point' may interoperate but where 'tls-unique' may
    not.
 
    Also, authentications mechanisms may arise which depend on channel
    bindings to contribute entropy, in which case unique channel bindings
    would have to always be used in preference to end-point channel
    bindings.  At this time there are no such mechanisms, though one such
    SASL mechanism has been proposed.  Whether such mechanisms should be
    allowed is out of scope for this document.
 
    In other words, for many applications there may be two potentially
    applicable TLS channel binding types.  Channel binding is all or
    nothing for the GSS-API [RFC2743], and likely other frameworks.
    Therefore agreement on the use of channel binding, and a particular
    channel binding type is necessary.  Such agreement can be obtained a
    priori, by convention, or negotiated.
 
    The specifics of whether and how to negotiate channel binding types
    are beyond the scope of this document.  However, it is RECOMMENDED
    that application protocols making use of TLS channel bindings, use
    'tls-unique' exclusively, except, perhaps, where server-side proxies
    are common in deployments of an application protocol.  In the latter
    case an application protocol MAY specify that 'tls-server-end-point'
    channel bindings must be used when available, with 'tls-unique' being
    used when 'tls-server-end-point' channel bindings are not available.
    Alternatively, the application may negotiate which channel binding
    type to use, or may make the choice of channel binding type
    configurable.
 
    Specifically, application protocol specifications MUST indicate at
    least one mandatory to implement channel binding type, MAY specify a
    negotiation protocol, MAY allow for out-of-band negotiation or
    configuration, and SHOULD have a preference for 'tls-unique' over
    'tls-server-end-point'.

 7.  Required Application Programming Interfaces
 
    TLS implementations supporting the use of 'tls-unique' and/or 'tls-
    unique-for-telnet' channel binding types, MUST provide application
    programming interfaces by which applications (clients and servers
    both) may obtain the channel bindings for a TLS connection.  Such
    interfaces may be expressed in terms of extracting the channel
    bindings data for a given connection and channel binding type.
    Alternatively the implementor may provide interfaces by which to
    obtain the initial client Finished message, the initial server
    Finished message and/or the server certificate (in a form that
    matches the description of the 'tls-server-end-point' channel binding
    type).  In the latter case the application has to have knowledge of
    the channel binding type descriptions from this document.  This
    document takes no position on which form these application
    programming interfaces must take.

 8.  IANA Considerations
 
    The IANA is hereby directed to update three existing channel binding
    type registrations.  See the rest of this document.

 9.  Security Considerations
 
-   The Security Considerations section of [RFC5056] applies to this
-   document.
+   The Security Considerations sections of [RFC5056], [RFC5246] and
+   [RFC5746] apply to this document.
 
    The TLS Finished messages (see section 7.4.9 of [RFC5246]) are known
    to both endpoints of a TLS connection, and are cryptographycally
-   bound to it.  Therefore the TLS Finished messages can be safely used
-   as a channel binding provided that the authentication mechanism doing
-   the channel binding conforms to the requirements in [RFC5056].
+   bound to it.  For implementations of TLS that correctly handle re-
+   negotiation [RFC5746] each handshake on a TLS connection is bound to
+   the preceding handshake, if any.  Therefore the TLS Finished messages
+   can be safely used as a channel binding provided that the
+   authentication mechanism doing the channel binding conforms to the
+   requirements in [RFC5056].
 
    The server certificate, when present, is also cryptographically bound
    to the TLS connection through its use in key transport and/or
    authentication of the server (either by dint of its use in key
    transport, by its use in signing key agreement, or by its use in key
    agreement).  Therefore the server certificate is suitable as an end-
    point channel binding as described in [RFC5056].
 
 9.1.  Cryptographic Algorithm Agility
 
    The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do
    not add any use of cryptography beyond that used by TLS itself.
    Therefore these two channel binding types add no considerations with
    respect to cryptographic algorithm agility.
 
    The 'tls-server-end-point' channel binding type consist of a hash of
    a server certificate.  The reason for this is to produce manageably
    small channel binding data, as some implementations will be using
    kernel-mode memory (which is typically scarce) to store these.  This
    use of a hash algorithm is above and beyond TLS's use of
    cryptography, therefore the 'tls-server-end-point' channel binding
    type has a security consideration with respect to hash algorithm
    agility.  The algorithm to be used, however, is derived from the
    server certificate's signature algorithm as described in Section 4.1;
    to recap: use SHA-256 if the certificate signature algorithm uses MD5
    or SHA-1, else use whatever hash function the certificate uses
    (unless the signature algorithm uses no hash functions or more than
    one hash function, in which case 'tls-server-end-point' is
    undefined).  This construction automatically makes 'tls-server-end-
    point' hash algorithm agile, with a dependency on PKIX and TLS for
    hash agility.
 
    Current proposals for randomized signatures algorithms
    [I-D.irtf-cfrg-rhash] [NIST-SP.800-106.2009] use hash functions in
    their construction -- a single hash function in each algorithm.
    Therefore the 'tls-server-end-point' channel binding type should be
    available even in cases where new signatures algorithms are used that
    are based on current randomized hashing proposals (but we cannot
    guarantee this, of course).
 
 9.2.  On Disclosure of Channel Bindings Data by Authentication
       Mechanisms
 
    When these channel binding types were first considered, one issue
    that some commenters were concerned about was the possible impact on
    the security of the TLS channel, of disclosure of the channel
    bindings data by authentication mechanisms.  This can happen, for
    example, when an authentication mechanism transports the channel
    bindings data, with no confidentiality protection, over other
    transports (for example, in communicating with a trusted third
    party), or when the TLS channel provides no confidentiality
    protection and the authentication mechanism does not protect the
    confidentiality of the channel bindings data.  This section considers
    that concern.
 
    When the TLS connection uses a cipher suite that does not provide
    confidentiality protection, the TLS Finished messages will be visible
    to eavesdroppers, regardless of what the authentication mechanism
    does.  The same is true of the server certificate which, in any case,
    is generally visible to eavesdroppers.  Therefore we must consider
    our choices of TLS channel bindings here to be safe to disclose by
    definition -- if that were not the case then TLS with cipher suites
    that don't provide confidentiality protection would be unsafe.
    Furthermore, the TLS Finished message construction depends on the
    security of the TLS PRF, which in turn needs to be resistant to key
    recovery attacks, and we think that it is, as it is based on HMAC,
    and the master secret is, well, secret (and the result of key
    exchange).
 
    Note too that in the case of an attempted active man-in-the-middle
    attack, the attacker will already possess knowledge of the TLS
    finished messages for both inbound and outbound TLS channels (which
    will differ, given that the attacker cannot force them to be the
    same).  No additional information is obtained by the attacker from
    the authentication mechanism's disclosure of channel bindings data --
    the attacker already has it, even when cipher suites providing
    confidentiality protection are provided.
 
    None of the channel binding types defined herein produce channel
    bindings data that must be kept secret.  Moreover, none of the
    channel binding types defined herein can be expected to be private
    (known only to the end-points of the channel), except that the unique
    TLS channel binding types can be expected to be private when a cipher
    suite that provides confidentiality protection is used to protect the
    Finished message exchanges and the application data records
    containing application-layer authentication messages.

 10.  References
 
 10.1.  Normative References
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 
    [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.
 
+   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
+              "Transport Layer Security (TLS) Renegotiation Indication
+              Extension", RFC 5746, February 2010.
+
 10.2.  Normative References for 'tls-server-end-point'
 
    [FIPS-180-2]
               United States of America, National Institute of Standards
               and Technology, "Secure Hash Standard (Federal Information
               Processing Standard (FIPS) 180-2".
 
 10.3.  Informative References
 
    [I-D.irtf-cfrg-rhash]
               Halevi, S. and H. Krawczyk, "Strengthening Digital
               Signatures via Randomized Hashing",
               draft-irtf-cfrg-rhash-01 (work in progress), October 2007.
 
    [NIST-SP.800-106.2009]
               National Institute of Standards and Technology, "NIST
               Special Publication 800-106: Randomized Hashing for
               Digital Signatures", February 2009.
 
    [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
               Specification", STD 8, RFC 854, May 1983.
 
    [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.
 
    [RFC2743]  Linn, J., "Generic Security Service Application Program
               Interface Version 2, Update 1", RFC 2743, January 2000.
 
    [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
               (SHA1)", RFC 3174, September 2001.
 
    [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
               Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
 
    [RFC5081]  Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
               Layer Security (TLS) Authentication", RFC 5081,
               November 2007.
 
    [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
               Housley, R., and W. Polk, "Internet X.509 Public Key
               Infrastructure Certificate and Certificate Revocation List
               (CRL) Profile", RFC 5280, May 2008.

 Authors' Addresses
 
    Jeff Altman
    Secure Endpoints
    255 W 94TH ST PHB
    New York, NY  10025
    US
 
    Email: [email-masked]

    Nicolas Williams
-   Sun Microsystems
+   Oracle
    5300 Riata Trace Ct
    Austin, TX  78727
    US
 
-   Email: [email-masked]
+   Email: [email-masked]

    Larry Zhu
    Microsoft Corporation
    One Microsoft Way
    Redmond, WA  98052
    US
 
    Email: [email-masked]

---

From: <[email-masked]>
Date: Thu, 18 Mar 2010 12:49:11 +0100

A question for SASL: both GS2 and SCRAM are currently in
RFC Editor AUTH48, and they have a normative reference
to the IANA registration page for 'tls-unique'.

Since it appears we're about to change that registration
quite radically, what's the impact on GS2/SCRAM? Have GS2
and/or SCRAM implementors implemented the 'tls-unique'
binding?

And should we publish the RFCs at this time, if we know one
of the normative references is, well, unstable (likely to
change in non-backward-compatible way soon)?

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Nicolas Williams
> Sent: 18 March, 2010 01:15
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [sasl] Updates to draft-altman-tls-channel-bindings (PLEASE
> REVIEW)
>
>                                                                    L.
> Zhu
>                                                     Microsoft
> Corporation
> -                                                            October
> 2009
> +                                                          March 17,
> 2010
> _______________________________________________
> sasl mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sasl

---

From: Dave Cridland <[email-masked]>
Date: Thu, 18 Mar 2010 13:45:13 +0000

> and/or SCRAM implementors implemented the 'tls-unique'
This SCRAM implementor did, yes. And I followed the specification.  
Aren't I naïve?

> >    handshake the server sends its Finished message first);

This is quite annoying. It's harder for me (personally) to implement,  
given the APIs I'm working with. Moreover, since it changes with a  
(relatively) unusual feature of TLS, I suspect people will get this  
wrong - most uses of TLS in, for example, XMPP or IMAP do not appear  
to use session resumption much.

> >    handshake, rather than the outer-most one

This unnerves me. I'd prefer to use only the first negotiation from  
each side, since that effectively means that both ends know which one  
that was. Moreover, in principle a negotiation could occur during the  
SASL exchange, which would then invalidate the channel binding.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Mar 2010 16:22:20 +0100

Dave Cridland <[email-masked]> writes:

> This SCRAM implementor did, yes. And I followed the
> specification. Aren't I naïve?

I've done testing with the IANA registered tls-unique too.  GnuTLS added
APIs for this two major/stable release cycles ago (2008-10) which is now
widely deployed.  It may be that the APIs are flexible enough to be able
to implement the new semantics, although I suppose applications would
need to be modified.  I haven't analyzed the details yet...

What kind of software has Microsoft deployed already that use
tls-unique?  I thought GS2 and SCRAM were the most ready protocols that
used it, and they are still not final.

Changing the IANA specification for tls-unique long after it has been
registered and published seems bad to me.  Bad enough to make me think
that it is a mistake for GS2/SCRAM to reference the IANA specification
normatively -- if the IANA registry is not immutable, interop is not
possible.

There is always the option of making GS2/SCRAM reference 'tls-unique2'
and specify that clearly and stable once and for all.  Then we can let
'tls-unique' be the interop mess that it appears to be right now.

/Simon

> CHANNEL-BINDING mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/channel-binding

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 18 Mar 2010 10:42:45 -0500

Oh dear.  Larry?  Can you please chime in as to whether you can fix your
implementation to match the original spec?  Anybody else?

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Thu, 18 Mar 2010 18:13:43 +0000

It seems that we can leave tls-unique as is, and add a new registry, let's say, called "tls-dynamic" or similar, to use the updated definition. Unless some one finds a case where interop can be an issue, it is probably a better way to go.

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: Thursday, March 18, 2010 8:22 AM
To: Dave Cridland
Cc: [email-masked]; SASL Working Group; [email-masked]
Subject: Re: [sasl] [CHANNEL-BINDING] Updates to draft-altman-tls-channel-bindings (PLEASE REVIEW)

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 18 Mar 2010 13:17:05 -0500

On Thu, Mar 18, 2010 at 06:13:43PM +0000, Larry Zhu wrote:
> It seems that we can leave tls-unique as is, and add a new registry,
> let's say, called "tls-dynamic" or similar, to use the updated
> definition. Unless some one finds a case where interop can be an
> issue, it is probably a better way to go.

We can do that, but it doesn't solve any problems because we don't have
a way to negotiate which channel binding type to use.  It would be best
to reach agreement on tls-unique and make sure that any implementors
that have to make changes do so while it's still early.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Mar 2010 19:16:07 +0000

On Thu, Mar 18, 2010 at 3:22 PM, Simon Josefsson <[email-masked]> wrote:

 [...]

> 'tls-unique' be the interop mess that it appears to be right now.

+1.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 18 Mar 2010 14:20:11 -0500

> > 'tls-unique' be the interop mess that it appears to be right now.

I'd missed this.  Yes, this works.

Fair enough.  That will be what I'll do.  I'll add 'tls-unique2' that
will match what MSFT implements in (I think) HTTP/Negotiate, and I'll
add suitable applicability statements.

Larry, can you list the application protocols where you're using channel
binding now?

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Mar 2010 19:26:07 +0000

> add suitable applicability statements.

Does Microsoft depend on the name of the channel binding?
If yes, we can update SCRAM/GS2 to reference tls-unique2, which would
be defined as we like.
I.e. tls-unique can be just left alone.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 18 Mar 2010 14:42:27 -0500

> Does Microsoft depend on the name of the channel binding?

I doubt it.  I've asked Larry off-line as well.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 19 Mar 2010 08:41:26 +0100

> I doubt it.  I've asked Larry off-line as well.

If they don't, we can keep the definition of tls-unique as it is, and
let Larry's application use a newly defined tls-unique-msft or similar.
I think this would cause the least amount of problems for GS2/SCRAM
implementers.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 19 Mar 2010 09:57:34 +0100

> +   while for abbreviated TLS handshakes the first Finished message is

I don't follow this fully -- IF you use the latest TLS finished message,
the channel binding data WILL be specific the each TLS session, and it
will depend on whether the session is resumed or not, which is contrary

> +   resumption is used).  If TLS re-negotiation takes place before the

I wonder what happens if a TLS re-negotiation happens after the client
started its authentication attempt (for GS2-KRB5: sent the AP-REQ) but
before the server has responded (for GS2-KRB5: sent the AP-REP)?  Then
authentication will fail, it seems, because the client and server will
have different ideas of what the channel binding data should be.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Mar 2010 18:30:05 -0500

> will depend on whether the session is resumed or not, which is contrary

No, the _first_ finished message of the _latest_ handshake.  That's what
Larry says MSFT implemented.  I still don't know if that's just for
HTTP/Negotiate or what.

> have different ideas of what the channel binding data should be.

Good question.  That's one reason to use the first handshake.

---

From: Martin Rex <[email-masked]>
Date: Sat, 20 Mar 2010 01:13:08 +0100 (MET)

> Larry says MSFT implemented.  I still don't know if that's just for

Is that a successor to rfc-4559?  Is there a draft available?

Personally, I think that channel binding should be done to the
communication channel, not to a particular TLS session.

I think the original definition of tls-unique is _much_ better,
even though it will require the TLS stack to memorize an additional
connection parameter from the first handshake on a connection.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 Mar 2010 18:21:50 -0500

I've posted -08 of draft-altman-tls-channel-bindings:

http://www.ietf.org/id/draft-altman-tls-channel-bindings-08.txt

This version adopts the form of tls-unique that MSFT has implemented and
deployed, which is backwards-incompatible with the original.  I expect
this will be a controversial change.  A new IETF Last Call will be
necessary, and publication of GS2 and SCRAM will have to be held up
until the IANA registration of tls-unique is updated.

Pasi,

Please review this change and begin a new IETF Last Call at your
earliest convenience.  Thanks,

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 22 Mar 2010 16:48:22 -0700

> earliest convenience.  Thanks,

After talking to Pasi/Tim/Sean, I will be taking over AD sponsoring of
this document.
So I will be starting IETF LC.
But of course I would encourage Pasi to review this.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Mar 2010 01:53:01 -0500

> http://www.ietf.org/id/draft-altman-tls-channel-bindings-08.txt

I forgot to describe the synchronization problem that Simon pointed out,
as well as the solution.

I'll file -09 tomorrow.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Mar 2010 14:06:29 -0500

> I forgot to describe the synchronization problem that Simon pointed out,

Submitted:

http://www.ietf.org/id/draft-altman-tls-channel-bindings-09.txt

Larry, Mark,

It occurs to me that it must be very unlikely that any apps using the
MSFT variant of tls-unique are doing authentication after TLS
re-negotiation.  We already have confirmation that in the HTTP/Negotiate
case that never happens.  If so, might you be willing to fix your
implementation to always use the initial handshake?  That would help
remove two pieces of complexity from -09: a) security considerations with
regard to the TLS re-negotiation bug, b) interoperability considerations
with regard to the channel binding synchronization problem.

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Tue, 23 Mar 2010 19:56:19 +0000

> re-negotiation.

Should we instead say that the receiver/verifier of the tls-unique binding is encouraged to remember the previous finished structure before re-negotiation. If the synchronization is more than 2 finished messages apart, the auth request is expected to fail.

This way we have a solution when the actual need arises, without complicating either the interface or the protocol. Hopefully the burden to implementation is minimal as well. Is that reasonable?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Tuesday, March 23, 2010 12:06 PM
To: [email-masked]; [email-masked]; [email-masked]; Mark Novak; Larry Zhu
Cc: Pasi Eronen
Subject: Re: [TLS] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

Submitted:

Larry, Mark,

Nico
-- 
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Mar 2010 14:59:56 -0500

On Tue, Mar 23, 2010 at 07:56:19PM +0000, Larry Zhu wrote:
> Should we instead say that the receiver/verifier of the tls-unique
> binding is encouraged to remember the previous finished structure
> before re-negotiation. If the synchronization is more than 2 finished
> messages apart, the auth request is expected to fail.

What's the motivation?  Is it really that hard to keep the initial CB
around?  It is tiny...

> This way we have a solution when the actual need arises, without
> complicating either the interface or the protocol. Hopefully the
> burden to implementation is minimal as well. Is that reasonable?

Ah, I think I understand.  In your API it's the application's burden to
remember the CB from the initial handshake.  But even so, that does not
seem like such a tough burden.

Your proposal is more reasonable than the earlier one for the simple
reason that we'll never see three handshakes prior to authentication,
and accepting the possibility of spurious authentication failures in
such cases, if they happened, would be OK with me.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Mar 2010 15:04:55 -0500

Also, what applications are you using 'tls-unique' in besides
HTTP/Negotiate?

---

From: Larry Zhu <[email-masked]>
Date: Tue, 23 Mar 2010 20:48:41 +0000

I briefly chatted with Sam who was in the tls-unique design/discussion meeting last Sunday. It turns out that the community as represented by key stake holders in that meeting believed that:

1) TLS renegotiation is driven by TLS apps.
2) as the result, the apps can figure out, based on the app specific context, which TLS side will start renegotiation and when, e.g. in a locked-step fashion.
2) therefore it is acceptable to leave the behavior in the case of the described synchronization undefined.

If this does not capture the spirit of that discussion, please let me know. 

Shall we proceed with that and capture the discussion in the ID (that means another update to the ID). Personally I am not aware of any new data points that would invalidate the above recommendation.

Thanks,

--Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 1:00 PM
To: Larry Zhu
Cc: [email-masked]; [email-masked]; [email-masked]; Mark Novak; Pasi Eronen
Subject: Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Mar 2010 21:56:12 +0100

> 1) TLS renegotiation is driven by TLS apps.

I recall that both OpenSSL and NSS drive TLS renegotiation internally
(i.e., TLS apps are not required to do the handshake).  For GnuTLS, it
is the apps that drives TLS renegotiation.  Can someone confirm/deny my
recollection?  As far as I recall, the reason the TLS renegotiation
issue was problematic for OpenSSL/NSS (and not for GnuTLS) was that the
former libraries drives renegotiation internally in the library.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Mar 2010 15:55:55 -0500

On Tue, Mar 23, 2010 at 08:48:41PM +0000, Larry Zhu wrote:
> I briefly chatted with Sam who was in the tls-unique design/discussion
> meeting last Sunday. It turns out that the community as represented by
> key stake holders in that meeting believed that:
> 
> 2) as the result, the apps can figure out, based on the app specific
> context, which TLS side will start renegotiation and when, e.g. in a
> locked-step fashion.

It does.  However, it does also mean that I had to write a bunch of
normative text in draft-altman-... to say that apps must do this.  That
strikes me as ugly complexity.

If you never have re-negotiation happening before authentication then
why do we need to worry about this?  -- that's my question.

> Shall we proceed with that and capture the discussion in the ID (that
> means another update to the ID).

I wrote -09 so as to capture that discussion.

>                                  Personally I am not aware of any new
> data points that would invalidate the above recommendation.

I'm asking questions about your implementation.  The answers to those
questions might actually bring new data points to light that, while they
wouldn't invalidate our earlier decision, might lead us to re-consider
that decision.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Mar 2010 15:58:08 -0500

> former libraries drives renegotiation internally in the library.

But what is the trigger?  Key aging?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Mar 2010 22:03:06 +0100

> But what is the trigger?  Key aging?

A renegotiation request from the peer, as I understood it.

/Simon

---

From: Larry Zhu <[email-masked]>
Date: Tue, 23 Mar 2010 21:07:12 +0000

Nicolas Williams wrote:
> It does.  However, it does also mean that I had to write a bunch of normative text in draft-altman-... to say that apps must do this.  That strikes me as ugly complexity.
> If you never have re-negotiation happening before authentication then why do we need to worry about this?  -- that's my question.

It is amusing that if you actually suggest that it is more complex to leave the behavior as undefined.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Tuesday, March 23, 2010 1:56 PM
To: Larry Zhu
Cc: Mark Novak; [email-masked]; Pasi Eronen; [email-masked]; [email-masked]
Subject: Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Mar 2010 16:14:01 -0500

On Tue, Mar 23, 2010 at 09:07:12PM +0000, Larry Zhu wrote:
> > normative text in draft-altman-... to say that apps must do this.
> > That strikes me as ugly complexity.  If you never have
> > re-negotiation happening before authentication then why do we need
> > to worry about this?  -- that's my question.
> 

I _never_ said that.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 23 Mar 2010 22:15:56 +0100 (MET)

> A renegotiation request from the peer, as I understood it.

That was my understanding as well.

Whether the server tries to request a client certificate on the
initial handshake or whether it tries to request it after having
seen the request (and before sending a 401 Unauthorized reply)
is a configurable behaviour of some servers.

Client apps on OpenSSL style APIs usually do not know, and should
not have to care, whether the server is configured in that
originally very dangerous fashion and that the clients local
TLS implementation performs the TLS renegotiation transparently.

When it is the client app that retrieves the ChannelBindings information
from the TLS implementation and feeds it into gss_init_sec_context(),
then the channel binding information should be sticky to the
TLS connection handle (which represents the communication channel
as seen by the application).

I believe we agreed and documented in the Security Considerations
section of the TLS renegotiation RFC that a change in the servers
identity during a server-triggered TLS renegotiation, which is not
necessarily visible at the API used by the client app, may come as
a surprise to that client app and should _NOT_ be the default.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Mar 2010 22:22:48 +0100

> as seen by the application).

I believe the Microsoft implementation of the 'tls-unique' channel
binding leads to different cb after each TLS handshake.  So the cb is
not sticky.  I guess the question is if there is any problem (*) in
making the Microsoft approach the official definition.

/Simon

(*) Aside changing an already published definition.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Mar 2010 16:24:48 -0500

> with regard to the channel binding synchronization problem.

I need to re-word my question to clarify that I'm not interested in
knowing what MSFT proprietary apps you're using CB in.  Does TLS
re-negotiation ever occur prior to authentication in any of your
applications?  I'm NOT interested in knowing anything else about
proprietary MSFT applications, just that one detail about Internet as
well as proprietary apps.

The point of the question is to establish whether we really have to pick
the first Finished message of the latest/inner-most handshake or if
there's still time for you to fix your implementation so that we can use
the first Finished message of the first/outer-most handshake.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 24 Mar 2010 00:14:33 +0100 (MET)

> to leave the behavior as undefined.

The part that is a little funny (or weird) is something else.

When we realized that the original TLS renegotiation resulted,
in fact, in a completely different and unrelated channel than
its predecessor, and that all apps that blindly assumed it
would be still the same channel, we decided to fix TLS and
provide that assurance to the app.

_After_ fixing TLS renegotiation, it sounds strange to
define TLS channel bindings that clearly indicate that the
channel before TLS renegotiation and after TLS renegotiation
is _NOT_ the same channel (because it uses different channel
bindings and will make authentications fail that mix them up).

That is IMHO a little weird.

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Tue, 23 Mar 2010 23:42:02 +0000

More precisely we allow you treat the renegotiated channel the same in  
tls- endpiont, or differentally in tls-unique. Thus the flexiblity  
remains yours.

Sent from my phone

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Mar 2010 16:28:30 -0500

> A renegotiation request from the peer, as I understood it.

The peer being the TLS server.  What's the trigger on the server side?

In most apps authentication happens soon after establishing the channel,
so re-keying as a trigger is out of the question.  That leaves TLS
authentication using a user cert, which is a form of authentication in
itself, and which the server application ought not request
asynchronously from application-layer authentication.

It's possible that in practice we never authenticate before
re-negotiation because the server doesn't ever need to request
re-negotiation before authentication.  The spec would still need
significant amounts of verbiage about this situation, but at least
avoiding the situation would be much easier because avoidance could be
done using existing APIs on the server-side instead of requiring new
APIs on the client side.

(Of course, if it never happens, then it seems much less necessary to
change the spec for tls-unique to say that re-negotiation changes the
channel's CB.  But it might turn out to always happen for future app
protocols, in which case a discrepancy amongst implementors would be
bad.  Also, there exist SASL apps allow for re-authentication at any
time, so we must agree on one approach.)

I'm much more comfortable with avoiding the CB synchronization problem
by using existing APIs on the server side.  Do we agree that this is
possible and desirable?  If so I'll make the change.

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Wed, 31 Mar 2010 15:45:07 +0200

Nico:

> http://www.ietf.org/id/draft-altman-tls-channel-bindings-09.txt

That URL doesn't work for me.  For those actually trying to find it via 
a link it is here:

http://tools.ietf.org/id/draft-altman-tls-channel-bindings-09.txt

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2010 11:39:40 -0500

On Wed, Mar 31, 2010 at 03:45:07PM +0200, Eliot Lear wrote:
> That URL doesn't work for me.  For those actually trying to find it
> via a link it is here:

Strange.  Maybe because I submitted -10?

> http://tools.ietf.org/id/draft-altman-tls-channel-bindings-09.txt

Review -10.  The changes from -09: I added text on avoiding the sync
problem using client-side and server-side techniques.

---

From: Sean Turner <[email-masked]>
Date: Wed, 31 Mar 2010 15:25:35 -0400

If you don't mind the html version:
http://tools.ietf.org/html/draft-altman-tls-channel-bindings

It automagically takes you to the latest version.

spt