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

Namespaces in SPKI

Carl M. Ellison

Intel Architecture Labs

[email protected]

19 August 1999

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 <name,key> 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

KeyPermission

[ID] Certificate

ACL /Attribute

Certificate

19 August 1999

Authorization (1)

Distinguished Name [DN]

KeyPermission

[ID] Certificate

ACL /Attribute

Certificate

Access Control Security Perimeter

=

19 August 1999

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] (Dan Geer)

To: [email protected], [email protected], [email protected], [email protected]

Subject: discussion next week

Cc: [email protected], [email protected]

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

KeyPermission

[ID] Certificate

ACL /Attribute

Certificate

ACL /Authorization

Certificate

19 August 1999

Authorization (2)

Name

KeyPermission

ID

ACL / AuthorizationCertificate

Access Control Security Perimeter

Lawyer’s Security

19 August 1999

Credential Formats

• 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

19 August 1999

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 <key> fred) = k1

(name <key> n1 n2 … nN) = kN

19 August 1999

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.

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

ACL K3 do X?

Y

N

Verifier’s Machine Verifier’s Machine

A B

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

Certificates

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.