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, 05 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 --
- [TLS] Channel binding versus keying material expo… Douglas Stebila
- Re: [TLS] Channel binding versus keying material … Nicolas Williams