Proxying of non "plain" SASL mechnisms.

[Peter Mogensen]

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.
- 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
the Kerberos ticket doesn't put restrictions on the client IP-address.

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