1 KERBEROS: AN AUTHENTICATION SERVICE FOR OPEN NETWORK SYSTEMS J. G. Steiner, C. Neuman, J. I. Schiller MIT

2 AUTHENTICATION SERVERS (I) Their mission is: (a) To check identity of all users (b) To prevent unauthorized accesses Traditional solution is to use a pair (userid, password) –Very bad in a LAN environment –Too vulnerable to snooping

3 AUTHENTICATION SERVERS (II) Another bad solution is to trust the kernel of sender’s machine: –Solution used by rlogin, rsh, rcp –Like trusting a foreign passport –Only works in well-controlled networks –Suffers from domino effect : Gaining full access to one machine gives full access to whole network

4 CRYPTOGRAPHY (I) 1. Conventional Cryptography –Uses same key for coding and encoding Key could be a secret alphabet –We now use much more complex schemes and much bigger keys –Major problem is key distribution Very hard without a trusted channel

5 Example Assume we have a random stream of bits: r 0, r 1, r 2, r 3,... We convert our message into a bit stream: m 0, m 1, m 2, m 3,... Encode the message bitwise using XOR : c i = m i  r i for i = 1, 2, 3,... Impossible to break if random bit stream is truly random and never reused

6 CRYPTOGRAPHY (II) 2. Public-Key Cryptography –Uses two keys: (a) A public key to encode: K P (b) A secret key to decode: K S –It is not possible to compute K S knowing K P The function K P = f ( K S ) is said to be hard to invert :

7 CRYPTOGRAPHY (II) –We should have { { cleartext } K P } K S = cleartext { { cleartext } K S } K P = cleartext –Requires very long keys – Cannot pick an arbitrary secret key –Much slower than conventional cryptography

8 Example Assume A knows K P, B and B knows K P, A – A can send to B a secret message : { text } K P, B – A can send to B a message that is signed : A, { text } K S, A – A can send to B a signed secret message: { A, { text } K S, A } K P, B

9 Application Can combine conventional cryptography and public-key cryptography – A uses public-key cryptography to send to B a signed secret message containing a session key K S –A and B use this session key K S to continue their dialogue

10 KERBEROS Authentication server using conventional keys The Kerberos server has –The key of each user –The key of the ticket granting service (TGS) Authentication is a two-step process –Get from kerberos a ticket for the TGS –Get from TGS the ticket for a given server

11 WS K S TGS General Organization Ticket granting service KerberosServer Client c on workstation WS

12 General Assumptions (I) Cannot trust the network: –Intruders can listen to all messages and replay them later Can trust the time service –No intruder can reset any clock backward by more than a few minutes

13 General Assumptions (II) Client c can trust the workstation WS on which she is logged on: –Cannot do encryption without a safe place to encode and decode messages Assumes the workstation is controlled by the client –Not true for public workstations

14 Step 1 Client provides WS with its ID c : c  WS : c WS sends to Kerberos a request for a ticket for the TGS: WS  K : c, tgs

15 Step 2 Kerberos sends to WS a ticket T c,tgs and a random session key K c,tgs : K  WS : { K c,tgs, { T c,tgs } K tgs } K c Both items are encrypted with the client key K c Ticket is encrypted with the secret key of the ticket granting service to prevent tampering by client

16 The ticket (I) Note that the encrypted ticket is encrypted a second time by the client key K C –In more recent versions of Kerberos K  WS : { K c,tgs } K c, { T c,tgs } K tgs

17 The ticket (II) T c,tgs = c, tgs, addr, timestamp, life, K c,tgs It contains –The client's name c –The name of the ticket-granting service tgs –The IP address of the client addr –The current time timestamp –A ticket lifetime life –The random session key K c,tgs

18 Step 3 When WS receives Kerberos reply, it prompts the client c for her password and uses it to compute the user key K c = fn(password) and uses K c to decrypt the message

