On 5/26/2020 5:09 PM, Ken Dreyer wrote: > 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".
As described in RFC4120 Section 1.3 https://tools.ietf.org/html/rfc4120#section-1.3 Kerberos implementations "MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names." That said MIT and Heimdal have canonicalized hostnames using insecure DNS since the beginning of time and changing the defaults will be sure to break authentication for some unknown number of sites. > I'm wondering what the original purpose of Kerberos' rdns feature was. > Why would a client want or need to do hostname canonicalization? There are two reasons that scream at me: 1. Before the introduction of Kerberos Referrals by Microsoft (and later standardized and adopted by MIT, Heimdal, ...), the clients required the PTR name in order to determine the true "domain" for host domain to realm mapping. With Kerberos referrals it is best if the Kerberos client sends the initial service ticket request to a KDC in the client principal's realm and allow the KDC to refer the client to the first cross-realm hop if required. There are still too many systems that have client-side domain_realm mapping data that would break if "rdns" was turned off. 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. In order to identify the name of the host that was contacted the DNS PTR record is used. Even with the existence of SRV records, too few application protocols use them. Even for services that are hosted on a system system, CNAME records are convenient to permit migration of services from an old machine to a new one. Again, disabling "rdns" by default will break an unknown number of application clients. > 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. I'm unaware of any OS distribution that ships with Kerberos that doesn't provide some default equivalent of "/etc/krb5.conf". Those distributions can of course add whatever default settings it wants with appropriate documentation. If a distribution ships default krb5.conf with "rdns = false", then an end user that replaces the default krb5.conf with their organization's krb5.conf will not be broken. If the hard coded default is changed, then installing the organization's krb5.conf might not work as intended. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
