[39453] in Kerberos

home help back first fref pref prev next nref lref last post

Why do "strict acceptor checking"?

daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Mon Oct 7 20:23:42 2024

Message-Id: <202410080023.4980NSGB010697@hedwig.cmf.nrl.navy.mil>
To: kerberos@mit.edu
MIME-Version: 1.0
Date: Mon, 07 Oct 2024 20:23:28 -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

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
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post