kerberos - university of cincinnatigauss.ececs.uc.edu/courses/c653/lectures/pdf/kerberos.pdf ·...

Kerberos

KERBEROS: the fierce watchdog of Haides, depicted as a threeheaded dog with a serpent's tail, a mane of snakes, and a lion's claws.

"And before them a dreaded hound, on watch, who has no pity, but a vile stratagem: as people go in he fawns on all, with actions of his tail and both ears, but he will not let them go back out, but lies in wait for them and eats them up, when he catches any going back through the gates." Theogony 769774

Kerberos

"Herakles asked Pluto for Kerberos, and was told to take the hound if he could overpower it without using any of the weapons he had brought with him. He found Kerberos at the gates of Akheron, and there, pressed inside his armour and totally covered by the lion's skin, he threw his arms round its head and hung on, despite bites from the serpenttail, until he convinced the beast with his chokehold. Then, with it in tow, he made his ascent through Troizen. After showing Kerberos to Eurystheus, he took it back to Hades' realm." Apollodorus 2.1225126

"When you have crossed the river and have advanced a little further, some aged women weaving at the loom will beg you to lend a hand for a short time. But you are not permitted to touch that either, for all these and many other distractions are part of the ambush which Venus will set to induce you to release one of the cakes from your hands. Do not imagine that the loss of a mere barley cake is a trivial matter, for if you relinquish either of them, the daylight of this world above will be totally denied you. Posted there is a massive hound with a huge, tripleformed head. This monstrous, fearsome brute confronts the dead with thunderous barking, though his menaces are futile since he can do them no harm. He keeps constant guard before the very threshold and the dark hall of Proserpina, protecting that deserted abode of Dis. You must disarm him by offering him a cake as his spoils. Then you can easily pass him, and gain immediate access to Proserpina herself … When you have obtained what she gives you, you must make your way back, using the remaining cake to neutralize the dog’s savagery.”

Distributed authentication service

Allows a process (a client) running on behalf of a principal (a user) to prove its identity to a verifier (an application server, or just server) without sending data across the network that might allow an attacker or the verifier to subsequently impersonate the principal.

Optionally provides integrity and confidentiality for data sent between the client and server. Uses 3DES in CBC for encryption.

Developed in the mid'80s as part of MIT's Project Athena. As its use spread to other environments, changes were needed to support new policies and patterns of use. To address these needs, design of Version 5 of Kerberos began in 1989. Though V4 still runs at many sites, V5 is considered to be standard Kerberos.

Kerberos (Modern Times)

KerberosProject Athena: Developed at MIT with cooperation of IBM Creates a distrbuted campuswide computing environment Still in use – makes a computer a thin client that downloads applications from servers as needed Started in 1983 Based on the NeedhamSchroeder protocol

Resulted in: kerberos X windows

Influenced: Active Directory – a directory service LDAP – maintains distributed directory services Instant Messaging

Built upon the assumption that the network is "unsafe". Example: data sent over the network can be eavesdropped and altered, and addresses can also be faked. Therefore they cannot be used for authentication purposes.

Trusted thirdparty service: the kerberos server is trusted by all the entities on the network (users and services, usually called principals). Kerberos cannot be used to connect to unknown or untrusted servers, say in the cloud.

All principals share a secret password (or key) with the kerberos server and this enables principals to verify that the messages from the kerberos server are authentic.

Thus trusting the kerberos server, users and services can authenticate each other.

Kerberos

C ClientV ServerC

addr address of client

KC Secret Key of client known to Authenticating Server

KV Secret Key of server known to Authenticating Server

KC,V

Session Key for secure client/server communication

TC,V

Ticket issued for client to send to server

contains: session key, timestamp, lifetime, client address

The Client's secret key is a function of the Client's password e.g. a hash of the password

The Server's secret key is chosen randomly

Kerberos

KerberosPrincipals use tickets to prove that they are who they claim to be. Example: Client C wishes to use service V.

1. C sends a ticket request to the Authentication Server AS2. T

C,V = K

C,V , time , lifetime , C

addr

To C: KC{K

V{T

C,V} , V , time , K

C,V , lifetime}

AuthenticationServer (AS)


Client (C)Client (C) Server (V)Server (V)

1. 2.2.3.

4.

Kerberos

3. Before sending a message to V, C creates an authenticator consisting of C's name, C's address, the current time, and a "nonce" chosen by C, all encrypted with the secret session key K

C,V{C , C

addr , time , nonce}.

Authenticator is sent together with ticket TC,V

to V.

V decrypts the ticket using V's secret key. V gets the session key from the ticket. V uses the session key to decrypt the authenticator. V compares the contents of the ticket with that of the authenticator. V compares the timestamp and nonce to prevent a replay attack. If everything matches, V considers C to be properly authenticated



Server (V)Server (V)1. 2. 3.

4.Client (C)Client (C)

Kerberos

4. Mutual Authentication (Optional)

Server extracts C's time from the authenticator of step 3. Server returns time to C encrypted with session key: K

C,V{time}

(the Server V was able to decrypt the authenticator so if the Kerberos Authentication Server is OK, the Server V must be OK since its secret key was used to decrypt the authenticator)



Server (V)Server (V)1. 2. 3.

4.Client (C)Client (C)

Obtaining additional tickets: Protocol allows client with knowledge of user's password to obtain ticket and session key for, and to prove its identity to any server registered with the authentication server.

Kerberos


Should the user's password be presented each time the user performs authentication with a new server ????.

Kerberos



Cumbersome: instead, system should support single signon, where the user logs in to the system once, providing the password at that time, and with subsequent authentication occurring automatically.

Kerberos



Cumbersome: instead, system should support single signon, where the user logs in to the system once, providing the password at that time, and with subsequent authentication occurring automatically.

Obvious way to support this: cache user's password on the workstation (dangerous) ticket and key valid for short time. But user's password can be used to obtain tickets, and to impersonate the user until the password is changed.

Kerberos

Obtaining additional tickets: Better approach: cache only tickets and encryption keys (collectively called credentials) that will work for a limited period (typically on the order of 8 hours).

Kerberos


This is how Kerberos does it.

Kerberos



When a user first logs in, an authentication request is issued and a ticket and session key for the ticket granting service is returned by the authentication server.

Kerberos



When a user first logs in, an authentication request is issued and a ticket and session key for the ticket granting service is returned by the authentication server.

This ticket, called a ticket granting ticket, has a relatively short life (8 hours). The response is decrypted, the ticket and session key are saved, and the user's password is forgotten.

Kerberos

Obtaining additional tickets: Subsequently, when a user wishes to prove its identity to a new server, a new ticket is requested from the Authentication Server using the ticket granting exchange.

Kerberos

Obtaining additional tickets: Subsequently, when a user wishes to prove its identity to a new server, a new ticket is requested from the Authentication Server using the ticket granting exchange.

The ticket granting exchange is identical to the authentication exchange except that the ticket granting request has embedded within it an application request, authenticating the client to the authentication server, and the ticket granting response is encrypted using the session key from the ticket granting ticket, rather than the user's password.

Kerberos

Kerberos

1. [C, TGS, time, nonce] 1 and 2. Only on first login2. [K

C{K

C,TGS, TGS , time , nonce}, K

TGS{C, K

C,TGS}]

3. [KC,TGS

{C, Caddr

, time, nonce} , KTGS

{C, KC,TGS

} , V , time , nonce]

4. [KC,TGS

{KC,V

, V , time , nonce} , KV{C, K

C,V}]

5. [KC,V

{C, Caddr

, time , nonce} , KV{C, K

C,V}]

6. [KC,V

{time+1}] (optional for mutual authentication)



Client (C)Client (C) Server (V)Server (V)3. 4.

5.

6.

Ticket GrantingServer (TGS)

Ticket GrantingServer (TGS)

1.2.

Green text isAuthenticator

KerberosAssume interorganizational communicationUsers will not be registered with same Authentication ServerRealm: Authentication Server with registered usersCross Realm Authentication: a principal of one realm proves its identity to an Authentication Server of another realm

