[cap-talk] What Horton cannot do? (Was: mailkey: transfer of accountability...)

[Jed Donnelley]

At 04:56 PM 6/2/2007, James A. Donald wrote:
>  > > > What Horton shows is that an effective mechanism
>  > > > to determine who did what can be added to
>  > > > object/capability systems...
>
>Jed Donnelley
>  > Uh - but the problem is solved.  Before it wasn't.
>  > That seems to me a huge contribution.
>
>Solved in the sense that is important to mathematicians.
>I don't think that Horton is a solution that should be
>very interesting to engineers.

Do you mean in the sense that there isn't a significant
market for object/capability system where Horton could
be deployed?  Of course that's true, but that's the
problem that we're trying to redress - by showing the
value add that is available.

However, if you are suggesting that the solution is
for some other reason impractical (with two reference
codings), then I would like to hear what your
concerns are.

>  > Now if you wish to suggest a better engineered
>  > solution to the problem
>
>By selecting a particular case, I had a well defined
>problem.  For that well defined problem, the problem did
>not seem very hard, and the solution (OTR + Rob Meijer's
>mailkey) considerably simpler and lower overhead than
>Horton.
>
>  > - fire away.
>
>I did, in the post titled mailkey: "transfer of
>accountability. Is this broken ?? should I start from
>scratch/horton ?", and again in the June 2nd post titled
>"What Horton cannot do? (Was: mailkey: transfer of
>accountability...)"

I don't think we're making much progress in this
discussion.  I can't see why you don't appreciate
our work on the problem of responsibility tracking
in capability systems.  I appreciate your work
on the spam problem.  Surely you saw the messages
from MarkM and Dean Tribble with the subject
"Mailkey works!.  I wasn't at that meeting but
I appreciate their analysis.  I suggest following
up on their analysis and comments if you want to
pursue the Mailkey solution to the spam problem.

I understand your point about the spam problem
being concrete and your proposed solution being
concrete.  To me this is a bit like I imagine the
situation could be before there locks and keys
had been invented and somebody was trying to
protect something.

I could imagine somebody (e.g. us) arguing that
this new technology, locks and keys, could be
developed and deployed to provide significant
additional security.  However, the engineers of
the day could well argue that problem was too
abstract and complex (interlocking teeth,
tumblers, etc.??) and that they could better
protect a lords fortune with a vault suitable
for posting guards.

For most of the early history the engineers
would have been right.  That doesn't mean that
it isn't worthwhile working on a new general
approach that might pay off in the longer run
to solve a more general problem.

>Repeating from my June 2nd post:
>: :     Let us consider the application of this to
>: :     some real world cases.
>: :
>: :     Let us suppose we manage to get in place an
>: :     email system where all email is authenticated
>: :     by a public key, but...
>: :
>: :     In this situation, what does Horton buy us
>: :     that Rob Meijer's proposal, plus
>: :     authentication does not buy us?

I don't think Horton contributes anything to
that situation.

>But you do not seem to regard concrete and particular
>cases as meaningful

I do.

>- as illustrating general solutions.

You're right, I don't.

>So here is the same solution in general terms.
>
>Assume a system such as Zooko's triangle, where all
>entities have public private key pairs, a but many key
>pairs are unknown, and we do not in general know if the
>possessor of a certain key pair should be exercising a
>capability.   Adversaries have such key pairs as much as
>allies, but allied key pairs are known, while
>adversarial key pairs are likely to be unknown.
>
>All capabilities are shared secrets, that are issued to
>particular identifiable individuals.
>
>A Zooko identity is a smart browser bookmark as in the
>petname tool, or a smart buddy link, as in OTR IM.  A
>capability is an unguessable URL.
>
>In Horton, each capability is issued to one, and only
>one, entity, and should be exercised only by that
>entity.

I'm not sure, but I don't think we have the same view
here.  What do you mean by an "entity"?  With Horton
the view is that permissions as capabilities can
be communicated between "entities".  This ability
to dynamically communicate permissions as
object/capabilities is of course the very essence
of the capability paradigm.

