Kerberos Authentication: An Overview Kerberos, named after the three-headed dog of Greek mythology that is known for protecting the gates of Hades, is an authentication protocol developed by MIT through another project, Project Athena. Project Athena, which started in 1983 when MIT decided to use network computers as part of its campus curriculum. MIT had grants from DEC (Digital Equipment Corporation) and IBM, as well as multiple operating systems. The goals of Athena were to have a Single Sign-on (SSO), networked file systems, a unified graphical environment, and a naming convention service. Within 5 years, they had done this. Kerberos allowed for SSO as well as secure remote authentication. Microsoft picked up this program with its development and release of Windows 2000 to replace their previous authentication protocol CHAP (Challenge Handshake Application Protocol) that simply used a plaintext password and user name to authenticate. With Kerberos, this was upgraded to a password that uses encryption keys created using a pseudo-random number generator rather than relying on the password hash of the user. The password is involved in the process, but is not transmitted across the network and is only used in the beginning stage of logging on. When you first log in to the network, users must provide a log-in name and password in order to be verified by the Authentication Service (AS) portion of a Key Distribution Center (KDC) within their domain. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is given a Ticket to Get Tickets (TGT). This TGT has a default lifetime of 10 hours and may be renewed through the user’s log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine and used to request sessions with services throughout the network. The first step in the TGT retrieval process is that the AS request identifies the client to the KDC in plain text. If the client is identified, a time stamp will be encrypted using the user’s password hash as an encryption key. If the KDC reads a valid time it will know that request isn’t a replay of a previous request. If the KDC approves the client’s request for a TGT, the reply (referred to as the AS reply) will include two sections: a TGT encrypted with a key that only the KDC (TGS) can decrypt and a session key encrypted with the password hash that will handle all future communications. The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user’s TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, cached on the client machine. The TGS receives the client’s TGT and reads it. If the TGS approves of the client’s request, a service ticket is generated for both the client and the target server. The client reads its portion using the TGS session and presents it to the target server in the client/server exchange. Once the client user has the client/server service ticket, he can establish the session with the server. The server can decrypt the information coming from the TGS using its own key. The client user is authenticated and a service session is established using the service ticket. After the ticket's