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

Peter Saint-Andre 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)?


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070126/ef0d1f2c/attachment.bin>

More information about the Standards mailing list