Client gets cross realm ticket to another TGS:

Kerberos

C V

ASC TSC ASV TSV

ASV TSV ASV TSV

ASV TSV

1. Request for ticket to Vaddr

Kerberos

C V

ASC TSC ASV TSV

ASV TSV ASV TSV

ASV TSV

2. Is Vaddr

in your domain?

Kerberos

C V

ASC TSC ASV TSV

ASV TSV ASV TSV

ASV TSV

3. Is Vaddr

in your domain?

Kerberos

C V

ASC TSC ASV TSV

ASV TSV ASV TSV

ASV TSV

4. Looking for Vaddr

Auth. Server

Kerberos

C V

ASC TSC ASV TSV

ASV TSV ASV TSV

ASV TSV

5. Looking for Vaddr

Auth. Server

Kerberos

C V

ASC TSC ASV TSV

ASV TSV ASV TSV

ASV TSV

6. Send a session key for TSv

Kerberos

...

Kerberos

C V

ASC TSC ASV TSV

ASV TSV ASV TSV

ASV TSV


Kerberos

C V

ASC TSC ASV TSV

ASV TSV ASV TSV

ASV TSV

11. Request ticket to V from TSv

Kerberos

Limitations:

Kerberos must be integrated with other parts of the system.

Kerberos

Limitations:


Does not protect all messages sent between two computers: only protects the messages from software that has been written or modified to use it.

Kerberos

Limitations:



While it may be used to exchange encryption keys when establishing link encryption (encryption/decryption on each communication line) and network level security services, this would require changes to the network software of the hosts involved.

Kerberos

Limitations:



While it may be used to exchange encryption keys when establishing link encryption (encryption/decryption on each communication line) and network level security services, this would require changes to the network software of the hosts involved.

Kerberos does not itself provide authorization, but V5 Kerberos passes authorization information generated by other services. In this manner, Kerberos can be used as a base for building separate distributed authorization services

Kerberos

Attacks: Password Guessing Not effective against password guessing attacks: If a user chooses a poor password, then an attacker guessing that password can impersonate the user.

Kerberos

Attacks: Password Guessing Not effective against password guessing attacks: If a user chooses a poor password, then an attacker guessing that password can impersonate the user.

Post Password Theft Kerberos requires a trusted path through which passwords are entered. If the user enters a password to 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 an attacker may obtain sufficient information to impersonate the user.

Kerberos

Attacks: Impersonating C An impostor, I, could steal the authenticator and the ticket as it is transmitted across the network, and use them to impersonate C. The address in the ticket and the authenticator was added to make it more difficult to perform this attack. To succeed I will have to either use the same machine as C or fake the source addresses of the packets. By including the time stamp in the authenticator, I does not have much time in which to mount the attack.

Kerberos

Attacks: Impersonating C An impostor, I, could steal the authenticator and the ticket as it is transmitted across the network, and use them to impersonate C. The address in the ticket and the authenticator was added to make it more difficult to perform this attack. To succeed I will have to either use the same machine as C or fake the source addresses of the packets. By including the time stamp in the authenticator, I does not have much time in which to mount the attack.

Impersonating V I can masquerade V's network address, and when C sends its credentials, I just pretends to verify them. C can't be sure that it is talking to I.

Kerberos

Defenses: Replay Cache (in Kerberos v.5) Save the authenticators sent during the last few minutes, so that V can detect when someone is trying to retransmit an already used message. Somewhat impractical (mostly regarding efficiency).

Kerberos


Mutual Authentication To authenticate V, C requests V send something back that proves V has access to the session key. Example: checksum that C sent as part of authenticator plus 1.

Kerberos


Mutual Authentication To authenticate V, C requests V send something back that proves V has access to the session key. Example: checksum that C sent as part of authenticator plus 1.

Message Integrity and Confidentiality Session key used to add cryptographic checksums to the messages sent between C and V. Encryption can also be added. This is probably the best approach in all cases.

kerberos - university of cincinnatigauss.ececs.uc.edu/courses/c653/lectures/pdf/kerberos.pdf ·...

Documents