Kerberos is a single sign on solution. AFAICT, it is the only one that solves the problem completely: You confirm that you are who you say you are, and the remote side confirms that it is who you think it is. It doesn’t work over he public internet only due to the fact that most corporate firewalls block the ports it needs.  So  we want to be able to do Kerberos, or its equivalent from the browser.

There are two approaches:  we could try to do it in the context of existing technology, or we could extend the browser.  First a really quick overview.

When using Kerberos you do two things:

1. Go to a centralized location and authenticate yourself

2.  Use something from that centralized place to authenticate yourself to some other service.

Yeah, it is  overly simplified.  I’ll get into more details as I go.

OK:  so this kind of maps to the web single sign on technologies out there.  For example, OAuth and OpenID both work through redirects to a central auth server.  After authenticating yourself, you then receive a redirect back, but this time with an addition value that confirms that the centralized server recognized you.

Why are these not the same?  The devil is in the details.

First off,  when you go to the auth server in Kerberso (called the Key DIstribution center, or KDC)  the  trust is mutual.  The KDC send you something encrypted with your password.  Meaning the KDC has to know your password.  Thus,   you know that the KDC is really the right auth server, or your password won’t work.   WebSSO  doesn’t provide this.  IN fact, when you get redirected to, say, yahoo,  and prompted for a UID and password, you are potentially going to receive a phishing attack.  You provide your auth credentials to the remote server, and you get your token, but it could be configured to accept anything, and to just record your password.

Of course, the fact that you are authenticating with Basic Auth (UserID and Password)  is pretty bad in its own right.

Kerberos uses the Password, but it doesn’t pass across the network.  There is a big difference.  What does back and forth allows you and the KDC to authenticate, but if either side attempts to cheat, it gains no more information than it had before.

The nonce/cookie/token/whatever that you get from a web SSO solution is just a random number.  In most OpenID solutions, the Auth provider does not know anything about the services that it provides auth for, so it can’t say “these are legitimate” and, more importantly,  “these are not legitimate.”  It is easy to extend the systems to authenticate the requester, but it isn’t done baseline by the protocols.

In Kerberos, you get a  ticket specific for some service.  If the service you want the ticket for is unknown to the KDC, you don’t get a service ticket.

OK, so how could we make this work with current technology?  The first step is certificates.

The Auth provider should present to you a certificate, signed by a trusted third party.  Thus, you know the auth provider is who it says it is.  This is necessary but not sufficient.  An attacker can present a certificate that says “I am me”  but you still have to check that  you are talking to who you think you are talking.  Thus, you need to direct which URL provides your auth server, not the requesting service.  This is requirement #1.  Once you auth against your ID server, it should provide you with a certificate with a short lifetime.  This is the certificate that you would use for the remote service.  This is requirement #2.

Much of this can be short circuited.  If your machine has a client certificate, you can use that to authenticate to the remote server without having to go back to the auth server.  Its SSL Certificate can confirm its identity to you.  Since both certificates are signed by trusted third parties, both are confident that they are accurate.  The question, then, is why don’t more people do this?

Cost.  Getting a server that can sign other certificates is trivial.  There is a great Open Source  CA implementation that I happen to work on:  However, getting your CA certificate signed by one of the authorities in the Mozilla  or Internet Explorer known CA list costs big bucks.  $10,000 was one price that I heard quoted.  Lets say it is a million.  The fact is that it costs something significant.

There are other issues.   Probably the most significant is that there is no session timeout.  Once you have a certificate, you are signed in to any site that accepts that certificate.  No user interaction is required.  Ideally, a certificate based approach would be linked with a short, non-cacheable token like “enter the first letter of the day of week followed by a 4 digit PIN”.

User certificates are complicated to administer in the browser.  For example, to remove a certificate in the current version of Mozilla, You have to know to go to “Edit->Preferences->Advanced->Encryption->View Certificate->Your Certificates.  Also, if you accidentally use the wrong one to try and log in to a site, the only way to rectify this problem is to close the browser and go back to the site.  User certificates typically have long lifespans:  A year to two years is not uncommon.  If a certificate times out,  getting a new one can be tricky.

But there is a lot of technology to make it easy, too.  OK a little more crypto background:  A certificate is really just a decorated public key.  If you do SSH, you probably have had to generate a key pair, and then copied the key over to the remote site.  A Certificate takes that public key,  and a trusted service cryptographically ensures that the key is really from you.  So to get a certificate, you need to first generate key pair, then generate a signing request (CSR), send that in to get approved and signed, and get back the certificate.

All of this can be done by the browser.  Mozilla has a internal database that holds your password, and that holds your private keys and  certificates. It is (probably) in  ~/.mozilla/firefox/*.default/cert8.db.

You can see what is in there with  certutil -d ~/.mozilla/firefox/*.default -L

So the mechanisms all exist to do web single sign on with Certificates, but they are painful.  So we have two options:  build out the mechanisms for Certificate web SSO, or make Kerberos SSO  work through the current technology.

To do Kerberos SSO,  here’s what you would need.

Make it possible to get a Ticket granting ticket (TGT)  via  the web browser from the Key distribution Centery (KCD).  This means first setting up an SSL connection between  the browser and the KDC< and then using port 443.  The browser could do a post to the KDC, to request a ticket, buyt the most important part is that the browser pops up a dialog that is unmistakably the enter your Kerberos password/kinit  dialog, and not a phishing attempt.  The browser needs to be involved, and should probably have a spot on the border of the browser that is not in the client area.  This is a tricky design issue, and will require some smarts.

The mechanism to get a service ticket is pretty similar to getting the TGT, but could probably be hidden from the end user.

There should probably be a handful of notifications that are visible to the user.  Getting a TGT requires interaction, but anytime something requests a new service ticket, the user should probably be notified, to prevent requests happening behind his/her back.

One shortcoming with current Keberos implementations is that they only allow one TGT and KDC  at a time.  This limitation is well understood and discussed, and will need to be alleviated prior to Kerbers really being a viable SSO alternative.