Namespaces in SPKI

1. Namespaces in SPKI Carl M. Ellison Intel Architecture Labs carl.m.ellison@intel.com

2. Diffie, Hellman and Kohnfelder • D-H: key management problem is solved. Instead of a courier, if you want to send me a message for my eyes only, look me up in the modified phone book and find my key. • Kohnfelder: the central phone book is a bottleneck. Sign the (name,key) entries, call them certificates and let them wander the net.

3. Early Assumptions • You know the people with whom you deal. • Names function as identifiers. • Therefore, if you learn the name of a keyholder you can make security decisions. • System security depends on the security and practices of the <name,key> CA.

4. New Realizations • In the Global Village, names retain their social role but are not good identifiers. • Even if there were a name that functioned as an identifier (e.g., a domain name), you probably don’t know the identified person. • E.g., do you grant access to classified information to anyone who has a valid passport? …from Iraq?

5. Most Basic Flaw • A telephone book does not claim to tell you whether a person should have access to classified information. • It does not even tell you which Bob Smith is your old friend Bobby from summer camp. • It gives clues but lets you do trial and error. • Access control needs more than weak clues.

6. Certificate Classes (1) Name ACL / Attribute Certificate [ID] Certificate Permission Key

7. Authorization (1) Distinguished Name [DN] = ACL / Attribute Certificate [ID] Certificate Key Permission Access Control Security Perimeter

8. The Third Attack • DN = common name + other information to make it globally unique. • The DN’s common name field is defended as an aid to human users. • This leads to the potential flaw that a human will look at the common name and assume he knows the person. That flaw can be exploited to create an attack.

9. Example (1/3) Date: Mon, 24 Aug 1998 15:48:15 -0400 From: geer@world.std.com (Dan Geer) To: wford@verisign.com, kent@bbn.com, cme@acm.org, perry@piermont.com Subject: discussion next week Cc: blakley@vnet.ibm.com, geer@world.std.com

10. Example (2/3) Gentlemen, I've decided to ask Bob Blakley to moderate rather than do it myself. He'll be in touch and if you've already got a lot of format and/or questions worked out, please bring him up to speed. See you next week. --dan

11. Example (3/3) So, I saw Bob Blakley outside a conference session on 8/26/98 and I approached him, saying that we needed to talk about the panel session the next week. He responded, “What panel session?” I was speaking to the father, not the son. Worse, the father is Bob Junior.

12. Certificate Classes (2) Name ACL / Attribute Certificate [ID] Certificate Permission ACL / Authorization Certificate Key

13. Authorization (2) Name Lawyer’s Security ID Permission ACL / Authorization Certificate Key Access Control Security Perimeter

14. ID Certificates X.509 PGP SDSI/SPKI Attribute Forms X9 attribute cert SPKI attribute cert ACL by name Authorization Forms SPKI authorization cert X.509 SSL X.509v3 extension X.509 SET PGPticket ACL by key ~/.ssh/authorized_keys AADS / X9.59 SSL root key list Credential Formats

15. Global keyholder ID Local human-friendly name Local (to the verifier) permission tag Three Namespaces

16. 1: Key as Global ID • The keyholder is the entity holding the private key, by definition. • A public key is mathematically associated with a single private key. • A public key is a byte string  an ID. • A collision-free hash of the public key is also a byte string  an ID of the keyholder.

17. Lack of Public Key Anonymity • Because a key is a global ID for the keyholder, use of the public key when the key is transmitted in the clear by the protocol, gives the attacker the equivalent of an ID codebook puzzle to solve. • The televangelist problem… • Need multiple keys, one per function or function class

18. 2: Local Names • People use names. We think with them. • The names we use are local to our own heads and can be good identifiers when limited to our own small communities. • SDSI defines local names and rules for linking name spaces, with a resulting increase in security.

19. Fully-qualified Names (1) • To be used away from its locality, a name must be globally unique. Let us call this a fully-qualified name. • A name local to one keyholder, paired with the public key of that keyholder, is a global ID, mapping to a key: (name <key> fred) = k1 (name <key> n1 n2 … nN) = kN

20. Fully-qualified Names (2) • SDSI name chain reduction, recursively: (name <k0> n1 n2 … nN) & (name <k0> n1) = k1  (name <k1> n2 … nN) • Identical to the process with X.509 • If there were one naming root, then the root key could be just assumed and not stated. • There will never be one root, so all attribute certs need FQNs, probably as shown above.

21. 3: Tag Namespaces • Permissions need to be named to be verified • The verifier is in charge of that naming -- and verification is local to it. • Anyone delegating that permission must also be aware of it, unless delegation is by group.

22. Authorization Flow Certificates N ACL K3 do X? A B Y Verifier’s Machine Verifier’s Machine ACL: I say ( K1 may delegate or do { X, Y, Z } ) A: K1 says ( K2 may delegate or do { X, Y } ) B: K2 says ( K3 may do { W, X } )  I say (K3 may do {X}), by logical reduction

23. A tag is visible only along a verification path. The verifier defines it and can get agreement from its delegates as to the meaning, syntax and use of the tag. Since entities are free to have as many keys as desired, a delegate can create a key for a specific tag delegation. Tag Uniqueness