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

[Toby Murray]

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. 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.

>  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.

> Doesn't this suggest that the non-delegatable
> authority approach that you are using is at least dependent on
> the particular sort of object-capability system?
Yes. But under these new relaxed assumptions, we cover the most widely 
used capability systems in existence, namely E and the KeyKOS 
derivatives. (The jury is still out on whether Coyotos meets these 
requirements but preliminarily I think it does but refuse to make a 
strong claim until I get time to look at it more closely.)

>   That is, in
> systems where all authorities are represented by capabilities
> (which I regard as a "good" thing - what's good for one
> authority seems to me good for all) the non-delegatable authority
> mechanism that you describe can't be implemented. 
That was what we originally thought but Kevin and others have convinced 
us otherwise.
<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).
> 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. I believe there may be some value to being able to express and 
enforce non-delegatability in the object-cap model. At a minimum, it 
puts object-cap systems on par with ACL systems in which one can hand 
out a right without handing out the associated "grant" right. Even if 
this has no practical usefulness, as you assert, being able to express 
it increases the utility of the object-cap model because it allows us to 
express ACL-like and Ideneity-based access controls within the 
object-cap model. Having done so, we can then compare their 
effectiveness against capability-based approaches such as Horton, 
membranes etc.

In fact, I'd argue that if you really want to put the nail in the coffin 
of non-delegatability, that hte NDA gives you the perfect vehicle for 
doing so. You can create an experiment in an object-cap system in which 
you use both NDA-like constructs and also traditional capability-based 
constructs for solving different sorts of trust problems (e.g. handing 
out authority to untrusted subjects.) Given some means to quantify the 
effectiveness of both, you've now got the perfect playing field in which 
to decide which actually *is* better than the other. Without being able 
to express NDA in the object-cap model, you've got no guarantee that 
both sides are playing on an even (unbiased) field.
> Of course if we could decide that non-delegatable authority
> is a good that needs to be supported, then we could build
> it into the model (e.g. as they did in DEMOS with the
> "pass once" capability).  
I'm not advocating this. Otherwise I'd have written a paper about the 
need to include some sort of "pass once' mechanism into the object-cap 
model. Instead, I wrote a paper about how to express non-delegatability 
in the traditional object-cap model without having to modify it. These 
are vastly different things.

<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 
partiicular 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.

Non-delegatable authority pervades Defence. There might be better ways 
to solve the trust problems faced by Defence but history shows that 
non-delegatability is the way they've chosen to go. There must be some 
reason for this. Non-Delegatability has certainly proved useful in this 
small slice of the world.

The paper also gives other examples in the real world where 
non-delegatability has been embraced and proven effective. I'm certainly 
not arguing that it is useful in all cases, but I believe that there do 
exist some cases in which it has proven useful. This doesn't preclude 
the possibility that in those same cases some other technique might have 
been more useful, however, but you cannot deny that non-delegatability 
has proven to be 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?

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.

People are drawn to non-delegatable authority in the real world. It does 
prove useful in the real world certainly. Hence, there might be a small 
proportion of cases in which it is useful to apply in the object-cap model.

