Bug#752853: Exim4 AUTH GSSAPI does not work with cross-realm

[Jaap Winius]

Package: exim4-daemon-heavy
Version: 4.80-7

When Exim4 is configured to support AUTH GSSAPI, this does not work  
when cross-realm authentication is used -- only when clients have a  
Kerberos ticket for the same realm. Cross-realm authentication will  
work properly with other services on the same machine, such as SSH and  
Dovecot IMAP, but not with Exim4.

To illustrate, I've included two sets of Exim4 debug output, some  
lines of which have been shortened: one set with a successful  
authentication and the other with a failure.

The first involves a client using a Kerberos ticket from the same  
realm and results in a successful authentication:

  7280 ...
  7280 SMTP>> 250-hello.ebdeep.nl Hello bitis.umrk.nl [82.95.126.201]
  7280 250-SIZE 268435456
  7280 250-8BITMIME
  7280 250-AUTH GSSAPI
  7280 250 HELP
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 SMTP<< AUTH GSSAPI YIICggYJKoZIhvcSAQICAQ ... a7dywKw9uSiRsrIqRvPA0g==
  7280 Initialised Cyrus SASL server connection; service="smtp"  
fqdn="hello.ebdeep.nl" realm="DAPADAM.NL"
  7280 Cyrus SASL set EXTERNAL SSF to 128
  7280 Calling sasl_server_start(GSSAPI,"YIICggY ... dywKw9uSiRsrIqRvPA0g==")
  7280 SMTP>> 334 YIGZBgkqhkiG9xIBAgICAG+BiTCBhq ... X/45CnWuLqKO6mxQL36Uzofe
  7280 tls_do_write(0x7f45d6358730, 214)
  7280 gnutls_record_send(SSL, 0x7f45d6358730, 214)
  7280 outbytes=214
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 SMTP<<
  7280 Calling sasl_server_step("")
  7280 SMTP>> 334 BQQF/wAMAAAAAAAAIgiYcgEAAABoYMqAQcSMI6LY2Ws=
  7280 tls_do_write(0x7f45d6358730, 50)
  7280 gnutls_record_send(SSL, 0x7f45d6358730, 50)
  7280 outbytes=50
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 Calling gnutls_record_recv(0x7f45d639b5f0, 0x7f45d639fa30, 4096)
  7280 SMTP<< BQQE/wAMAAAAAAAAIEXR/QEAAABqd2luaXVzeGET6yg4i7WxWq8G
  7280 Calling sasl_server_step("BQQE/wAMAAAAAAA ... luaXVzeGET6yg4i7WxWq8G")
  7280 Cyrus SASL GSSAPI authentication succeeded for jwinius at DAPADAM.NL
  7280 Cyrus SASL GSSAPI negotiated SSF: 0
  7280 sasl_gssapi authenticator server_condition:
  7280   $auth1 = jwinius at DAPADAM.NL
  7280   $1 = jwinius at DAPADAM.NL
  7280 SMTP>> 235 Authentication succeeded
  7280 ...

This second example is of an authentication failure involving a client  
with Kerberos ticket from a foreign, albeit trusted realm:

13448 ...
13448 SMTP>> 250-hello.ebdeep.nl Hello bitis.umrk.nl [82.95.126.201]
13448 250-SIZE 268435456
13448 250-8BITMIME
13448 250-AUTH GSSAPI
13448 250 HELP
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 SMTP<< AUTH GSSAPI YIICUAYJKoZIhvcSAQICAQ ... k3bEkmKVJoPJo/84ZQIN/pc=
13448 Initialised Cyrus SASL server connection; service="smtp"  
fqdn="hello.ebdeep.nl" realm="DAPADAM.NL"
13448 Cyrus SASL set EXTERNAL SSF to 128
13448 Calling sasl_server_start(GSSAPI,"YIICUAY ... bEkmKVJoPJo/84ZQIN/pc=")
13448 SMTP>> 334 YIGZBgkqhkiG9xIBAgICAG+BiTCBhq ... JMUoa345XJ4rV9J7g8Q7l5Br
13448 tls_do_write(0x7f3eca23c730, 214)
13448 gnutls_record_send(SSL, 0x7f3eca23c730, 214)
13448 outbytes=214
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 SMTP<<
13448 Calling sasl_server_step("")
13448 SMTP>> 334 BQQF/wAMAAAAAAAAHB6hYwEAAAA8eyFNZeXq5Fs4j7w=
13448 tls_do_write(0x7f3eca23c730, 50)
13448 gnutls_record_send(SSL, 0x7f3eca23c730, 50)
13448 outbytes=50
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 SMTP<< BQQE/wAMAAAAAAAAJF/wrAEAAABqd2luaXVzCUv6EURTgAGEo6yT
13448 Calling sasl_server_step("BQQE/wAMAAAAAAA ... luaXVzCUv6EURTgAGEo6yT")
13448 Cyrus SASL permanent failure -13 (authentication failure)
13448 LOG: REJECT
13448   sasl_gssapi authenticator (GSSAPI):
13448   Cyrus SASL permanent failure: authentication failure
13448 SMTP>> 535 Incorrect authentication data
13448 tls_do_write(0x7f3eca23c730, 35)
13448 gnutls_record_send(SSL, 0x7f3eca23c730, 35)
13448 outbytes=35
13448 LOG: MAIN REJECT
13448   sasl_gssapi authenticator failed for bitis.umrk.nl  
([192.168.2.20]) [82.95.126.201]: 535 Incorrect authentication data
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 Calling gnutls_record_recv(0x7f3eca27f000, 0x7f3eca283440, 4096)
13448 SMTP<< QUIT
13448 SMTP>> 221 hello.ebdeep.nl closing connection
13448 tls_do_write(0x7f3eca23c730, 40)
13448 gnutls_record_send(SSL, 0x7f3eca23c730, 40)
13448 outbytes=40
13448 tls_close(): shutting down TLS
13448 LOG: smtp_connection MAIN
13448   SMTP connection from bitis.umrk.nl ([192.168.2.20])  
[82.95.126.201] closed by QUIT
13448 search_tidyup called

Perhaps it's worth mentioning that, despite this failure, the client  
received a Kerberos service ticket anyway.

Some background. In both cases the client connection is initiated from  
the umrk.nl network at 82.95.126.201 and connects to hello.ebdeep.nl  
at 80.101.160.10, which is part of the DAPADAM.NL realm. In the first  
case, the client is an OS X machine running Mozilla Thunderbird 24.6.0  
and has a Kerberos ticket for jwinius at DAPADAM.NL, while in the second  
case it's a Debian wheezy machine running Iceweasel 24.6.0 with a  
jwinius at UMRK.NL ticket. The UMRK.NL realm is trusted by DAPADAM.NL and  
cross-realm authentication works for other Kerberized services in use.  
The wheezy client has no trouble using AUTH GSSAPI to submit mail via  
the local Exim4 server, bitis.umrk.nl with realm UMRK.NL.