[squid-users] Uncomplete Negotiate negotiation with Kerberos

[Amos Jeffries]

On 4/10/18 3:18 AM, Emmanuel Coirier wrote:
> Hi Amos !
> 
> First thank you for your patience and your answers.
> 
> I agree on the Negotiate/Kerberos workflow, and its security implication. But I have some
> last extra questioning about Kerberos.
> 
> It seems that we disagree on how Kerberos is supposed to work. See lower :
> 
>>> [Client sends a Kerberos Service Ticket to Squid]
>> The client sends such ticket to the proxy, the proxy sends it to the DC.
> 
> What do you consider as a DC ?
> 
> For me and until now, DC meant "Domain Controller", or "Distribution Center"
> (shorthand for KDC, Kerberos' Key Distribution Center): the trusted third party
> process that can be either MIT/Heimdal Kerberos or MS Active Directory.
> Am I right ?

That matches my understanding.

> 
>> The DC tells the proxy ("OK allow" or "no deny"). 
> 
> I didn't observed any communication between the negotiate_kerberos_auth helper
> and the DC. The only form of communication is reading requests on the standard input
> (from squid), reading files like a keytab (the service key) and the krb5.cfg
> Kerberos Realm configuration file, and writing responses on the standard output (to Squid).
> No connect() system call, no socket, no IPC to some DC. (And users where correctly
> authenticated, of course)
> 
> And it should be fine since the Kerberos protocol doesn't define any communication
> between a service and a DC.
> 

I can only hazard a guess that you were not looking at the right place
or time for the server<->DC communication.

Maybe something to do with your "-s GSS_C_NO_NAME" setting.


> Yesterday I tried a Debian Firefox with a Heimdal Kerberos server. This morning,
> I've tried to use a Firefox on Windows 10, with an account provided from a
> MS Windows Terminal Server 2008 running an Active Directory.
> 
> In either case Firefox was configured to pass trough a Squid instance.
> 
> This Squid instance was configured like this in the two scenarii :
> 
> 	auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s GSS_C_NO_NAME
> 	auth_param negotiate children 1
> 	auth_param negotiate keep_alive on
> 	
> 	acl foobar proxy_auth REQUIRED
> 	http_access allow foobar
> 
> The keytab was configured via the KRB5_KTNAME environment variable like this :
> 
> 	(in the /etc/default/squid file)
> 	export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
> 
> This keytab was generated using the Samba "net ads keytab" command for Active Directory,
> and with "kadmin ext" for Heimdal.
> 
>> If that were the case there would be no need for auth_param helpers to be 
>> configured. Squid passes tokens to the helper which handles all contact and 
>> validation with the DC.
> 
> My point is that the Kerberos helper doesn't need any contact with the DC. All it
> has to know is the service key stored in the keytab file. So each new TCP connection
> does not create a contact to the DC. It is what I have observed, but perhaps I'm
> missing something.

AFAIK the keytab file tells Squid helper what credentials *it* is to use
to login to the DC.


Consider, how is the Squid helper to know that a secret token delivered
by a random unknown client was actually generated by the DC and
validating that clients identity?


> 
> So I need to be sure of this detail because we need to reduce the authentication
> load of some Active Directories (which previously used NTLM), and Kerberos seems
> to be the solution. By telling me that the helper contacts the DC on each TCP
> connection with Kerberos, you puzzles me...
> 


I have not said that exactly. I have said that every connection needs to
be *authenticated*. There are optimizations built into kerberos that
*may* be used to minimize and/or speedup DC contact unless it is
specifically needed.


I also see another source of confusion there.


NTLM requires 2 HTTP messages to complete the handshake. Kerberos only
uses 1. This is achieved by removing the initial type-1 and type-2 token
exchange out of HTTP and into side-channels defined by the keytab's and
their related info (eg DNS).

By not causing HTTP requests to be repeated as much and waited for this
change alone produces a massive speed increase (seconds vs milliseconds
of latency) and load reduction (helpers not stuck waiting for next HTTP
message to arrive with more tokens for their incomplete auth process).

Notice that these are details at the HTTP level of things. Optimizations
at the level of things like contact with the DC are minuscule compared
to the above benefits.


Amos