>   The ability to
> delegate through existing capabilities is a fundamental
> part of the model.  If people's intuitive fears of
> such delegations are justified, then the object capability
> model is repudiated.
>   
Not if there is only a fraction of cases in which these fears are 
justified and if there is a mechanism to be used in these few cases 
without breaking the model -- as the paper shows there is.
> I believe this is a case where what people intuitively
> feel drawn to is misguided. 
How do you argue against the use of non-delegatability that pervades the 
real world (e.g. Defence, accreditation, etc.) then?
>  As I believe you have clearly
> described, there are two aspects to the consideration of
> efforts toward non-delegatable authority:
>
> 1.  The cost.  As far as this goes, I go further than your
> statement: 'I agree that non-delegatability is potentially
> harmful because it breaks the assumptions of programmers
> and makes it difficult to impossible to create the sort of
> "networks of subcontracting" for which the OO paradigm is
> so adept.'  I argue that non-delegatability *is* harmful
> for effective access control and thus security both in
> the area of programming - where, as you say, it breaks
> what I refer to as the decomposability of object oriented
> programming (forcing one to break the model by proxying
> to subcontract) - and in the area of interactions between
> people, e.g. at the level of network communication of
> authority that I feel is so important, but also even
> delegation between people without computers where, if it
> could really be supported, it would block use of administrative
> assistants, cabinet members, effective staff, and the like.
>   
Let's agree that NDA is very likely to be harmful in some cases. I hope 
you'll also agree that experience has shown that is can also be very 
useful in some cases in the real world for solving human-to-human trust 
problems.
> and
>
> 2.  Value.  Here you say "It might be the case that while
> non-delegatability is useful between humans..." seeming to
> assume that it's clear that non-delegatability is clearly
> of value between people.  I dispute this point and feel that
> perhaps this might be a good area to focus some discussion.
>
> I believe that even in human institutions the ability to
> delegate authority is vital for making such institutions
> work.
Absolutely. I'm not arguing against ruling out delegation. In fact the 
conclusion of the paper says that ruling out delegation is harmful for 
security. But I am arguing that there have been numerous cases in which 
preventing delegation has helped security in the real world. (see above)
>   I wonder if there may be a bit of confusion between
> authority (that is the ability to take or allow an action)
> vs. responsibility (e.g. ultimate responsibility - namely
> where the buck stops) for an action?
>
> I'm not sure how we can answer this question.  I know
> I have been on the receiving end of authority delegation
> (e.g. final decisions for salary actions, purchasing
> decisions, etc.).
I'm sure you've also been given authority that you have been told not to 
delegate, at one point or another.
>   While there may have been a formally
> responsible person (with an "authority"?), the actual
> authority was delegated and even the signature mechanism
> was handled by an administrative assistant.  I believe such
> mechanisms work all the way up and down typical authority
> hierarchies in most (all?) human organizations.
>   
I don't dispute that delegation pervades the real world -- probably much 
more so than non-delegatable authority does. But that doesn't preclude 
non-delegatable authority from being useful -- it just means it isn't 
always useful.
> Do others disagree?  I'll be interested to hear of
> structures where others have experienced authorities
> in human organizations which may argue for the
> practical importance of non-delegatability in human
> organizations.
>   
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. 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.
>  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.
> I
> believe such illusions may be most easily harbored
> by those who have never had such "non-delegatable"
> authority actually delegated to them.
>   
I've held non-delegatable authority. I still see value in it.

<snip to the part about value of NDA versus other approaches>
> If you are to argue for the value of delegating
> with a non-delegatable authority from Aaron to
> Alice then it seems to me you need to consider
> the options available to Aaron.  Aaron has at
> least these three options that seem relevant
> to me:
>
> a.  Communicate the authority directly as a
> capability (reference),
>
> b.  Communicate the authority in the non-delegatable
> manner that you describe, but also
>
> c.  Communicate the authority through any sort
> of a policy engine such as a simple revokable
> capability, a more thorough membrane, an
> identity based delegation tracking mechanism
> like Horton, or any other possible policy engine
> (e.g. indirect through a service that can
> accept any sort of a policy module upload).
>
> Since we assume that Aaron doesn't fully trust
> Alice, it seems reasonable to exclude #a.
> Between #b and #c which seems preferable?
>   
This is a good debate to have. However, the paper isn't trying (and 
neither am I) to argue that non-delegatable authority is the best choice 
over alternatives such as #c in all cases; merely that there are cases 
in which it is useful and perhaps the best choice.
> when considering your
> concern about a possible software fault in the
> Alice code that can be exploited by Bob, mightn't
> it be that Aaron could become aware of such an
> exploit without being able to correct the code
> fault in Alice?  In that situation #c would solve
> the problem while #b would not.  It seems that
> #c has more value in this case - at least for
> protection (access control).
>   
Indeed. But this doesn't invalidate the claim that NDA can be useful. It 
merely provides a good example of where it is not.
> 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.
> 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>

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

Cheers

Toby