Kerberos is a symmetric key authentication system that allows clients to securely accessKerberos_logo_800_ENG
networked services. It can be used as part of a single sign-on (SSO) architecture.
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

Kerberos was designed to secure clients and servers connecting via an untrusted network, and it is currently used in a variety of applications.

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,Keys are never passed in cleartext, making it secure when an attacker has access to all network traffic.
the Kerberos protocol extension is “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 post 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.

Untitled
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.

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.