Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:
Nicolas Williams <Nicolas.Williams@sun.com> Tue, 03 November 2009 22:35 UTC
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: channel-binding@core3.amsl.com
Delivered-To: channel-binding@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F363A6831; Tue, 3 Nov 2009 14:35:06 -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 FdgmYQNaDAHg; Tue, 3 Nov 2009 14:35:05 -0800 (PST)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id CB86C3A67D6; Tue, 3 Nov 2009 14:35:05 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA3MZNxi006393; Tue, 3 Nov 2009 22:35:23 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 nA3MZNQN029500; Tue, 3 Nov 2009 15:35:23 -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 nA3MNrrf007585; Tue, 3 Nov 2009 16:23:53 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3MNrtr007584; Tue, 3 Nov 2009 16:23:53 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 03 Nov 2009 16:23:53 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: mrex@sap.com
Message-ID: <20091103222352.GJ1105@Sun.COM>
References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:
X-BeenThere: channel-binding@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of channel binding IANA registry requests and specifications <channel-binding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/channel-binding>
List-Post: <mailto:channel-binding@ietf.org>
List-Help: <mailto:channel-binding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2009 22:35:06 -0000
On Mon, Nov 02, 2009 at 03:59:44PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > Another problem that Larry has is that in his implementation what I call > > a "TLS connection" is called a "security context", and if the > > application re-handshakes (e.g., to authenticate a user) then the result > > is a second security context -- we need to be extra clear that it's the > > client Finished message from the _first_ "security context" that we're > > after. > > OooopS. > > The session that results from a re-handshake is an entirely new and > independent session from what it started from, it does NOT modify > the state of the original session (as identified by its TLS session ID). What "oops"? We need to identify one, and only one, client Finished message to use. The name of the thing that that message is related to is only relevant to writing the text for this channel binding type's definition. > Many SSL protocol stacks, however, will perform the re-negotiation > with the same "context" or API handle -- giving the application caller > impression that the original session is modified. TLS does _NOT_ > have capabilities to modify a session, however. It will either > resume a cached session as proposed by the client as-is, or it > will go through a full handshake and create a new session > that is entirely independent from previous sessions. > > The TLS specs do not describe API semantics, however, only the > network protocol and TLS session state, so your terminology is > IMHO confusing. All of that is irrelevant. > > > > My proposal, then, is this: > > > > OLD: > > > > 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). > > > > NEW: > > > > Description: The client's TLS Finished message (note: the Finished > > struct) from the first handshake of the application's TLS connection. > > > > NOTES: > > > > a) If a session is resumed, the client's TLS Finished message from > > the session resumption handshake is to be used; > > > > b) If a client does multiple TLS handshakes in sequence, each > > protected by the previous one, then the client's TLS Finished > > message from the first/outermost TLS connection is to be used; > > > > c) By "TLS connection" we refer to the TLS connection state, not to > > any notion of connection of any underlying transport protocols > > (such as TCP, UDP, SCTP, etcetera). > > > > I'm not sure that we can make it any clearer. > > > b) sounds wrong to me. A renegotiate results in a entirely > new and independent session. That a renegotiate does that is irrelevant. What is relevant is that we want the first Finished message. > It might be easier to _NOT_ key on the finished message, but on the > master secret instead. Too late for that. Nico --
- Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt … Nicolas Williams
- [CHANNEL-BINDING] Last Call: draft-altman-tls-cha… The IESG
- Re: [CHANNEL-BINDING] Last Call: draft-altman-tls… Simon Josefsson
- Re: [CHANNEL-BINDING] Last Call: draft-altman-tls… Nicolas Williams
- [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLVED (… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] lasgt call comments … Pasi.Eronen
- Re: [CHANNEL-BINDING] lasgt call comments (st Cal… Simon Josefsson
- Re: [CHANNEL-BINDING] lasgt call comments (st Cal… Simon Josefsson
- Re: [CHANNEL-BINDING] [sasl] lasgt call comments … Nicolas Williams
- [CHANNEL-BINDING] lasgt call comments (st Call: d… Larry Zhu
- Re: [CHANNEL-BINDING] lasgt call comments (st Cal… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] lasgt call comments … Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Martin Rex
- [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Martin Rex
- Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt … Simon Josefsson
- Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt … Martin Rex
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Martin Rex
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Martin Rex
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Peter Gutmann
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLV… Martin Rex
- Re: [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLV… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Martin Rex
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Pasi.Eronen
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Pasi.Eronen
- Re: [CHANNEL-BINDING] [TLS] lasgt call comments (… Pasi.Eronen
- Re: [CHANNEL-BINDING] [TLS] lasgt call comments (… Simon Josefsson
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] [TLS] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Jeffrey Hutzelman
- Re: [CHANNEL-BINDING] [sasl] [TLS] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Michael D'Errico
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Sam Hartman
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] lasgt call comments (… Simon Josefsson
- Re: [CHANNEL-BINDING] [TLS] lasgt call comments (… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Larry Zhu
- [CHANNEL-BINDING] New Problem (Was: Last Call: dr… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] New Problem (Was: Las… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] New Problem (Was: Las… Nicolas Williams