[cap-talk] the value of non-delegatable authority?

[Jed Donnelley]

At 11:22 PM 1/13/2008, Toby Murray wrote:
>Jed Donnelley wrote:
> > In the paper you describe
> > the Authority by Method Return mechanism that you build on to
> > implement the non-delegatable authority mechanism.  You note
> > that in many object-capability systems the return authority
> > isn't represented as a capability (e.g. E, W7, and the Annex
> > Capability System) and consequently isn't delegatable through
> > normal capability communication,

>This isn't true actually. The version of the paper you're reading is
>flawed, as was pointed out by Kevin Reid on this list. In fact, the
>ability to return from an invocation in E is also represented as a
>capability. In both EROS and E, this "return" capability can only be
>invoked once but it can be delegated.

Ah, delighted to hear that.  Sorry to display my ignorance of
the return mechanism in E.  I hope to get some more time to
learn more about that facility.  Perhaps there's an updated
version of the paper I should read?  Sorry if I missed the
above discussion elsewhere.  Perhaps you could point me
to the relevant message(s) in the archive?

>Kevin has argued convincingly that
>under these weaker assumptions, the non-delegatable authority (NDA)
>implementation presented in the paper is still valid. Say Bob has an NDA
>that allows him to access Carol. The NDA works by invoking Bob and
>asking him what method he wants to invoke on Carol. Suppose now that Bob
>delegates the "return" capability used to send back the reply to this
>invocation to another object, Dennis. Now Dennis gets to decide which
>method will be invoked on Carol but only just this once. In order for
>Dennis to be given this power, Bob has to collude with him. Hence, even
>under the weaker assumption, Bob still needs to actively collaborate
>with Dennis on each invoation by NDA in order to share his authority.
>Hence, the analogy with a proxy still holds.

Hmmm.  That does seem to put a different light on things.  I admit
that I'm a bit confused about the roles for the players in the above
discussion compared to those in the original paper.  Let me check
my understanding by feeding back my thoughts in this next paragraph:

On first thought it seems to me that under the above circumstances
what Bob delegates to Dennis is exactly the *permission* that Bob
has.  Namely, the reply capability only provides Bob only with the
permission to invoke Carol once.  However, it seems that Bob has
greater authority than just that one permission by virtue of being
invoked again after his reply capability has been exercised (to
invoke Carol by NDA).  This greater authority has indeed not been
delegated to Dennis.  Bob only has this authority by virtue
of the NDA service having its capability to Bob and re invoking
that capability to Bob after every return.  As you say, it would
require cooperation by Bob to allow Dennis the authority to
make further invocations of Carol through NDA.

Does the above sound right to you?  I'll have to think a bit
more about what for me seems a new implementation.

> >  while in some object-capability
> > systems the authority to return is represented as with all other
> > authorities as a capability (e.g. EROS and RATS - what about KeyKOS?)
> > and can be delegated.

>The crucial thing about EROS, KeyKOS and E here is that the authority to
>return is created afresh for each invocation and is implemented as a
>"use once" capability. Therefore, Bob can't pass on the authority to
>reply to /all/ invocations on him by NDA to anyone else, other than by
>delegating the "return" capability each time he is invoked. In doing so,
>he is acting analogously to a proxy, as argued above. Hence, the
>non-delegatability constraint still holds.

I believe I understand.  I think I was confusing the roles
of Alice and Bob from the paper.

><snip>
> > To state my position most strongly, I see the non-delegatable
> > authority mechanism that you describe as a "hack" on an
> > obscure and unfortunate inadequacy in some object-capability
> > implementations.

>Does this comment still apply under the new conditions? (delegatable,
>"use once" return capabilities created afresh for each invocation).

No, it doesn't.  It seems to me that if the NDA mechanism
can work with a 'use once' but delegatable return capability,
then it is built on what I regard as a reasonable facility
that should be present in any object capability system in
some form.  As I suggest, I'll have to think a bit more
about this aspect of the NDA mechanism.

