RE: NTLM authentication, recent logs for Robert Collins

> -----Original Message-----
> From: Dr. Michael Weller [mailto:eowmob@exp-math.uni-essen.de]
> Sent: Friday, 27 October 2000 3:58 AM
> To: Chemolli Francesco (USI)
> Cc: squid-users@ircache.net
> Subject: RE: NTLM authentication, recent logs for Robert Collins
>
>
> On Thu, 26 Oct 2000, Chemolli Francesco (USI) wrote:
>
> > This is the problem. If I am forced to issue new challenges
> > over and over again, the cache will be completely ineffective.
>
> Sorry, this time *I* cannot follow because I've no idea who challenges
> whom in that NTLM business. I was under the impression that
>
> 1. IE opens connection (maybe also sends domaim\user, somehow
> fakeauth has
> to work), squid consults DC for a challenge (possibly already
> mentioning for which user) and passes it to the client.
>
> 2. IE takes user credentials, password and challenge and mangles them
> into a reply.
>
> 3. Squid passes that on to the DC which compares it with its own idea
> and accepts or denies it.
>
> This is how I would do it. Now, for Gods sake, I don't work for M$ so
> might be completely wrong.

Yup. You are :-] Well not completely. There is some info at
http://squid.sourceforge.net/ntlm/ that might help. here is a brief
overview though:

1. IE opens connection and sends a request.
2. Squid denies with 407 and offers NTLM as an authentication option, it
then *drops the connection*.
3. IE opens a new connection and sends an NTLM Negotiation struct as the
authentication parameter. This is the same as is normally sent on the
wire using MS networking.
        This struct DOES NOT have any user related details. It _MIGHT_
have the workstation name but that's about it. It is used to define the
protocol acceptable to the workstation.
4. Squid (with the helper) get a challenge from the DC with protocol
compatible with the Negotiate struct's options and sends it to IE on the
same connection.
5. IE encrypts the users hash with the challenge value and sends it to
squid as part of a new request (this is your mangling). This is the
Authenticate struct. This struct contains the Domain\Username.
6. squid sends the Authenticate Struct to the *same* helper, which then
logs onto the DC with the ecrypted password hash.
7. the helper tells squid the domain\username or ERR if it couldn't log
in.

Now fakeauth follows the protocol exactly, but instead of actual DC
generated challenges it uses a random or static (see the code)
challenge, and doesn't attempt to verify the password. It just extracts
the username and returns it to squid.

Caching? The caching works by observing the challenge-authenticate pairs
and remembering the user details when a succesful login occurs. Note
that the negotiate struct is useless for this :-[. The helper performs
as per normal for getting the challenge and sending to squid, but when
the authenticate request comes in, it doesn't try to login if there is a
matching entry in the cache.

Getting a new challenge on *every request* provides the best security
(given NTLM's capabilities :-]) but means that the
challenge-authenticate cache will never receive a cache hit. Using the
same challenge for a few minutes (perhaps even longer) at a time doesn't
increase the risk much but does increase performance significantly. (NB:
a replay attack is only possible while the old challenge is still being
issued.). Multiple use of the same challenge doesn't increase the
chances of a password compromise (AFAIK - any encryption guru's
listening in?) but will increase the chance of a replay attack. We could
tie the challenge-authenticate pairs in the cache to a single IP to
reduce that chance though (just thinking out loud). Because the cache
has to use challenge-authenticate pairs, sharing it between helpers
(which get different challenges from the DC) is of no use: no helper
will ever receive an authenticate request that would generate a cache
hit against the cache of another helper.

Anyway the in-squid cache works the same way but has a single cache
shared across all the helpers.

>
> So I thought, there is no problem at all to send IE the same challenge
> again and again and again and compare the result with
> ntlm-auths cache.
> The only reasons not to do that are imho that the user might
> have changed
> his password or that you don't want to a allow someone having
> snooped the
> communication with squid is able to login as that user.

Password cahnges don't matter - the resulting authenticate struct will
be a cache miss and get logged into the DC.

>
> Just for curiosity I'd like to know how NTLM really works.
> (any pointer?)
The sourceforge page, the SAMBA documentation (NTLM with http is the
same wire level stuff wrapped in base64). MS networking
http://www.microsoft.com probably has even less :-[
> Ok, your idea how NTLM really works ;-)
Above :-] Also the code is pretty well self-documenting in the
auth_rewrite cvs branch ... see acl.c
>
> Michael.
>
> --
>
> Michael Weller: eowmob@exp-math.uni-essen.de,
> eowmob@ms.exp-math.uni-essen.de,
> or even mat42b@spi.power.uni-essen.de. If you encounter an
> eowmob account on
> any machine in the net, it's very likely it's me.
>
>
> --
> To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
>
>

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html