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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.