RE: Straw-man charter for http-bis -- call for errata/clarifications to 2617

tor 2007-05-31 klockan 15:39 -0700 skrev Paul Leach:

> [Paul Leach] Since I think people safely use it today, I don't think any
> additions are needed. At least when no proxy server is involved -- I
> forget the trick used to make sure that proxies preserve connection
> semantics before relying on Kerb/SPNEGO when using a proxy. It may be
> that they won't be used if a proxy is involved.


The no-proxy case is workable, as both endpoints then know they need to
go outside the HTTP specs and can bend the protocol pretty much as they
desire. But it doesn't make it fit better into the HTTP specs.

The proxy case is quite ugly. Doable, but requires a bit crossed fingers
and guesswork on how the clients and servers behave. We just went
through this with the Squid proxy about a year ago which was a quite
interesting experience..

> That was what my second suggestion from the message, part
> of which you quoted above, was about. I guess it wasn't clear enough. 

Good. So lets keep that in mind when talking about RFC2617bis.

If Microsoft is willing to rework their authentication schemes so that a
future revision fits the HTTP message model, perhaps by using virtual
sessions instead of transport connections to identify the authentication
session then the need for extending HTTP to officially supporting
transport level authentication disappears.

> It would be a better approach, but it would still be pretty helpful to
> tell people how to interop with the existing approach. 

The existing RFC is perfectly fine for that purpose.

The question here is if the requirements of RFC4559 "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Windows" should be on
the table while revising the HTTP specifications or not. I say firmly
not.

But I am perfectly fine with RFC2617bis including a generic framework
for strong session identification with replay protection, which can then
be utilized to implement NTLM and other session oriented authentication
schemes without requiring a closely tied transport<->session relation as
is the case today.

Regards
Henrik