[Standards] Re: [Standards-JIG] UPDATED: XEP-0178 (Best Practices for Use of SASL EXTERNAL)
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.
> 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...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards