StudyMoose App
24/7 writing help on your phone
Save to my list
Remove from my list
A third party authentication service, Kerberos, developed at MIT is used to verify users and keep us safe from sniffer programs. The essay focusses on how Kerberos authentication service and key authentication works. It will also demonstrate the advantages and limitations of Kerberos authentication service.
The term Kerberos was acquired from Hades three headed dog, a Greek mythological character, whose responsibility was to protect the living from the world of dead just like how Kerberos security system guards' electronic transmissions that get sent across the network.
Kerberos scrambles the information encrypts it so, only the computer that's supposed to receive the information can decrypt it. Furthermore, it makes sure that the password never gets sent across the wire: solely a scrambled "key" to the password is sent. The design for Kerberos protocol started out in the late 1980s at the Massachusetts Institute of Technology (MIT). It is a secure authentication mechanism designed for distributed servers, which assumes the network is unsafe.
4.9 (984)
“ Ok, let me say I’m extremely satisfy with the result while it was a last minute thing. I really enjoy the effort put in. ”
The client and server mutually authenticate before they establish a connection. Kerberos version 4 was the first release which lead to another version (v5) in 1993 after a huge public review.
This protocol followed the IETF standard process and its specifications are outlined in RFC 1510. Originally designed for UNIX and is currently available for all major operating systems, freely from MIT or also through commercial versions.[1]Secure communication has now become a vital thing more than ever and most organizations prefer to use network infrastructure to perform their businesses. The main factor that leads to secure communication over the distributed infrastructure is authentication, the process of ensuring the identity of any user or process.
Kerberos is widely used to address the authentication part and it acts as a major building block to ensure a secure networked environment. Kerberos authentication is used by Microsoft Windows, and implementations of Kerberos exist in Apple OS, FreeBSD, UNIX, and Linux. Microsoft introduced their version of Kerberos in Windows2000. It has also become a standard for websites and Single-Sign-On implementations across platforms.Key Distribution Centre in cryptography is responsible for providing keys to the users that share sensitive data over the network. Every time a connection is established between two computers, both request the KDC to generate a unique password which can be used by the end system users for verification.
The Initial report published on Kerberos [STEI88] indicated the following requirements: Reliable: The lack of availability of the Kerberos service for all the services dependent on it for access control means lack of availability of the supported services. Hence, Kerberos should be exceptionally reliable and should use distributed server architecture, with one system able to back up the other. Secure: Any network tapper should not be able to obtain the necessary information to impersonate or mimic a user. Moreover, Kerberos should be strong enough that a potential impersonator does not find it to be the weak link. Scalable: The system should be competent enough to support large number of clients and servers. This demonstrates that a modular, distributed architecture should be used. Transparent: Preferably, the user should not be aware about the authentication taking place, except the requirement to enter his/her password.Kerberos (Version 4) used Data Encryption Standards to provide authentication service.
According to a property of DES, if cipher text (encrypted data) is decrypted with the same key as the one used to encrypt it, the plaintext (original data) appears. If different encryption keys are used for encryption and decryption, the result will be garbled, and the checksum in the Kerberos message will not match the original data. This amalgam of encryption and the checksum provides integrity and confidentiality for the encrypted Kerberos messages. In an unprotected network environment, any client can communicate to any server for any specific service. There is an obvious security risk of impersonation. Any opponent can pretend to be a client and gain unauthorized privileges on server machines. To counter this threat, servers must be able to confirm the identities of clients who request service. Every server is required to undertake the task for each client/ server interaction, but in an open environment, this places a substantial burden on each server.An alternative way is to use an authentication server (AS) that knows the passwords of all users and stores these in a centralized database. Furthermore, the authentication server shares a unique secret key with each server. These keys are distributed physically or in some other secure manner
Kerberos is typically used when a user on a network is attempting to make use of a network service, and the service wants assurance that the user is the actual user and not an impersonator. So, the user presents a ticket that is issued by the Kerberos authentication server (AS). Then the service examines the ticket to verify the identity of the user. If all the boxes check out, then the user is accepted and granted access. Therefore, this ticket should contain information connecting it in an infallible manner to the user. Since the user and the service don't meet, a picture is of no use. Therefore, the ticket must indicate that the bearer knows something only its intended user would know, for example, a password. Furthermore, there must be a defence mechanism against an attacker trying to steal the ticket and use it later. The process flow has been divided into 5 steps to reduce complexity.
Considering an example, A client wants to establish a secure connection with the server. Both client and the server decide to involve Kerberos protocol to ensure their identities, the Kerberos protocol uses symmetric key cryptography where a single key is generated and used for both encryption and decryption. The key is needed by the server to confirm the originality of the client, before it processes the message. For this, they use the information of a shared secret key to confirm the identity of the end party.The client then sends a message that includes the client's name in plain text and an authenticator in encrypted form using a secret key. The authenticator is nothing but a data structure that includes two fields, first field includes the client's name and the second field has the timestamp on the client's workstation.
After the message is received by the server it extracts the client information by decrypting the authenticator with the same secret key and then verifies the timestamp to the current time on the server, if the difference is within the acceptable skew, the server decides the message is possibly from Client. If in case the time exceeds then the server automatically rejects the message. The authenticator is mainly used to avoid replay attacks. Usually, replay attacks occur when an attacker steals the message from the middle and then resends it to the server as if it was the original the user. The server rejects the message if the time skew is more than permissible differences, it limits the possible replay attack. The server then encrypts client's timestamp with the secret key and sends it back. Since the server sends only, the client can confirm that no one else has received the message except the server as only the server can decrypt and use the timestamp details. If both times match, the client can be confident that his message reached server who is aware about the secret key.
Both, the client and the server utilize a similar secret key and the client should need to communicate with a few different servers and it needs a key for each server. So also, the server may communicate with numerous clients and it will require a key for each client. In this manner, it is badly arranged to store and verify different keys on numerous frameworks. The Key Distribution Centre (KDC) is an answer to this issue. KDC accommodates a database that incorporates account data of whole security principals. The cryptographic key, known as a long-term key, that is utilized in correspondence between the KDC and security principal, is one of the record data in that database. On the off chance that a client needs to communicate with the server, it sends a solicitation to the KDC first and after that KDC circulates a session key for both client and server in a scrambled structure where the client's duplicate is encoded with the client's long-term key and server duplicate with server's long-term key.C. Session key transmission in Session TicketsOnce the client gets the session key, it sends a message to the server at any time. In that case, 2 very important situations arise.
First being, if a client decides to communicate later, the server needs to store the session key that it received from KDC and it is required to remember the client key to handle every time he asks for service. Furthermore, due to network traffic and congestion, the server might not receive the session key from KDC before the client's request. Hence, the server might also need to suspend its reply while it is waiting to receive a key from the KDC. To avoid this, instead of sending the session key to the server, the KDC sends the server's copy of key in the form of Session Ticket to the client.As a response to the client's request, KDC sends both copies of the session key to the client and the client's copy is encrypted with client's long-term key, whereas the server's session key is sent in a Session key.
The client then becomes responsible to manage the session ticket until it successfully reaches the server. So, it ensures that no harm happens if the message from the KDC reaches the wrong hand as the client's copy of session key can only be fetched by someone who is about the secret key and server's copy of session key can only be extracted by someone who is aware about the server's secret key.After receiving the response from the KDC, the client then sends a message to the server when it wants to communicate. During this authentication process, the client sends the message that includes the authenticator encrypted with the session key that was received from the KDC and the session ticket. Now the session ticket and authenticator together act as the client's identity credentials.
Now when the server receives the message, it decrypts the session ticket using the secret key (server long term key) which is shared between the server and KDC and then extract the session key to decrypt the authenticator. After verifying the client's timestamp, it responds with the encrypted timestamp as discussed in step 1D. Ticket Granting ticketsNow, the client's session key that is sent from KDC to the client is encrypted using a client's long-term key. Here, the client's long-term key is taken from the credentials that are used to log-on to the client's workstation by using the one-way hash function. On the other hand, KDC extracts its copy of client's long-term key from his account record in the database. To further enhance the security, the long-term key is replaced with the session key.
After generating a long-term key when the client logs on at his/her workstation, it sends a request to the KDC for session key that is required for communication between the client and the KDC. Once the KDC receives the request from the client, it fetches it's long-term key from the database and responds back to the client with a session ticket called as a Ticket Granting Ticket (TGT), which includes the session key that is going to be used by the KDC while communicating with the client. With TGT, the response message also incorporates the session key for the client to use in communication with the KDC. The TGT is encrypted with the long-term key of KDC and Client's session key is encrypted with the client's long-term key.Once the client receives the message from the KDC, it extracts the session key by decrypting it with its own copy of the long-term key. After fetching the session key, the client will discard the long-term key and will begin to use the session key for further communication with the KDC. the session expires once the TGT gets expired.
The client must get the session ticket from the KDC to request a service from the server. So, the client sends a message that includes TGT and the authenticator that is encrypted using the session key shared between client and KDC. The operation of the KDC is divided into two parts in order to work across the domain:1. Authentication Service: issues TGTs2. Ticket-granting Service: issues Session TicketsOn receiving the message from client, the KDC and the ticket-granting service verifies the request and sends the session ticket and session key as discussed in step 3. The appropriate use of authentication procedures, which don't disclose identity credentials is mandatory. The Kerberos protocol is well-suited for such environments.
Version 4 was targeted mainly for project Athena and in some areas, it makes assumptions that are not universally accepted. Some sites use functionalities that version 4 does not provide. Version 4 used only DES from USA, which is restricted by the government to use elsewhere. It requires usage of IP addresses thus, making it unsuitable for some environments. It has no provision for authentication forwarding. Since, it has double encryption it leads to wastage of processing time and resources. Several attacks like replay and password attacks are unavoidable in version 4. Inter-realm authentication is easy to implement but requires multiple key exchanges which makes it an expansive task
Kerberos version 5 was taken into consideration in 1989 to solve the limitations of version 4 and to provide additional functionality. In version 5, the encryption module was separated into multiple different software modules which can be modified and used by the programmer in various ways. The length and type field are attached to the protocol messages, so it becomes easy to interpret. There is no need to specify the encoding independently as done in version 4. The ticket is split into 2 parts: encrypted and plain text. The ticket also contains a new field for flags. Every realm is interoperable and optimizable.
Kerberos is not very effective against password guessing attacks, if a user chooses a fairly poor password, then the attacker can guess that password and impersonate the user. Also, Kerberos requires a trusted path through which passwords are entered. If the user enters the password for a program that has already been modified by an attacker (a Trojan horse), or if the path between the user and the initial authentication program can be monitored, then the attacker might obtain enough information to impersonate the user. Kerberos combined with other techniques can address these limitations. It surely does not protect all messages sent between two computers but protects the messages from software that has been written or modified to use it. Kerberos does not provide authorization, but V5 Kerberos passes authorization information generated by other services. Thus, Kerberos can be used as a base for building multiple different distributed authorization services. The weaknesses of Kerberos can be summarized as follows: It requires continuous availability of KDC. When the server is down, the system becomes vulnerable to a single point of failure. This can be overcome by using multiple servers. The password guessing attacks cannot be resolved by Kerberos. There are no specific standards for Kerberos administration. The system clock needs to be synchronized to keep the authentication from failing.
Authentication is critical for the security of computer systems. Without knowledge of the identity of a principal requesting an operation, it's difficult to decide whether the operation should be allowed. Traditional authentication methods are not suitable for use in computer networks where attackers monitor network traffic to intercept passwords. The use of strong authentication methods that do not disclose passwords is imperative. The Kerberos authentication system is well suited for authentication of users in such environments.
Kerberos Authentication and Key Distribution. (2019, Aug 20). Retrieved from https://studymoose.com/kerberos-authentication-and-key-distribution-essay
👋 Hi! I’m your smart assistant Amy!
Don’t know where to start? Type your requirements and I’ll connect you to an academic expert within 3 minutes.
get help with your assignment
