[cap-talk] Fwd: HotSec '07

[Mark Miller]

The Horton paper just got accepted to Hotsec (Hot Topics in Security)
2007. Referee comments below. The deadline for the final paper is
7/31. In order to address the referee's issues and stay within the 5
page limit, some cleverness will be needed. Suggestions appreciated!

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

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"?


=======================================================================

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. 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). The authors could also compare it to existing reputation-
based
systems.

=======================================================================

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

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.

With some reservation, I support accepting this paper. The technique of
encoding "watermarked" capabilities as methods appears both promising
and
novel.  However, per my comments below, I found the analysis lacking and
some aspects of the design under-motivated.

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

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

       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.

   * 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?

   * 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?

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

   * 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?  Is this logging best performed by stubs, or by
       the service providers which stubs wrap?

   * As described in the paper, you must trust Carol to trust 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.  Have you considered this?  I suspect it could be
ameliorated
       by requiring that proxies endorse stubs at each use.

   * What is your attack model?  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?

   * 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?

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.

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

   * Please put spaces between text and citations (e.g. "needs [21]"
instead
       of "needs[21]").






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

    Cheers,
    --MarkM