[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rant on Capability Security [LONG]

On Fri, Apr 18, 1997 at 02:56:00PM -0700, Bill Frantz wrote:
> I think I understand some of the power of SPKI as it has been evolving in
> the last month, and it scares me.  I don't think I will be able to reason
> correctly about the security relationships, particulary at 3AM while
> fighting a fire.  I tried to keep my use of SPKI simple, and directly
> mapped to capabilities, so I would be able to use my 25 years of experience
> with capabilities to reason about the security relationships.  YMMV

I have watched with mounting horror the flood of creative,
intelligent, and inventive ideas being applied to SPKI.  Words like "I
don't see any real use for X now, but it might be useful later"  have 
been stated more than once.  

Like Bill, I worked for a number of years on a capability-based OS
(NLTSS), in an environment where security was a priority, and I am
finding it very hard to reason about the model being presented for 

For counterpoint, let me present the following description of NLTSS 
capabilities, couched in SPKI terms:

The issuer, the verifier, and the service provider were all the same,
and called the "server".  The capability always contained the
network address of the server.  Only the server knew how to interpret 
the tag field.  If it was desired to generate a new capability for 
that service (with perhaps restricted permissions) a request was sent 
to the server for a new capability.  That request could have any 
parameters appropriate for the request, including other capabilities 
that served to identify the requestor, or otherwise validate the 
request.  Thus the equivalent of "collapsing certificate chains" was 
completely a function of the service provided, and was completely 
general -- the server could use whatever algorithm it deemed 
appropriate for the purpose.  

Therefore there was no point in defining complex relationships in the
tag fields, because the meaning of the relationship was purely local 
to the service provided.  (In practice, of course, there were many 
common relationships.)  Thus I would almost completely eliminate from SPKI 
any discussion of semantics in tag field, and, at least for version 
1, require that the issuer/verifier be identical, and that 
certificate chains be handled by the I/V as a private matter.

In this model, the "delegate" bit has a particularly simple semantics 
-- it means "can generate a new certificate".  That is, if I have a 
certificate that authorizes me for a particular service (say 
signature authority for purchase orders up to a certain amount in a 
company) I either have the authority to generate a new capability for 
that same service (with perhaps lesser limits) or I don't.  This is 
only useful if I want to limit my liability in my delegation -- with 
or without the "delegate" authority I can let someone else use my 
cert -- this is Bill's old argument about how you can't prevent 
delegation.  However, you as a delegator may not trust a delegatee to 
have your refined level of judgement.  So, if your certificate has 
the delegate bit, you can generate a new certificate, with someone 
else's key, and with lesser permissions.

> >Instead, I see executable programs (single entities) that do different
> things 
> >according to the certificates presented to it when it starts to run. My
> example 
> >of remote access to online facilities is a good example. A grade-school
> student 
> >might be able to view the output of an electron microscope, but not have
> access 
> >to the focus controls. A researcher could do everything.
> This approach maps well to different capabilities, each with different
> authority over a single object.  In your example, the researcher would have
> all the authorities, while the grade-school student would have only the
> "view" authority.

To carry this example a bit further, there might be a researcher with
full access, a docent with somewhat restricted "manipulate" access,
and students with only "view" access.  The "delegate" bit would 
enable the docent to give out more "view" capabilities, or to create 
another docent.

Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55