3
Many-to-Many Authentication How do users prove their identities when requesting services from servers on the network? Naïve solution: every server knows every users password: - insecure: compromise of any server will compromise all users - inefficient: a user must contact every server to change password 3 Users Servers ?

4
Using Trusted Third Party Trusted authentication service on the network: knows all passwords, can grant access to any server convenient, but also the single point of failure requires high level of physical security 4 User Servers User requests ticket for some service; proves his identity User receives ticket Ticket is used to access desired network service Knows all users and servers passwords

5
Kerberos Network authentication protocol Provides strong authentication for client/server applications, using secret-key cryptography A user types in a password and logs into a workstation. On behalf of the user, the workstation authenticates and accesses resources seamlessly Developed at MIT Kerberos V4 and V5 are widely deployed KDC: a database of and a library of subroutines 5

6
Configuration 6 Kerberos server: KDC Each principal has its master key, K Alice, shared with KDC - human user: key is derived from password - machine: key is pre-configured KDC has a master key, K KDC, known only by itself, to encrypt user master keys and ticket-granting tickets KDC keeps a database of, where key for each user is encrypted by K KDC Based on secret-key cryptography: DES, V5 theoretically can use other encryption algorithms

13
Replicated KDCs 13 Purposes: - Prevent single point failure - Prevent performance bottleneck Multiple KDCs - One master copy for read/write - Multiple replicas for read only - All having the same database and the same master key Updating KDC database - KDCs database is transferred in clear - Privacy: keys are stored as ciphertext encrypted by K KDC - Integrity: a cryptographic hash of the database file and a timestamp

14
Realms 14 To scale to a large network including multiple administrations, the principals are divided into realms. Each realm has its own KDC. The KDCs of other realms are treated as resources (principals) of a local realm.

15
Interrealm Authentication 15 Kerberos V4 does not allow authentication through a chain of KDCs: a rogue KDC can impersonate other realms Kerberos V5 does: hierarchy of realms

16
Interrealm Authentication (2) 16

17
Key Version Numbers 17 If Bob changes his master key, Alices ticket for Bob will be invalidated without Alice knowing it Solution: Each key has a version number. Old keys are maintained for a period of time. Different keys are identified by their version numbers. Tickets are sent together with the key version numbers.

18
Other Uses of Kerberos 18 Besides authentication… Integrity only: perform an undocumented arithmetic based on mod 2^63 – 1 on the message concatenated with the session key, which results in a checksum. Send the message with the checksum Privacy and integrity

19
Privacy and Integrity 19 Plaintext Cipher Block Chaining (PCBC) - Modify any cipher block will garble the rest of the message - Put recognizable data at the end of a message - Does not prevent swapping attack (why?)

38
Exercises (1) 38 [Kaufman] 13.5: With CBC, if one ciphertext block is lost, how many plaintext blocks are lost? With PCBC, why do things get back in sync if c n and c n+1 are switched? How about if a ciphertext block is lost? How about if ciphertext block n is switched with ciphertext block n+2? How about any permutation of the first n blocks?

39
Exercises (1): Answer 39 [Kaufman] 13.5: In CBC decryption, each ciphertext block affects two plaintext blocks, one through decryption and one through XOR. In PCBC decryption, each ciphertext block affects the corresponding plaintext block by XORing its decryption, while it affects all following plaintext blocks by XORing the XOR of it and its decryption. Thus, a set of ciphertext blocks affects the following plaintext blocks in a manner independent of the order of ciphertext blocks within the setthe effect is just an XOR of the XOR of all the ciphertext blocks and their decryptions.

40
Exercises (2) 40 [Kaufman] 14.4: Design a different method of Bob authenticating Alice when Bob does not remember his own master key, which places the work on Bob instead of Alice. In other words, Alice will act as if Bob was an ordinary civilized thing that does not remember its own master key, and Bob interacts appropriately with the KDC so that Alice will be unaware that Bob didn't know his own master key.

41
Exercises (2): Answer 41 [Kaufman] 14.4: We assume that Bob has a valid TGT and still remembers the session key S B. With the cooperation of the KDC, Bob can still decrypt messages encrypted with his master key, and thus authenticate Alice as follows. Bob gets the KDC to decrypt a message encrypted with his master key by sending the encrypted message and his TGT (which contains Bobs name and the session key encrypted with the KDCs master key) to the KDC. The KDC (which knows Bobs master key) decrypts the message and sends it back to Bob encrypted with the session key. Since Bob knows the session key, he can now decrypt the message.

42
Exercises (3) 42 Alice wants to send Bob a large data file containing confidential data. She wants to make sure the file cannot be modified undetected during transmission. All Alice and Bob have is their public/private key pair PUB A /PRV A and PUB B /PRV B, respectively. Show how Alice will construct the message to be transmitted in a secure and efficient way. Show also how Bob will extract the data file from the received message. You can draw diagrams or write down the message construction/extraction using notations.