[cap-talk] Fwd: Fwd: HotSec '07

[Mark Miller]

Forwarded with permission

---------- Forwarded message ----------
From: Jed Donnelley <capability at webstart.com>
Date: Jul 7, 2007 12:43 PM
Subject: Re: Fwd: HotSec '07
To: Mark Miller <erights at gmail.com>, "Karp, Alan" <alan.karp at hp.com>
Cc: Jed Donnelley <jed at nersc.gov>


At 01:52 PM 7/6/2007, Mark Miller wrote:
>We're in!

Hot dog!  Let me know if you'd like me to try to come along
for the discussion.  Sounds like fun.  I'll see if I can
get a ride...  They seem to suggest you (Mark) and one
other.  That would seem to put Alan and I into the position
of competing for the last slot - if both of us are interested.
I am interested.  The issue for me will be paying for my
'ride' (transport, hotel).  If I can get support for the
ride, e.g. from LBL/NERSC, then I'd definitely enjoy
participating.  Even if not it might work out for me:

I have a trip planned to Massachusetts (currently
scheduled into Hartford, CN with my oldest girl Faye -
who is heading to eastern Massachusetts for college
in the Fall, Simons Rock) on August 16.  One possibility
would be for me to leave early for Massachusetts (with
or without Faye) for the Hotsec workshop and then to
travel around a bit with her as a holiday/vacation and
to help her get familiar with the area after she
arrives before the 16th.  That might work out.

I'll wait to hear from Alan and from you again Mark
on this topic before pursuing the topic of participation
at the conference further.

More reactions below:

>---------- Forwarded message ----------
>From: Trent Jaeger <tjaeger at cse.psu.edu>
>Date: Jul 6, 2007 9:33 AM
>Subject: HotSec '07
>To: erights at gmail.com
>Cc: hotsec07chair at usenix.org
>
>
>On behalf of the 2007 Workshop on Hot Topics in Security (HotSec07)
>program committee, I am pleased to invite you and one other of your
>coauthors (if applicable) to participate in the the workshop, to be
>held August 7, 2007 in Boston, MA, in conjunction with the USENIX
>Security Symposium.
>
>Your position paper below has been selected for presentation at the
>Workshop and inclusion in the workshop proceedings.
>
>"Delegating Responsibility in Digital Systems: Horton's Who Done It?"
>
>The program committee's reviews for your paper are included below;
>please take the comments into account as you revise your paper and
>prepare your presentation.  As with all referee reports, remember that
>different reviewers will sometimes express contradictory opinions.
>
>You (or a coauthor) will be expected to make a brief (10-15 minute)
>presentation that serves as a starting point for a discussion that you
>will then lead.  Participants will be asked to be critical,
>provocative, and creative in responding to your presentation; we will
>expect and encourage lively discussion and debate.
>
>We received 30 position paper submissions and selected only 10 for
>presentation.  Papers were selected especially for their potential to
>stimulate interesting discussion and to inspire new research
>directions.
>
>The workshop registration site is up with an early registration deadline
>of July 27, 2007.  Since the workshop is by invitation only, please send
>me the name of the registering participants, so I can approve these
>registrations (email to hotsec07chair at usenix.org).  For more
>information,
>see the registration web site at:
>
>http://www.usenix.org/events/hotsec07/registration/
>
>
>Congratulations again on your paper, and I look forward to seeing you
>in Boston!
>
>
>Trent Jaeger
>HotSec 2007 Chair
>
>=======================================================================
>
>Title:   Delegating Responsibility in Digital Systems: Horton's Who
>Done It?
>Authors: Mark Miller
>Email:   erights at gmail.com
>
>This paper proposes to solve tracking problems in capability systems.

Hmmm.  I certainly don't like the wording of such a "summary".
The above seems to be ambiguous in that it could mean that
we are trying to track problems vs. what we are doing in
solving the problem of tracking (auditing, providing
for ex post facto control) delegation between responsible
subjects.

