CIS 6930/4930 Computer and Network Security. Topic 6.2 Authentication Protocols

Transcription

1 CIS 6930/4930 Computer and Network Security Topic 6.2 Authentication Protocols 1

2 Authentication Handshakes Secure communication almost always includes an initial authentication handshake. Authenticate each other Establish session keys This process is not trivial; flaws in this process undermine secure communication 2

3 Authentication with Shared Secret I m A challenge R f(k -, R) Weaknesses Authentication is not mutual; Trudy can convince that she is Trudy can hijack the conversation after the initial exchange If the shared key is derived from a password, Trudy can mount an off-line password guessing attack 3

4 Authentication with Shared Secret (Cont d) I m K - {R} R Weaknesses still cannot authenticate Trudy can easily get pairs of (plaintext, ciphertext) Trudy can hijack the conversation after the initial exchange Other vulnerability? 4

5 Authentication with Public Key I m R Sig {R} Weaknesses Authentication is not mutual; Trudy can convince that she is Trudy can hijack the conversation after the initial exchange Trudy can trick into signing something 5

6 Authentication with Public Key (Cont d) I m {R} R A variation What can trick to do? 6

7 Mutual Authentication I m R 1 f(k -, R 1 ) R 2 f(k -, R 2 ) Optimize I m, R 2 R 1, f(k -, R 2 ) f(k -, R 1 ) 7

8 Mutual Authentication (Cont d) Reflection attack Trudy I m, R 2 R 1, f(k -, R 2 ) f(k -, R 1 ) Trudy I m, R 1 R 3, f(k -, R 1 ) 8

9 Reflection Attacks (Cont d) Lesson: Don t have and do exactly the same thing Different keys Totally different keys K - = K Different Challenges: and s challenges cannot be the same The initiator should be the first to prove its identity Assumption: initiator is more likely to be the bad guy 9

10 Mutual Authentication (Cont d) I m, R 2 R 1, f(k -, R 2 ) f(k -, R 1 ) I m R 1 Countermeasure f(k -, R 1 ), R 2 f(k -, R 2 ) 10

11 Mutual Authentication (Cont d) Public keys Authentication of public keys is a critical issue I m, {R 2 } R 2, {R 1 } R 1 11

12 Mutual Authentication (Cont d) Mutual authentication with timestamps Require synchronized clocks and have to encrypt different timestamps I m, f(k -, timestamp) f(k -, timestamp+1) 12

13 Integrity/Encryption for Data Communication after mutual authentication should be cryptographically protected as well Require a session key established during mutual authentication 13

14 Establishment of Session Keys Secret key based authentication Assume the following authentication happened. Can we use K - {R} as the session key? Can we use K - {R+1} as the session key? Can we use K - +1 {R} as the session key? In general, modify K - and encrypt R. Use the result as the session key. I m R K - {R} 14

15 Establishment of Session Keys Secret key based authentication Can we use f(k -, R 1 ), or f(k -, R 2 ) as the session key? Can we use f(k -, R 1 +1), or f(k -, R 2 +1) as the session key? Can we use f(k - +1, R 1 ), or f(k - +1, R 2 ) as the session key? I m R 1 f(k -, R 1 ), R 2 f(k -, R 2 ) 15

16 Two-Way Public Key Based Authentication Approach I chooses and encrypts R 1 with s public key chooses and encrypts R 2 with s public key Session key is R 1 R 2 Trudy will have to compromise both and Approach II and establish the session key with Diffie-Hellman key exchange and signs the quantity they send 17

17 Establishment of Session Keys (Cont d) One-way public key based authentication It s only necessary to authenticate the server encrypts R with the server s public key Diffie-Hellman key exchange signs the D-H public key 18

18 Trusted Key Servers How do a large number of users authenticate each other? inefficient / impractical for every pair of users to negotiate a secret key or share passwords Alternative: everybody shares a key with (and authenticates to) a single trusted third party Assumes there is a way to negotiate a key with the third party 19

19 Trusted (cont d) Shared keys between the Key Distribution Center (KDC) and users A B K A-KDC KDC K E-KDC K C-KDC K D-KDC C E D 20

20 (Simplified) Example of Use wishes to communicate securely with ; has previously negotiated K A-KDC with the KDC, has negotiated K B-KDC 1. requests from the KDC a session key to use with 2. KDC generates session key K S, sends to, encrypted with K A-KDC 3. KDC also sends K S to, encrypted with K B-KDC and can then communicate using K S 21

21 Assessment Simplifies mutual authentication / key negotiation, but secure against attacks? robust to failures? efficient? 22

22 A Hierarchy of KDCs For an Internet, not practical to have a single KDC instead, imagine one KDC per domain To communicate securely with user in your own domain, just contact your domain s KDC To talk with user in another domain, your KDC needs to contact the other domain s KDC KDCs must be able to authenticate each other and communicate securely 23

23 Hierarchy (cont d) A K A-K1 K B-K1 KDC-1 Domain 2 B C K C-K1 K E-K2 E KDC-2 Domain 1 K D-K2 D 24

24 Mediated Authentication (With KDC) KDC operation (in principle) wants to talk to K {K AB } KDC Generate K AB K {K AB } Some concerns Trudy may claim to be and talk to KDC Trudy cannot get anything useful Messages encrypted by using K AB may arrive at before KDC s message K {K AB } arrive It may be difficult for KDC to connect to 25

25 Mediated Authentication (With KDC) KDC operation (in practice) wants to talk to K {K AB }, K {K AB } Generate K AB KDC K {K AB } ticket Must be followed by a mutual authentication exchange To confirm that and have the same key 26

26 Needham-Schroeder Protocol Classic protocol for authentication with KDC Many others have been modeled after it (e.g., Kerberos) N 1, wants to talk to K {N 1,, K AB, ticket to }, where ticket to = K {K AB, } Generate K AB KDC ticket to, K AB {N 2 } K AB {N 2 1, N 3 } K AB {N 3 1} How is authenticated? How is authenticated? How is KDC authenticated? What are the N s used for? Why is N-1 needed? 27

27 Needham-Schroeder Protocol (Cont d) A vulnerability When Trudy gets a previous key K AB used by, Trudy may reuse a previous ticket issued to for Essential reason The ticket to stays valid even if changes her key 28

28 Expanded Needham-Schroeder Protocol I want to talk to you K {N B } Generate K AB ; extract N B N 1, wants to talk to, K {N B } K {N 1,, K AB, ticket to }, where ticket to = K {K AB,, N B } KDC ticket to, K AB {N 2 } K AB {N 2 1, N 3 } K AB {N 3 1} 29

29 Otway-Rees Protocol N C,,, K {N A, N C,, } Generate K AB Extract N B KDC K {N A, N C,, }, K {N B, N C,, } N C, K {N A, K AB }, K {N B, K AB } K {N A, K AB } K AB {anything recognizable} Only has five messages KDC checks if N C matches in both cipher-texts Make sure that is really 30