Internet DRAFT - draft-snyder-trust-relationships
draft-snyder-trust-relationships
Network Working Group J. Snyder
Internet-Draft Opus One
Expires: April 27, 2012 K. O'Donoghue
ISOC
M. Shore
TBS
October 25, 2011
A Survey of Trust Models and Relationships in Internet Protocols
draft-snyder-trust-relationships-00
Abstract
This document reviews common Internet protocols and discusses how
each protocol establishes, maintains, and tears down trust
relationships within the protocol. This document includes discussion
of "meta" trust issues, including extra-protocol trust creation,
management, and destruction. In cases where specific issues related
to establishment of trust have been documented, these are discussed
as well. By examining both similarities and differences between
different protocols, this document can help protocol designers and
maintainers in IETF working groups learn from successful (and un-
successful) Internet protocols.
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 April 27, 2012.
Copyright Notice
Copyright (c) 2011 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
Snyder, et al. Expires April 27, 2012 [Page 1]
Internet-Draft Trust Models and Relationships October 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview and Problem Statement . . . . . . . . . . . . . . . . 3
4. DKIM (Domain Keys Identified Mail) . . . . . . . . . . . . . . 4
4.1. DKIM Background and Overview . . . . . . . . . . . . . . . 4
4.2. Trust Relationships in DKIM . . . . . . . . . . . . . . . 4
4.3. DKIM Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
5. DNSSEC (Domain Name System Security Extensions) . . . . . . . 4
5.1. DNSSEC Background and Overview . . . . . . . . . . . . . . 4
5.2. Trust Relationships in DNSSEC . . . . . . . . . . . . . . 4
5.3. DNSSEC Diagrams . . . . . . . . . . . . . . . . . . . . . 4
6. PKI (Public Key Infrastructure) . . . . . . . . . . . . . . . 4
6.1. PKI Background and Overview . . . . . . . . . . . . . . . 4
6.2. Trust Relationships in PKI . . . . . . . . . . . . . . . . 5
6.2.1. Basic Model . . . . . . . . . . . . . . . . . . . . . 5
6.2.2. Creating and instantiating trust . . . . . . . . . . . 6
6.2.3. Validating Trust . . . . . . . . . . . . . . . . . . . 8
6.2.4. Revoking Trust . . . . . . . . . . . . . . . . . . . . 8
6.3. PKI Diagrams . . . . . . . . . . . . . . . . . . . . . . . 9
7. RPKI (Resource Public Key Infrastructure) . . . . . . . . . . 9
7.1. RPKI Background and Overview . . . . . . . . . . . . . . . 9
7.2. Trust Relationships in RPKI . . . . . . . . . . . . . . . 9
7.3. RPKI Diagrams . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Snyder, et al. Expires April 27, 2012 [Page 2]
Internet-Draft Trust Models and Relationships October 2011
1. Introduction
Many Internet protocols need to establish some type of trust between
the parties participating in the protocol in order to be effective.
For example, the Internet Key Establishment (IKE) protocol ([insert]
[references] [here]) passes through an authentication phase between
the two IKE peers before it moves to a second phase where
cryptographic material is established for encrypting and
authenticating IPsec traffic. The authentication phase serves to
establish trust between the two IKE peers. For example, if the IKE
peers use pre-shared secrets, then each IKE peer is willing to trust
the other once they have mutually proven knowledge of a pre-shared
secret.
Please note that this document was derived from existing protocols
and does not attempt to define or re-define the function of any
Internet protocol. This document is entirely non-definitive and
should not be used by implementers as an authoritative source of
information about protocol behavior or description.
WHY IS THIS IMPORTANT?
NEED A BETTER DESCRIPTION OF "TRUST" HERE AND WHAT WE WILL BE LOOKING
AT EXACTLY.
The protocols described in the document were chosen for their
exemplar value. This document is not meant to be an exhaustive
description of all protocols and their trust establishment models.
2. Terminology
Trust: This is the definition of Trust.
Authentication: This is the definition of Authentication.
Identification: This is the definition of Identification.
Reputation: This is the definition of Reputation.
3. Overview and Problem Statement
In this section, we would provide as much background and other
related information as we can to help describe some things
including...
WHY ARE WE DOING THIS?
Snyder, et al. Expires April 27, 2012 [Page 3]
Internet-Draft Trust Models and Relationships October 2011
WHAT IS THE VALUE OF THIS CONTRIBUTION?
WHAT ARE WE NOT INCLUDING IN THIS DOCUMENT AND WHY?
4. DKIM (Domain Keys Identified Mail)
4.1. DKIM Background and Overview
Protocol Overview
4.2. Trust Relationships in DKIM
Trust Models and Relationships in DKIM
4.3. DKIM Diagrams
Diagrams go here
5. DNSSEC (Domain Name System Security Extensions)
5.1. DNSSEC Background and Overview
Protocol Overview
5.2. Trust Relationships in DNSSEC
Trust Models and Relationships in DNSSEC
5.3. DNSSEC Diagrams
Diagrams go here
6. PKI (Public Key Infrastructure)
6.1. PKI Background and Overview
The IETF PKIX working group has specified an X.509v3 profile, and
that profile and set of associated specifications are colloquially
referred to as PKIX. The core specification is RFC 5280.
Throughout this section we look at how trust is conveyed in PKIX from
two perspectives:
Snyder, et al. Expires April 27, 2012 [Page 4]
Internet-Draft Trust Models and Relationships October 2011
(1) from the perspective of a relying party -- an entity that
receives an assertion (credential) and needs to make a decision
whether or not to trust it, and
(2) from the perspective of an end entity -- an entity that needs to
assert its identity in a way that can be accepted by a relying
party.
By way of terminology, the entity which signed a certificate and
which is vouching for the authenticity of both the certificate and
the certificate holder is referred to as the issuer. The entity to
which the certificate was issued is the subject.
Trust in PKIX is instantiated through the use of trust anchors. A
trust anchor is itself a certificate, but one about which a human has
made an explicit trust decision. In this context, subsequent trust
decisions must successfully chain back to that initial decision --
that a certification authority is reliable, secure, and honest, and
that its business practices provide assurance that it will only be
issuing certificates to entities which are also reliable, secure, and
honest.
This document does not yet discuss the Trust Anchor Management
Protocol. [insert][reference][here] TAMP does not change the
underlying trust model or the trust lifecycle, although it does
provide mechanisms for implementing it.
6.2. Trust Relationships in PKI
6.2.1. Basic Model
Perhaps the key assumption around which PKIX is built is that it is
not necessary for two entities to have an existing relationship in
order to make a decision whether or not to accept the otherE1/4s
assertions as 1) correct, and 2) trustworthy. Rather than
negotiating in advance of any communication, those decisions are
mediated through the use of third party agents, and consequently
whether or not a given entity is trustworthy comes down to the
question of whether or not the agent (and its agent, and on up the
chain) can be seen as trustworthy and authoritative, and can make
reliable assertions about the credentials it has issued.
A certification authority, which may or may not be a commercial
entity, issues signed credentials for its customers. These
credentials are known as end entity certificates. Its signature is
essentially an attestation that the CA has some level of confidence
that the entity to which the certificate was issued really is who it
claims to be. Certificates may be chained from a trust anchor --
Snyder, et al. Expires April 27, 2012 [Page 5]
Internet-Draft Trust Models and Relationships October 2011
that is to say, there may be from zero to n certification authorities
between the trust anchor and the end entity to which the certificate
has been issued.[insert][reference][here]
Trust is instantiated by provisioning a root certificate in a local
cache or in some logically local data store. This root certificate
functions as a trust anchor. If the process of validating an end
entity certificate does not terminate at a trust anchor, the
validation fails.
The data model is essentially hierarchical, and tree-shaped. While a
CA may issue multiple (typically many) certificates, a certificate
may have only one issuer. At the very top of the trust tree is a
person or organization who determines which root certificates
represent a trusted CA (note that this decision and associated
information are basically determined manually and out-of-band,
typically requiring human judgment).
Bidirectional trust may be established between two CAs and their
subjects through the use of cross-certification. In this case the
two CAs issue certificate to each other. It is still the case,
however, that a certificate will have one issuer, and that a CA may
issue multiple (many) certificates. The decision to cross-certify is
still out-of-band, and human. The question of what the trust anchor
is in this situation is still being debated on the pkix mailing list5
and is unresolved as of this writing. (Oct/2011)
Self-signed certificates merit special mention, because they are so
commonly deployed. A self-signed certificate is one in which the
issuer and the subject are the same. It is very rarely the case that
a self-signed certificate is already installed in a root cert cache
and is functioning as a trust anchor, but it is very common for users
to accept and install self-signed certificates when they are offered
by a visited website.
6.2.2. Creating and instantiating trust
There are two aspects to creating trust and instantiating it through
PKIX technologies. The first aspect relates to the determination
made by a user or systems administrator (i.e. a relying party) that a
given certification authority is a reliable source of authority
regarding the identity of the entities represented in the certificate
it issues. The second relates to the determination made by the end
entity that a given certification authority is a reliable agent --
that they are who they say they are, that their business practices
are sound, that the operation of their certificate infrastructure is
secure, and, perhaps most importantly, that the chain to the trust
anchor contains only issuers who are also secure, reliable, and
Snyder, et al. Expires April 27, 2012 [Page 6]
Internet-Draft Trust Models and Relationships October 2011
trustworthy. The relying party also needs to have assurances about
intermediate CAs and certificates in a chain, but this comes into
play during validation, not during provisioning.
6.2.2.1. Bootstrapping trust in a relying party
From an end entity perspective, trust is instantiated, or verified,
through the presence of trust anchors in a local store. A decision
to install or provision a root CA certificate as a trust anchor is an
out-of-band, human decision and represents a decision to trust that
the CA represented by that certificate is secure, reliable, and
authoritative. It also represents a decision that the intermediate
CAs underneath the root CA are also secure, reliable, and
authoritative (this has turned out to be a problem, in practice).
It is typically the case that web browsers are distributed with a
cache of root certificates, which have been vetted with varying
degrees of rigor by the browser developers. When a user decides to
use a browser with an existing cache, theyE1/4re implicitly trusting
the browser developers. This is not unreasonable -- in theory, the
browser developer has the resources and expertise to evaluate trust
anchors for inclusion, and will exclude certificates from unreliable
CAs.
In other cases, often in cases where a local CA is issuing
certificates, a local systems administrator makes the decision to add
a root CA certificate from a local (or neighboring) CA.
A special case of bootstrapping trust, and one which poses a security
problem, is that a user may be offered an unknown certificate, be
asked by the browser whether or not to accept it, and will not only
accept the certificate as authentic but also install it locally for
future use. In this situation there is an apparent disconnect
between whatE1/4s happening conceptually in the security transaction
(the user is being asked whether or not to accept a credential as
both authentic and trustworthy) and the userE1/4s understanding of
whatE1/4s going on (the user just wants the connection to complete
and may not understand the underlying security model).
6.2.2.2. Bootstrapping trust in an end entity
In this case, bootstrapping essentially means investigating
certification authorities, making a decision to acquire a certificate
from one, and installing that certificate. Again,this is a human
decision thatE1/4s instantiated through technical means (the
provisioning of the certificate).
Unfortunately there really is no way, as a relying party, to
Snyder, et al. Expires April 27, 2012 [Page 7]
Internet-Draft Trust Models and Relationships October 2011
determine the soundness of the end entityE1/4s decision to acquire a
cert from a particular CA. It may be that they chose one CA over
another on the basis of business practices but it may also be the
case that they chose the least expensive vendor regardless of
soundness. When things are working as they should a CA will only
sell certificates to other very reliable CAs, and on down the chain,
but there have been several issues with compromised or sloppy
intermediate CAs in the recent past that call this model into
question.
6.2.2.3. A brief digression on EV certs
The CA/Browser forum has published guidelines for identity
verification, including specification of specific identity criteria.
These center around three goals:
(1) establish the legal identity of the certificate applicant;
(2) establish that the applicant has legal ownership of the entity
for which the certificate is to be issued (the Subject), and
(3) confirm the identity and the authority of the ownerE1/4s agents.
Certificates issued under these criteria are called Extended
Validation Certificates. Browser markers provide visual clues, such
as color in the address bar, when an EV certificate is present and
has been validated. A CA must typically pass an independent audit to
be accepted by browser vendors as an issuer of EV certs.
6.2.3. Validating Trust
In PKIX, trust is chained back to a trust anchor. Validation
essentially consists of path validation, with the assumption that
youE1/4ll trust who your anchor vouches for, and so on up the chain.
It may also be the case that a non-root certificate - an end-entity
certificate thatE1/4s not a trust anchor, is explicitly trusted,
usually through local installation in a browser or other cache.
Unfortunately itE1/4s often the case that the user is making a
decision to get a connection to work rather than making an explicit
trust decision.
6.2.4. Revoking Trust
The X.509 lifecycle model typically is based on a long-lived
credential (months or, more often, years) which may expire without
being reissued, or may be explicitly revoked. Explicit revocation
may be accomplished through a variety of measures:
Snyder, et al. Expires April 27, 2012 [Page 8]
Internet-Draft Trust Models and Relationships October 2011
(1) Manual removal from a browser or other certificate cache,
(2) Blacklist checking by the relying party as part of the
validation process. This, in turn, may take one of several
forms:
(a) Certificate revocation lists, issued by the certification
authority which issued the original certificate. These
should be created and published on a regular, timely
schedule and must be checked as part of the certificate
validation process.
(b) A status query at validation time, through the use of the
Online Certificate Status Protocol
(c) Blacklisting by the browser vendor
The technical means for revoking trust is essentially the same as
that for revoking a non-trust anchor certificate. If the trust
anchor is gone, certificates which chain back to it will fail the
validation check.
6.3. PKI Diagrams
Diagrams go here
7. RPKI (Resource Public Key Infrastructure)
7.1. RPKI Background and Overview
Protocol Overview
7.2. Trust Relationships in RPKI
Trust Models and Relationships in RPKI
7.3. RPKI Diagrams
Diagrams go here
8. IANA Considerations
None.
Snyder, et al. Expires April 27, 2012 [Page 9]
Internet-Draft Trust Models and Relationships October 2011
9. Security Considerations
To be supplied.
10. Acknowledgements
Insert list of key collaborators..
11. References
11.1. Normative References
11.2. Informative References
Authors' Addresses
Joel Snyder
Opus One, Inc.
1404 East Lind Road
Tucson, Arizona 85719
US
Phone: +1 520 324 0494
Email: jms@opus1.com
URI: http://www.opus1.com/jms
Karen O'Donoghue
The Internet Society
7167 Goby Lane
King George, Virginia 22485
US
Email: odonoghue@isoc.org
URI: http://www.isoc.org
Melinda Shore
TBS
Snyder, et al. Expires April 27, 2012 [Page 10]
