Theory of authentication - A formal model of beliefs of agents in a distributed system - A powerful and rigorous way to express authorization & policy Channels - Source of all messages - e.g.: I/O ports, keyboard, mouse, and so on (physically secure links) - IPC, with a trusted reference monitor to establish secure channel through memory protection etc. - Often a "secure channel", e.g., a series of encrypted/MACed messages - Q: How did paper suggest to implement? What do you think? A: Suggested to append a digest and encrypt. WRONG!!! Crypto: - [X]_{K_A^{-1}} means you can conclude K_A says X - Channels often named with keys - Note that this provides a broadcast channel, too, if you use public keys Names - either a Channel or a Principal Says - A says X means "A believes X" or "A would agree with / endorse X" or "A would (have good reason to) believe X". Doesn't require that A actually transmitted X at any point in time; just that A would be willing to do so. - Rationality rules: X => A says X; (X => Y) => ((A says X) => (A says Y)) - Some obvious cases - ((A says X) and (A says Y)) => (A says (X and Y)) [and-introduction] - (A says (X and Y)) => ((A says X) and (A says Y)) [and-elimination] - etc. (e.g., or-intro, or-elim, ...) - Special cases: A says read(f) is shorthand for A says It would be good to read(f). - Quoting: A says B says X doesn't mean B said X; A could be lying. - Short-hand: A says B says X <=> A|B says X Example - "Do what your Mommy says" becomes (Mom says X) => X - "Mommy tells you: do your homework" becomes Mom says "Do your HW" Note: Can conclude "do your HW" - "Mommy tells you: do what your Daddy says" becomes Mom says ((Dad says X) => X) - "Daddy tells you: do your homework" becomes Dad says "do your HW" Note: can conclude "do your HW" Speaks for - A speaks for B <=> B says ((A says x) => x) - This is a generalization of the above (e.g., Dad speaks for Mom) - Handoff rule: B says A speaks for B => A speaks for B - Exercise: Given "B says A speaks for B" and "A says Y", derive "B says Y" - One possible derivation: B says A speaks for B [by assumption] A speaks for B [handoff rule] B says ((A says X) => X) [defn of speaks for] A says Y [by assumption] B says A says Y [rationality rule] B says ((A says Y) and ((A says X) => X)) [and-introduction] B says ((A says Y) and Y) [rationality rule] B says Y [and-elimination] Delegation - B has access to some resource R - B wants to give A access to the resource R - e.g., scenario with a printer - A speaks for B allows a special kind of delegation, where the delegation is unlimited - Compare: A speaks for B; A|B speaks for B. - Q: Why the difference? Which is preferred? - Latter ensures that A doesn't mistakenly say things that would be taken as speaking for B. Intended to avoid confused deputy! - Perhaps even better is to pick a fresh name D_B, then: B says A|D_B speaks for B A uses A|D_B whenever he wants to use the delegated privileges More on delegation - Teacher scenario - Unlimited: Mom says ((Teacher says "do your HW") => "do your HW") - Limited: Mom says \forall X . ((Teacher says "do your HW by X") => "do your HW by X") - But of course we all know teachers can't be trusted! They like to give out too much homework. So maybe we want a threshold scheme, where we only trust the teacher if more than one teacher agrees that you should do your HW. Mom says \forall i,j . ((T_i says "do your HW" and T_j says "do your HW") => "do your HW") ACL's - Give example of an ACL. - Q for class: Find equivalent specification in this logic. Capabilities - Do same as above. Certificates - Do same as above. - Example of modelling Netscape (a few trusted CA's; they sign certs for all domain names) Hierarchical schemes - PKI's - Filesystems Isn't this cool? Protocol construction - Given a protocol, model it as statements in logic above - e.g., S->B: {[K,A]_{K_S^-1}}_{K_B} becomes "S says K is fresh and K speaks for A" Q: Is this sufficient? A: No. Q: What's missing that's needed to make this work? A: Need concepts for secrecy, freshness, "good for communication between", temporal properties (limited validity), etc. BAN logic and other follow-on logics can be thought of as an extension to the basic "says" calculus that provides this (even though this is not historically correct). In other words, the "says" calculus is just one in a set of many security logics; I showed it to you only because it is small, easy to understand, and nevertheless very powerful. This is an open research topic that has seen considerable activity. Idea: Make the "says" statements first-class. - Rather than taking a protocol and modelling it as "says" statements, how about the reverse? - Start with a set of "says" statements, and the protocol just gives you a hint at what sort of things you should send (but of course you won't send something unless you believe in it -- protocol is just a template so you don't need to send _everything_ you believe in, but rahter just the relevant stuff). - Messages from the protocol can now be separated and re-used with other protocols. A "protocol" is just an informal recipe for one way to interact to prove to each other the validity of some statements; receiver can derive all logical consequences of these statements in an automated way using the calculus described in the paper. - Can now provide either _static_ proof of validity or _dynamic_ proof. Idea: Shift the burden to the sender (just like in PCC) - Rather than having receiver re-derive logical consequences, why not have sender provide a list of claimed consequences, along with their proofs? - Q: Remind you of anything? A: The analog of PCC. Thus, this idea is called proof-carrying authentication; this is a very recent research topic. - Q: Why should sender have to provide the proof? A: He's in the best position to know why the derived consequence ought to be true. Furthermore, it's natural to place burden on entity requesting access why they should be granted access. - Q: Advantages? A: An "assembly language" for authorization in distributed systems; can build other policies on top of it. (Kerberos-like policy; X509-certificates-like policy; and others.) Provides a powerful way for extensibility -- clients can introduce new paradigms for proving authorization (posibly with delgation, etc.), without needing to modify servers. Think of being able to deploy Kerberos without having to deploy it: neat! Extra stuff (SKIP THIS) Running programs - If U invokes P, we assign principal U|P to P - If P does op X, this means U|P says X, i.e., U says P says X - If we want to allow our program to do anything & everything, delegate: U says U|P speaks for U - If we want to give it only limited rights, use limited delegation: U says \forall f . ((U|P says "read(f)") => (U says "read(f)"))