Hi, To expand on my previous mail [1], the problem is that, unlike XMPP, in IMAP's profile for SASL it is not possible to send additional data along with a servers' indication of successful authentication. This is covered by section 5.2 in RFC 2222, copied here in full:
5.2. Server returns success with additional data Some mechanisms may specify that server challenge data be sent to the client along with an indication of successful completion of the exchange. This data would, for example, authenticate the server to the client. If a protocol's profile does not permit this server challenge to be returned with a success indication, then the server issues the server challenge without an indication of successful completion. The client then responds with no data. After receiving this empty response, the server then indicates successful completion. In the DIGEST-MD5 authentication mechanism, there is such additional data. It can be used for subsequent authentications without challenges. So for the IMAP profile there are two challenges, one 'real' and one for carrying the additional data on success in the 'rspauth' field. The IMAP exchange appears to be copied to the XMPP examples in RFC 3920, also resulting in two challenges. However, since the XMPP profile *does* support sending along additional data in the <success/> element, the data from the second 'challenge' should go in the <success/> element instead, resulting in the exchange as mentioned in [1]. So, to detect this, you need to try logging in with DIGEST-MD5 while monitoring the exchange. If there are two <challenge/> elements send by the server, the implementation is not correct. Note that a client could always accept the wrong behaviour by storing the result of the second query and sending back <response>=</response>, waiting for the empty badly implemented server to send back an empty <success/>. Of course I'd rather not have such workarounds in place. Note, that this could apply to mechanisms other than DIGEST-MD5, too. I think we should start checking implementations for this and fix things as soon as possible, before it becomes practically impossible because of deployment. I know that some server implementations use the cyrus sasl library for their SASL implementation, and if so, check for the use of the SASL_SUCCESS_DATA flag to sasl_server_new(). If you don't use it, your implementation is most probably not correct. Since jabberd2 (2.0s10 is the one I checked) has this error in its implemention, I suspect all client implementations that successfully authenticate to jabberd2 using the DIGEST-MD5 mechanism to be faulty. I'd like to urge server and client developers to check their code and report back to the xmppwg list (or me privately) about their findings, so we have a clear scope on the problem. [1] http://mail.jabber.org/pipermail/xmppwg/2005-October/002332.html -- Groetjes, ralphm
