1. Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication

2. 2 4.1 Symmetric Key Distribution Using Symmetric Encryption Possible methods of key sharing between A and B : 1. A selects key, physically delivers to B 2. Third party C selects key, physically delivers to A and B 3. If A and B have previously shared a key, a new key could be chosen by one of them and sent to the other encrypted with the old key 4. If A and B each have an encrypted connection to a trusted third party C, C could generate the key and transmit it to A and B over the encrypted connections

3. 3 3. If A and B have previously shared a key, a new key could be chosen by one of them and sent to the other encrypted with the old key Problem: If an attacker ever succeeds in gaining access to one key, then all subsequent keys are revealed. 4. If A and B each have an encrypted connection to a trusted third party C, C could generate the key and transmit it to A and B over the encrypted connections C is called the Key Distribution Center (KDC)

4. 4 Key Distribution Center (KDC) uses two types of key: ► Session Key – used to protect messages between two users ► Master key – used to protect messages between a user and the KDC Master key A ↔ C Master key B ↔ C Session key A ↔ B

5. 5 4.2 Kerberos

6. 6 Threats: * Darth may gain access to a workstation and masquerade as legitimate user * Darth may alter the network address of a workstation, so that messages appear to come from a different workstation ( "IP address spoofing" ) * Darth may eavesdrop on an exchange and use a replay attack to gain entrance to a server or disrupt operations * Darth may masquerade as a server to legitimate clients (“phishing”) Assume a distributed collection of workstations (clients) and servers, communicating over an insecure network. Users can sit down at any workstation, but most services are restricted to specific users. Users and servers must authenticate themselves to each other securely over the insecure network.

7. 7 Kerberos Version 4 “… makes use of DES in a rather elaborate authentication service. Viewing the protocol as a whole it is difficult to see the need for many of the elements … we build up to the full protocol by looking at several hypothetical dialogs. Each successive dialog adds additional complexity to counter security vulnerabilities revealed in the preceding dialog.”

8. 8 Problem: No authentication of user ID C. Darth could copy message 2 or 3 and later present it to V

9. 9 Fixes: ► User authenticates self to authentication server ► Ticket specifies user to whom it is issued ► User authenticates self to V-server, which checks user name on ticket

10. 10 Problem: Darth could copy ticket in step 2, change ID C to ID D and present ticket to V-server, possibly from a different workstation. Fix: Encrypt ticket so that only V can read it (AS and V share a secret password); add the address of the workstation to the ticket.

11. 11 A Simple Authentication Dialog

12. 12 Simple Authentication Dialog

13. 13 Strengths of the Simple Authentication Dialog: ►Ticket can be used only from the same workstation from which it was requested. ►V-server checks its decryption and that ticket is being presented to correct server by finding its own address ID V. Matching ID C in the ticket with ID C outside verifies that ticket is being used by the person who requested it. ►Ticket issued is encrypted using secret password shared between the authentication server and the V-server, so cannot be forged. ►User has to supply password to log into authentication server.

14. 14 Problems with the Simple Authentication Dialog: Password is sent “in the clear.” User has to login to the authentication server every time (s)he needs service (mail server, print server, etc.). Darth can copy the ticket in step 2 or 3 inherit the workstation AD C and masquerade as ID C We would like to authenticate ourselves just once, when we log in, then be able to ask for tickets to access different servers as we need them. This suggests separating authentication from ticket-granting.

15. 15 “The new service, TGS, issues tickets to users who have been authenticated to AS. Thus, the user first requests a ticket-granting ticket (Ticket tgs ) from the AS. The client module in the user workstation saves this ticket. Each time the user requires access to a new service, the client applies to the TGS, using this ticket to authenticate itself. The TGS then grants a ticket (Ticket v ) for the particular service [if the client is authorized to use that service!] The client saves each service-granting ticket and uses it to authenticate the user to a server each time a particular service is requested.” More Secure Authentication Dialog

16. 16 More Secure Authentication Dialog Password overwritten immediately after use.

17. 17 “Two additional problems remain.” 1. Lifetime of tickets 2. Authentication of server to client (“phishing”) Must prove that the person using the TGS ticket is the same person to whom it was issued.

18. 18 Kerberos Version 4 Authentication Dialog Fixing problem #1 – lifetime of ticket. Must prove that the person using the TGS ticket is the same person to whom it was issued. The idea will be for the AS to provide both client and TGS with a secret piece of information (the session key) in a secure manner; when contacting the TGS the client will demonstrate knowledge of this secret information, proving that it is the unit to which the AS sent the TGS ticket. Fixing problem #2 – phishing An additional (sixth) step will be added during which the server will prove its identity by demonstrating knowledge of a secret. This will be repeated to obtain secure access to the V-server.

19. 19

20. 20

21. 21

22. 22 Two aspects: ► distribution of public keys At first thought there is no problem: just put your public key on a bulletin board! Problem: somebody else posts a key, stating it to be yours. Need a trusted third party to certify that the public key is yours, and distribute it. ► use of public-key encryption to share secret keys for symmetric cryptography. 4.3 Key Distribution Using Asymmetric Encryption The trusted third party is called a Certificate Authority, which issues Public Key Certificates (next section).

23. 23 Fig 4.3 Public-Key Certificate Use

24. 24 This uses a digital signature to authenticate the certificate. Figure 3.2 The certificate can then be used to facilitate other digital signatures. Alice Bob

25. 25 Public-Key Distribution of Secret (symmetric cryptography) Keys Bob and Alice may be geographically distant – how to exchange key? ► Diffie-Hellman (but no authentication) ► use public-key encryption 1. Bob prepares a message 2. He encrypts it using symmetric algorithm, using one-time “session key” 3. He encrypts the session key with Alice’s public key 4. He attaches the encrypted session key to the encrypted message and sends both to Alice 5. Alice uses her private key to decrypt the session key (only Alice can do this) 6. Alice reverses the symmetric encryption of the message.

26. 26 4.4 X.509 Certificates Kerberos achieves authentication of user without making use of public- key cryptography. X.509 uses public-key cryptography for this purpose. We used public-key certificates in the previous section Here we give details of the generation and standard form of a public-key certificate, X.509

27. 27 Figure 4.4 X.509 Formats hash

28. 28 “little, if any, utility” Certificate binds these two together The only encryption in the certificate hash

29. 29

30. 30 Characteristics of the X.509 Certificate User certificates generated by a CA have the following characteristics: ► Any user with access to the public key of the CA can verify the user public key that was certified. ► No party other than the certification authority can modify the certificate without this being detected. How do you get the CA’s public key?

31. 31 Tools => Options => Advanced => View Certificates

32. 32

33. 33

34. 34

35. 35 Revocation of Certificate Although the certificate includes an expiration date, it may be necessary to revoke a certificate before then (eg. private key revealed). CA needs to publish periodic revocation lists. Must be signed by CA! hash

36. 36 Reasons for Revocation of Certificates ► Confidentiality of the user’s private key has been compromised. ► The user is no longer certified by this CA ► The CA’s certificate is assumed to be compromised (CA’s private key has been released) From Peterson and Davie: “.. If all certificates had unlimited life spans, the Certificate Revocation List would always be getting longer, since you could never take a certificate off the CRL for fear that some copy of the revoked certificate might be used. However, by attaching an expiration date to a certificate when it is issued, we can limit the length of time that a revoked certificate has to stay on the CRL.”

37. 37 End Chapter 4 Skim X.509 Version 3 Omit 4.5 Public-Key Infrastructure Omit 4.6 Federated Identity Management