Security & Authentication: SSL vs SASL

Question

My understanding is that SSL combines an encryption algorithm (like AES, DES, etc.) with a key exchange method (like Diffie-Hellman) to provide secure encryption and identification services between two endpoints on an un-secure network (like the Internet).

My understanding is that SASL is an MD5/Kerberos protocol that pretty much does the same thing.

So my question: what are the pros/cons to choosing both and what scenarios make either more preferable? Basically, I'm looking for some guidelines to follow when choosing SSL or to go with SASL instead. Thanks in advance!

Answer 1

It's quite difficult to compare SSL/TLS and SASL, because SSL/TLS is a communication protocol, whereas SASL is a framework, integrated with other protocols. (In fact, you can use both at the same time in some circumstances.)

In addition, you're mentioning Kerberos, which is indeed an authentication protocol (which can be used with SSL/TLS or SASL or independently both). Your question seems to suggest that whether or not to use Kerberos one of the main sub-problems you should choose first.

SASL is essentially an indirection layer to allow for pluggable authentication systems and data security in existing application protocols (e.g LDAP, SMTP, Subversion, ...), although these protocols need to be aware of this extension (e.g. SMTP auth). Whether and how it provides secure authentication and data encryption depend heavily on what underlying mechanism is used within this framework. Here is an example from the svnserve documentation: "The built-in CRAM-MD5 mechanism doesn't support encryption, but DIGEST-MD5 does". If you want to use Kerberos with SASL, you will need another level of indirection: GSS-API (which is most commonly used with Kerberos, but can also allow for other mechanisms). (Note that GSSAPI in the context of SASL seems to imply Kerberos anyway, unlike its GS2 successor.)

The general goal of SSL/TLS is to secure the communication (integrity and confidentiality) between a client and a server. The client should always check the identity of the SSL/TLS server, and it provides mechanisms for server to check the identity of the client too. What it can do also depends on how it is configured. SSL/TLS is most commonly used with X.509 certificates: that's how a browser can check the identity of an HTTPS server. Servers can also be configured to request the client to use a certificate to identify themselves (client-certificate authentication). However, if you want to use Kerberos, you can use TLS Kerberos cipher suites. This is much less common, but they are implemented in the JSSE.

Its implementations usually provide APIs similar to what you get with plain TCP connections: in Java, once configured, you can more or less use an SSLSocket as you would use a plain Socket. This doesn't require specific awareness by the protocol on top of the socket, although some protocols have explicit commands to switch to SSL/TLS from a plain connection (Implicit v.s. Explicit SSL/TLS). It can also provide authentication. In Java, the JSSE is the default SSL/TLS implementation, which gives you access to SSLSocket (or SSLEngine if you're brave enough).

You might want to read "When to use Java GSS-API vs. JSSE", which is similar to "SASL vs. SSL/TLS" (although it doesn't seem to have been updated for a while, since the JSSE does support Kerberos cipher suites now, at least since Oracle Java 6).

I'll admit I know less about SASL than about SSL/TLS, but doing data encryption via SASL sounds like it's going to be more work. It doesn't seem to have certain SSL/TLS features such as the Perfect Forward Secrecy offered by EDH cipher suites. There is an example that uses SASL with GSSAPI (Kerberos here) in the JGSS tutorial: you need to wrap/unwrap the data explicitly, which you wouldn't have to do when using SSLSockets.

I think your main concern should be to decide which authentication mechanism you want to use in the first place: Kerberos, X.509 certificates, or something else. This will have more impact on your overall architecture, and both can be used with SASL and SSL/TLS (more so if you use SASL with an EXTERNAL mechanism, when on top of an SSL/TLS connection).

• Kerberos is very centralised. The client will need to be able to contact the KDC to authenticate, in addition to being able to contact your application server. The clients will also need to be configured to use that KDC. From a user's point of view, they can use passwords.
• X.509 is more decentralised. However, you may need to deploy a Certification Authority (or use a commercial one) for your user certificates. Users will need to be given certificates and private keys, which some might find too complex.

JAAS comes into it because it's the general Java framework for dealing with authentication and authorisation. It's very closely linked to the notion of security managers. It gives you the notion of Subject and Principal. This isn't directly linked to the protocols or the communication, but rather to the way you model authentication and authorisation within your application. (It gives you a standard set of classes to do so.)

(I'd generally suggest to go through the Java reference documents that mention the words you're after: JGSS, SASL, ..., although they're not necessarily easy to read.)