Before 1980, within the campus of MIT, USA computers (mainframe) were used throughout for research works, but they were not available to undergraduates for use, except in Course VI (computer science) classes. But they wanted to make computers available to most undergraduates too, but no department of university was taking any interest, except 3-departments, all related with Computer Science, Engineering, and Electricals. Then two things happened.
First, the School of Engineering in 1982 approached DEC to donate equipment for 'itself. ' DEC agreed to contribute more than 300 terminals, 1600 microcomputers, 63 minicomputers, and five employees to them.
Two, MIT Corporation wanted the project to benefit the rest of the university too, and they approached IBM to donate equipment for rest of MIT. IBM agreed to contribute 500 microcomputers, 500 workstations, software, five employees, and grant funding.
With all this, Project Athena began in May 1983. The project was intended to extend computer power into fields of study outside computer science and engineering, such as foreign languages, economics, and political science, etc.
Initial goals of Project Athena were to:
1. Develop computer-based learning tools that are usable in multiple educational environments
2. Establish a base of knowledge for future decisions about educational computing
3. Create a computational environment supporting multiple hardware types
4. Encourage the sharing of ideas, code, data, and experience across MIT
MIT built computer labs for their users, although the goal was to put networked computers into each student dormitory.
Project Athena ended in June 1991, MIT's IT department took it over and extended it into the university's research and administrative divisions too. The system they made, ATHENA, is still used by many in the MIT community through the computer labs scattered around the campus. It is also now available for installation on personal computers, including laptops.
You might be wandering why I am sharing all this info. There is a reason... Because the Project Athena made highly significant contribution to modern computing as we know and use today. If we use modern terminology, then you would understand better as what they created for us. Here they are:
-
'Client–Server model' of distributed computing using three-tier architecture (read, Multi-tier architecture)
-
'Thin client' (stateless) desktops
-
System-wide security system (e.g., Kerberos encrypted authentication and authorization)
-
Naming service (e.g., Hesiod)
-
X Window System, widely used within the Unix community
-
X tool kit for easy construction of human interfaces
-
Instant messaging (e.g., Zephyr real time notification service)
-
System-wide use of a directory system
-
Integrated system-wide maintenance system (e.g., Moira Service Management System)
-
On-Line Help system (OLH)
-
Public bulletin board system (e.g., Discuss)
This post is focused only on the 'Kerberos' system...
-
What is Kerberos?
Massachusetts Institute of Technology (MIT) developed Kerberos to protect network services provided by Project Athena. There have been 5 versions of Kerberos. Version 1 to 4 were concerned with Project Athena.
In 2005, IETF Kerberos Working Group offered the 'Kerberos Network Authentication Service (v5)'. It clarified many aspects of the protocol and intended use in a detailed and clearer explanation.
In 2007, MIT formed the 'Kerberos Consortium' to foster continued development of Kerberos. Founding sponsors of this consortium include vendors such as Oracle, Apple Inc., Google, Microsoft, Centrify Corporation and TeamF1 Inc., and academic institutions such as the Royal Institute of Technology in Sweden, Stanford University, MIT, and vendors such as CyberSafe offering commercially supported versions.
There is one very interesting story you will enjoy...
In Greek Mythology, there is one God, Hades. He is said to be the god of the dead and the king of the underworld. He has a hound, named Cerberos, and mythology says that Cerberos is a ferocious dog with 3-heads and a serpent tail. Cerberos is the guard of the underworld and prevents the deads to escape the underworld. He was captured by none other than mythical hero 'Heracles.'
And, MIT chose the name Kerberos, on our Cerberos. Interesting. Isn't it?
But in case of Kerberos, the three heads of Kerberos represent three entities:
1. The Client
2. The Server
3. The Key Distribution Center (KDC)
Remember, every Kerberos verification involves KDC. The KDC acts as a trusted third-party authentication service, and it operates from the Kerberos server. All Kerberos authentications take place in Kerberos realms. A realm is a group of systems over which a KDC has the authority to verify users and services.
KDC itself has three main components (three heads again):
3.1 Authentication Server (AS): This server performs 'initial' authentication when a user wants to access a service (resource).
3.2 Ticket Granting Server (TGS): This server connects a user with the 'Service server (SS).' This service server is nothing but any service or resource the users wants to access.
3.3 A Kerberos database: This database stores IDs and passwords of verified users.
Originally, Kerberos was designed for MIT's Project Athena, but today, Kerberos supports a large breadth of functions, including single sign-on (SSO) implementations, and serves as the go-to authentication protocol for websites. Many popular operating systems, including Windows, have Kerberos built in. Kerberos is a widely used service that, like DNS, but most users are not even aware that they are using Kerberos.
Well, Kerberos is an authentication protocol that is used to verify the identity of a user or host. The original idea behind Kerberos is to authenticate users while preventing passwords from being sent over the network or internet.
Kerberos uses 'SYMMETRIC KEY' cryptography and requires trusted third-party authorization (through KDC) to verify user identities.
Kerberos authentication is currently the default authorization technology used by Microsoft Windows, they have been using it since 'Microsoft Windows 2000.' And many other major operating systems too rely upon Kerberos, e.g., Apple MacOS, FreeBSD, UNIX, and Red Hat Linux, Oracle's Solaris, IBM's AIX, HP-UX, etc.
What you need to understand is that Kerberos was and is a vast improvement on previous authorization technologies. The strong cryptography and third-party 'ticket authorization' make it much more difficult for cybercriminals to infiltrate your network. Kerberos has made the internet and corporate networks, and people like you and me, more secure as it enables users to do more work on the Internet and in the office without compromising safety.
Overall, Kerberos is a mature authentication system and has been around for quite a long time. It meets the requirements of modern distributed systems by default. It is architecturally sound too which allow it to evolve and integrate with other systems.
-
How does KERBEROS Authentication work?
Let us assume there is a computer user, named 'Rahul.' Rahul wants to connect to a service, say 'Network File Server' to read an important document. Also assume that the user Rahul (the client), and the service 'Network File Server', both reside within the Kerberos realm. Ok?
-------------------------------------------------------------------------
STEP-1: The User sends a request to access the service
-------------------------------------------------------------------------
Though Rahul is sending a request to connect to service 'Network File Server,' but this request is not directly sent to any service server. With Kerberos, no user can ever authenticate themselves to the service (read, resources they are seeking) directly. Instead, they go through a series of steps performed by different parts of the Key Distribution Center. So what is happening here is that Rahul's request to access the File Server is automatically sent to the Authentication Server (AS) of KDC.
This request is PARTIALLY encrypted with a secret key, i.e., hashed version of Rahul’s password. This hashed version of Rahul's password is a shared key (secret) between Rahul and the Authentication Server (AS) of KDC. You know that hashed version of Rahul's password is already stored in ... Kerberos database. Right?
@
This request is partially encrypted. This request would contain 2-important things:
1. User name as 'Rahul' in plain text
2. The exact Timestamp of the request (but in encrypted form). This 'Timestamp' is encrypted using the hashed version of Rahul's password.
REMEMBER:
A plain text password never reaches the KDC or the Service server. It never travels over the network.
When this partially encrypted request is received by the Authentication Server (AS) of KDC. Then, it picks up the user name 'Rahul' and finds the associated 'hashed version of Rahul's password' in the Kerberos database. Now, it would proceed to decrypt the remaining part of the request, i.e., Timestamp in encrypted form, using the hashed version of Rahul's password. If AS succeed in decrypting and obtains the original Timestamp correctly, then it is established that Rahul is a verified users and the request is genuine.
--------------------------------------------------------------------------
Step 2: Authentication Server issues a Ticket Granting Ticket
--------------------------------------------------------------------------
Since the user 'Rahul' has been verified, now AS would issue a ticket, known as TGT. You need to remember, that it is Authentication Server (AS) who is issuing the TGT, not the Ticket Granting Server (of KDC).
Authentication Server (AS) would now send its response back to the user 'Rahul.'
This response would contain 2-different things:
1. A Session key
This session key belongs to Rahul, and is encrypted with hashed version of Rahul's password. Rahul is expected to be capable of decrypting his session key easily. This session key is with time-expiration. For convenience, you can call this session key, as 'SK1.'
2. A 'Ticket Granting' Ticket (TGT)
This TGT, containing various information, e.g., User name 'Rahul,' Validity period of ticket, the Session key (SK1), the
Privilege Attribute Certificate (PAC) which contains a lot of specific information about Rahul, including his identifier (SID) and all the groups he is member of, IP address, etc. The beauty is that this TGT is also encrypted by Authentication Server, using the shared (secret) of Ticket Granting Server (TGS). Only the TGS and AS know this secret key and nobody else. It means that though Rahul will receive the TGT, but he will not be able to decrypt it.
I would advise you to remember that this is first time when TGS has come into the picture, as its shared (secret) key has been used by Authentication Server to encrypt the TGT.
The job of Authentication Server is over now!
-----------------------------------------------------------
STEP-3: The user sends a request to the TGS
-----------------------------------------------------------
The client, user Rahul is using, would first decrypt the Session Key. At this point, Rahul has his own key (i.e., hashed version of his password) as well as a time-limited session key (SK1) that only he currently knows, and an encrypted ticket (TGT) that contains, among other things, this same session key (SK1). No issue so far!
Now the user 'Rahul' would send a request to Ticket Granting Server (TGS).
@
Like the previous one, this request is also partially encrypted. This request would contain 3-important things:
1. The service he wants to use and the associated host (in plain text). The user also explains the reason for accessing the File Server.
2. The Ticket Granting Ticket (TGT) he is in possession of.
3. An authenticator, which contains his username and current timestamp, all encrypted with the session key (SK1). )
Note: Last time his username was sent in plain text, but not this time. Instead, both user name and timestamp are encrypted and then sent to TGS.)
What you need to remember here is that - this TGS server has no prior idea of any TGT created (by AS) and issued to Rahul. Even, the user Rahul has not idea of the contents of this TGT. Thus, when TGS receives the TGT sent by user Rahul, it has no choice but to check if this TGT is valid or not. I hope it makes perfect sense to you...
In order to check the validity of this TGT, the TGS server would use its own secret key (shared with AS) to decrypt it and decipher its content. If TGS succeeds in decrypting this TGT, then it means that the user Rahul is a valid user and should be granted access to the service (resource) he is seeking. One more thing happens here is that when TGT is decrypted by TGS, it obtains the session key issued to Rahul. Using this, it can now decrypt the Authenticator sent by Rahul and can match the user name with the name mentioned in the TGT.
-------------------------------------------------------------
Step 4: TGS issues a Service Ticket to the user
-------------------------------------------------------------
If the TGT is valid and the user Rahul has permission to access the service 'File Server,' then the process of authentication completes here, and now the user 'Rahul' should be allowed to make a request to the service. Right?
For that thing to happen, TGS needs to issues Rahul a 'Service ticket (TGS).'
Now when Ticket Granting Server (TGS) would send its response back to the user 'Rahul.'
@
This response would contain 2-different things:
1. A New Session key
This session key belongs to 'Rahul-Service Server (File Server)' exchange, and is encrypted with original session key (SK1) which user Rahul is already in possession. Rahul is expected to be capable of decrypting this new session key easily. This session key is also with time-expiration. For convenience, you can call this session key, as 'SK2.'
2. A Service Ticket (TGS)
Since this new ticket has been issued by TGS server (not AS), it is called TGS only, not TGT. This service ticket contains the client ID, client network address, validity period, and new 'Client/server session key (SK2).' This service ticket is also encrypted with a secret shared key of the 'Service server' (File Server, here).
---------------------------------------------------------------
STEP-5: The user sends a request to the service
---------------------------------------------------------------
The client, user Rahul is using, would first decrypt the new Session Key (SK2). At this point, Rahul has his own key (i.e., hashed version of his password), his own session key (SK1) that only he currently knows and a new time-limited session key (SK2) , and an encrypted ticket (TGS) that contains, among other things, this same session key (SK2). No issue so far!
Now the user 'Rahul' would send a request to service Server (i.e., File Server) to get access.
@
Like the previous one, this request is also partially encrypted. This request would contain 3-important things:
1. The service he wants to use and the associated host (in plain text).
2. The Ticket Granting Ticket (TGS) he is in possession of.
3. A new authenticator, which contains his username and current timestamp, all encrypted with the new session key (SK2).
In order to check the validity of this TGS, the service server/resource (i.e., File Server) would use its own secret key (shared with TGS) to decrypt it and decipher its content. If service server succeeds in decrypting this TGS, then it will obtain the SK2 among other things. Using this SK2, it can now decrypt the Authenticator sent by Rahul and can match the user name with the name mentioned in the TGS.
When the user name 'Rahul' matches with the details contained in the TGS, then service server/resource grants access to it.
----------------------------------------------------------
Step 6: User access the service or resource
----------------------------------------------------------
Since the user name 'Rahul' has matched with the TGS, the file server allows the user to open the document. The TGS (just mentioned above) however, determines how long the user has access to the record.
Once access expires, the user 'Rahul' needs to go through the entire Kerberos authentication protocol again.
That's about it!
-
For my readers of Cybersecurity PRISM who have struggled to grasp the whole process of Kerberos authentication, they need to understand these things, that:
1. There are 3-entities: The User, The Server (service/resource), and KDC
2. There are 3-components of KDC: Authentication Server (AS), Ticket Granting Server (TGS), and Kerberos database
3. There are three secret shared keys: Hashed version of user's password, Session Key (SK1), and client-server session key (SK2). No key is used again.
4. There are 3-exchanges of information: between the client (user) and AS and vice a versa, between the client (user) and TGS and vice a versa, between the client (user) and the service/resource and vice a versa
I hope, in the light of above thoughts, you would be better able to understand the whole process of Kerberos authentication.
-
-
Kindly write 
your comments on the posts or topics, because when you do that you help me greatly in 
designing new quality article/post on cybersecurity.
your comments on the posts or topics, because when you do that you help me greatly in designing new quality article/post on cybersecurity.You can also share with all of us if the information shared here helps you in some manner.
Life is small and make the most of it!
Also take care of yourself and your beloved ones…
With thanks,
Meena R.
______
This Article Was Written & published by Meena R, Senior Manager - IT, at Luminis Consulting Services Pvt. Ltd, India.
Over the past 16 years, Meena has built a following of IT professionals, particularly in Cybersecurity, Cisco Technologies, and Networking...
She is so obsessed with Cybersecurity domain that she is going out of her way and sharing hugely valuable posts and writings about Cybersecurity on website, and social media platforms.
34,000+ professionals are following her on Facebook and mesmerized by the quality of content of her posts on Facebook.
If you haven't yet been touched by her enthusiastic work of sharing quality info about Cybersecurity, then you can follow her on Facebook:
Click Here to follow her: Cybersecurity PRISM