Trust Management BOF
August 27, 1998
The Birds of a Feather meeting on Trust Management opened with remarks from the
chair, Hilarie Orman, about the purpose of the group and the agenda. Trust
management is the representation, negotiation, and transmission of policy for sharing
network resources. The idea of the BOF arose from a conjunction of available
technology and the complications in defining suitability policy frameworks for new
standards such as IPSEC and mobile IP. The BOF was charged with refining the
definition and seeking opinions on the viability and utility of a working group in
1. Matt Blaze of AT&T gave the first talk. He addressed the differences between
trust management and certification, noting that policy with explicit representation
can be examined by separate software for validation and control. He defined the
goals of having a common syntax and semantics that is simple and amenable to
2. Bob Moskovitz of ICSA spoke about commercial certificate policies. He has
been working to establish certificates that are useful in conjunction with contract
law and regulatory policy. The policies under which the certificates were issued
are maintained must be expressed so that organizations can decide is the
certificates meet their requirements for doing business. It is desirable for the
acceptance procedures to be based on rules rather than lists of number. For
example, the certificate authorities statement of the certificate revocation
conditions, such as timeouts, may be examined as part of the acceptance
procedure. Matt Blaze questioned the relevance of certificate policy to trust
3. John Zao of GTE's BBN Research spoke about the security policy management
project at BBN, which is developing a policy requirements framework. In this
framework applications specify their trust requirements, and the policy subsystem
looks for policies that can satisfy those requirements. He distinguished policy
decisions from enforcement of policy constraints. He also mentioned the need for
secure negotiation mechanisms.
Trust management systems must feature robust enforcement mechanisms and be
applicable to all sizes of networks and use groups. The policies must be sufficiently
expressive to deal with a very wide range of network protocols.
There will be policy interactions between peer entities, between protocol layers,
and between different types of objects. For example, virtual private network
formation requires one type of security policy expression between domains,
while RSVP requires another.
He noted that important issues include representation, enforcement management,
enforcement mechanisms, authentication, and negotiation,processing. While he
questioned the need for discovery mechanisms, he did note that new forms of
access control, even if desirable, would require a huge investment in changing sites
that already have adequate policy expressions using local semantics.
4. Sandra Murphy of Network Associate's TIS Laboratories spoke about firewalls and
active networks; while they can support the formation of secure virtual enclaves on
networks, they do not in themselves solve the problem of distributing policy and
authorizing it suse. Current work is using X.509 certificates. She noted the
difficulty of combining firewall filtering policies with end-to-end security policies.
TIS is also investigating policy expression for group communication. The policy
has the goal of expressing requirements for perfect forward secrecy, minimum key
sizes, non-repudiation, etc. All of the attributes supported by IKE are to be
expressed in the policy language.
5. Carl Ellison of IBM spoke about the SPKI working group's considerations of
policy expression. They have addressed access control and delegation of authority,
but they have not addressed complex policies that involve mixed credentials.
Another unaddressed issue is to enforce mandatory policy and to distinguish it
from discretionary policy.
He also noted that large organizations need to define policy centrally but
disseminate it to their users; this implies a discovery process for policy.
6. Cliff Neuman of USC's Information Sciences Institute (ISI) spoke about his work
with Kerberos and GSS-API. He posed the following questions that should be
answered before performing access operations:
- Is it consistent with policy?
- Is the policy consistent?
- Who sets the policy
- Where is it?
He pointed out that if a trust management system is complicated to understand or
administer or to adopt, then it is unlikely to be successful.
He offered the opinion that GSS-API might be powerful enough to solve all usual
authorization questions, but he thought it was worth considering the possibility of
using a trust management system to give applications the option of delegating
decisions to a different authorization system that the system default.
7. Angelos Keromytis of the University of Pennsylvania spoke about the Keynote
System that derives from work at AT&T Laboratories on a system named PolicyMaker.
Licensees and conditions are two major attributes of the Keynote. The major object
is a policy (which looks like access control assertions) and can be signed. Expressions
are monotonic in order to facilitate automated analysis. When a policy request is made,
Keynote looks for subgraph of assertions that resolves the request (if such a subgraph
exists). The value of a resolution can be TRUE/FALSE/(extensible set of other values).
Names types conforming to X509 or SPKI or allowed, and revocation is supported.
8. Matt Blaze then presented proposed charter items. The working group purpose is
to deveolop a trust management layer for use by many protocols and/or application.
He addressed the need for expression of policy and of simple but general semantics
that will address application needs. The working group should consider how to
map the policy expression requirements from other working groups into suitable,
common semantics. He distinguished the discussion of what actual policy should
be from the discussion of how to represent and work with the representations on
a large scale. While policies are generally expressed in English, the automated
enforcement of the policy is done by computer programs; the term trust
management is a way of referring to the mechanisms, not the English.
General discussion ensued, in which several points were made regarding the
necessity to stay with computer representable objects and mechanisms and to
avoid attempting to set particular policies or to express law.
An action item to discuss the results of the BOF organized by Fred Baker on
schema for policy-based routing was noted.
The value of human readable policy expression was noted as an aid to
Carl Ellison questioned the difference between access control in SPKI and trust
management; Matt Blaze replied that SPKI addressed credentials, not policy. This
is an issue that seems to need further elucidation.
The working group was reminded that the mailing list is managed by Majordomo
and is at firstname.lastname@example.org
Marcus Leech, Security Area Co-Director reminded the group of his early requirement
that other working groups be found to defer their own trust management issues to the
proposed new working group in trust management. A simple poll was taken, limited to
the approximately seven working group chairs who were in attendance. One expressed
the opinion that his group would find no use for any product from a trust management
group, while all others expressed at least cautious interest in seeing the results of such
He also advised selecting a co-chair and to noted that the group should have a schedule
for producing results established quickly.
The meeting adjourned at 5:30 pm.
go to list