Dovecot SASL GSSAPI regression with krb5 1.18

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Dovecot SASL GSSAPI regression with krb5 1.18

Mantas M.-2
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/[hidden email]" 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)

--
Mantas Mikulėnas

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot SASL GSSAPI regression with krb5 1.18

Simo Sorce-3
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/[hidden email]" 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)

Sounds like Dovecot is passing an actual empty string instead of
GSS_C_NO_NAME, that's what you should fix, if you have no name you
shouldn't pass an empty string, you should pass a NULL gss_name_t

I think this is an unexpected use of the interface. It was never really
expected that users would pass an empty string for a name ...

I think it could be fixed for backwards compatibility, but you should
also open a bug in Dovecot and stop from using empty string in
gss_import_name()...

Simo.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc





_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot SASL GSSAPI regression with krb5 1.18

Дилян Палаузов
In reply to this post by Mantas M.-2
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/[hidden email]" 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot SASL GSSAPI regression with krb5 1.18

Simo Sorce-3
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/[hidden email]" 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             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc





_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot SASL GSSAPI regression with krb5 1.18

Greg Hudson
In reply to this post by Mantas M.-2
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@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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev