Authentication in the Taos Operating System =========================================== [describe simple model in which principal signs every message.] E.g. every file server RPC. Very slow: Taos took 1/4 second to RSA sign. What if I ssh into a second machine. It needs to make authentic file server RPCs too. Does it send messages back to first machine for signature? How do I know they are authentic? I.e. why should I sign? What if I go home and leave a simulation running? Does SSL solve these problems? Assume both sides present certificates. It is fast, since it can use symmetric key ciphers. But workstation needs to know my private key for every connection. What if I ssh into a second machine? I want it to talk to the file server as well. Would have to give it my private key! Outline of Taos solution. Give every machine an identity: a public/private key. When I log into machine X I sign a certificate saying "DM says X speaks for DM." Which reflects reality -- X is running my programs! Then X can: Open an SSL-like secure chan from itself to file server. Now file server knows it's talking to X. Present "DM says X speaks for DM" to the file server. Now file server knows X can speak for me. Send my programs' RPCs to file servers. All done w/o my private key! So what would ssh to machine Y look like? We want Y to talk to the file server for DM. ssh on X signs "X says Y can speak for DM". Gives that cert to Y when I log in. Now Y presents a proof outline to file server: I'm Y. X says Y can speak for DM. DM says X can speak for DM. FS can check signatures and believe it! Why can't SSL do this? SSL involves exactly two players, and is tied to channels. If X says something to Y, Y can't prove anything to Z. Y can't even veryify anything after X hangs up. So hard to build distributed systems w/ > 2 parties. Why Taos is cool: Certificates are true independent of channels. Can be stored, passed to other parties. Used to prove transitive trust relationships. Let's try to figure out what the example in 2.2 means. Point: distinguish actions from logic. What are all the principals involved? Workstation firware, OS, Bob, Channel Keep track of who knows: Private keys. Signed certificates. Channel keys. Who knows what at the start? Workstation firmware knows Kvax4. User knows Kbob's private half. File server has Kbob's public half in an ACL. What does (1) mean? Workstation firmware makes up a fresh public/private key, Kws. Why not use Kvax4 directly? Don't want it to be stolen. Don't want statements to survive a reboot. I.e. login sessions. Signs "Kvax4 says (Kws speaks for Kvax4)". Kvax4 is never used again. Why preserve Kvax4's identity? ... why not pretend Kws is the workstation's true identity? I.e. why not have a workstation's identity survive reboot? What is "Kvax4 as OS" about? User might not trust some versions of the OS, or some OS. Want to allow that to be visible in ACLs. Now Vax4's authentication agent knows: Kws (but forgets Kvax4). (1) Why does Vax4 even need an identity? So Bob can delegate to it! What does (2) mean? Bob is delegating authority to the workstation. So workstation can act for Bob. Bob signs (2) with his private key, Kbob. Then private half Kbob is never used again, until next login. Why not "Kbob says (Kws speaks for Kbob)"? If Kws signs something, on whose behalf was it? Then statements by Kws are ambiguous. Perhaps usable out of context. Also Bob may distinguish between running on his personal secure workstation vs running on a public windows box. What does (A | B) mean? That A is doing the signing. That A is claiming (no proof yet) that A is speaking for B. This really means that A says in its signed statement that it's speaking for B. What does (A for B) mean? This is a logical conclusion that A is allowed to speak for B. Basically (A | B) plus a delegation like (2) (see delegation axiom p. 4). By default, interpreted as B for purposes of ACLs. But for those who care, preserves who actually signed (A). Now Vax4's auth agent knows: Kws private half. (1). (2). What does (3) mean? The file server received an RPC encrypted with Cbob. Channels are named by their symmetric cipher keys. This name is globally interpretable. "Cbob" does not imply anything about bob. Just signals authors' intent that Cbob carry messages from Bob. System has to establish proof of this. So all FS knows is that RQ arrived from someone who knows the key Cbob. Is it Kws? Kws on behalf of Bob? Kws on behalf of someone else? What does (4) mean? Vax4 sends it to FS to convince FS about meaning of Cbob. Vax4 probably creates (4) when Vax4/FS create the channel. We want somehow to link RQ encrypted with Cbob to Bob. Why not have Kbob sign "Cbob speaks for Kbob"? This is what SSL does. Because auth agent doesn't have Kbob! Why not have Kws sign "Cbob speaks for Kws"? Along with pre-signed "Kws speaks for Kbob"? Cbob doesn't speak for Kws in general! Only Kbob. (4) is nicely restricted: States exactly what we mean. Vax4 says Cbob speaks for (Vax4 speaking for Bob). But Vax4 could sign it whether or not Kbob agrees! So FS needs more evidence: is Vax4 allowed to speak for Bob? Let's assume that Vax4 sends all relvant signed certs to FS: (1). (2). (4). Now FS can reason about the meaning of Cbob says RQ. What does (Kws|Kbob) => (Kws for Kbob) mean? FS deduced it using logic from (2). If Bob signs a cert allowing Kws to speak for Bob, then Kws is allowed to speak for Bob. What it really means is: If Kws says it is speaking for Bob, then believe it. It is *not* "Kws speaks for Kbob". What does (5) mean? How is it different from (4) -- what has FS concluded? That Kws really does speak for Kbob -- not just claiming to. So what can we conclude about Cbob? Not quite that it speaks for Bob. But that it speaks for Kws speaking for Bob. Thus (6) tells FS that Kbob really is making RPC RQ. Look at protocol in 4.1.1 A -> B: {Ja}_Kb B -> A: {Jb}_Ka K = H (Ja, Jb) Is this secure? Looks pretty good... What about forward secrecy? OK as long as either Ka or Kb is not long-lived (e.g., Kws possibly OK) Suppose instead that the protocol went like this: A -> B: {A, B, {K}_Kb}_Ka^-1 How would this be insecure? Open to a replay attack--attacker could replay session Okay, how about we add two more steps A -> B: {A, B, {K}_Kb}_Ka^-1 B -> A: {N}_K (some random nonce) A -> B: {H(N)}_K Now simple replay won't work, because B would pick a different key Is this secure now? Maybe for some applications, but worrisome with channel certificates Channel certificates are proved in terms of keys, and now A can set an arbitrary session key, allowing possibly it to recycle old channel certs