[Standards] XMPP and end to end PKI

[Dave Cridland]

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:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade