[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
SPKI.
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
http://songbird.com/kent/pgp_key.html
References: