|
Kerberos
In Greek mythology, Kerberos is the three headed watchdog that guarded the gates of Hades
Kerberos
?? Kerberos is an authentication service developed at MIT as part of project Athena.
?? Kerberos provides a trusted third-party service that uses Needham-Schroeder protocol.
Scenario
?? Assume an open distributed environment
- users at workstations wish to access services on servers distributed throughout the network.
- A distributed computing system is a collection of independent computing systems.
?? We would like for servers to be able to restrict access to authorised users and to be able to authenticate requests for services.
Motivation
?? Users wish to access services on servers.
?? Three threats exist:
- User pretend to be another user.
- User alter the network address of a workstation.
- User eavesdrop on exchanges and use a replay attack to gain access to a server or disrupt its operation.
Kerberos' Aspects
?? Kerberos provides a centralized authentication server whose function is to authenticate users to servers and servers to users.
?? Kerberos does not need an elaborate authentication protocol at each server.
?? Kerberos relies on conventional encryption, making no-use of public-key encryption.
Kerberos' Versions
?? Version 4: widely used.
?? Version 5: corrects some of the security deficiencies of version 4 and has been issued as a Proposed Internet Standard (RFC 1510).
Where do we use Kerberos?
?? Some common applications:
- Telnet (RFC 854)
- BSD rtools (rlogin, rcp, rsh)
- NFS (Network File System, RFC 1094)
" a utility that permits files on a remote node on the network to be accessed as though they were local files.
Kerberos' Requirements
?? Secure: a network eavesdropper should not be able to obtain the necessary information
to impersonate a user.
?? Reliable
?? Transparent: the user should not be aware that authentication is taking place.
?? Scalable: the system can support large numbers of clients and servers.
Note on Simple Mutual
Authentication
?? The scheme may work for Alice and Bob, but it is not practical for a large computer network,
which may contain thousands of users and hundreds of servers.
?? We introduce a trusted third party, Audry, who has established a key with each client and each
server of the network. This key is called longterm key, to distinguish it from other keys.
Role of Audry
?? When Alice wants to talk to Bob, she first sends Audry a message. Alice uses her long-term key to encrypt the message before sending it to Audry.
?? Audry uses the key that she shares with Alice to decrypt and to authenticate the message and uses the nonce to foil replay attacks.
?? If the message is authentic, Audry creates another symmetric key, which is called a session key, to differentiate it from the long-term key. This is in fact a ticket which can be used by Alice to talk to Bob.
Scenario
Alice-------' Audry
KA{"Audry, hey, it's me, Alice! I want to talk to Bob", n"}
Audry ------' Alice
KA{KAB, n, KB{"Bob, hey, Alice wants to talk to you!", KAB}}
KA: Alice's long-term key
KB: Bob's long-term key
KAB: Session key for Alice and Bob
n: Nonce
Scenario
Alice -'Bob
KAB("Bob, hey, it is me,Alice!", n2)
KB{"Bob, hey, Alice wants to talk to you!", KAB}
Terminology
?? The message KAB("Bob, hey, it is me, Alice!", n2) is called an authenticator because Alice can use it to authenticate herself to Bob.
?? The authenticator and the ticket form the credentials that Alice needs to request a service from Bob.
?? Bob knows that Alice is who she claims to be, by trusting Audry.
?? To protect against the replay attack, Bob must keep track of all the nonces that he has been receiving from Alice.
New Problem
?? The problem with the previous approach is: whenever Alice wants to talk to someone
else, she has to contact Audry, and re-enter her password.
?? Is there any way to solve this problem? In other words, is there a way to allow Alice to
have a single sign-on (SSO)?
Solution
?? The solution is to introduce a new entity called a Ticket-Granting Ticket (TGT).
?? Alice provides her password once to obtain a TGT, which she can use repeatedly, until
it expires, to request session tickets for other servers from TGT.
A More Formal Discussion
Notations
Notations:
C = Client AS = Authentication Server
V = Server IDC = Identifier of user on C
IDV = Identifier of V
PC = Password of user on C
ADC = Network Address of C
KV = Secret Enc.Key shared by AS and V
Simple Authentication Dialogue
1. C -> AS: IDC || PC || IDV
2. AS -> C: Ticket
3. C ->V: IDC || Ticket
Ticket = EKV [ IDC || ADC || IDV ]
What is a 'Ticket'?
?? A authentication message that is encrypted by a shared key which is shared by two
entities is usually called a ticket.
?? We will see more later.
The first simple authentication
?? In the dialogue, the ticket is encrypted to prevent alternation or forgery.
?? The server ID is included in the ticket so that the server can verify that it has decrypted the ticket properly.
?? IDC is included to indicate that this ticket has been issued on behalf of C.
?? ADC is used to protect:
- an enemy who capture the ticket transmitted in message (2), then use the name IDC and
transmit a message of form (3) from another workstation.
Problems
?? How to minimise the number of times that a user has to enter a password?
- How to make a ticket re-usable?
?? The password in message (1) is transferred in a plaintext.
- An enemy could capture this one!
Introducing TGS
?? To solve the second problem, i.e. transmitting password in plaintext, a new server known as a Ticket Granting Server (TGS) is introduced.
?? TGS issues tickets to users who have been authenticated to AS. These tickets are saved
by the client, and they are used whenever a users want to access a new service.
Second Scheme (1/3)
?? Once per user logon session:
(1)C -> AS: IDC || IDtgs
(2) AS -> C: EKC [Tickettgs ]
Tickettgs = Ektgs[IDC||ADC||IDtgs||TS1||Lifetime1]
Second Scheme (2/3)
?? Once per type of service:
(3)C -> TGS: IDC || IDV || Tickettgs
(4) TGS ->C: TicketV
TicketV = EKV[IDC||ADC||IDV||TS2||Lifetime2]
Second Scheme (3/3)
?? Once per service session:
(5)C->V: IDC || TicketV
Advantages
?? The client's password does not need to be sent in plain.
?? Only one password query per user session and protection of the user password.
Problems remaining
?? Lifetime associated with the ticket-granting ticket.
- If it's very short, the user will be repeatedly asked for a password.
- If it's very long, an enemy has a greater opportunity to replay.
How to solve the problem?
?? A network service (the TGS or an application service) must be able to prove
that the person using a ticket is the same person to whom that ticket was issued.
Second problem
?? How can a server authenticate itself to a user?
- Without this mechanism, an enemy could sabotate the configuration so that messages to a
server were directed to another location.
- The false server would then be in a position to act as a real server and capture any information
from the user and deny the true service to the user.
Solutions
?? To avoid an opponent to steal the ticket and use it before it expires, AS provides both
the client and the TGS a secret piece of information in a secure manner.
- This is used in Kerberos.
Terminology
?? AS shares a secret key, known as a master key, with each principal.
?? When Alice informs AS that she wants to talk to Bob, AS invents a session key KAB
for Alice and Bob to share,encrypts KAB with Alice's secret master key for Alice and
KAB with Bob's secret master key for Bob.
Terminology (2)
?? A message consisting of the session key KAB encrypted with Bob's master key is
known as a ticket to Bob.
?? The session key KAB together with the ticket to Bob are known as Alice's credential to
Bob.
Kerberos Components
?? Kerberos has three components to guard a network:
- Kerberos database
- Kerberos Authentication Server (AS)
- Kerberos Ticket-Granting Server (TGS)
Kerberos Database
?? Kerberos database contains:
- user names and their passwords
- network services that each user has access to
- an encryption key associated with each service
?? A service can be an application on a host computer or giving the user ability to look at a
directory or a file on a system.
?? AS checks the identity of users and their rights to services.
?? TGS uses tickets after user identities are verified.
Kerberos: How it works (1)
?? The system works as follows.
1. A user must log onto a workstation by:
1. entering his/her password
2. requesting ticket for a TGS
The process appears as logging onto a host computer.
2. Name of the user and the TGS is sent to AS.
Kerberos: How it works (2)
3. AS checks the user's authorisation for the requested service. If valid, AS creates a ticket for TGS: ticket = {user name, name of TGS, time, time duration, a randomly generated session key}
These information are DES encrypted using a key known to AS and TGS. This is called a Ticket
Granting Ticket (TGT). This can be used a number of times.
Kerberos: How it works (3)
AS sends <TGT + session key> encrypted with users' private key known only to AS
and the user.
4. Client uses user's password to generate a DES key and decrypt the response from the Kerberos server.
Kerberos: How it works (4)
5. After a successful decryption, the client workstation stores the TGT and the session
key and erases the user's password and session key which were stored in the
temporary memory of the client.
A client has to obtain a separate ticket from TGS for every service he wants to use.
Kerberos: How it works (5)
?? To get a ticket for a service:
1. Client sends a request to TGS.
2. Client prepares an authenticator. An authenticator consists of:
{client's name, network address, current time}
all encrypted using the session key sent to the client.
An authenticator is used only once.
Kerberos: How it works (6)
3. Client sends the TGT and the authenticator to the server that he/she seeks access to.
4. TGS decrypts the ticket using the common key it shares with AS. It takes the session key from the decrypted information and decrypt the authenticator.
If the information in the authenticator matches those of the ticket, access can proceed -> the server checks the time to see if it is in the valid period of the ticket.
Kerberos: How it works (7)
5. TGS responds by sending a ticket to the client that the client can present to the server.
ticket = {name of the client, network address of the client, a timestamp, an expiration time for the ticket, session key} all encrypted in server's secret key.
TGS includes the session key and the ticket in a message encrypted with the session key shared by the client and the TGS.
Kerberos: How it works (8)
?? Requesting a service:
Now, client can authenticate himself to the server:
1. Client forms a message similar to the one he sent to TGS.
2. Server adds one to the time stamp sent from the client's workstation, encrypts the information with the session key and sends it to the client.
3. A successful decryption ensures the client that the server is the correct one.
Drawbacks of Kerberos
?? Every network service must be modified to use Kerberos. This is called Kerberizing and requires change to the code of the application.
?? Kerberos relies on passwords as the only means of identification. This makes Kerberos susceptible to dictionary attacks.
Kerberos' Strengths
?? Kerberos provides a higher level of security compared to using passwords.
?? Kerberos is transparent to the end-user and performs all steps of encryption/decryption
in the background.
Notes
?? Security offered by Kerberos can be easily lost if the software is not trusted:
- a client program that stores the passwords of the users totally compromises the system.
|
