Kerberos Authentication and Single Sign-On Access Control
Kerberos Authentication: In Greek mythology, Kerberos is the monstrous three-headed dog that guards the entrance to Hades. Indeed, we can view modern-day Kerberos Authentication as the god who guards the entrance to a network’s resources.
Kerberos Authentication, a computer network authorization protocol, was originally invented and published by MIT. This system allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner. In general, we call this function access control.
Before we address the working mechanisms of Kerberos Authentication, we need to understand several terms in the discussion.
Kerberos Authentication is based on a system of “tickets,” which serve to prove the identity of users. It consists of a number of components found within its system. Two main components are:
Authentication Server (AS): The AS is responsible for identifying the user and issuing a valid ticket for the client to use. This is referred to as a Ticket Granting Server (TGS) service. The AS also generates a short-term secret key for the communication between the client and the TGS.
Ticket Granting Server (TGS): The TGS is logically separate from the AS. It is responsible for issuing a Service Request Ticket (SRT) to users in the network when they request certain resources within the Kerberos network environment.
Physically, the AS and the TGS can reside within a single server.
The Single Sign-On Process of Kerberos Authentication
When a user logs into the system, he or she presents to the client server a username and password. The client performs a one-way hash transformation to yield a secret key, called the client’s own secret key or long-term secret key. The client then sends the information to the Authentication Server (AS).
When the AS receives the user’s clear text identification information from the client machine, it checks to see if the user’s long-term secret key is in the database. If the user has entered the password correctly, this secret key will be identical to the client’s own secret key. (Please note that this process does NOT involve the transfer/exchange of the user’s actual password or client’s own secret key through the network, thus eliminating the possibility of unauthorized third parties capturing sensitive information.)
The AS then generates two items. The first item is a random session key, referred to as the TGS session key, or the short-term secret key. This key is encrypted with the client’s own secret key (the long-term secret key) and sent to the client machine, which can then decrypt the TGS session key by its own secret key. The TGS session key (short-term secret key) is stored within the client’s system (usually in its volatile memory, for security purposes).
The second item the AS generates is a Ticket Granting Ticket (TGT), encrypted with the TGS’s secret key, the username, and some other information encrypted by TGS’s secret key. The TGT is sent to the client, but it cannot be tampered with or altered by the client or any other party. This use of a TGT is the essence of this type of access control technology.
Now the client has enough information to present itself to the Ticket Granting Server (TGS) for authentication and service request. The client presents the following three items to the TGS:
- The TGT it received from AS
- The service ID of the network service requested
- The client’s own authentication information (authenticator).(The authenticator is encrypted by the TGS’s session key.)
After receiving the TGT, the TGS uses its secret key to decrypt the content. It extracts the TGS’s session key from the TGT and uses it to decrypt the client’s authenticator in order to verify the client’s identity.
After successful verification, TGS then issues the client two messages. The first message is the client’s own service session key to a particular service. As an example, let’s say the user requested a printer service. So the service session key is a printer service session key encrypted by the TGS’s session key. The client can immediately decrypt the printer service session key using the same TGS session key (the short-term secret key).
The second message the TGS sends to the client is the Service Request Ticket (SRT) encrypted by the printer service’s secret key. This SRT contains the printer service session key already shared with the client. (Again this second message cannot be altered or tampered with by the client and any other third parties because it is encrypted by the printer’s secret key.)
When the client requests the service from the printer, it sends the SRT to the printer together with its own authenticator (encrypted by the printer service session key.) The printer first decrypts the ticket by its own secret key, and extracts the respective printer service session key shared with the client. It then uses the session key to decrypt the authenticator to verify the client’s identity.
After successful verification, the printer can communicate with the client and provides the service to the client. From that point forward, the two parties communicate using the printer service session key.
Why is Kerberos Authentication called Single Sign-On?
The magic of the single sign-on process lies in the fact that the client logs onto the AS only one time, using a password. The password is “hashed” in order to produce the long-term secret key for verification. The authentication process within the AS then creates a TGS session key (the short-term secret key) for the client. The client then uses this short-term secret key to communicate with the TGS, requesting different network services. At this point there is no need to enter the password again—hence, the “single sign-on” name.
Security Threats of Kerberos Authentication
It is still possible to compromise this short-term secret key, threatening the security of the system. However, this threat is minimized by the fact that the user is required to re-enter his or her password every six to eight hours. This causes the Kerberos system to go through the authentication process with AS once again, and the short-term secret key is renewed with another one. Additionally, in order to protect the short-term secret key further, it should reside on the client’s volatile memory side instead of within permanent secondary storage, which is vulnerable to attack.
Pros and Cons of Single Sign-On Systems
On the one hand, the single sign-on process offers the user the convenience of typing in a password only once to request different services during any six-to-eight-hour period. However, it has the disadvantage of possible compromise of services for that period of time if the short-term secret key is compromised.
Tags: Short-term session key, Long-term session key, Single point of failure, Password Management, Replay-attack, Single Sign-On Access Control
Leave a Reply