Kerberos - GIAC Research in the Common Body of Knowledge

Kerberos: Category: Cryptography
Author: Eric Conrad
Date Added: February 6th, 2007

Analysis and Explanation of Kerberos

Kerberos is a symmetric key authentication system that allows clients to securely access networked services. It can be used as part of a single sign-on (SSO) architecture. Kerberos is described by Request for Comment (RFC) 4120¹, released in July 2005.²

Kerberos is part of the Massachusetts Institute of Technology's (MIT) project Athena, which was launched in 1983 with the goal of integrating computers into the curriculum at MIT.³ The need for networked security arose as MIT migrated from terminal-based computer access to workstation-based access via Ethernet. Kerberos was designed to secure clients and servers connecting via an untrusted network, and it is currently used in a variety of applications, including Windows Active Directory, among many others.

The Kerberos authentication model is based on the Needham-Schroeder symmetric-key protocol, described in the 1978 paper Using Encryption for Authentication in Large Networks of Computers.⁴ The paper describes both symmetric and asymmetric methods.⁵

Kerberos is designed to provide secure symmetric key exchange by leveraging trusted third parties and shared secrets, and it allows mutual authentication of principals (clients and services). Authentication is the verification of an identity claim (such as, "I am client Alice"). Keys are never passed in cleartext, making it secure when an attacker has access to all network traffic.

Much of Kerberos's complexity derives from the challenge of securely exchanging symmetric keys. Asymmetric, or public key, cryptography addresses this issue. RFC 4556 was released in June 2006, and it describes the Kerberos protocol extension "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)."⁶

The current version of Kerberos is version 5, released in 1993. Version 5 has addressed a number of security issues with Kerberos version 4, added new features, and introduced additional encryption methods beyond DES. This paper describes Kerberos version 5.

Kerberos Credentials

Kerberos servers issue clients credentials that allow them access to services. A credential is made up of a ticket and a session key.

Tickets identify a client to a service. A ticket granting ticket (TGT) allows access to the ticket granting server (TGS), which can issue additional tickets, such as service tickets (used to request specific services). Each ticket contains the client ID and network address, the end time value, and a session key.⁷ Tickets are valid until the end time value (usually set to 10 hours).

Upon receipt from a client, a service uses its secret key to decrypt the ticket, which produces a session key that is then used for further communication with the client.

Tickets allow services (including the TGS) to be stateless: There is no need to keep track of sessions because all state information is contained in the encrypted ticket.

Authenticators

Authenticators were added to improve the security of Kerberos.⁸ They are sent with tickets as part of Kerberos service requests and contain the client ID, a timestamp, and a checksum. After they're decrypted, the checksum is compared with the contents of the request. This step verifies that the key is correct and provides integrity by ensuring the request has not been altered.

The timestamp is compared with the local system time (allowing for clock skew, usually set to 5 minutes). If the checksum or timestamp does not match, the request is rejected.

Kerberos Encryption

Kerberos originally used the Data Encryption Standard (DES) for encryption. DES has a 64-bit key length, but 8 bits are used for parity (error correction), for an effective 56-bit key length. Due to a short key length, DES has become weak to brute-force guessing attacks. Kerberos 5 added Triple DES and RC4 as additional supported encryption types.

The Kerberos Authentication Process

Here are the systems and services involved in a sample authentication process:

Alice: the client requesting services
Bob: a file share Alice would like to access
Key Distribution Center (KDC): the Kerberos server that issues TGTs
Ticket Granting Server (TGS): the Kerberos server that issues Service Tickets

Both the KDC and TGS services have access to the same database, which includes the unencrypted secret keys of all registered services and clients. The KDC and TGS are services that usually run on the same server.

Simplified Kerberos Authentication

Here is a summary of the Kerberos authentication process:

Alice requests and receives credentials for the TGS from the KDC.
Alice requests and receives credentials for Bob from the TGS.
Alice authenticates to Bob (and Bob optionally authenticates to Alice).

This image shows a simplified authentication of client Alice to server Bob:¹⁰

Step 1: User Alice enters her password, which is converted into a hash and stored locally.

Alice's Kerberos client (hereafter referred to as "Alice") requests credentials for the TGS from the Kerberos KDC. This request is sent via cleartext¹¹; subsequent traffic will use encryption.¹²

Step 2: The KDC sends Alice credentials for the TGS. These include a session key, encrypted with Alice's key (the KDC has access to all client and service keys) and a TGT encrypted with the TGS's key.¹³

Step 3: Alice decrypts the session key, saves the TGT, and deletes the hashed password.

Alice requests credentials for Service Bob and sends the encrypted TGT and the first authenticator (encrypted with the session key) to the TGS.

Step 4: The TGS uses its key to decrypt the TGT, recovers the session key, and then decrypts the Authenticator. Possession of a TGT and a valid session key authenticates Alice to the TGS: Alice's key was required to decrypt the session key.

The TGS sends Alice credentials for Service Bob. These include a service ticket, encrypted with Bob's key,¹⁴ and the client/server (C/S) session key, encrypted with the session key.

