Re: Authentication and TCP Connection State

On Sat, Oct 04, 2014 at 02:03:11PM -0400, Michael B Allen wrote:
> On Sat, Oct 4, 2014 at 5:02 AM, Julian Reschke
> <julian.reschke@greenbytes.de> wrote:
> > Hm, no. HTTP authentication is stateless, the server doesn't need to
> > associate it with a life connection. Unless you're talking about the weirdo
> > NTLM, which never should have been approved as HTTP authentication scheme.
> 
> What's more "weirdo":
> 
> a) Use IPsec or TLS to get a secure TCP connection and then HTTP
> clients and servers just have to authenticate the TCP connection (and
> they can skip TLS if they're satisifed that clients are not being
> directed through a compromised proxy).
> 
> OR
> 
> b) Require HTTP clients and servers build security on top of HTTP
> which involves peforming authentication using the Auth-ID mechanism in
> draft-montenegro-httpbis-multilegged-auth and then separately either
> compute and submit a crypto token for every single request or get a
> secure TCP connection so that you can safely store auth state in the
> session.
> 
> Outside of corporate IntrAnets people are not going to do option b.

And inside intranets, people are already abusing option a. It's only
clueless admins which continue to trust it. In every large place I have
been in, there were rogue proxies installed on end-users PCs to offer
free internet connectivity to other users, and the user with the highest
access class would authenticate once, then the proxy would pass everyone
in the same connection. What a great design! HTTP requests are independant
over a single TCP connection, NTLM is just a design mistake which happens
to work well enough to exist. But it's still a mistake given that it
authenticates something irrelevant to HTTP : the underlying TCP connection,
so it's neither reliable nor secure.

> So
> everyone on the Internet is just going to continue to construct their
> own auth scheme on top of HTTPS and process plaintext passwords on the
> server. That is bad.

Why ? *If* we stop thinking like NTLM, *then* we can design something
working to replace it. If there are few alternatives, it's likely because
of clueless admins which continue to deploy NTLM.

> And now with multiplexing the client could submit multiple requests
> only to find authentication is required which could lead to some at
> least awkward if not highly inefficient scenarios.

Cookie-based auth works well for servers, it's just not suited to proxies,
which have to perform a redirect dance. We could have an auth scheme
explicitly designed for proxies.

> Note that Kerberos doesn't actually do authentication entirely over
> HTTP. The client authenticates separately with a 3rd server using an
> entirely different protocol and then it only submits a service ticket.
> It is only because of this that Kerberos does not require Keep-Alive.

Then what's the problem ?

> And the "nonce" in Digest authentication serves the same function as
> the Auth-ID in multilegged auth so Digest is really multilegged.
> 
> So I suppose my point is that since HTTP is stateless, it cannot
> support any kind of real authentication at all without the Auth-ID
> mechanism.

I don't see your point. Provided that the client is able to show the
challenge that was submitted to it and the result, I don't see why
it cannot work.

> Maybe everyone understands this already and I'm just now realizing
> that HTTP has totally punted authentication.
> 
> I suppose it could be thought of as a positive thing because it will
> create a lot of work and jobs.

What's certain is that if pipelining and multiplexing had been in use
earlier, NTLM would probably never have been designed this way due to
incompatibilities, and a correct auth scheme would have been designed
instead, not causing all the mess we all know.

Willy

Received on Sunday, 5 October 2014 06:18:32 UTC