Re: Dovecot SASL GSSAPI regression with krb5 1.18

Unfortunately looking at cyrus-sasl I see it makes it required to hand
over a server name, but it does also check and fail if 
the server name has length 0.

Finally I though dovecot implemented their own SASL handling and did
not use cyrus, but I may be wrong.

Simo.

On Mon, 2020-03-30 at 13:16 +0000, Дилян Палаузов wrote:
> Hello,
> 
> 
> I also got had a GSSAPI SASL regression back in Fall 2019 (Krb 1.17) which was fixed by revering 
> https://github.com/cyrusimap/cyrus-sasl/commit/238380260fe623212c0f21d63e . As on git/cyrus-sasl several things were
> changed and reverted recenlty, try with the newest cyrus-SASL (I do not understand low-lever GSSAPI, the c-interface, or
> the protocol details, but I got it working for me and now I do not want to change anything).
> 
> Greetings
>   Dilyan	
> 
> On Mon, 2020-03-30 at 15:08 +0300, Mantas Mikulėnas wrote:
> > Hello,
> > 
> > I have a mostly normal Dovecot 2.3.10 configuration with SASL GSSAPI:
> > 
> > 	auth_mechanisms = anonymous plain gssapi
> > 	# auth_gssapi_hostname is unset
> > 	auth_krb5_keytab = /etc/dovecot/dovecot.keytab
> > 	auth_verbose = true
> > 
> > This used to work with MIT Kerberos version 1.17.1, and Dovecot would
> > automatically determine the system's FQDN and would find the principal
> > "imap/[email protected]" in its keytab.
> > 
> > However, the principal search broke after upgrading to 1.18 -- now, each
> > authentication attempt reports:
> > 
> > 	dovecot[1367034]: auth: gssapi(...): While acquiring service
> > credentials: Unspecified GSS failure.  Minor code may provide more
> > information
> > 	dovecot[1367034]: auth: gssapi(...): While acquiring service
> > credentials: No key table entry found matching imap/.nullroute.eu.org@
> > 
> > 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.
> > 
> > For now I can work around the issue in various ways: I could set
> > 'qualify_shortname = ""' in krb5.conf to revert to old 1.17 behavior, or
> > I could set 'auth_gssapi_hostname' in Dovecot to *actually* hold the
> > system hostname or even the correct FQDN.
> > 
> > However, I'd much rather have everything work "by default" -- it did
> > work in previous versions, after all -- and it seems to me that the
> > check in k5_expand_hostname() should avoid canonicalization when `host`
> > is an empty string, too.
> > 
> > So would this be considered a bug in krb5, or is it an expected change
> > in behavior? (In addition to what I assume is a bug in Dovecot itself)
> > 
> 
> _______________________________________________
> krbdev mailing list             [email protected]
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc





_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev