Difference between SSL and Kerberos authentication?

Question

I am trying to understand what's the actual difference between SSL and Kerberos authentications, and why sometimes I have both SSL traffic and Kerberos. Or does Kerberos use SSL in any way?

Anyone could help? Thank you!

Solution 1

SSL uses public key cryptography:

1. You (or your browser) has a public/private keypair
2. The server has a public/private key as well
3. You generate a symmetric session key
4. You encrypt with the server's public key and send this encrypted session key to the server.
5. The server decrypts the encrypted session key with its private key.
6. You and the server begin communicating using the symmetric session key (basically because symmetric keys are faster).

Kerberos does not use public key cryptography. It uses a trusted 3rd party. Here's a sketch:

1. You both (server and client) prove your identity to a trusted 3rd party (via a secret).
2. When you want to use the server, you check and see that the server is trustworthy. Meanwhile, the server checks to see that you are trustworthy. Now, mutually assured of each others' identity. You can communicate with the server. 2

Solution 2

While Kerberos and SSL are both protocols, Kerberos is an authentication protocol, but SSL is an encryption protocol. Kerberos usually uses UDP, SSL uses (most of the time) TCP. SSL authentication is usually done by checking the server's and the client's RSA or ECDSA keys embedded in something called X.509 certificates. You're authenticated by your certificate and the corresponding key. With Kerberos, you can be authenticated by your password, or some other way. Windows uses Kerberos for example, when used in domain.

Keep in mind: Recent versions of SSL are called TLS for Transport Layer Security.

Solution 3

To put simply, Kerberos is a protocol for establishing mutual identity trust, or authentication, for a client and a server, via a trusted third-party, whereas SSL ensures authentication of the server alone, and only if its public key has already been established as trustworthy via another channel. Both provides secure communication between the server and client.

More formally (but without getting into mathematical proofs), given a client C, server S, and a third-party T which both C and S trust:

After Kerbeos authentication, it is established that:

• C believes S is who it intended to contact
• S believes C is who it claims to be
• C believes that it has a secure connection to S
• C believes that S believes it has a secure connection to C
• S believes that it has a secure connection to C
• S believes that C believes it has a secure connection to S

SSL, on the other hand, only establishes that:

• C believes S is who it intended to contact
• C believes it has a secure connection to S
• S believes it has a secure connection to C

Clearly, Kerberos establishes a stronger, more complete trust relationship.

Additionally, to establish the identity of S over SSL, C needs prior knowledge about S, or an external way to confirm this trust. For most people's everyday use, this comes in the form of Root Certificates, and caching of S's certificate for cross-referencing in the future.

Without this prior knowledge, SSL is susceptible to man-in-the-middle attack, where a third-party is able to pretend to be S to C by relaying communication between them using 2 separate secure channels to C and S. To compromise a Kerberos authentication, the eavesdropper must masquerade as T to both S and C. Note, however, that the set of trusts is still unbroken according to the goal of Kerberos, as the end-state is still correct according to the precondition "C and S trusts T".

Finally, as it has been pointed out in a comment, Kerberos can be and has been extended to use SSL-like mechanism for establishing the initial secure connection between C and T.

Solution 4

In short:

Kerberos usually does not encrypt transferring data, but SSL and TLS do.

"there are no standard APIs for accessing these messages. As of Windows Vista, Microsoft does not provide a mechanism for user applications to produce KRB_PRIV or KRB_SAFE messages." - from http://www.kerberos.org/software/appskerberos.pdf

In opposite, SSL and TLS usually do not transfer and proof Yours Windows domain login name to the server, but Kerberos does.

Solution 5

A short answer: SSL and Kerberos both use encryption but SSL uses a key that is unchanged during a session while Kerberos uses several keys for encrypting the communication between a client and a client.

In SSL, encryption is dealt with directly by the two ends of communication while in Kerberos, the encryption key is provided by a third party - some kind of intermediate - between the client and the server.

View more solutions

Comments

[Bruno]

Presumably, by "SSL authentication" you mean "PKI-based authentication via X.509 certificates, as it often happens in SSL/TLS". SSL doesn't strictly depend on X.509 certificates. See stackoverflow.com/questions/4878018/…

[Channa]

secureblackbox.com/kb/articles/6-Kerberos.rst

[Vagnerr]

Kerberos can use public key cryptography for its session keys. The standard was extended from the shared key mechanisms in 2006 see ietf.org/rfc/rfc4556.txt for more details

[Draemon]

SSL is perfectly capable of establishing the client's identity using client certificates.

[Chris]

I guess I was talking about the older Kerberos protocol. And another point would be to make a distinction about how in SSL you're vouching for yourself (via public/private key), whereas in Kerberos, even with PKC for session keys, the server is still vouching for you.

[Eugene Mayevski 'Callback]

This is not exactly so - the key can be changed on-the-fly in TLS (this is often called re-keying).

[Eugene Mayevski 'Callback]

First of all, SSL does not require TCP. It can run over any transport providing that the transport guarantees delivery, and there's DTLS which is slight modification of TLS to run on UDP. Next, SSL allows authentication using not only certificates, but passwords, openpgp keys etc.

[Bruno]

In addition to what @Eugene said, there are Kerberos-based cipher suites in TLS too.

[IAmYourFaja]

I know this is an old question, but I've been struggling trying to figure out a "best practices" set of guidelines to use when choosing SSL vs Kerberos. This answer is, IMHO, the best answer not only to this question but the best answer Google pulled back. Period. Kudos.

[Tom Kludy]

It's clear how SSL client certificates can establish the identity of the client machine, but it's not clear how they can establish the identity of the client user. For example if the user picks up a different device, or connects via double-hop to a service. Kerberos does that however, in a pretty low-friction manner.

[Andy Song]

To me, the root CA is the 3rd party. So it is still similar. And in Kerberos, how does C and S trust T?

[masterxilo]

Why would I want to "manage user access to services" (i.e. giving different permissions for "the same user" for different resources)? Why don't I create one "user account" with a set of permissions for each service-user combination? I don't see any advantage to the single-user philosophy, other than the usability benefit of having to remember only one password - but this usability can be provided on a higher level by password managers. Also I don't understand how the services being "on one host" has anything to do with the authentication.

[Ding-Yi Chen]

Kerberos can use either UDP and TCP