Distributed Systems Authentication Protocols Paul Krzyzanowski - PDF document

Authentication Establish and verify identity – allow access to resources Distributed Systems Authentication Protocols Paul Krzyzanowski pxk@cs.rutgers.edu Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution 2.5 License. Page 1 Page 1 Page 2 Authentication Authentication Three factors: factors may be combined – something you have key, card • can be stolen – ATM machine: 2-factor authentication – something you know passwords • ATM card something you have • can be guessed, shared, stolen • PIN something you know – something you are biometrics • costly, can be copied (sometimes) Page 3 Page 4 Password Authentication Protocol (PAP) Authentication: PAP • Reusable passwords Password Authentication Protocol • Server keeps a database of username:password mappings login, password • Prompt client/user for a login name & password client server OK • To authenticate, use the login name as a key to look up the corresponding password in a database (file) to authenticate • Unencrypted passwords if (supplied_password == retrieved_password) • Insecure on an open network user is authenticated Page 5 Page 6 1

PAP: Reusable passwords PAP: Reusable passwords Passwords can be stolen by observing a One problem: what if the password file isn’t sufficiently protected and an intruder gets hold user’s session over the network: of it, he gets all the passwords! – snoop on telnet, ftp, rlogin, rsh sessions – Trojan horse Enhancement: Store a hash of the password in a file – social engineering – given a file, you don’t get the passwords – brute-force or dictionary attacks – have to resort to a dictionary or brute-force attack Page 7 Page 8 One-time password Skey authentication Different password used each time • One-time password scheme – generate a list of passwords • Produces a limited number of or: authentication sessions – use an authentication card • relies on one-way functions Page 9 Page 10 Skey authentication Skey authentication Authenticate Alice for 100 logins Authenticate Alice for 100 logins • pick random number, R • using a one-way function, f(x): store x 101 in a password file or database record associated with Alice x 1 = f(R) x 2 = f(x 1 ) = f(f(R)) give this list x 3 = f(x 2 ) = f(f(f(R))) alice: x 101 to Alice … … x 100 = f(x 99 ) = f(…f(f(f(R)))…) • then compute: x 101 = f(x 100 ) = f(…f(f(f(R)))…) Page 11 Page 12 2

Skey authentication Two-factor authentication with an authenticator card Alice presents the last number on her list: Alice to host: { “alice”, x 100 } Challenge/response authentication Host computes f(x 100 ) and compares it with – user provided with a challenge number from host the value in the database – enter challenge number to challenge/response unit if (x 100 provided by alice) = passwd(“alice”) – enter PIN replace x 101 in db with x 100 provided by alice – get response: f(PIN, challenge) return success – transcribe response back to host else fail • host maintains PIN next time: Alice presents x 99 – computes the same function – compares data if someone sees x 100 there is no way to generate x 99 . • rely on one-way function Page 13 Page 14 Challenge-Response authentication SecurID card Username: paul Alice network host “alice” Password: look up alice’s “alice” 1234032848 key, K PIN + passcode from card generate random C challenge number C Something you know R ’ = f( K , C ) Something you have Passcode changes every 60 seconds R ’ R = f( K , C ) “welcome” 1. Enter PIN R = R ’ ? 2. Press ◊ 3. Card computes password 4. Read off password Password: an eavesdropper does not see K 354982 Page 15 Page 16 SecurID card SecurID Vulnerable to man-in-the-middle attacks • from RSA, SASL mechanism: RFC 2808 • Compute: AES-hash on: – attacker acts as application server – 128-bit token-specific seed – user does not have a chance to authenticate server – 64-bit ISO representation of time of day (Y:M:D:H:M:S) – 32-bit serial number of token – 32-bits of padding • Server computes three hashes with different clock values to account for drift. Page 17 Page 21 3

