> For the complete documentation index, see [llms.txt](https://davidjosearaujo.gitbook.io/notes-mcs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://davidjosearaujo.gitbook.io/notes-mcs/identification-authentication-and-authorization/authentication-with-trusted-third-parties-kdcs/kerberos.md).

# Kerberos

## Goals

Authenticate peers in a distributed environment.

* Targeted for Athena (at MIT)

Distribute session keys for adding security to sessions between peers.

* Authentication (the initial goal)
* Confidentiality (optional)

Single Sign-On.

* Only one password to remember
* Daily use (typically)

## Background: Needham-Schroeder (1978)

A and B trust on a common Key Distribution Center (KDC). 

KDC shares a key with every A and B. Central authentication authority.

KDC generates good (random) $$K\_{ab}$$ keys.

* Directly imported by requesters
* Indirectly obtained by targets

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FyK6W0mlpk8D6Axh9HeIi%2F2024-04-21_17-18.png?alt=media&amp;token=1895fc2c-c4f2-417e-ba12-5f14ded8b523" alt=""><figcaption></figcaption></figure>

## Architecture and base concepts

### Two Kerberos KDC services

* Authentication Service (AS)
* Ticket Granting Server (TGS)

### Entities (principals)

* All have a secret shared with Kerberos (AS or TGS)
* People: a key derived from a password:
  * $$K\_U$$ = hash(password)
  * Services/servers: key stored in some repository.
* Requisites
  * Clocks (very well) synchronized.

### Authentication elements

* **Ticket**: required to request a service.
* **Authenticator**: proof of the identity of a requester.

## Tickets and authenticators

### Ticket

Unforgeable piece of data.

It can only be interpreted by the target service.

Carries the identities of the client that can use it.

Carries a session key.

Carries a validity timestamp.

### Authenticator

Carries a timestamp of the request.

Carries the identity of the client.

Proves that the client knows the session key.

## Overview of Kerberos SSO

### 1º Step: Login

Location of the Kerberos servers of the realm.

Authentication of user U by Kerberos (AS).

* The user gets a Ticket Granting Ticket (TGT) and a session key ($$K\_{TGT}$$) for interacting with another Kerberos service (TGS).
* The TGT can be used to request other tickets needed by the user U to access every service S.

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FVi49zucyvBLbUgpqMnbb%2F2024-04-21_17-32.png?alt=media&amp;token=df1427bf-ea27-4032-a576-894f327dd580" alt=""><figcaption></figcaption></figure>

### 2nd step: Authenticated access to servers

U requests Kerberos (TGS) a ticket for accessing S.

* U uses TGT in the request.
* U must prove that he is the owner of TGT.
* U gets a session key $$(K\_{US})$$ and a ticket to S $$(T\_{US})$$.

U uses $$(T\_{US})$$ to make authenticated requests to S.

* Server S uses $$T\_{US}$$ to check the identity of U.
* U must prove that he is the owner of $$T\_{US}$$.

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FJikGJdath8nyMDuxAxa4%2F2024-04-21_17-36.png?alt=media&amp;token=11f5bb0f-80c7-4e80-a972-300457980559" alt=""><figcaption></figcaption></figure>

## Protocol (of version V5)

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FfiaqpKTan3eR1SrVMDGm%2F2024-04-21_17-36_1.png?alt=media&amp;token=64e559a5-fa25-41c3-bbda-6cc00bdceca1" alt=""><figcaption></figcaption></figure>

## Pre-authentication alternative

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FZnZj7libx4daCaT1Vqog%2F2024-04-21_17-44.png?alt=media&amp;token=6de16ea1-c557-42c5-b05f-e311ae9031aa" alt=""><figcaption></figcaption></figure>

Vulnerable to proactive dictionary attacks! (Kerberoasting).

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FMk8ruG7i9hhh1Dhn734o%2F2024-04-21_17-45.png?alt=media&amp;token=ede52e6d-bc6a-41be-8e2a-f2487fbb1c09" alt=""><figcaption></figcaption></figure>

## Scalability

### Authentication scope

Realms.

A kerberos server per realm.

### Inter-realm cooperation

Fundamental to allow a client from a realm to access a server in another realm.

Realms need to trust authentication performed by other realms.

### Protocol

Secret keys are shared between TGS servers of different realms.

* Inter-realm key.
* Each inter-realm key is associated with a trust path.

A client (user) needs to jump from TGS to TGS to get a ticket.

* Not particularly user-friendly.

## Security politics and mechanisms

### Entity authentication

Secret keys, names, and network addresses.

name/instance\@realm (<user@ua.pt>, ftp/ftp.<ua.pt@ua.pt>).

### Validity periods

Timestamps in tickets (hours).

Timestamps in authenticators (seconds, minutes).

### Replay protections

Nonces (in ticket distributions).

Timestamps / sequence numbers (in authenticators).

### Protection against an excessive use of session keys

Key distribution in authenticators.

### Delegation (proxying)

Options and authorizations in tickets.

### Inter-real authentication

Secret keys shared among TGS services, trust paths.

Ticket issuing from a TGS to another TGS.

## Security issues

Kerberos KDC can impersonate anyone. Needs maximum security in its administration.

Kerberos KDC may be a single point of failure. Replication is an option since stored keys are seldom updated.

A stolen user password allows others to impersonate the victim in every service of the realm. Stolen TGS credentials are less risky, as their validity is shortly limited (one day, usually).

## Actual availability

[MIT releases](http://web.mit.edu/kerberos)

Windows versions

* Windows 2000 adopted Kerberos for inter-domain authentication.
* Kerberos was modified to accommodate Windows credentials.

Components

* Kerberos servers/daemons.
* Libraries for “kerberizing” applications.
* Support applications.
  * klogin, kpasswd, kadmin.
* Kerberized applications (clients and servers).