Overview of the AT&T Labs Trust-Management Project - CiteSeerX

Overview of the AT&T Labs Trust-Management Project Joan Feigenbaum AT&T Labs { Research 180 Park Avenue, Room C203 Florham Park, NJ 07932-0971 USA [email protected]

1 Introduction Emerging electronic commerce services that use public-key cryptography on a mass-market scale require sophisticated mechanisms for managing trust. For example, any service that receives a signed request for action is forced to answer the central question \Is the key used to sign this request authorized to take this action?" In some services, this question reduces to \Does this key belong to this person?" In others, the authorization question is more complicated, and resolving it requires techniques for formulating security policies and security credentials, determining whether particular sets of credentials satisfy the relevant policies, and deferring trust to third parties. Since the Autumn of 1995, a small group at AT&T Labs has conducted a broad research project in Trust Management. Our main focus has been the design, implementation, and use of the PolicyMaker trust-management system [4, 6]. This paper presents some of the ndings and open questions that our group has produced thus far. Reasoned controversy may be stimulated by some of the following design choices: { Authorization not authentication: In answering the question \is the key used to sign this request authorized to take this action?," a trustmanagement system should not necessarily have to answer the question \whose key it is?" Rather, the trust-management framework should support credentials that directly authorize keys for certain types of actions. { General compliance-checking mechanism: The mechanism for checking that a set of credentials proves that a requested action complies with local policy should not depend on the semantics of the application-speci c request, credentials, or policy. Because designing, implementing, and proving the correctness of a compliance checker is a non-trivial task, it should not have to be done from scratch for each application. { Programmability: Policies, credentials, and trust relationships should be expressed in a simple but general programming language. The language should be expressive enough to support the complex trust relationships that can occur in the very large-scale network applications currently being developed. At the same time, simple and standard policies, credentials, and relationships should be expressible succinctly and comprehensibly.

{ Locality of contol: Each party in the network should form the \trust root"

for its own environment. That is, local policy should determine in each transaction whether to accept the credentials presented by a second party or, alternatively, which third party should be asked for additional credentials. Local control of trust relationships eliminates the need for the assumption of a globally known, monolithic hierarchy of \certifying authorities."

2 Discussion We will now discuss each of these decisions brie y and give some of the reasons that they are controversial.

2.1 Authorization not authentication Traditional \public-key certi cates" that bind identities to public keys have received a lot of attention (e.g., [1,2]). Acceptance of the goal of reliable, largescale creation, distribution, interpretation, and, when necessary, revocation of such certi cates is based on the assumption that the way every product or service should deal with a digitally signed request for action and a public key that can be used to verify the signature cryptographically is to ask \who owns the private key that corresponds to this public key?" and \is the owner of that private key authorized to take this action?" We reject this assumption and hence reject the goal. Why would a reliable answer to the question \who owns the private key that corresponds to this public key?" allow a product or service to answer the question \is the owner of that private key authorized to take this action?" In mass-market scale applications, the identities of signers usually won't be known to the receivers of signed requests. Thus they cannot appear on receivers' accesscontrol lists and other identity-based policies for deciding who can do what. Our position is that, rather than supporting signed requests with name-key binding \certi cates," requesters should support them with more exible and general \credentials" that prove that keys are authorized to take actions. Note that a reliable system for associating a persistent \identity" with a public key would provide accountability after the fact for any actions taken in response to signed requests. Developers and users should thus ask what they are really trying to accomplish by processing digital signatures. If it is technically feasible and cost-eective to track down people whose signatures resulted in objectionable actions, then traditional certi cates would be useful if they could be deployed in a reliable way. In the many contexts in which after-the-fact accounting is either technically infeasible or cost-ineective, digital signatures are only useful if they are supported by credentials that prove before the fact that the signer is authorized to take the requested action.

2.2 General compliance-checking mechanism An essential part of the goal of our \trust-management" project is to build a general-purpose, application-independent system that processes queries of the form \does request , supported by credential set , comply with policy ?" Why is this a reasonable goal? Since any product or service that requires some form of proof that requested transactions comply with policies could use a special-purpose compliance checker implemented from scratch, what do developers, administrators, and users gain by using a general-purpose compliance checker? The most important gain is in soundness and reliability of both the de nition and the implementation of \proof of compliance." Developers who set out to implement a \simple," special-purpose compliance checker (in order to avoid what they think are the overly \complicated" syntax and semantics of a generalpurpose system like PolicyMaker) often discover that they have underestimated their application's need for proof and expressiveness; as they discover the full extent of their requirements, they may ultimately wind up reinventing the wheel and implementing a system that is as general and expressive as the \complicated" one they set out to avoid. A general-purpose compliance checker can be explained, formalized, proven correct, and implemented in a standard package, and applications that use it can be assured that the answer returned for any given input ( ) depends only on the input and not on any implicit policy decisions (or bugs) in the design or implementation of the compliance checker. Having made the decision to use a general-purpose compliance checker, we still have to choose and defend a notion of \proof of compliance." A detailed de nition and analysis of the proof system currently used in PolicyMaker is given in [6]. r

C

P

r; C; P

2.3 Programmability The two kinds of PolicyMaker assertions are policies and credentials. Both kinds of assertions have the same form, with two important components: a source (the keyword POLICY in one case and a string representing a credential-issuer in the other) and a program that speci es the nature of the authority that the source is conferring as well as whom or what it is conferring authority on. (See [4,6] for details.) These can be general programs, written in any language for which a \safe" interpreter can be incorporated into the trust-management environment. So far, we have used AWK, only because the pattern-matching features are useful for the policies and credentials we have experimented with and because a \safe" version was conveniently available. The question of which fully expressive programming language or languages are most suitable for policies and credentials is interesting and still wide open; the controversial decision we have made so far is to use general programs. The most common arguments against full programmability of assertions are that it makes assertions incomprehensible and that it is not necessary. We have only the most straightforward response to the incomprehensibility argument:

While it is certainly possible to write incomprehensible assertions using a general programming language, it is not inevitable that this will be done, and indeed we oer the examples in [5,7,9, 10] as evidence that programmability and comprehensibility can co-exist; in fact, we believe that users who need to express complex, real-world policies and credentials in restricted languages will be more likely to produce something incomprehensible than they would have been if given a more expressive language. Our response to the claim that full programmability of assertions is not necessary is that repeated attempts to design adequate, partially programmable assertions have failed. For example, the Simple Public Key Infrastructure (SPKI) proposal [8], like PolicyMaker, supports direct authorization of public keys but rejects the notion that such authorizations should be fully programmable; over time, the original set of authorizations that could be conferred by SPKI credentials has been enlarged and changed several times, in response to what we believe are inevitable needs of applications that cannot be foreseen when any xed set of authorizations is chosen. Very recently, we designed KeyNote [3] in an attempt to provide precisely enough generality and programmability to serve the trustmanagement needs of a Public-Key Infrastructure, if not the trust-management needs of a broader class of applications. It is close enough to being a \subset of PolicyMaker" to permit KeyNote requests and assertions to be processed by the PolicyMaker compliance-checker almost unchanged. I predict that there will be reasonable PKI demands that KeyNote's restricted assertion structure cannot accommodate and that we will wind up responding to such demands by saying \use PolicyMaker."

2.4 Locality of control The idea that explicit, local policy should form the \trust root" for decisions about all potentially dangerous actions has provoked less controversy than our other design decisions (perhaps because this approach has already been taken in certain special cases, including the popular PGP [13]). There may eventually be considerable controversy about how to implement this decision. \Local control" sounds very good in the abstract, but it is most straightforwardly done in a way that requires considerable con guration management by administrators and users. People who embrace the abstract idea that they should control their own \trust relationships" may resent the increased responsibility to choose and maintain security policies. Balancing the demands of local control on the one hand and ease of use and administration on the other is an important upcoming challenge.

3 Open questions Of course the fundamental open questions are whether any general-purpose \trust-management system" will ultimately be widely used in diverse applications and, if so, which one(s). Other open or partially open questions include:

1. Which programming language(s) should be used for policies and credentials? 2. Application areas in which general-purpose trust-management systems have already been deployed include web-page labeling [5,7], signed email [10], and copyright management [9]. Are these the most eective test beds for the idea of general-purpose trust management? Which other application areas should be explored? What evidence of the success or failure of the idea could the developers, users, and administrators of these applications provide? 3. What are some important and challenging elements of security policies that a good trust-management system should facilitate for a wide variety of applications? 4. What is the right way to de ne \credentials proving that a request complies with a policy"? Is the PolicyMaker approach of de ning and analyzing a proof system from scratch reasonable, or would it make more sense to build a trust-management module on top of an existing logic-based programming language or other \inference engine" with standard formal semantics? 5. Where should the boundaries be drawn between a trust-management system and the applications that use it? For example, should credential-fetching and digital signature veri cation be the responsibility of the trust-management system or the calling application?

4 Acknowledgements AT&T participants in the trust-management project include Matt Blaze, myself, Jack Lacy, Dave Maher, and Martin Strauss. Some of the work is joint with Yang-hua Chu (CMU), Angelos Keromytis (Univ. Pennsylvania), Brian LaMacchia (Microsoft), and Paul Resnick (Univ. Michigan). This position paper is my version of the results (to date) of several years of extensive group discussion.

References 1. Information Technology { Open Systems Interconnection { The Directory:Authentication Framework, Recommendation X.509, ISO/IEC 9594-8. 2. International Telegraph and Telephone Consultative Committee (CCITT). The Directory { Authentication Framework, Recommendation X.509 1993 update. 3. M. Blaze, J. Feigenbaum, and A. Keromytis, The KeyNote Trust Management System, work in progress. Internet Draft, March 1998, http://www.cis.upenn.edu/~angelos/draft-angelos-spki-keynote.txt.gz. 4. M. Blaze, J. Feigenbaum, and J. Lacy, Decentralized Trust Management, in Proceedings of the Symposium on Security and Privacy, IEEE Computer Society Press, Los Alamitos, 1996, pp. 164{173. 5. M. Blaze, J. Feigenbaum, P. Resnick, and M. Strauss, Managing Trust in an Information-Labeling System, European Transactions on Telecommunications, 8 (1997), pp. 491{501. (Special issue of selected papers from the 1996 Amal Conference on Secure Communication in Networks.)

6. M. Blaze, J. Feigenbaum, and M. Strauss, Compliance-Checking in the PolicyMaker Trust Management System, in Proceedings of the 2nd Financial Cryptography Conference, Lecture Notes in Computer Science, Springer, Berlin, 1998, to appear. Available in preprint form as AT&T Technical Report 98.3.2, http://www.research.att.com/library/trs/TRs/98/98.3/98.3.2.body.ps. 7. Y.-H. Chu, J. Feigenbaum, B. LaMacchia, P. Resnick, and M. Strauss, REFEREE: Trust Management for Web Applications, World Wide Web Journal, 2 (1997), pp. 127{139. (Reprinted from Proceedings of the 6th International World Wide Web Conference, World Wide Web Consortium, Cambridge, 1997, pp. 227{238.) 8. C. Ellison, A Simple Public-Key Infrastructure, http://www.clark.net/pub/cme/html/spki.html. 9. J. Lacy, D. P. Maher, and J. H. Snyder, Music on the Internet and the Intellectual Property Protection Problem, in Proceedings of the International Symposium on Industrial Electronics, IEEE Press, New York, 1997, pp. SS77{83. 10. R. Levien, L. McCarthy, and M. Blaze, Transparent Internet E-mail Security, http://www.cs.umass.edu/~lmccarth/crypto/papers/email.ps

11. P. Resnick and J. Miller, PICS: Internet Access Controls Without Censorship, Communications of the ACM, October 1996, pp. 87{93. 12. R. Rivest and B. Lampson, SDSI: A Simple Distributed Security Infrastructure, http://theory.lcs.mit.edu/~rivest/sdsi11.html. 13. P. Zimmermann, PGP User's Guide, MIT Press, Cambridge, 1994.