PKIX over Secure HTTP (POSH)
draft-ietf-xmpp-posh-05

Abstract

Experience has shown that it is difficult to deploy proper PKIX certificates for TLS in multi-tenant environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines two methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. While these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application 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 March 4, 2016.

Copyright Notice

Copyright (c) 2015 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.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Obtaining Verification Material
• 3.1. Source Domain Possesses PKIX Certificate Information
• 3.2. Source Domain References PKIX Certificate
• 3.3. Performing Verification
• 4. Secure Delegation
• 5. Order of Operations
• 6. Caching Results
• 7. Guidance for Server Operators
• 8. Guidance for Protocol Authors
• 9. IANA Considerations
• 9.1. Well-Known URI
• 9.2. POSH Service Names
• 10. Security Considerations
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Appendix A. Acknowledgements
• Authors' Addresses

1. Introduction

We begin with a thought experiment.

Imagine that you work on the operations team of a hosting company that provides instances of the hypothetical "Secure Protocol for Internet Content Exchange" (SPICE) service for ten thousand different customer organizations. Each customer wants their instance to be identified by the customer's domain name (e.g., bar.example.com), not the hosting company's domain name (e.g., hosting.example.net).

In order to properly secure each customer's SPICE instance via Transport Layer Security (TLS) [RFC5246], you need to obtain and deploy PKIX certificates [RFC5280] containing identifiers such as bar.example.com, as explained in the "CertID" specification [RFC6125]. Unfortunately, you can't obtain and deploy such certificates because:

• Certification authorities won't issue such certificates to you because you work for the hosting company, not the customer organization.
• Customers won't obtain such certificates and then give them (plus the associated private keys) to you because their legal department is worried about liability.
• You don't want to install such certificates (plus the associated private keys) on your servers because your legal department is worried about liability, too.
• Even if your legal department is happy, this still means managing one certificate for each customer across the infrastructure, contributing to a large administrative load.

Given your inability to obtain and deploy public keys / certificates containing the right identifiers, your back-up approach has always been to use a certificate containing hosting.example.net as the identifier. However, more and more customers and end users are complaining about warning messages in user agents and the inherent security issues involved with taking a "leap of faith" to accept the identity mismatch between the Source Domain (bar.example.com) and the Delegated Domain (hosting.example.net) [RFC6125].

This situation is both insecure and unsustainable. You have investigated the possibility of using DNS Security [RFC4033] and DNS-Based Authentication of Named Entities (DANE) [RFC6698] to solve the problem. However, your customers and your operations team have told you that it will be several years before they will be able to deploy DNSSEC and DANE for all of your customers (because of tooling updates, slow deployment of DNSSEC at some top-level domains, etc.). The product managers in your company are pushing you to find a method that can be deployed more quickly to overcome the lack of proper server identity checking for your hosted customers.

One possible approach that your team has investigated is to ask each customer to provide the public key / certificate for its SPICE service at a special HTTPS URI on their website ("https://bar.example.com/.well-known/posh/spice.json" is one possibility). This could be a public key that you generate for the customer, but because the customer hosts it via HTTPS, any user agent can find that public key and check it against the public key you provide during TLS negotiation for the SPICE service (as one added benefit, the customer never needs to hand you a private key). Alternatively, the customer can redirect requests for that special HTTPS URI to an HTTPS URI at your own website, thus making it explicit that they have delegated the SPICE service to you.

