[Standards] Re: [Standards-JIG] UPDATED: XEP-0178 (Best Practices for Use of SASL EXTERNAL)

Mridul mridul at sun.com
Fri Jan 26 18:44:50 UTC 2007


Peter Saint-Andre wrote:
> Matthias Wimmer wrote:
>> Peter Saint-Andre schrieb:
>>>> The other thing is if EXTERNAL has been offered (i.e. TLS was able to
>>>> verify the authentication identity), but EXTERNAL failed to authorize
>>>> (i.e. the peer tried to authorize as someone he is not allowed to
>>>> authorize as), it might be considered as a final authorization failure
>>>> causing a stream-close. I am not sure about that one yet.
>>>
>>> I guess in that case the auth would fail and the client would need 
>>> to retry with a different mechanism next time?
>>
>> Not sure. That would mean, that if SASL EXTERNAL fails for 
>> temporarily reasons, that a server stops using it for future 
>> authentication attempts.
>
> No, I mean the server would offer SASL EXTERNAL the next time but the 
> client would try a different mechanism. Alternatively, the server 
> could return a SASL failure for EXTERNAL but not close the stream, in 
> which case the client could try another mechanism. The SASL spec has 
> some text about the number of retries a server might allow, and I'll 
> look at that again. But right now I am deeply involved in cleaning up 
> the text about server dialback in rfc3920bis (don't worry, I'm making 
> no modifications to the logic, just better examples and more error 
> flows!).
>
> Peter
>

Hi,

Actually this is slightly relevant to s2s case also - and maybe an impl 
note in some xep/bis spec might be a good idea.
That is, if tls is not required and it fails - how is the server 
supposed to behave while retrying.
Similarly, if tls succeeds but sasl external fails - how is the server 
supposed to behave while retrying.

Regards,
Mridul




More information about the Standards mailing list