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

Peter Saint-Andre stpeter at jabber.org
Tue Nov 28 23:35:58 UTC 2006


I'll fix up the spec soon to reflect this thread...

/psa

Dave Cridland wrote:
> On Tue Nov 28 05:36:59 2006, XMPP Extensions Editor wrote:
>> Version 0.4 of XEP-0178 (Best Practices for Use of SASL EXTERNAL) has
>> been released.
> 
> I read this, and a couple of things stand out for me - sufficient for me
> to ask Alexey Melnikov to read it through. I've re-interpreted some of
> his comments, and added some of my own. Mistakes are still my own. :-)
> 
> 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.
> 
> 2) The <auth/> element has to contain some character data, although this
> would typically be an empty response - "=" - for clients, and probably
> servers too. RFC4422 essentially says that clients shouldn't make any
> assumption about how the server will bind an authorization identity, so
> in theory there's an argument for the client explicitly specifying its
> JID here. Alexey commented here that "But I am not sure this should be
> mentioned at all".
> 
> 3) Resource binding doesn't authorize, as others have pointed out.
> 
> 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.
-------------- 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/20061128/820e26e8/attachment.bin>


More information about the Standards mailing list