[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KeyNote draft available
Bill Frantz:
> Is it better to deliver systems which claim to enforce things
> they can not enforce, or to deliver systems that do not
> make those claims?
The distinction has been made between
"admonition" policies and policies enforced by
engineered security. Policies based on the no-delegation
assumption fall into the admonition category.
I wonder if SPKI or KeyNote could better clarify which
components of policies are based on self-enforcing security,
and which on admonition. A policy or authorization expression
could specify which policies fall into strongly enforced,
admonition, or some intermediate strength of security.
Examples: a freely delegable, or bearer, certificate, good for
a limited amount of encapsulated service. Here, by canceling
the certificate (putting it on a "spent" list), the usage limit
is made self-enforcing. On the other hand, a certificate
issued to a particular entity, and an expected usage limit
based on punishment (reputational, legal, or otherwise) of
entities that misuse the resource, is policy based
on admonition: both in terms of the assumption of non-delegation,
and the expected deterrence effect of the punishment. For a
particular application it may be a quite sufficient admonition -- people
usually don't swap their IDs, for a variety of reasons,
and in many cases reputational or legal deterrents are
effective -- but in terms of engineered security it
remains a policy of admonition, not a policy fully
secured by the protocol.
In the first case we are trusting a self-enforcing protocol, and
in the second case social incentives which probably cannot
be fully specified. Whether the admonition will be followed
depends on the nature of the relationship between the
authorizor, authorizee, and any third parties that might
be invoked.
(A more sophisticated specification might include an
economic analysis of exposures, breach costs, incentives,
etc., but that is probably well beyond the scope of
these policy languages).
I don't think SPKI or KeyNote can or should prevent insecure
constructs -- the world is full of them and they are often
necessary -- but we should allow and encourage them to
be distinguished from self-enforcing constructs when
possible. Certain components of an admonition
system (such as the authentication protocol assuming
non-delegation) are secure while other components
are admonition. It would be interesting if conclusions
could be drawn about the security of a policy by analyzing
the specified security of its components.
Bill Frantz (in another post):
> since you
> can not prevent "informal" delegation by technical means, it is better to
> design the technology to provide an audit trail of the actual delegations,
> so you can control delegation by social means.
Such an audit remains an admonition system, in some cases effective
and in some cases not. The audit can be spoofed by delegating
via key-sharing rather than via the audited mechanism the
user is admonished to use. Economically speaking, the audit does
not deter anti-admonition behaviors whose benefits outweigh the cost
of key sharing.
szabo@best.com
http://www.best.com/~szabo/
PGP D4B9 8A17 9B90 BDFF 9699 500F 1068 E27F 6E49 C4A2
References: