id,summary,reporter,owner,description,type,status,priority,milestone,component,resolution,keywords,cc,fix_version,see_also 1384,Disable DNS canonicalization for Kerberos,geofft,,"Use of Kerberos in the Athena environment currently involves using DNS for canonicalization, an insecure practice called out in RFC 4120 (the krb5 RFC): > one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, accepting the primary name as the party that one intends to contact, since an attacker can modify the mapping and impersonate the party. Athena basically uses Kerberos DNS canonicalization (forward and reverse lookup) as a user experience measure: users expect to be able to do things like `ssh athena.dialup`, `remctl xvm-remote help`, etc. without providing the long name. In particular, the `.mit.edu` suffix needs to be appended, and names like `linux.mit.edu` need to be expanded to canonical names like `linerva.mit.edu` (or, in the case of `athena.dialup.mit.edu`, one of several possible canonical names), before the name becomes something suitable to turn into the name portion of a Kerberos service key. But since DNS is completely insecure, an attacker can spoof the DNS response and canonicalize, say, `linux` to `some-random-server.mit.edu`, which they might legitimately own a keytab for, and the login would succeed. Deployment of DNSSEC would basically solve this issue, but as far as I'm aware there are no real plans to deploy DNSSEC at MIT. Turning off canonicalization is mostly straightforward, but doing so right now would break the UX mentioned earlier. So this ticket is primarily about software changes needed to make the UX work as well, without trusting DNS. Here are a couple of approaches. For merely fully-qualifying a domain name: * Active Directory solves this in a straightforward manner by issuing a domain-joined server a `host/machine@EXAMPLE.COM` key as well as a `host/machine.example.com@MACHINE.EXAMPLE.COM` one. We could do that: I don't see a security issue in creating `host/linerva@ATHENA.MIT.EDU` etc. keytabs, but maybe I'm not thinking hard enough. This requires no client changes. * We can also have the Kerberos libraries process `/etc/resolv.conf`, which would let them know how unqualified names should be fully-qualified. For resolving aliases: * We could just have servers carry keys for all their aliases (that people log in through). This would mean that athena.dialup's keytab would need a key for each `athena.dialup` alias (`x.dialup`, etc.) and each servers' own aliases (`ant`, `cvp`, etc.), which would be slightly awkward but certainly manageable. * The KDC has support for [http://k5wiki.kerberos.org/wiki/Projects/Aliases aliases], which seem to be ways for the server and KDC to agree that a certain name is an alias for an existing principal, and that the same key should be used. I'm not sure what needs to be done on the server side to configure aliases on a key in a keytab. * There's a [http://k5wiki.kerberos.org/wiki/Projects/Trust_KDC-local_name_resolution project on the krb5 wiki] talking about doing DNS resolution on the KDC, which should be significantly more trustworthy than doing it on the client. It looks like the implementation is that you'll ask the TGS for a service ticket for `host/linux`, and get a service ticket for `host/linerva.mit.edu` back. * You could also imagine combining the above two approaches: keeping aliases in the KDC database (and not trusting DNS anywhere), but returning the canonical name to the client. I think that, in addition to `rdns = false` in `krb5.conf`, this also requires `GSSAPITrustDns No` in `ssh_config`. Also note that the Kerberos libraries in Ubuntu have a bug (fixed in in krb5 1.10.2) that seems to effectively make `rdns = true` unconditionally set, so we'll need to get a security update through for that. In terms of deployment strategy, it'd be nice to find a solution that doesn't break existing clients or servers, but allows clients to opt in to be more secure without breaking their functionality. I think all of the above solutions allow unmodified clients, that continue to canonicalize hostnames in DNS, to still work. Some of the above solutions don't involve coordinating with server maintainers; some involve adding more keys to the keytab, or configuring aliases server-side. (Like #529, this is not entirely a Debathena bug, but this is the most convenient place to keep track of it, especially as it interacts with our security policy re `GSSAPIDelegateCredentials`, `GSSAPIKeyExchange`, and friends.)",defect,new,normal,The Distant Future,--,,,,,