The approach sketched out above, called POSH ("PKIX Over Secure HTTP"), is explained in the remainder of this document. While this approach was developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a prooftype for Domain Name Associations (DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP application protocol.

2. Terminology

This document inherits security terminology from [RFC5280]. The terms "Source Domain", "Delegated Domain", "Derived Domain", and "Reference Identifier" are used as defined in the "CertID" specification [RFC6125].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Additionally, this document uses the following terms:

POSH client:

A client that uses the application service and that uses POSH to obtain material for verifying the service's identity.

POSH server:

A server that hosts the application service and that uses POSH to provide material for verifying its identity.

3. Obtaining Verification Material

Server identity checking (see [RFC6125]) involves three different aspects:

1. A proof of the POSH server's identity (in PKIX, this takes the form of a PKIX end-entity certificate [RFC5280]).
2. Rules for checking the certificate (which vary by application protocol, although [RFC6125] attempts to harmonize those rules).
3. The material that a POSH client uses to verify the POSH server's identity or check the POSH server's proof (in PKIX, this takes the form of chaining the end-entity certificate back to a trusted root and performing all validity checks as described in [RFC5280], [RFC6125], and the relevant application protocol specification).

When POSH is used, the first two aspects remain the same: the POSH server proves its identity by presenting a PKIX certificate [RFC5280] and the certificate is checked according to the rules defined in the appropriate application protocol specification (such as [RFC6120] for XMPP). However, the POSH client obtains the material it will use to verify the server's proof by retrieving a JSON document [RFC7159] containing hashes of the PKIX certificate over HTTPS ([RFC7230] and [RFC2818]) from a well-known URI [RFC5785] at the Source Domain. POSH servers MUST use HTTPS. This means that the POSH client MUST verify the certificate of the HTTPS service at the Source Domain in order to securely "bootstrap" into the use of POSH; specifically, the rules of [RFC2818] apply to this "bootstrapping" step to provide a secure basis for all subsequent POSH operations.

A PKIX certificate is retrieved over secure HTTP in the following way.

    GET /.well-known/posh/spice.json HTTP/1.1
    Host: bar.example.com
            

1. The POSH client performs an HTTPS GET request at the Source Domain to the path "/.well-known/posh.{servicedesc}.json". The value of "{servicedesc}" is application-specific; see Section 8 of this document for more details. For example, if the application protocol is the hypothetical SPICE service, then "{servicedesc}" could be "spice"; thus if an application client were to use POSH to verify an application server for the Source Domain "bar.example.com", the HTTPS GET request would be as follows:
2. The Source Domain HTTPS server responds in one of three ways:
   • If it possesses PKIX certificate information for the requested path, it responds as detailed in Section 3.1.
   • If it has a reference to where the PKIX certificate information can be obtained, it responds as detailed in Section 3.2.
   • If it does not have any PKIX certificate information or a reference to such information for the requested path, it responds with an HTTP 404 Not Found status code [RFC7231].

3.1. Source Domain Possesses PKIX Certificate Information

If the Source Domain HTTPS server possesses the certificate information, it responds to the HTTPS GET request with a success status code and the message body set to a JSON document [RFC7159]; the document is "fingerprints document", i.e., a JSON object with the following members:

• A "fingerprints" member whose value is a JSON array of fingerprint descriptors (the member MUST include at least one fingerprint descriptor).
• An "expires" member whose value is a JSON number specifying the number of seconds after which the POSH client ought to consider the key information to be stale (further explained under Section 6).

The JSON document returned MUST NOT contain a "url" member as described in Section 3.2.

Each included fingerprint descriptor is a JSON object, where each member name is the textual name of a hash function (as listed in [HASH-NAMES]) and its associated value is the base 64 encoded fingerprint hash generated using the named hash function (where the encoding adheres to the definition in Section 4 of [RFC4648] and where the padding bits are set to zero).

The fingerprint hash for a given hash algorithm is generated by performing the named hash function over the DER encoding of the PKIX X.509 certifiate. (This implies that if the certificate expires or is revoked, the fingerprint value will be out of date.)

As an example of the fingerprint format, a "sha-256" fingerprint is generated by performing the SHA-256 hash function over the DER encoding of the PKIX certificate, as illustrated below.

Example Fingerprints Response

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 135

{
  "fingerprints": [
    {
      "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ="
    }
  ],
  "expires": 604800
}
            

The "expires" value is a hint regarding the expiration of the keying material. It MUST be a non-negative integer. If the "expires" member has value of 0 (zero), a POSH client MUST consider the verification material to be invalid. See Section 6 for how to reconcile this "expires" member with the reference's "expires" member.

To indicate alternate PKIX certificates (such as when an existing certificate will soon expire), the returned fingerprints member MAY contain multiple fingerprint descriptors. The fingerprints SHOULD be ordered with the most relevant certificate first as determined by the application service operator (e.g., the renewed certificate), followed by the next most relevant certificate (e.g., the certificate soonest to expire). Here is an example:

{
  "fingerprints": [
    {
      "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ"
    },
    {
      "sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="
    }
  ],
  "expires": 806400
}
          

Matching on any of these fingerprints is acceptable.

Rolling over from one hosting provider to another is best handled by updating the relevant SRV records, not primarily by updating the POSH documents themselves.

3.2. Source Domain References PKIX Certificate

If the Source Domain HTTPS server has a reference to the certificate information, it responds to the HTTPS GET request with a success status code and message body set to a JSON document. The document is a "reference document", i.e., a JSON object with the following members:

• A "url" member whose value is a JSON string specifying the HTTPS URI where POSH clients can obtain the actual certificate information. The URI can be a well-known POSH URI as described in Section 8, but it need not be. (For historical reasons, the member name is "url", not "uri".)
• An "expires" member whose value is a JSON number specifying the number of seconds after which the POSH client ought to consider the delegation to be stale (further explained under Section 6).

Example Reference Response

HTTP/1.1 200 Ok
Content-Type: application/json
Content-Length: 82

{
  "url":"https://hosting.example.net/.well-known/posh/spice.json",
  "expires":86400
}
              

In order to process a reference response, the client performs an HTTPS GET request for the URI specified in the "url" member value. The HTTPS server for the URI to which the client has been referred responds to the request with a JSON document containing fingerprints as described in Section 3.1. The document retrieved from the location specified by the "url" member MUST NOT itself be a reference document (i.e., containing a "url" member instead of a "fingerprints" member), in order to prevent circular delegations.

• Note: See Section 10 for discussion about HTTPS redirects.

The "expires" value is a hint regarding the expiration of the Source Domain's delegation of service to the Delegated Domain. It MUST be a non-negative integer. If the "expires" member has a value of 0 (zero), a POSH client MUST consider the delegation invalid. See Section 6 for guidelines about reconciling this "expires" member with the "expires" member of the fingerprints document.

3.3. Performing Verification

The POSH client compares the PKIX information presented by the POSH server against each fingerprint descriptor object in the POSH reference document, until a match is found using the hash functions that the client supports, or until the collection of POSH verification material is exhausted. If none of the fingerprint descriptor objects match the POSH server PKIX information, the POSH client SHOULD reject the connection (however, the POSH client might still accept the connection if other verification methods are successful, such as DANE [RFC6698]).

4. Secure Delegation

The delegation from the Source Domain to the Delegated Domain can be considered secure if the credentials offered by the POSH server match the verification material obtained by the client, regardless of how the material was obtained.

5. Order of Operations

In order for the POSH client to perform verification of reference identifiers without potentially compromising data, POSH operations MUST be complete before any application-layer data is exchanged for the Source Domain. In cases where the POSH client initiates an application-layer connection, the client SHOULD perform all POSH retrievals before initiating a connection (naturally this is not possible in cases where the POSH client receives instead of initiates an application-layer connection). For application protocols that use DNS SRV (including queries for TLSA records in concert with SRV records as described in [I-D.ietf-dane-srv]), the POSH operations ideally ought to be done in parallel with resolving the SRV records and the addresses of any targets, similar to the "happy eyeballs" approach for IPv4 and IPv6 [RFC6555].

The following diagram illustrates the possession flow:

 POSH                      Source                      POSH
Client                     Domain                     Server
------                     ------                     ------
  |                          |                          |
  |      POSH Request        |                          |
  |------------------------->|                          |
  |                          |                          |
  | Return POSH fingerprints |                          |
  |<-------------------------|                          |
  |                                                     |
  |                  Service TLS Handshake              |
  |<===================================================>|
  |                                                     |
  |                     Service Data                    |
  |<===================================================>|
  |                                                     |
          

 POSH              Source       Delegated              POSH
Client             Domain         Domain              Server
------             ------         ------              ------
  |                  |              |                   |
  |  POSH Request    |              |                   |
  |----------------->|              |                   |
  |                  |              |                   |
  | Return POSH url  |              |                   |
  |<-----------------|              |                   |
  |                                 |                   |
  |            POSH Request         |                   |
  |-------------------------------->|                   |
  |                                 |                   |
  |     Return POSH fingerprints    |                   |
  |<--------------------------------|                   |
  |                                                     |
  |                 Service TLS Handshake               |
  |<===================================================>|
  |                                                     |
  |                     Service Data                    |
  |<===================================================>|
  |                                                     |