> > I'd be interested to hear your or others
> > present arguments that representing the return authority as
> > a communicable capability is a bad idea for the general
> > object-capability model - and thus that building the
> > non-delegatable authority mechanism as you have is more
> > of an appropriate "rule" for object-capability systems
> > rather than an unfortunate "exception" as I see it.
>
>I'm unwilling to present such an argument because I don't believe it
>myself.

Then to that point we agree.  Now to what I regard as the
"main event":

<snip - more along the above lines that I will have to take some time 
to think about>

><snip>
> > I believe such arguments [in favour of non-delegatable authority] 
> feed into what I refer to as the
> > "loose capabilities" fear.  I also agree that "people seem
> > inherently drawn to the idea of non-delegatability
> > of permissions" as you note later.  In fact what such
> > people hope to achieve (I hope we will agree) is non-delegatable
> > authority - which is the stronger claim in your paper
> >
> > I believe that if this fear of delegation through
> > capability enabled communication channels is accepted
> > as justified then we may as well pack up the object
> > capability model and go home.

>Why? Couldn't it be the case that in 99% of cases you *don't* want
>non-delegatable authority. But there is 1% of cases in which you do?
>Being able to express NDA in the basic object-cap model allows you to
>use it in the 1% of cases when it is necessary and ignore it in the 99%
>of cases when it is not.
>
>In the real world, there is a small fraction of "tough" security
>situations in which non-delegatable authority has been embraced; namely
>within the defence community.
>
>A person who is cleared to read classified documents certainly doesn't
>have the right to pass on their clearance to anyone else. Further, they
>certainly don't have the automatic right to pass on the right to read a
>particular classified document to anyone else -- particularly if that
>other person holds no security clearance. There is very good reason for
>this as I'm sure you'll agree, coming from a government background.

Hmmm.  In the above I believe we are getting into some fine points
with regards to definitions.  You have switched to using the term
"right" above as opposed to the term "authority" - for good reason
I think.  I believe this term "right" is more closely aligned with
the term 'responsibility' that I mentioned in my previous message.

One way I might express the above is to say that a person with
a clearance does have the authority to delegate the permission
to read any documents that they can themselves read to anybody
with whom they can communicate - however, they have a
responsibility (duty) not to do so.  That is, they are trusted
not to do so.

Does the above phrasing make sense to you?  If not, what if
I substituted the word "power" for "authority" in the above?

><snip>
>... you cannot deny that non-delegatability
>has proven to be a useful tool in the real world for tough
>security/trust problems.

Deny might be too strong a term, but I am defending that position
(i.e. denying that non-delegatable authority has been a useful tool
in the real world for tough security/trust problems).

>Any situation involving accrediation of some kind, where an accredited
>individual doesn't automaticaly have the right to accredit others would
>appear to be an instance of non-delegatable authority in action. Are you
>arguing that in all of these cases, there was a better solution?

What I'm arguing is that the distinction is between the delegatability
of authority (which I'm arguing is available in all practical real world
situations) and the delegatability of responsibility (trust?), which is
not permitted in many real world situations.

>I remember reading about a mechanism to reduce the risk of
>identity-fraud whereby credit card charges (or something similar, can't
>remember) would have to authorised by having a bank (or similar entity)
>phone you up on a registered number to authenticate each charge. This is
>almost an exact real-world embodiment of the NDA as explained in the paper.

If I chose to delegate the use of a credit card of mine that used a
mechanism like the above, I could arrange to give the card to my
delegate and give that person permission to answer my telephone.
I have the power ("authority") to delegate its use.  I believe that
in such a case I even have the "right" to do so, though I consider
use of that term a bit less well defined.

In any real practical situation the bank would provide me with
a mechanism to authorize another card on my account - even if they
tried to then assure that it was really my delegate that actually
used the delegated card by such an extreme means as above.  For me
this demonstrates that the delegatability of the authority is
actually provided even in this 'real world' situation.

>People are drawn to non-delegatable authority in the real world. It does
>prove useful in the real world certainly.

