Securing XMPP

I have to agree with Peter StAndre, the state of secure XMPP standards is a joke! I will immediately dismiss the actual RFC 3923, which is kind of trying to force a square plug into a circular socket. Look like there is a strong faction at IETF in the security working group knowing only one way to do end to end encryption. Take it or leave it…  As to the usage of PGP, I have always wondered why this had not taken up more. Maybe something to do with the disdain found in enterprise against this technology. And finally the proposal for encrypted sessions, which is a thorough work on the subject by several authors. This last proposal in my opinion suffers from its very wide scope.

You will notice that I did not say complexity. Encryption is a complex subject. I have myself taken up writing a encryption JEP that was published as JEP-0102. Probably too early, and the XML signature and XML encryption were not entirely finalized at W3C. I nevertheless based my proposal on these standard to come. In essence, the proposal was very similar to JEP-0116, without the added management of long term keys. Same use of Diffie-Helmann key negotiation, same reference to IKE, use of XMLsig and XMLenc to represent the encrypted stanza. The main difference was its simplicity. Instead of managing long term keys, keying material was created for each encrypted session, and discarded afterwards. This JEP has been implemented in commercial clients, and has been working flawlessly.  

This bring again the statement that we’re not earth to suffer from the use of technology, but to use technology at providing solutions. Encryption would be a worthy addition to XMPP if we could come up with an easy to implement standard, and above all a transparent usage. One click on the padlock of the user interface must be all is needed to toggle encryption on/off. Actually the GUI part is really the easy bit… We may be better off revisiting the requirements set forward when writing JEP-0116 and come up with something applicable in 80% of the cases. And I am certain we can do it without compromising any of the security requirements. I believe we would also gain better acceptance by using the W3C recommendations for the encryption and signature framework.

Using XMLsig and XMLenc will not lower the original security requirements described in the JEP-0116. XMLsig and XMLenc provide a framework to encrypt and sign XML documents. They do not impose the keying material, nor the algorithms to use. These have to be provided by another process, either through a Diffie-Helmann key exchange, or through the use of asymmetric PKI keys. When the parties have agreed on a particular security context (i.e. crypto material and algorithms) they will use it by following the process described in XMLsig to sign and in XMLenc to encrypt XML.

The perfect forward secrecy is not linked to the encryption or signature method. PFS is just the statement that the ephemeral key negotiated during the key agreement will not be compromised if the long term secret keying material is compromised. In short, it is the way you use your long term secret, your random parts and the way you derive your ephemeral session key which will define PFS. This is entirely done outside XMLsig and XMLenc, which are only “using” the key material.

The repudiability is the notion of denying that an action occurred. If the ephemeral session key is short lived and discarded at the end of the session, it becomes impossible to prove the stanza has been exchanged from a cryptographic standpoint, in the absence of a stanza’s signature. Enforcing stanza signature will on the contrary provide non-repudiability, i.e. a proof of the stanza having been sent.

A little trickier, the “canonicalization” is only a way to standardize how the XML must be prepped in order to provide a reproducible XML when verifying signatures. In XMLsig and XMLenc, you need to use a canonicalization method, so different parties agree that the XML has not been tampered with. The W3C has standardized generic canonicalization, but very much related to the development of the web services framework. XMLsig and XMLenc will work with any canonicalization method. We may have to provide an XMPP specific canonicalization method if we find difficult to use the standard W3C methods.

Technorati Tags: XMPP, Jabber, Security, Trust, Antecipate