[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Delegation (was: Re: Comments on SPKI draft of 25 March 1997)
-----BEGIN PGP SIGNED MESSAGE-----
Amazing how Carl & Ron each took a different view of John's comment...
First, John, I don't think the two rights are all that distinct. IMO,
when delegation occurs it always means "act as my delegatee". Sometimes,
however, it also includes "delegate to someone else". I think the
may-delegate tag (whatever its type) is enough to capture this.
That said, I don't see an automated way out of your "cascading revoke"
problem. The authority came to Z from X via Y. Since it's Y who
designated Z, when Y loses that authority everything Y did under it has to
be re-affirmed. To get around that, X would have to delegate directly to
Z, but that just gives X more work while making Y redundant, and it
doesn't solve the problem anyway.
Back to the point (boolean vs. integer may-delegate). I still prefer
boolean. When you assign to someone the ability to delegate, what is the
of restricting that power? Sure, infinite delegation can be a security
risk, but is an integer tag enough to mitigate that risk? I don't think
so.
Besides, an integer may-delegate doesn't prevent infinite delegation.
Sure, it restricts the length of a single chain, but nothing prevents the
delegatee from assigning the authority to many people at once.
Marc
On Mon, 31 Mar 1997 John_Reinke@pcmailgw.ml.com wrote:
>
> 31 Mar 97 @ 0900 EST
>
> Distinguished correspondents,
>
> Pardon the intrusion into your thinking, but may I point out that "delegate" may
> have a level of indirection you might wish to consider. In the right "to
> delegate", there are actually two rights clouded by semantics -- the right to
> execute a transaction under my authority as my delegatee without further
> delegation AND the right to delegate my authority to someone else.
>
> You may wish to consider these as two different things. Lest you think this is
> an arbitrary distinction, this is exactly how IBM "fell on its sword" in DB2.
> By failing to distinguish between these two rights, IBM forever coded into DB2
> the problem of "cascading revoke". That is: X as a dbadmin, X grant authority
> to Y; Y grants to Z; Y leaves the firm; X revokes Y and Z is disabled.
>
> Perhaps you might wish to consider this input from one who spent some time in
> that particular bowl of spaghetti.
>
> John Reinke
> 609-282-3738
>
> Note: This is really my own opinion and not reflect any official opinion of my
> employer or my wife -- both of whose opinions count a lot more than mine. ;-)
>
>
>
> ______________________________ Reply Separator _________________________________
> Subject: Comments on SPKI draft of 25 March 1997
> Author: rivest@theory.lcs.mit.edu (Ron Rivest) at UNIXGTWY
> Date: 3/29/97 12:06 PM
>
>
>
> On Question 5:
>
> I am in favor of making the may-delegate field boolean (that is,
> 0/1 valued), as I can't see why someone might need more. Certainly,
> the security implications between ( may-delegate 1 ) and ( may-delegate 2 )
> are hardly crisp, since you are depending on your delegee to determine
> who gets delegated to in either case (either directly by his own judgement,
> or indirectly via his delegees).
>
> Ron Rivest
>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQB1AwUBMz/ce1rdFXNdDxPlAQHTqAMAke6NGcWVo/s5nAHp99WQigaPQs5298nE
KAVoJSmZCpAVtd9hs1L+YVSj4Ki1dJt+Uh5HFTqZjS3TiTVhiP22LDNss5TXbQfr
+o9HS/osmd/kUYugmIeOabJIYFuaw2w5
=yYLo
-----END PGP SIGNATURE-----
References: