Kerberos

Properties
=========
– Kerberos is a authentication protocol
– Credentials never flow through network in this case
– Kerberos uses symmetric keys.

How it works
===============
1. When you login early in the morning to your system first, you provide login user ID (User Name). So think your system as a client.

2. User name goes to KDC(key Distribution Center – which has AS(Authentication Server), DataBase(to store keys of services, users and servers) and TGS (Ticket granting Server).

3. Now KDC, checks its db if the user is present or not, and generates 2 things ::
3.1 A TGT(ticekt granting ticket-which has username+client IP+Kerberised name) for the user which in encypted by KDC’s private key.
3.2 A session key[KDC-Client session key]
both the things travels in a packet which is encrypted by the user’s private key(password)from KDC to client/user.[KDC-Client session key]

4. Now the packet gets decrypted at the client’s system using user’s private key. The session key isolated from the packet, but TGT is still in encrypted form, because it was encrypted with the KDC’s private key which is only with KDC in its db.

5. When client tries to access any service of application server(say ssh server), it has to prove its identity to Application server while client has already proved its identity to KDC and got the encrypted TGT.

6. Client will send request to KDC ::
1. A authenticater(User name,IP,time stamp) which is encrypted with the session key[KDC-Client session key] got from KDC AND
2. Already encrypted TGT
3. This whole packet (authenticater+TGT) encrypted by the session key[KDC-Client session key].

7. KDC will receive this packet request from client for SSH service, it decrypts the packet using session key[KDC-Client session key]
1. KDC will decrypt the TGT using its private key and matches it with the authenticator’s details.
2. If details matches, KDC will generate a Ticket for the client which will have username,client IP and service name. Which will be encrypted using the application server’s private key.
3. With Ticket, KDC will also send another session key which is client-application session key.
4. Now, this packet (Ticket for app server + Client-appServer’s session key) will be encrypted using session key[KDC-Client session key] and sent from KDC to client.

8. Now Client has received the packet encrypted with [KDC-Client session key], it decrypts it and got the Ticket for app server along with the session key of client and KDC server. But Ticket is still encrypted as it is encrypted using App Server’s private key.
1. Client send the Ticket+Authenticator to App server which is now encrypted using the session key of client and app server’s session key.
2. App server receives the packet request from the client, it has the session key to decrypt the packet and isolate the Ticket.
3. App server decryptes the Ticket using its own private key and check for the access and responds back.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s