W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Thu, 01 Mar 2012 01:54:08 +0100
Message-ID: <1330563248.24673.198.camel@home.hno.se>
To: Adrien de Croy <adrien@qbik.com>
Cc: ietf-http-wg@w3.org
tor 2012-03-01 klockan 13:07 +1300 skrev Adrien de Croy:

> I'm not 100% convinced.  Esp with auth.  Even disregarding NTLM, any 
> time you have a challenge and response, if the response comes to a 
> server over a different TCP connection, then I think a lot of 
> implementations will break.  Maybe therefore they are poorly designed.

We do have a bit of this problem with digest auth. If the servers do not
have syncronized nonce stores then digest performance degrades
considerably if the client switches server.

> Maybe if assuming 1 connection = 1 user is broken, it should be 
> explicitly warned about in the spec.

That assumption is utterly broken. Has always been since HTTP/1.0 added
keep-alive. Not even 100% safe to assume that for https:// these days.

> The alternative though is either 
> the server has to challenge every request, or the auth tokens submitted 
> by clients can be used without round-trips, or some other token needs to 
> be stored and looked up by the server in global (i.e. 
> non-connection-oriented) memory.  Basic fits there, but does Digest?  
> NTLM certainly doesn't of course.

basic auth is completely stateless on the server side, by nature of
transmitting plaintext login:password in each request.

digest auth requires servers to keep shared state of issued server
nonces to perform well. If not then each time the client lands at a
different server the server will issue a new nonce and the client
automatically retry the request until the client manages to hit the same
server twice in a row. keep-alive helps mitigating this a lot but not

NTLM is.. well NTLM. Does not fit into anything HTTP terms.

> > Are you talking of transparent intercepting proxies doing NTLM here? If
> > you do then please stop, that's just happens to work because the
> > security model of NTLM is plain broken broken allowing it to be abused
> > in mitm attacks in completely insecure manners. end of discussion.
> actually any sort of auth when you intercept you no longer know who the 
> target is.

You can't do any standard HTTP auth (basic or digest) in intercepting
mode and still have happy users.

> > Please let NTLM die a painful death.
> It's going to be a very long death.  It's just not going away.  I think 
> we will still see significant use of it in 10 years from now.

I hope not. Most should be switching to Kerberos via Negotiate now. And
you can't do the transparent intercepting proxy auth trick with

> I'm not even sure how to implement Digest on windows (I've only briefly 
> looked), but it looks quite difficult.

It's not very difficult. But you need to enable it in the domain
controller and reset the password on every account that needs to use
digest auth, and also enable it in IIS obviously.

In theory Windows should even be able to do automatic single sign on
with Digest auth just as it does for NTLM/Kerberos, but I do not think
that's implemented. Never investigated it in detail.

> Even Negotiate is still connection-oriented?

Yes, it's the same breakage HTTP wise as NTLM, but at least a reasonably
secure auth protocol as such if ignoring the mess it does to HTTP.

> So basically the answer remain: "use Digest".

Yes. Digest is the best we currently have in HTTP with some sanity

Received on Thursday, 1 March 2012 00:54:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC