Re: Authentication and TCP Connection State

On Sun, Oct 05, 2014 at 12:37:11PM -0400, Michael B Allen wrote:
> Could it be that the reason NTLM is still so popular is *because* it's stateful?

No, simply because users don't have to enter a password a second time,
that's the *only* argument that was given to me by people who break
their network with it. It exists, is convenient, and is safe *enough*
for what admins think their network looks like.

> And BTW I never said anything about NTLM. I don't know why everyone
> keeps mentioning it like it's THE problem.

Simply because the mechanism you described was as broken as NTLM and
we already know that it does not work.

> I'm not concerned with
> NTLM. I have a generic "Security Provider" API. So I will just
> implement whatever gets the job done.

So you want to start with something which every HTTP implementer knows
does not work and is insecure by design ?

> My concern is with what will *replace* NTLM?

Then better not keep the concepts that make people want to replace it.

> It's not obvious to me that "stateless authentication" is really
> possible in practice.
> 
> Digest only works because it carries the nonce with it and that is a
> pretty significiant constraint on the authentication mechanism itself.
> 
> Kerberos only works because it's not actually doing a complete
> authentication - only a "ticket" is submitted.
> 
> NTLM will break with HTTP 2.

And so what ? It already broke HTTP/1 and that didn't prevent admins
from deploying it. They'll simply do the same horrible hacks as they
did in v1 and it will work as in v1 : authenticate whoever is on the
other side of the connection and serialize all requests. And their
auth will continue to be broken by users installing proxies on their
PC or their VMs, so nothing will change.

> I don't know much about PKI / HTTP authentication methods but it
> sounds like it's effectively what Kerberos is doing.
> 
> So there is no stateless complete HTTP-only authentication mechanism
> in existence today that will work with HTTP 2.
> 
> I'm just saying - the whole "stateless authentication" thing is a
> little dubious. The Auth-ID will need to be routed back to the server
> that issued it.

I'm sorry if I don't know the details of all the auth schemes you're
describing, but I'm still not seeing the problem in defining a new one
if needed. There is a need for an auth scheme for proxies and for
applications. Anything involving a challenge is fine as long as the
client repeats the challenge in future requests. New challenges may
be emitted in responses and the client will have to break them before
the current one becomes too old (timestamp or request counter). That's
just *one* possibility, many are possible.

Willy

Received on Monday, 6 October 2014 06:08:18 UTC