[JDEV] Security in XMPP/Jabber: some questions

[David Waite]

Mattias Campe wrote:

> Hi,
>
> yesterday, I did a presentation of Jabber at my university (actually 
> it was a presentation for my RSS headlines jabber component) and they 
> asked me how secure Jabber was. Unfortunately I couldn't answer that 
> question very good. As I still need to give in my résumé, I would like 
> to have some more information on this one.
>
> First, I've done some more research myself, but I still have some 
> questions. From DJ Adams book, I know that there are 3 methodes to 
> authenticate, namely plaintext, digest and zero knowledge. Is it 
> correct that most clients use digest by default? 

Currently, althought the XMPP working group has put effort into also 
using SASL.

> Then there is SSL (Secure Socket Layer?) that you can use to encrypt 
> the whole stream, am I correct? Still, I don't see that clients use 
> this by default. What is the reason for this? I've read somewhere that 
> it could  be that this causes problems on some proxy servers, is this 
> true? And does SSL provide end-to-end security or only 
> client-to-my-own-server security? 

SSL is expensive, and there isn't always an easy way to support it for a 
particular client implementation. Also, SSL only secures a segment of 
the transport, it is not end-to-end and thus there are no security 
guarantees either that the traffic will or will not traverse the network 
at some point in clear text, and also no way to verify the identities of 
all the other intermediate routes so that you can decide if you want to 
trust them.

> Other two known ones are PGP and GnuPG, what's the difference between 
> those two? Is a client supporting PGP compatible with one supporting 
> GnuPG? How does this actually work? Is it encrypted at the client 
> side, decrypted at the server side, to know the to address and then 
> encrypted again to send it to the "other side"? What if the other side 
> doesn't know about PGP, how those this side knows about that lack of 
> feature? 

OpenPGP is what GPG supports, and there is existing end-to-end 
encryption based on this. You do not have protection outside of the 
payload, and this sort of asymmetric encryption (with public and private 
keys) is much more computationally expensive in terms of bandwidth usage 
processor usage - but at least the processing is done on the ends of the 
network rather than the intermediate routes.

Normally OpenPGP support is indicated by signing the presence status. 
The actual signed data is meaningless (it would be simple to forge by 
just sending a previous signed block), but you can get the key id used 
to sign the data from the signature block, and use this to retrieve the 
key and start using it based on the level of trust in it.

> I read in "The Instant Messaging Standards Race: Comparing XMPP/Jabber 
> and SIP/SIMPLe" from Jabber Inc. sth. about SASL (Simple 
> Authentication and Security Layer) and TLS (Transport Layer Security). 
> What is the principle of those two? 


TLS is basically the standardized SSL. SASL is the IETF authentication 
standard. The main point of SASL is that it provides a framework for 
adding new authentication mechanisms, but also saves all the effort of 
designing an authentication system and verifying the authentication 
system is secure - you can just use an off-the-shelf library.

> What is meant by "end-to-end" vs "hop-to-hop" encryption, that with 
> the first one even the server can't read what is in the message? But 
> how do they know then where to send the message? 

end to end means that only the sender and recipient require knowledge of 
how to decrypt the message; hop-to-hop means the transport is secure, 
but the intermediate parties (the servers) can see the contents. PGP is 
used for end-to-end, while SSL/TLS is hop-to-hop.

I've always thought of the SSL choice being one that the administrator 
makes, not one that the user makes. If you can connect to a server with 
both a straight connection and with SSL, there is little reason to 
connect _with_ SSL, because the administrator already has made the 
policy decision that information is allowed to travel across the network 
in the clear. SSL just uses more processing power, memory, and bandwidth 
in this case. Just my opinion, though :-)

> Will jabberd2 support more security than the current jabberd server? 

It already does. :-)

-David Waite