Dovecot SASL GSSAPI regression with krb5 1.18
ghudson at mit.edu
Mon Mar 30 13:29:33 EDT 2020
On 3/30/20 8:08 AM, Mantas Mikulėnas wrote:
> I have tracked this down to commit 99635376 "Qualify short hostnames
> when not using DNS". I'm still not entirely sure what is happening here,
> but it seems to me that Dovecot tries to pass an empty hostname to
> GSSAPI -- despite its docs saying that auth_gssapi_hostname should
> default to gethostname() -- and Krb5 canonicalizes that empty string
> resulting in a garbage domain name.
Thanks for the preliminary investigation.
Dovecot imports the GSS name "imap@" for the acceptor cred, unless a
gssapi hostname is set. The hostname part of a service-based GSSAPI
acceptor name can be omitted, in which case we allow any key in the
keytab matching the service name, as described in
. But this is normally done by omitting the "@" per RFC 2743 section 4.1.
With a "@" present in the GSS name, we currently proceed (in both 1.17
and 1.18) as if there is an empty hostname. In 1.17, we attempt DNS
canonicalization on the empty name (if allowed by configuration) and
typically fail, after which we build the acceptor principal name
"imap/@REALM". By happenstance, this name has the same wildcard
hostname behavior in krb5_rd_req() as we would use if the hostname were
properly omitted, so the operation succeeds. In 1.18 we also attempt
DNS canonicalization, but after that fails, shortname qualification
kicks in and we build the acceptor principal "imap/.stuff at REALM".
I think any one of the following changes would suffice:
1. Dovecot should omit the "@" in the GSS name when no gssapi hostname
2. Our GSS layer should treat "imap@" like it treats "imap".
3. krb5_sname_to_principal() could treat an empty hostname like it
treats a null hostname, or could refuse to shortname-qualify an empty
I intend to implement (2) and possibly (3) for 1.18.1.
More information about the krbdev