Internet DRAFT - draft-shore-trust-problemstatement
draft-shore-trust-problemstatement
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, <http://ir.lib.uwo.ca/cgi/
viewcontent.cgi?article=1478&context=etd>.
[ws-trust]
"WS-Trust 1.3: OASIS Standard", March 2007, <http://
docs.oasis-open.org/ws-sx/ws-trust/200512/
ws-trust-1.3-os.html>.
[samlgloss]
"Glossary for the OASIS Security Assertion Markup Language
(SAML) V2.0", March 2005, <https://www.oasis-open.org/
committees/download.php/21111/saml-glossary-2.0-os.html>.
[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] <http://www.identitywoman.net/
the-trouble-with-trust-the-case-for-accountability-frameworks>
[2] <http://www.nist.gov/nstic/>
Shore & O'Donoghue Expires August 29, 2013 [Page 14]
Internet-Draft Problem Statement on Trust February 2013
[3] <http://oauth.net/>
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]
