Network Working Group M. Shore Internet-Draft No Mountain Software Expires: August 29, 2013 K. O'Donoghue ISOC February 25, 2013 A problem statement on trust in IETF protocols draft-shore-trust-problemstatement-01 Abstract This document attempts to set out a problem statement and framework for future discussions regarding "trust" in the IETF. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Shore & O'Donoghue Expires August 29, 2013 [Page 1] Internet-Draft Problem Statement on Trust February 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and glossary . . . . . . . . . . . . . . . . . . . 4 3. What is trust? . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Modeling trust . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Path forward . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Informative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Shore & O'Donoghue Expires August 29, 2013 [Page 2] Internet-Draft Problem Statement on Trust February 2013 1. Introduction "Trust" is used quite broadly in IETF documents but has not been discussed or defined very rigorously. To the extent that it's been discussed explicitly it's typically been within an implementation or protocol definition context, often around the question of trust anchors and their management (see RFCs [RFC5914], [RFC5934], [RFC6024], and many others for examples). In this document we intend to tease out how IETF protocols have tended to approach questions around trust, discuss whether or not this has been sufficient, and see if there is new work on trust that could be of value. We are not specifically interested in defining the word "trust," but rather identifying broader issues and problems related to trust. Note, as well, that a survey of trust mechanisms in IETF documents and protocols is out-of-scope for this document. Text relating to problems around revocation will be added to future revisions of this document, as well as text relating to problems modeling trust in third-party and federated authentication and authorization protocols. Shore & O'Donoghue Expires August 29, 2013 [Page 3] Internet-Draft Problem Statement on Trust February 2013 2. Terminology and glossary Assurance, Assurance Level Attestation of Control Authentication Binding, Cryptographic Binding Blocklist/Whitelist Certification, Certification Practices, Certification Practices Statement Certifying Authority, Certification Authority Confidence Correct Digitally Signed/Digital Signature Hijack Identity, Identity information Leap of Faith Legitimate Mediated Trust Revocation Risk Source Integrity Transitive Operations (in the context of Trust) Trust Trust Anchor Shore & O'Donoghue Expires August 29, 2013 [Page 4] Internet-Draft Problem Statement on Trust February 2013 Trust Auditing Trust Establishment and Bootstrapping Trust Framework Trust Revocation Trust Passing Trust Transaction Trustee, Trustor Unilateral Trust, Bilateral Trust Validation, Validation of Compliance Shore & O'Donoghue Expires August 29, 2013 [Page 5] Internet-Draft Problem Statement on Trust February 2013 3. What is trust? As of this writing, "trust" does not appear to be defined in an IETF document, relying, rather, on functional or operational contexts to imply intent. [RFC4949], a quite substantial internet security glossary, does not define it anywhere, although in its definition of "source integrity" it includes the text: The property that data is trustworthy (i.e., worthy of reliance or trust), based on the trustworthiness of its sources and the trustworthiness of any procedures used for handling data in the system. which is a rather circular discussion. Kaliya Hamlin, on her IdentityWoman blog, has written a bit [1] about this in the context of the NSTIC [2] (National Strategy for Trusted Identities in Cyberspace) program, ultimately arguing that a "trust framework" is an accountability framework. Accountability would seem to be a component of an intuitive understanding of "trust," and establishing accountability is a core component of establishing trust as we understand it, but accountability implies auditability only; that is to say, this definition seems to focus on the ability to retrospectively determine that some set of actions took place in the past. Establishing accountability does not establish that future interactions will be safe, and authorized. The OASIS Web Service Secure Exchange Technical committee has developed a standard [ws-trust] to specify a framework for, among other things, brokering trust relationships. Much like the IETF, they seem to rely on an operational definition of "trust": Trust is the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions about a set of subjects and/or scopes. Zainab Aljazzaf has done extensive work on trust in web transactions, and in his doctoral dissertation [tbss] he defines trust as a complex subjective term, with the following components: o Utility: a trustee (for example, an IdP, or a web server) needs to provide a utility to a trustor (for example, a relying party or a web browser) o Dependency and reliability Shore & O'Donoghue Expires August 29, 2013 [Page 6] Internet-Draft Problem Statement on Trust February 2013 o Risk attitude. o Vulnerability o Remedies, in the event of a breach of trust. This is closely related to Hamlin's notion of accountability o Confidence expectation, with an inverse relationship between trust and confidence (Aljazzaf asserts that possession of confidence makes trust unnecessary) o Context-specific o Subjective -- trust is experienced differently for different trustees o A trustor may have no control over the trustee. The more control a trustor has over a trustee, the less need there is for trust He then goes on to propose the following one-sentence definition of trust: Trust is the willingness of the trustor to rely on a trustee to do what is promised in a given context, irrespective of the ability to monitor or control the trustee, and even though negative consequences may occur. The key question seems to be around risk, and the expectations of risk. Imparting trust would seem in some sense to be a signaling mechanism - that transactions with the trusted party should be regarded as carrying known than transactions with non-trusted parties. Shore & O'Donoghue Expires August 29, 2013 [Page 7] Internet-Draft Problem Statement on Trust February 2013 4. Modeling trust Describing, or modeling, trust requires identifying parties and understanding their relationships. It may also require identifying trust processes. Participants in a trust transaction may resemble the participants in identity services (see, for example, the OASIS SAML 2.0 glossary [samlgloss]). A trustor may be seen to take on a similar role to that of a relying party, while a trustee may have a parallel role to an identity provider. Both a trustee and an identity provider make authoritative assertions about a subject. Trustors may or may not have an established relationship with a given entity. That is to say, at the time that a transaction is initiated, a trustor may have information about the other party, and they may have an existing business relationship. For example, if you have an account with your bank, you provide them with identifying and other information. When you establish an account with an ISP you are providing them with considerably less information but you are paying them - you are purchasing a service. It is also common to have unilateral relationships, in which one party has knowledge of and is able to authenticate the other party, but the other party has to rely on mediated trust regarding the first party. This is common with banks, for example, where to access your account online you need to present the credentials you've established directly with the bank, while the bank authenticates itself to you using mediated authentication (an X.509 certificate issued by a commercial CA and presented using the TLS protocol). We believe that in this case, trust establishment and bootstrapping, trust auditing, and trust revocation are normal trust lifecycle activities. Where problems seem to arise is in those cases where two entities without an existing relationship attempt to determine whether or not, and to what extent, they may trust each other. With some exceptions (for example, unauthenticated IPsec SAs [RFC5386], or the use of self-signed X.509 certificates), this involves the use of some mediating agent and tends to rely on a transitive trust model. Transitivity in trust is similar to transitivity in mathematics: "Things which are equal to the same thing are equal to one another." (the first of Euclid's Common Notions). When there are transitive trust relationships, if A trusts B and B trusts C, then A trusts C. Quite possibly the most common case of mediated trust on the internet Shore & O'Donoghue Expires August 29, 2013 [Page 8] Internet-Draft Problem Statement on Trust February 2013 is the use of X.509 [RFC5280]certificates in TLS [RFC5246]. X.509 certificates are issued to identify entities, but because of conflation of identity with trust issues are often seen as conveying trust. That is to say, a model in which I trust a given CA to assert identity is, in practice, often a seen as a model in which I trust a given entity based on its CA's assertion of identity. A given user cannot reasonably be expected to have pre-installed end entity certificates for every server she is likely to want to access, and so we have mediated trust based on someone (in this case, a certification authority) making an authoritative statement about the identity of a server, and that statement being verifiable using formal and well-understood (??) validation procedures, walking a chain of trust back to an installed trust anchor. Another example, but one in which communicating entities may be closely related and still not have foreknowledge of one another, is in the use of group keys, as in GDOI [RFC6407] (the Group DOI for IKE). In that case group members share a key, but access to the key (along with key management operations including initial authentication) is mediated through a Group Controller/Key Server. A non-cryptographic example of mediated, transitive trust is in VoIP systems in which a call control server is used. For example, if user Customer A has service with Service A, and is able to authenticate to that service, and Customer B has service with Service B, and is similarly able to authenticate to its service, Customer A is able to talk to Customer B if Service A and Service B know about each other and trust each other. A variation on the mediated, authority-based trust models described above is consensus systems, where an endpoint or user still needs to rely on an external source for the basis for trust decisions, but a trust decision is based on agreement (or not) between a number of parties. If a very large number of parties state that a given entity is trustworthy, with little disagreement, that leads to a different decision from one when there's substantial agreement that a given entity is untrustworthy, or when there's very little agreement (or insufficient data). As of this writing we are not familiar with consensus-based trust models in IETF protocols. Shore & O'Donoghue Expires August 29, 2013 [Page 9] Internet-Draft Problem Statement on Trust February 2013 5. Problems We believe that these are the major problems with the internet trust infrastructure as commonly used in IETF protocols: o Users, services, and other network elements are often required to make trust decisions about entities with which they have no previous relationship o There is often insufficient information about the practices at and reliability of network entities making identity and attribute assertions o There has been no delegation mechanism to make it clear when one entity is authorized to act on behalf of another entity. OAuth is [3] an authorization mechanism currently under development which may prove to be useful for generalized service delegation. As described in Section 4, we believe that where there are problems related to trust in IETF protocols, it is largely in situations in which participating endpoints have no foreknowledge of one another, or the knowledge is unilateral. This is due at least in part to the familiar problem of conflating authentication - proven identity - with the problem of authorization. In the case where two entities have an existing relationship this is probably reasonable. It is unlikely that the credentials or resources would have been provisioned if the relationship were not authorized. In cases where there is no pre-existing relationship, however, there is frequently insufficient basis to make a trust decision. Transitivity is not appropriate in all cases, and is a genuinely bad idea in many. When a certification authority issues a certificate and signs it, they are making an identity assertion. That may be sufficient for access control decisions when there is local knowledge of the identity being asserted, or when the resources being requested are low-value or not sensitive. The broader problem with identity assertions is that it is not always possible to know how reliable, or trustworthy, a given certification authority or trust anchor is, or what their vetting practices are for verifying a customer's actual identity before issuing a certificate or other credentials. Having a certification authority vouch for an entity's identity is meaningless if the CA is not careful about making sure that an applicant really is who they say they are. Unfortunately it is not often possible to know how reliable a given CA is, or whether or not their vetting Shore & O'Donoghue Expires August 29, 2013 [Page 10] Internet-Draft Problem Statement on Trust February 2013 practices meet a given set of requirements. In addition to the limitations with the existing internet trust and identity infrastructure, there are some missing components, as well. There isn't always a mechanism to identify the relationship between two entities when one is needed. For example, a utility company (gas, electric, sewer, water) may use a third-party payments company, and when you use the utility's website, when you click the "Pay my bill" button you're taken to the payment company's website. From the underlying identity and trust mechanism it is not possible to determine that there really is a relationship between the utility and the payment company, and that the payment company is authorized to collect money on behalf of the utility. A delegation mechanism is missing. Shore & O'Donoghue Expires August 29, 2013 [Page 11] Internet-Draft Problem Statement on Trust February 2013 6. Security Considerations This document attempts to describe and identify problem areas related to trust in the internet infrastructure, within IETF scope. As such it does not introduce new mechanisms. However, it should be understood that the problems described in this document do have immediate impact on the security of related mechanisms. Recommendations for remediation are outside the scope of this document. Shore & O'Donoghue Expires August 29, 2013 [Page 12] Internet-Draft Problem Statement on Trust February 2013 7. Path forward We suggest that there may be value in pursuing discussion of some of the question raised earlier in this document. In particular, o Is there value in a shared understanding or shared definition of what is meant by the word "trust?" o Do we, as an organization, care about clearer descriptions of trust models in IETF protocols? o Do we need to develop a stronger understanding of how to support trust frameworks, or how to develop frameworks in which multiple trust and policy models are used in a given scenario (say, in VoIP, where you may involved DNS, SIP, TLS, STUN, and others in completing a single "call")? o Should we be differentiating between threats introduced by cryptographic or protocol flaws, and threats tied to trust problems? o Does renewed interest in federated and other third-party identity and authorization mechanisms affect organizational priorities around trust issues? o What, if anything, does the IETF need to be doing more generally around questions of trust? Shore & O'Donoghue Expires August 29, 2013 [Page 13] Internet-Draft Problem Statement on Trust February 2013 8. Informative References [tbss] Aljazzaf, Z., "Trust-Based Service Selection", December 2011, . [ws-trust] "WS-Trust 1.3: OASIS Standard", March 2007, . [samlgloss] "Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008. [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010. [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010. [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, October 2010. [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011. [1] [2] Shore & O'Donoghue Expires August 29, 2013 [Page 14] Internet-Draft Problem Statement on Trust February 2013 [3] Shore & O'Donoghue Expires August 29, 2013 [Page 15] Internet-Draft Problem Statement on Trust February 2013 Authors' Addresses Melinda Shore No Mountain Software PO Box 16271 Two Rivers, AK 99716 US Phone: +1 907 322 9522 Email: melinda.shore@nomountain.net Karen O'Donoghue ISOC 7167 Goby Lane King George, VA US Email: odonoghue@isoc.org Shore & O'Donoghue Expires August 29, 2013 [Page 16]