#SystemArchitecture Series: #Kerberos Architecture Component and communication flow #architecture #Kerberos is a ticketing-based #authentication #system, based on the use of #symmetric keys. #Kerberos uses tickets to provide #authentication to resources instead of #passwords. This eliminates the threat of #password stealing via #networksniffing. One of the biggest benefits of #Kerberos is its ability to provide single sign-on (#SSO). Once you log into your #Kerberos environment, you will be automatically logged into other applications in the environment. To help provide a secure environment, #Kerberos makes use of Mutual #Authentication. In Mutual #Authentication, both the #server and the #client must be authenticated. The client knows that the server can be trusted, and the server knows that the client can be trusted. This #authentication helps prevent man-in-the-middle attacks and #spoofing. #Kerberos is also time sensitive. The tickets in a #Kerberosenvironment must be renewed periodically or they will expire.

1. Welcome to TechGurukul
dwivedishashwat@gmail.com

2. System Architecture Series:
[Kerberos]
Learning Architecture of and
various components in a technology system

3. 1. Kerberos is a ticketing-based authentication system, based on the use of
symmetric keys. Kerberos uses tickets to provide authentication to resources
instead of passwords. This eliminates the threat of password stealing via
network sniffing. One of the biggest benefits of Kerberos is its ability to provide
single sign-on (SSO). Once you log into your Kerberos environment, you will be
automatically logged into other applications in the environment.
2. To help provide a secure environment, Kerberos makes use of Mutual
Authentication. In Mutual Authentication, both the server and the client must be
authenticated. The client knows that the server can be trusted, and the server
knows that the client can be trusted. This authentication helps prevent man-in-
the-middle attacks and spoofing. Kerberos is also time sensitive. The tickets in a
Kerberos environment must be renewed periodically or they will expire.
About Kerberos

4. 1. Client: User/system/service which want to call another service/server. E.g : suppose want to access any resource on any service/server which is
Kerberos enabled.
2. Server
1. KDC: This is basically the Key distribution server which has following components:
1. Authentication Server : Authentication Server is the part of the KDC which replies to the initial authentication request from the client, when the
user, not yet authenticated, must enter the password. In response to an authentication request, the AS issues a special ticket known as the
Ticket Granting Ticket, or more briefly TGT, the principal associated with which is krbtgt/REALM@REALM.
2. Ticket Granting Server : Ticket Granting Server is the KDC component which distributes service tickets to clients with a valid TGT, guaranteeing
the authenticity of the identity for obtaining the requested resource on the application servers. The TGS can be considered as an application
server which provides the issuing of service tickets as a service
3. Principle Database : container for entries associated with users and services. We refer to an entry by using the principal, It contains :
1. The principal to which the entry is associated;
2. The encryption key and related kvno;
3. The maximum validity duration for a ticket associated to the principal;
4. The maximum time a ticket associated to the principal may be renewed (only Kerberos 5);
5. The attributes or flags characterizing the behavior of the tickets;
6. The password expiration date;
7. The expiration date of the principal, after which no tickets will be issued.
3. Realm : The term realm indicates an authentication administrative domain. Its intention is to establish the boundaries within which an authentication
server has the authority to authenticate a user, host or service. This does not mean that the authentication between a user and a service that they must
belong to the same realm: if the two objects are part of different realms and there is a trust relationship between them, then the authentication can take
place. This characteristic, known as Cross-Authentication
Components Terms in Kerberos

5. 1. Principal : A principal is the name used to refer to the entries in the authentication server database. A principal is associated
with each user, host or service of a given realm.
2. Ticket : A ticket is something a client presents to an application server to demonstrate the authenticity of its identity. Tickets
are issued by the authentication server and are encrypted using the secret key of the service they are intended for. Since this
key is a secret shared only between the authentication server and the server providing the service, not even the client which
requested the ticket can know it or change its contents.
3. Encryption : Kerberos often needs to encrypt and decrypt the messages (tickets and authenticators) passing between the
various participants in the authentication. It is important to note that Kerberos uses only symmetrical key encryption (in other
words the same key is used to encrypt and decrypt.
1. Kerberos 4 supports DES 56-bit
2. Kerberos 5 supports DES and AES keys with 128 and 256 bit.
4. Salt : This is a string to be concatenated to the unencrypted password before applying the string2key function to obtain the
key. Kerberos 5 uses the same principal of the user as salt: Kuser = string2key ( Puser + "user@REALM.COM" )
5. Key versions number kvno: When a user changes a password or an administrator updates the secret key for an application
server, this change is logged by advancing a counter. The current value of the counter identifying the key version, is known
as the Key Version Number or more briefly kvno.
Components Terms in Kerberos

6. Learning about Kerberos Architecture and Components
Server/Application/Service
which uses need to access
(HDFS/NFS/SSH)
Database
User id/secret key
Service id/secret key
etc
1
2
3
4
5
6

7. Communication Diagram

8. 1. Ticket Request from client
2. Ticket Sent from KDC
3. Service Ticket request form Client
4. Service ticket sent from KDC
5. Ticket Presented to Application Server
6. Open access channel for application to access service.
Authentication Flow

9. 1. Shashwat to KDC Hi, I’m Shashwat. Could I have access to the AuthServer?
2. AuthServer to Shashwat Here is your “ticket-granting ticket.” If you aren’t Shashwat, it’s
useless. If you are Shashwat, decrypt this, and come back with the answer.
3. Shashwat to TGS Okay, I figured out your secret. Give me a “service-granting ticket” so I can
talk to server Application_Server_OR_Service.
4. TGS to Shashwat You have it! It’s encrypted using the same mechanism as before, and then
encrypted with Application_Server_OR_Service's password. This ticket will be accepted by
Application_Server_OR_Service for eight hours.
5. Client to Application_Server_OR_Service The KDC gave me this ticket, and it is encrypted
using your password. Please Validate me.
6. Application_Server_OR_Service to Shashwat Hello, Shashwat! I’ve decrypted what you got
from the KDC, I trust the KDC, and he trusts you, so your access is granted.
Steps

10. Request Types

11. Thanks For Watching
—-TechGurukul—-
Please support our channel by just liking
Subscribing and pressing bell icon.
dwivedishashwat@gmail.com