>To be honest, I found this paper a little hard to follow as it seemed
>to be a stream of conciousness description of an design with little
>supporting text to clairfy the assumptions or tell me what challenges
>were faced.

That seems a fair criticism, though what to do given the space
constraints coupled with the desire to include the 'implementation'
for reference?

It seems to me we should either get the length limit relaxed
(unlikely I guess) or perhaps remove or abbreviate (perhaps
with web references) the implementation and instead focus as
the reviewer suggests on "supporting text to clarify the
assumptions or tell <me> the challenges that were faced".

I agree with the reviewer that it is important to better
clarify what challenges were faced.  To me it seems we attacked
a problem that most in the field believed was contrary to
any use of capabilities and therefore at least in some sense
couldn't be solved.  I think that is important to say in
more detail.

Perhaps we need a plan of action for responding to the
review?  As the lead author, what do you think Mark?

I suggest taking this discussion immediately to the
cap-talk list, including this message.  Please forward
if you agree or discuss if you don't.

>Alot of the paper was filler (code, figures without
>meaningful captions, ...), so I would expect the authors could have
>made the reason to care a little more clear.

I agree with this criticism.  That was indeed difficult
with the space constraints, given that we wanted to
include the reference implementation.

>Other comments::
>
>   - While I thought the abstract was cute, it did not really help me
>   understand the framing of the paper.  Given my trouble really
>   grasping the details, it would have helped to frame the ideas at the
>   outset.
>
>   - In the end, the solution seemed to be thin on idea.  Why is this
>"hot"?

Heh.  That may be the essence of what we need to respond to.

Horton is "hot" (I believe - which should go without saying) because:

1.  The only effective way to deal with the most important problem
in security (Trojan horses in one form or another) is POLA,

2.  Capabilities are the only (certainly most viable) effective
approach to POLA (providing for dynamic assigning of least
authority to running programs with simple object oriented
parameter passing), and

3.  Capabilities seem, from past experience (criticism), to come
with this difficulty (criticized again and again in papers like
the TCSEC analysis of capabilities) of not providing for an audit
(log) of responsibility for actions - let alone a dynamic means
for 'reactive' access control.  That is of not providing for one
of the most fundamentally important aspects of security, being
able to tell who did what and being able to do anything about a
need to change who can do what.

Horton - somewhat surprisingly - shows how to answer this criticism
(#3) in a reference form for the simplest of pure (unmodified,
'traditional') capability systems.

To my thinking this is 'hot' because it answers this most fundamental
of the criticisms of capability systems and would seem to pave
the way for using capability systems to solve the most serious
security problem of the day (any day?), the Trojan horse problem
(except for legacy compatibility issues - which may be handled
or worked around via other means).

>=======================================================================
>
>The authors propose to 'delegate responsibility' when delegating
>authority
>by attributing actions in object capability systems. The goal is to
>revoke
>access not to the party delegating access but to the party
>responsible for
>abusing access. If A delegates access to B and B abuses the delegated
>access to C, then C can revoke B without impacting A as long as C can
>identify B and
>distinguish it from A. The paper is convincing in its argumentation.

That seems good that the reviewer got the essence of what the
paper is arguing!

>To
>improve the paper, the authors could examine the scalability of their
>approach and apply it to a challenging access control problem (e.g.,
>Wikipedia).

Huh?  Let me see (from Wikipedia - fun that they should start to
include such references in reviews of papers.  This could be trend,
perhaps with papers themselves showing up in the Wikipedia articles?)

"In computer security, access control includes authentication,
authorization and audit."

The Horton paper directly shows how the most effective approach
for dealing dynamically with authorization (for mutually
suspicious processes) can also deal effectively with audit
and even get ex post facto authorization control.

The Horton paper doesn't deal with authentication, but beyond
that it treats all other aspects of computer security in a
way that has never been possible before.

