Why do "strict acceptor checking"?

[Jeffrey Hutzelman]

On Tue, Oct 8, 2024, 12:06 Ken Hornstein via Kerberos <kerberos at mit.edu>
wrote:

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

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.

RFC4752 recommends that SASL implementations use a credential acquired for
GSS_C_NO_NAME, which is usually equivalent. It also recommends verifying,
after accepting a context, that the service principal used is of the
expected type. This mitigates the potential issues if keys for another
application are in the same keytab.



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.
So, software that validates passwords has a reasonably good excuse for
assuming that host/$hostname is a valid service principal to use for that
purpose and that its key will be readily available.

We have sudo configured to use PAM, and use Russ's pam_krb5, which handles
this (and has some features we use to support use of /root principals for
sudo).

Unfortunately, the Cyrus SASL library does not support non-strict mode.
That has unfortunate implications for LDAP, IMAP, and SMTP. We developed
and submitted a patch for that quite a number of years ago, but it doesn't
seem to have gone anywhere.



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

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.

So, maybe an option rather than a change to a different non-configurable
behavior. If I remember right, the structure of sudo makes adding a new
option a little annoying but not actually difficult.

-- Jeff

>