While I dont have an account to comment on the pidgin ticket, there are a few things going on here. First is the ambiguous language in RFC2831. If the client previously authenticated to the server, then it MAY perform "subsequent authentication". According to RFC2119 the word MAY indicates the item is truly optional, and may be left out for any number of reasons. The problem here is that the verbage is in reference to what a client MAY do. Does that mean the server MAY support it? Or that the server MUST support it in case the client might try?
Sun's take on the matter is that the subsequent authentication is optional in server implementations. From the java6 source:
/**
* An implementation of the DIGEST-MD5 server SASL mechanism.
* (<a href="http://www.ietf.org/rfc/rfc2831.txt">RFC 2831</a>)
* <p>
* The DIGEST-MD5 SASL mechanism specifies two modes of authentication.
* <ul><li>Initial Authentication
* <li>Subsequent Authentication - optional, (currently not supported)
* </ul>
*/
so its pretty clear that it wont be supported by Openfire (or any other Java implementation) anytime soon. Perhaps Java7 will have it, or some other SASL library will show up with support. The problem is with the current Java implementation the object is not kept around after the first authentication, so the server dosnt remember the original nonce, nonce-count, and cnonce values, and thus cant compare them to what the client provides.
My personal opinion on the matter is pidgin should try the subsequent authentication method, and upon failure fall back to the initial method. With the RFC as ambiguous as it is, there may be other implementations that choose to skip it.
Currently workarounds are:
