Wednesday, 25 June 2014

Kerberos mechanism explained

Understanding the mechanism behind kerberos.

How does kerberos work ?

This part of the article will explain the mechanisms behind Kerberos: 
Ticket exchange principles
Key Distribution Center(KDC)
Authentication mechanisms.

A commonly found description for Kerberos is "a secure, single sign on, trusted third party
mutual authentication service". It doesn't store any information about UIDs, GIDs, or home's
path. In order to propagate this information to hosts, you will eventually need yellow page
services: NIS, LDAP, or Samba

As Kerberos is only dealing with Authentication, it does neither Authorization, nor Accounting. it delegates those to the services requesting Kerberos' help for user's identification. Anyway, Kerberos being a "service" by itself, it can partially provide such functionalities, but in a very limited range.

Ticket Exchange Service

Kerberos' communication is designed to provide a distributed secure authentication service, through secret key cryptography.

For a user, the secret key is his "hashed password" (the password is reworked through a one-
way hash function and the resulted string is used as a key), usually stored in the Key
Distribution Center. For a service, the key is a random generated sequence, acting like a
password; it is also stored in Key Distribution Center, and in a file called a keytab on the
machine's service side.

The Kerberos communication is based around tickets. Tickets are a kind of encrypted data
scheme that is transmitted over the network, and stored on the client's side. The type of storage
depends on the client's operating system and configuration. Traditionally, it's stored as a small
file in /tmp, for compatibility reasons

The main central part of a Kerberos network is the the Key Distribution Center (KDC). It
consists of three parts:

• an Authentication Server, which answers requests for Authentication issued by clients.
Here, we're in the AS_REQUEST and AS_REPLY challenging part (see below for details),
where the client gets a Ticket Granting Ticket (TGT).

• a Ticket Granting Server, which issues Ticket Granting Service (TGS) to a client. This is
the TGS_REQUEST and TGS_REPLY part, where a client gets a TGS that allows him to
authenticate to a service accessible on the network.

• a database, that stores all the secret keys (clients' and services' ones), as well as some
information relating to Kerberos accounts (creation date, policies, ...).

Authentication mechanism—Ticket Granting Tickets  

AS_REQUEST & AS_REPLY, in conclusion Authentication mechanism can be represented as below which is self explanatory.

Service's use mechanism—Ticket Granting Service

TGS_REQUEST & TGS_REPLY in conclusion service's use mechanism can be represented as below which is self explanatory.


We can divide the Kerberos protocol into three main steps:

1. Authentication process, where the user (and host) obtain a Ticket Granting Ticket (TGT)
as authentication token,

2. Service request process, where the user obtain a Ticket Granting Service (TGS) to access
a service,

3. Service access, where the user (and host) use TGS to authenticate and access a specific

The service access step is not really Kerberos related, but merely depends on the service we are
authenticating to.

The below tutorial will explain the same in simplicity. 

I would further write an article to demonstrate deploying kerberos on Linux.