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

Peter Saint-Andre stpeter at jabber.org
Thu Jan 25 22:52:03 UTC 2007

Still processing messages about SASL EXTERNAL...

Matthias Wimmer wrote:
> Hi Dave!
> Dave Cridland schrieb:
>> 1) The server should authenticate the user before offering EXTERNAL.
>> Offering EXTERNAL implies that it's already been authenticated by some
>> unspecified means. Failure to authenticate via a certificate simply
>> means that the server doesn't offer EXTERNAL - it shouldn't close the
>> connection simply due to not recognizing the certificate, it's
>> essentially the same situation as not having a certificate at all.
> Exactly - I am trying to explain that for a long time now.

Yes I have finally fixed that in my working copy. I'll push out a new 
version of the spec real soon now.

>> 4) Alexey spotted that the document's recommended course of action if
>> the EXTERNAL mechanism fails is to close the stream - there's no need to
>> this, the client might be able to authenticate using a different mechanism.
> If TLS certificate verification fails, I agree with you, that there is
> no reason to close the stream - just don't offer EXTERNAL (as you
> proposed) and check if other authentication methods are available. 

For clients, yes. It may be different for servers.

> Only
> if no other authentication methods (either SASL, JEP-0078, or Dialback)

Officially, dialback is not an authentication mechanism, it provides 
weak identity verification only. :-)

> are left (or are not acceptable due to local security policy settings)
> you should close the stream.
> 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?


-------------- 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/20070125/ec8daca2/attachment.bin>

More information about the Standards mailing list