[cap-talk] Delegating Responsibility in Digital Systems: Horton's "Who Done It?"

[Jed Donnelley]

At 10:13 PM 5/15/2007, Charles Landau wrote:
>At 7:04 PM -0700 5/15/07, Mark S. Miller wrote:
> >Jed Donnelley, Alan Karp, and I would like your comments on our draft paper
> >
> >          Delegating Responsibility in Digital Systems:
> >                    Horton's "Who Done It?"
> >
> >found at <http://www.erights.org/download/horton/document.pdf>
> >
> >We plan to submit it to USENIX HotSec 07 (Hot Topics in Security)
> >http://www.usenix.org/events/hotsec07/cfp/
> >which has a five page limit. Submission deadline is 6/1/2007.
> >
> >We think this paper is important. Your comments and suggestions will be
> >greatly appreciated. Thanks!
>
>I agree this is important. Good work!

Thanks!  We're excited to get discussion of this topic going.
I think there are some pretty fundamental issues here.

For example, consider this difference between stack walking and
a capability system that David Hopwood noted recently:

" - in a pure capability system, an invoked object *cannot* determine the
    identity of any of its invokers (except indirectly by knowing which
    subjects might possess a reference to it)."

As we see with Horton, this is still strictly true.  The invoked
object C can't determine the "identity" (whatever that means in
this context) of A or B, but it can determine an identity
label.  That is, it can distinguish the responsible party
Alice from Bob.  It could even use this information for
what amounts to identity based access control.  That is,
Alice's access could be revoked while leaving Bob's access
in tact.  This basic property is something that the ACL,
Orange Book, MLS, etc., etc. sorts of people have been
finding lacking in capabilities.  It remains to be seen
how each community reacts to what Horton provides.

>I like that I can flip the pages and see the transitions between the
>three figures.

There are quite a number of "animations" of the protocol that
are more complete than we could include in the paper.  I think
some have already been referenced on cap-talk, but we can dig
those out (possibly with corrections?) if people would find
them helpful.

>In Figure 1, there are two rectangles labeled "Bob". Are these two
>different objects?

No.

>If not, did you make separate boxes just to avoid
>a tangle of arrows? It's a little confusing either way.

Right, though any suggestions are appreciated.  I'd be interested
to see what it looks like with the arrows.  There are some
issues in this area that we discussed, but decided to
get the paper out there for wider comments first.  After a few
people have had a chance to look (thanks for starting the
ball rolling Charlie!) I think we should review all the
issues, including those of the placement in the diagrams.

I'm personally somewhat uncomfortable with the placement of
the <Id> and be<Id> capabilities hovering over the rounded
rectangles - that are a rather loose construct (denoting
elements that generally belong to <Id>).  Note that there
is a protection boundary between, for example, A and P1 and P2
(and thus beAlice).  A does not have access to beAlice.
I'd like to find a way to clarify this protection boundary.
At one point I suggested a dotted semicircle around
A (B and C), though I admit that would be a bit awkward.
I'm interested to hear the thoughts of others in this area.
I believe this protection boundary is critically important
(more on this below).

>makeproxy does not seem to use its first parameter.

Hmmm.  So it appears.  I admit that despite going through
it a few times I'm still pretty weak on the E code.  I think
I should let MarkM (who wrote it) or Alan (who might understand
it better) take those topics relating to the E code, including
also:

>What if B happens to have a getGuts method and A says b.getGuts()? It
>appears that P1 won't forward that. I can see how to fix this, but
>your simplified code doesn't do it.

and:

>It isn't clear what the purpose of the "t" in p3Desc is.
>
>I'm hoping the answer to most of these questions is that you had to
>oversimplify to cram this into five pages, and these questions are
>answered in the Java code, which I haven't read.

Not intentionally.  I believe it's supposed to be working code,
but it did undergo some revisions.    Hmmm.  I just looked back
at the earlier versions and "t" is included in those as well.
Sigh.  I hope to get some time to understand the E code better.
I'd like to put some initialization and test code around it
so I can see it work, though I don't know if that will be
possible before we submit the paper - unless we switch focus
to another call for papers (might be worthwhile just to get
some relief from the page limit and a bit more time for
discussion).

