Twice this week I have helped other sites deal with issues related to
"strict acceptor checking" (the programs in question were sshd and
sudo). Both of these programs explicitly have code that constructs a
service name based on the value of gethostname() and thus will only
accept a service ticket for that name regardless of what's actually
in the keytab, and this fails in a number of complicated multihomed
networking situations (sudo does this for the service principal passed
to krb5_verify_init_creds()). At least in the case of sshd there is an explicit knob to turn this off.

However, this has made me wonder: why do this at all? What is the
possible security gain here? It's not the default in the code; you have
to explicitly write code to enable this behavior. But I can't really
think of a case where NOT having strict acceptor checking is a security problem; I could maybe squint and envision some kind of weird hosted
server setup where it might matter, but I'm not sure that is ever done
in the real world. I will admit it is entirely possible I am missing something; if I am, I'd sure like to understand what I am missing.

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

On Mon, Oct 07, 2024 at 08:23:28PM -0400, Ken Hornstein via Kerberos wrote:

However, this has made me wonder: why do this at all? What is the
possible security gain here? It's not the default in the code; you have
to explicitly write code to enable this behavior. But I can't really
think of a case where NOT having strict acceptor checking is a security problem; I could maybe squint and envision some kind of weird hosted
server setup where it might matter, but I'm not sure that is ever done
in the real world. I will admit it is entirely possible I am missing something; if I am, I'd sure like to understand what I am missing.

I have always operated under the theory that one should make sure that
the keytab accepts exactly the set of principals that are required.
This is something that is under the ultimate control of the system administrator. When an application turns on strict acceptor checking,
they remove this configrability from the system administrator which I
think makes the system much less flexible.

--
Roland C. Dowdeswell https://Imrryr.ORG/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

However, this has made me wonder: why do this at all? What is the
possible security gain here? It's not the default in the code; you have
to explicitly write code to enable this behavior. But I can't really
think of a case where NOT having strict acceptor checking is a security
problem; I could maybe squint and envision some kind of weird hosted
server setup where it might matter, but I'm not sure that is ever done
in the real world. I will admit it is entirely possible I am missing
something; if I am, I'd sure like to understand what I am missing.

I have always operated under the theory that one should make sure that
the keytab accepts exactly the set of principals that are required.
This is something that is under the ultimate control of the system >administrator. When an application turns on strict acceptor checking,
they remove this configrability from the system administrator which I
think makes the system much less flexible.

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.

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected] (Roland C. Dowdeswell)
Copy: [email protected]

On Tue, 2024-10-08 at 09:42 -0400, Ken Hornstein via Kerberos wrote:

However, this has made me wonder: why do this at all? What is the possible security gain here? It's not the default in the code; you have to explicitly write code to enable this behavior. But I can't really think of a case where NOT having strict acceptor checking is a security problem; I could maybe squint and envision some kind of weird hosted server setup where it might matter, but I'm not sure that is ever done
in the real world. I will admit it is entirely possible I am missing something; if I am, I'd sure like to understand what I am missing.

I have always operated under the theory that one should make sure that
the keytab accepts exactly the set of principals that are required.
This is something that is under the ultimate control of the system administrator. When an application turns on strict acceptor checking,
they remove this configrability from the system administrator which I
think makes the system much less flexible.

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

Granted I think 99% of the time it is the other way around, so it would
be nice if we could rewind to the past and make strict acceptor default
to false, but there have been "reasons" for this behavior, and changing
the default now would risk opening up unsuspecting admins to unexpected failures.

Simo.

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected] (Simo Sorce)
Copy: [email protected] (Jonathan Calmels via Kerberos)

On Tue, Oct 8, 2024, 12:06 Ken Hornstein via Kerberos <[email protected]>
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



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ken Hornstein via Kerberos <[email protected]> writes:

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.

You definitely are not. I don't know how many times I've tried to explain
this to people.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)