GSSAPI and Success as a error code

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

GSSAPI and Success as a error code

Kacper
Hello,

I've been trying to setup GSSAPI in postfix via cyrus-sasl. The service principal is configured and so is sasl2/smtpd.conf. All I get from the postfix log file is that the GSSAPI auth failed and that the minor error code was Success.

Success as an error code doesn't leave much to go on. log_level: 7 did nothing to produce more verbose output. 

How do I debug this? Is there a configuration flag to bring out trace information? Perhaps postfix can be recompiled with some kind of SASL debug flag? I guess the last option would be to use gdb (already tried strace) but then I would need to know what to look for.

Any help is appreciated.

Thanks,
Kacper

log/mailog:
Aug 22 08:57:10 srv postfix/smtpd[15965]: xsasl_cyrus_server_first: decoded initial response `?????*?H???????
Aug 22 08:57:10 srv postfix/smtpd[15965]: warning: SASL authentication failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Success)
Aug 22 08:57:10 srv postfix/smtpd[15965]: warning: unknown[192.168.0.150]: SASL GSSAPI authentication failed: authentication failure
Aug 22 08:57:10 srv postfix/smtpd[15965]: > unknown[192.168.0.150]: 535 5.7.8 Error: authentication failed: authentication failure

sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: plain login gssapi
keytab: /etc/postfix/postfix.keytab
log_level: 7

Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Wietse Venema
Kacper:
> Hello,
>
> I've been trying to setup GSSAPI in postfix via cyrus-sasl. The service
> principal is configured and so is sasl2/smtpd.conf. All I get from the
> postfix log file is that the GSSAPI auth failed and that the minor error
> code was Success.

Indeed. Postfix does not implement GSSAPI. Cyrus SASL does. Therefore,
only Cyrus Sasl knows what is going on.

> Success as an error code doesn't leave much to go on. log_level: 7 did
> nothing to produce more verbose output.

It's a bit like logging into a system where you have no account.
The password check fails successfully.

> How do I debug this? Is there a configuration flag to bring out trace
> information? Perhaps postfix can be recompiled with some kind of SASL debug
> flag? I guess the last option would be to use gdb (already tried strace)
> but then I would need to know what to look for.

There is no code in Postfix to look inside the guts of Cyrus SASL.
You'd have to use some debugger like gdb for that (as described in
Postfix DEBUG_README).

However it may be possible to configure additional callbacks in
the Postfix xsasl_cyrus_server.c file:

176  /*
177   * SASL callback interface structure. These call-backs have no per-session
178   * context.
179   */
180 #define NO_CALLBACK_CONTEXT     0
181
182 static sasl_callback_t callbacks[] = {
183     {SASL_CB_LOG, (XSASL_CYRUS_CB) &xsasl_cyrus_log, NO_CALLBACK_CONTEXT},
184     {SASL_CB_LIST_END, 0, 0}
185 };

Perhaps there is anything in there that would shed a light on the
problem.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Viktor Dukhovni
In reply to this post by Kacper


> On Aug 22, 2018, at 5:02 AM, Kacper <[hidden email]> wrote:
>
> I've been trying to setup GSSAPI in postfix via cyrus-sasl. The service principal is configured and so is sasl2/smtpd.conf. All I get from the postfix log file is that the GSSAPI auth failed and that the minor error code was Success.

Post more detailed configuration information.

   0.  List the keytab file owner and permissions (ls -l)
   1.  List the principal names from the keytab file
   2.  As the "postfix" user, use the keytab file to obtain a
       TGT with "kinit -k -t <keytab> <principal>".  List the
       obtained creds with "klist".

I expect your keytab file is owner=root mode=0600, which can't
work with Postfix, because by the time smtpd(8) is using Cyrus
SASL to check SASL creds, it is no longer running as "root".

> How do I debug this?

Don't debug, configure it correctly instead.  To make doubly sure the
correct keytab file is used:

   import_environment =
        MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ LANG=C
        KRB5_KTNAME=/etc/postfix/postfix.keytab

though you should store your keytab elsewhere, the files
in /etc/postfix/ are expected to belong to root.  This
should be in /var/spool/keytabs/smtp or similar.

I use GSSAPI via dovecot auth:

main.cf:
    smtpd_sasl_type = dovecot

dovecot.conf:
    auth_realms = <MYREALM>
    auth_mechanisms = gssapi plain
    auth_gssapi_hostname = "$ALL"
    auth_krb5_keytab = /var/spool/keytabs/imap

$ ls -l /var/spool/keytabs/imap
-rw-------  1 dovecot  wheel  1142 Jun 26 18:47 /var/spool/keytabs/imap

/var/spool/keytabs/imap:

Vno  Type                     Principal
  1  aes128-cts-hmac-sha1-96  imap/<myhostname>@<MYREALM>
  1  aes128-cts-hmac-sha1-96  smtp/<myhostname>@<MYREALM>

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Kacper
In reply to this post by Wietse Venema

I managed to get gdb setup and tracked down the error happening in gss_accept_sec_context in the cyrus sasl library. I got the major and minor kerberos error codes (851968 respectively 100001) but that doesn't leave much to go on either.

On Wed, Aug 22, 2018 at 2:37 PM Wietse Venema <[hidden email]> wrote:
Kacper:
> Hello,
>
> I've been trying to setup GSSAPI in postfix via cyrus-sasl. The service
> principal is configured and so is sasl2/smtpd.conf. All I get from the
> postfix log file is that the GSSAPI auth failed and that the minor error
> code was Success.

Indeed. Postfix does not implement GSSAPI. Cyrus SASL does. Therefore,
only Cyrus Sasl knows what is going on.

> Success as an error code doesn't leave much to go on. log_level: 7 did
> nothing to produce more verbose output.

It's a bit like logging into a system where you have no account.
The password check fails successfully.

> How do I debug this? Is there a configuration flag to bring out trace
> information? Perhaps postfix can be recompiled with some kind of SASL debug
> flag? I guess the last option would be to use gdb (already tried strace)
> but then I would need to know what to look for.

There is no code in Postfix to look inside the guts of Cyrus SASL.
You'd have to use some debugger like gdb for that (as described in
Postfix DEBUG_README).

However it may be possible to configure additional callbacks in
the Postfix xsasl_cyrus_server.c file:

176  /*
177   * SASL callback interface structure. These call-backs have no per-session
178   * context.
179   */
180 #define NO_CALLBACK_CONTEXT     0
181
182 static sasl_callback_t callbacks[] = {
183     {SASL_CB_LOG, (XSASL_CYRUS_CB) &xsasl_cyrus_log, NO_CALLBACK_CONTEXT},
184     {SASL_CB_LIST_END, 0, 0}
185 };

Perhaps there is anything in there that would shed a light on the
problem.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Kacper
In reply to this post by Viktor Dukhovni
I know for a fact that postfix and cyrus can read the keytab since
wrong permissions correctly give a permission denied in the log file.
I also verified that the correct files was chosen using strace.

I also tried using dovecot as a sasl auth backend. It gave me the same
cryptic kerberos error response as cyrus. I also have imap setup in
dovecot and it works without issues with GSSAPI. I can't understand
why SMTP refuses to work.

log/dovecot.log:
Aug 22 15:45:35 auth: Info: gssapi(?,192.168.0.150): While processing
incoming data: Unspecified GSS failure.  Minor code may provide more
information
Aug 22 15:45:35 auth: Info: gssapi(?,192.168.0.150): While processing
incoming data: Success

As requested:

# ls -la /etc/postfix/postfix.keytab
-rw-rw-rw-. 1 root root 5859 Aug 22 15:52 /etc/postfix/postfix.keytab

klist -Kek /etc/postfix/postfix.keytab
Keytab name: FILE:/etc/postfix/postfix.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 smtp/[hidden email] (arcfour-hmac)
(0x51f860d755da544604c21b686c70fdb2)
   2 smtp/[hidden email] (des-cbc-md5)  (0x32f8f1ad3140859b)
   2 smtp/[hidden email] (des-cbc-crc)  (0x32f8f1ad3140859b)

# sudo -u postfix kinit -k -t /etc/postfix/postfix.keytab smtp/srv.mydomain.test
# sudo -u postfix klist
Ticket cache: FILE:/tmp/krb5cc_89
Default principal: smtp/[hidden email]

Valid starting       Expires              Service principal
08/22/2018 15:56:55  08/23/2018 01:56:55  krbtgt/[hidden email]
renew until 08/29/2018 15:56:55

On Wed, Aug 22, 2018 at 3:05 PM Viktor Dukhovni
<[hidden email]> wrote:

>
>
>
> > On Aug 22, 2018, at 5:02 AM, Kacper <[hidden email]> wrote:
> >
> > I've been trying to setup GSSAPI in postfix via cyrus-sasl. The service principal is configured and so is sasl2/smtpd.conf. All I get from the postfix log file is that the GSSAPI auth failed and that the minor error code was Success.
>
> Post more detailed configuration information.
>
>    0.  List the keytab file owner and permissions (ls -l)
>    1.  List the principal names from the keytab file
>    2.  As the "postfix" user, use the keytab file to obtain a
>        TGT with "kinit -k -t <keytab> <principal>".  List the
>        obtained creds with "klist".
>
> I expect your keytab file is owner=root mode=0600, which can't
> work with Postfix, because by the time smtpd(8) is using Cyrus
> SASL to check SASL creds, it is no longer running as "root".
>
> > How do I debug this?
>
> Don't debug, configure it correctly instead.  To make doubly sure the
> correct keytab file is used:
>
>    import_environment =
>         MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ LANG=C
>         KRB5_KTNAME=/etc/postfix/postfix.keytab
>
> though you should store your keytab elsewhere, the files
> in /etc/postfix/ are expected to belong to root.  This
> should be in /var/spool/keytabs/smtp or similar.
>
> I use GSSAPI via dovecot auth:
>
> main.cf:
>     smtpd_sasl_type = dovecot
>
> dovecot.conf:
>     auth_realms = <MYREALM>
>     auth_mechanisms = gssapi plain
>     auth_gssapi_hostname = "$ALL"
>     auth_krb5_keytab = /var/spool/keytabs/imap
>
> $ ls -l /var/spool/keytabs/imap
> -rw-------  1 dovecot  wheel  1142 Jun 26 18:47 /var/spool/keytabs/imap
>
> /var/spool/keytabs/imap:
>
> Vno  Type                     Principal
>   1  aes128-cts-hmac-sha1-96  imap/<myhostname>@<MYREALM>
>   1  aes128-cts-hmac-sha1-96  smtp/<myhostname>@<MYREALM>
>
> --
>         Viktor.
>
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Viktor Dukhovni


> On Aug 22, 2018, at 12:04 PM, Kacper <[hidden email]> wrote:
>
> As requested:
>
> # ls -la /etc/postfix/postfix.keytab
> -rw-rw-rw-. 1 root root 5859 Aug 22 15:52 /etc/postfix/postfix.keytab

This is of course wrong.  The file MUST NOT be world-readable.  It
needs to belong to the "postfix" user, and have mode 0600.

> log/dovecot.log:
> Aug 22 15:45:35 auth: Info: gssapi(?,192.168.0.150): While processing
> incoming data: Unspecified GSS failure.  Minor code may provide more
> information
> Aug 22 15:45:35 auth: Info: gssapi(?,192.168.0.150): While processing
> incoming data: Success

Why are you looking in the dovecot logs?  This is a dovecot IMAP error,
not a Postfix smtpd(8) error...

> klist -Kek /etc/postfix/postfix.keytab
> Keytab name: FILE:/etc/postfix/postfix.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
>   2 smtp/[hidden email] (arcfour-hmac)
> (0x51f860d755da544604c21b686c70fdb2)
>   2 smtp/[hidden email] (des-cbc-md5)  (0x32f8f1ad3140859b)
>   2 smtp/[hidden email] (des-cbc-crc)  (0x32f8f1ad3140859b)

This makes the RC4 and DES keys for this principal public.  It should not
have any DES keys, you need to disable DES in your KDC, and generate keytabs
that use AES and perhaps also RC4 (though this is generally no longer needed
even on Windows).  Since the keys have leaked to the world, this is a good
time to change them.

> # sudo -u postfix kinit -k -t /etc/postfix/postfix.keytab smtp/srv.mydomain.test
> # sudo -u postfix klist
> Ticket cache: FILE:/tmp/krb5cc_89
> Default principal: smtp/[hidden email]
>
> Valid starting       Expires              Service principal
> 08/22/2018 15:56:55  08/23/2018 01:56:55  krbtgt/[hidden email]
> renew until 08/29/2018 15:56:55

It does look like the keys match what the KDC has.  Now you need to include
KRB5_KTNAME=/path/to/keytab as recommended in "import_environment", ensure
correct location (not /etc/postfix) and ownership/permissions, provision
non-legacy algorithms.

You should also ensure that the client is using the same hostname for
the SMTP server that you see listed in the keytab file (whatever
"srv.mydomain.test" is).  Make sure the client does not have
stale cached tickets, that no longer match the server keytab.

What is the "kvno" for the service as seen from "klist" on the client?
Is the principal name the same?

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Bastian Blank-3
In reply to this post by Kacper
On Wed, Aug 22, 2018 at 06:04:33PM +0200, Kacper wrote:
> klist -Kek /etc/postfix/postfix.keytab
> Keytab name: FILE:/etc/postfix/postfix.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
>    2 smtp/[hidden email] (arcfour-hmac)
> (0x51f860d755da544604c21b686c70fdb2)
>    2 smtp/[hidden email] (des-cbc-md5)  (0x32f8f1ad3140859b)
>    2 smtp/[hidden email] (des-cbc-crc)  (0x32f8f1ad3140859b)

I would really start with a keytab that got non-deprecated ciphers.  I
doubt that anything from the last ten years will work with the des ones
and not many with the arcfour one.  So there needs to be at least one
aes one.

Bastian

--
The heart is not a logical organ.
                -- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Kacper
In reply to this post by Viktor Dukhovni
On Wed, Aug 22, 2018 at 6:30 PM Viktor Dukhovni
<[hidden email]> wrote:
> Why are you looking in the dovecot logs?  This is a dovecot IMAP error,
> not a Postfix smtpd(8) error...

Because you said that you had GSSAPI working using dovecot sasl, so I
configured postfix to use dovecot instead of cyrus and got the same
kerberos error. dovecot.log had more in depth logging of sasl errors
than mailog.
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Viktor Dukhovni
On Wed, Aug 22, 2018 at 06:41:31PM +0200, Kacper wrote:

> On Wed, Aug 22, 2018 at 6:30 PM Viktor Dukhovni
> <[hidden email]> wrote:
> > Why are you looking in the dovecot logs?  This is a dovecot IMAP error,
> > not a Postfix smtpd(8) error...
>
> Because you said that you had GSSAPI working using dovecot sasl, so I
> configured postfix to use dovecot instead of cyrus and got the same
> kerberos error. dovecot.log had more in depth logging of sasl errors
> than mailog.

I see.  What keytab file was dovecot using?  That keytab file needs
to include service principals (under the same names as used by
clients) for both smtp and imap.  Dovecot reads its keytab file as
the "dovecot" user (at least on my system), and it needs to have
appropriate ownership and permissions.

What client software are you testing with?  Is the client sending
an appropriate KRB5 mechanism GSS token?  What do you see in the
client's credential cache?  List sufficient detail to show the
service principal name, kvno and enctype.  No need to post session
keys (nor keys from keytab files, just the enctypes are enough).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Kacper
It's a test system so I'm not worried if the keys become public (which
they now are). On my test box dovecot runs as root (something I'm
going to change, but it's out of the scope for this problem).
I know I should have the keytab in /etc/dovecot but I don't think it
makes any difference right now, seeing how GSSAPI for imap using
dovecot works.

I'm using Thunderbird 59.9.1 on Windows 7 and Samba 4.8.3 as an AD DC/KDC.

#ls -la /etc/dovecot/dovecot.keytab
-rw-rw-rw-. 1 root root 762 Aug 22 16:44 /etc/dovecot/dovecot.keytab

I have the permission set so broad jus to rule out any permission problems.

I retested it all and added more enctypes. Some result. It's puzzling
though why IMAP works via GSSAPI but SMTP refuses to.

# klist -ek /etc/dovecot/dovecot.keytab
Keytab name: FILE:/etc/dovecot/dovecot.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 smtp/[hidden email] (aes256-cts-hmac-sha1-96)
   2 smtp/[hidden email] (aes128-cts-hmac-sha1-96)
   2 smtp/[hidden email] (arcfour-hmac)
   2 smtp/[hidden email] (des-cbc-md5)
   2 smtp/[hidden email] (des-cbc-crc)
   2 imap/[hidden email] (aes256-cts-hmac-sha1-96)
   2 imap/[hidden email] (aes128-cts-hmac-sha1-96)
   2 imap/[hidden email] (arcfour-hmac)
   2 imap/[hidden email] (des-cbc-md5)
   2 imap/[hidden email] (des-cbc-crc)
On Wed, Aug 22, 2018 at 6:50 PM Viktor Dukhovni
<[hidden email]> wrote:

>
> On Wed, Aug 22, 2018 at 06:41:31PM +0200, Kacper wrote:
>
> > On Wed, Aug 22, 2018 at 6:30 PM Viktor Dukhovni
> > <[hidden email]> wrote:
> > > Why are you looking in the dovecot logs?  This is a dovecot IMAP error,
> > > not a Postfix smtpd(8) error...
> >
> > Because you said that you had GSSAPI working using dovecot sasl, so I
> > configured postfix to use dovecot instead of cyrus and got the same
> > kerberos error. dovecot.log had more in depth logging of sasl errors
> > than mailog.
>
> I see.  What keytab file was dovecot using?  That keytab file needs
> to include service principals (under the same names as used by
> clients) for both smtp and imap.  Dovecot reads its keytab file as
> the "dovecot" user (at least on my system), and it needs to have
> appropriate ownership and permissions.
>
> What client software are you testing with?  Is the client sending
> an appropriate KRB5 mechanism GSS token?  What do you see in the
> client's credential cache?  List sufficient detail to show the
> service principal name, kvno and enctype.  No need to post session
> keys (nor keys from keytab files, just the enctypes are enough).
>
> --
>         Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Viktor Dukhovni


> On Aug 22, 2018, at 1:05 PM, Kacper <[hidden email]> wrote:
>
> I know I should have the keytab in /etc/dovecot but I don't think it
> makes any difference right now, seeing how GSSAPI for imap using
> dovecot works.

Using which keytab file?  What kerberos/GSSAPI-related settings do
you have in the dovecot configuration?  If you want help you need
to make it possible for others to see sufficient details of your
configuration.

> I'm using Thunderbird 59.9.1 on Windows 7 and Samba 4.8.3 as an AD DC/KDC.

And what does "klist" report on Windows (for relevant service principals)?
What hostname is Thunderbird configured to use?  Is this name an alias?

> #ls -la /etc/dovecot/dovecot.keytab
> -rw-rw-rw-. 1 root root 762 Aug 22 16:44 /etc/dovecot/dovecot.keytab

You really should have this working mode 0600 with IMAP, and the keytab
file not owned by root.

> I have the permission set so broad jus to rule out any permission problems.

Some libraries don't like insecure permissions, though if this works for
IMAP, it should (all else being equal) work equally well for SMTP.

> I retested it all and added more enctypes. Some result. It's puzzling
> though why IMAP works via GSSAPI but SMTP refuses to.

Perhaps you're not looking at the right keytab file, or the client
has stale tickets, or is using a different hostname, ...

> # klist -ek /etc/dovecot/dovecot.keytab
> Keytab name: FILE:/etc/dovecot/dovecot.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
>   2 smtp/[hidden email] (aes256-cts-hmac-sha1-96)
>   2 smtp/[hidden email] (aes128-cts-hmac-sha1-96)
>   2 smtp/[hidden email] (arcfour-hmac)
>   2 smtp/[hidden email] (des-cbc-md5)
>   2 smtp/[hidden email] (des-cbc-crc)
>   2 imap/[hidden email] (aes256-cts-hmac-sha1-96)
>   2 imap/[hidden email] (aes128-cts-hmac-sha1-96)
>   2 imap/[hidden email] (arcfour-hmac)
>   2 imap/[hidden email] (des-cbc-md5)
>   2 imap/[hidden email] (des-cbc-crc)

I see new enctypes here, but the same "kvno" (2) as before.  Normally,
when keys are changed to add new enctypes the "kvno" changes.  I'd
have expected "kvno = 3" here.  Are the AES keys new, or were they
present all along?

Change the IMAP and the SMTP keys in the KDC, drop the DES keys and
re-create the keytab file.  Does IMAP still work?  If SMTP does not,
is Postfix still using Dovecot authentication?  If dovecot still
logs GSSAPI errors, perhaps the problem is on the client side,
run "klist purge" (Windows-specific) and retry after all the changes
above.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Kacper
I managed to get it working after coincidentally finding a post in the
dovecot mailing list,
https://www.dovecot.org/list/dovecot/2010-October/054082.html.
It seems that postfix is truncating the GSSAPI token and one must set
line_length_limit. Setting it to something high works, however setting
it to 2176 as the dovecot mailing list post suggests didn't work for
me. The question is how long can a GSSAPI token be?

It's a potential bug though I believe. Shouldn't SASL auth tokens be
passed without modification to the SASL backend?
On Wed, Aug 22, 2018 at 7:43 PM Viktor Dukhovni
<[hidden email]> wrote:

>
>
>
> > On Aug 22, 2018, at 1:05 PM, Kacper <[hidden email]> wrote:
> >
> > I know I should have the keytab in /etc/dovecot but I don't think it
> > makes any difference right now, seeing how GSSAPI for imap using
> > dovecot works.
>
> Using which keytab file?  What kerberos/GSSAPI-related settings do
> you have in the dovecot configuration?  If you want help you need
> to make it possible for others to see sufficient details of your
> configuration.
>
> > I'm using Thunderbird 59.9.1 on Windows 7 and Samba 4.8.3 as an AD DC/KDC.
>
> And what does "klist" report on Windows (for relevant service principals)?
> What hostname is Thunderbird configured to use?  Is this name an alias?
>
> > #ls -la /etc/dovecot/dovecot.keytab
> > -rw-rw-rw-. 1 root root 762 Aug 22 16:44 /etc/dovecot/dovecot.keytab
>
> You really should have this working mode 0600 with IMAP, and the keytab
> file not owned by root.
>
> > I have the permission set so broad jus to rule out any permission problems.
>
> Some libraries don't like insecure permissions, though if this works for
> IMAP, it should (all else being equal) work equally well for SMTP.
>
> > I retested it all and added more enctypes. Some result. It's puzzling
> > though why IMAP works via GSSAPI but SMTP refuses to.
>
> Perhaps you're not looking at the right keytab file, or the client
> has stale tickets, or is using a different hostname, ...
>
> > # klist -ek /etc/dovecot/dovecot.keytab
> > Keytab name: FILE:/etc/dovecot/dovecot.keytab
> > KVNO Principal
> > ---- --------------------------------------------------------------------------
> >   2 smtp/[hidden email] (aes256-cts-hmac-sha1-96)
> >   2 smtp/[hidden email] (aes128-cts-hmac-sha1-96)
> >   2 smtp/[hidden email] (arcfour-hmac)
> >   2 smtp/[hidden email] (des-cbc-md5)
> >   2 smtp/[hidden email] (des-cbc-crc)
> >   2 imap/[hidden email] (aes256-cts-hmac-sha1-96)
> >   2 imap/[hidden email] (aes128-cts-hmac-sha1-96)
> >   2 imap/[hidden email] (arcfour-hmac)
> >   2 imap/[hidden email] (des-cbc-md5)
> >   2 imap/[hidden email] (des-cbc-crc)
>
> I see new enctypes here, but the same "kvno" (2) as before.  Normally,
> when keys are changed to add new enctypes the "kvno" changes.  I'd
> have expected "kvno = 3" here.  Are the AES keys new, or were they
> present all along?
>
> Change the IMAP and the SMTP keys in the KDC, drop the DES keys and
> re-create the keytab file.  Does IMAP still work?  If SMTP does not,
> is Postfix still using Dovecot authentication?  If dovecot still
> logs GSSAPI errors, perhaps the problem is on the client side,
> run "klist purge" (Windows-specific) and retry after all the changes
> above.
>
> --
>         Viktor.
>
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Viktor Dukhovni
On Thu, Aug 23, 2018 at 01:37:14PM +0200, Kacper wrote:

> I managed to get it working after coincidentally finding a post in the
> dovecot mailing list,
> https://www.dovecot.org/list/dovecot/2010-October/054082.html.
> It seems that postfix is truncating the GSSAPI token and one must set
> line_length_limit. Setting it to something high works, however setting
> it to 2176 as the dovecot mailing list post suggests didn't work for
> me. The question is how long can a GSSAPI token be?

With PACs in the ticket, tokens can arbitrarily long.

Long tickets should work without changing SMTP command line length
limits:

    https://tools.ietf.org/html/rfc4954#page-4

       ...

       Note that the AUTH command is still subject to the line length
       limitations defined in [SMTP].  If use of the initial response
       argument would cause the AUTH command to exceed this length,
       the client MUST NOT use the initial response parameter (and
       instead proceed as defined in Section 5.1 of [SASL]).

    [ Corrected in the Errata to:

       If use of the initial response
       argument would cause the AUTH command to exceed this length,
       the client MUST NOT use the initial response parameter (and
       instead proceed as defined in Section 5.1 of [RFC 2222]). ]

    https://tools.ietf.org/html/rfc2222#section-5.1

       If the initial client response parameter is not given, or if a
       protocol's profile does not permit the command which initiates an
       authentication protocol exchange to contain an initial client
       response, then the server issues a challenge with no data.  The
       client's response to this challenge is then used as the initial
       client response.  (The server then proceeds to send the next
       challenge, indicates completion, or indicates failure.)

The upshot is that with large GSS TOKENS the client's AUTH command
must be:

        AUTH GSSAPI

rather than:

        AUTH GSSAPI <base64-token>

the server returns an empty response

        334<SPACE>

and now the client can continue in an AUTH-specific context, which
is not necessarily subject to generic SMTP command limits.  The
relevant text is:

    https://tools.ietf.org/html/rfc4954#page-5

          ...

          Note that these [BASE64] strings can be much longer than
          normal SMTP commands.  Clients and servers MUST be able to
          handle the maximum encoded size of challenges and responses
          generated by their supported authentication mechanisms.  This
          requirement is independent of any line length limitations the
          client or server may have in other parts of its protocol
          implementation.  (At the time of writing of this document,
          12288 octets is considered to be a sufficient line length
          limit for handling of deployed authentication mechanisms.)
          If, during an authentication exchange, the server receives a
          line that is longer than the server's authentication buffer,
          the server fails the AUTH command with the 500 reply.  Servers
          using the enhanced status codes extension [ESMTP-CODES] SHOULD
          return an enhanced status code of 5.5.6 in this case.

Which means that the client's subsequent message is a single line
of base64 containing the client's initial GSS token:

        <base64-of-token>

this line could be up to 12288 (or more) bytes long.  In this context
Postfix should be prepared to read multiple 4k buffers up to a
generous line limit of 16k or more.  If that's not the case, we're
somewhat out of spec in our SASL implementation.  If, on the other
hand, the client's initial token is sent with the "AUTH GSSAPI"
command despite its excessive length, then the client is out of
spec.  Looking at the traffic should show which is at fault.

How many groups is the user a member of?  Double that if credential
delegation is requested (should not be for SMTP, but may depend on
the service principal's KDC entry "ok-as-delegate" flag when the
client is on Windows.  MIT and Heimdal Kerberos clients on unix
tend to use local policy (command-line arguments, ...) rather than
KDC hints to decide when to delegate.

At $WORK we run unix services (that don't consume PACs) in a separate
Kerberos realm, and the Unix-realm Heimdal KDCs drop the PAC when
issuing cross-realm TGTs, and the resuling service tickets are
svelte.  GSS tokens for users originally logged into Windows are
then small, except when delegation is enabled, which is mostly just
for SSH (we have ok-as-delegate enabled for host/* and similar
principals and not otherwise).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Viktor Dukhovni
On Thu, Aug 23, 2018 at 09:04:15AM -0400, Viktor Dukhovni wrote:

> Which means that the client's subsequent message is a single line
> of base64 containing the client's initial GSS token:
>
> <base64-of-token>
>
> this line could be up to 12288 (or more) bytes long.  In this context
> Postfix should be prepared to read multiple 4k buffers up to a
> generous line limit of 16k or more.  If that's not the case, we're
> somewhat out of spec in our SASL implementation.  If, on the other
> hand, the client's initial token is sent with the "AUTH GSSAPI"
> command despite its excessive length, then the client is out of
> spec.  Looking at the traffic should show which is at fault.

It looks like Postfix is not prepared to receive large tokens:

    src/smtpd/smtpd_sasl_glue.c:

309         /*
310          * Receive the client response. "*" means that the client gives up.
311          * XXX For now we ignore the fact that an excessively long response
312          * will be chopped into multiple responses. To handle such responses,
313          * we need to change smtpd_chat_query() so that it returns an error
314          * indication.
315          */
316         smtpd_chat_query(state);

We need to replace smtpd_chat_query() with a sasl-specific function
that calls smtp_get_line() one or more times as necessary to read
and combine any partial lines to yield a complete client token, up
to a limit of 12288 or more bytes (9K bytes before base64 encoding).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: GSSAPI and Success as a error code

Wietse Venema
Viktor Dukhovni:

> On Thu, Aug 23, 2018 at 09:04:15AM -0400, Viktor Dukhovni wrote:
>
> > Which means that the client's subsequent message is a single line
> > of base64 containing the client's initial GSS token:
> >
> > <base64-of-token>
> >
> > this line could be up to 12288 (or more) bytes long.  In this context
> > Postfix should be prepared to read multiple 4k buffers up to a
> > generous line limit of 16k or more.  If that's not the case, we're
> > somewhat out of spec in our SASL implementation.  If, on the other
> > hand, the client's initial token is sent with the "AUTH GSSAPI"
> > command despite its excessive length, then the client is out of
> > spec.  Looking at the traffic should show which is at fault.
>
> It looks like Postfix is not prepared to receive large tokens:
>
>     src/smtpd/smtpd_sasl_glue.c:
>
> 309         /*
> 310          * Receive the client response. "*" means that the client gives up.
> 311          * XXX For now we ignore the fact that an excessively long response
> 312          * will be chopped into multiple responses. To handle such responses,
> 313          * we need to change smtpd_chat_query() so that it returns an error
> 314          * indication.
> 315          */
> 316         smtpd_chat_query(state);
>
> We need to replace smtpd_chat_query() with a sasl-specific function
> that calls smtp_get_line() one or more times as necessary to read
> and combine any partial lines to yield a complete client token, up
> to a limit of 12288 or more bytes (9K bytes before base64 encoding).

Fine as long as it does not introduce a memory exhaustion vulnerability,
and as long as it handles time limits and EOF consistent with other SMTP
server inputs.

If the response has a length indication perhaps one could benefit
from the brand-new smtp_fread() call (added for BDAT support).

        Wietse
Reply | Threaded
Open this post in threaded view
|

[PATCH] Postfix 3.4: SASL response length limit

Viktor Dukhovni
On Thu, Aug 23, 2018 at 11:14:57AM -0400, Wietse Venema wrote:

> > It looks like Postfix is not prepared to receive large tokens:
> >
> > 316         smtpd_chat_query(state);
> >
> > We need to replace smtpd_chat_query() with a sasl-specific function
> > that calls smtp_get_line() one or more times as necessary to read
> > and combine any partial lines to yield a complete client token, up
> > to a limit of 12288 or more bytes (9K bytes before base64 encoding).
>
> Fine as long as it does not introduce a memory exhaustion vulnerability,
> and as long as it handles time limits and EOF consistent with other SMTP
> server inputs.
>
> If the response has a length indication perhaps one could benefit
> from the brand-new smtp_fread() call (added for BDAT support).
Sadly no length indication.  Two patches attached, the firsrt fixes
a compiler type mismatch warning for a no-longer-used argument to
psc_get_footer().  The second is the new SASL line limit.

--
        Viktor.

0001-Drop-unused-psc_get_footer-parameter.patch (1K) Download Attachment
0002-Implement-new-SASL-response-line-limit.patch (8K) Download Attachment