Why do "strict acceptor checking"?

[Ken Hornstein]

>> I'm completely with you, but clearly plenty of application writers do not
>> agree with this sentiment!  So I'm wondering what I am missing.
>
>There *are* weird cases where the keytab needs to contain multiple keys
>for different principals, but you want to use only one of them for
>*accepting* connections.
>
>These days you can easily have separate keytabs for "client" vs
>"server" keys and programmatically specify which keytab you want via
>gss_acquire_cred_from(), but it hasn't always been like that. In the
>past in some cases your only option was to use a fixed specific file on
>the filesystem not even env vars...

I'm certainly kind of a grizzled old Kerberos user at this point and
I'm willing to believe that these weird corner cases exist, but part of
me wonders out loud how this attitude got proliferated to so many
applications.  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".

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.  Given
this is just to verify a Kerberos password, I am trying to come up with
any kind of scenario where the default behavior of krb5_verify_init_creds()
would cause a security problem.  If there IS no such scenario, I'm
going to try to submit a patch upstream to change this behavior.

--Ken