Authentication in Dist Systems Presented in cs294-4 P2P Systems by Sailesh Krishnamurthy Oct

Access Control Authentication Model elements: Objects, resources (files,processes etc) Requests to perform operations on objects Principals - request sources, use Channels Guardian - request validator Easy in centralized systems OS implements all channels, “knows” all principals Hard in distributed systems Long path from request originator Different kinds of channels Parts can break, get inaccessible

Paper contributions Authentication theory for distributed systems (why theory ?) Assumptions about authority and trust Formally represent these assumptions Carefully examine the assumptions Describes a practical system based on the theory Uses the theory to explain several mechanisms

Concepts Principals Simple People: Lampson, Abadi Machines: coeus, mammoth Roles: manager, secretary Named sets of principals: Services, Groups Channels (principals that “say” things) Wires, IO ports, N/W addr, encryption keys Compound principals Roles: Abadi as manager Delegations: Mike for Burrows Conjunctions: Lampson ^ Wobber

Statements Statements - made by principals Simple: request for file foobar.tex Compound: Bob as secretary requests file bar.tex Trusted Computing Base - keep it small

Statements Primitive statements (e.g. “read file foo”) s^s’ (s and s’) s  s’ (s implies s’) s  s’ (s is equivalent to s’) If ‘A’ is a principal and ‘s’ is a statement, A says s is a statement If ‘A’ and ‘B’ are principals A  B (A speaks for B) is a statement A | B ( A quotes B) is a statement

More on statements Needham-Schroeder auth ticket {K ab,A}K s can be written:K bs says K ab  A If ‘s’ is an axiom it is represented as  s. Some axioms:  (A says s ^ A says (s  s’))  A says s’ If  s then  A says s for every principal A  A says (s ^ s’)  (A says s) ^ (A says s’)

Principals Let ‘A’ and ‘B’ be principals, ‘C’ be a channel. (A^B) says s  (A says s) ^ (B says s) (A|B) says s  (A says B says s) What if A lied - B did not say s ? (A  B)  ((A says s)  (B says s))

Tools: handoffs, joint authorities  (A says (B  A))  (B  A) If you see A says s, simply conclude ‘s’ if it is of the form B  A. Simply states that A allows B to speak for itself. Third Parties!  ((A’  A) ^ A’ says (B  A))  (B  A) Joint Authorities  ((A’^B  B) ^ (B  A’))  (B  A)

Joint authorities Useful for certificate revocation Refreshing requires source availability Hard to make a source that is both: Secure Highly available Solution: use 2 sources One is highly secure with a long lifetime Other is highly available, uses a short lifetime However, both must agree to validate certificate

Channels and Encryption Encryption channel: Dec(K,Enc(K -1,x)) = x for a message x Encryption enforces: Security: If you know Enc(K -1,x) but not K, then should not be able to compute x Integrity: If you know x but not K -1 should not compute a y such that Dec(K,y) = x 2 forms: public keys, shared keys Public keys can be simulated with stateless symmetric key

Named principals Pull vs Push to get credentials Pull: receiver looks up named principal to get credential Push: sender provides credentials CA: external certificate authority Paths: able to trace “up” and “down” an authority tree Groups:Members “speak for” groups Certificates: P1 => G, P2 => G etc. Or, for each member Pi, store Enc(K p,K g -1 ) in G’s database

Roles and Programs Can be run with different priorities Use digests (MD5) of prog text to confirm identity Similar to booting a machine Different OS’s on a given machine

Other stuff Delegation Login (session keys) Authenticating IPC Use authenticating agents Access Control Standard ACL plus theory

Relevance to P2P systems ? How can peers authenticate themselves to each other ? RIAA trace lookups for file sharing systems ? Authenticate steps in multiple-hop DHTs (like Chord/Viceroy) in a manner similar to the paths ?