[39460] in Kerberos
Re: Why do "strict acceptor checking"?
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Tue Oct 8 20:34:57 2024
Message-Id: <202410090033.4990XeEZ023125@hedwig.cmf.nrl.navy.mil>
To: <kerberos@mit.edu>
In-Reply-To: <CALF+FNzt7ZL_e0o=xLSCjjRX7Vwi7-1EqTro2XhU+sg+0Tm6iQ@mail.gmail.com>
MIME-Version: 1.0
Date: Tue, 08 Oct 2024 20:33:39 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>> Also, I guess I find it personally frustating that a
>> practice that has caused me a ton of pain over a few decades is justified
>> by what I would charitably classify as "vague hand-waving".
>
>Me too. We've been recommending calling gss_accept_sec_context with
>GSS_C_NO_CREDENTIAL for a long time, and almost no one does that. it's
>very annoying.
It's comforting to know that at least I'm not the only old, grizzled Kerberos
user that feels that way.
>>But, fine, let's talk about a specific example. In the case of sudo,
>> the local hostname is used to build a "host" principal and passed in as
>> the server argument to krb5_verify_init_creds(). If you pass in NULL
>> instead to the server argument, krb5_verify_init_creds() will try
>> every "host" principal in the local keytab until one succeeds.
>
>
>AFAIK, that's a relatively recent feature in the grand scheme of things.
I am chuckling at the realization that "relatively recent" in Kerberos
now means "within the last 12 years" (looks like that code went in to
MIT Kerberos version 1.11). Now I feel even older. It seems like the
sudo Kerberos code has been unchanged for even longer. But even then,
the previous implementation of krb5_verify_init_creds() just did the
same thing that sudo did, so the code in sudo was at best redundant
even when it was written.
>well, the keytab could contain a copy of a key that is known to other
>services or to some user. even a principal intended to be used only as a
>client could be an issue, if an attacker knows the key and can print valid
>tickets.
I mean, sure, that's possible ... but that could be true for the host
key!
I know that newer versions of MIT Kerberos have the configuration file
entry "ignore_acceptor_hostname" (first appeared in 1.10) which does
resolve these issues, so it's not as big of a deal as it once was.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
