Re: Comment on the paper by Rotondi, et al.
David Barbour <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAAOQMStkJUH8KbJ-6VQek3+riCCFdNOah5m8pM8LTeCbMezrjg@mail.gmail.com> |
Could you link to this paper? On Fri, Jan 31, 2014 at 12:50 AM, Karp, Alan H <[email protected]> wrote: > I’m reading the paper section by section as time permits, and I just > finished the piece on revocation. Here I want to comment on the feature > that allows revocation of just the capability and not those delegated from > it. I believe that feature has a serious flaw, but Marc Stiegler has come > up with the correct variant. > > > > As described in the paper, a revocation request can be for the capability > itself or the capability and all capabilities delegated from it. The > problem with the former is that it is too easy to bypass the revocation. > Say that Alice delegates a capability that expires in a year to Bob, a > manager in her department. Bob re-delegates capabilities with subsets of > the permissions to people reporting to him. Three months later, Bob leaves > the company under suspicion of stealing company secrets. Alice clearly > wants to revoke Bob’s capability, but she doesn’t want to disrupt the work > of people in his former department. As a result, she revokes Bob’s > capability but not the capabilities delegated from it. Unfortunately, one > of those delegated capabilities was one Bob delegated to himself with a key > not controlled by the company. The result is that Bob retains access even > after being fired. > > > > Marc Stiegler’s solution to Alice’s dilemma uses the distinction between > vetted and unvetted identities. Say that the enterprise provides a > mechanism by which Bob denotes the target of the delegation by specifying > someone in the company directory. That’s a vetted identity. If Bob > delegates to someone not known to the enterprise, that’s an unvetted > identity. When Bob’s capability is revoked, the rule is to revoke all > capabilities delegated to unvetted identities but leave the others. > > > > ________________________ > > Alan Karp > > Principal Scientist > > Enterprise Services, Office of the CTO > > Hewlett-Packard Company > > 1501 Page Mill Road > > Palo Alto, CA 94304 > > (650) 857-3967, fax (650) 857-7029 > > http://www.hpl.hp.com/personal/Alan_Karp > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk > > _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk