Vitaly Shmatikov CS 361S Kerberosslide 2 Reading Assignment Kaufman Chapters 13 and 14 “Designing an Authentication System: A Dialogue in Four Scenes” • A high-level survey of network threats and design principles behind Kerberosslide 3 Many-to-Many Authentication How do users prove their identities when requesting services from machines on the network? Users Servers ? Naïve solution: every server knows every user’s password • Insecure: break into one server  compromise all users • Inefficient: to change password, user must contact every serverslide 4 Requirements Security • … against attacks by passive eavesdroppers and actively malicious users Transparency • Users shouldn’t notice authentication taking place • Entering password is Ok, if done rarely Scalability • Large number of users and serversslide 5 Threats User impersonation • Malicious user with access to a workstation pretends to be another user from the same workstation Network address impersonation • Malicious user changes network address of his workstation to impersonate another workstation Eavesdropping, tampering, replay • Malicious user eavesdrops, tampers, or replays other users’ conversations to gain unauthorized accessslide 6 Solution: Trusted Third Party User Servers 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 User proves his identity; requests ticket for some service User receives ticket Ticket is used to access desired service Knows all users’ and servers’ passwordsslide 7 What Should a Ticket Look Like? User Server User should not be able to access server without first proving his identity to authentication service Ticket proves that user has authenticated • Authentication service encrypts some information with a key known to the server (but not the user!) – The only thing the user can do is pass the ticket to the server – Hash functions would’ve worked well, but this is 1980s design • Server decrypts the ticket and verifies information Ticket gives the holder access to a network serviceslide 8 What Should a Ticket Include? Server Encrypted ticket Knows passwords of all users and servers Encrypted ticket User  User name  Server name  Address of user’s workstation • Otherwise, a user on another workstation can steal the ticket and use it to gain access to the server  Ticket lifetime  A few other things (session key, etc.)slide 9 Naïve Authentication Encrypted ticket User Authentication server Password Insecure: passwords are sent in plaintext • Eavesdropper can steal the password and later impersonate the user to the authentication server Inconvenient: need to send the password each time to obtain the ticket for any network service • Separate authentication for email, printing, etc.slide 10 Two-Step Authentication Encrypted TGS ticket Joe the User Key distribution center (KDC) USER=Joe; service=TGS Prove identity once to obtain a special TGS ticket Use TGS to get tickets for any network service File server, printer, other network services Encrypted service ticket Ticket granting service (TGS) TGS ticket Encrypted service ticketslide 11 Threats Ticket hijacking • Malicious user may steal the service ticket of another user on the same workstation and try to use it – Network address verification does not help • Servers must verify that the user who is presenting the ticket is the same user to whom the ticket was issued No server authentication • Attacker may misconfigure the network so that he receives messages addressed to a legitimate server – Capture private information from users and/or deny service • Servers must prove their identity to usersslide 12 Symmetric Keys in Kerberos Kc is long-term key of client C • Derived from the user’s password • Known to the client and the key distribution center (KDC) KTGS is long-term key of TGS • Known to KDC and the ticket granting service (TGS) Kv is long-term key of network service V • Known to V and TGS; each service V has its own long-term key Kc,TGS is short-term session key betw. C and TGS • Created by KDC, known to C and TGS Kc,v is short-term session key between C and V • Created by TGS, known to C and Vslide 13 “Single Logon” Authentication User  Client only needs to obtain TGS ticket once (say, every morning)  Ticket is encrypted; client cannot forge it or tamper with it kinit program (client) Key Distribution Center (KDC) password IDc , IDTGS , timec EncryptKc(Kc,TGS , IDTGS , timeKDC , lifetime , ticketTGS) Kc Convert into client master key Key = Kc Key = KTGS TGS … All users must pre-register their passwords with KDC Fresh key to be used between client and TGS Decrypts with Kc and obtains Kc,TGS and ticketTGS Implicit authentication: only someone who knows Kc can decrypt EncryptKTGS(Kc,TGS , IDc , Addrc , IDTGS , timeKDC , lifetime) Client will use this unforgeable ticket to get other tickets without re-authenticatingslide 14 Obtaining a Service Ticket User  Client uses TGS ticket to obtain a service ticket and a short-term session key for each network service (printer, email, etc.) Client Ticket Granting Service (TGS) usually lives inside KDC System command, e.g. “lpr –Pprint” IDv , ticketTGS , authC EncryptKc,TGS(Kc,v , IDv , timeTGS , lifetime , ticketv) Fresh key to be used between client and service Knows Kc,TGS and ticketTGS EncryptKc,TGS(IDc , Addrc , timec) Proves that client knows key Kc,TGS contained in encrypted TGS ticket EncryptKv(Kc,v , IDc , Addrc , IDv , timeTGS , lifetime) Client will use this unforgeable ticket to get access to service V Knows key Kv for each serviceslide 15 Obtaining Service User Client Server V System command, e.g. “lpr –Pprint” ticketv , authC EncryptKc,v(timec+1) Knows Kc,v and ticketv EncryptKc,v(IDc , Addrc , timec) Proves that client knows key Kc,v contained in encrypted ticket Authenticates server to client Reasoning: Server can produce this message only if he knows key Kc,v. Server can learn key Kc,v only if he can decrypt service ticket. Server can