Namespaces in SPKI Carl M Ellison Intel Architecture

Namespaces in SPKI Carl M. Ellison Intel Architecture Labs carl. m. [email protected] com

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. 19 August 1999

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 CA. 19 August 1999

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? 19 August 1999

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. 19 August 1999

Certificate Classes (1) Name ACL / Attribute Certificate Permission 19 August 1999 [ID] Certificate Key

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

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. 19 August 1999

Example (1/3) Date: Mon, 24 Aug 1998 15: 48: 15 -0400 From: [email protected] std. com (Dan Geer) To: [email protected] com, [email protected] com, [email protected] org, [email protected] com Subject: discussion next week Cc: [email protected] ibm. com, [email protected] std. com 19 August 1999

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 19 August 1999

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. 19 August 1999

Certificate Classes (2) Name ACL / Attribute Certificate Permission 19 August 1999 [ID] Certificate ACL / Authorization Certificate Key

Authorization (2) s. S er’ wy La Name ity ur ec ID Permission ACL / Authorization Certificate Key Access Control Security Perimeter 19 August 1999

Credential Formats • ID Certificates – X. 509 – PGP – SDSI/SPKI • Attribute Forms – X 9 attribute cert – SPKI attribute cert – ACL by name 19 August 1999 • Authorization Forms – – – SPKI authorization cert X. 509 SSL X. 509 v 3 extension X. 509 SET PGPticket ACL by key • ~/. ssh/authorized_keys • AADS / X 9. 59 • SSL root key list

Three Namespaces • Global keyholder ID • Local human-friendly name • Local (to the verifier) permission tag 19 August 1999

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. 19 August 1999

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 19 August 1999

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 August 1999

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 fred) = k 1 (name n 1 n 2 … n. N) = k. N 19 August 1999

Fully-qualified Names (2) • SDSI name chain reduction, recursively: (name n 1 n 2 … n. N) & (name n 1) = k 1 (name n 2 … n. N) • 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. 19 August 1999

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. 19 August 1999

Authorization Flow Certificates ACL A B K 3 do X? N Y Verifier’s Machine ACL: I say ( K 1 may delegate or do { X, Y, Z } ) A: K 1 says ( K 2 may delegate or do { X, Y } ) B: K 2 says ( K 3 may do { W, X } ) I say (K 3 may do {X}), by logical reduction 19 August 1999

Tag Uniqueness • 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. 19 August 1999