Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:

Martin Rex <Martin.Rex@sap.com> Mon, 02 November 2009 14:59 UTC

Return-Path: <Martin.Rex@sap.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 702A33A657C; Mon, 2 Nov 2009 06:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.202
X-Spam-Level:
X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 597Bt2s2X7u1; Mon, 2 Nov 2009 06:59:29 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BF13128C14D; Mon, 2 Nov 2009 06:59:27 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA2Exj5S008421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 15:59:45 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com (Nicolas Williams)
Date: Mon, 2 Nov 2009 15:59:44 +0100 (MET)
In-Reply-To: <20091030223647.GO1105@Sun.COM> from "Nicolas Williams" at Oct 30, 9 05:36:48 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org
Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 02 Nov 2009 14:59:30 -0000

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

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.

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

It might be easier to _NOT_ key on the finished message, but on the
master secret instead.

-Martin