possible XMPP SASL bug?

[Paul Aurich]

On 2010-04-29 14:28, Evan Schoenberg, M.D. wrote:
> 
> On Apr 29, 2010, at 4:17 PM, Joe Hildebrand wrote:
> 
>> I've not seen Adium try a second method without waiting for a result,
>> but I
>> have seen it try another mechanism when the first one fails.
>>
>> This is almost always wrong, since if one mechanism fails, another one is
>> unlikely to work.  As well, this leads to some servers disconnecting you
>> when you enter the wrong password.  What the user sees is "Socket Error",
>> not "Bad Password", which is almost impossible for them to diagnose.
> 
> Trying all available mechanisms is the correct behavior, as far as I am
> aware. See http://trac.adium.im/ticket/8108 for a realworld use-case of
> this, in which GSSAPI is tried, and, if it fails, the desired behavior
> is to attempt CRAM-MD5 or DIGEST-MD5 password-based authentication.

Right (there are also interoperability issues with some DIGEST-MD5
implementations, which mean that DIGEST-MD5 will fail and PLAIN
subsequently succeeds -- going forward, hopefully SCRAM will alleviate
these issues :) )

Anyway, draft-ietf-xmpp-3920bis section 6.3.5 on failure handling seems
to indicate that Adium's behavior is OK:

6.3.5.  Failure
...
   If the initiating entity attempts a reasonable number of retries with
   the same SASL mechanism and all attempts fail, it MAY fall back to
   the next mechanism in its ordered list by sending a new <auth/>
   request to the receiving entity.  If there are no remaining
   mechanisms in its list, the initiating entity SHOULD instead send an
   <abort/> element to the receiving entity.

~Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20100429/7c761cad/attachment.sig>