SASL External authentication support for C2S

Bug #405233 reported by Michal Witkowski
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Jabberd
Medium
Tomasz Sterna

Bug Description

I've created a patch for jabberd2 which adds support for C2S SASL External authentication (according to XEP-0178)

A compatible client library implementation can be found here: http://pyxmpp.jajcus.net/trac/ticket/35. I've added the functionality and tested it against the implemented C2S support.

What has been added:
1. Client CA chain verification for both TLS and SSL connections to C2S
2. Client CA chain names reporting to client connections (so they can pick a correct certificate)
3. Client certificate id-on-xmppAddr field extraction. A certificate can contain up to five such fields. If the client doesn't provide authzid information (puts "=" in their <auth> stanza), the first field is chosen.
4. Fixed parsing of SASL External information. S2S will presumably also benefit from this.

What's missing:
1. Support for wildcards in S2S SASL External matching.
2. Support for dNSName fields in server certificates in S2S connections.
3. Testing if it doesn't break S2S SASL External authentication (it shouldn't but who knows?)
4. Extensive testing with other clients and servers. I've tried testing against Spark's (http://www.igniterealtime.org/projects/spark/index.jsp) SVN, but I couldn't get it to work. Presumably, because Spark expects the JID to be in CommonName instead of the dedicated id-on-xmppAddr field.
5. Support for Certificate Revocation Lists. I have absolutely no idea how to do this.

How to test it:
1. Generate a temporary CA.
2. Generate a client certificate with the id-on-xmppAddr field (http://webview.jabberd.org/cgi-bin/viewvc.cgi/trunk/jabberd14/selfsigned.cnf?view=markup&pathrev=1399).
3. Put the CA certificate in cachain options in c2s.xml
4. Set verify-mode to 7, enable SASL external in c2s.xml
5. Get pyxmpp, apply the above patch.
6. Run the the testing.py script.

Revision history for this message
Michal Witkowski (neuro-o2) wrote :
Revision history for this message
Michal Witkowski (neuro-o2) wrote :

Ok, a new patch version comming up.

The id-on-xmppAddr parsing in the previous version didn't conform to RFC3920bis. The field was expected as part of distinguishedName (DN) and not x509v3's extension field subjectAltName. In the following patch, id-on-xmppAddr is taken from the appropriate location, along with dNSName and CommonName (for badly-written clients).

Revision history for this message
Tomasz Sterna (smoku) wrote :

Merged in SVN r890.
Thank you for your submission. :-)

Changed in jabberd2:
assignee: nobody → Tomasz Sterna (smoku)
importance: Undecided → Medium
Revision history for this message
sander (s-devrieze) wrote :

Is there an accessible jabberd2 server running SVN r890 or higher? We want to test client certificates in Coccinella SVN r2797 (see bug #240603).

Revision history for this message
Tomasz Sterna (smoku) wrote :

chrome.pl is always running SVN jabberd2

Revision history for this message
calamar (cal-rhizomatik) wrote :

We have a demo server at xmpp.rhizomatik.net running jabberd with this patch. (note: I commented out the CRL checking). A tutorial and some utils for the cert generation can be found here, as long a debian lenny backported package:

https://rhizomatik.net/myceliafoafssl/wiki/XmppFoafSSL . There is also a django app that handles user registration and cert generation (a bit insecure now, since the client key generation is done server side).

Also, the trunk version of gajim also supports sasl-external now: http://trac.gajim.org/ticket/5704

Revision history for this message
Michal Witkowski (neuro-o2) wrote :

Hi,

I've fixed (or I think I've fixed) the problem with CRLs.
The CRL should be located in the cachain PEM file along with the CA certificate.
In the previous patch CRL checking was forced. Certificates of connected clients were verified against the CRL stored in cachain. When a cert was marked revoked on the CRL, client certificate verification failed and connection was broken. If it wasn't on the list and was valid, connection was granted.

However, the problem with OpenSSL's CRL verification is that the CRL must exists. So if you had a cachain file only with the CA certificate sans the CRL, _ALL_ verification failed with X509_V_ERR_UNABLE_TO_GET_CRL.

In this patch, I make a special case to ignore the error.

Revision history for this message
Tomasz Sterna (smoku) wrote :

Merged in r892.
Thanks for your submission.

Changed in jabberd2:
status: New → Fix Committed
Revision history for this message
Tomasz Sterna (smoku) wrote :

Fixed in 2.2.12 release.

Changed in jabberd2:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.