Public bug reported: smtp_cmd_buffer_size is currently 2048 bytes. 2048 bytes is not sufficient for clients that send an AUTH with an initial-response for GSSAPI when Windows Kerberos tickets are used that contain a PAC -- as of Windows 2003, the maximum ticket size is 12000 bytes.
MUAs that use AUTH GSSAPI without an initial-response are not impacted by the 2048 limit, since the remainder of the SASL session is handled by auth_get_data in Exim, which uses big_buffer and has sufficient space to process large Kerberos tickets. Thunderbird will always send an AUTH GSSAPI with an initial-response, which makes it subject to the 2048 byte limit. A large Kerberos ticket will easily surpass 2048 bytes when base64-encoded, causing the AUTH to fail. RFC 4954 recommends 12288 bytes as a line limit to handle AUTH. For a base64 encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed. This bug is fixed upstream (4.77). It would be nice to backport it to precise. [Impact] smtp_cmd_buffer_size is currently 2048 bytes. 2048 bytes is not sufficient for clients that send an AUTH with an initial-response for GSSAPI when Windows Kerberos tickets are used that contain a PAC. For a base64 encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed. [Test Case] 1. Configure exim4 to use GSSAPI auth. 2. Configure thunderbird to use GSSAPI smtp auth on windows xp/vista/7/2003/2008. 3. Auth will always fail. [Regression Potential] The fix for this bug is one-line-patch applied to upstream (4.77) more than year ago, so it already has got sufficient testing. ** Affects: exim Importance: Unknown Status: Unknown ** Affects: exim4 (Ubuntu) Importance: Undecided Status: New ** Package changed: heimdal (Ubuntu) => exim4 (Ubuntu) ** Description changed: smtp_cmd_buffer_size is currently 2048 bytes. 2048 bytes is not sufficient for clients that send an AUTH with an initial-response for GSSAPI when Windows Kerberos tickets are used that contain a PAC -- as of Windows 2003, the maximum ticket size is 12000 bytes. MUAs that use AUTH GSSAPI without an initial-response are not impacted by the 2048 limit, since the remainder of the SASL session is handled by auth_get_data in Exim, which uses big_buffer and has sufficient space to process large Kerberos tickets. Thunderbird will always send an AUTH GSSAPI with an initial-response, which makes it subject to the 2048 byte limit. A large Kerberos ticket will easily surpass 2048 bytes when base64-encoded, causing the AUTH to fail. RFC 4954 recommends 12288 bytes as a line limit to handle AUTH. For a base64 - encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed. + encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed. - This bug is fixed upstream (4.77). + This bug is fixed upstream (4.77). It would be nice to backport it to + precise. [Impact] smtp_cmd_buffer_size is currently 2048 bytes. 2048 bytes is not sufficient for clients that send an AUTH with an initial-response for GSSAPI when Windows Kerberos tickets are used that contain a PAC. For a base64 encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed. [Test Case] 1. Configure exim4 to use GSSAPI auth. 2. Configure thunderbird to use GSSAPI smtp auth on windows xp/vista/7/2003/2008. 3. Auth will always fail. [Regression Potential] The fix for this bug is one-line-patch applied to upstream (4.77) more than year ago, so it already has got sufficient testing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1088136 Title: AUTH cannot handle a request with an initial-response over 2048 bytes (GSSAPI-related) To manage notifications about this bug go to: https://bugs.launchpad.net/exim/+bug/1088136/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs