Re: Authentication and TCP Connection State

On Sun, Oct 5, 2014 at 2:18 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Sat, Oct 04, 2014 at 02:03:11PM -0400, Michael B Allen wrote:
>> 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.

My point is that it's not obvious to me that there is a good truly
stateless auth scheme at all - including the Auth-ID method.
Presumably the Auth-ID header must be routed back to the server
instance that issued it which means it's not truely stateless. At
least it seems to me proxies are going to have to use hard server
stickyness when processing Auth-ID requests / responses.

Could it be that the reason NTLM is still so popular is *because* it's stateful?

And as a result it blows the doors off of Kerberos which is the only
other enterprise SSO mech?

Kerbeors is fickle as hell. Clients have to have access to KDCs. It's
bound very tightly to DNS. Time has to be exactly correct on all 3
machines. Tickets become stale. Tickets are submitted with every
single request and they can be HUGE.

And BTW I never said anything about NTLM. I don't know why everyone
keeps mentioning it like it's THE problem. I'm not concerned with
NTLM. I have a generic "Security Provider" API. So I will just
implement whatever gets the job done. I pretty much have Kerberos 5
provider but I don't feel the pressure to roll it out because right
now, performance wise, NTLM is kickn' ass. And AFAIK it is secure if
NTLMv2 is used and there's no hijacked proxy in between.

My concern is with what will *replace* NTLM?

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.

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.

Mike

Received on Sunday, 5 October 2014 16:37:38 UTC