[squid-dev] [PATCH] add support for using an existing kerberos cache instead of a keytab

[aymericvincent at free.fr]

Hi,

"Amos Jeffries" <squid3 at treenet.co.nz> writes:

> This patch appears to make Squid ignore loading keytabs entirely and
> just allow random credentials from unspecified location(s) to be used.

That's correct and that's the whole point of the diff. ("unspecified location"... to squid)

> In the absence of a location from which to load the credentials where
> does GSSAPI load the credentials from?

When a user is logged in and authenticated to a kdc, a credentials cache is kept around (in practice in a file belonging to the user in /tmp on Unix) and used whenever kerberos authentication is required by a client. That's what you see when you type "klist" for example. Given that one of the interesting features of kerberos is single sign on, I would be surprised that the behaviour is not very similar on other OSes/implementations.

> Is the users generic cache backed by a keytab somewhere in the local
> account? and why can't we just load that?

I'm not familiar enough with kerberos to be authoritative, but I'm quite sure it's not the case : the ticket granting ticket is provided in exchange for the user's password, not thanks to a user-specific keytab AFAIK.

> Overall this seems to me to be making Squid pick a random user account
> from the machine and sending a lot of traffic through some peer
> pretending to be that user instead of a proxy. That is bad security, and
> Kerberos is supposed to be the most secure authentication possible. So I
> am not happy with this (yet).

I'm fine with your opinion, but you should replace "a random user account" by "the account which started squid".

> NP: don't worry about small diff. We are in feature freeze for Squid-4
> beta cycle. Since this is a small UI change it will be held anyway until
> Squid-5 branching, which is likely to be a month or two away.

OK, I'll keep that in mind. So we can devise a better way of specifying the option. Moreover, I also realised that keeping the ability to specify a principal name in the NOKEYTAB case is pointless (and will be ignored by the current code) so if others prefer to keep a similar syntax (I'm not fond of it either), it could be login=NEGOTIATE:NOKEYTAB directly and not login=NEGOTIATE::NOKEYTAB.

Best regards,
 Aymeric