Kerberos

Kerberos is a network authentication service protocol.

Kerberos is from MIT. The version we're interested in is Kerberos 5, which has finally been officially released as version 1.0, and has been around for a long time in a series of beta releases. Kerberos 4 is currently in use at some large sites, including universities.

DCE supports Kerberos 5. The DCE security service uses Kerberos tickets, and it accepts connections on the kerberos5 service port, like its Kerberos counterpart. DCE authentication is normally RPC based, so DCE clients don't connect to this port, but MIT Kerberos 5 clients do. DCE doesn't support Kerberos 4.

Microsoft NT security does or will support Kerberos 5 authentication, according to a white paper.

Let's say you have connected to a service daemon like ftpd on melville, and are about to ask for one of your files, so ftpd needs to authenticate your identity. Of course ftpd can't just trust you in this matter, so it asks for an ftp/melville service ticket. This ticket includes your name and location, a timestamp and lifetime, and a special key generated for this particular session. All of that is encrypted in ftpd's own Kerberos key - so you can't even look at the contents, but it can. Since only ftpd and the Kerberos service know this key, when ftpd finds that it can decrypt the ticket, it assumes you got it straight from Kerberos - the third party.

If you don't already have that ftpd/melville ticket in your credentials, your ftp client gets it from Kerberos by presenting the ticket-granting ticket (tgt) that you get for your overall computer session. That ticket is similar to the service tickets in principle, but it's encrypted in your own key (derived from your password), so you can take it apart. What you find is your randomly generated Kerberos security session key, plus some information that Kerberos encrypted in its own key; thereafter when you deal with Kerberos, you send your ID encrypted in your session key, and the undecryptable thing Kerberos sent you.

Well, no doubt that's all clear as mud, but the main points are

• You don't have to put your password out on the net at any point, but rather information that was encrypted using your password.
• You can acquire a reusable service ticket for a particular service on a particular host, and the service daemon can tell it's valid without having to ask the Kerberos service.

All of this requires that you and your password can be found in the Kerberos data base, of course, where that identity is known as a principal. Each service also has to be a principal - like ftp/melville, for instance. In fact, in Kerberos terminology, that is an instance - the Kerberos implementation of that makes a single principal, ftp, with an instance for each host. DCE doesn't have instances, though, and to make things even more confusing slashes mean something else in DCE, but it seems to work out OK. I haven't actually added any service principals other than host (e.g., host/melville.u.washington.edu), which is intended for telnet/rsh/rlogin and also works for ftp. I would recommend that where convenient our own services also use this host principal.