Hi,
I understand from earlier discussions that the reason dovecot doesn't support proxying of other SASL mechanisms than those which supply the plaintext password is that in general it would be possible to proxy any SASL mechanism since it might protect against man-in-the-middle attacks (which would prevent proxying).
However, that has led to choice between letting users use PLAIN (or equivalent), or to have the proxy access the target hosts by "master" password. Of course, having the plaintext password the proxy could in principle do other challenge/response SASL handshakes with the target backend, but right now only LOGIN and PLAIN is implemented.
So I wondered about the rationale for not just forward the SASL handshake. the Kerberos ticket doesn't put restrictions on the client IP-address.
First, blindly forwardning will not do, since the mech data has to be decoded anyway to do any per/user passdb lookup (to, say, find the target host). But you don't need authentication to actually succeed to do that. You only need AuthZ-id or AuthN-id.
Secondly, the design of the interaction between imap-login processes and the auth-service in general prevent in general to forward multi-handshake SASL mechanisms, since the authentication must be done before the proxying can be started. But it doesn't prevent forwarding of single handshake SASL mechanisms which use SASL-IR.
Thirdly, while it's correct that some SASL mechanisms protect against man-in-the-middle attacks, that doesn't apply for most single-handshake SASL-IR mechanisms unless they do some kind of channel-binding. (like SASL EXTERNAL) For example, the GS2-KRB5 SASL mech would be perfectly forwarded if just
So, why not just extend the support for proxy authentication forwarding to any single-handskake SASL-IR mechanism, which doesn't use channel-binding? (which includes PLAIN, but also GS2-KRB5, and possibly others).
/Peter