[E-Lang] Possession as Metaphor (was: Pet Extensions and such (was: what is good about E?))

[Karp, Alan]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Friday, July 27, 2001 3:00 AM
> To: Ken Kahn
> Cc: Karp, Alan; e-lang@eros-os.org; Miriam Walker; Ka-Ping Yee
> Subject: Re: [E-Lang] Possession as Metaphor (was: Pet Extensions and
> such (was: what is good about E?))
> 
> 
>			(snip)
> 
> What's the difference between capabilities and keys?  Keys separate 
> designation and authority.  Houses and cars that you can't 
> enter are still 
> part of your world.  In a key system, when you want to enter 
> a house, you 
> have to make two choices: "Of all the houses I might want to 
> enter, which 
> one do I wish to enter now (and where is it)?" and "Of these 
> various keys I 
> have, which one should I use to enter the house?"  The user 
> logically should 
> only need to make one choice.  In your key ring system, and 
> SPKI's ambient 
> authority, you select the house you want, and if you possess 
> the needed 
> authority, it will automatically be found and provided.

At least as applied in e-speak 3.0, you must decide which SPKI certificates
to include in your SLS session.  Once you've done that, the proper authority
is provided automatically.  You may choose to withhold certificates from the
session, allowing you to conform to POLA.  Thus, if your session includes
only the mailbox key, your front door can't be opened.

> 
> In a capability system, to a potential user of the house, the 
> key *is* the 
> house.  You interact with the house by interacting with the 
> key, or with 
> objects derived from interacting with the key.  There are not 
> two things 
> being brought together.  Whereas in a physical key system there are: 
> designation (which house) and authority (keys).

As done with split capabilities in e-speak 2.2.  The benefit you get for
this cost is that one key can open all the doors to your house, hence my
scalability argument.

> 
> So, if both schemes reduce the user's burden to one choice, 
> is there a 
> difference?  Yes, a huge one, and I think it's the basis for 
> Alan's concern 
> about E-Speak2.2's POLA violating key rings.  If the 
> provision of authority 
> is automated, by selection from a large pool, then deputies 
> can be confused 
> into, for example, using their own authority to take actions 
> that they 
> "thought" were being authorized by keys handed to them by 
> their clients.
> 

Clients don't pass keys to deputies.  Clients present keys to the TCB which
uses them to unlock permissions.  These permissions are passed to the
resource handler (deputy), which is responsible for using them to determine
whether or not to honor the request.  Of course, keys are resources, and
name bindings for them can be passed to others; that's how we did
delegation.

The problem with key rings is that people tended to put all their keys on
one key ring.  Having done that, every request carried their full set of
authorities.  So, when reading email, the "execute" key would always be
submitted with any request from the email process, and the virus program
would run.  A better UI might have encouraged people to construct a key ring
for each request that carried exactly the needed authorities.

> 				(snip)  
> 
> Rights amplification is about separating an authority into 
> two parts that 
> must be brought back together in order for the authority to 
> be used.  While 
> the separation isn't designation vs authority, it's still a 
> separation, and 
> has many of the same consequences.  We are now exactly 
> parallel to our 
> original houses, keys, and locks metaphor, and Ken's solution 
> for making it 
> easier exactly describes what KeyKOS did.  

E-speak Beta 2.2 split capabilties do this separation.  However, the two
parts are not brought together at the deputy.  Instead, the designation and
a representation of the authority, rather than the authority itself, are
brought together.  That, I believe, makes a confused deputy attack less
likely to succeed.

>				(snip)
> 
>  From here, I'm not sure how to bring the discussion back to 
> UI design for 
> secure installation.
> 

I think the suggestion that got us started was proximity.  I contend that
this approach has at least one of the problems of ACLs.  The problem with
the proximity mechanism is that any and all of my keys are applied each time
I approach the door.  It may be that I only want to unlock the mailbox, but
the front door will pop open if both keys are on my key ring.


> 
>         Cheers,
>         --MarkM
> 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
> 

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-3
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/