"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

Transcription

1 KERBEROS: the fierce watchdog of Haides, depicted as a three headed 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

2 "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 serpent tail, until he convinced the beast with his choke hold. Then, with it in tow, he made his ascent through Troizen. After showing Kerberos to Eurystheus, he took it back to Hades' realm." Apollodorus

3 "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, triple formed 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.

4 (Modern Times) 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 3 DES 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 Though V4 still runs at many sites, V5 is considered to be standard Kerberos.

5 Project Athena: Developed at MIT with cooperation of IBM Creates a distrbuted campus wide computing environment Still in use makes a computer a thin client that downloads applications from servers as needed Started in 1983 Based on the Needham Schroeder protocol Resulted in: kerberos X windows Influenced: Active Directory a directory service LDAP maintains distributed directory services Instant Messaging

6 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 third party 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.

7 C Client V Server C@addr address of client K@{C} Secret Key of client known to Authenticating Server K@{V} Secret Key of server known to Authenticating Server K@{C,V} Session Key for secure client/server communication Ticket@{C,V} Ticket issued for client to send to server contains: session key, timestamp, lifetime, client address The client's secret key is the client's password using a hash or key scheduling algorithm The server's secret key is chosen randomly

8 Principals 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 AS 2. Ticket@{C,V}=(K@{C,V}, time, lifetime, C@addr) To C: {{Ticket@{C,V}}K@{V}, V, time, K@{C,V}, lifetime}k@{c}

9 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 [{C, C@addr, time, nonce}k@{c,v}]. Authenticator sent together with ticket to V. V decrypts the ticket using V's secret key. V gets session key from ticket. V uses session key to decrypt authenticator. V compares contents of ticket with that of authenticator. V compares the timestamp and nonce to prevent a replay attack. If everything matches, V considers C to be properly authenticated

10 4. Mutual Authentication (Optional) Server extracts C's time from authenticator of 3. Returns it to C encrypted with session key: {time}k@{c,v} (Server was able to decrypt authenticator so if Kerberos Server is OK, Server must be OK since its secret key was used to decrypt the authenticator)

11 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.

12 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. Should the user's password be presented each time the user performs authentication with a new server????.

13 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. Should the user's password be presented each time the user performs authentication with a new server????. Cumbersome: instead, system should support single sign on, where the user logs in to the system once, providing the password at that time, and with subsequent authentication occurring automatically.

14 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. Should the user's password be presented each time the user performs authentication with a new server????. Cumbersome: instead, system should support single sign on, 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.

15 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).

16 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). This is how Kerberos does it.

17 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). This is how Kerberos does it. When 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.

18 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). This is how Kerberos does it. When 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 saved, and the user's password forgotten.

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

20 Obtaining additional tickets: Subsequently, when 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.

21 1. [C, TGS, time, nonce] 1 and 2. Only on first login 2. [{K@{C,TGS}, TGS, time, nonce}k@{c}, {Ticket@{C,TGS}}K@{TGS}] 3. [{C, C@addr, time, nonce}k@{c,tgs}, {Ticket@{C,TGS}}K@{TGS}, V, time, nonce] 4. [{K@{C,V}, V, time, nonce}k@{c,tgs}, {Ticket@{C,V}}K@{V}] 5. [{time, nonce, Ksubsession}K@{C,V}, {Ticket@{C,V}}K@{V}] 6. [{time}k@{c,v}] (optional mutual authentication)

22 Assume interorganizational communication Users will not be registered with same authentication server Realm: authentication server with registered users Cross Realm Authentication: a principal of one realm proves identity to an authentication server of another realm Client gets cross realm ticket to another TGS:

23 ASV TSV ASV TSV ASV TSV ASC TSC ASV TSV 1. Request for ticket to C V

24 ASV TSV ASV TSV ASV TSV 2. Is in your domain? ASC TSC ASV TSV C V

25 ASV TSV 3. Is in your domain? ASV TSV ASV TSV ASC TSC ASV TSV C V

26 ASV TSV ASV TSV ASV TSV 4. Looking for Auth. Server ASC TSC ASV TSV C V

27 ASV TSV ASV TSV ASV TSV 5. Looking for Auth. Server ASC TSC ASV TSV C V

28 ASV TSV ASV TSV ASV TSV 6. Send a session key for TSv ASC TSC ASV TSV C V

29 ...

30 ASV TSV ASV TSV ASV TSV 9. Send a session key for TSv ASC TSC ASV TSV C V

31 ASV TSV ASV TSV ASV TSV ASC TSC ASV TSV 10. Send a session key for TSv C V

32 ASV TSV ASV TSV ASV TSV ASC TSC ASV TSV 11. Request ticket to V from TSv C V

33 Limitations: Kerberos Kerberos must be integrated with other parts of the system.

34 Limitations: Kerberos Kerberos must be integrated with other parts of the system. Does not protect all messages sent between two computers: only protects the messages from software that has been written or modified to use it.

35 Limitations: Kerberos Kerberos must be integrated with other parts of the system. Does not protect all messages sent between two computers: only protects the messages from software that has been written or modified to use it. 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.

36 Limitations: Kerberos Kerberos must be integrated with other parts of the system. Does not protect all messages sent between two computers: only protects the messages from software that has been written or modified to use it. 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

37 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.

38 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.

39 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.

40 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.

41 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).

42 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). 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.

43 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). 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.