Am I claiming too much?  If the above can be defended, it
seems to me to answer this criticism effectively.

>The authors could also compare it to existing reputation-
>based systems.

Hmmm.  That seems like a good suggestion.  I took a quick
look, but this would seem to require a bit of research.
One question that it would seem we would need to answer
would be that of how any other "reputation-based systems"
deal with access revocation if a subject proves unworthy
of the authority they have been given - for any reason.
Horton provides for access revocation via capability
revocation.  How do any other reputation-based systems
accomplish this most fundamental aspect

>=======================================================================
>
>This paper describes a new technique for capability based access
>control. In
>conventional capability systems, A delegates to B by passing a
>capability
>object to B directly.  Reference monitors are not able to distinguish
>requests by A from requests by B, as both use the same capability.  The
>authors insightfully note that this corresponds to delegating
>"authority"
>but not "responsibility."

Hoorah.

>The authors propose a system, called Horton, that connects authority and
>responsibility.  In Horton, capabilities are implemented as stubs (e.g.
>objects wrapping the interfaces of resources to be controlled). Stubs
>are
>not passed directly as part of delegation.  Instead, if A wishes
>provide B
>with the ability to use stub S, A asks the source of S to created a
>new stub
>S'.  S' is intended for B's use but returned to A (in wrapped form).  A
>passes S' to B in place of passing A's own stub.  Thus a reference
>monitor
>or log can distinguish requests made by A and B.

Right on.  Glad the reviewer 'got it.'

>With some reservation, I support accepting this paper. The technique of
>encoding "watermarked" capabilities as methods appears both promising
>and novel.

There we go.

>However, per my comments below, I found the analysis lacking and
>some aspects of the design under-motivated.

That seems a valid criticism to me.

>Specific comments:
>   * You need to more clearly define reactive access control.  I
>can't tell
>       if you intend to to require that reactive access control methods
>       associate a human-user with requests.  Is revocation a necessary
>       component of reactive a.c.?

Of course it is.  "Reactive access control" simply means that you
are changing who is authorized to do what in response to some
change in the state of things (e.g. somebodies responsibility
changes or somebody proves unworthy of trust).

>   * Assume A has stub S.  In lieu of passing S to B, A communicates
>with
>       a third party to get a (gift-wrapped) stub S', which is suitable
>       for passing to B.  It's not clear to me why A and B cannot
>synthesize
>       S' on their own.  Perhaps there is a technical reason why
>signature
>       chaining cannot be "lifted" to implement stubs, but I don't
>see it.

Very insightful point.  This focuses on my concern about third
party involvement in a 'responsible delegation' directly.

>       Requiring A to communicate with the owner of S appears to
>complicate
>       the system.  Perhaps this is necessary, but the authors provide
>       no discussion of why that is.  This is a major omission.

I agree - we should discuss this.  Who is this reviewer anyway?
Do you know Mark?

>   * Page 3 discusses running Horton across "mutually suspicious
>machines,"
>       and page 4 describes an implementation of unwrap which appears
>       to require passing a mutable reference between actors.  How
>does the
>       model account for this apparently distributed shared state?

Hmmm.  I'm not sure I fully understand this concern.  Is this getting
at Alan's concerns about supporting identities (whos) across
multiple organizations?

>   * To what extent is Horton transparent to programmers?  You mention
>       transparency in section 2, but it's not clear what a
>programmer or
>       system architect must do in order to use Horton.  What sorts of
>       objects can be passed as "whoBlame" or "beMe" arguments to
>makeStub?

If this wasn't clear then it seems to me we should make it
more clear.  From the viewpoint of the program communicating
a permission (object) the Horton protocol can be completely
transparent.  It's exactly when a programmer might want
control (namely to manage access control in response to
changing conditions) that Horton is visible - as is of
course necessary and desirable.  What more can one ask?

