Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to

Martin Rex <mrex@sap.com> Tue, 23 March 2010 21:15 UTC

Return-Path: <mrex@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 941B03A6CAC; Tue, 23 Mar 2010 14:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.119
X-Spam-Level:
X-Spam-Status: No, score=-9.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 p9UgBZ2dvwuQ; Tue, 23 Mar 2010 14:15:50 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0D3483A6BA1; Tue, 23 Mar 2010 14:15:40 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o2NLFvHk019852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 22:15:57 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003232115.o2NLFuOS025546@fs4113.wdf.sap.corp>
To: simon@josefsson.org (Simon Josefsson)
Date: Tue, 23 Mar 2010 22:15:56 +0100 (MET)
In-Reply-To: <87hbo6px85.fsf@mocca.josefsson.org> from "Simon Josefsson" at Mar 23, 10 10:03:06 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: Mark.Novak@microsoft.com, channel-binding@ietf.org, Nicolas.Williams@sun.com, pasi.eronen@nokia.com, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to
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: Tue, 23 Mar 2010 21:15:51 -0000

Simon Josefsson wrote:
> 
> Nicolas Williams <Nicolas.Williams@sun.com> writes:
> 
> > On Tue, Mar 23, 2010 at 09:56:12PM +0100, Simon Josefsson wrote:
> >> 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.
> >
> > But what is the trigger?  Key aging?
> 
> 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