Kerberos Named after a mythological three-headed dog that guards the underworld of Hades, Kerberos is a network authentication protocol that was designed at the Massachusetts Institute of Technology (MIT) in the 1980s to provide proof of identity on a network. 1

Introduction Kerberos is an integral part of Windows Active Directory implementations. Kerberos provides secure user authentication with an industry standard that permits interoperability. Based on RFC 1510, the Kerberos Version 5 protocol provides enhanced authentication for the distributed computing environment and standardization to interoperate with other operating systems. The Active Directory domain controller maintains user account and log-in information to support the Kerberos service. For local machines that aren't actively participating in a domain, Windows NT LAN Manager (NTLM) protocol is still utilized to verify a user's name and password before granting system access. 2

Understanding Kerberos Kerberos Version 5 is standard on all versions of Windows 2000/2003 and ensures the highest level of security to network resources. The Kerberos protocol name is based on the three- headed dog figure from Greek mythology known as Kerberos. The three heads of Kerberos comprise ▫The Key Distribution Center (KDC) ▫The client user ▫The server with the desired service to access The KDC is installed as part of the domain controller and performs two service functions: ▫The Authentication Service (AS) ▫The Ticket-Granting Service (TGS). 3

Understanding Kerberos Three exchanges are involved when the client initially accesses a server resource: ▫AS Exchange ▫TGS Exchange ▫Client/Server (CS) Exchange 4

How It Works 5 Authentication exchange Ticket-granting service exchange Client/server exchange Secure communications

How It Works Authentication exchange: ▫The client asks the authentication server for a ticket to the ticket-granting server (TGS). ▫The authentication server looks up the client in its database, then generates a session key (SK1) for use between the client and the TGS. ▫Kerberos encrypts the SK1 using the client’s secret key. ▫The authentication server also uses the TGS’s secret key (known only to the authentication server and the TGS) to create and send the user a ticket-granting ticket (TGT). 6

How It Works 7

8 Ticket-granting service exchange: ▫The client decrypts the message and recovers the session key, then uses it to create an authenticator containing the:  User’s name  IP address  Time stamp ▫The client sends this authenticator, along with the TGT, to the TGS, requesting access to the target server. ▫The TGS decrypts the TGT, then uses the SK1 inside the TGT to decrypt the authenticator. ▫It verifies information in the authenticator, the ticket, the client’s network address and the time stamp. ▫If everything matches, it lets the request proceed. ▫Then the TGS creates a new session key (SK2) for the client and target server to use, encrypts it using SK1 and sends it to the client. ▫The TGS also sends a new ticket containing the client’s name, network address, a time stamp and an expiration time for the ticket — all encrypted with the target server’s secret key — and the name of the server.

How It Works 9

10 Client/server exchange: ▫The client decrypts the message and gets the SK2. ▫Finally ready to approach the target server, the client creates a new authenticator encrypted with SK2. ▫The client sends the session ticket (already encrypted with the target server’s secret key) and the encrypted authenticator. ▫Because the authenticator contains plaintext encrypted with SK2, it proves that the client knows the key. ▫The encrypted time stamp prevents an eavesdropper from recording both the ticket and authenticator and replaying them later. ▫The target server decrypts and checks the ticket, authenticator, client address and time stamp. ▫For applications that require two-way authentication, the target server returns a message consisting of the time stamp plus 1, encrypted with SK2. ▫This proves to the client that the server actually knew its own secret key and thus could decrypt the ticket and the authenticator.

How It Works 11

How It Works 12 Secure communications: ▫The target server knows that the client is who he claims to be, and the two now share an encryption key for secure communications. ▫Because only the client and target server share this key, they can assume that a recent message encrypted in that key originated with the other party.

How It Works 13

14

Understanding Kerberos AS Exchange ▫When initially logging on to a network, users must negotiate access by providing a log-in name and password in order to be verified by the AS portion of a KDC within their domain. ▫Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain. ▫The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. ▫The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network. 15

Understanding Kerberos Kerberos at computer boot ▫Client sends a DNS query to find a domain controller (LDAP Service) ▫ The client sends a UDP query to the Kerberos port, 88, on the DC, and is answered by the DC. ▫This is the clients request for Ticket-Granting-Ticket ▫The client’s account password is used as the key in a cryptographic hash of a timestamp. ▫A plaintext copy of the timestamp also accompanies the hash. ▫On the DC, the client time from the unencrypted timestamp is compared to the DC’s time. ▫If the time is off by more than 5 minutes, the logon is rejected. ▫If the time is OK, the Kerberos KDC uses its copy of the client’s password to create a cryptographic hash of the unencrypted timestamp. ▫The two hashes are compared and if they match the client is authenticated. 16

Understanding Kerberos Example AS Administration ▫The AS request identifies the client to the KDC in plain text. ▫If pre-authentication is enabled, a time stamp will be encrypted using the user's password hash as an encryption key. A plaintext copy of the timestamp also accompanies the hash. ▫If the KDC reads a valid time when using the user's password hash (stored in the Active Directory) to decrypt the time stamp, the KDC knows that request isn't a replay of a previous request. ▫The pre-authentication feature may be disabled for specific users in order to support some applications that don't support the security feature. 17

Understanding Kerberos Example AS Administration ▫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  A session key encrypted with the user's password hash to handle future communications with the KDC. ▫Because the client system cannot read the TGT contents, it must blindly present the ticket to the TGS for service tickets. ▫The TGT includes:  Time to live parameters  Authorization data  A session key to use when communicating with the client  The client's name. 18

Understanding Kerberos TGS Exchange ▫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, is then cached locally on the client machine. ▫The TGS receives the client's TGT and reads it using its own key.  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 key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server exchange. 19

Understanding Kerberos Client/Server Exchange ▫Once the client user has the client/server service ticket, he can establish the session with the server service. ▫The server can decrypt the information coming indirectly from the TGS using its own long-term key with the KDC. ▫The service ticket is then used to authenticate the client user and establish a service session between the server and client. ▫After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service. 20

Understanding Kerberos Client/Server Exchange Detail ▫The client blindly passes the server portion of the service ticket to the server in the client/server request to establish a client/server session. ▫If mutual authentication is enabled, the target server returns a time stamp encrypted using the service ticket session key. ▫If the time stamp decrypts correctly, not only has the client authenticated himself to the server, but the server also has authenticated itself to the client. ▫The target server never has to directly communicate with the KDC. This reduces downtime and pressure on the KDC. 21