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

[Martin Rex <[e-mail]>]

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