[krbdev.mit.edu #8925] qualify_shortname default can be harmful in LAN setups

[Greg Hudson via RT]

Thu Jul 09 16:31:04 2020: Request 8925 was acted upon.
 Transaction: Ticket created by ghudson at mit.edu
       Queue: krb5
     Subject: qualify_shortname default can be harmful in LAN setups
       Owner: Nobody
  Requestors: ghudson at mit.edu
      Status: new
 Ticket <URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8925 >


https://bugzilla.redhat.com/show_bug.cgi?id=1852041 describes a regression when
Fedora changed the default of dns_canonicalize_hostname from "true" to
"fallback" in their 1.18 package. The user has a LAN setup using
single-component hostnames resolved via /etc/hosts (with no presence in the
DNS), and has set rdns=false. This setup worked with
dns_canonicalize_hostname=true because we don't qualify DNS-canonicalized
results, but with dns_canonicalize_hostname=fallback, the single-component
hostnames were qualified with the DNS search domain, which was some useless
domain supplied by the ISP during DHCP. This caused sshd to stop accepting
tickets.

This is an immediate issue for Red Hat, and a time bomb for upstream as we are
slated to change the dns_canonicalize_hostname default to "fallback" in 1.19.
Red Hat's response so far has been to change the qualify_shortname default to
"", but I think this change alone will cause problems in different setups. For
instance, https://mailman.mit.edu/pipermail/kerberos/2017-October/021816.html
describe's a user experiencing a kprop failure after setting
dns_canonicalize_hostname=false.

Whatever we do needs to account for the following use cases for
krb5_sname_to_principal():

* TGS request service names (the most prominent use case, and the one we paid
the most attention to when implementing dns_canonicalize_hostname=fallback).
For this use case qualify_shortname is mostly a user convenience, perhaps not a
necessity.

* Acceptor names for server applications. Probably the most common scenario is
when the application calls gethostname() and then imports
servicename+"@"+hostname (e.g. "host at small-gods" for sshd on my machine). Here
we want the local FQDN, but don't specifically know that, and we probably
received only the local hostname without domain. (Applications can get better
behavior by importing just the service name, which causes the hostname part to
be wildcarded, but I don't think many server application code bases have gotten
that message.)

* Non-GSS applications using a keytab to authenticate using a service principal
name as the client. Within the tree, this case includes kprop, kpropd when
acting as an iprop client, kadmin -k (with no -p option), and kinit -k (with no
principal name argument).

* ksu looks for a ticket to {sn2princ with "host" and null hostname} as an
alternative to a TGT, although this may currently be broken (see ticket 8619).

* KDB creation, where we create kadmin/hostname and kiprop/hostname principals.
There is a certain amount of slack here if this goes wrong; kadmin will fall
back to kadmin/admin, and the administrator can simply create the kiprop
principal for the master KDC when they create ones for the replicas (as they
had to do before ticket 7979).