[E-Lang] cap-based design question

[Jonathan S. Shapiro]

Following Alan's latest, I had a long conversation with MarkM. Here are my
thoughts following that conversation.

First, MarkM's proposal and Alan's do not differ in a substantive way that I
can see. Both proposals effectively embed (object-name, secure-id) in the
target capability. They differ a bit in the overhead of implementation.
After a lot of back and forth, I have come back to the feeling that I am
reluctant to conflate object identity with authority identity in this way in
this application.

What convinced me of this was a question posed by MarkM: "Are there cases in
the information architecture where the identity under which an object was
checked out impacts subsequent operations?" My initial reaction was "no",
but on reflection this is untrue.

One of the very common cases in PCMS will be the case where an individual
checks out a code base anonymously, and later becomes authorized to modify.
This can happen either as a result of their creating a local branch (in
which case they had a cryptographic identity, but it wasn't known to the
server they checked out from), or as the result of being added to the
project team after the initial checkout. Empirically, we run into this
problem all the time with CVS -- we end up hacking our CVS/Repository and
CVS/Root files to avoid the need to download again.

Given this, there is a problem with embedding authorization identity into
the object ids, which is that operations involving an identity change demand
a complete re-acquisition of the client-side tree. This seems undesirable.

Further, the problem, isn't unique to CM systems. We see cases daily at cash
registers where a "supervisor password" is needed. In both cases, the object
being manipulated is manipulated under the authority of the new identity.

All of these situations can be *modeled* using capabilities. That's not at
issue here. For example, you can think of the supervisor password in the
style of a rights amplification operation.

My conclusion from the scenarios above is that I want to keep identity of
object distinct from identity of authorization under which operation is
performed.

Having said this, though, it's also important to be clear about what the
protections are and are not.

Having password-based or crypto-key based authentication separate from
capabilities doesn't necessarily improve security. As MarkM pointed out to
me, the standard script-kiddee DDoS tools now routinely include keystroke
sniffers, so passwords are no harder to get than capabilities if the system
has been compromised.

This means that we need to distinguish between two diferent classes of
attack: attacks that compromise the whole machine vs. attacks that induce
some program to misbehave in a way that misuses the user's proper authority.
My thinking here is that the latter attack is on the one hand more common
and easier to perpetrate, and on the other easier to defend against (by
fixing the scripting languages). Demanding a password from a user isn't per
se adding any security. The security in this situation comes from requiring
acknowledgement from the user via a trusted path that the operation is one
the user intended to perform. When your email agent asks you to authorize a
PCMS commit, there is at least a chance that you will be suspicious.

It seems, then, that I have come to a hybrid design, in which you must
*both* have a capability to the object and also have some authenticated
access to the server. Perhaps, in light of this, I should call it an
"unguessable object name" rather than a capability.

An unprincipled user can clearly choose to give their password away, just as
they can give away capabilities. However, the hybrid approach provides
simultaneously the possibility of delegation constraints and also the
possibility of audit independent of delegation.


Jonathan