[cap-talk] disputing the slam against capabilities as data
ben at algroup.co.uk
Mon Oct 25 07:39:55 EDT 2004
Karp, Alan H wrote:
> Ben Laurie wrote:
>>>E-speak's distribution model took a different approach.
>>>were passed between machines, the corresponding
>>capabilities were only
>>>usable on the connection they were sent on. Someone who
>>>capability bits could not use those on his own
>>>unless he also had the same capability and referred to it
>>with the same
>>>bits. E could be modified to use this approach. All that would be
>>>needed is a per connection mapping between Swiss number and object
>>>reference instead of a single table for all connections.
>>So the nett effect of this is:
>>a) if the bits leak, they're useless
> I would word this to say that it doesn't matter if the bits leak. Same
> facts, different implication.
>>b) if the recipient wants to pass on the capability, they must proxy
> Yes, but the end points can be introduced if the recipient doesn't want
> to proxy. In other words, if Alice has a capability to Carol that she
> wants Bob to have, she can choose to proxy, or she can introduce Bob to
> Carol saying to Carol "Here's what I'll proxy for Bob; you might as well
> let him do it directly." Carol now has the option to accept or refuse
> the introduction. This way path shortening becomes a matter of policy,
> not architecture.
>>c) capabilities are ephemeral
> It is a matter of policy whether or not they are preserved across
> network failure and subsequent reconnection.
>>d) there are no long-term capabilities
> Same answer as c).
OK, but not what you described.
>>We already have ways to handle a) (don't leak the bits). b) is
>>inefficient. c) can be achieved with a proxy capability. d)
>>me to suck.
> It is much better to make an attack inexpressible than to try to prevent
> it. Your solution to a) presumes perfection in not leaking the bits.
True, but I'd contend you need to do pretty well on this anyway for any
kind of security - the bits representing capabilities are far from being
the only bits of interest.
> While proxying does add some latency, it also has advantages for each of
> the parties. The advantage for Alice is that she may be a broker who's
> business depends on her markup (something Alice can do in E). The
> advantage for Bob is that he is not known to Carol and won't get on any
> of Carol's mailing lists (something I'm not sure that Bob can enforce in
But having a scheme that forces proxying (or introduction) is not
required to confer this advantage.
> The advantage to Carol is that she can reliably use Alice as an
> aggregator (something which I think Carol can't enforce in E). I agree
> that the absence of long term capabilities would be a problem, but
> there's nothing in what I described that precludes them.
I disagree. You said "while strings were passed between machines, the
corresponding capabilities were only usable on the connection they were
sent on". This means that when the connection closes, you lose the
ability to use the capability, right?
ApacheCon! 13-17 November! http://www.apachecon.com/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
More information about the cap-talk