Step 5: Alice uses the session key to decrypt the C/S session key. Alice then sends Bob the requested service, the service ticket (encrypted with Bob's key), and the 2nd Authenticator, encrypted with the C/S session key.

Bob uses its key to decrypt the service ticket, which produces the C/S session key. Bob then uses the C/S session key to decrypt the second authenticator. A valid authenticator authenticates Alice to Bob: Only Bob and the KDC know Bob's secret key.

Step 6: (optional) Bob can authenticate to Alice by adding 1 to the timestamp received from the second authenticator, encrypting it with the C/S session key and sending it to Alice. This proves to Alice that Bob was able to read the authenticator, which required the session key encrypted with Bob's key.

Both Alice and Bob have now mutually authenticated, and possess a symmetric C/S session key. This key has never been exposed in cleartext on the network and CAN be used for further communication between the two principals.

The need for both the KDC and TGS

Steps 1 through 4 could be combined into two steps and one Kerberos service (Alice directly requesting a service ticket for Bob), which would simplify the Kerberos architecture. The 'additional ticket exchange' was designed to 'reduce the risk of exposure of the client's secret key... and to make the use of Kerberos more transparent to the user.'¹⁵

After receiving the TGT, the client deletes the local copy of the secret key (reducing its exposure). The TGT and session key allow the user to authenticate to other services without requiring the user to reenter his password.

Access to the TGS is similar to access to any other service, such as Bob. In both cases Alice sends a ticket encrypted with the service's key and also sends an authenticator encrypted with a session key. The service uses its key to decrypt the ticket, recovers the session key, and then decrypts the authenticator.

Attacks on Kerberos

KDC security: The KDC has unencrypted access to all client and service keys and is thus critical to the security of Kerberos. The KDC must be kept secure, both from a physical and a network standpoint.

Availability: Kerberos provides confidentiality through encryption, and integrity via checksums, but it does not provide availability. A denial-of-service attack on the KDC or TGS services would prevent clients from receiving TGTs or accessing new services. This attack can be mitigated through the use of redundant Kerberos servers.

Replay attacks: Tickets can be copied or captured via sniffing and replayed at a later time. One attack involves copying a ticket, taking the client off the network (through a denial-of-service attack), impersonating the client's IP address, and resending the ticket.

The authenticator was added to mitigate this attack. If the authenticator's timestamp is off by more than the clock skew (usually set to 5 minutes), the request is rejected.¹⁶

The security of Kerberos depends in large part on synchronized time, and therefore on the security of time synchronization protocols, which are often unauthenticated. Spoofing such services is not trivial, but "it is not cryptographically difficult."¹⁷

Password-guessing attacks: The security of Kerberos depends on the secrecy of principal's keys. An attacker with a copy of Alice's encrypted credentials (sniffed or copied from the local system) can attempt to discover Alice's password by guessing or brute-forcing keys to decrypt the session key.

Kerberos 4 allowed unauthenticated requests for any client's encrypted credentials, meaning an attacker could simply request a victim's encrypted credentials. Kerberos 5 introduced the Pre-Authentication option to mitigate this attack, in which the client in step 1 (described previously) also encrypts the current time with its secret key. The KDC then decrypts the time with the client's key and verifies it before sending credentials. Password-guessing attacks are still possible if an attacker obtains credentials through other methods.

¹ RFC 4120. URL: http://www.ietf.org/rfc/rfc4120.txt

² RFC4120 replaced RFC1510 (released in September 1993), which described Kerberos version 5. URL: http://www.ietf.org/rfc/rfc1510.txt

³ Aaron D. Mihalik, Project Athena. URL: http://www-tech.mit.edu/V119/N19/history_of_athe.19f.html

⁴ Roger Needham and Michael Schroeder. Using encryption for authentication in large networks of computers. Communications of the ACM, 21(12), December 1978.

⁵ Kerberos uses the symmetric method. The asymmetric method (as described by the paper) was found to be vulnerable to a man-in-the-middle attack.

⁶ RFC 4556. URL: http://www.ietf.org/rfc/rfc4556.txt

⁷ There are also additional optional fields.

⁸ They help mitigate replay attacks, see 'Attacks on Kerberos' below.

⁹ There are additional values that are transmitted, such as nonces (a random value that is used once). There are also optional fields. For the sake of clarity, only the critical fields are described.

¹⁰ {foo}Key ^bar means "foo" is encrypted with secret key "bar".

¹¹ This exchange does not use (optional) Kerberos preauthentication; see the "Attacks on Kerberos" section.

¹² Critical data is encrypted, but some fields will remain unencrypted, such as the requested service.

¹³ Note that Alice cannot decrypt the TGT (but the TGS can, in step 3).

¹⁴ Alice cannot decrypt this ticket (but Bob can, in step 5).

¹⁵ John T. Kohl, B. Clifford Neuman, and Theodore Y. T'so, The Evolution of the Kerberos Authentication System. In Distributed Open Systems, pages 78-94. IEEE Computer Society Press, 1994. URL: ftp://athena-dist.mit.edu/pub/kerberos/doc/krb_evol.PS

¹⁶ This does not completely prevent the replay attack, but it makes it more challenging for an attacker.

¹⁷ S. M. Bellovin and M. Merritt. Limitations of the Kerberos Authentication System. In Proceedings of the Winter 1991 Usenix Conference. January 1991. URL: http://www.securiteinfo.com/ebooks/palm/kerblimit.usenix.pdf

^ Top

Domain 5: Cryptography