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
On 25 Feb 2015, at 20:59, Peter Mogensen <apm at one.com> wrote:> 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).Yeah, I guess it would work for several of the auth mechanisms. It's a lot of work though and requires some larger changes to how authentication works. I don't currently see it being worth the effort, but I wouldn't mind if somebody else implements it. I guess the parts would be: - Some flag to auth mechanisms that allow proxying based on their initial SASL response. - A new auth setting to enable auth proxying for mechanisms that support it. - If auth proxying is enabled, perform passdb lookup on non-plaintext auth on the initial SASL response. Return "finished" to the auth client with some "mech-proxy=y" extra field, so it knows to start proxying the SASL session to the destination server. - Implementation of the above for all the mechanisms that support it.. - login-common to support sending the same initial response to the target server and proxying the rest of the authentication. (Possibly somehow integrate this with Dovecot's lib-sasl, but not sure if this is needed/useful.)
On 2015-03-18 00:47, Timo Sirainen wrote:> - If auth proxying is enabled, perform passdb lookup on non-plaintext > auth on the initial SASL response. Return "finished" to the auth > client with some "mech-proxy=y" extra field, so it knows to start > proxying the SASL session to the destination server.This is actually the tricky part. To perform a problemer passdb lookup, the proxy will have to be able to decode the user from the SASL IR even though it might not be able to authenticate. This requires knowledge of the SASL IR format (like extracting authz-id/authn-id from the PLAIN argument). That might not be possible for all SASL mechanisms. With GS2-KRB5 you can always get authz-id. On the other hand, mechanisms like GSSAPI (which would work for other reasons) requires the actually perform the authentication before authz-id can be known. So ... it might be a bit difficult to precisely define which mechanism such a feature covers and which it doesn't. /Peter