I'm not yet convinced.  At least I feel that any such real world uses
are much more restricted than you've argued for so far.  I believe
there is a confusion between responsibility (trust and perhaps policy)
and "authority" - which for me is closer to power.  That is, if
the available mechanisms allow me to take an action myself or to
enable an action by another then I say I am "authorized" to
take or delegate that action.  I may be trusted not to delegate
it, I may be considered responsible for any such delegated
action if I so delegate, but I am *authorized* to do so.  I'm
working with the terminology here.  I hope you'll bear with
me so we can get through these terminology issues and can work
out the practical considerations.

>Hence, there might be a small
>proportion of cases in which it is useful to apply in the object-cap model.

I hope not, but then I hope we will come to agree on just where
any such value might lie.

><snip - stuff that seems to me to repeat the above discussion>

> > Defence is the killer example here as far as I see it.
> > I believe that in human institutions just, as in
> > computing systems, the point that David Wagner most
> > recently stated, "Don't prohibit what you can't
> > prevent" applies up and down the line.

>No it doesn't. A security cleared individual is trusted not to perform
>certain actions that they can't be prevented from performing -- e.g.
>leaking secrets.

I think that is my point.  They are trusted not to take such
actions even though they are in fact "authorized" (that is
they are able to by mechanism, not by policy) to do so.
They have the "power" to do so.

I think there is a fine point here in terminology that I hope
we can work out.  I'm not yet sure how relevant it is to
the practical considerations.

>The slogan ought not be
>"don't prohibit what you can't prevent" but
>"don't prohibit (Alice from performing) what you can't prevent unless
>you trust Alice not to perform these things". This is the way things
>work in practice.

However, even in the defense situation, the ultimate protection
is based on the trust, not on an effective prohibition, which
it seems to me we agree is trying to prohibit something that
in fact can't be prevented.  Communicating conspirators can
share the classified information in any case.  I would say
that they are "authorized" to do so, but are trusted not
to do so.  In any case they aren't prevented from doing so.

> >  Any imagination
> > of value for non-delegatability is illusory IMHO.

>You'll have to argue against my Defence et al. examples above in order
>to convince me of this point.

As I have above.  Perhaps we should take up the discussion
above and leave the rest for now.

However, I don't want to exclude this lesser point from
future discussion:

<snip>
> > One situation where I can see some value in
> > the non-delegatable authority mechanism that I
> > can't see how to improve on is the case where
> > there is a program fault in Alice (as you
> > suggest) that can be corrected.  In that case
> > either #b or #c can protect from invalid
> > use of the authority when the fault is discovered,
> > but it seems to me that #b provides a less
> > costly correction.  Namely with #b correcting
> > the code (which must be done in any case) by
> > itself suffices.  With #c the authority must
> > be revoked through the indirection and then
> > it must be reissued somehow to Alice and
> > potentially wherever Alice delegated it.

>Hence, we have a case in which NDA is at least as useful as other
>approaches. Hence, there is a possibility that it does, in fact, have value.

I don't see another way to get the value that the NDA
mechanism can provide as above.  However, I'll note that
the value is not in protection (where the revokable,
membraned capability does at least as well), but in
reducing the cost of recovering from a revoked authority.
This value provides no support for the intuitive "loose
capabilities" concern.  The authority is just as safe
through the membrane approaches, its just that it may
be more costly to restore full functionality after
revoking some authority.

> > Generally I believe that your paper underrates the
> > cost of non-delegatability and overrates the value.

> > Possibly. But I'm not sure we have the evidence to argue that properly yet.
> > If these merits are accepted then I believe the
> > object capability model is in serious trouble.

>I disagree as stated above.
>
><snip the rest -- need to finish this message, sorry>

I appreciate that problem as I'm also struggling with time issues.

>This has turned into a great discussion  Jed. I hope we can continue it
>further.

I certainly want to clear these issues up in my mind,
so I'll continue the discussion as time permits and
hope for help from you and others Toby.  Thanks for
your message.

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