From: Jonathan Kamens <jik@kamens.brookline.ma.us>

     In brief, the question seems to be, "What does Kerberos give me
     that SSL doesn't?"

     That question is specific case of the general question, "What are
     the advantages and disadvantages of a private-key,
     trusted-third-party authentication system vs. a public-key,
     certificate-based authentication system?"

     As I see it, SSL has two major advantages over Kerberos: (1) It
     doesn't require an accessible trusted third party; (2) it can be
     used to establish a secure connection even when one end of the
     connection doesn't have a "secret" (a.k.a. "key" or "password").
     These two advantages make it ideal for secured Web communication
     and for similar applications where there is a large user base
     which is not known in advance.

     [ Here are some disadvantages of SSL: ]

     1) Key revocation. If a Verisign certificate issued to a user is
     compromised and must be revoked, how will all the servers with
     whom that user interacts know that the certificate is no longer
     valid? Either revocation certificates have to be circulated to all
     relevant servers and cached for a long time, or servers have to
     verify incoming user certificates against a "revocation server."
     In that case, the revocation server must be a highly available
     third party, which means you've eliminated one of the two major
     advantages of SSL over Kerberos. Kerberos principals can be
     disabled at will on the KDC and will then become unusable as soon
     as any cached tickets expire, on the order of hours, without any
     action by servers.

     2) Key security. If I'm issued a Verisign certificate, it has to
     live on my hard disk. Yes, it may be encrypted there such that I
     have to unlock it with a password before I can use it, but it's
     still on the hard disk and therefore vulnerable to cracking
     attacks. On the other hand, I don't need any sort of certificate
     to authenticate to Kerberos -- all I need is my password, which is
     in my brain, not on a hard disk.

     3) Cost of use. Kerberos doesn't infringe on any patents. Which
     means that it can be used for free, while SSL users may have to
     pay.

     4) Open standards. Kerberos has been free from the beginning. The
     standards documenting it are open and have been developed openly
     from the start. On the other hand, SSL was developed by a company
     with a commercial interest in ensuring that its standards become
     THE standard. Let's just say that Netscape is not exactly known
     for "playing by the rules" when it comes to developing Internet
     standards.

     5) Flexibility. I'm under the impression, although I may be wrong
     (if so, I hope someone will correct me), that Kerberos is somewhat
     more flexible than SSL. For example, if I want to add a new
     authentication technology to Kerberos (e.g., a new kind of
     SmartCard with its own algorithm), all I have to do is modify my
     KDC and my ticket-acquiring client to know how to do the new
     authentication. Then, it can be used to get Kerberos tickets which
     will look the same as any other Kerberos tickets and will be
     usable with any Kerberos-capable application. On the other hand,
     if I want to implement a new authentication technology for SSL, I
     believe I'd have to get new versions of all my SSL-capable
     applications.

     I'm probably forgetting some advantages and disadvantages of
     Kerberos and SSL, but my object here isn't to be comprehensive. My
     point is that there are applications for which SSL is superior to
     Kerberos and vice versa.

Another good reference for comparing public-key cryptography to symmetric
key systems like Kerberos can be found at:

   * Don Davis, "Compliance Defects in Public-Key Cryptography"
     <http://world.std.com/~dtd/compliance/compliance.ps>