Understanding kerberos: The single sign on authentication system

The full definition of kerberos is a secure, single sign on, trusted, third party, mutual authentication service. Let’s break that definition and quickly check on each one.

• Secure: Kerberos is unique in it’s use of tickets , a cryptographic measure of transmitting messages over network to provide users identity. Instead of passing messages over network.
• Single-sign-on: This means that user need to login only once to access all the services that support kerberos.
• Trusted third party: This means that all the authentication requests are routed through the centralized kerberos server.
• Mutual Authentication: Ensures that not only the person behind the keyboard proves who he claims to be, but also the server he is communicating with who it claims to be.

Kerberos Terminology and concepts

Now let us look at into terms that is specific to kerberos authentication system.

Principals, Realms and Instances

Principals: Every entity contained within kerberos installation including individual users, computers and services running on servers has a principal associated with it. Each principal associated is associated with a long term key. This can be a password or a passphrase. Every principal starts with a username followed by an optional instance.

instances: An instance is used in two situation for service principals(services that user needs access into ) and in order to create special principal for administrative use (when administrators need elevated privileges)

Realm: The username and optional instances taken together, form a unique identity within a given realm. Each kerberos installation defines an administrative realm of control that is distinct from every other kerberos installation. For example kerberos realm for a DNS name is its domain converted to uppercase that if example.org is the domain name the realm name would be EXAMPLE.ORG

Service and host principals

Users aren’t the only ones assigned to the kerberos realm. Hosts and services also have principals since in kerberos each endpoint can request mutual authentication, both endpoints require an identity and a key.

Kerberos principal name

An example of kerberos 5 principal name would be as follows.

username[/instance]@REALM 
service/fully-qualified-domain-name@REALM
joedoe/admin@EXAMPLE.ORG

The above example implies that joedoe has admin privileges at the EXAMPLE.ORG realm.

Keys,Salts and passwords

A method called String2key is used to convert alphanumeric keys into an encryption key. Salt is a sequence of characters that is added to password to make it more unique.

Key Distribution Center

The key Distribution Center (KDC) is an integral part of the kerberos system. The KDC consists of three components.

Authentication server(AS): Issues an encrypted Ticket Granting Ticket (also known as TGT) to clients who wish to log into the kerberos realm. TGT is encrypted with user’s password since only user and KDC know the secret password when the user attempts login only correct password can decrypt the key, attempt to login with wrong password will prompt to login again.

Ticket Granting Server(TGS): Ticket Granting Server issues individual service tickets based on two piece of data from the client.

• Principal name which represents the service client wants to access.
• TGT key issued by the authorization server

Database: Stores principal components and the associated keys.

Putting all the pieces together

Now let us look put all the pieces together and look into the working of kerberos 5.

Authentication flow

Kerberos authentication flow

• Request from the client to the Authentication Server, request will contain user principal name and timestamp. Encrypted using user’s password.
• Tries to decrypt the message for successful decryption it will return TGT and TGS session keys.
• Send request to the TGS server with TGT key.
• TGS validates TGT for successful validation it will return service ticket(TGS).
• Encrypt TGS with session key and message is send to the application server for authentication.
• Application server tries to decrypt the server and allows the access.

Pre-Authentication

kerberos 5 introduces per-authentication. Require users to prove identity before KDC issue ticket for a particular principal.

If user tries for a login and require pre-authentication KDC will send a KRB_ERROR instead of AS_REP. This message will tell the client that pre-authentication is required.

AS exchange with pre-authentication

Kerberos ticket types

Forwardable tickets: User can forward ticket into another host, a common use case is user acquire a TGT, and this ticket can be forwarded into another host. User does not need to enter password in the receiver host system.

Proxiable tickets: You can set proxiable flag on a ticket. This is similar to forwardable ticket this can be send to another host and can be used to get further service tickets.

Renewable tickets: The ticket is valid only until a standard duration of lifetime after that it can be submitted to KDC for renewal.

Postdated tickets: These tickets are not valid until a particular date in the future. Useful for the jobs scheduled in the future.