>   * Similarly, can existing code be easily modified for use with
>Horton?

Hmmm.  This is an awfully broad request.  I would say that
code that manages existing ACL based access control will not
be particularly easy to modify for use with Horton.  Programs
that are already object oriented (do their communication of
permissions as object arguments) will of course be quite
easy (no change) to use with Horton.  Programs designed
to manage ex post facto changes in authorizations (very
few I assume) should, I think, probably not have too much
difficulty adapting to Horton.  Mark?  I'm not sure how
to answer this without getting into examples.  I wonder
what sort of examples to use?

>   * You repeatedly mention using Horton to assign blame, but do not
>discuss
>       the mechanics of this process.  To you intend for Horton messages
>       to be logged?

I believe the answer to this is yes.

>Is this logging best performed by stubs, or by
>       the service providers which stubs wrap?

That's a good question.  Isn't it clear that only the stubs
have to the authority to do the appropriate logging?

>   * As described in the paper, you must trust Carol to trust Carol's
>log.

An awkward sentence.  I assume he means we trust Carol to
manage Carol's log - ?

>       For instance, if Carol (mistakenly or maliciously) provides Bob
>       with Alice's stub, there is no way to distinguish Alice's and
>Bob's actions.

Hmmm.  I don't believe Carol has access to Alice's stub.  That
is, Carol never gets access to P2 (from the paper), only
S2.  Carol could of course make up S2, so this is no loss.
Of course Carol emphatically doesn't get access to the
beAlice or beBob.

>Have you considered this?  I suspect it could be ameliorated
>by requiring that proxies endorse stubs at each use.

I guess I'm not clear what he's getting at here.

>   * What is your attack model?

Reasonable question.  I believe the answer is that we assume
the integrity of the underlying object/capability implementation
and whatever meaning there is to the who/be objects and then
we defend against an active object appearing (through Horton)
to act for one 'beId' without being directly delegated a
capability labeled as the responsibility of beId through
Horton.  Does more need to be said to answer this?

>Section 2 discusses the possibility
>of A
>       attempting to forge stubs for B.  Are attackers obliged to obey
>       E's memory safety properties or can they attempt to modify stubs
>       with a debugger?

I think perhaps MarkM is in the best position to answer this one.
My concern is mostly with the distributed version of Horton.

>   * What are the (formal or informal) properties provided by
>Horton?  How
>       could a user describe the access control properties of an
>application
>       written in Horton?

I'm not sure what he's getting at here.  An application written
"in" Horton?  Does he mean an application written 'for' Horton?
That is, one that 'manages' access based on responsible
identities?  Is he asking us to define the interfaces to
such manipulation for Horton?  For example, an interface that
allows "upstream" capability holders to revoke and/or reinstate
permission managed through Horton based on object/whoId pairs?

>Presentation:
>   * The paragraph beginning "Only ACLs current support reactive access
>       control" does not ring true.  Your reference [10] explains how
>       revocation can be realized in capability based system.
>       I think this is related to the ambiguity in definition of
>       reactive access control.

Perhaps so.  Input to "reactive access control" must include
the identity for which access is to be controlled.  Despite being
able to revoke access, previous capability systems haven't provided
a facility for identity tracking that could provide this "who
did it?" information.  I guess he's right that we need to
clarify this.  It seemed obvious to me.

>   * Section 2 needs reorganization.  Please explain the Horton
>system and
>       and your Alice/Bob/Carol example in text before getting into the
>       details.

This seems reasonable to me, but it of course come with the question
of either:

1.  Do we get more space, or
2.  What do we leave out?

I wonder if we should ask the reviewer what he feels could/should
be left out so that we can include more explanatory information?

All in all a pretty positive review from my perspective.  I agree
that we need to do something (add/change content?) to convey why
this topic is "hot".  I have thoughts (e.g. as above) on what could
be added.  I'm just not sure what we can remove to stay within the
space constraints.

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




-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM