Re: Authentication and TCP Connection State

On Mon, Oct 6, 2014 at 2:44 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 6/10/2014 7:07 p.m., Willy Tarreau wrote:
>> 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.
>
>
> FYI, I have seen one other re-occuring "reason".
>
> That NTLM can be used even by machines not attached to the domain.

Right.

A stand-alone complete authentication [1] is required if the client
doesn't have access to or knowledge of an authentication server like a
KDC in a Kerberos domain.

Note that this is not specific to NTLM. It is a generic concept that
is at the center of what I keep trying to say and I will keep saying
it until someone proves me wrong:

Any "challenge" will have to be directed back to the server that generated it.

This is probably the problem Rob mentioned about Digest being
replayable. Specifically, if the "nonce" in Digest auth is sent to a
different server from the one it was generated (such as because you're
load balancing requests between two servers), it could not prove that
the nonce wasn't used before. So it would just have to trust the nonce
the client supplied. That is the critical flaw in Digest auth.

I can see you guys really want to just direct requests like you're
routing packets around on an IP network. Sadly I don't think that day
will ever come. It is simply not possible to perform authentication
unless there is some state somewhere in which case all auth requests
must be routed back to the location of that state. So a proxy would
have to create an index of Auth-IDs and corresponding TCP connections
and route those requests to the corresponding TCP connection.

The alternative is to just say "HTTP does not support stand-alone
complete authentication". And that is pretty much where you claim your
at right now. Clients would have to use a 3rd party service using a
completely different protocol (that could not be based on HTTP and
thus would have to run on a different port and probably on a different
machine entirely). And that has all the problems Kerberos has of just
getting the client to find that service.

And so Internet users will still be processing plaintext passwords (or
password-equivalent hash) on the server and hanging auth state on the
session.

If HTTP had a built-in stand-alone complete authentication mechanism
that browsers could build a little secure form element around,
security breaches would drop like a led zeppelin (queue "Heartbreaker"
... ♩♩♩♩).

Mike

[1] An authentication that occurs entirely between only the client and
the server and that proves the user knows the shared secret and not
just a product of a previous authentication step.

Received on Monday, 6 October 2014 16:22:38 UTC