Why do "strict acceptor checking"?

[Ken Hornstein]

>>  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