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.
