Re: [TLS] Comments on TLS identity protection

Martin Rex <martin.rex@sap.com> Tue, 19 December 2006 23:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwo3I-0004KL-Dd; Tue, 19 Dec 2006 18:07:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwo3I-0004KA-1m for tls@ietf.org; Tue, 19 Dec 2006 18:07:16 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwo3F-0007FL-M4 for tls@ietf.org; Tue, 19 Dec 2006 18:07:16 -0500
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA23490; Wed, 20 Dec 2006 00:07:04 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200612192307.AAA25601@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Comments on TLS identity protection
To: ekr@networkresonance.com
Date: Wed, 20 Dec 2006 00:07:03 +0100
In-Reply-To: <868xh3pktk.fsf@raman.networkresonance.com> from "Eric Rescorla" at Dec 19, 6 02:44:39 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Eric Rescorla wrote:
> 
> "Kyle Hamilton" <aerowolf@gmail.com> writes:
> > On every renegotiation, does the server have to reauthenticate itself
> > (present its certificate again)?  Or can the credential on the client
> > side be cached to avoid that duplication?
> 
> I don't think I understand the question.
> 
> 1. You do a regular handshake with no client auth.
>
> 2. The server initiates a rehandshake with client auth. This has
>    to be a full handshake with a new key exchange.
> 
> Any future resumptions of the second session can be done out
> of cache.

When the server-requested renegotiation is application triggered,
as in the Microsoft IIS case, then the server better caches the
result along with the SSL session.

Microsoft IIS has a silly (performance-wasting) bug, where a client that
does either not have a client cert or does not show one (and requiring
the application to perform application level client authentication)
is continously forced through the renegotiation when the client
tries to resume the session from the session cache on a new connection.

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls