Authentication: Kerberos or SSL?

I'm in the "pre-design" phase (if there is such a thing!) for a Java EE app that will use a Swing box on the client end and implement components for both web and server tiers.

I'm instantly presented with some technology choices and have been reading up on the differences between how Kerberos and SSL work. One area that I have not been able to find any answers to has been the subje开发者_如何学Cct of how to choose between Kerberos or SSL. In other words, how do you tell when it is appropriate to use either protocol?

Let's assume that the Swing client isn't bound by a particular transport (UDP, TCP or otherwise) and could use either/any. How does one choose between which of these two is a better match for their application?

Thanks!

and suddenly (several months later) a wild Sys Admin appears...

I'm going to have to be a voice of dissent on this. The notion that you would ever establish a PKI without a CA is incredibly absurd. You have to maintain the integrity and performance of the PKI by streamlining the creation process. You have to create and store the certs somewhere, where is that going to be? Boom, you have a CA. Any decent PKI is also going to require a CRL be maintained, is the administrator supposed to just write that by hand? You can also forget about having different types of 509's as the overhead of maintaining that by hand would blow-your-mind-wide-open-and-turn-it-into-grey-slurry.

I suppose you could just manually create the tickets with openssl's CLI and just ftp them to the remote clients, but that gets to be a HUGE hassle for deployments of appreciable size. Essentially, if your deployment is so small that generating the certs by hand (repetitive entering of information and all) and then just not worrying about a CRL is a reasonable plan, you don't need an advanced authentication system at all. Something along the lines of TLS+LDAP (one server cert for confidentiality and not authentication) is more appropriate.

Ok, now that I've cleared some misconceptions, let's actually answer your question: When would you want to use SSL over Kerberos for authentication? x509-based authentication is an incredibly nebulous beast, mostly on account that most people (like Michael-O above) don't realize that SSL work specifically because it's authenticating users. There are a few FTP programs that I know of that authenticate that way, middleware employs it...sometimes (which sounds close to your use case from the java talk), and vpn clients/gateways often authenticate with SSL certs.

Usage of SSL would imply the PKI I spoke of up there, which would work great if your use case involves confidentiality. DoD is a good example of an enterprise that makes extensive use of PKI for functions outside of authentication. In that context, supposing all relevant client programs support x509 authentication makes a lot of sense. It's still an exotic set up, and you would still have to figure out how the end-users will "present" their SSL credentials to the system (client configuration, smart cards, etc) but it would fit together nicely. Besides the odd fit, kerberos authenticates by way of a temporary ticket, whereas SSL certs typically last a long time (which is why a CRL is required) meaning that if the never-changing key is factored on one cert the attacker will have several months of free rides before they have to find a new cert, versus kerberos where they only have it for a day and that's only if the ticket isn't destroyed.

All other cases should use Kerberos authentication when possible. It provides the right layer of security and is actually designed as a large network authentication system, which is why you have things that are hard to duplicate with SSL (like authenticating as a service instead of a regular user) and just plain work for their intended purpose. Your use cases are always going to need to take into account existing infrastructure which is probably going to be kerberos-oriented, sometimes LDAPS-oriented, but almost never x509 authentication-oriented. In other words: whatever you're writing is MUCH more likely to be running in a kerberos infrastructure already, so you might as well plug into that somehow. You'll also benefit more from administrator familiarity with Kerberos-as-authentication than 509-as-authentication. The con on this is that confidentiality outside of the ticket is kind of a joke. NFSv4 has some weak DES (and no I didn't mean 3DES even) encryption that it (somehow) relates to the kerberos ticket but it does authentication and that's basically all it does.

I'd like to see some of x509's flexibility combined with kerberos-style infrastructure (recognition of services and the "one time pad" aspect of having a soon-to-expire ticket) incorporated into a solution that was more widely implemented than x509 is now, but at this stage it's mostly day-dreaming.

Summary:

x509 is good if infrastructure requirements won't be a problem and you'll be using PKI for other stuff anyways, but might be duplicating effort needlessly otherwise or if the deployment is probably going to have a kerberos infrastructure anyways.

Kerberos is a similar but better authentication scheme that is more widely used/understood but won't help you with PKI at all, you get authentication, and that is it.

Comparing Kerberos and SSL/TLS doesn't make sense.

• Kerberos is an authentication protocol.
• TLS is a protocol for securing the communication between two parties, which relies on mechanisms for authentication and encryption. How they work depend on the chosen cipher suite. Although most usages of TLS (e.g. HTTPS) use X.509 certificates, in which case you're likely to use a PKI for the authentication of the remote party, Kerberos cipher suites can also be used. Few TLS stacks support these Kerberos cipher suites as far as I'm aware (Java does).

It doesn't have to be one or the other. For example, even if you're using SPNEGO (Kerberos) HTTP authentication, it often makes sense to secure the transport using TLS (often with an X.509 certificate on the server side, verified via a PKI). If not, the SPNEGO tokens exchanged in the HTTP headers guarantee the authentication, but the rest of the HTTP messages could have been modified by an attacker.

This could be useful:

http://www.faqs.org/faqs/kerberos-faq/general/section-31.html

Consider that any solution involving Kerberos will be more complicated than SSL because it requires an additional, third component, the Authentication Server, which must be managed and administered (e.g. MS Active Directory) whereas SSL is simply a client/server protocol.

You are mixing stuff. Kerberos is an authentication protocol, SSL ist encryption. Kerberos is the way to go if you are in a corporate environment.

Edit: Kerberos can also encrypt your data traffic transparently. No need for SSL certiticates.