Simple Public Key Trust Alternatives
draft-johansson-pk-trust-alts-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 8, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document describes often used patterns for establishing technical trust for public key-based security architectures other than traditional PKIX-based public key infrastructure. The intent is that this document be useful as a reference for protocol specification authors who use technology like PKIX, PGP or S/MIME as part of their protocols.

Table of Contents

1.  Terminology
2.  Introduction and motiviation
3.  PKIX
4.  Simple Public Key Trust Alternatives
    4.1.  The role of X.509 certificates
    4.2.  Manually Shared Public Keys
    4.3.  Leap-of-faith Shared Public Keys
    4.4.  Authenticated Bag-of-Keys
5.  Examples
    5.1.  SAML Metadata
    5.2.  DNSSEC Trust Bridge
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informational References
§  Author's Address

1.  Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)

2.  Introduction and motiviation

Several protocols introduced by the IETF aswell as by by other SDOs employ public key-based technology in various ways - notably in order to protect messages or channels, eg using security technology like S/MIME, PGP or TLS. Notable examples include SIP, XMPP aswell as calendaring and scheduling protocols and several WebSSO technologies including SAML and OpenID.

A common problem facing these protocols is how to establish technical trust between protocol endpoints in the absence of a canonical internet-wide PKI.

This document only deals with technical trust, i.e artifacts and entities used to establish secure channels between protocol endpoints. Arguably there are larger issues involved in the general concept of "trust" but this falls outside the scope of this document.

Furthermore this document does not attempt to describe new design for technical trust but rather focuses on what can be achieved using common existing protocols, implementations and toolchains.

Quite often the problem of establishing technical trust for public-key technologies is presented as a simple market problem. The theory is that since public Certificate Authorities (CAs) exist and are readily available, their products are a simple answer to the question of how to establish technical trust between (say) TLS endpoints.

Economy does play a role in trust. Most commercial CAs sell several products where the price of the certificate is related to the cost of identity vetting that is performed so clearly there is a relationship between the amount of work that is spent on vetting and due diligence and the value of the trust represented by the technical trust bearer (eg X.509 certificate) that is produced.

Quite often it is desirable to establish technical trust between a small group of entities, excluding all others with a high degree of certainty. This is also known as a "ring of trust". For instance a private CA could be used to represent trust in a set of properties shared by all entities issued keys from the CA - for instance that all key holders represent the same type of organization or that they all represent the same class of service. The value of the CA is in the vetting and due diligence done to insure that the set of of certificates issued from the CA is isomorphic to a proper subset of entities having the given property.

Rather than being a simple question of "how much" vetting/due diligence was done before signing a certificate we see that trust often depends on specific contextual validation ("does this endpoint have property X?") for which no market exists in general since the size of these rings of trust are often small compared to the number of customers of most commercial CAs.

One problem with the single PKI model is that entities often need to participate in transactions within multiple contexts joining multiple rings of trust. The various ways in which multiple contexts can be represented using PKIX (eg naming constraints or 'bridge' CAs) are either not widely implemented or suffer from interoperability problems making them somewhat impractical.

This is not to say that traditional PKIX technology does not have a role to play still. Some of the strategies described in this protocol can be seen as extensions building on top of traditional PKI which remain an important tool.

3.  PKIX

TODO: Overview of bridge/cross PKI.

4.  Simple Public Key Trust Alternatives

4.1.  The role of X.509 certificates

An X.509 certificate can carry lots of semantics using its names and extensions. It is also possible to treat an X.509 certificate as a simple public key container, disregarding any other element in the certificate. Validation for such "raw key" certificates MUST be limited to comparing the public key or key fingerprint with a copy of the public key received from a trusted source. Used this way an X.509 certificate can be used with most existing PKIX implementations by altering the way certificate validation is performed.

While it may seem easier (and cleaner) to handle raw keys directly this is seldom supported in existing implementations.

4.2.  Manually Shared Public Keys

Arguably the simplest form of trust is derived from manually sharing keys. This can easily implemented using any X.509 certificates (which do not necessarily have to be self-signed) serving as public key bearers. In order to support this model it MUST be possible to validate endpoints using key values or key fingerprints. Exactly how the keys are established and updated is out of scope for this simple model.

An example is RADIUS over TCP. Traditionally RADIUS uses a shared-secret model where RADIUS clients and servers are each given (out of band) a secret which must be shared among parties who need to communicate with each other. RADIUS uses UDP. Recent work has extended RADIUS to use TCP ([I‑D.ietf‑radext‑radsec] (Winter, S., McCauley, M., Venaas, S., and K. Wierenga, “TLS encryption for RADIUS,” March 2010.)) and TLS for securing communication between RADIUS endpoints.

Distributing self-signed X.509 certificates and validating peers using their raw keys or key fingerprints is in this context semantically equivalent to managing traditional RADIUS shared secrets.

This begs the question of why a PKI isn't a better alternative than self-signed X.509 certificates used as raw key bearers. From a theoretical perspective a PKI might be preferable to manually sharing keys but practical deployment experience shows that it is very uncommon for RADIUS servers only to be part of a single business relationship which would lead to the requirement to deploy bridge or cross CA between the PKIX PKIs representing the various relationships a RADIUS server may be part of.

Deploying bridge CAs constitutes overhead which may be difficult to justify when the scale of the business relationships (number of relationships and number of members in each ring of trust) is small. By comparison manually sharing (possibly self-signed) certificate is good enough for many situations.

4.3.  Leap-of-faith Shared Public Keys

Certain protocols such as Secure Shell ([RFC4251] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” January 2006.) and [RFC4253] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.)) and BTNS ([RFC5386] (Williams, N. and M. Richardson, “Better-Than-Nothing Security: An Unauthenticated Mode of IPsec,” November 2008.)) allow security associations to be established by the so called leap-of-faith model where an initial association is established with little or no prior trust. Subsequent associations to the same endpoint is by contrast required to be authenticated using keys or other artifacts exchanged during the first association.

For instance Secure Shell associates endpoints (Secure Shell servers) with key fingerprints. When an SSH client opens a connection to the server fingerprints MUST match or the user is notified and forced to take action to manually authenticate the (possibly valid) new key.

The Secure Shell leap-of-faith authentication can be generalized to a pattern for public key sharing: Protocols implementing this pattern MUST provide mechanisms for endpoints to publish their keys or key fingerprints or include them in protocol messages.

The first time a trust relationship is needed the keys or fingerprints are associated with a representation of the endpont (eg URL or hostname). If the endpoint subsequently publishes a different (set of) keys or fingerprints the trust relationship MUST be invalidated and a manual process MUST resolve if this was a valid key roll-over or an attack.

4.4.  Authenticated Bag-of-Keys

A variation of manually shared public keys, the bag-of-keys approach is similar to a traditional X.509 Certificate Authority but with a few important operational differences.

The bag-of-keys is a data structure (eg XML, DNS resource records, ASN.1, etc) containing encoded representation of keys (either raw keys, X.509 certificates or in some cases fingerprints of keys). The data structure MUST be authenticated for instance using one or more digital signatures and it is from this authentication that trust in the contained keys is derived.

Trust in the authentication (eg the signing keys) can be established using manually sharing the corresponding public keys (cf above) or by any other means, including the mechanisms described in this document. Below we'll see how DNSSEC fits into this picture.

By including a time-to-live parameter for the embedded keys or fingerprints in the data structure itself the consumer of the keys can easily determine for how long it is safe to cache the keys in the data structure.

There are several operationally significant differences between a authenticated bag-of-keys and a traditional CA:

• The data structure can describe its own validity to consumers which eliminates the need for revocation infrastructure (eg CRLs or OCSP) - the bag-of-keys is both a CA and a CRL of sorts. Regular updates of the bag-of-keys replaces the need for validity checks.
• Most signature representation (eg XML-DSig or CMS) allows for multiple separate signatures on a single object. Using this mechanism to authenticate the bag-of-keys data structure it is possible to represent multiple trust relationships on single bag-of-keys.
• It is possible to assign multiple keys (with different life-times for instance) to a given entity in the bag-of-keys allowing for a simple roll-over mechanism.
• Keys contained in the bag-of-keys can be used to configure the validation-engine at a time separate from when these keys are used - i.e validation is done at configure-time rather than at run-time. This may seem like a relatively minor point but deployment experience from web federated identity shows this to be an important simplification.

5.  Examples

5.1.  SAML Metadata

The Security Assertion Markup Language (SAML) is a set of protocols and protocol bindings used to communicate information about authentication and authorization between peers. Communication is in the form of XML-based messages. Security is either derived from security at the message-transport layer (eg TLS) or XML digital signatures of the XML messages. In both cases SAML employs various means of establishing technical trust between peers.

Information about SAML entities (protocol endpoints and bindings) is sometimes described using SAML metadata which is used by protocol endpoints and supporting infrastructure. An important part of SAML metadata is to describe the entity-to-key mapping which can be done either by giving the name of a key (eg the name of a certificate) or by embedding the key itself.

Embedding keys in metadata (which is then signed using XML-DSig) is an example of the bag-of-keys pattern described above.

5.2.  DNSSEC Trust Bridge

DNSSEC [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.), [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.), [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.) is a mechanism for securing data in the domain name system (DNS). By introducing new (or reusing existing) resource records it is possible to use DNSSEC to provide a measure of authentication for any data than can be represented stored and queried from the DNS.

For instance [RFC4255] (Schlyter, J. and W. Griffin, “Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints,” January 2006.) describes a way to store Secure Shell ( (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” January 2006.) [RFC4251] and [RFC4253] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.)) fingerprints in DNS and a semantics for the trust derived from such fingerprints when stored in Secure DNS. Other examples include [RFC4398] (Josefsson, S., “Storing Certificates in the Domain Name System (DNS),” March 2006.) (certificates in the DNS) and [RFC4025] (Richardson, M., “A Method for Storing IPsec Keying Material in DNS,” March 2005.) (IPSec keying material).

We can think of these cases as examples of the authenticated bag-of-keys pattern where DNSSEC authenticates the keys (or fingerprints of keys) represented as DNS resource records.

6.  Security Considerations

Revocation is an important part of key management. Experience shows that it is sometimes quite difficult to achieve large-scale deployment of revocation infrastructure. The authentication bag-of-keys pattern does not include revocation but instead relies on the consumer regularly refreshing the data structure. Should the consumer fail to do that there is an increased risk of key compromise.

Leap-of-faith key sharing is vulnerable to user fatigue - presenting a user with questions about security associations when the user only wants to "get to his/her stuff" clearly hasn't worked so far.

Implementors of leap-of-faith patterns should strongly consider not allowing users to make decisions about security associations at all or at least not to present such decisions as problems to be overcome before the user can access resources.

7.  IANA Considerations

None

8.  References

8.1. Normative References

8.2. Informational References

Author's Address