KERBEROS Kerberos is a computer network authentication protocol which works on the basis of "tickets" to allow nodes communicating over

a non-secure network to prove their identity to one another in a secure manner. Its designers aimed primarily at a clientserver model, and it provides mutual authentication both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography by utilizing asymmetric key cryptography during certain phases of authentication.[Kerberos uses port 88 by default.

How Kerberos Authentication Works

You may not know it, but your network is probably unsecured right now. Anyone with the right tools could capture, manipulate, and add data between the connections you maintain with the internet. The security cat and mouse game isnt one sided, however. Network administrators are currently taking advantage of Kerberos to help combat security concerns.

Project Athena
Project Athena was initiated in 1983, when it was decided by the Massachusetts Institute of Technology that security in the TCP/IP model just wasnt good enough. A total of 8 long years of research passed before Kerberos, named after the three-headed Greek mythological dog known as Cerberus, was officially complete. The result of MITs famous research became widely used as default authentication methods in popular operating systems. If you are running Windows 2000 or later, you are indeed running Kerberos by default. Other operating systems such as the Mac OS X also carry the Kerberos protocol. Kerberos isnt just limited to operating systems, however, since it is employed by many of Ciscos routers and switches.

What Does It Protect Against, Anyways?

If you have ever used an FTP program over a network, you are at risk. If you have ever used a Telnet program over a network, you are again at risk. These are just two examples of how little security some applications allow. FTP and Telnet use what are called plaintext passwords, or otherwise known as cleartext passwords. These passwords are ridiculously easy to intercept with the right tools. Anyone with a simple packet sniffer and packet analyzer can obtain an FTP or telnet logon with ease. With that kind of sensitive information being transmitted, the need for Kerberos is obvious. This need doesnt stop there, however. Sure FTP and Telnet related logons are easy to intercept, but then again so is every other connection any of your applications has to the internet.

Through a process of man in the middle attacks, any hacker can get most logon information for just about anything. From online bank passwords to private passwords on your computer, they are all generally vulnerable to this attack. A man in the middle attack generally occurs when the hacker acts as the man in the middle between two computers. The hacker attempts to pretend to each computer that it is in fact, the computer they have connected to. In reality, all the data is being routed to the hacker, who can then modify or add instructions to the data.

Okay, This Sounds UsefulBut How Does It Work?

Kerberos operates by encrypting data with a symmetric key. A symmetric key is a type of authentication where both the client and server agree to use a single encryption/decryption key for sending or receiving data. When working with the encryption key, the details are actually sent to a key distribution center, or KDC, instead of sending the details directly between each computer. The entire process takes a total of eight steps, as shown below.

1. The authentication service, or AS, receives the request by the client and verifies that the client is indeed the computer it claims to be. This is usually just a simple database lookup of the users ID. 2. Upon verification, a timestamp is created. This puts the current time in a user session, along with an expiration date. The default expiration date of a timestamp is 8 hours. The encryption key is then created. The timestamp ensures that when 8 hours is up, the encryption key is useless. (This is used to make sure a hacker doesnt intercept the data, and try to crack the key. Almost all keys are able to be cracked, but it will take a lot longer than 8 hours to do so)

3. The key is sent back to the client in the form of a ticket-granting ticket, or TGT. This is a simple ticket that is issued by the authentication service. It is used for authenticating the client for future reference.

4. The client submits the ticket-granting ticket to the ticket-granting server, or TGS, to get authenticated.

5. The TGS creates an encrypted key with a timestamp, and grants the client a service ticket. 6. The client decrypts the ticket, tells the TGS it has done so, and then sends its own encrypted key to the service.

7. The service decrypts the key, and makes sure the timestamp is still valid. If it is, the service contacts the key distribution center to receive a session that is returned to the client.

8. The client decrypts the ticket. If the keys are still valid, communication is initiated between client and server. Is all that back-and-forth communication really necessary? When concerning speed and reliability, it is entirely necessary. After the communication is made between the client and server, no further need of transmitting logon information is needed. The client is authenticated until the session expires.

Yet More Authentication

The authentication method described above seems a little one-sided. Kerberos provides support for mutual authentication, for a more secure protection against man in the middle attacks. Remember how the client no longer needs to send logon information after the

authentication takes place? Well it sure would ruin everything if a hacker just intercepted our communication to the server and pretended to be us! This type of authentication is fairly easy to understand, since it only involves two systems. The Mutual Authentication Process

1. The first system creates a challenge code made up of random numbers. 2. This code is sent to the second system, which generates a response to the received code. This response and a challenge code of its own are then sent back to the first system. 3. The first system verifies the response of the second system, and then sends a response to the challenge code it received. 4. When the second system receives the response, it is verified. If all is well, it notifies the first system that they are indeed mutually authenticated.

This type of authentication uses challenge codes to ensure that both computers are who they claim to be. If someone tries to intercept the data, they obviously will fail because they cant pretend to be one of the computers after they have been authenticated with challenge codes.

Sounds Great! Any Drawbacks I Should Know About?

Of course, nothing is perfect. Kerberos has a couple of main flaws that system administrators need to take into account. First and foremost is the need of the Kerberos server. This server will handle all the functions required for authentication. If this server goes down, no one can get authenticated, and thusthe network is down. A total network crash can be prevented by using more than one Kerberos server, but that is more costly than some people would like to think. Next, we have the issue of clock synchronization. Since Kerberos uses timestamps to handle all activity, the clocks on all host machines must be within 10 minutes of the Kerberos servers clock. Since not all clocks are perfect, the host clock and server clock will eventually be misaligned enough to cause a failure. This can usually be remedied by keep clocks up to date, or use a Network Time Protocol, or NTP.

Closing Comments
Kerberos isnt the only encryption protocol available. There are multiple ways to encrypt data, and this holds true for many types of different applications. Email encryption protocols, for example, are a breed all of their own. With a product that has been researched and developed for over 8 years, it is generally expected that the product should be well polished. Kerberos doesnt fail to deliver, and this can be seen by looking at all the vendors who use it. Cisco, Microsoft, Apple, and many others rely on this faithful three-headed dog for network security.

Protocol
Theory
Kerberos uses as its basis the symmetric Needham-Schroeder protocol. The term NeedhamSchroeder protocol can refer to one of two communication protocols intended for use over an insecure network, both proposed by Roger Needham and Michael Schroeder.[1] These are:

The NeedhamSchroeder Symmetric Key Protocol is based on a symmetric encryption algorithm. It forms the basis for the Kerberos protocol. This protocol aims to establish a session key between two parties on a network, typically to protect further communication.

It makes use of a trusted third party, termed a key distribution center (KDC), which consists of two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server (TGS). The KDC maintains a database of secret keys; each entity on the network whether a client or a server shares a secret key known only to itself and to the KDC. Knowledge of this key serves to prove an entity's identity. For communication purposes the KDC generates a session key which communicating parties use to encrypt their transmissions. The security of the protocol relies heavily on short-lived assertions of authenticity called Kerberos tickets.

[edit] Description
The client authenticates itself to the AS and receives a ticket with a timestamp. The client then contacts the TGS, and using the ticket to prove its identity, it asks for a service. If the client is eligible for the service, the TGS sends another ticket to the client. The client then contacts the server providing the service (SS) and uses the latter ticket to prove that it has approval to receive the service. Here is another description.

Kerberos negotiations The client authenticates to the AS once using a long-term shared secret (e.g. a password) and receives a Ticket Granting Ticket (TGT) from the AS. Later, when the client wants to contact some SS, it can (re)use this ticket to get additional tickets from TGS, for SS, without resorting to using the shared secret. The latter tickets can be used to prove authentication to the SS. The phases are detailed below. User Client-based Logon 1. A user enters a username and password on the client machine. 2. The client performs a one-way function (hash usually) on the entered password, and this becomes the secret key of the client/user. Client Authentication

Kerberos Protocol

1. The client sends a cleartext message of the user ID to the AS requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g. Active Directory in Windows Server). 2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client: o Message A: Client/TGS Session Key encrypted using the secret key of the client/user. o Message B: Ticket-Granting-Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS. 3. Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client's secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS. Client Service Authorization 1. When requesting services, the client sends the following two messages to the TGS: o Message C: Composed of the TGT from message B and the ID of the requested service. o Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key. 2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client: o Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key. o Message F: Client/server session key encrypted with the Client/TGS Session Key. Client Service Request 1. Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages: o Message E from the previous step (the client-to-server ticket, encrypted using service's secret key). o Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key. 2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:

Message H: the timestamp found in client's Authenticator plus 1, encrypted using the Client/Server Session Key. 3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server. 4. The server provides the requested services to the client.

Drawbacks and Limitations

Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down, no one can log in. This can be mitigated by using multiple Kerberos servers and fallback authentication mechanisms. Kerberos has strict time requirements, which means the clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail. The default configuration per MIT requires that clock times are no more than five minutes apart. In practice Network Time Protocol daemons are usually used to keep the host clocks synchronized. The administration protocol is not standardized and differs between server implementations. Password changes are described in RFC 3244. Since all authentication is controlled by a centralized KDC, compromise of this authentication infrastructure will allow an attacker to impersonate any user