| XMPP Working Group | M. Miller |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Standards Track | P. Saint-Andre |
| Expires: July 30, 2015 | &yet |
| January 26, 2015 |
PKIX over Secure HTTP (POSH)
draft-ietf-xmpp-posh-03
Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted 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 obvious security implications. 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 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.
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 July 30, 2015.
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.
We begin with a thought experiment.
Imagine that you work on the operations team of a hosting company that provides the "foo" service (or email or instant messaging or social networking service) for ten thousand different customer organizations. Each customer wants their service 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 "foo" service via Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX certificates [RFC5280] containing identifiers such as bar.example.com, as explained in the "CertID" specification [RFC6125]. Unfortunately, you can't obtain such certificates because:
Given your inability to 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 what [RFC6125] calls the Source Domain (bar.example.com) and the Delegated Domain (hosting.example.net).
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 the "foo" service at a special HTTPS URL on their website ("https://bar.example.com/.well-known/posh.foo.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 "foo" 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 URL to an HTTPS URL at your own website, thus making it explicit that they have delegated the "foo" 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.
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].
Server identity checking (see [RFC6125]) involves three different aspects:
When POSH is used, the first two aspects remain the same: the POSH server proves it 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 materials 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. (This means that the POSH client needs to 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 processing.)
The process for retrieving a PKIX certificate over secure HTTP is as follows.
GET /.well-known/posh.foo.json HTTP/1.1
Host: bar.example.com
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 a JSON object which MUST have the following:
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). Each fingerprint descriptor MUST possess at least one named hash function.
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; for example, a "sha-1" fingerprint is generated by performing the SHA-1 hash function over the DER encoding of the PKIX certificate.
The following example illustrates the usage described above.
Example Content Response
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 134
{
"fingerprints": [
{
"sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=",
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ="
}
],
"expires": 604800
}
The "expires" value is a hint regarding the expiration of the keying materials. It MUST be a non-negative integer. If no "expires" field is included or its value is equal to 0, a POSH client SHOULD consider these verification materials invalid. See Section 6 for how to reconcile this "expires" field with the reference's "expires" field.
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 JSON object which MUST contain the following:
Example Reference Response
HTTP/1.1 200 Ok
Content-Type: application/json
Content-Length: 79
{
"url":"https://hosting.example.net/.well-known/posh.foo.json",
"expires":86400
}
The client performs an HTTPS GET request for the URL specified in the "url" field value. The HTTPS server for the URL to which the client has been redirected responds to the request with a JSON document containing fingerprints as described in Section 3.1. The content retrieved from the "url" location MUST NOT itself be a reference (i.e., containing a "url" field instead of a "fingerprints" field), in order to prevent circular delegations.
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 no "expires" field is included or its value is equal to 0, a POSH client SHOULD consider the delegation invalid. See Section 6 for guidelines about reconciling this "expires" field with the "expires" field of the fingerprints document.
The POSH client compares the PKIX information obtained from the POSH server against each fingerprint descriptor object in the POSH results, until a match is found using the hash functions that the client suports, or until the collection of POSH verification materials 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 schemes are successful).
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 materials possessed by the client, regardless of how those materials are obtained.
In order for the POSH client to perform verification of Reference Identifiers without potentially compromising data, POSH processes 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 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 processes 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:
Client Domain Server
------ ------ ------
| | |
| Request POSH | |
|------------------------->| |
| | |
| Return POSH fingerprints | |
|<-------------------------| |
| | |
| Service TLS Handshake |
|<===================================================>|
| | |
| Service Data |
|<===================================================>|
| | |
Figure 1: Order of Events for Possession Flow
While the following diagram illustrates the reference flow:
Client Domain Server
------ ------ ------
| | |
| Request POSH | |
|------------------------->| |
| | |
| Return POSH url | |
|<-------------------------| |
| | |
| Request POSH |
|---------------------------------------------------->|
| | |
| Return POSH fingerprints |
|<----------------------------------------------------|
| | |
| Service TLS Handshake |
|<===================================================>|
| | |
| Service Data |
|<===================================================>|
| | |
Figure 2: Order of Events for Reference Flow
The POSH client MUST NOT cache results (reference or fingerprints) indefinitely. If the Source Domain returns a reference, the POSH client MUST use the lower of the two "expires" values when determining how long to cache results (i.e., if the reference "expires" value is lower than the fingerprints "expires" value, honor the reference "expires" value). Once the POSH client considers the results stale, it needs to perform the entire POSH process again starting with the HTTPS GET request to the Source Domain. The POSH client MAY use a lower value than any provided in the "expires" field(s), or not cache results at all.
The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead using the expiration hints provided in the POSH reference document or fingerprints documents. To that end, the HTTPS servers for Source Domains and Derived Domains SHOULD specify a 'Cache-Control' header indicating a very short duration (e.g., max-age=60) or "no-cache" to indicate that the response (redirect, reference, or content) is not appropriate to cache at the HTTP layer.
To indicate alternate PKIX certificates (such as when an existing certificate will soon expire), the returned fingerprints document 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-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=",
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ"
},
{
"sha-1":"T29tGO9d7kxbfWnUaac8+5+ICLM=",
"sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="
}
],
"expires": 806400
}
Rolling over from one hosting provider to another is best handled by updating the relevant SRV records, not primarily by updating the POSH files themselves.
This document registers a well-known URI [RFC5785] for protocols that use POSH. The completed template follows.
Note that the registered URI is "posh." (with a trailing dot). This is merely a prefix to be placed at the front of well-known URIs [RFC5785] registered by protocols that use POSH, which themselves are responsible for the relevant registrations with the IANA. The URIs registered by such protocols SHOULD match the URI template [RFC6570] path "/.well-known/posh.{servicedesc}.json"; that is, begin with "posh." and end with ".json" (indicating a media type of application/json [RFC7159]).
For POSH-using protocols that rely on DNS SRV records [RFC2782], the "{servicedesc}" part of the well-known URI SHOULD be "{service}.{proto}", where the "{service}" is the DNS SRV "Service" prepended by the underscore character "_" and the "{proto}" is the DNS SRV "Proto" also prepended by the underscore character "_". As an example, the well-known URI for XMPP server-to-server connections would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers a service name of "xmpp-server" and uses TCP as the underlying transport protocol.
For other POSH-using protocols, the "{servicedesc}" part of the well-known URI can be any unique string or identifier for the protocol, which might be a service name registered with the IANA in accordance with [RFC6335] or which might be an unregistered name. As an example, the well-known URI for the mythical "foo" service could be "posh.foo.json".
Note: As explained in [RFC5785], the IANA registration policy [RFC5226] for well-known URIs is Specification Required.
This document supplements but does not supersede the security considerations provided in specifications for application protocols that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). Specifically, the security of requests and responses sent via HTTPS depends on checking the identity of the HTTP server in accordance with [RFC2818]. Additionally, the security of POSH can benefit from other HTTP hardening protocols, such as HSTS [RFC6797] and key pinning [I-D.ietf-websec-key-pinning], especially if the POSH client shares some information with a common HTTPS implementation (e.g., platform-default web browser).
Note well that POSH is used by a POSH client to obtain the public key of a POSH server to which it might connect for a particular application protocol such as IMAP or XMPP. POSH does not enable a hosted domain to transfer private keys to a hosting service via HTTPS. POSH also does not enable a POSH server to engage in certificate enrollment with a certification authority via HTTPS, as is done in Enrollment over Secure Transport [RFC7030].
A web server at the Source Domain might redirect an HTTPS request to another URL. The location provided in the redirect response MUST specify an HTTPS URL. Source domains SHOULD use only temporary redirect mechanisms, such as HTTP status codes 302 (Found) and 307 (Temporary Redirect). Clients MAY treat any redirect as temporary, ignoring the specific semantics for 301 (Moved Permanently) and 308 (Permanent Redirect) [RFC7238]. To protect against circular references, clients MUST NOT follow an infinite number of redirects. It is RECOMMENDED that clients follow no more than 10 redirects, although applications or implementations can require that fewer redirects be followed.
Hash function agility is an important quality to ensure secure operations in the face of attacks against the fingerprints obtained within verification materials. Because POSH verification materials are relatively short-lived compared to long-lived credentials such as PKIX end-entity certificates (at least as typically deployed), entities that deploy POSH are advised to swap out POSH files if the hash functions in use are found to be subject to realistic attacks.
Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias Markmann for their implementation feedback. Thanks also to Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their input on the specification.