IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 03 November 2009 09:06 UTC

Return-Path: <pgut001@wintermute01.cs.auckland.ac.nz>
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 129F73A6999; Tue, 3 Nov 2009 01:06:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.564
X-Spam-Level:
X-Spam-Status: No, score=-4.564 tagged_above=-999 required=5 tests=[AWL=-1.965, BAYES_00=-2.599]
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 Sw8FJ97M6P8c; Tue, 3 Nov 2009 01:06:36 -0800 (PST)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 26FBA3A6973; Tue, 3 Nov 2009 01:06:34 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4E96C9CDBE; Tue, 3 Nov 2009 22:06:40 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp61vi-qjIn8; Tue, 3 Nov 2009 22:06:40 +1300 (NZDT)
Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EC2909CD93; Tue, 3 Nov 2009 22:06:39 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1N5FLb-0007Pe-J2; Tue, 03 Nov 2009 22:06:39 +1300
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1N5FLb-0003cr-Qk; Tue, 03 Nov 2009 22:06:39 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: mrex@sap.com
In-Reply-To: <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp>
Message-Id: <E1N5FLb-0003cr-Qk@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@wintermute01.cs.auckland.ac.nz>
Date: Tue, 03 Nov 2009 22:06:39 +1300
Cc: channel-binding@ietf.org, tls@ietf.org, sasl@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
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, 03 Nov 2009 09:06:37 -0000

Martin Rex <Martin.Rex@sap.com> writes:

>Microsoft's implementation (which could be the one referred to by
>Larry's implementation) has a silly design flaw in its TLS renogiation,
>and I'm not sure that the previous text is a way to fix it.
>
>It is possible to configure Microsoft IIS in a fashion so that it
>will first perform a TLS handshake with a server-only authentication,
>and after having received the HTTP request, it will re-negotiate and
>ask for a client certificate.

It's not necessarily a design flaw, AFAIK it's a performance optimisation to 
avoid the server having to maintain state/leave a connection open for an 
arbitrary amount of time while the user fumbles around with smart cards and 
certificates and whatnot.

Peter.

v2.23.0 | Report a Bug | By Email