Securing the keytabs of host-based principals

[Sarah Day]

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