[39456] in Kerberos

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

Re: Why do "strict acceptor checking"?

daemon@ATHENA.MIT.EDU (Simo Sorce)
Tue Oct 8 10:05:42 2024

Message-ID: <f37de56c4c7c3754fba76bca6c911a255a435c44.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>,
        "Roland C. Dowdeswell"
 <elric@imrryr.org>
Cc: kerberos@mit.edu
Date: Tue, 08 Oct 2024 10:04:12 -0400
In-Reply-To: <202410081342.498DgtxB017212@hedwig.cmf.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

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


________________________________________________
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