Securing the keytabs of host-based principals

[John Devitofranceschi]

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

jd



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2393 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20160708/84fcb8ea/attachment.bin