Securing the keytabs of host-based principals

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York