6.824 2002 Lecture 14: Key management - In the previous lectures we have seen how to authenticate and encrypt messages, with both symmetric and public-key techniques. These techniques presuppose that parties have already created and appropriate distributed the cryptographic keys to be used. Today we talk about how to distribute keys in a secure manner. - We will focus on server authentication: how users verify that they are talking to the right server. Server authentication is often harder than user authentication: (1) there are a huge number of servers out there, (2) clients often can't keep as much state as servers (i.e. big lists of public keys), (3) you may want to support web-like anonymous access. One a user knows he/she is talking to a trusted server, the user may be willing to provide user identity with a password. - The primary attack of concern is server impersonation. If we don't have server authentication, then 1. a user might write sensitive data to a server controlled by attacker 2. the attacker might substitute data - Central question: User (or client) knows which server it wants to talk to That is, it knows the *name* of the server User wants to learn the server's public key Typically consults a trusted third party, a "certificate authority" Once user knows server's key, we can use SSL &c When things go wrong, usually has to do with what the *name* means. Does it really name the entity the user had in mind? Do the user and the CA agree on what the name means? - Example: server authentication in the Web. In web browser, user clicks on www.amazon.com and sets up an SSL connection with an IP address for the DNS name amazon.com. As part of the connection setup the SSL protocol verifies the name amazon.com using amazon's server certificate. amazon.com obtained the server certificate from certificate authority (e.g., verisign). Thus: 1. server -> verisign please give me a certificate binding "amazon.com" to pub key K 2. verisign convinces itself that whoever really owns "amazon.com" 3. verisign -> server certificate {"amazon.com", K} signed by verisign's private key 4. browser -> server connection request 5. server -> browser: {amazon.com, K} signed with verisign's private key [browser verifies certificate using verisign's public key] 6. browswer sends request Certificate: struct X509_certificate { unsigned version; unsigned serial; signature_cipher_identifier; issuer_signature; issuer_name; subject_name; subject_public_key_cipher_identifier; subject_public_key; validity_period; }; - Where did the browser get verisign's public key? - The browser has a number of public keys embedded in its binary (incl. Verisign's public key). So, we trust Netscape or Microsoft to put in the right public key. And everybody who has had their hands on the browser between Microsoft and us. - There is a user panel where users can add public keys for certificate authorities. - Why should the browser believe the certificate? - Verisign ran an "extensive" certification procedure to verify that amazon the book stores indeed owns amazon.com. So, what does it do? Verisign ask for your articles of incorporation for a company with the appopriate name. Verisign checks whether you own the DNS name that you getting a certificate for. Etc. Tension: between convenience and security. If the certification procedure is precise than certificate means a lot but it is a pain in the neck for the server company. If the certification procedure is lax, then certificate doesn't mean anything. - What does a certificate mean when the private key of amazon is compromised? [nothing]. What if verisign's private key is compromised? [all certificates signed by verisign mean nothing---verisign should keep its key secure (e.g, off-line)!] - How does one revoke certificates? [Certificate revocation lists (don't really work) and timeout (6-12 months).] - SSL machinery more or less checks that browser is actually talking to server named in URL. But connection to what user wanted is pretty vague. Did the user intend to visit the book store? what if the user clicks "aamazon.com"? does certificates solves this problem? [no; if the aazon.com's web site looks like amazon.com's there is no way to tell the difference to figure out that you want amazon instead of aamazon.] - What happens if the dns name in the certificate is different from the one you typed at the browser? - the first time a windown pops up - if you say continue, it is validated for future use! [See Fu's CERT advisory.] - Example: Kerberos - See Kohl, Neuman, and Ts'o, "The Evolution of the Kerberos Authentication Service" - Kerberos based on symmetric-key system using secret keys and a centralized auhentication server. The authentication server authenticates the client and helps in setting up an authenticated connection betwen the client and the server. From Kerberos V5 RFC: The authentication process proceeds as follows: A client sends a request to the authentication server (AS) requesting "credentials" for a given server. The AS responds with these credentials, encrypted in the client's key. The credentials consist of 1) a "ticket" for the server and 2) a temporary encryption key (often called a "session key"). The client transmits the ticket (which contains the client's identity and a copy of the session key, all encrypted in the server's key) to the server. The session key (now shared by the client and server) is used to authenticate the client, and may optionally be used to authenticate the server. It may also be used to encrypt further communication between the two parties or to exchange a separate sub-session key to be used to encrypt further communication. Alice logs in and wants to talk to a server named Bob. A is Alice, B is Bob, AS the Authentication Server, TGS is the ticket granting server. Typical scenario (this is really Kerberos v5): 0. Alice types her user-name to a workstation. 1. A -> AS. "My login name is Alice." 2. A <- AS. {Ka,tgs {Ka,tgs}Ktgs}PwdA 3. Alice types her password to the workstation. 4. A -> TGS. "Bob", {Ka,tgs}Ktgs, {"Alice",TS}Ka,tgs 5. A <- TGS. {{Ka,b}Kb, Kab}Ka,tgs 6. A -> B. {Ka,b}Kb, {"Alice",TS}Ka,b 7. A <- B. {TS+1}Ka,b What does Alice know? PwdA // Ka,tgs ticket What does AS know? PwdA Ktgs What does TGS know? Ktgs Kb What does Bob know? Kb {Kc,s}Ks,tgs is a "ticket". It establishes a session key between client c and server c, and is signed by the key Ks,tgs shared between the server and the ticket-granting server. Actual ticket format: {server-name, client-name, client-ip, TS, lifetime, Kc,s} How is A sure that she is talking to B? How is A sure she isn't seeing a replayed reply? How is B sure he is talking to A? How is B sure he isn't seeing a replayed request? How is A sure she is talking to the real AS? The protocol pushes all these questions back to the AS. How does the AS get correct password for A? How does the TGS get Bob's key Kb? Kerberos changes key distribution from O(N^2) to O(N). Why the AS / TGS split? I think to avoid the workstation having to remember Alice's password. I think AS and TGS have access to the same key database. - Suppose I want to implement an Access Control List (ACL) using Kerberos. For example, to control access to my directory on AFS. I want to list users who can read or write my directory. What exactly should I put in the ACL? That is, what is a Kerberos "identity"? Why does that make sense? - How can I revoke an account? Take it out of the AS's database. But user may still have a valid ticket, good for a day. - How can I revoke a user's authorization? Remove user from an ACL. Takes effect immediately? - What attacks might a Kerberos-based system be vulnerable to? Password-guessing based on recorded message #2. Could collect many of them. Replay within lifetime of authenticator. Attack the time synchronization system. If many users share e.g. athena.dialup.mit.edu, steal tickets from disk/memory. AS stores user passwords in the clear; break in and steal them all. User types password to workstation in clear; fake login: prompt. - Would Kerberos in practice make a big improvement to security? Compared to what? Non-cryptographic NFS and telnet? - Why not use Kerberos on the WWW in place of SSL/Verisign? Requires clients to have identities: no anonymous browsing. Only one identity space (realms sort of fixes this). Central authority involved in adding a new user or server. - How does an MIT user get authenticated access to a CMU server? That is, how can the MIT user trust the results of /afs/cs.cmu.edu? Needs to get a ticket for cs.cmu.edu file server. It requires that the administrators at MIT and CMU exchange inter-realm keys, which registers the local TGS as a principle in the remote realm and vice versa. This means Kerberos inter-realm authentication is O(N^2), and must be done by administrators, not users. [as noted by the RFC better automatic solutions are needed if cross-realm access is common.]