Securing the keytabs of host-based principals

[Jeff D'Angelo]

On July 8, 2016 7:48:31 AM, "John Devitofranceschi" <jdvf at optonline.net> wrote:
>> On Jul 7, 2016, at 1:14 PM, Sarah Day <sarahday at mit.edu> wrote:
>> 
>> 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:
>>>> ...
>>>> 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
>> 
> 
> 
> That would be great. If you do get some results/patches I would be happy to
> check/try them out.
> 
> At the risk of having this spiral out of control beyond all reason, perhaps when
> operators set the ‘hostbased’ flag on a principal they have the option of also
> setting providing the ip address(es) of the host which can then be stored in
> the principal entry. This takes care of Simo’s concerns while at the same time
> being optional for installations where these concerns are not material.

Some kerberized services (ones we tend to run) have different service names/IPs than those for the host personality.  These include:

1) hosts with multiple interfaces

2) hosts behind a load balance

3) hosts with domain aliases (name in ticket is not [necessarily] what you find in the PTR)

So this check may need to be accompanied by a registration of alternate IPs with a given principal on the KDCs (a +1 for keeping the mapping associated there) to allow for these cases.

But thinking more generically, this sounds like a request for an IP-ACL guarding from whence a given principal may be AS-REQed.  Principals used to authenticate applications (acting like a user in Kerberos terms; i.e. those that don't follow the service/f.q.d.n at realm name format) may also benefit by such a lockdown.  Might this also allow for CIDR notation in case a set of machines on the same network share the service principal?

-- 
Jeff