[jdev] sasl error on multiple <auth/>?

[Alexander Holler]

Am 29.08.2011 18:51, schrieb Peter Saint-Andre:
> On 8/25/11 8:57 AM, Alexander Holler wrote:
>> Hello,
>>
>> I have a similiar question as the one before. ;)
>>
>> What should a server do when he receives an<auth/>  after a successfull
>> negotiation?
>
> So SASL negotiation is complete but the client or peer server sends new
> SASL<auth/>  elements? Why would it do that (other than being buggy)?
> There is no re-authentication option in XMPP.

Dialback explicit allows it. ;)

>> RFC 6120 6.4.2 only defines what happens when the authentication isn't
>> completed but not what happens when the authentication was completed.
>>
>> Maybe a<failure/>  with<malformed-request/>.
>
> I'd say just ignore the new<auth/>  element, since the entity is already
> authenticated.
>
>> Or should the server
>> proceed and throw away the authentication done before?
>
> No. There's no re-authentication option.
>
>> It's easy to fool clients into doing that, just announce<mechanisms/>
>> in<features/>  when the stream got restarted after successfull
>> authentication. That itself isn't the correct thing to do, but happens. ;)
>
> Why design around buggy servers?

Hmm, I wouldn't say it's a bug in the server if he still announces 
<mechanisms> in features when the stream got restarted after authentication.
But I have to admit that RFC 3620 (and 6120, but not that verbose) 
already said that the feature list is a kind of a state machine and not 
a list of features of the server. I would prefer to see the feature list 
as a list of features of the server and not the actual stream (or state 
of), but the RFC don't. So I accept that it is a bug when announcing 
<mechanisms> after the stream got negotiated. ;)

Regards,

Alexander