[TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:)
On Tue, Nov 03, 2009 at 01:43:16PM +0100, Martin Rex wrote:
> Peter Gutmann wrote:
> > Martin Rex <Martin.Rex at 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.
> >
>
> 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.
After all some documents may have anonymous access, and some may
require user authentication. If the server requested user
authentication prior to knowing what document the client wants to
access, then it will force an ugly interaction on users that only want
to access documents that require no user authentication.
Nico
--
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.