TP2

Views:
 
Category: Entertainment
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

The Truth Behind PKI and Friends: 

The Truth Behind PKI and Friends Radia Perlman Distinguished Engineer, Sun Labs

Strategies for PKI Hierarchies: 

Strategies for PKI Hierarchies Monopoly Oligarchy Anarchy Bottom-up

Monopoly: 

Monopoly Choose one universally trusted organization Embed their public key in everything Give them universal monopoly to issue certificates Make everyone get certificates from them Simple to understand and implement

What’s wrong with this model?: 

What’s wrong with this model? Monopoly pricing Getting certificate from remote organization will be insecure or expensive (or both) That key can never be changed Security of the world depends on honesty and competence of that one organization, forever

Oligarchy of CAs: 

Oligarchy of CAs Come configured with 80 or so trusted CA public keys (in form of “self-signed” certificates!) Usually, can add or delete from that set Eliminates monopoly pricing

What’s wrong with oligarchy?: 

What’s wrong with oligarchy? Less secure! security depends on ALL configured keys naïve users can be tricked into using platform with bogus keys, or adding bogus ones (easier to do this than install malicious software) impractical for anyone to check trust anchors Although not monopoly, still favor certain organizations. Why should these be trusted?

Anarchy: 

Anarchy Anyone signs certificate for anyone else Like configured+delegated, but user consciously configures starting keys Problems won’t scale (too many certs, computationally too difficult to find path) no practical way to tell if path should be trusted too much work and too many decisions for user

Important idea: 

Important idea CA trust shouldn’t be binary: “is this CA trusted?” Instead, a CA should only be trusted for certain certificates Name-based seems to make sense (and I haven’t seen anything else that does)

Top Down with Name-based policies: 

Top Down with Name-based policies Assumes hierarchical names Each CA only trusted for the part of the namespace rooted at its name Easy to find appropriate chain This is a sensible policy that users don’t have to think about But: Still monopoly at top, since everyone needs to be configured with that key

Bottom-Up Model: 

Bottom-Up Model Each arc in name tree has parent certificate (up) and child certificate (down) Name space has CA for each node Cross Links to connect Intranets, or to increase security Start with your public key, navigate up, cross, and down

Intranet: 

Intranet abc.com nj.abc.com ma.abc.com alice@nj.abc.com bob@nj.abc.com carol@ma.abc.com

Extranets: Crosslinks: 

Extranets: Crosslinks abc.com xyz.com

Extranets: Adding Roots: 

Extranets: Adding Roots abc.com xyz.com root

Cross-link for added security: 

Cross-link for added security abc.com xyz.com root

Advantages of Bottom-Up: 

Advantages of Bottom-Up For intranet, no need for outside organization Security within your organization is controlled by your organization No single compromised key requires massive reconfiguration Easy configuration: public key you start with is your own

Now some buzzwords: 

Now some buzzwords

Now some buzzwords: 

Now some buzzwords Roles, Groups, Identities, RBAC

Definitions I'd like: 

Definitions I'd like An identity...preferably a single thing, but a person can have multiple identities (holder of credit card, employee) Group...not a single thing “Radia's group”, but rather millions of groups “over-18, Sun employee, Radia's friends” Role...kind of like a group, but...

Roles vs Groups: 

Roles vs Groups Groups---you always have all privileges associated with all the groups you are in Roles---they might be mutually exclusive, and you might have to separately authenticate

Roles vs Identities: 

Roles vs Identities If you have to authenticate to be a role, why isn't it an identity? For auditing purposes, you probably want to know which identity is acting in that role

authorStream Live Help