Kerberos is “a network authentication protocol…designed to provide strong authentication for client/server applications by using secret-key cryptography” by the Massachusetts Institute of Technology (Massachusetts Institute of Technology, 2019). The current version, 5.x, corrects previous vulnerabilities discovered in version 4.x of the protocol (Yu, Hartman, & Raeburn, 2004). Kerberos helps to eliminate one of the most difficult aspects of implementing cryptography, key management. Ferguson et al describe this as, “…especially difficult because it involves people instead of mathematics, and people are much harder to understand and predict. Key management is in many ways a capstone...Much of the benefit of cryptography is defeated if key management is done poorly” (2010, p. 269).
Modern encryption relies on public algorithms while maintaining absolute secrecy of the keys used. However, manually managing public keys quickly becomes burdensome in large networks such as a corporate local area network. Kerberos helps manage keys as it is a trusted entity by clients and services which uses asymmetric cryptography to help safely, and automatically, distribute public keys on a network. Because of this, the Key Distribution Center (KDC) which manages the database of keys must be physically protected from unauthorized access and logically protected from automated attacks on a hardened system which must always be online to provide authentication services to clients and servers.
Kerberos provides an authentication service (AS) to services and clients which have a shared secret key stored on the AS. Tung shares that “There are three basic steps involved in authenticating a user to an end service” (Tung, 2007). First, clients, known as principals, authenticate to the AS and receive a long-term key. Second, when clients need a service, they send a request to the AS, which generates a new random key (session key), encrypted with the service name and client long-term key (credentials), and the same session key and principal name encrypted with the services long-term key (ticket). Finally, the client creates a timestamp encrypted with the session key (authenticator) which is sent with the ticket to the service. The service decrypts the ticket with its long-term key to get the session key, and decrypts the session key to get the authenticator which relies on the fact that only a legitimate user could have gotten created an authenticator from the trusted AS.
Kerberos also uses a ticket granting server (TGS) to eliminate having to authenticate each time to multiple services. The TGS+AS are called the Key Distribution Center (KDC). Clients first request a ticket from the AS to talk to the TGS during authentication (username/password) to receive a ticket granting ticket (TGT) gets encrypted with the user’s session key. At this point, subsequent authentications for services go to the TGS using replies encrypted with the session key from the TGT. TGT have a limited life-time, which shared by the client and service Ticket Granting Ticket (TGT) which requires a synchronized clock across all participating systems to avoid time-based attacks.
Since the TGT have a limited time span, a reliable system clock is critical to prevent replay attacks, and for proper functionality. Attacks against a stolen TGT could set the clock on a system back so that the invalid ticket is valid again, stop the clock so that the TGT is valid longer than it should be, or set clocks forward to invalidate valid tickets (Ferguson, Kohno, & Schneier, 2010, pp. 262-263). In a Microsoft Windows domain the authentication, which uses Kerberos, it relies on synchronized clocks, often using network time protocol (NTP). As De Clerk shares, “[w]hen a Windows server receives a Kerberos authentication request, it compares the timestamp in the request to its local time. If the difference between the local time and the timestamp is too big, the authentication request is rejected and Kerberos authentication fails” (Clercq, 2011).
References
Modern encryption relies on public algorithms while maintaining absolute secrecy of the keys used. However, manually managing public keys quickly becomes burdensome in large networks such as a corporate local area network. Kerberos helps manage keys as it is a trusted entity by clients and services which uses asymmetric cryptography to help safely, and automatically, distribute public keys on a network. Because of this, the Key Distribution Center (KDC) which manages the database of keys must be physically protected from unauthorized access and logically protected from automated attacks on a hardened system which must always be online to provide authentication services to clients and servers.
Kerberos provides an authentication service (AS) to services and clients which have a shared secret key stored on the AS. Tung shares that “There are three basic steps involved in authenticating a user to an end service” (Tung, 2007). First, clients, known as principals, authenticate to the AS and receive a long-term key. Second, when clients need a service, they send a request to the AS, which generates a new random key (session key), encrypted with the service name and client long-term key (credentials), and the same session key and principal name encrypted with the services long-term key (ticket). Finally, the client creates a timestamp encrypted with the session key (authenticator) which is sent with the ticket to the service. The service decrypts the ticket with its long-term key to get the session key, and decrypts the session key to get the authenticator which relies on the fact that only a legitimate user could have gotten created an authenticator from the trusted AS.
Kerberos also uses a ticket granting server (TGS) to eliminate having to authenticate each time to multiple services. The TGS+AS are called the Key Distribution Center (KDC). Clients first request a ticket from the AS to talk to the TGS during authentication (username/password) to receive a ticket granting ticket (TGT) gets encrypted with the user’s session key. At this point, subsequent authentications for services go to the TGS using replies encrypted with the session key from the TGT. TGT have a limited life-time, which shared by the client and service Ticket Granting Ticket (TGT) which requires a synchronized clock across all participating systems to avoid time-based attacks.
Since the TGT have a limited time span, a reliable system clock is critical to prevent replay attacks, and for proper functionality. Attacks against a stolen TGT could set the clock on a system back so that the invalid ticket is valid again, stop the clock so that the TGT is valid longer than it should be, or set clocks forward to invalidate valid tickets (Ferguson, Kohno, & Schneier, 2010, pp. 262-263). In a Microsoft Windows domain the authentication, which uses Kerberos, it relies on synchronized clocks, often using network time protocol (NTP). As De Clerk shares, “[w]hen a Windows server receives a Kerberos authentication request, it compares the timestamp in the request to its local time. If the difference between the local time and the timestamp is too big, the authentication request is rejected and Kerberos authentication fails” (Clercq, 2011).
References
- Clercq, J. D. (2011, Jun 30). Q: Why is time synchronization between Windows machines critical in an Active Directory (AD) environment? How important is this for Kerberos authentication? What service controls time synchronization on Windows machines? Retrieved April 13, 2019, from ITPro Today: https://www.itprotoday.com/active-directory/q-why-time-synchronization-between-windows-machines-critical-active-directory-ad
- Ferguson, N., Kohno, T., & Schneier, B. (2010). Cryptography engineering: design principles and practical applications. Indianapolis, IN: Wiley Pub., Inc.
- Massachusetts Institute of Technology. (2019, January 07). What is Kerberos? Retrieved from Kerberos: The Network Authentication Protocol: https://web.mit.edu/kerberos/#what_is
- Tagg, G. (2000). Implementing a Kerberos Single Sign-on Infrastructure. United Kingdom. Retrieved April 13, 2019, from https://pdfs.semanticscholar.org/ee5a/69d86aa2d3d5f1d855c3e36ba778f73a3241.pdf
- Tung, B. (2007, January 2). The Moron's Guide to Kerberos, Version 2.0. Retrieved April 2019, 13, from https://wpollock.com/AUnixSec/MoronsGuideToKerberos.htm
- Yu, T., Hartman, S., & Raeburn, K. (2004, February 5). The Perils of Unauthenticated Encryption: Kerberos Version 4∗. Massachusetts Institute of Technology, Massachusetts, United States of America. Retrieved April 13, 2019, from http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf