Use Kerberos, Do Nothing

More than a Java library, its a network protocol.

Nope you don’t know Kerberos. There’s a lot that happens behind the scene and to not ignore the efforts that a **DBA(Database Administrator)** must have put in to actually enable your schemas and database users to actually allow your Java application to connect to the database via Kerberos. The more interesting part is people don’t really talk about it.

I’m Tired!

I’m tired, of seeing blogs on the internet to understand, what the heck is Kerberos. All of them are big-big written scripts seeming like I’m reading a manual for a machine that I even don’t want to assemble. So here’s my small effort to tell what is it that actually Kerberos does, in might be a simpler way.

Imagine you are a Targaryen, dragons belong to you. Nobody else in the seven kingdoms can ride on a dragon.

In Westeros, want my Iron throne back.

Just like that, a server /resource can be accessed by some particular number of users only. Security has two buzzwords often interpreted as same but actually are way apart: Authentication & Authorization. Authentication gives you your true identity whereas Authorization gives you access, your entitlements. Just like to be a potential heir you must have a dragon (authority) but its ultimately counsel that decides if you will ascend on the iron throne or not (access).

Imagine you are a Targaryen, dragons belong to you. Nobody else in the seven kingdoms can ride on a dragon.

Whenever a user tries to access some resources in a Kerberized environment, there are two major steps that are involved: Ticket Issuing ( Authentication via Ticket Granting System), Service Request.

Dragons, your ticket to the Iron throne

Everyone Says Targaryens Are Closer To Gods Than To Men, and dragons are no less than lords. Its your time to say “lykirī, dohaerās, drakarys” and make a dragon accept you as a rider. You gotta have that it factor , right?

Well its not that dramatic when it comes to authenticating users. A Ticket Granting Ticket(TGT) is all you need to get your keys and for any server to identify you as a credible client. The Key Distribution Center(KDC) is responsible for your TGT. kinit is the command that interacts with KDC to generate a TGT.

kinit -f <NetID/Principle Name>

Running Kinit asks you to enter your system password, the generation of TGT by kinit is a one time activity and not related to your access to servers, that’s why Kerberos is widely identified as “password-less authentication”. You can read more about kinit command here.

The mapping between you as a user and the service is to be done. For which your KDC should identify you as well as the services you are trying to access. Certain parameters are used as an identification metric, out of which, one is principle name. All the possible principle names, paths, hostnames, mapping of these hostnames, the realm of interests, are generally stored in one file (krb.conf or kdc.conf are used sometimes).

TGTs generally expires after sometime, even the time for expiration can be set in the krb.conf files. Your scripts generally reads this file via the environment variable KRB5_CONFIG. For Unix/Linux OS this file sits in the / etc directory. Kinit command bundles the following set of information to KDC: NetID/Principle Name, your IP address, the service you want to access (this could also be a domain in a Active Directory), lifetime of a TGT.

NetID is the unique identification given to a particular user in a AD domain or a computer in a LAN like set ups.

The KDC checks if the user exists in the database. On successful search the KDC replies back with two message with the following information:

Message1: NetID, TGS ID, Timestamp, IP Address, lifetime of TGT, TGT, Session Key
Message2: TGS ID, Timestamp, Session Key

KDC is not dumb, all the messages that it returns are encrypted and not just random encryption. The second message is encrypted using the user’s password and your NetID and realm ( for eg: iamjohnsnow@HOUSE.TARGARYEN, with iamjohnsnow being your NetID and HOUSE.TARGARYEN being the realm of Kerberos). This encryption is what makes Kerberos so suitable for AD services.

Train your dragon

A dragon that lets you sit on its back is not good for war yet, you have to train. Similarly having your TGT is not enough, why so, if you may ask. Well because its encrypted and if its encrypted your servers can’t identify you. The user one more time interacts with KDC to get a session ticket.

Message1: Service Ticket, NetID, IP Addresses, Validity Period, Service Session Key
Message2: Service Session key encrypted with your Session Key

War has Come

One step away from the Iron Throne, its your war, you have the dragons, concur the realm. For one last time, “Drakarys”.

Whenever you interact with any service you send two messages, the Message1 you received from KDC last time and new authenticator. Authenticator is a combination of your client ID/NetID and timestamp. Authenticators are always encrypted with session key.

The service after decrypting your authenticator, gets your client ID/NetID, matches it with previous messages, in some cases from the database, if they match gives you the access. As a positive ACK (PACK) timestamp encrypted with session key is sent back. Wider access to the services by the decryption of the timestamp sent in the last PACK can be used for authorization. And yes, you have become the protector of the realm, quite a journey, huh?