19 WS K S TGS Shared Secrets Server KcKc K tgs KsKs

20 Step 3 (continued) WS then sends to the TGS –The name of the service s the client wants to utilize –The encrypted ticket T c,tgs – An authenticator A c,tgs encrypted with K c,tgs WS  TGS : s, { T c,tgs } K tgs, { A c,tgs } K c,tgs

21 The authenticator (I) Any intruder could replay a ticket that has already be submitted to TGS Authenticator contains –The client name c –Its address addr –The current time timestamp A c,tgs = c, addr, timestamp Authenticator is encrypted with K c,tgs

22 The authenticator (II) Authenticator provides proof that WS was able to obtain the session key K c,tgs by decrypting message number 2 using the right client key K C To detect replays of authenticators, TGS –Rejects authenticators that are too old (say, by more than five minutes) –Keeps track of all recently received authenticators

23 Step 4 The TGS replies by sending to the workstation – A ticket T cs for the service s – A new random session key K c,s TGS  WS : { K c,s, { T c,s } K s } K c,tg s encrypted with the session key K c,tgs shared by the client and the ticket granting service

24 Step 4 (continued) T c,s contains –The user's name c –The name of the service s –The IP address of the client addr –The current time timestamp –A new lifetime life –A new random session key K c,s T c,s is encrypted with the secret key of server s

25 Step 5 WS then sends to server S –the encrypted ticket T c,s – an authenticator A c,s encrypted with K c,s WS  S : { T c,s } K s, { A c,s } K c,s

26 Step 5 (continued) Authenticator contains –the client name c –its address addr – the current time timestamp A c,s = c, addr, timestamp Authenticator is encrypted with the session key K c,s shared by client and server

27 Step 6 If client wanted to authenticate server, the server replies with the authenticator time stamp plus one: s  WS : { timestamp + 1 } K c,s encrypted with the session key K c,s This proves that s was able to obtain the session key K c,s by decrypting message number 5 using its server key K s

28 Picking ticket lifetimes There is a trade-off in determining the optimal ticket lifetime: – Short ticket lifetimes make the system more secure Less delay between password change and full effect of action –Short ticket lifetimes also make the system less convenient for its users.

29 The Kerberos server (I) Most critical part of the system –If it is compromised, all user passwords are lost –If it is unavailable, nobody will be able to log in A compromised TGS would only force all users to repeat the Kerberos login procedure

30 The Kerberos server (II)  The Kerberos server is normally replicated on several sites: –No single point of failure –More difficult to maintain key secrecy  There is a single primary site and it is the only than can accept key change requests –Changing passwords is not a critical task

31 LIMITATIONS Must maintain –secrecy of keys –integrity of time service Client must trust the workstation on which she is logged in Does not protect clients and servers against denial of service attacks

32 OTHER SOLUTIONS (I) Could use a pair public key / private key –private keys cannot be generated from an arbitrary password –impossible to memorize –must store them somewhere key ring of PGP is encrypted using a strong conventional encryption algorithm

33 OTHER SOLUTIONS (II) Could use one-time passwords –Use a different password at each log in –Passwords can be managed by a smart card –User must always carry it with her –Some systems also require a password to use the card and disable card after enough unsuccessful trials Must keep card in a rigid container

34 OTHER SOLUTIONS (III) SSH-2 uses –Diffie-Hellman key exchange Uses public keys and private keys Produces a symmetric session key –Strong integrity checking via message authentication codes.

35 OTHER SOLUTIONS (IV) Two-factor authentication –Must provide Something you know (a password) Something you have (a dongle or a phone) –Google two-factor authentication: Enter first name and password Google sends a six-digit code to your phone that you must then enter

36 CONCLUSIONS Kerberos offers one of the best solutions for authentication in distributed systems –Does not require any special equipment –Does not significantly alter the user interface Main drawback is that the user must trust the workstation on which she is logged in –Works best for personal workstations