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

[Peter Saint-Andre]

On 8/30/11 2:37 AM, Alexander Holler wrote:
> 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. ;)

Dialback doesn't use the SASL <auth/> element.

>>> 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. ;)

In fact, a server *could* announce SASL mechanisms after authentication
(if it allowed re-authentication of some unspecified kind). But in that
case it shouldn't close the stream if the client tries to authenticate
again.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/