Dovecot SASL GSSAPI regression with krb5 1.18

[Greg Hudson]

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
https://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html#acceptor-names
.  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
is set.

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
hostname.

I intend to implement (2) and possibly (3) for 1.18.1.