CS 4803 Computer and Network Security Servers Users How do users - PowerPoint PPT Presentation

Many-to-Many Authentication ? CS 4803 Computer and Network Security Servers Users How do users prove their identities when requesting services from machines on the network? Alexandra (Sasha) Boldyreva Naïve solution: every server knows every user’s password • Insecure: compromise of one server is enough to compromise all users Kerberos • Inefficient: to change his password, user must contact every server 1 2 Recall the threats Requirements • User impersonation • Security • Malicious user with access to a workstation pretends to be • Against attacks by passive eavesdroppers and actively another user from the same workstation malicious users • Network address impersonation • Reliability • Malicious user changes network address of his workstation • Transparency to impersonate another workstation • Users shouldn’t be aware of authentication taking place • Eavesdropping, tampering and replay • Entering password is OK, if done rarely • Malicious user eavesdrops on, tampers with or replays other users’ conversations to gain unauthorized access • Scalability • Large number of users and servers 3 4

What is a ticket for? Solution: Trusted Third Party Knows all users’ and servers’ passwords Ticket gives holder User requests ticket for some access to a network service service; proves his identity User Server User receives ticket Ticket is used to access Servers desired network service User • 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 5 6 What Should a Ticket Include? How Is Authentication Done? Knows all users’ and User servers’ passwords Encrypted ticket Server Password Encrypted User ticket Encrypted ticket Authentication server • User name • Insecure: passwords are sent in plaintext • Server name • Eavesdropper can steal the password and later impersonate • Address of user’s workstation the user to the authentication server • Otherwise, a user on another workstation can steal the ticket and use it to gain • Inconvenient: need to send the password each time to obtain access to the server the ticket for any network service • Ticket lifetime • Separate authentication for email, printing, etc. • A few other things (e.g., session key) 7 8

Still Not Good Enough Solution: Two-Step Authentication • Ticket hijacking Prove identity once to obtain special TGS ticket • Malicious user may steal the service ticket of another user on Instead of password, use key derived from password the same workstation and use it Use TGS to get tickets for many network services • IP address verification does not help • Servers must be able to verify that the user who is USER=Joe; service=TGS presenting the ticket is the same user to whom the ticket was Joe the User issued Encrypted TGS ticket Authentication server (AS) Key • No server authentication TGS ticket distribution center (KDC) Ticket granting • Attacker may misconfigure the network so that he receives Encrypted service (TGS) service ticket messages addressed to a legitimate server File server, printer, Encrypted service ticket other network services • Capture private information from users and/or deny service • Servers must prove their identity to users 9 10 Symmetric Keys in Kerberos Summary of Kerberos • Kc is long-term key of client C • Derived from user’s password • Known to client and key distribution center KDC • KTGS is long-term key of ticket granting service TGS • Known to KDC and TGS • Kv is long-term key of network service V • Known to V and TGS; separate key for each service • Kc,TGS is short-term key between C and TGS • Created by KDC, known to C and TGS • Kc,v is short-term key betwen C and V • Created by TGS, known to C and V 11 12

Obtaining A Service Ticket “Single Logon” Authentication Ticket Granting Client EncryptKc,TGS(IDc , Addrc , kinit program (client) Service (TGS) Key Distribution timec) Knows Kc,TGS Center (KDC) usually lives inside KDC and ticketTGS password IDc , IDTGS , timec System command, IDv , ticketTGS , authC e.g. “lpr –Pprint” Convert into client master key User EncryptKc,TGS(Kc,v , IDv , timeTGS , Kc EncryptKc(Kc,TGS , IDTGS , timeKDC , User ticketv) lifetime , ticketTGS) Decrypts with Fresh key to be used Knows key Kv for Kc and obtains Fresh key to be used between client and service between client and TGS each service Kc,TGS and TGS Key = KTGS EncryptKv(Kc,v , IDc , Addrc , IDv , ticketTGS Key = Kc EncryptKTGS(Kc,TGS , IDc , Addrc , timeTGS , lifetime) … IDTGS , timeKDC , lifetime) All users must pre-register their passwords with KDC � Client uses TGS ticket to obtain a service ticket and a short-term key for each network service One encrypted, unforgeable ticket per service (printer, email, etc.) � 13 14 Obtaining Service Kerberos in Large Networks • One KDC isn’t enough for large networks (why?) Client EncryptKc,v(IDc , Addrc , timec) Knows Kc,v Server V and ticketv • Network is divided into realms System command, ticketv , authC e.g. “lpr –Pprint” • KDCs in different realms have different key databases EncryptKc,v(timec+1) User • To access a service in another realm, users must… Authenticates server to client • Get ticket for home-realm TGS from home-realm KDC • Get ticket for remote-realm TGS from home-realm TGS � For each service request, client uses the short-term key for that service and the ticket he received from TGS • As if remote-realm TGS were just another network service • Get ticket for remote service from that realm’s TGS • Use remote-realm ticket to access service • N(N-1)/2 key exchanges for full N-realm interoperation 15 16

Problematic Issues Important Ideas in Kerberos • Use of short-term session keys • Password dictionary attacks on client master keys • Replay of authenticators • Minimize distribution and use of long-term secrets; use them only to derive short-term session keys • 5-minute lifetimes long enough for replay • Timestamps assume global, secure synchronized clocks • Separate short-term key for each user-server pair • Challenge-response would be better • But multiple user-server sessions reuse the same key! • Encryption is used for authentication • Proofs of identity are based on authenticators • Same user-server key used for all sessions • Client encrypts his identity, address and current time • Homebrewed PCBC mode of encryption using a short-term session key • Tries to combine integrity checking with encryption • Also prevents replays (if clocks are globally • Extraneous double encryption of tickets synchronized) • No ticket delegation • Server learns this key separately (via encrypted ticket • Printer can’t fetch email from server on your behalf that client can’t decrypt) and verifies user’s identity 17 18 Practical Uses of Kerberos Kerberos Version 5 • Email, FTP, SSH, network file systems and many other • Better user-server authentication applications have been kerberized • Separate subkey for each user-server session instead of re- • Use of Kerberos is transparent for the end user using the session key contained in the ticket • Transparency is important for usability! • Authentication via subkeys, not timestamp increments • Local authentication • Authentication forwarding • login and su in OpenBSD • Servers can access other servers on user’s behalf • Authentication for network protocols • Realm hierarchies for inter-realm authentication • rlogin, rsh, telnet • Richer ticket functionality • Secure windowing systems • Explicit integrity checking + standard CBC mode • xdm, kx • Multiple encryption schemes, not just DES 19 20