Kerberos ======== Topic: authentication over an insecure network MIT Athena's Kerberos one of the first; influential; still used Microsoft's Active Directory system based on Kerberos v5 Kerberos setting: Single organization. Many users. Many public workstations. Many servers: remote login, mail, printing, file server. Each user logs into their own workstation, has root access. Adversary may have workstation, account, ability to read network traffic. Goal: allow users to authenticate themselves to services. Goal: no passwords in the clear over the network. The key management problem: if X and Y already share a crypto key, they can set up a "secure channel". what if X and Y don't already share a key? don't want to set up N^2 keys pairs in advance idea: everyone shares a key with a central Authentication Server X tells AS "I want to talk to Y" AS makes a session key, gives it to X, gives it to Y AS can talk securely to both X and Y now X and Y share a key, so they can talk securely too Overall architecture diagram: +-----------------------+ c, tgs | | [ User: Kc ] <--------> [ AS ] | ^ \ | Database: | | \ | c: Kc | V \ s | s: Ks | [ Server: Ks ] \--------> [ TGS ] tgs: Ktgs | | | | KDC | +-----------------------+ The protocol (Kerberos v4): User "c" logs into workstation and wants to talk to server "s". AS is Authentication Server, TGS is ticket-granting server. User types user-name "c" and password (Kc) to a workstation. 1. C -> AS: "c", "tgs" 2. C <- AS: {Kc-tgs , Tc,tgs}Kc 3. C -> TGS: "s", Tc-tgs, Ac-tgs 4. C <- TGS: {Kc-s, Tc-s}Kc-tgs 5. C -> S: Ac-s, Tc-s 6. C <- S: {TS+1}Kc-s 7. C <-> S: {data, TS}Kc-s Tc-s : {"s", "c", addr, TS, lifetime, Kc-s}Ks -- a "ticket" Ac-s : {"c", addr, TS}Kc-s -- an "authenticator" TS : time-stamp, close to current time and not repeated. What are the entities sure of at the start? Client: Kc (user's password) AS: Kc and Ktgs TGS: Ktgs and Ks S: Ks What can S conclude about source of msg #5? ... the principal that the AS calls "c". What is the point of msg #6? What can C conclude about src of msg #6? ... the principal for which the TGS gave us a ticket. What do the names "s" and "c" really mean? The protocol pushes this question back to the AS. "The entity that knows the key that the AS calls "c"." The names don't mean anything, but now we have a secure way to agree on human-readable names for entities. How does the AS get correct password for Client? How does the TGS get server's key Ks? Kerberos changes work of key distribution from O(N^2) to O(N). What can the server do now? It knows the user's name, e.g. rtm@mit, and IP address. It can look for the user's name in file-system access control-lists &c. So users can put human-readable names in their ACLs; "rtm@mit" looks like a mere string but securely names password owner. How is the rest of the client/server conversation protected? Client may send a sequence of e.g. file system operations. How does server know that they are from the user that authenticated? c and s now share a session key Kc-s that others don't know. Kc,s can be used to build a secure channel. { data, TS } Kc-s Their own DES block chaining scheme; private, and modified data will usually wreck decryption of timestamp. Don't try this at home; use a real secure channel scheme like TLS. The paper's NFS appendix says only the initial client/server connection is authenticated, NFS server remembers IP addr -> username mapping. No crypto after that -- NFS server only checks source IP address. Depends on attackers not forging src IP, not guessing NFS handles. Pretty reasonable at the time, though it looks weak now. Why the AS / TGS split? Workstation remembers Kc,tgs and Tc,tgs (and others). So can authenticate to new servers w/o needing password Kc. Workstation erases memory of password after AS exchange. Good b/c password is very sensitive, don't want it stolen from workstation memory. TGS shares key DB with AS, runs on same machine. Why authenticator needed? Ticket is basically public, anyone can see and then send it. Must have a way to force client to prove that it knows Kc-s. For one-message-pair exchanges (e.g. TGS), or for when rest of conversation isn't protected (e.g. NFS). Can the attacker see and replay a ticket+authenticator? What is the point of these ticket fields: s (perhaps avoid mistakes? in case multiple servers use same key?) c (so server knows client's name -- this is the main point) addr (harder to steal ticket, use on another machine) TS+lifetime (limit damage from a stolen ticket) What would happen if attacker tried to modify a ticket, e.g. get a legitimate ticket, then change the client name? What can the client verify about server's identity? Does the client know what server the ticket is for? Does it matter whether the client can verify server's identity? How is C sure msg #2 is from the real AS? How is AS sure it is talking to the real C in msg #1/#2? Problem: off-line brute-force password-guessing using message #2. I can ask for a message #2 for any user. Doesn't look suspicious -- only one request to AS (not one per guess). Kerberos v5: client sends {TS}Kc to AS, to prove it knows Kc. Still vulnerable to password guessing by network sniffer at that time. What if the various servers don't have synchronized time? What attacks does that open up? Is secure synchronized time a reasonable assumption? Could someone steal my tickets from workstation's memory? Does Kerberos make sense for time-sharing e.g. athena.dialup.mit.edu? How do you know if it's safe to type your password to a computer that says "MIT Athena Workstation" on it? What if an attacker learns my Kerberos password? Perhaps by looking over my shoulder as I type. Now would be a good time for me to change my password. Adversary could change your password, too! What happens in that case? There is a password-change service on the KDC. I get a ticket to it, and send it my new password (encrypted with Kc-s). Can the attacker, who knows my old password, look at my network traffic and figure out my new password? What if the attacker has been recording all traffic, somehow learns your last year's password (no longer valid)? Kerberos lacks "forward secrecy". It would be better if client/server could set up a session key that the AS *didn't* know! I.e. wasn't included in the ticket! This can be done -- look up Diffie-Hellman key exchange. What if an attacker steals my TGS ticket and session key? Can they authenticate to new services? Ticket lifetime propagated to new service tickets. Can they change my password? Tickets contain "initial" flag indicating if they came via AS or TGS. Password-change service requires an "initial" ticket obtained w/ password. Can they still access services if I change my password? Can use existing tickets. TGS may be able to prevent issue of new service tickets based on old TGS ticket. Would need to look at ticket lifetime in the ticket, and track pw change time. AS DB / KDC is critical and must be on-line -- how to protect it? What happens if the KDC is down? Cannot log in. Cannot obtain new tickets. Can keep using existing tickets. Replicated KDC for availability. One master server (supports password changes), zero or more slaves. All servers can issue tickets, only master can change keys. Why this split? Only one master ensures consistency: cannot have conflicting changes. Master periodically updates the slaves (when paper was written, ~once/hour). More recent impls have incremental propagation: lower latency (but not 0). How scalable is this? Symmetric crypto (DES, AES) is fast -- O(100MB/sec) on current hardware. Tickets are small, O(100 bytes), so can support 1M tickets/second. Easy to scale by adding slaves. Potential problem: password changes take a while to propagate. Adversary can still use a stolen password for a while after user changes it. Realms: how does an MIT user get authenticated access to a CMU server? E.g. I want to look at /afs/cs.cmu.edu. CMU's AFS servers needs to know who I am. I need to know I'm really talking to CMU's server. Kerberos Realms: MIT and CMU are separate realms; user1@mit, user2@cmu, &c. MIT TGS and CMU TGS share a key that administrators set up. CMU's TGS looks like a principal to MIT's TGS. I talk to MIT's TGS, ask for ticket to CMU's TGS. I talk to CMU's TGS, ask for ticket to CMU's AFS server. I talk to CMU's AFS server. But I am not a user at CMU! So what can CMU's AFS server do for me? Users at CMU can put "rtm@mit" in file ACLs, and I can read them. Kerberos v4 inter-realm authentication takes N^2 key setup, and must be done by admins, not users. Kerberos v5 does better here -- hierarchy via ".edu". Why didn't Kerberos use public key crypto? Too slow: computers were 1000x slower than today. Government export restrictions. Patents. Why not use Kerberos for web pages in place of SSL/Verisign? Online AS/TGS would see a very high load. Single name-space a big management/trust headache (maybe realms help). Requires clients to have identities: no anonymous browsing. So: Kerberos good for users and services in an organization.