Capability development principles (was Re: [cap-talk] YURLs. What is
the model of development?)
David Chizmadia (JHU)
chiz at cs.jhu.edu
Fri Nov 25 18:00:32 EST 2005
David Wagner wrote:
> David Chizmadia writes:
>>From: "Sandro Magi" <smagi at naasking.homeip.net>
>>> Is it possible to interject some sort of authentication step before a
>>> capability request is satisfied? In explaining the web-calculus to
>>> others, they've often expressed dismay that the unguessable URL is the
>>> only authentication required to access a resource. Their main concern is
>>> that a user might inadvertently leak a URL to a third party who
>>> shouldn't have access to the resource.
>> Of course, the underlying problem is a complete failure on
>>the part of those looking for the extra authentication to
>>understand the concept of capability discipline, but if this
>>provides comfort, it is worth it.
> I don't understand your comment. This is not about comfort and warm
> fuzzies. This is about what seems to me to be a valid real-world concern.
> Framing this as about "comfort" leaves the impression that you consider
> this to be not a real problem and the questioner not thoughtful enough
> to understand why.
I agree that it is a real concern in terms of tradeoffs, but it
is indeed the case that the questioner has either not thought through
or not asked enough questions about the principles of capability
discipline. Caveating that I'm referring to object capabilities
here, my understanding of those principles is as follows:
* An object capability contains both the designation (name) of
a resource and the authority required to access that resource;
* Possessing the capability, such that it can be presented to the
resource server, is the only necessary and sufficient condition
for actually getting access to the resource;
* Revocation and additional accountability are accomplished through
the careful use of facades (membranes?);
As with all security architectures, capability discipline implies
certain obligations on the capability wielder (i.e., client). When
these obligations cannot be met in a particular environment, the
security architect must reconsider the use of capabilities. (When
doing so however, the architect will often find that other approaches
actually impose the same obligations on the client and are therefore
no more or less effective.)
> If the goal is to see capabilities more widely used,
> this kind of response seems, quite frankly, more likely to put people off
> than to win converts.
I agree, but I was speaking to someone who appears to have
been a convert longer than myself, so I was considerably more
blunt than I would be with someone I was trying to convince.
> I'd think that patient education and explanation of your preferred
> solution is going to be a lot more effective than telling people
> they don't understand capability discipline.
Absolutely! I do find the comment somewhat ironic since
education and explanation is usually only required when a
person does, in fact, not understand something; otherwise,
it is either being pendantic or more correctly characterized
as arguing architecture ;-)
> Perhaps you could
> explain what is a better solution to this problem that is more in keeping
> with capability discipline. I like to think that anyone who is reading
> this list is likely to be interested enough to listen to your preferred
> solution, and thoughtful enough to have the capacity to understand.
I was having trouble understanding the first sentence, when I
realized that the quote above dropped my statement that the solution
to the originally stated problem is to use the SSL protocol (which is
an integral component of HTTPSY) in mutual authentication mode. I
assert that this would provide all of the advantages of passwords
with greater assurance.
Looking at the problem from a "pure" capability perspective, the
more correct solution would be to require the server to hand out a
different YURL to each unique client and keep a record of what known
characteristics of the client make that client unique to the server.
Then, when the YURL is presented to the server for access, the server
can check the known characteristics of the client presenting the YURL
against its record for the client that was given the YURL. If the
server had required client login, then it would make perfect sense to
use that login information as a unique characteristic.
More information about the cap-talk