[JDEV] Security in Jabber server protocols

[jabber at msg.net]

> On the security front, I've been looking at the use of digital signatures a
> asymetric crytpography to improve trust relationships. The areas that affect
> what you bring up are;

There is certainly a lot of unused potential benefit from the OpenSSL library,
it should not take significant changes to the server code to improve the trust
model of the Jabber c2s and s2s protocols.

This is one area I plan to cover in my 'security' talk at JabberCon.
 

> 1) Client -> Server: The use of signed digital certificates which are signed
> by a known entity (possibly Jabber.com, and/or others), to verify the
> servers name, IP, and any other details in a similar was as TLS.

I'd like to see Jabber clients distributed with the jabber.org and jabber.com
public keys, and the easy ability to add additional keys and re-distribute
them. I operate a number of sets of private servers for which I have a need
to distribute the key to my userbase- from a few dozen to a few thousand users
who have a need for the key, using a variety of clients.

Easiest is to look towards web browsers and the OpenSSL project for standards.
 

> 2) Server -> Server: The establishment to a key bank (possibly distributed)
> in which jabber servers store their public keys, data then sent from server
> A to server B can be encrypted by Server A using it's private key, send to
> B, B can fetch A's public key from the key store, and decrypt the data. This
> would give not only server to server message security, but also verification
> of server A's identity.

3) Server -> client: The ability to have your jabber server sign and issue
individual 'client certificates', used by the server as part of the initial
SSL negotiation, to authenticate the end user, in addition to or in place
of a password.

 
> I'm also keen on developing the idea of using a Jabber server as a central
> authentication location so that 3rd party apps can make use of jabber for
> authenticating users.

Personally, I am strongly opposed to that idea, but don't let me stop you :-)

I'm putting my effort in this area toward having my Jabber server authenticate
new accounts and/or logins against an existing authentication service.  There
are so many other more mature strong authentication models, I do not see the
value in using Jabber instead of a 'standard' such as LDAP, Kerberos, etc.

 
> > One of my primary explorations focus on the area of security with Jabber
> > (my current impression being that things are Not Good(tm)).  For example,
> > there seems to be a built-in assumption that client's must trust their
> > server (a situation that seems obviously ripe for exploitation) and that
> > server's trust each other (a possibly worse assumption).  Pretty much
> > every man-in-the-middle and packet spoofing attack seems to be effective
> > against a Jabber server...  I noticed you're signed up for the security
> > JIG so I'd love to hear your thoughts on this topic and if you've been
> > thinking/looking at these issues.

It's not as bad as all that. The SSL implemenation in the Jabber server
has the ability to prevent one type of MITM attack- where a fake server
intercepts the client's connection. The missing piece is for clients to add
code to validate the certificate presented by the server against a pre-shared
certificate store (just like a web browser).  Trivial to implement in a
client which already makes use of the OpenSSL library.

IIRC, a client cannot spoof another user's identity on a packet to the server,
so the ability to perform packet-spoofing attacks depends on having a s2s
connection.  If you deploy a standalone server without s2s, and/or only permit
connections on 5269 with hosts you _truly_ trust, this risk is reduced.


Kevin Kadow
MSG.Net, Inc.