IETF Logo Mail Archive

Re: [TLS] [CHANNEL-BINDING] Unrelated (Re: RESOLVED (Re: [sasl] lasgt call comments (st Call:)

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 04 November 2009 00:18 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 98F843A6A34; Tue, 3 Nov 2009 16:18:14 -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 alMGzZp79hVp; Tue, 3 Nov 2009 16:18:14 -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 C7F3C3A6897; Tue, 3 Nov 2009 16:18:13 -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 nA40IVCF029003; Wed, 4 Nov 2009 00:18:31 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 nA40IUBi021644; Tue, 3 Nov 2009 17:18:31 -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 nA3NxVxQ007665; Tue, 3 Nov 2009 17:59:31 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3NxUr9007664; Tue, 3 Nov 2009 17:59:30 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 03 Nov 2009 17:59:30 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: mrex@sap.com
Message-ID: <20091103235930.GP1105@Sun.COM>
References: <20091103222045.GI1105@Sun.COM> <200911040001.nA401rVh002365@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200911040001.nA401rVh002365@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] [CHANNEL-BINDING] Unrelated (Re: RESOLVED (Re: [sasl] lasgt call comments (st Call:)
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: Wed, 04 Nov 2009 00:18:14 -0000

On Wed, Nov 04, 2009 at 01:01:53AM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > Why is that a problem?  The request will have named a document, but if
> > you're using confidentiality protection then so what?  The client knows
> > the document name, and so does the server.  Authorization _correctly_
> > happens when the access request is made.  That the necessary user
> > authentication step is delayed until authorization is needed doesn't
> > strike me as a problem -- it's a feature.
> 
> You are barking up the wrong tree.
> 
> The flaw in Microsoft IIS is, that it's server-side session cache is
> somehow broken.  Once it has forced the client through a renegotiate,
> it should memorize what the client sent as response to the
> CertificateRequest message (either a client cert or the indication
> that it doesn't have one or doesn't want to send one).

Ah, sure, that sounds like a bug.

Nico
--

v2.23.0 | Report a Bug | By Email