Hi folks,
In public cloud environments or Kubernetes environments, PTR records
are difficult or impossible for administrators to set. We increasingly
have to tell users to set "rdns = fallback" or "rdns = false".
I'm wondering what the original purpose of Kerberos' rdns feature was.
Why would a client want or need to do hostname canonicalization?
I'm also wondering if we will ever be able to default MIT Kerberos'
rdns setting to "fallback" or "false" in a future version. IMHO this
would make it easier to deploy Kerberos applications in modern hosting environments.
On 5/26/20 5:09 PM, Ken Dreyer wrote:
In public cloud environments or Kubernetes environments, PTR records
are difficult or impossible for administrators to set. We increasingly
have to tell users to set "rdns = fallback" or "rdns = false".
Note that dns_canonicalize_hostname and rdns are separate settings. dns_canonicalize_hostname supports "fallback", but rdns only supports
true or false (and only takes effect when DNS canonicalization happens).
2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.
Again, disabling "rdns" by default will break an unknown number
of application clients.
On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman
<jaltman@secure-endpoints.com> wrote:
2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.
I'm curious about this. What makes it a poor idea?
It seems like a very convenient way to scale a service up and down dynamically quickly when you share a key among all instances.
Again, disabling "rdns" by default will break an unknown number
of application clients.
Sure. My point is that it breaks the other way for modern
architectures where PTR records will never be under an application developer's control. With Kubernetes a service can appear to clients
to move IPs very quickly. I'm not defending Kubernetes or anything
here, I'm wildly speculating that maybe breaking with the past is a
good idea as more applications and developers move in this direction.
On 5/26/2020 6:31 PM, Ken Dreyer wrote:
On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.
I'm curious about this. What makes it a poor idea?
It seems like a very convenient way to scale a service up and down dynamically quickly when you share a key among all instances.
Because if you hack into one of the hosts you now have the key for
all of the hosts. The holder of the key can forge tickets for any
user. Since the key isn't unique the entire distributed service has
to be shutdown to address the vulnerability. It is also much harder
to trace where the key was stolen from.
<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><Dr. Dameon Wagner, Unix Platform Services
<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
On 5/26/2020 6:31 PM, Ken Dreyer wrote:
On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.
I'm curious about this. What makes it a poor idea?
It seems like a very convenient way to scale a service up and down dynamically quickly when you share a key among all instances.
Because if you hack into one of the hosts you now have the key for all
of the hosts. The holder of the key can forge tickets for any user.
Since the key isn't unique the entire distributed service has to be
shutdown to address the vulnerability.
It is also much harder to trace where the key was stolen from.
On Tue, May 26, 2020 at 4:59 PM Jeffrey Altman
<jaltman@secure-endpoints.com> wrote:
On 5/26/2020 6:31 PM, Ken Dreyer wrote:
On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.
I'm curious about this. What makes it a poor idea?
It seems like a very convenient way to scale a service up and down dynamically quickly when you share a key among all instances.
Because if you hack into one of the hosts you now have the key for all
of the hosts. The holder of the key can forge tickets for any user.
This is true only if the administrator has enabled constrained
delegation for that key (eg. ok_to_auth_as_delegate) right? Is there
some other scenario I'm missing?
Since the key isn't unique the entire distributed service has to be shutdown to address the vulnerability.
Ok, that makes sense. I was thinking of a homogeneous environment
where each app server runs the exact same versions of code, so an
attacker entry through a vulnerability on one system means that all
systems almost certainly have the same vulnerability.
It is also much harder to trace where the key was stolen from.
Yeah, that's fair.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 292 |
Nodes: | 16 (2 / 14) |
Uptime: | 180:33:26 |
Calls: | 6,616 |
Calls today: | 3 |
Files: | 12,165 |
Messages: | 5,314,215 |