1. After TGS verifies the client’s identity, TGS will issue a ticket to the clie
ID: 3599445 • Letter: 1
Question
1. After TGS verifies the client’s identity, TGS will issue a ticket to the client. What information items are included in this ticket?
2. After a while, the client will receive the ticket. Then (in Step 5), the client will send the ticket to the server. However, this ticket itself is NOT sufficient for the server to offer the service to the client because John may launch a serious attack.
What can this attack do to fool the server?
3. Because of the problem mentioned in Question 8, the client also needs to send another authenticator to the server. The authenticator will be encrypted by which key?
4. When the Server receives the authenticator and the ticket from the client. The server will compare the information items contained in the authenticator and the ticket to authenticate the client user’s identity.
How much of a comparison will be done? Please give a detailed answer.
5. To avoid letting every server know every user’s password, Kerberos wants to enforce the ticket-based service access idea. However, this idea is facing three security threats. What are they?
Explanation / Answer
Preface:
The question is related to computer network authentication protocol named as Kerberos. It works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to each other in a secure manner. Here the servers are AS: AuthenticationServer (step 1), TGS: Ticket Generating Server (step 2), SS: Service Server (Step 3).
The first steps of this client-server based login system are:
2. Client Service Authorization
3. Client Service Request
In the first step (i.e. Client Authentication), initially when the user requests for services the client machine sends a message to the server containing the user ID.
The server then checks for the existence of the client in the database, if found affirmative existence then the server generates a secret key by hashing the password of the user found in the database and sends back two messages to the client:
· Message 1: Client/TGS Session Key encrypted using the secret key of the user.
· Message 2: Ticket-Granting-Ticket (TGT, which includes the client ID, client network address, ticket validity period, and the client/TGS session key), encrypted using the secret key of the TGS.
In the second step (Client Service Authorization) while requesting services, the client sends the following messages to the TGS:
· Message 3: Composed of the TGT from message 2 and the requested service ID.
· Message 4: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Message 1 (Client/TGS Session Key).
Answer to Question 1:
Upon receiving messages 3 and 4, the TGS retrieves message 2 out of message 3 as it has the TGT. It then decrypts message 2 using the TGS secret key. Now it gets ‘client/TGS session key’. Using this key, the TGS decrypts message 4 and compare client ID from message 3 and 4, if they match, server sends the following two messages to the client:
· Message 5: Client-to-server ticket (that includes, just like the TGT, the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key.
· Message 6: Client/Server Session Key encrypted with the Client/TGS Session Key.
Answer to Question 2:
It is to observe from the above mechanism that, the client has to use his password only once. The password is not sent over the network in text. However, the ticket can still be stolen by John, and he can launch a replay attack.
A replay attack takes place when an intruder (i.e. John) steals a packet from the network and forwards that packet to the service server as if the intruder was the client who originally sent the packet. Here as the packet is as authentication packet, so, John can launch replay attack to authenticate himself on the client's behalf and consequently access that clients's personal resources or data.
Answer to Question 3:
Because of the above-mentioned problem, the client sends another authenticator (Message 7) to the server.
Message 7: A new Authenticator, that includes the client ID, timestamp and is encrypted using the Client/Server Session Key.
The Client/Server Session Key is available to the client in Message 6, which was encrypted using Client/TGS Session Key. That is not available to John.
Answer to Question 4:
The server side decrypts the ticket of message 5 using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, server decrypts the Authenticator (message 7) and compare client ID from message 5 and 7, if they match then only server sends next confirmation messages to the client. Moreover while validating an authentication message, the server-side check the authenticator's timestamp. If the timestamp is earlier or the same as a previous authenticator received within the last five minutes, it will reject the packet because it treats it as a replay attack and user authentication fails.
Answer to question 5:
1. It suffers from a Single point of failure, i.e. it requires continuous availability of the server. When the TGS is down, new users cannot log in.
2. Kerberos assumes that each user is trusted but uses an untrusted network or hosts. Hence, if anyone other than the proper user has access to the one host that issues tickets used for authentication — called the key distribution center (KDC) — the entire Kerberos authentication system is at risk.
3. The attacker can control every attribute of the forged ticket including the Ticket's client id, client’s network id, and ticket's life time. Attackers typically set ‘Golden Tickets’ to have an unusually long lifetime, which allows the possessed entity to keep using for a long period without renewal.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.