Horton adds a mechanism that allows for a different
type of communication of a permission as a
translated capability that provides additional
responsibility tracking.  That is - as you see
in the paper - it provides for the communication
of the object access c from "entity" A (acting on
behalf of identity Alice) to entity B (acting
on behalf of Bob) with a translation that makes
the new capability that B receives distinct and
labeled as having been delegated with responsibility
tracking from Alice to Bob.

As MarkM mentions in the paper, if A has a capability
to directly communicate to B, A need not use the
Horton responsibility translation mechanism to
communicate the "c" permission to B.  A could
communicate "c" directly to B.  In that case any
action that was taken by B on the "c" capability
would be considered the responsibility of Alice.
We only imagine Horton being used in the relatively
rare (but we argue important) cases where permissions
(capabilities) are being communicated between
relatively high level identities, such as those
associated with people.

It's important that we are not simply identifying
"entities" (e.g. running programs) by some sort
of identity (e.g. as a key pair) and then providing
a means for communicating permissions between
entities.  Doing so would simply be providing for
a capability mechanism at another level.  You can
see such a mechanism in:

http://www.webstart.com/jed/papers/Managing-Domains/#s13

>Alternatively, we can pass around capabilities, but
>since we know who is exercising them this is not too
>bad.   Any entity exercising a capability that we do not
>want widely shared, exercises after first logging on
>using his Zooko key. If a capability issued to Alice
>turns up in the hands of unknown bad people doing bad
>things, then Alice has been bad in sharing her
>capabilities unwisely, and that is Alice's fault.  If a
>capability issued to Alice turns up in the hands of Bob,
>a known person who Alice could reasonably have shared it
>with, but Bob does bad things, then that is Bob's fault.

It sounds in the above as if Alice and Bob are people
and not running programs.  If so then I think there is
an important distinction between levels being missed in
here somewhere, perhaps by me though of course I don't
see it.  The importance of Horton lies in the fact that
the communicating entities are active objects (A, B,
and C) while the responsible parties are "identities"
(as provided by the sealer/unsealer pairs, but that
we use the suggestively anthropomorphic names of
Alice, Bob, and Carol for).

>James A. Donald:
>  >> As a demonstration that capabilities can support
>  >> identities, Horton doubtless works.
>
>Jed Donnelley
>  > To me it isn't "doubtless", but it does indeed seem to
>  > work.  A somewhat surprising result from my
>  > perspective given the "bearer right" aspect of
>  > capabilities.  When a key opens a lock, do you know
>  > "who" was responsible for that opening of the lock by
>  > that key?  Generally not.
>
>"who" contains too many meanings.  Identity is not a
>clear well defined concept with clear well defined
>meanings and definite unambiguous solutions.

In Horton it is.  It is, as you suggest, as simple
as a key pair (in the described Horton implementation
a sealer/unsealer).  The notion of "identity" has
no meaning in Horton beyond that.  Of course a higher
level mechanism may associate meaning with such
identities such as an identification with a person,
as we suggest metaphorically with the names
Alice and Bob and Carol - distinct from A, B,
and C which happen to be running programs acting
on behalf of the identities Alice, Bob, and Carol
respectively (though only in the sense that they
happen to have access to the unsealer for their
respective identities).

I hope the above is adding some clarity.  Sorry if
you feel that I am repeating myself.  I don't believe
I have so far.

>If each
>key is unique, as is typically the case with electronic
>keys used in office security systems, then the owner of
>a key will be disinclined to share it,

Disinclined perhaps, but the owner must necessarily
share the private key (unsealer) with any software
acting with the authority of the owner's identity.

>whereupon knowing
>what key opened the lock is in fact sufficient
>information.

You lost me with the above.  Sufficient for what?
Sufficient to attribute responsibility to an
identity?  How?

>Of course, there is lots of stuff that can
>only be done, or is simplest to do, by passing out keys,
>by delegating capabilities.

Hmmm.  From my viewpoint those two clauses above:

1.  PASSING OUT KEYS (even at that you don't specify
whether they are public keys, private keys, or some
other sort of key such as a metaphoric key in the
sense used in the KeyKOS documentation) and

2.  DELEGATING CAPABILITIES.

