34,333
edits
Changes
→Kerberos Authentication
== Kerberos Authentication ==
Kerberos Authentication was originally developed at the Massachusetts Institute of Technology as part of a project called ''Athena''. In an earlier section of this chapter we looked at the ''username and password'' authentication approach and discussed the inherent weaknesses of transmitting the username and password between the client and the server (such that it might be intercepted by a malicious party and used to gain unauthorized access).
The purpose of Kerberos is to provide an authentication process that does not require the transmission of username and password though the use of a ''symmetric-key authentication protocol''. The term ''symmetric key'' in this context is used to refer to the fact that the same key is used for both the encryption and decryption processes.
In previous authentication scenarios, the process has involved two entities (the client and the server). The Kerberos Authentication process relies on a third entity called the ''Key Distrubution Center''. The following provides a stop by step breakdown of the Kerberos authentication process:
=== Logon at Client ===
* The user enters a username and password on the client system.
* The client performs a one-way hash on the user's password, which becomes the ''secret key'' of the client.
=== Client Authentication ===
* The client system transmits a cleartext message to the ''Authentication Server'' (AS) requesting services for the user. Note that neither the ''secret key'' nor the password is sent to the Authentication Server.
* The Authentication Server checks to see if the client exists in its database. If it exists, it sends back the two messages, Client/Ticket Granting Server (TGS) session key encrypted using the secret key of the user and a 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.
* The client devrypts the TGS session key for use in further communications with TGS. The client cannot, however, decrypt the TGT message which was encrypted using TGS's secret key.
== Client Service Authorization ==
* In order to request services, the client sends two messages to the TGS, a messaging containing the Ticket-Granting Ticket and the ID of the requested service and an authenticator message composed of the client ID and the timestamp), encrypted using the client/TGS session key.
* Upon receipt of the above messages, the TGS decrypts the messages and sends a Client-to-server ticket and a client/server session key encrypted with the client/TGS session key to the client.
=== Client Service Request ===
* Upon receiving the a Client-to-server ticket and a client/server session key, the client has enough information to authenticate itself to the server. The client connects to the server and sends the Client-to-server ticket and a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key.
* The server decrypts the ticket using its own secret key and sends a message to client containing the timestamp found in client's recent Authenticator plus 1, encrypted using the client/server session key to the client to confirm its true identity.
* The client decrypts the confirmation using the client/server session key and checks whether the timestamp is correctly updated.
* Authentication is complete. The server provides the services to the client.