X.
509 Certificates
Public Key Infrastructure ( PKI)
Remote User Authentication Principles
Remote User Authentication using Symmetric Encryption
Kerberos
The Kerberos Version 4 protocol is designed to address several security concerns related to user authentication in a network environment,
particularly the problem of replay attacks, identity verification, and mutual authentication between clients and servers. Below is a detailed
explanation of the dialogue exchanges
1. Authentication Service Exchange (Message 1 and 2)
Message (1):
• Client → Authentication Server (AS): IDC || IDtgs || TS1
• IDC: The user’s identity (e.g., username).
• IDtgs: The identifier of the Ticket-Granting Server (TGS) that the client wishes to access.
• TS1: A timestamp, ensuring the freshness of the request and preventing replay attacks (i.e., ensuring that the message is not a replay of
an old message).
Message (2):
• AS → Client (C): E(Kc, [Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs])
• Kc: The key derived from the user’s password, which encrypts the message.
• Kc,tgs: A session key that will be used between the client and the TGS. This key is created by the AS to ensure secure communication
between the client and the TGS.
• IDtgs: The identifier of the TGS, confirming that the ticket is meant for the TGS.
• TS2: A timestamp indicating when the ticket was issued.
• Lifetime2: The expiration time of the ticket, ensuring that the ticket will not be used indefinitely.
• Tickettgs: The ticket granting access to the TGS. This ticket is encrypted with the TGS’s secret key (Ktgs) and contains essential
information such as the client’s identity, address, and the TGS identifier.
• Purpose: This message allows the client to securely receive a ticket granting access to the TGS, along with a session key (Kc,tgs) that will
be used in future exchanges between the client and TGS.
2. Ticket-Granting Service Exchange (Message 3 and 4)
Message (3):
• Client → TGS: IDC || IDv || Tickettgs || Authenticatorc
• IDC: The user’s identity.
• IDv: The identifier of the service or server (V) the client wishes to access.
• Tickettgs: The ticket received from the AS, which proves that the client has been authenticated by the AS.
• Authenticatorc: A newly created authenticator that includes the client’s identity (IDC), address (ADC), and a timestamp (TS3). This
authenticator proves that the client is the legitimate user who holds the ticket and is initiating the request.
• The authenticator is encrypted using the session key (Kc,tgs), ensuring that only the TGS can decrypt it and verify the client’s identity.
• This prevents replay attacks, as the authenticator is valid only for a short period and cannot be reused.
Message (4):
• TGS → Client: E(Kc,tgs, [Kc,v || IDv || TS4 || Ticketv])
• Kc,tgs: The session key shared between the client and the TGS, which encrypts the message.
• Kc,v: A session key created by the TGS for secure communication between the client and the server (V).
• IDv: The identifier of the requested service (V).
• TS4: A timestamp, ensuring the freshness of the message.
• Ticketv: The service-granting ticket that allows the client to access the service (V). This ticket is encrypted with the service’s secret key
(Kv), ensuring that only the service can decrypt it.
3. Client/Server Authentication Exchange (Message 5 and 6)
Message (5):
• Client → Server (V): Ticketv || Authenticatorc
• Ticketv: The service-granting ticket that proves the client has been authenticated by the TGS.
• Authenticatorc: A new authenticator that includes the client’s identity (IDC), address (ADC), and a timestamp (TS5), encrypted with the
session key shared between the client and the server (Kc,v). This ensures that the client is the legitimate user and that the message is not a
replay.
Message (6):
• Server → Client: E(Kc,v, [TS5 + 1])
• Kc,v: The session key shared between the client and the server (V).
• TS5 + 1: The server increments the timestamp from the client’s authenticator by 1 and encrypts it with the session key. This confirms
that the server has received and decrypted the client’s message and is replying in real-time (not replaying an old message).
• The server’s response proves to the client that the message was generated by the server, preventing an attacker from impersonating the
server.
Key Features of Kerberos Version 4:
• Session Keys: These are used to securely exchange information between parties without needing to share permanent keys. The client
and TGS share a session key (Kc,tgs), and the client and server share a session key (Kc,v). This ensures that each communication between
parties is encrypted and secure.
• Authenticators: These are used to prove the identity of the ticket holder. The authenticator is encrypted using the session key, making it
unique and preventing replay attacks.
• Replay Protection: Both the ticket and authenticator have time stamps and expiration times to ensure that they cannot be used after a
certain period or if they have been intercepted by an attacker.
• Mutual Authentication: The server can also authenticate itself to the client by responding with a modified timestamp, ensuring both
parties are who they claim to be.
• Ticket Reusability: The tickets are reusable for the entire lifetime of the ticket, meaning the client does not need to re-enter their
password or request a new ticket for every interaction with the same service.
Figure 15.1 Overview of Kerberos Exchanges:
• This figure illustrates the flow of messages between the client (C), the Authentication Server (AS), the Ticket-Granting Server (TGS), and
the Service Provider (V). It shows how the client authenticates to the AS, requests a service-granting ticket from the TGS, and finally accesses the
requested service by presenting the service-granting ticket and an authenticator to the server.
In summary, Kerberos Version 4 improves security by introducing session keys, authenticators, and timestamps to protect against replay attacks
and ensure that both the client and server are authenticated. It also provides a way to minimize the number of password prompts by allowing the
client to reuse tickets within a session.
Remote User Authentication using Asymmetric