are very distinct operations.  If you feel that they
are identical (that is that delegating capabilities
is accomplished by "passing out keys"), then I'm
afraid I'm lost.  Perhaps I'm getting lost in the
terminology here.  I'm sorry for whatever responsibility
I bear for that confusion.

You needn't rewrite the above or refer me to the
same words.  I'm afraid I'll need some sort of
translation.  Perhaps in a face to face meeting
with somebody else who understand what you are
getting at (e.g. the folks at the HP meeting?).

>The problem is not well defined except by reference to a
>real or hypothetical identity system, and real resources
>that need protecting.  The real problem is too amorphous
>for us to casually assume that abstractions of it have
>clear meaning.

The meaning of a sealer/unsealer pair, just as with
a public/private key pair is perfectly well defined.
There is no intent to do any binding to anything else
like a person or any other sort of "identity" beyond
that associated with the technology.  Any such further
binding is a specific application of the technology,
though we do use suggestive names for binding with
people (e.g. through well know means like LDAP
directories and with typical authentication means).

>OTR plus Rob Meijer's mailkey works by requiring two
>keys to access the capability, one of which the owner is
>likely to be disinclined to share, and one of which the
>owner will be inclined to share - so when the door is
>opened, we know "who" opened it - the key that is
>unlikely to be shared - and who allowed him to open it -
>the key that is likely to be shared.  If Alice should
>have allowed Bob to enter the office, the office manager
>presumably knows Bob, and will grill him if something
>bad happens.  If Alice is allowing strangers into the
>office, the office manager will grill Alice.

Perhaps Mark or Dean can make sense of the above
paragraph.  I'm sorry, but I can't.

>James A. Donald:
>  >> As a proposal for an actually useful system, I doubt
>  >> that it works.
>
>Jed Donnelley
>  > I agree that in it's current form(s) Horton is not
>  > part of a useful system solving important problems.
>  >
>  > Still, I've developed capability based systems (e.g.
>  > the NLTSS system that ran production scientific
>  > computing at Lawrence Livermore National Laboratory
>  > for over 10 years:
>  >
>  > http://en.wikipedia.org/wiki/NLTSS
>  >
>  > ) that I believe could have benefited by a mechanism
>  > along the lines of Horton.  It was one of the
>  > implementations that was criticized in this document:
>  >
>  > TRADITIONAL CAPABILITY-BASED SYSTEMS: AN ANALYSIS OF
>  > THEIR ABILITY TO MEET THE TRUSTED COMPUTER SECURITY
>  > EVALUATION CRITERIA
>  > http://www.webstart.com/jed/papers/P-1935/
>  >
>  > - along with all other capability systems.
>
>That criticizes "traditional" capability systems.  But
>all "traditional" systems - including the systems we are
>using right now - are alarmingly insecure.  That does
>not seem to me like a criticism of capability systems
>that urgently needs answering.

I've described how criticisms like the above during the
late 1980s and early 1990s lead to the near extinction
of research into capability based systems.  Indeed into
any sort of dynamic fine grained access control system -
suitable for Principle Of Least Authority protection for
program operation (unless you consider ACL implementations
such as SELinux to fall into that category.  I do not.).

I've also indicated how I believe the views expressed
in the above paper is still widely shared in the IT
community and has the effect of throwing cold water
on any development that even uses the term "capability"
in the sense of access control as we use it on this list.

I believe this is a criticism that very much needs to
be answered.  Of course I can understand that there
can be disagreement about that - as I noted in my
exchange with David Hopwood.  As you see I'm focused
on the problem of protecting against viruses (and
generally untrustworthy software).  I'm sure you can
appreciate the importance of that problem.  Do you
believe the Mailkey proposal is applicable to that
problem?  In that case I will quickly change my tune.

>  > The problem that we (speaking generally for cap-talk)
>  > are trying to address is that of POLA...
>
>You are preaching the choir.  Horton is not POLA.

About that we disagree.  Horton is based on pure
object/capabilities that permit fine grained
communication of capabilities - whether using
the added responsibility delegation of Horton
or not.  Therefore while Horton in and of itself
is not "POLA", Horton is based on an underlying
object/capability implementation that permits
POLA communication of permissions.  Horton does
not change the underlying object/capability
mechanism that it uses, but merely builds a
service on an underlying object/capability
infrastructure such as is available in E.

