Re: [TLS] Channel binding versus keying material exporters

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 05 November 2009 17:10 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D1F3A6768 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 09:10:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.045
X-Spam-Level:
X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-D4t7wxc6fI for <tls@core3.amsl.com>; Thu, 5 Nov 2009 09:10:24 -0800 (PST)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id DD9623A67EA for <tls@ietf.org>; Thu, 5 Nov 2009 09:10:21 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA5HAW6G008548 for <tls@ietf.org>; Thu, 5 Nov 2009 17:10:44 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA5HAWA2040295 for <tls@ietf.org>; Thu, 5 Nov 2009 10:10:32 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA5Gx1bU009151; Thu, 5 Nov 2009 10:59:01 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5Gx1bM009150; Thu, 5 Nov 2009 10:59:01 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 5 Nov 2009 10:59:00 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Douglas Stebila <douglas@stebila.ca>
Message-ID: <20091105165900.GW1105@Sun.COM>
References: <3DE8D6FD-CABD-4851-9ACC-189CB0E1CE61@stebila.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DE8D6FD-CABD-4851-9ACC-189CB0E1CE61@stebila.ca>
User-Agent: Mutt/1.5.7i
Cc: tls@ietf.org
Subject: Re: [TLS] Channel binding versus keying material exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2009 17:10:25 -0000

On Fri, Nov 06, 2009 at 12:23:05AM +0800, Douglas Stebila wrote:
> Can someone comment on the similarities and differences of TLS channel  
> binding and TLS keying material exporters?  Is the keying material  
> derived from a TLS master key using a keying material exporter  
> suitable for channel binding as well, if used for key confirmation?   
> If a higher-level application wishes to do additional authentication  
> and bind the endpoints of that authentication to the endpoints of the  
> TLS connection, should one use key confirmation with keying material  
> exporters or something from TLS channel binding?

TLS connections[0] form a secure channel.  They also optionally provide
authentication, and are often run on top of other TLS connections[1].
Therefore there's two ways in which channel binding is interesting for
TLS: a) you should be able to get channel binding information _from_ a
TLS channel to bind into authentication at a higher layer, b) you should
be able to provide channel binding information to TLS to bind into its
handshake.

The two ways in which TLS relates to channel binding are two sides of
the same coin, but we need to look at them separately.

At this point I recommend reading RFC5056.

For (a), see draft-altman-tls-channel-bindings-07.

For (b), see the recent draft-solinas-tls-additional-prf-input-00.

You ask if we could use the TLS exporter to create a channel binding for
TLS, and the answer is: no, or at least not by itself.  You could use
the exporter to construct a channel binding that is sufficiently secure,
but why re-invent the wheel?  You really should use one of the channel
binding types for TLS defined in draft-altman-tls-channel-bindings-07.

The TLS exporter, as defined in draft-ietf-tls-extractor-07, is this:

          PRF(SecurityParameters.master_secret, label,
              SecurityParameters.client_random +
              SecurityParameters.server_random +
              context_value_length + context_value
              )[length]

Compare that to the Finished message computation:

         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];

Both use the TLS PRF() and master secret.  But only the second
formulation also binds all the handshake messages.  The second
formulation therefore protects all of the negotiation involved
in a TLS exchange, while the first protects only the key
exchange, and that makes the Finished message construction more
appropriate as a channel binding for TLS than the exporter.

This has been much, much discussed in the past in the context of
draft-altman-tls-channel-bindings, including one or more proposals that
we use the TLS PRF instead of Finished messages.  That we need to use a
Finished message or a similar construction is and has been the consensus
for a long time.

[0]  There's been a lot of confusion lately about what is meant when one
     says "TLS connection".  I use it to mean "the TLS state created by
     a TLS hello, handshake and finished message exchange".

[1]  This is called re-negotiation.  The client initiates one TLS
     exchange, then either the client or server initiates a second
     exchange.  This is basically TLS-over-TLS, though to be pedantic,
     the inner connection can replace the outer, so it's not quite
     TLS-over-TLS, but the inner TLS connection's handshake does happen
     with the protection of the outer TLS connection's record layer.

     As you surely know by now, there's no real binding between the
     inner and outer TLS connections -- the only possible binding is for
     the client to enforce that the server uses a cert in both TLS
     connections, and that it uses the _same_ cert in both TLS
     connections.

     From EKR's message about the re-negotiation MITM vulnerability, I
     gather that TLS will be modified to provide a direct channel
     binding that both, the client _and_ server can enforce for the
     nested TLS case.  IMO that's the correct solution, though in the
     very short-term the quickest, most interoperable solution is for
     clients to do as described in above.

Nico
--