[19452] in Kerberos_V5_Development
Re: Securing the keytabs of host-based principals
daemon@ATHENA.MIT.EDU (Jeff D'Angelo)
Tue Jul 26 14:09:20 2016
Date: Tue, 26 Jul 2016 14:09:04 -0400 (EDT)
From: "Jeff D'Angelo" <jcd@psu.edu>
To: krbdev@mit.edu
Message-ID: <1572732691.3104125.1469556544966.JavaMail.zimbra@psu.edu>
In-Reply-To: <797C2AB1-C84F-49A9-9A0B-66B6BDC39B76@optonline.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On July 8, 2016 7:48:31 AM, "John Devitofranceschi" <jdvf@optonline.net> wrote:
>> On Jul 7, 2016, at 1:14 PM, Sarah Day <sarahday@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@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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
