Securing the keytabs of host-based principals

[John Devitofranceschi]

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

[Simo Sorce]

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.

[Sarah Day]

Post by Simo Sorce

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

[John Devitofranceschi]

Post by Sarah Day

Post by Simo Sorce

Post by John Devitofranceschi
...
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

[Jeff D'Angelo]

Post by John Devitofranceschi

Post by Sarah Day

Post by Simo Sorce

Post by John Devitofranceschi
...
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/***@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?