>There's a fair amount of calling between the mutually suspicious
>Alice, Bob, and Carol. As previously discussed (around
>http://www.eros-os.org/pipermail/cap-talk/2006-December/006278.html),
>there's no guarantee that these calls will return soon, if ever. For
>example, Carol has the ability to delay forever the message from A to
>B. In the absence of Horton, Carol is limited to delaying anyone who
>*invokes* C, but not anyone who merely *passes* C around. I doubt
>there's any way around this without something mutually trusted. In
>some concurrency models (KeyKOS/EROS/CapROS), the lack of a guarantee
>of a return will be a problem.

There is a point in here that interests me with regard to what one
might call an "identity infrastructure" (including Horton).  One can
imagine an 'enterprise' where there is a shared identity infrastructure.
In a system (or organization) with such an infrastructure it would be
natural to trust the infrastructure for what it does - provide for
identities and transformations of capability references from one
identities responsibility to another identities responsibility.
This is a topic that we've discussed a good deal but didn't have
space to deal with in the paper.

I believe MarkM rightly argued that the important case to illustrate
is that between mutually suspicious domains (that is domains that
don't even trust each other's identities or transformation [Horton]
mechanisms - though the liveness issue does come up there).

I believe that within an 'enterprise' infrastructure one could
be confident of liveness of the identity infrastructure (e.g. just
as one is confident of the liveness of the communication).  However,
I agree that between mutually suspicious identity infrastructures
there is a concern about liveness of a simple communication of
a capability - though even there I'm not sure this issue is
any more or less a concern than being concerned about the
communication itself.

Even with the mutually suspicious structure diagramed, however,
it isn't Carol (for example as C) that can delay the message from
A to B, but rather only the Horton protocol mechanism acting with
Carol's identity (beCarol).  I think this distinction is particularly
important in light of the 'enterprise' discussion above.  The
Horton mechanism only needs to do the Carol sealing and unsealing.
I still think of it like encrypting and signing within a PKI
where there is no issue of liveness trust, just time to execute
an algorithm.

>At line 03, P1 calls an arbitrary capability passed by A. It might be
>wise for P1 to use a primitive such as MyCap? to ensure it is talking
>to another proxy.

This again touches on issues of trust within an identity infrastructure.

>Nits:
>
>"messages in flight" - cute, but "messages in transit" is more accurate.

Sounds reasonable to me.

>"reflection", "reflective" - a term I'm not familiar with; did I
>sleep through language class?

I haven't yet gotten my question answered about that one.  I think
MarkM referred me to his thesis and I haven't had a chance to check
it out yet.  Hmmm.  I just looked and didn't find a single instance
of "reflect" in his thesis.  I guess we'll have to wait for him or
perhaps Alan or others to comment.

>"P1's access to S3 would enable Alice to fool Carol into blaming Bob
>for messages Alice sends to S3" - clear enough; the phrase evidences
>MarkM's precise style.

I agree.  I got a few style elements in there also, but most are
MarkM's.  One that I've expressed concern about is the business
of 'thinking', e.g.:

A in step (1), executes b.foo(c),
"thinking" it is sending the message "foo" to receiver
B with a reference to object C as an argument.

I know what is meant and I've gradually become more comfortable
with that construct, but I don't see why A can't know exactly
what is going on (could in any case) and still chooses to
execute b.foo(c) knowing that b is actually the identity
tracking proxy P1 and c is the identity tracking proxy P2.

In this case A "knows" that it is communicating a transformed
'c' to B that has it's responsible Id transformed from
Alice to Bob.  In some cases it's important for A (Alice)
to know this.  Alice (with A acting on her behalf) may not
wish to transfer a raw 'c' capability to B, but will only
trust B (acting for Bob one assumes) with a capability
whose responsibility has been transferred to Bob.

I'll have more to say about this topic and I hope to hear
more.  I think this is an important area.

>References: Is it customary to not give URLs for papers that are
>available online? I'm far from any library; if it isn't online, I
>don't read it.

I don't know what is customary any more in this area, but generally
a quick Google will find whatever is on-line.

>skyhunter.com/marcs/SecurityPictureBook.ppt - would you please make
>this available in a non-proprietary format?

A question for MarcS I guess.

Thanks for the comments Charlie!  I hope we're able to get these
and others resolved before publication.

Just a note about timing - MarkM indicated that he will be traveling
to the East coast until I believe Monday - though with some email
access.  I'm not sure what Alan's time constraints are, but except
for my 9-5 sorts of conflicts I should be pretty available to
work issues with this paper - though as noted above I'll try to
leave the areas of MarkM's expertise to him.

We've put a lot of work into this paper, even as it stands,
and we naturally hope for a lively discussion of what we believe
to be an important topic - r.e. capabilities and "identities".

--Jed  http://www.webstart.com/jed-signature.html