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 (Nicolas Williams)
Date: Wed, 4 Nov 2009 01:01:53 +0100 (MET)
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