360 likes | 690 Views
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)
E N D
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) • Very bad in a LAN environment • Too vulnerable to snooping
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
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
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 = miri for i = 1, 2, 3 , ... • Impossible to break if random bit stream istruly random and never reused
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:
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
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
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
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
General Organization Ticket granting service TGS 3 4 Kerberos Server 2 5 6 S 1 WS K Client c on workstation WS
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
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
Step 1 • Client provides WS with its ID c: c WS: c WS sends to Kerberos a request for a ticket for the TGS: WSK: c, tgs
Step 2 • Kerberos sends to WS a ticket Tc,tgs and a random session key Kc,tgs: KWS: { 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
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 KWS: { Kc,tgs }Kc, { Tc,tgs}Ktgs
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
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
Shared Secrets TGS Ks Ktgs Server Kc S WS K
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 WSTGS: s, { Tc,tgs}Ktgs, { Ac,tgs }Kc,tgs
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
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
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 TGSWS: { Kc,s, { Tc,s}Ks}Kc,tgs encrypted with the session key Kc,tgs shared by the client and the ticket granting service
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
Step 5 • WS then sends to server S • the encrypted ticket Tc,s • an authenticator Ac,s encrypted with Kc,s WSS: { Tc,s }Ks, { Ac,s }Kc,s
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
Step 6 • If client wanted to authenticate server, the server replies with the authenticator time stamp plus one: sWS: { 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
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.
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
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
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
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
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
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.
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