draft-shore-trust-problemstatement.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="no"?>
<!DOCTYPE rfc
  SYSTEM "rfc2629.dtd" [
          <!ENTITY rfc2119 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc ipr='trust200902'
     docName='draft-shore-trust-problemstatement-00'>

<front>
  <title abbrev='Problem Statement on Trust'>
    A problem statement on trust in IETF protocols
  </title>
  <author initials='M.' surname='Shore' fullname='Melinda Shore'>
    <organization>No Mountain Software</organization>
    <address>
      <postal>
        <street>PO Box 16271</street>
        <city>Two Rivers</city>
        <region>AK</region>
        <code>99716</code>
        <country>US</country>
      </postal>
      <phone>+1 907 322 9522</phone>
      <email>melinda.shore@nomountain.net</email>
    </address>
  </author>

  <author initials='K.' surname="O'Donoghue" fullname="Karen O'Donoghue">
    <organization>ISOC</organization>
    <address>
      <postal>
        <street>7167 Goby Lane</street>
        <city>King George</city>
        <region>VA</region>
        <country>US</country>
      </postal>
      <email>odonoghue@isoc.org</email>
    </address>
  </author>

    <date month='July' year='2012' />
    <area>General</area>

    <abstract>
      <t>This document attempts to set out a problem
      statement and framework for future discussions
      regarding "trust" in the IETF.  </t>
    </abstract>
</front>

<middle>
  <section title='Introduction'>
    <t>"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 <xref target='RFC5914' />,
      <xref target='RFC5934' />, <xref target='RFC6024' />, and many
      others for examples).  </t>

    <t>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. </t>

    <t>Note, as well, that a survey of trust mechanisms in IETF documents
      and protocols is out-of-scope for this document, being covered
      <xref target='snyder'>elsewhere.</xref></t>

    <t>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.</t>
    
  </section> <!-- introduction -->

  <section title='What is trust?'>

    <t>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.  <xref target='RFC4949' />,
      a quite substantial internet security glossary, does not define
      it anywhere, although in its definition of "source integrity"
      it includes the text:</t>

    <t><list>
      <t>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.</t>
    </list></t>

    <t>which is a rather circular discussion.</t>

    <t>Kaliya Hamlin, on her IdentityWoman blog, has written a
      <eref target='http://www.identitywoman.net/the-trouble-with-trust-the-case-for-accountability-frameworks'> bit</eref> about
      this in the context of the <eref target='http://www.nist.gov/nstic/'>NSTIC</eref>
      (National Strategy for Trusted Identities in Cyberspace) program,
      ultimately arguing that a "trust framework" is an accountability
      framework.</t>

    <t>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.</t>

    <t>The OASIS Web Service Secure Exchange Technical committee has
      developed a <xref target='ws-trust'>standard</xref> 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":</t>

    <t><list>
        <t>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.</t>
    </list></t>

    <t>Zainab Aljazzaf has done extensive work on trust in web transactions,
      and in his doctoral <xref target='tbss'>dissertation</xref> he defines
      trust as a complex subjective term, with the following components:</t>

    <t><list style='symbols'>
        <t>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)</t>
        <t>Dependency and reliability</t>
        <t>Risk attitude.  </t>
        <t>Vulnerability (trustors have something to lose when they trust</t>
        <t>Remedies, in the event of a breach of trust.  This is closely
          related to Hamlin's notion of accountability</t>
        <t>Confidence expectation, with an inverse relationship between trust
          and confidence (Aljazzaf asserts that possession of confidence makes
          trust unnecessary)</t>
        <t>Context-specific</t>
        <t>Subjective -- trust is experienced differently for different
          trustees</t>
        <t>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</t>
    </list></t>

    <t>He then goes on to propose the following one-sentence definition of trust:</t>
    <t><list>
        <t>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.</t>
    </list></t>

    <t>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
      less risk than transactions with non-trusted parties.      
    </t>

  </section> <!-- what is trust -->

  <section title='Modeling trust' anchor='models'>

    <t>Describing, or modeling, trust requires identifying parties and
      understanding their relationships.  It may also require identifying
      trust processes.</t>

    <t>Participants in a trust transaction may resemble the participants
      in identity services (see, for example, the <xref target='samlgloss'>
      OASIS SAML 2.0 glossary</xref>).  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.</t>

    <t>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.
    </t>

    <t>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).</t>

    <t>We believe that in this case, trust establishment and
      bootstrapping, trust auditing, and trust revocation are
      normal trust lifecycle activities.</t>

    <t>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,
      <xref target='RFC5386'>unauthenticated IPsec SAs</xref>,
      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.</t>

    <t>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.</t>

    <t>Quite possibly the most common case of mediated trust
      on the internet is the use of <xref target='RFC5280'>X.509
      </xref>certificates in <xref target='RFC5246'>TLS</xref>.
      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 certificate 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.</t>

    <t>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
      <xref target='RFC6407'>GDOI</xref> (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.</t>

    <t>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.</t>
      
    <t>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.</t>

  </section> <!-- modeling trust -->

  <section title='Problems'>

    <t>We believe that these are the major problems with the
      internet trust infrastructure as commonly used in
      IETF protocols:</t>

    <t><list style='symbols'>
        <t>Users, services, and other network elements are
          often required to make trust decisions about
          entities with which they have no previous relationship</t>
        <t>There is often insufficient information about the
          practices at and reliability of network entities making
          identity and attribute assertions</t>
        <t>There is no delegation mechanism to make it clear
          when one entity is authorized to act on behalf of another
          entity</t>
    </list></t>

    <t>As described in <xref target='models' />, 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.</t>

    <t>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.</t>

    <t>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 some.  </t>

    <t>When a certificate 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 certificate 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 certificate
      authority vouch for an entity's identity is meaningless
      if the certificate authority 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 practices meet a given set of requirements.</t>

    <t>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.</t>
      

  </section> <!-- problems -->

  <section title='Security Considerations'>
    <t>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.
    </t>

  </section>

</middle>

<back>
  <references title='Informative References'>
    <reference anchor='tbss' target='http://ir.lib.uwo.ca/cgi/viewcontent.cgi?article=1478&context=etd'>
      <front>
        <title>Trust-Based Service Selection</title>
        <author initials='Z.' surname='Aljazzaf' fullname='Zainab Aljazzaf' />
          <date month='December' year='2011' />
      </front>
    </reference>

    <reference anchor='snyder'>
      <front>
        <title>A Survey of Trust Models and Relationships in Internet Protocols</title>
        <author initials='J.' surname='Snyder' fullname='Joel Snyder' />
        <date month='October' year='2011' />
      </front>
    </reference>

    <reference anchor='ws-trust' target='http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html'>
      <front>
        <title>WS-Trust 1.3: OASIS Standard</title>
        <date month='March' year='2007' />
      </front>
    </reference>

    <reference anchor='samlgloss' target='https://www.oasis-open.org/committees/download.php/21111/saml-glossary-2.0-os.html'>
      <front>
        <title>Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0</title>
        <date month='March' year='2005' />
      </front>
    </reference>
    <?rfc include="reference.RFC.4949.xml"?>
    <?rfc include="reference.RFC.5246.xml"?>
    <?rfc include="reference.RFC.5280.xml"?>
    <?rfc include="reference.RFC.5386.xml"?>
    <?rfc include="reference.RFC.5914.xml"?>
    <?rfc include="reference.RFC.5934.xml"?>
    <?rfc include="reference.RFC.6024.xml"?>
    <?rfc include="reference.RFC.6407.xml"?>
  </references>
</back>

</rfc>