[Standards] Re: [Standards-JIG] UPDATED: XEP-0178 (Best Practices for Use of SASL EXTERNAL)
stpeter at jabber.org
Fri Jan 26 21:26:33 UTC 2007
Matthias Wimmer wrote:
> Hi Peter!
> Peter Saint-Andre schrieb:
>>> 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.
> Sorry, I wrote "server" but did mean "s2s-client". If for temporarily
> reasons the destination-server does not accept the certificate of the
> connecting entity (e.g. problems allocating memory to verify the
> certificate), the connecting entity would not try to use SASL EXTERNAL
> again for the next connection, no?
If it remembers, perhaps. But I don't think the "s2s-client" needs to
remember what happened the last time. When was the last time? Was it 20
seconds ago, 20 minutes ago, 20 hours ago? And I think in this case the
"s2s-server" would return <temporary-auth-failure/> for SASL so it would
make sense for the "s2s-client" to try SASL EXTERNAL again the next time.
>> 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.
I'm not sure how this should be handled. In Section 6.2 of RFC 3920 we
say that the "s2s-server" should allow retries, but I don't know if it's
right to allow retry with a different SASL mechanism. If we did that, we
might have a situation like this:
1. "s2s-client" tries SASL EXTERNAL but receives <failure/>
2. "s2s-server" allows retries
3. "s2s-client" sends <auth mechanism='foo'/>
4. Does "s2s-server" return <challenge/> (allowing retry with the
non-EXTERNAL mechanism) or <invalid-mechanism/> or <not-authorized/> or
something else (not allowing retry with the non-EXTERNAL mechanism)?
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards