Securing the keytabs of host-based principals

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Securing the keytabs of host-based principals

John Devitofranceschi
It is a common convention to have service principal names of the form service/fqdn@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.

jd


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Securing the keytabs of host-based principals

Simo Sorce-3
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@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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: 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@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


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Securing the keytabs of host-based principals

John Devitofranceschi

> On Jul 7, 2016, at 1:14 PM, Sarah Day <[hidden email]> 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




_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Securing the keytabs of host-based principals

Jeff D'Angelo
On July 8, 2016 7:48:31 AM, "John Devitofranceschi" <[hidden email]> wrote:

>> On Jul 7, 2016, at 1:14 PM, Sarah Day <[hidden email]> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev