[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ACLs vs. Capabilities
Tthe following was missent to spki@c2.COM, instead of c2.org.. Serves me right
for relying on memory.]
>[Feel free to post this comment to the spki list if you think it relevant.]
>>It seems to me that Carl Ellison is describing the capability model
of>security while Bob Jueneman is assuming an Access Control List (ACL)
model>of security.
>>With the capability model, "having" the capability (in this case, the>secret
key) gives you the authority to do whatever it is that the key lets>you do (as
specified in the text of Carl's certificate). In contrast, in>the ACL model,
having the secret key lets you prove identity, and then some>other list
authorizes you to take some action.
>>Perhaps this model can help you better describe your positions.
Those represent two useful models, but I'm not assuming only an ACL view. In
particular, I strongly support the use of additional attributes or fields
within X.509 V3, including private extensions as required, to provided
authorization or capability-like functions. And I'm not sure that Carl meant to
limit his model to the capability-only view, either.
The view you ascribed to me does describe a point of view that some withinthe
ANSI X9F1 group had at one time (and perhaps some still do). They were
assuming, as you said, a basic identity certificate that might be issued by
some neutral CA, and then the organization that wanted to control some
particular function (your basic library card model) would issue an attribute
certificate that would refer back to the identity certificate and grant some
additional right or capability.
That model may have its uses, especially if the granting (and possibly
revoking) or some privilege is highly dynamic, for example in the case of
delegation of authority. In the military, the commanding officer typically
designates an Officer of the Day, which is an assignment that is rotated
through most of the officers in the unit so that they will all have a basic
understanding of what is going on. This helps to ensure survivability, and it
also spread out the load on the CO. The OOD generally has the authority to sign
certain documents or orders in the name of the commander, but just as in the
case of an acting manager in the civilian world, that authority is only for a
limited period.
In this case, issuing a special-purpose certificate granting some temporary
additional authority to an individual makes sense, because the person who is
granting the additional authority may not be the appropriate person to make the
initial basic identity determination. The two certificates can therefore be
tied together to make a whole. (I should also say that some of the motivation
for this came from the restrictions inherent in the X.509 V1 certificates,
which had no place to hold any additional information about the subject).
However, if the privilege or capability is expected to be long-term, then
issuing two certificate may be too much trouble. If I am required to use my
certificate (stored in a token like a key or credit card) to authenticate my
right to have access to my building after hours, then presumably that privilege
will last for a long time. The capability therefore might as well be encoded
into the basic certificate that I use for other purposes, and only the
door-opening software will need to understand it. There are also the usual
forms of engineering tradeoffs. Although a fingerprint template, digitized
photograph, height, weight, eye color, skin color, and even retinal pattern may
be very useful for a number of point-of-presence applications (access control,
fraud control in the case of credit cards, etc.), they don't serve a very
useful purpose for remote access to databases, or for authenticating someone's
digital signature. So someone will have to make a tradeoff between the virtue
of having everything together in one place, vs. the cost of transporting a lot
of unneeded information every time you have to transmit the certificate to
someone.
So it isn't a capabilities vs. ACL question -- it's either or both, as
appropriate. And it's important to understand that X.509 V3 can support both
functions with equal facility.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Jueneman@gte.com
1-617/466-2820
"The opinions expressed are my own, and may not
reflect the official position of GTE, if any, on this subject."