>Everyone on this list agrees with POLA and capabilities.
>Horton is an attempt to address identity through
>capabilities.  I don't think it is a good fit for most
>real world cases.

Which 'real world' deployments of capabilities that
are applying POLA are you referring to?  Coyotos?
The Waterken Web Calculus?  Unfortunately I don't know
of enough substance to such systems at this point
to be able to determine whether or not the
organizational pressures for accountability that
are visible in P-1935 (and elsewhere) would suggest
deploying Horton (or something like it) on top of
any such current 'real world' deployments of
capabilities.  I wish we were that far along with
'real world' capability system deployments.

>James A. Donald:
>  >> When dealing with abstractions, it is easy to get
>  >> lost and not notice.
>
>Jed Donnelley
>  > There is nothing abstract about using capabilities for
>  > POLA to deal with the threat from viruses,
>
>Horton, however, does not directly address anything so
>concrete as the threat from viruses.

About the above we agree (whew).  We also seem to agree
that applying POLA using capabilities does address
the real threat from viruses (e.g. with capdesk,
with the powerboxes in deployments like Plash,
anywhere that applications are run with just the
permissions they need rather than with ambient
authority).

The problem is that most IT professionals shun capability
systems because of criticisms like those in P-1935.
They shun capability systems (and thus the possibility
of solving their virus problems) at least partly (mostly?)
because they believe that capability systems cannot
adequately provide accountability for actions taken
within such systems - the "reactive" sort of 'access
control' that MarkM refers to in the Horton paper.

So... While Horton indeed does not itself address the
problem of protection from untrustworthy software,
if Horton was understood to provide adequate
accountability for capability systems, then more
people might accept capability systems and thus
avail themselves of the means to address their
problems with untrustworthy software.

>James A. Donald:
>  >> It seemed to me that Horton is lost and does not know
>  >> it.
>
>Jed Donnelley
>  > I wish I understood why you feel that way.
>
>I have explained, and you snipped my explanation without
>making any relevant response.  I have explained again in
>different words, and I expect you will snip that
>explanation also and make irrelevant response or no
>response.
>
>I am sick of retyping.  If you really wish to
>understand, you should reread.

I have reread.  I still haven't understood your
viewpoint.  Since at this point you are sick,
I guess it's time to give up on what is apparently
an ineffective exchange.  Sorry.

>James A. Donald:
>  > > Building identities on top of capabilities is rather
>  > > like writing a bit wise addition operator in lisp,
>  > > to operate on bit patterns represented as sets.
>
>Jed Donnelley
>  > Uh, except that lisp has a working addition operator.
>
>If it did not have one, it would be an exceedingly bad
>idea to write it in lisp, or to represent integers by
>sets.

I agree (as I indicated in my previous message).

>  > Capabilities do not have a working identity mechanism.
>  > Are you suggesting building such a mechanism into
>  > capabilities somehow?
>
>And I have given a concrete example.

The relevant distinction I was trying to make is
that between building an identity mechanism on
top of object/capabilities (as Horton does) vs.
building an identity mechanism INTO some form
of capabilities.  That (on top of) I haven't seen
you give an example of - unless I missed it (seems
to be a lot of that going around).

>  > What we are seeking is:
>  >
>  > 1.  Practical POLA control of permissions.  We believe
>  > the most effective way to achieve this value is
>  > through communicable tokens of permission (objects)
>  > that we refer to as "capabilities" or
>  > object/capabilities.
>  >
>  > and
>  >
>  > 2.  Identification of responsibility for permitted
>  > actions.
>  >
>  > Any way of achieving the above is fair game.  How do
>  > you believe the above should be achieved James?
>
>I have explained three times so far.  Perhaps you should
>re-read, for I doubt that me retyping is going to have
>any results different from the first three explanations.

Indeed not.  I tried to clarify above where I feel some
of our words are being differently interpreted (goals,
terminology, etc.).  However, if you feel that the only
way to move forward is for me to reread what you have
written before (as I have again while responding to this
message), then I think we are done.  Perhaps others can
weigh in with some clarification.

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