1 / 35

KERBEROS: AN AUTHENTICATION SERVICE FOR OPEN NETWORK SYSTEMS

KERBEROS: AN AUTHENTICATION SERVICE FOR OPEN NETWORK SYSTEMS. J. G. Steiner, C. Neuman, J. I. Schiller MIT. 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)

albert
Télécharger la présentation

KERBEROS: AN AUTHENTICATION SERVICE FOR OPEN NETWORK SYSTEMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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: r0 , r1 , r2 , r3 , ... • We convert our message into a bit stream: m0 , m1 , m2 , m3 , ... • Encode the message bitwise using XOR: ci = miri for i = 1, 2, 3 , ... • Impossible to break if random bit stream istruly random and never reused

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

  7. CRYPTOGRAPHY (II) • We should have • { { cleartext }KP }KS = cleartext • { { cleartext }KS }KP = cleartext • Requires very long keys • Cannot pick an arbitrary secret key • Much slower than conventional cryptography

  8. Example • Assume A knows KP, B and B knows KP, A • A can send to B a secret message: { text } KP, B • A can send to B a message that is signed: A, { text } KS, A • A can send to B a signed secret message: { A, { text }KS, A} KP, B

  9. Application • Can combine conventional cryptography and public-key cryptography • A uses public-key cryptography to send to B asigned secret message containing a session key KS • A and B use this session key KSto 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. General Organization Ticket granting service TGS 3 4 Kerberos Server 2 5 6 S 1 WS K 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 Tc,tgs and a random session key Kc,tgs: KWS: { Kc,tgs, { Tc,tgs }Ktgs}Kc Both items are encrypted with the client key Kc 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 ticket is encrypted a second time by the client key KC • In more recent versions of Kerberos KWS: { Kc,tgs }Kc, { Tc,tgs}Ktgs

  17. The ticket (II) • Tc,tgs = c, tgs, addr, timestamp, life, Kc,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 Kc = fn(password) and uses Kc to decrypt the message

  19. Shared Secrets TGS Ks Ktgs Server Kc S WS K

  20. Step 3 (continued) • WS then sends to the TGS • The name of the service s the client wants to utilize • The encrypted ticket Tc,tgs • An authenticator Ac,tgs encrypted with Kc,tgs WSTGS: s, { Tc,tgs}Ktgs, { Ac,tgs }Kc,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 Ac,tgs = c, addr, timestamp • Authenticator is encrypted with Kc,tgs

  22. The authenticator (II) • Authenticator provides proof that WS was able to obtain the session key Kc,tgs by decrypting message number 2 using the right client key KC • 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 Kc,s TGSWS: { Kc,s, { Tc,s}Ks}Kc,tgs encrypted with the session key Kc,tgs shared by the client and the ticket granting service

  24. Step 4 (continued) • Tc,scontains • 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 Kc,s • Tc,sis encrypted with the secret key of server s

  25. Step 5 • WS then sends to server S • the encrypted ticket Tc,s • an authenticator Ac,s encrypted with Kc,s WSS: { Tc,s }Ks, { Ac,s }Kc,s

  26. Step 5 (continued) • Authenticator contains • the client name c • its address addr • the current time timestamp Ac,s = c, addr, timestamp • Authenticator is encrypted with the session key Kc,sshared 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 }Kc,s encrypted with the session key Kc,s • This proves that swas able to obtain the session key Kc,s by decrypting message number 5 using its server key Ks

  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. 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

More Related