[20071] in Kerberos_V5_Development
Re: Dovecot SASL GSSAPI regression with krb5 1.18
daemon@ATHENA.MIT.EDU (Simo Sorce)
Mon Mar 30 11:12:36 2020
Message-ID: <9015c6a44fa84e89df4c7c64ffe94cc89353eafb.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?=
=?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?=
<dilyan.palauzov@aegee.org>,
krbdev@mit.edu
Date: Mon, 30 Mar 2020 11:12:14 -0400
In-Reply-To: <310fa6435721f38aaf5f830432a785486fc25ed9.camel@aegee.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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/wolke.nullroute.eu.org@NULLROUTE.EU.ORG" 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 krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
