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

[Jed Donnelley]

At 08:28 PM 6/1/2007, James A. Donald wrote:
>James A. Donald wrote:
>  >> ...Seems to me that some of the things that Horton is
>  >> attempting to do probably cannot be done, or even
>  >> very clearly defined, with the result that it grows
>  >> without limit in complexity, and declines without
>  >> limit in comprehensibility.
>
>Jed Donnelley
>  > I'm puzzled by your statement that:
>  >
>  > "some of the things that Horton is attempting to do
>  > probably cannot be done, or even very clearly defined"
>  > (and the rest, but let me focus on this)
>  >
>  > Horton in only attempting to do one thing:
>  >
>  >...it seems clear to me that Horton is able to do
>  > the simple delegation work that is claimed.
>
>I find your explanation a good deal clearer than that
>given in the Horton document.

Unfortunately the Horton paper was seriously constrained
on space.  I hope the reviewers are able to understand
the problem that it is solving.

>But is seems to me that Horton is trying to do something
>more,

What makes you think so?

>or that it is considerable overkill for the
>problem you describe.

If you have a simpler solution, propose away, please!
I believe the Horton protocol is quite simple as it
is.  Unfortunately there are some aspects of the
implementation and the way we found to describe it
that may make it seem more complex than it is.
MarkM may disagree with me on this.  I'll be interested
to hear his view on whether my explanation in the
previous message is more or less clear/complete.

>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
>not signed by a public key - that is to say, the
>recipient knows what key it came from but cannot prove
>this to others.  We assume entities are ultimately
>identified by their key, not by a "true name" that is
>somehow bound to the key.

 From my perspective you are focusing on a problem that
is orthogonal to the problem that Horton is solving.

Here are what I believe to be the key points:

1.  Many (most?) of us on this list believe strongly
that POLA is the best (only?) effective 'solution'
to the security problems with viruses and generally
with untrustworthy software.  We have to accept that
there can be untrustworthy software, so what we do
to protect ourselves is POLA.

2.  We also strongly believe that the capabilities
paradigm is the best (only?) effective approach for
achieving POLA.  Object/capabilities (the pure and simple
capabilities) arise naturally as tight/clean
object parameters from object oriented programming.
As such they provide a natural object communication
mechanism - capabilities - that can easily support
POLA, with a little help from some techniques such
as power boxes and application authority initialization
templates.

If #1 and #2 are true, why aren't all our languages,
operating systems, and network communication protocols
capability (and thus POLA) oriented?

One reason (I believe the main reason) is that capabilities
were heavily (!) criticized by the computer science
(security) community during the late 1980s.  This criticism,
such as:

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/

effectively carried the day.  I personally believe there
was a bit of natural laziness in this result - with
ambient authority system such as Unix and VMS already
dominant and getting justified - but I believe the
criticism was sincere.

I recently took a careful look at this criticism
(e.g. in the above paper).  I believe that the most
important unanswered part of that criticism was
that capability systems are unable to log who
did what for auditing purposes and for what
MarkM has referred to as 'reactive' access control.
In "traditional" capability-based systems,
capabilities stand alone as bearer rights.  There
is no notion of who is responsible for what.

What Horton shows is that an effective mechanism
to determine who did what can be added to
object/capability systems - even without changing
the underlying capability mechanism.  Simply with
an added protocol such as Horton.


We believe this answers the primary criticism
that lead to abandoning the capability paradigm.
The next logical step seems to be to go back
and start to build out production capability
systems - something that many of us on this
list are ready to help make happen ;-)

With Horton we can imagine an object capability
system (language, OS, or network) where, for
example, the identities are associated with
people and audit logs can record who did (i.e.
is responsible for) what.  Furthermore, access
control can be managed by identity.  If Bob is
no longer a part of our organization and is no
longer trusted with our resources, we can cut
Bob off, while still granting access to others
that Bob delegated permission to while a member
of the organization.

There is still some controversy here in terms of
how such a "who done it" facility should most
effectively be used, but we feel that fact that
such a facility can be built at all on top of
a pure object/capability system (where permission
communication can be simply a bearer right) is
important.

It does not directly address the problem that
you seem to be focused on.  The problem of
spam I accept is important, but to me it seems
quite a bit more narrow than the issue that
we are addressing with the Horton paper.

>...
>In this situation, what does Horton buy us that Rob
>Meijer's proposal, plus authentication does not buy us?
>
>Suppose Alice has authorities to bypass Carol's spam
>filter.  She gives one of them to Bob.  Since the
>authorities are large unguessable numbers, Carol, on
>receiving a message from Bob, knows he is exercising
>Ann's authority, and since we have a separate
>authentication system, knows that Ann is not exercising
>that authority while pretending to be Bob - which is
>what the system you described above provides, without
>the complexity.

I'm afraid I didn't follow the above.  How does Ann
get into this scenario?  Did you mean Alice for
Ann or is Ann a distinct identity whose separate
identity is significant?

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