[Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
thijs at xnyhps.nl
Thu Aug 15 19:47:47 UTC 2013
On 20 jun. 2013, at 05:14, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> >> So when we wrote XEP-0178 this was fairly vague, but the upshot
> >> is that it probably needs some revision:
> >> 1) The right way to specify the jid you're expecting to become is
> >> by using the from attribute of the stream. This is most
> >> especially true for servers.
> > I'm still not sure I understand 10(c), though. Does "the address
> > specified during SASL negotiation" refer to the "from" attribute on
> > the <stream>?
> IMHO that would indeed be the 'from' on the initial stream header. It
> would be good to clear that up in the spec, eh?
There's one more point I want to make about this, not exactly related, but close
enough to continue this thread.
The security considerations section of XEP-0178 states only:
"This document introduces no security considerations or concerns above and
beyond those discussed in RFC 6120 and RFC 6125."
While that may be true, there's one thing that might warrant some emphasis:
Both the server's and the client's certificate are sent in plain during the
handshake. This means that any id-on-xmppAddr attribute, common name field or
any other personal info on the certificate will be visible to any passive
observer of the stream. Every client I've used tries to avoid leaking your
identity before TLS is active (no 'from' attribute on the initial stream) and
this could break that.
Even when a user is using a certificate with no personally identifiable
information at all, just by looking at the public key an observer could try to
correlate different connections to the same account.
In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS renegotiation
as a way to protect the client's certificate if it's known to be private. I
guess this would work, though I'm not sure how well-supported that is.
I think it would be good if XEP-0178 at least mentioned that the certificate is
sent in plain and pointed to §5.1.3 for a workaround.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Standards