+ All Categories
Home > Documents > Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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

Date post: 26-Dec-2015
Category:
Upload: theodora-wood
View: 224 times
Download: 0 times
Share this document with a friend
37
Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication
Transcript
Page 1: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

Part TwoNetwork Security Applications

Chapter 4

Key Distribution and User Authentication

Page 2: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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

Page 3: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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)

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

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

Page 5: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

5

4.2 Kerberos

Page 6: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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.

Page 7: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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

Page 8: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

8

Problem: No authentication of user IDC.

Darth could copy message 2 or 3 and later present it to V

Page 9: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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

Page 10: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

10

Problem: Darth could copy ticket in step 2, change IDC to IDD 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.

Page 11: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

11

A Simple Authentication Dialog

Page 12: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

12

Simple Authentication Dialog

Page 13: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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 IDV. Matching IDC in the

ticket with IDC 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.

Page 14: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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 ADC and

masquerade as IDC

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.

Page 15: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

15

“The new service, TGS, issues tickets to users who have been authenticated to AS. Thus, the user first requests a ticket-granting ticket

(Tickettgs) 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 (Ticketv) 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

Page 16: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

16

More Secure Authentication Dialog

Password overwritten immediately after use.

Page 17: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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.

Page 18: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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.

Page 19: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

19

Page 20: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

20

Page 21: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

21

Page 22: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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

Page 23: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

23Fig 4.3 Public-Key Certificate Use

Page 24: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

24

This uses a digital signature to authenticate the certificate.

Figure 3.2

The certificate can then be used to facilitate other digital signatures.

AliceBob

Page 25: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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.

Page 26: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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

Page 27: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

27Figure 4.4 X.509 Formats

hash

Page 28: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

28

“little, if any, utility”

Certificate binds these two together

The only encryption in the certificate

hash

Page 29: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

29

Page 30: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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?

Page 31: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

31

Tools => Options

=> Advanced

=> View Certificates

Page 32: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

32

Page 33: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

33

Page 34: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

34

Page 35: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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

Page 36: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

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

Page 37: Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.

37

End Chapter 4

Skim X.509 Version 3

Omit 4.5 Public-Key Infrastructure

Omit 4.6 Federated Identity Management


Recommended