SKID2/SKID3 authentication SKID2/SKID3 authentication • uses symmetric cryptography Alice chooses a random R A Bob – shared secret key number (nonce) R A and sends it to Bob • generate a random token – nonce • give it to the other party, which encrypts it – returns encrypted result • verify that the other party knows the secret key Page 22 Page 23 SKID2/SKID3 authentication SKID2/SKID3 authentication R A Bob R A Bob Alice R B , H K (R A , R B ,”bob”) Bob chooses a random number (nonce): R B. Alice receives R B and has R A . He computes H K (R A , R B ,”bob”) Computes: H K (R A , R B ,”bob”) and sends it to Alice with R B Alice R B , H K (R A , R B ,”bob”) compares result to verify that Bob was able to encrypt data with key K. Bob shows that he can Authentication is complete as far as Alice is encrypt Alice’s nonce concerned (Bob knows the key). Page 24 Page 25 SKID2/SKID3 authentication SKID2/SKID3 authentication R A Bob R A Bob Alice R B , H K (R A , R B ,”bob”) Alice R B , H K (R A , R B ,”bob”) H K (R B , “alice”) Bob Now Alice has to convince Bob (mutual authentication) H K (R B , “alice”) Bob computes H K (R B , “alice”) and compares Alice’s message. Bob If they match, he trusts Alice’s identity Alice demonstrates that she can encrypt Bob’s nonce Key point : Each party permutes data generated by the other. Challenge the other party with data that will be different each time. Page 26 Page 27 4

Authentication: CHAP Authentication: MS-CHAP Challenge-Handshake Authentication Protocol Microsoft’s Challenge -Handshake Authentication Protocol challenge challenge: 16-byte random # hash(challenge, secret) client server hash(user name, password, password_challenge, challenge ) client server password_challenge: 16-byte random # OK shared secret shared secret OK The challenge-response scheme in a slightly different form. The same as CHAP – we’re just hashing more things in the response This is functionally the same as SKID2 (single party authentication) The challenge is a nonce. Instead of encrypting the nonce with a shared secret key, we create a hash of the nonce and the secret. Page 28 Page 29 Wide-mouth frog Alice Trent “alice” , E A (T A ,”bob”, K) Combined authentication session key destination and key exchange time stamp – prevent replay attacks sender • arbitrated protocol – Trent (3 rd party) has all the keys • symmetric encryption for transmitting a session key Page 30 Page 30 Page 31 Wide-mouth frog Wide-mouth frog Alice Trent Alice Trent Bob “alice” , E A (T A ,”bob”, K) “alice” , E A (T A ,”bob”, K) E B (T T ,”alice”, K) session key session key destination source time stamp – prevent replay attacks time stamp – prevent replay attacks sender Trent: Trent: • looks up key corresponding to sender (“alice”) • creates a new message • decrypts remainder of message using Alice’s key • new timestamp • validates timestamp (this is a new message) • identify source of the session key • extracts destination (“bob”) • encrypt the message for Bob • looks up Bob’s key • send to Bob Page 32 Page 33 5

Wide-mouth frog Wide-mouth frog Alice Trent Bob Alice Bob “alice” , E A (T A ,”bob”, K) E B (T T ,”alice”, K) E K (M) session key source time stamp – prevent replay attacks Bob: • decrypts message Since Bob and Alice have the session key, • validates timestamp they can communicate securely using the key • extracts sender (“alice”) • extracts session key, K Page 34 Page 35 Kerberos Kerberos • authentication service developed by MIT Users and services authenticate themselves to each other – project Athena 1983-1988 • trusted third party • symmetric cryptography To access a service: • passwords not sent in clear text – user presents a ticket issued by the Kerberos authentication server – assumes only the network can be compromised – service examines the ticket to verify the identity of the user Page 36 Page 37 Kerberos Authenticate, get permission Alice Authentication Server (AS) • user Alice wants to communicate with a service Bob “I want to talk to Bob” if Alice is allowed to talk to Bob, • both Alice and Bob have keys generate session key, S {“Bob’s server”, S} A • Step 1: Alice decrypts this: – Alice authenticates with Kerberos server • gets ID of “Bob’s server” • Gets session key and sealed envelope • gets session key • Step 2: TICKET • knows message came from AS sealed envelope – Alice gives Bob a session key (securely) {“Alice”, S} B eh? (Alice can’t read this!) – Convinces Bob that she also got the session key from Kerberos Page 38 Page 39 6