[SQU] Fw: NTLM authentication, recent logs for Robert Collins

RE: NTLM authentication, recent logs for Robert CollinsSorry if this is a
repeat message - we had a switch meltdown today and the mailserver got
confused... I'm resending to ensure delivery
----- Original Message -----
From: Robert Collins
To: Dr. Michael Weller ; Chemolli Francesco (USI)
Cc: squid-users@ircache.net
Sent: Friday, October 27, 2000 10:58 AM
Subject: 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