[19448] in Kerberos_V5_Development
Re: Securing the keytabs of host-based principals
daemon@ATHENA.MIT.EDU (Sarah Day)
Thu Jul 7 13:15:24 2016
From: Sarah Day <sarahday@mit.edu>
To: Simo Sorce <simo@redhat.com>, John Devitofranceschi <jdvf@optonline.net>
Date: Thu, 7 Jul 2016 13:14:55 -0400
Message-ID: <2124558.NBCL94HfaQ@perfluence.mit.edu>
In-Reply-To: <1467810208.3121.139.camel@redhat.com>
MIME-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Wednesday, July 6, 2016 9:03:28 AM EDT Simo Sorce wrote:
> On Wed, 2016-07-06 at 07:25 -0400, John Devitofranceschi wrote:
> > It is a common convention to have service principal names of the form
> > service/fqdn@REALM.
> >
> > It is also common for these SPNs to have keytab files on the servers that
> > run the services they’re associated with.
> >
> > Sometimes it is necessary for these keytabs to be used for authentication.
> >
> > I was thinking that is would be a good thing to be able to verify that an
> > authentication request for a principal like service/fqdn was actually
> > coming from the fqdn in the principal name. Certainly this check can be
> > done by looking at the ISSUE KDC log message since both the requesting
> > principal name and the requesting ip address are in the log. But by then
> > it’s too late.
> >
> > Would it be possible/desirable/sensible to have a new attribute (or flag)
> > that designates a principal to be a host-based principal that follows
> > standard conventions? When the KDC sees a ticket request from a principal
> > with this attribute, an additional check will verify that the source
> > address of the request maps to the fqdn in the principal.
> >
> > Additionally a kdc.conf variable could be defined that controls the
> > behavior of this check when it fails: warn (the default) or deny.
> >
> > This would allow operators to (at least) easily detect if any keytabs are
> > being used on hosts for which they were not intended.
> Unless you plan to keep a hard copy of Name-IP pairs on the KDC you
> would need DNSSEC to make this check useful, otherwise DNS spoofing can
> be easily used to fool the check.
> Also adding a DNS request before returning an AS Response will increase
> the latency increase the chance clients will re-send the request or move
> to another KDC and discard the request. Many clients have an aggressive
> retry strategy that waits only 1 second for the first reply and then
> slowly backs down.
>
> Simo.
I still see value in something like this being implemented. It's still another
layer of security that would have to be bypassed by an attacker. A keytab
could be accidently leaked in many ways, and a DNS spoof attack isn't always
incredibly easy.
Including a warning log message should be relatively simple, but I do see
multiple issues presenting themselves if it should actually fail if the
hostname doesn't resolve correctly. I can add taking a look at how it performs
to my list if you would like.
--
Sarah Day
Identity & Access Management
MIT | IS&T | Platform & Systems Integration
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
