[cap-talk] disputing the slam against capabilities as data

[Ben Laurie]

Karp, Alan H wrote:
> Ben Laurie wrote:
> 
>>> 
>>>E-speak's distribution model took a different approach.  
>>
>>While strings
>>
>>>were passed between machines, the corresponding 
>>
>>capabilities were only
>>
>>>usable on the connection they were sent on.  Someone who 
>>
>>discovered the
>>
>>>capability bits could not use those on his own 
>>
>>communications channel,
>>
>>>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) 
>>appears to 
>>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
> E).

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?

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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