[cap-talk] Identity tokens (e.g. Kerberos) for responsibility labeling of capability invocations

[Karp, Alan H]

Jed wrote:
> 
> I understand this, but isn't it clear that at that point the program
> has authenticated fully "as Bob".  That is, the program can
> then claim to do anything else that it is able to do as Bob's
> responsibility.  Suppose, for example, the program has also
> received a capability from Dave.  With Horton the capability
> from Dave may be labeled as Dave's responsibility.  In Horton (or
> MarkM's reference implementation of Mailkey as I understand it) it
> is the capability itself that is effectively labeled with the Dave
> responsibility.
> 
The difference here is that a direct transfer of a capability-as-data
from Dave to Bob results in Bob being held responsible for Bob's use of
that capability.  Carol can only know that Dave is responsible for Bob
having the capability is for Carol to keep track of the individual
capabilities she hands out.  It's sort of Horton inside out.
> 
> In the above scenario where "the program" authenticates as
> Bob, then it seems to me that it can invoke the permission
> granted by the capability received from Dave (or indeed any
> received capability) and hold Bob responsible.  In that sense
> once the authentication as Bob happens, the authority to
> act as Bob is "ambient".  As you say it is the channel
> (any communication from the program) that becomes Bob's
> responsibility, not just permissions authorized via
> capabilities labeled as Bob's responsibility.  This seems
> to me (very) contrary to POLA.
> 
I don't see why it's contrary to POLA.  Even though a program running on
Bob's behalf can authenticate as Bob, it can only use those of Bob's
authorities that Bob explicitly granted it.  Bob should be held
responsible for actions taken by his programs, no matter who he got the
capabilities from.  Horton includes tracking of the delegation chain,
allowing Carol to assign responsibility to the delegator.  James
Donald's does not by default, but I believe it can be added.
> 
> Are you imagining that programs will only receive capabilities
> that are the responsibility of at most one identity?  In this
> case the problem is trivial (programs run as 'users') and
> current ambient authority systems suffice.
> 
That wouldn't be very useful.
> 
> I understand the above.  The explicit permissions may
> be limited to POLA, but with this approach the program
> seems to be able to make any identity that it has been
> given the ability to authenticate as (having been
> received as the responsible identity for some received
> capability) responsible for invocations of any other
> capability that it has received.  The capabilities as
> data are POLA, but the identities seem to apply ambiently
> to the whole program (process, active object) and can be
> applied (for the purpose of establishing responsibility)
> at the programs choice to any capability that it has
> received as data.
> 
The main difference from Horton seems to be that responsibility is
transferred by default.  Bob wants to start a program that can't
authenticate as him.  He creates a new identity Bobbie and registers it
with Carol.  Bob starts a program and gives it some of his capabilities
and the ability to authenticate as Bobbie.  Carol assigns responsibility
for the program's actions to Bobbie but needs to remember that Bob is
responsible for the Bobbie account.  As James Donald noted, at the end
of the day it becomes at least as complicated as Horton.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp