[cap-talk] Safety of Password Capabilities

[Karp, Alan H]

Nick Szabo wrote:
> 
> I previously described four big differences between Bob proxying
> requests to Alice's method and Bob giving out a password capability to
> that method, mostly due to fundamental differences between 
> incentives and
> costs incurred between the two cases.  Since I'm not convinced 
> that Alan's very abstract model of security (to the extent I 
> understand
> it) is a useful model -- it seems to ignore, among other 
> critical factors,
> basic differences of incentives and vast differences in 
> hardware resource 
> costs -- I remain convinced that there are at least four distinct and 
> fundamental differences between proxying and sharing a 
> password capability.
> 
I agree that the issues I am ignoring are important.  Indeed, we
considered them in designing the Client Utility.  However, I wanted to
focus this discussion more narrowly, at least to start.  Also, I
wouldn't say that I'm presenting an abstract model of security.
Instead, I'm trying to focus very narrowly on a particular perceived
weakness of password capabilities that some people believe can be
avoided by controlling delegation.
> 
> Since Bob won't, for the reasons of prohibitive costs I described, 
> proxy so many requests, the information revealed and other operations 
> performed with very high probability will in fact be 
> different, even if 
> at the rarified abstraction of your particular formal model they are 
> considered the same. 
> 
Let's look at a very simple example.  Let the password capability Alice
gives to Bob represent a single piece of information.  Alice would
prefer that only Bob have this information, so she doesn't give that
password capability to anyone else.  My question was meant to illustrate
the fact that this information is available to Bob's co-conspirators,
whether Alice can control delegation or not.  If Alice has a billion
such secrets, it is possible that more of them will be revealed in a
given time interval if Bob delegates than if Bob proxies.  

> 
> BTW, what specifically do you mean by "security"?  Something 
> rather different
> from how most other network security people use the term, I suspect. 
> This word is almost as vague and variously used as "trust".  All of us
> could benefit from a clear definition whenever any protocol designer
> claims they are analyzing "security" or that their protocol is
> "secure".   Indeed, a specialized term or brief description of the
> assumptions of the model might be far better than using the term
> "security". 
> 
I agree that we need to be precise.  I think my statement

> > Of course, this attack isn't a "security" vulnerability, in the
sense
> > that some information is revealed or some operation performed that
> > wouldn't happen if Bob proxied the requests. 

is quite clear.  If the password capability controls access to some
information, and if Bob conspires with David, David can still learn that
information whether Alice controls delegation or not.  If Alice is
willing to perform some operation when Bob presents the capability, that
same operation will be done on behalf of David whether the password
capability is presented by David or by Bob on David's behalf.  

If keeping the information secret is important to Bob, he won't share it
widely.  If the service represents a scarce resource, and if Bob wants
to use the service himself, he might not want David using up all of
Alice's resources.  Clearly, incentives are important, but both these
issues are beyond the scope of the narrow issue I'm addressing.
> 
> My security analysis thus takes into account incentives, DOS, and the 
> like.

and that's the key difference between our points.  You are doing a
security analysis, and I'm asking a very narrow question.
>  
> > Yes, but MarkM has shown how to use sealer/unsealer pairs to prevent
> > rights amplification
> 
> This is moving beyond mere password capabilities and adding 
> qualitatively 
> different cryptography -- the very kind of thing I am 
> recommending. 

Does this mean that a sealed password capability is not a password
capability?  I had assumed that it was, but now I'm not so sure.
> 
> It's not an analysis of password capability security when you 
> go outside
> the password capability model.  Password capabilities might be made
> more secure still with zero-knowledge proofs, multiparty private
> computations, post-unforgeable audit logs, and so on -- but they might
> also be made irrelevant.  It's the cryptography, not the password
> capabilities, that would be doing the work in such cases, and
> it's the cryptography that's doing the work with inter-vat 
> sealer/unsealer pairs that password capabilities are unable to do.
> 
I was applying sealer/unsealer pairs only in the case where rights
amplification is an issue, but that's not needed for the more common
case.  Let's resolve that one first.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20050311/89baf3a9/KarpAlanH.vcf