[jdev] Re: [xmppwg] Incorrect SASL Digest MD5 example in XMPP Core

[Ralph Meijer]

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] https://www.jabber.org/xmppwg/2005-October/002332.html

-- 
Groetjes,

ralphm