On Wed Sep 12 08:31:33 2007, Jonathan Chayce Dickinson wrote:
Or, alternatively, what I said before, is that the SSL/TLS be two
way, that
is both the client and the server present certificates (SASL
EXTERNAL).
Certificates are freely available from start.com, so that needn't
be an
issue for the client. We just need the mainstream servers, like
JAIM and J.O
to implement it: and then everyone will catch on.
Actually, it's still an issue. You've mostly passed the buck, rather
than solved anything. You're now encouraging attackers to concentrate
on the client machines, and obtain the authentication credential from
there. Moreover, you've made life much harder for the users, who now
have to keep a copy of their certificate everywhere.
This also runs along with the SPIMming issue from a while back. As
I said,
if a client is misbehaving you simply report it to the CA and get
the
certificate revoked. That would be a huge pain for SPIMmers, they
can make
accounts as they see fit, but not certificates.
I think this relies on several assumptions, some of which may not be
true.
1) You think that a spammer obtaining a new certificate is hard.
2) You think that a legitimate user obtaining a new certificate is
easy.
3) You think that the CAs are likely to be willing to revoke
certificates because of spamming.
4) You think that all XMPP servers will be willing to maintain an up
to date CRL from all CAs.
The juxtaposition of 1 and 2 seems fair, since spammers would need
lots of them, but if you recall, spammers have effectively infinite
computational resource and plenty of experience of electronic-borne
fraud. I suspect it would be significantly easier for spammers to
obtain an X.509 cert than Aunt Tillie.
In the case of a SPIMmer having their own server, we could try
something
like the following (the server NEVER authenticates itself with other
servers, rather, the client certificate is used for that):
* John connects to j.o with his certificate.
* He wants to send a message to Fred in jaim.org.
* Jaim.org sends a SASL EXTERNAL request to j.o, which forwards it
to John.
* John sends his certificate to j.o, which then forwards it to
jaim.org.
* Jaim.org checks his certificate against his CA.
* John, and not j.o, is now authenticated on Jaim.org.
No, that's not how SASL EXTERNAL works - it's not a magic silver
bullet, it just asserts that you want to authenticate using the
credentials you established via a lower layer - usually TLS.
For end-to-end authentication, Jaim.org would have to send a
challenge to John (via j.o), which would be signed with John's
private key, and sent back with John's X.509 certificate. There's a
lot of data flying about there, as well as significant cryptographic
"heavy lifting". And it gets worse, since John now doesn't know if
the challenge really came from Jaim.org, or someone else who's
playing the man in the middle, ready to authenticate and then hijack
the session. So John actually has to sign every stanza he sends,
instead.
This latter technique - signed operations - is used in another
protocol that passes operations along a chain of servers, namely
X.500, the OSI directory service. (LDAP is a highly simplified form
of X.500, with all the particularly hairy bits like this removed).
Signed operations are, I believe, generally only used within an
administrative domain. And only by exceedingly paranoid people. (For
extra marks, you need to ensure that stanzas cannot be replayed, of
course. An exercise for the reader.)
Besides which, you probably want the servers to authenticate anyway -
a rogue server is simply not worth talking to, after all. Verifiable
servers are one thing that XMPP has over SMTP right now. It's worth
keeping that feature, it's very difficult to put back in later.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
