[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: spec for wire format of SPKI cert
Both Peter Williams and Paul Lambert have asked similar questions about my
views on capabilities, delegation and security. Let me see if I can write
something which actually communicates how SPKI relates to capabilities,
delegation, and security.
Capabilities
Capabilities, in classical capability systems, combine the aspects of
object naming and access authority in one token. It is as if the Unix file
name and the access permissions are combined in a token that can then be
used by the holder to access the file.
If the bits of a capability can be modified by its holder, then any
capability can be forged and any object accessed, a very bad thing.
Classic capability systems prevented alteration of capabilities by storing
them in protected storage. This protected storage was implemented either
by hardware tagged architectures or thru system-call access to special
system-controlled storage.
When we move into a system like the Internet, we no longer have the luxury
of these methods. To protect capabilities in SPKI, we modify them in two
ways: (1) We have the issuer sign the capability, and (2) we have the
capability specifically identify the holder. The resulting thing we call a
certificate.
The issuer's signature prevents the capability from being altered. It
also, indirectly, identifies the resource because we assume issuers and
resources are closely associated.
We specifically identify the holder by including the identification of a
public key. Any entity in the network which holds the corresponding
private key holds the capability. This prevents the capability from being
stolen and used by a third party.
However, introducing the holder as part of the signed capability introduces
a problem which classical capability systems don't have. That is, the
holder of a capability can no longer pass the capability to some other
entity as part of a service request. It is as if Unix programs could no
longer pass file handles to the programs they fork. In a pure capability
system (where capabilities are the only way of expressing authority), not
being able to pass capabilities prevents any use of authority and therefore
such a system is unworkable.
In SPKI, we allow capability passing by use of certificates with the
MAY-DELEGATE attribute. This method provides a simple, auditable way to
delegate authority.
Delegation
However, issuing certificates without the MAY-DELEGATE attribute do not
prevent other methods of delegation. Sharing secret keys provides a simple
way to delegate (although one may argue that since entities are only
identified by the secret keys they have, all things sharing a secret key
are the same entity). Setting up a proxy server provides a way to delegate
which does not require key sharing. Let me give a brief example:
Assume Alice has a certificate allowing her FTP access to xyz.com. The
administrator of xyz.com didn't want Alice to be able to pass FTP access to
others, for example Bob, so Alice's certificate does not have the
MAY-DELEGATE attribute. Alice has several options available to her if she
wants to delegate to Bob. (1) She can give Bob her secret key allowing Bob
to "become" Alice. (2) She can set up a service on her machine which
forwards Bob's FTP requests to xyz.com along with her certificate. This is
a proxy service. (3) She can FTP the files Bob is interested in from
xyz.com and put them up on her FTP site.
Security
The important difference between the security of the lack of MAY-DELEGATE
and the security provided against third party attacks (i.e. Carol
intercepting Alice's certificate and using it) is that lack of a
certificate does not prevent proxy access to a resource. For example: if a
for-pay web site is dependent on client certificates (or passwords for that
matter) to restrict access to paying customers, nothing prevents one of
those customers from providing proxy access to the site for non-paying
customers. Such a proxy would look a lot like the current web anonymising
proxies.
In terms of the NCSC Orange Book, SPKI, and the Internet in general, can
provide discretionary security, but not mandatory security. In order to
provide mandatory security, it will be necessary to prevent activities such
as key sharing and proxy building. While I can imagine techniques for
accomplishing this, they require cooperation of all the system's
users/managers, something which is distinctly lacking in the global
Internet.
I hope this discussion answers Peter's question about what I consider "real
security" to be. I also hope it answers the question in Paul's post. Real
security is technological controls which can not be bypassed, like a real
safe, not a safe door on a plywood room. It is prevention of access, not
just the prevention of certificate chain creation.
-------------------------------------------------------------------------
Bill Frantz | Cave ab homine unius lebri | Periwinkle -- Consulting
(408)356-8506 | [Beware the man of one | 16345 Englewood Ave.
frantz@netcom.com | book] - Anonymous Latin | Los Gatos, CA 95032, USA