RE: NTLM authentication

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Tuesday, 1 August 2000 10:47 AM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org; Chemolli Francesco (USI)
> Subject: Re: NTLM authentication
>
>
> Robert Collins wrote:
> >
> > I thought I'd send out a general update on this (for anyone
> who cares :-])
> > so that the squid gurus out there can tell us if we've made
> any horrible
> > mistakes.
>
> You seem to be farily on track.

Cool
 
> > Thanks for your comments Henrik (I presume your back on deck now?)
>
> I am back from my vacation yes, and have catched up on most
> interesting
> email (directly addressed + squid-dev). I won't be able to catch up on
> squid-users or other heavy traffic lists for some time however...
>
> > So with the challenge generated by the NT domain
> controller, squid _could_
> > cache the challenge and the expected response for a 'user',
> but that will
> > cause any user that uses a machine before it times out to get a
> > username/password box, which NTLM is meant to avoid. On the
> up side no
> > external authentication is needed on the persistent
> connection once done.
>
> The challenge should of course be tied to the specific
> WORKSTATION,USER
> touple, not only machine.

The challenge is tied to a connection in the MS protocol, we only find
the username on the response, so any caching we do has to be tied to a
machine(It's the only info we can use), and we find the username on the
client response. As such we are one step behind the game, and any
problems (users moving machines, multi-user machines) will surface after
the client has tried authenticating.
 
> Remember the protocol:
>
> 1. Proxy advertises it's capabilities
> 2. The client sends it's identification information
> 3. The server (with help from domain controller) responds with a
> password challenge
> 4. The client responds with a password response
It's not actually a password response. That's why we have dificulty
caching. It's the result of DES encrypting the challenge with the hash
of the password.
> 5. The server verifies (via the domain controller) the password
> response.

> As far as I can tell this can be replayed just fine without any of the
> issues you describpbe. There is however an issue when a user
> changes his
> password.

As above the issue is: who do we replay it to? (must be machine as that
is the only info we have when we present the challenge)
What if that machine has multiple users (a la metaframe or a big
X-client)? (We're stuffed - every connection will be for a different
user and a cached challenge is only valid for a single user).

For the moment I'm going to leave the possibilities of caching to the
side. I will put together a update for the NTLM notes page though.
 
> > Henrik, the alterations in the NTLM branch I was talking
> about, remove the
> > pump module and change the request flow. We've done our
> coding now though
> > so, I hope the original NTLM branch was ok!
>
> Ok, then we are speaking about the same think. This change is
> a cleanup
> of how Squid handles request with request entities. The old design is
> farily broken on several ways, and was basically impossible
> to tweak to
> do it correctly in a intelligble way. Some of the old-timers might
> remember my sometimes quite lengthy objections to the "old" (current)
> request processing loop and the pump module..

That's good then :-]
 
> > We've leaving the authentication type differentiated
> proxy_auth code for
> > later, once the core is bedded down.
>
> Ok.
>
> > That's about it really.. look for working NTLM authentication soon!
>
> Great!
>
> > Oh, regarding the NTLM and Basic header order, I've lookup
> it up - RFC
> > 2617 - and MS is breaking spec (again).
>
> Funny isn't it ;-)
>
> > I'm going to post something to them sometime soon and see
> waht they say.
>
> I think they are abandoning the NTLM authentication sheme in 2000 and
> replacing it with something kerberos based. Haven't actually
> bothered to
> investigate the details thought, but they do know that NTLM HTTP
> authentication is fundamentally flawed.

There is no _option_ in IIS 5 in windows 2000 for kerberos, but I
haven't done a header trace yet. I hope they do release something soon.
 
> /Henrik
>

Rob
Received on Mon Jul 31 2000 - 19:13:10 MDT