Re: [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:)
Martin Rex <Martin.Rex@sap.com> Wed, 04 November 2009 00:01 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 47EA93A6936; Tue, 3 Nov 2009 16:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.197
X-Spam-Level:
X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 MaHHInw4ERKa; Tue, 3 Nov 2009 16:01:41 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 1E0223A686B; Tue, 3 Nov 2009 16:01:40 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA401tk5002236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 01:01:55 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200911040001.nA401rVh002365@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com
Date: Wed, 04 Nov 2009 01:01:53 +0100
In-Reply-To: <20091103222045.GI1105@Sun.COM> from "Nicolas Williams" at Nov 3, 9 04:20:45 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: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] Unrelated (Re: [CHANNEL-BINDING] 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: Wed, 04 Nov 2009 00:01:42 -0000
Nicolas Williams wrote: > > > > I was refering to a design flaw in server-side session caching of > > Microsoft IIS (the Server) when it is configured to perform renegotiation > > in order to obtain a client certificate after having seen and evaluated > > the request. > > 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). The way it is currently implemented in IIS, it will force the client through a renegotiate on every SSL resume. I never checked how other clients deal with a server that asks them to do a renegotiate in order to ask for a client certificate. Since a renegotiate will ALWAYS result in an entirely new TLS session by performing a full TLS handshake, a sensible client should replace the previously cached session with the re-negotiated one in the client-side cache. A server with a correctly working server-side session cache will find the reply to the CertificateRequest from the regenotiation if that session is later resumed on a new connection and does not need to force a renegotiate when a client proposes a TLS session resume over a new network connection (which is what Microsoft IIS currently does). This strange behaviour of Microsoft IIS only applies for the renegotiation configuration. IIRC, when Microsoft IIS is configured to always ask for the client certificate, it will do so in the initial TLS handshake and correctly use the memorized answer of the client on later TLS session resumes. -Martin
- [TLS] Last Call: draft-altman-tls-channel-binding… The IESG
- Re: [TLS] lasgt call comments (st Call: draft-alt… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: Martin Rex
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- [TLS] RESOLVED (Re: [sasl] lasgt call comments (s… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Simon Josefsson
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Peter Gutmann
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLVED (… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLV… Martin Rex
- Re: [TLS] [CHANNEL-BINDING] Unrelated (Re: RESOLV… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Pasi.Eronen
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Michael D'Errico
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Jeffrey Hutzelman
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Sam Hartman
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] lasgt call comments (st Call: draft-alt… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Larry Zhu
- [TLS] New Problem (Was: Last Call: draft-altman-t… Nicolas Williams
- Re: [TLS] New Problem (Was: Last Call: draft-altm… Larry Zhu
- Re: [TLS] [CHANNEL-BINDING] New Problem (Was: Las… Nicolas Williams