What is Kerberos?
Why Kerberos is useful?
What Kerberos is about
What a principal looks like
How it works
Detailed protocol
Where it can be used for
What is cross-realm authentication?
Known weakness
Kerberos v.s. SSL

The name comes from Greek mythology; it is a three-headed dog.

• What is Kerberos?

Kerberos is a network authentication and key-exchange protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.

• Why Kerberos is useful?
• Internet is an insecure place. Many of the protocols used in the Internet do not provide any security. Tools to "sniff" passwords off of the network are in common use by systems crackers. Thus, applications which send an unencrypted a password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be "honest" about the identity of the user who is using it. Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server.
• Kerberos is better than firewall. Unfortunately, firewalls assume that "the bad guys" are on the outside, which is often a very bad assumption. Most of the really damaging incidents of computer crime are carried out by insiders. Firewalls also have a significant disadvantage in that they restrict how your users can use the Internet.

• What Kerberos is about
• Client, Sever: One program which runs on one host and requests a remote service is Client, whileas the program which runs on remote machine and performs the service is Server.
• Kerberos server(KDC): The server which supplies Kerberos service(both AS and TGS). AS is Authentication Service, TGS is Ticket Granting Service.
• Princpals: Entities that uses Kerberos service, including Client and Server.

The KDC has a copy of every password associated with every princpals
Most KDCs store the principals in a database
• Kerberized Service:  Application server that clients communicate with using Kerberos tickets for authentication. e.g. the Kerberos telnet daemon.
  
  
• What a principal looks like

a principal is in three parts:
The principal name, instance, the Kerberos realm.
e.g. ftp/slinky.cs.nyu.edu@NYU.EDU
Usually the instance is the hostname on which the service is. And Kerberos realm is the domain name if your hosts are all in the NYU.EDU domain.

• How it works

The outline of Kerberos Authentication Protocols

 Kerberos(AS)                             TGS
            ^      \                                 ^      /
              \       \                             /      /
           1   \       \    2              3  /      /   4
                  \       \                     /      /
                    \       \                /      /                  5
                             User/Client       ---------->     Server

1. Request for TGS ticket (TGT)
2. Get TGT for TGS from Kerberos
3. Request for Sever ticket
4. Get Ticket for Sever from TGS
5. Request for Sevice from Server

 

 Detailed protocol.

1. The user is prompted for her/his username. A request {c, tgs}  is sent to AS.
2. AS sends { K_{c, tgs}, {T_c,tgs}K_tgs}K_c back to the user.

T_c,tgs contains C, tgs, time, lifetime, client's IP, K_c,tgs.
A machine's network address is part of the ticket information. This address is used as an additional check to make sure the ticket hasn't been stolen and is being used on another machine.
3. The user is asked for her/his password. The password is converted to DES key through ONE_WAY hash function and used to decrypt the response. Only K_c,tgs, {T_c,tgs}K_tgs are stored.
   In version 5, the complete principal name (including the realm) is used as the salt. There is some advantage for doing this way. User likes to use same password in more than one realm. In this case, the same encrypted passwords for two different realms will not be the same. Hence, if one key is compromised, the other one can still survive. In addition, the same encrypted passwords for two differnet principals will be different. Which is good in that the keys for two users in same realm are distinctable.
4. Tickets for each service the client wants to use can be obtained from TGS. A request {s, {T_c,tgs,}K_tgs, {A_c}K_c,tgs } is sent to TGS Authenticator: {c, IP, time}K_{c, tgs.}
5. If both TGT and Authenticator is valid, TGS  sends { {T_c,s}K_s, K_c,s}K_c,tgs back.  No password needed now.
   The reason the TGT exists is that a user doesn't have to enter in their password every time they wish to connect to a Kerberized service or keep a copy of their passwords around. If TGT is compromised, an attacker can only user the ticket for the lifetime of the ticket.
6. Client sends {{A_c}K_c,s, {T_c,s}K_s} to sever.
7. Server sends { {timestamp + 1} K_c,s} back to Clients. --DONE

• Where it can be used for

rlogin, rsh, telnet
All implementations of telnetd, rlogind, and other remote login utilities generally only check the ticket expiration time at login time, and don't care about it afterwards. However, AFS will not give you access to your files anymore, even if you already have files open.

Note, however, that this is just a matter of implementation. Someone could write a version of telnetd that closed your connection when your ticket expired, but I doubt that it would be very popular :-)

• What is cross-realm authentication?

Any Kerberos principal can authenticate to other principals within the same Kerberos realm. Configuring a Kerberos realm so principals in one realm can authenticate to principals in another realm is called cross-realm authentication.
A KDC cannot acquire a ticket for a user in a foreign realm.

• Known weakness
1.  If an attacker breaks into a machine and steals all of the tickets on that machine, he can use the tickets during the lifetime.
2.  What if a user's password is stolen by an attacker? The attacker can imperonate the user
3.  What if the kerberos database is stolen by an attacker? The whole realm cracks.
4.  Since anybody can request a TGT for any user, and that ticket is encrypted with the user's secret key (password), it is simple to perform a offline attack on this ticket by trying to decrypt it with different passwords. Kerberos 5 introduced preauthentication to solve this problem. Preauthentication is that KDC requires some additional authentication before it issues a TGT. A way doing this is using the current timestamp encrypted with the user's key.
5. In Kerberos 4, authenticators are valid for 5 minutes, if an attacker sniffs the network for authenticators, they have 5 minute of re-using it to gain access to the same service you used. Kerberos 5 introduced a replay cache which prevents any authenticator from being used more than once.

• Kerberos v.s. SSL

Kerberos is authentication for clients/servers in a network by secret-key cryptography, whileas SSL is by public-key cyptography.
SSL has 2 major advantages over Kerberos:
1.  It doesn't require an accessible third-party
2.  It can be used to establish a connection without a password, good for Web communication for a large user unknown inadvance.
disadv. 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 Kerberos, principals can be disabled at will on the KDC and will then become unusable as soon as any cached tickets expires.
2. SSL certificate need to be on disk, whileas Kerberos password can be memorized.