draft-ietf-xmpp-posh-00.txt   draft-ietf-xmpp-posh-01.txt 
XMPP Working Group M. Miller XMPP Working Group M. Miller
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track P. Saint-Andre Intended status: Standards Track P. Saint-Andre
Expires: August 8, 2014 &yet Expires: December 21, 2014 &yet
February 4, 2014 June 19, 2014
PKIX over Secure HTTP (POSH) PKIX over Secure HTTP (POSH)
draft-ietf-xmpp-posh-00 draft-ietf-xmpp-posh-01
Abstract Abstract
Experience has shown that it is extremely difficult to deploy proper Experience has shown that it is extremely difficult to deploy proper
PKIX certificates for TLS in multi-tenanted environments, since PKIX certificates for TLS in multi-tenanted environments, since
certification authorities will not issue certificates for hosted certification authorities will not issue certificates for hosted
domains to hosting services, hosted domains do not want hosting domains to hosting services, hosted domains do not want hosting
services to hold their private keys, and hosting services wish to services to hold their private keys, and hosting services wish to
avoid liability for holding those keys. As a result, domains hosted avoid liability for holding those keys. As a result, domains hosted
in multi-tenanted environments often deploy non-HTTP applications in multi-tenanted environments often deploy non-HTTP applications
skipping to change at page 1, line 34 skipping to change at page 1, line 34
identifier, resulting in obvious security implications. This identifier, resulting in obvious security implications. This
document defines two methods that make it easier to deploy document defines two methods that make it easier to deploy
certificates for proper server identity checking in non-HTTP certificates for proper server identity checking in non-HTTP
application protocols. The first method enables the TLS client application protocols. The first method enables the TLS client
associated with a user agent or peer application server to obtain the associated with a user agent or peer application server to obtain the
end-entity certificate of a hosted domain over secure HTTP as an end-entity certificate of a hosted domain over secure HTTP as an
alternative to standard PKIX techniques. The second method enables a alternative to standard PKIX techniques. The second method enables a
hosted domain to securely delegate a non-HTTP application to a hosted domain to securely delegate a non-HTTP application to a
hosting service using redirects provided by HTTPS itself or by a hosting service using redirects provided by HTTPS itself or by a
pointer in a file served over HTTPS at the hosted domain. While this pointer in a file served over HTTPS at the hosted domain. While this
approach is developed for use in the Extensible Messaging and approach was developed for use in the Extensible Messaging and
Presence Protocol (XMPP) as a Domain Name Association prooftype, it Presence Protocol (XMPP) as a Domain Name Association prooftype, it
can be applied to any non-HTTP application protocol. can be applied to any non-HTTP application protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2014. This Internet-Draft will expire on December 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Obtaining Verification Materials . . . . . . . . . . . . . . 4
4. Obtaining Verification Materials . . . . . . . . . . . . . . 4 3.1. Source Domain Possesses PKIX Certificate Information . . 5
4.1. Source Domain Possesses PKIX Certificate . . . . . . . . 6 3.2. Source Domain References PKIX Certificate . . . . . . . . 6
4.2. Source Domain References PKIX Certificate . . . . . . . . 7 3.3. Performing Verification . . . . . . . . . . . . . . . . . 7
4.3. Performing Verification . . . . . . . . . . . . . . . . . 8 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8
5. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 9 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8
6. Order of Operations . . . . . . . . . . . . . . . . . . . . . 9 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 9
7. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 10 7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10
8. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
We start with a thought experiment. We start with a thought experiment.
Imagine that you work on the operations team of a hosting company Imagine that you work on the operations team of a hosting company
that provides the "foo" service (or email or instant messaging or that provides the "foo" service (or email or instant messaging or
social networking service) for ten thousand different customer social networking service) for ten thousand different customer
organizations. Each customer wants their service to be identified by organizations. Each customer wants their service to be identified by
the customer's domain name (e.g., foo.example.com), not the hosting the customer's domain name (e.g., foo.example.com), not the hosting
skipping to change at page 3, line 28 skipping to change at page 3, line 27
o Customers won't obtain such certificates and then give them (plus o Customers won't obtain such certificates and then give them (plus
the associated private keys) to you because their legal department the associated private keys) to you because their legal department
is worried about liability. is worried about liability.
o You don't want to install such certificates (plus the associated o You don't want to install such certificates (plus the associated
private keys) on your servers anyway because your legal department private keys) on your servers anyway because your legal department
is worried about liability, too. is worried about liability, too.
Given your inability to deploy public keys / certificates containing Given your inability to deploy public keys / certificates containing
the right identifiers, your back-up approach was always to use a the right identifiers, your back-up approach has always been to use a
certificate containing hosting.example.net as the identifier. certificate containing hosting.example.net as the identifier.
However, more and more customers and end users are complaining about However, more and more customers and end users are complaining about
warning messages in user agents and the inherent security issues warning messages in user agents and the inherent security issues
involved with taking a "leap of faith" to accept the identity involved with taking a "leap of faith" to accept the identity
mismatch between the source domain (foo.example.com) and the mismatch between the source domain (foo.example.com) and the
delegated domain (hosting.example.net). delegated domain (hosting.example.net).
This situation is both insecure and unsustainable. You have This situation is both insecure and unsustainable. You have
investigated the possibility of using DNS Security [RFC4033] and DNS- investigated the possibility of using DNS Security [RFC4033] and DNS-
Based Authentication of Named Entities (DANE) [RFC6698] to solve the Based Authentication of Named Entities (DANE) [RFC6698] to solve the
problem. However, your customers and your operations team have told problem. However, your customers and your operations team have told
you that they will not be able to deploy DNSSEC and DANE for several you that it will be several years before they will be able to deploy
years at least. The product managers in your company are pushing you DNSSEC and DANE for all of your customers (because of tooling
to find a method that can be deployed more quickly to overcome the updates, slow deployment of DNSSEC at some top-level domains, etc.).
lack of proper server identity checking for your hosted customers. 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 is to ask each customer to provide the public One possible approach that your team has investigated is to ask each
key / certificate for the "foo" service at a special HTTPS URI on customer to provide the public key / certificate for the "foo"
their website ("https://foo.example.com/.well-known/posh.foo.json" is service at a special HTTPS URL on their website
one possibility). This could be a public key that you generate for ("https://foo.example.com/.well-known/posh.foo.json" is one
the customer, but because the customer hosts it via HTTPS, any user possibility). This could be a public key that you generate for the
agent can find that public key and check it against the public key customer, but because the customer hosts it via HTTPS, any user agent
you provide during TLS negotiation for the "foo" service (as one can find that public key and check it against the public key you
added benefit, the customer never needs to hand you a private key). 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 Alternatively, the customer can redirect requests for that special
HTTPS URI to an HTTPS URI at your own website, thus making it HTTPS URL to an HTTPS URL at your own website, thus making it
explicit that they have delegated the "foo" service to you. explicit that they have delegated the "foo" service to you.
The approach sketched out above, called POSH ("PKIX Over Secure The approach sketched out above, called POSH ("PKIX Over Secure
HTTP"), is explained in the remainder of this document. While this HTTP"), is explained in the remainder of this document. While this
approach is developed for use in the Extensible Messaging and approach was developed for use in the Extensible Messaging and
Presence Protocol (XMPP) as a prooftype for Domain Name Associations Presence Protocol (XMPP) as a prooftype for Domain Name Associations
(DNA) [XMPP-DNA], it can be applied to any non-HTTP application (DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP
protocol. application protocol.
2. Discussion Venue
The discussion venue for this document is the posh@ietf.org mailing
list; visit https://www.ietf.org/mailman/listinfo/posh for
subscription information and discussion archives.
3. Terminology 2. Terminology
This document inherits security terminology from [RFC5280]. The This document inherits security terminology from [RFC5280]. The
terms "source domain", "derived domain", "reference identifier", and terms "source domain", "derived domain", "reference identifier", and
"presented identifier" are used as defined in the "CertID" "presented identifier" are used as defined in the "CertID"
specification [RFC6125]. specification [RFC6125].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
4. Obtaining Verification Materials 3. Obtaining Verification Materials
Server identity checking (see [RFC6125]) involves three different Server identity checking (see [RFC6125]) involves three different
aspects: aspects:
1. A proof of the TLS server's identity (in PKIX, this takes the 1. A proof of the TLS server's identity (in PKIX, this takes the
form of a PKIX certificate [RFC5280]). form of a PKIX certificate [RFC5280]).
2. Rules for checking the certificate (which vary by application 2. Rules for checking the certificate (which vary by application
protocol, although [RFC6125] attempts to harmonize those rules). protocol, although [RFC6125] attempts to harmonize those rules).
skipping to change at page 5, line 13 skipping to change at page 5, line 5
form of chaining the end-entity certificate back to a trusted form of chaining the end-entity certificate back to a trusted
root and performing all validity checks as described in root and performing all validity checks as described in
[RFC5280], [RFC6125], and the relevant application protocol [RFC5280], [RFC6125], and the relevant application protocol
specification). specification).
When POSH is used, the first two aspects remain the same: the TLS When POSH is used, the first two aspects remain the same: the TLS
server proves it identity by presenting a PKIX certificate [RFC5280] server proves it identity by presenting a PKIX certificate [RFC5280]
and the certificate is checked according to the rules defined in the and the certificate is checked according to the rules defined in the
appropriate application protocol specification (such as [RFC6120] for appropriate application protocol specification (such as [RFC6120] for
XMPP). However, the TLS client obtains the materials it will use to XMPP). However, the TLS client obtains the materials it will use to
verify the server's proof by retrieving a JSON Web Key (JWK) set verify the server's proof by retrieving a JSON document [RFC7159]
[JOSE-JWK] over HTTPS ([RFC2616] and [RFC2818]) from a well-known URI containing hashes of the PKIX certificate over HTTPS ([RFC7230] and
[RFC5785]. [RFC2818]) from a well-known URI [RFC5785].
The process for retrieving a PKIX certificate over secure HTTP is as The process for retrieving a PKIX certificate over secure HTTP is as
follows. follows.
1. The TLS client performs an HTTPS GET at the source domain to the 1. The TLS client performs an HTTPS GET at the source domain to the
path "/.well-known/posh.{servicedesc}.json". The value of path "/.well-known/posh.{servicedesc}.json". The value of
"{servicedesc}" is application-specific; see Section 9 of this "{servicedesc}" is application-specific; see Section 8 of this
document for more details. For example, if the application document for more details. For example, if the application
protocol is some hypothetical "Foo" service, then "{servicedesc}" protocol is some hypothetical "Foo" service, then "{servicedesc}"
could be "foo"; thus if a Foo client were to use POSH to verify a could be "foo"; thus if a Foo client were to use POSH to verify a
Foo server for the domain "foo.example.com", the HTTPS GET Foo server for the domain "foo.example.com", the HTTPS GET
request would be as follows: request would be as follows:
GET /.well-known/posh.foo.json HTTP/1.1 GET /.well-known/posh.foo.json HTTP/1.1
Host: foo.example.com Host: foo.example.com
2. The source domain HTTPS server responds in one of three ways: 2. The source domain HTTPS server responds in one of three ways:
* If it possesses a PKIX certificate for the requested path, it * If it possesses PKIX certificate information for the requested
responds as detailed in Section 4.1. path, it responds as detailed in Section 3.1.
* If it has a reference to where the PKIX certificate can be * If it has a reference to where the PKIX certificate
obtained, it responds as detailed in Section 4.2. information can be obtained, it responds as detailed in
Section 3.2.
* If it does not have any PKIX certificate for the requested * If it does not have any PKIX certificate information or a
path, it responds with a client error status code (e.g., 404). reference to such information for the requested path, it
responds with an HTTP client error status code (e.g., 404).
4.1. Source Domain Possesses PKIX Certificate 3.1. Source Domain Possesses PKIX Certificate Information
If the source domain HTTPS server possesses the certificate If the source domain HTTPS server possesses the certificate
information, it responds to the HTTPS GET with a success status code information, it responds to the HTTPS GET with a success status code
and the message body set to a JSON Web Key (JWK) set [JOSE-JWK]. The and the message body set to a JSON document [RFC7159]; the document
JWK set MUST contain at least one JWK object, and MUST contain an is a JSON object which MUST have the following:
"expires" field whose value is the number of seconds after which the
TLS client ought to consider the key information to be stale (further
explained under Section 7).
Each included JWK object MUST possess the following information:
o The "kty" field set to the appropriate key type used for TLS
connections (e.g., "RSA" for a certificate using an RSA key).
o The required public parameters for the key type (e.g., "n" and "e" o A "fingerprints" field whose value is an array of fingerprint
for a certificate using an RSA key). descriptors.
o The "x5t" field set to the certificate thumbprint, as described in o An "expires" field whose value is the number of seconds after
section 3.6 of [JOSE-JWK]. which the TLS client ought to consider the key information to be
stale (further explained under Section 6).
Each JWK object MUST NOT possess the private parameters for the key Each included fingerprint descriptor is a JSON object, where each
type (e.g., "d", "p", "q" for a certificate using an RSA key). 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.
Each JWK object MAY possess other parameters as desired by The fingerprint hash for a given hash algorithm is generated by
application servers (e.g., the "x5c" field containing the entire performing the named hash function over the DER encoding of the PKIX
X.509 certificate chain, as per section 3.7 of [JOSE-JWK]). 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. The following example illustrates the usage described above.
Example Content Response Example Content Response
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/jwk-set+json Content-Type: application/json
Content-Length: 2785 Content-Length: 134
{ {
"keys": [ "fingerprints": [
{ {
"kty":"RSA", "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=",
"kid":"c8fb8b80-1193-11e3-b2b1-835742119fe8", "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ="
"n":"ANxwssdcU3LbODErec3owrwUhlzjtuskAn8rAcBMRPImn5xA
JRX-1T5g2D7MTozWWFk4TlpgzAR5slvM0tc35qAI9I0Cqk4Z
LChQrYsWuY7alTrnNXdusHUYc6Eq89DZaH2knTcp57wAXzJP
IG_tpBi5F7ck9LVRvRjybix0HJ7i4YrL-GeLuSgrjO4-GDcX
Ip8oV0FMKZH-NoMfUITlWYl_JcX1D0WUAiuAnvWtD4Kh_qMJ
U6FZuupZGHqPdc3vrXtp27LWgxzxjFa9qnOU6y53vCCJXLLI
5sy2fCwEDzLJqh2T6UItIzjrSUZMIsK8r2pXkroI0uYuNn3W
y-jAzK8",
"e":"AQAB",
"x5t":"UpjRI_A3afKE8_AIeTZ5o1dECTY"
} }
], ],
"expires": 604800 "expires": 604800
} }
The "expires" value is a hint regarding the expiration of the keying The "expires" value is a hint regarding the expiration of the keying
materials. If no "expires" field is included, a TLS client SHOULD materials. If no "expires" field is included, a TLS client SHOULD
consider these verification materials invalid. See Section 7 for how consider these verification materials invalid. See Section 6 for how
to reconcile this "expires" field with the reference's "expires" to reconcile this "expires" field with the reference's "expires"
field. field.
4.2. Source Domain References PKIX Certificate 3.2. Source Domain References PKIX Certificate
If the source domain HTTPS server has a reference to the certificate If the source domain HTTPS server has a reference to the certificate
information, it responds to the HTTPS GET with a JSON document. The information, it responds to the HTTPS GET with a success status code
document MUST contain a "url" field whose value is the HTTPS URL and message body set to a JSON document. The document is a JSON
where TLS clients can obtain the actual JWK set, and MUST contain an object which MUST contain the following:
"expires" field whose value is the number of seconds after which the
TLS client ought to consider the delegation to be stale (further o A "url" field whose value is the HTTPS URL where TLS clients can
explained under Section 7). obtain the actual certificate information.
o An "expires" field whose value is the number of seconds after
which the TLS client ought to consider the delegation to be stale
(further explained under Section 6).
Example Reference Response Example Reference Response
HTTP/1.1 200 Ok HTTP/1.1 200 Ok
Content-Type: application/json Content-Type: application/json
Content-Length: 78 Content-Length: 79
{ {
"url":"https://hosting.example.net/.well-known/posh.foo.json", "url":"https://hosting.example.net/.well-known/posh.foo.json",
"expires":86400 "expires":86400
} }
The client performs an HTTPS GET for the URL specified in the "url" The client performs an HTTPS GET for the URL specified in the "url"
field value. The HTTPS server for the URI to which the client has field value. The HTTPS server for the URL to which the client has
been redirected responds to the request with a JWK set. The content 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 retrieved from the "url" location MUST NOT itself be a reference
(i.e., containing a "url" fields instead of a "keys" field), in order (i.e., containing a "url" field instead of a "fingerprints" field),
to prevent circular delegations. in order to prevent circular delegations.
Note: The JSON document returned by the source domain HTTPS server Note: The JSON document returned by the source domain HTTPS server
MUST contain either a reference or a JWK-set, but MUST NOT contain MUST contain either a reference or a fingerprints document, but
both. MUST NOT contain both.
Note: See Section 10 for discussion about HTTPS redirects. Note: See Section 9 for discussion about HTTPS redirects.
The "expires" value is a hint regarding the expiration of the source The "expires" value is a hint regarding the expiration of the source
domain's delegation of service to the delegated domain. If no domain's delegation of service to the delegated domain. If no
"expires" field is included, a TLS client SHOULD consider the "expires" field is included, a TLS client SHOULD consider the
delegation invalid. See Section 7 for guidelines about reconciling delegation invalid. See Section 6 for guidelines about reconciling
this "expires" field with the JWK-set's "expires" field. this "expires" field with the "expires" field of the fingerprints
document.
4.3. Performing Verification 3.3. Performing Verification
The TLS client compares the PKIX information obtained from the TLS The TLS client compares the PKIX information obtained from the TLS
server against each JWK object in the POSH results, until a match is server against each fingerprint descriptor object in the POSH
found or the collection of POSH verification materials is exhausted. results, until a match is found or the collection of POSH
If none of the JWK objects match the TLS server PKIX information, the verification materials is exhausted. If none of the fingerprint
TLS client SHOULD reject the connection (the TLS client might still descriptor objects match the TLS server PKIX information, the TLS
accept the connection if other verification schemes are successful). client SHOULD reject the connection (however, the TLS client might
still accept the connection if other verification schemes are
The TLS client SHOULD compare the fingerprint of the PKIX certificate successful).
from the TLS server against the "x5t" field of the JWK object (note
the "x5t" field is the base64url encoding of the fingerprint).
The TLS client MAY verify the certificate chain provided in the "x5c"
field of the JWK object (if present), but it MUST NOT implicitly
consider the final certificate in the "x5c" field to be a trust
anchor itself; the TLS client only uses the end entity certificate
information for verification.
5. Secure Delegation 4. Secure Delegation
The delegation from the source domain to the delegated domain can be The delegation from the source domain to the delegated domain can be
considered secure if the certificate offered by the TLS server considered secure if the certificate offered by the TLS server
matches the POSH certificate, regardless of how the POSH certificates matches the POSH certificate, regardless of how the POSH certificate
are obtained. is obtained.
6. Order of Operations 5. Order of Operations
In order for the TLS client to perform verification of reference In order for the TLS client to perform verification of reference
identifiers without potentially compromising data, POSH processes identifiers without potentially compromising data, POSH processes
MUST be complete before any application-level data is exchanged for MUST be complete before any application-level data is exchanged for
the source domain. The TLS client SHOULD perform all POSH retrievals the source domain. The TLS client SHOULD perform all POSH retrievals
before opening any socket connections to the application protocol before opening any socket connections to the application protocol
server. For application protocols that use DNS SRV, the POSH server. For application protocols that use DNS SRV (including
processes ideally ought to be done in parallel with resolving the SRV queries for TLSA records in concert with SRV records as described in
records and the addresses of any targets, similar to the "happy [I-D.ietf-dane-srv]), the POSH processes ideally ought to be done in
eyeballs" approach for IPv4 and IPv6 [RFC6555]. 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: The following diagram illustrates the possession flow:
Client Domain Server Client Domain Server
------ ------ ------ ------ ------ ------
| | | | | |
| Request POSH | | | Request POSH | |
|--------------------->| | |------------------------->| |
| | | | | |
| Return POSH keys | | | Return POSH fingerprints | |
|<---------------------| | |<-------------------------| |
| | | | | |
| Service TLS Handshake | | Service TLS Handshake |
|<===========================================>| |<===================================================>|
| | | | | |
| Service Data | | Service Data |
|<===========================================>| |<===================================================>|
| | | | | |
Figure 1: Order of Events for Possession Flow
While the following diagram illustrates the reference flow: While the following diagram illustrates the reference flow:
Client Domain Server Client Domain Server
------ ------ ------ ------ ------ ------
| | | | | |
| Request POSH | | | Request POSH | |
|--------------------->| | |------------------------->| |
| | | | | |
| Return POSH url | | | Return POSH url | |
|<---------------------| | |<-------------------------| |
| | | | | |
| Request POSH | | Request POSH |
|-------------------------------------------->| |---------------------------------------------------->|
| | | | | |
| Return POSH keys | | Return POSH fingerprints |
|<--------------------------------------------| |<----------------------------------------------------|
| | | | | |
| Service TLS Handshake | | Service TLS Handshake |
|<===========================================>| |<===================================================>|
| | | | | |
| Service Data | | Service Data |
|<===========================================>| |<===================================================>|
| | | | | |
7. Caching Results Figure 2: Order of Events for Reference Flow
The TLS client MUST NOT cache results (reference or JWK-set) 6. Caching Results
The TLS client MUST NOT cache results (reference or fingerprints)
indefinitely. If the source domain returns a reference, the TLS indefinitely. If the source domain returns a reference, the TLS
client MUST use the lower of the two "expires" values when client MUST use the lower of the two "expires" values when
determining how long to cache results (i.e., if the reference determining how long to cache results (i.e., if the reference
"expires" value is lower than the JWK-set "expires" value, honor the "expires" value is lower than the fingerprints "expires" value, honor
reference "expires" value). Once the TLS client considers the the reference "expires" value). Once the TLS client considers the
results stale, it SHOULD perform the entire POSH process again results stale, it needs to perform the entire POSH process again
starting with the HTTPS GET to the source domain. The TLS client MAY starting with the HTTPS GET to the source domain. The TLS client MAY
use a lower value than any provided in the "expires" field(s), or not use a lower value than any provided in the "expires" field(s), or not
cache results at all. cache results at all.
The TLS client SHOULD NOT rely on HTTP caching mechanisms, instead The TLS client SHOULD NOT rely on HTTP caching mechanisms, instead
using the expiration hints provided in the POSH reference or JWK-set using the expiration hints provided in the POSH reference document or
documents. To that end, the HTTPS servers for source and derived fingerprints documents. To that end, the HTTPS servers for source
domains SHOULD specify a 'Cache-Control' header indicating a very domains and derived domains SHOULD specify a 'Cache-Control' header
short duration (e.g., max-age=60) or "no-cache" to indicate that the indicating a very short duration (e.g., max-age=60) or "no-cache" to
response (redirect, reference, or content) is not appropriate to indicate that the response (redirect, reference, or content) is not
cache at the HTTP level. appropriate to cache at the HTTP level.
8. Alternates and Roll-over 7. Alternates and Roll-over
To indicate alternate PKIX certificates (such as when an existing To indicate alternate PKIX certificates (such as when an existing
certificate will soon expire), the returned JWK set MAY contain certificate will soon expire), the returned fingerprints document MAY
multiple JWK objects. The JWK set SHOULD be ordered with the most contain multiple fingerprint descriptors. The fingerprints SHOULD be
relevant certificate first as determined by the application service ordered with the most relevant certificate first as determined by the
operator (e.g., the renewed certificate), followed by the next most application service operator (e.g., the renewed certificate),
relevant certificate (e.g., the certificate soonest to expire). Here followed by the next most relevant certificate (e.g., the certificate
is an example: soonest to expire). Here is an example:
{ {
"keys":[ "fingerprints": [
{ {
"kty": "RSA", "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=",
"kid": "cfc0ca70-1193-11e3-b2b1-835742119fe8", "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ"
"n": "AM-ktWkQ8btj_HEdAA6kOpzJGgoHNZsJmxjh_PifpgAUfQeq
MO_YBR100IdJZRzJfULyhRwn9bikCq87WToxgPWOnd3sH3qT
YiAcIR5S6tBbsyp6WYmwM1yuC0vLCo6SoDzdK1SvkQKM3QWk
0GFNU4l4qXYAMxaSw83i6yv5DBVbST7E92vS6Gq_4pgI26l1
0JhybZuTEVPRUCG6pTKAXQpLxmjJ5oG9M91RP17nsuQeE7Ng
0Ap4BBn5hocojkfthwgbX4lqBMecpBAnky5jn6slmzS_rL-L
w-_8hUldaTPD9MHlHPrvcsRV5uw8wK5MB6QyfS6wF4b0Kj2T
vYceNlE",
"e": "AQAB",
"x5t": "Ae0sLVtm78VT-mQXJQop-ENOM6o"
}, },
{ {
"kty": "RSA", "sha-1":"T29tGO9d7kxbfWnUaac8+5+ICLM=",
"kid": "dbc28570-1193-11e3-b2b1-835742119fe8", "sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="
"n": "AM-ktWkQ8btj_HEdAA6kOpzJGgoHNZsJmxjh_PifpgAUfQeq
MO_YBR100IdJZRzJfULyhRwn9bikCq87WToxgPWOnd3sH3qT
YiAcIR5S6tBbsyp6WYmwM1yuC0vLCo6SoDzdK1SvkQKM3QWk
0GFNU4l4qXYAMxaSw83i6yv5DBVbST7E92vS6Gq_4pgI26l1
0JhybZuTEVPRUCG6pTKAXQpLxmjJ5oG9M91RP17nsuQeE7Ng
0Ap4BBn5hocojkfthwgbX4lqBMecpBAnky5jn6slmzS_rL-L
w-_8hUldaTPD9MHlHPrvcsRV5uw8wK5MB6QyfS6wF4b0Kj2T
vYceNlE",
"e": "AQAB",
"x5t": "lYZC2n9TBpOaUsBclEIacQTKToA"
} }
] ],
"expires": 806400
} }
9. IANA Considerations 8. IANA Considerations
This document registers a well-known URI [RFC5785] for protocols that This document registers a well-known URI [RFC5785] for protocols that
use POSH. The completed template follows. use POSH. The completed template follows.
URI suffix: posh. URI suffix: posh.
Change controller: IETF Change controller: IETF
Specification document: [[ this document ]] Specification document: [[ this document ]]
skipping to change at page 12, line 27 skipping to change at page 11, line 5
prefix, protocols that use POSH need to register particular prefix, protocols that use POSH need to register particular
URIs that are prefixed with the "posh." string. URIs that are prefixed with the "posh." string.
Note that the registered URI is "posh." (with a trailing dot). This 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 is merely a prefix to be placed at the front of well-known URIs
[RFC5785] registered by protocols that use POSH, which themselves are [RFC5785] registered by protocols that use POSH, which themselves are
responsible for the relevant registrations with the IANA. The URIs responsible for the relevant registrations with the IANA. The URIs
registered by such protocols SHOULD match the URI template [RFC6570] registered by such protocols SHOULD match the URI template [RFC6570]
path "/.well-known/posh.{servicedesc}.json"; that is, begin with path "/.well-known/posh.{servicedesc}.json"; that is, begin with
"posh." and end with ".json" (indicating a media type of application/ "posh." and end with ".json" (indicating a media type of application/
json [RFC4627] or application/jwk-set+json [JOSE-JWK]). json [RFC7159]).
For POSH-using protocols that rely on DNS SRV records [RFC2782], the For POSH-using protocols that rely on DNS SRV records [RFC2782], the
"{servicedesc}" part of the well-known URI SHOULD be "{servicedesc}" part of the well-known URI SHOULD be
"{service}.{proto}", where the "{service}" is the DNS SRV "Service" "{service}.{proto}", where the "{service}" is the DNS SRV "Service"
prepended by the underscore character "_" and the "{proto}" is the prepended by the underscore character "_" and the "{proto}" is the
DNS SRV "Proto" also prepended by the underscore character "_". As DNS SRV "Proto" also prepended by the underscore character "_". As
an example, the well-known URI for XMPP server-to-server connections an example, the well-known URI for XMPP server-to-server connections
would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers
a service name of "xmpp-server" and uses TCP as the underlying a service name of "xmpp-server" and uses TCP as the underlying
transport protocol. transport protocol.
skipping to change at page 12, line 49 skipping to change at page 11, line 27
For other POSH-using protocols, the "{servicedesc}" part of the well- For other POSH-using protocols, the "{servicedesc}" part of the well-
known URI can be any unique string or identifier for the protocol, known URI can be any unique string or identifier for the protocol,
which might be a service name registered with the IANA in accordance which might be a service name registered with the IANA in accordance
with [RFC6335] or which might be an unregistered name. As an with [RFC6335] or which might be an unregistered name. As an
example, the well-known URI for the mythical "Foo" service could be example, the well-known URI for the mythical "Foo" service could be
"posh.foo.json". "posh.foo.json".
Note: As explained in [RFC5785], the IANA registration policy Note: As explained in [RFC5785], the IANA registration policy
[RFC5226] for well-known URIs is Specification Required. [RFC5226] for well-known URIs is Specification Required.
10. Security Considerations 9. Security Considerations
This document supplements but does not supersede the security This document supplements but does not supersede the security
considerations provided in specifications for application protocols considerations provided in specifications for application protocols
that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP).
Specifically, the security of requests and responses sent via HTTPS Specifically, the security of requests and responses sent via HTTPS
depends on checking the identity of the HTTP server in accordance depends on checking the identity of the HTTP server in accordance
with [RFC2818]. Additionally, the security of POSH can benefit from with [RFC2818]. Additionally, the security of POSH can benefit from
other HTTP hardening protocols, such as HSTS [RFC6797] and key other HTTP hardening protocols, such as HSTS [RFC6797] and key
pinning [KEYPIN], especially if the TLS client shares some pinning [I-D.ietf-websec-key-pinning], especially if the TLS client
information with a common HTTPS implementation (e.g., platform- shares some information with a common HTTPS implementation (e.g.,
default web browser). platform-default web browser).
Note well that POSH is used by a TLS client to obtain the public key Note well that POSH is used by a TLS client to obtain the public key
of a TLS server to which it might connect for a particular of a TLS server to which it might connect for a particular
application protocol such as IMAP or XMPP. POSH does not enable a application protocol such as IMAP or XMPP. POSH does not enable a
hosted domain to transfer private keys to a hosting service via hosted domain to transfer private keys to a hosting service via
HTTPS. POSH also does not enable a TLS server to engage in HTTPS. POSH also does not enable a TLS server to engage in
certificate enrollment with a certification authority via HTTPS, as certificate enrollment with a certification authority via HTTPS, as
is done in Enrollment over Secure Transport [RFC7030]. is done in Enrollment over Secure Transport [RFC7030].
A web server at the source domain might redirect an HTTPS request to A web server at the source domain might redirect an HTTPS request to
another URL. The location provided in the redirect response MUST another URL. The location provided in the redirect response MUST
specify an HTTPS URL. Source domains SHOULD use only temporary specify an HTTPS URL. Source domains SHOULD use only temporary
redirect mechanisms, such as HTTP status codes 302 (Found) and 307 redirect mechanisms, such as HTTP status codes 302 (Found) and 307
(Temporary Redirect). Clients MAY treat any redirect as temporary, (Temporary Redirect). Clients MAY treat any redirect as temporary,
ignoring the specific semantics for 301 (Moved Permanently) and 308 ignoring the specific semantics for 301 (Moved Permanently) and 308
(Permanent Redirect) [HTTP-STATUS-308]. To protect against circular (Permanent Redirect) [RFC7238]. To protect against circular
references, clients MUST NOT follow an infinite number of redirects. references, clients MUST NOT follow an infinite number of redirects.
It is RECOMMENDED that clients follow no more than 10 redirects, It is RECOMMENDED that clients follow no more than 10 redirects,
although applications or implementations can require that fewer although applications or implementations can require that fewer
redirects be followed. redirects be followed.
11. References 10. References
11.1. Normative References
[JOSE-JWK] 10.1. Normative References
Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key-20 (work in progress), January 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
JavaScript Object Notation (JSON)", RFC 4627, July 2006. Encodings", RFC 4648, October 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, April Uniform Resource Identifiers (URIs)", RFC 5785, April
2010. 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
11.2. Informative References [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[HTTP-STATUS-308] [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
Reschke, J., "The Hypertext Transfer Protocol (HTTP) (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
Status Code 308 (Permanent Redirect)", draft-reschke-http- 2014.
status-308-07 (work in progress), March 2012.
[KEYPIN] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 10.2. Informative References
Extension for HTTP", draft-ietf-websec-key-pinning-09
(work in progress), November 2013.
[XMPP-DNA] [I-D.ietf-dane-srv]
Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Based Authentication of Named Entities (DANE) TLSA Records
with SRV Records", draft-ietf-dane-srv-06 (work in
progress), June 2014.
[I-D.ietf-websec-key-pinning]
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", draft-ietf-websec-key-pinning-14
(work in progress), June 2014.
[I-D.ietf-xmpp-dna]
Saint-Andre, P. and M. Miller, "Domain Name Associations Saint-Andre, P. and M. Miller, "Domain Name Associations
(DNA) in the Extensible Messaging and Presence Protocol (DNA) in the Extensible Messaging and Presence Protocol
(XMPP)", draft-ietf-xmpp-dna-05 (work in progress), (XMPP)", draft-ietf-xmpp-dna-05 (work in progress),
February 2014. February 2014.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, May 2005. 4033, March 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
skipping to change at page 15, line 28 skipping to change at page 14, line 9
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, March 2012. and D. Orchard, "URI Template", RFC 6570, March 2012.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTPS Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, November 2012.
[RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over
Secure Transport", RFC 7030, October 2013. Secure Transport", RFC 7030, October 2013.
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7238, June 2014.
[HASH-NAMES]
"Hash Function Textual Names", <http://www.iana.org/
assignments/hash-function-text-names/
hash-function-text-names.xhtml>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Many thanks to Philipp Hancke, Joe Hildebrand, and Tobias Markmann Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and
for their implementation feedback. Thanks also to Dave Cridland, Tobias Markmann for their implementation feedback. Thanks also to
Chris Newton, Max Pritikin, and Joe Salowey for their input on the Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their
specification. input on the specification.
Authors' Addresses Authors' Addresses
Matthew Miller Matthew Miller
Cisco Systems, Inc. Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600 1899 Wynkoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Email: mamille2@cisco.com Email: mamille2@cisco.com
skipping to change at page 16, line 4 skipping to change at page 14, line 39
Authors' Addresses Authors' Addresses
Matthew Miller Matthew Miller
Cisco Systems, Inc. Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600 1899 Wynkoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Email: mamille2@cisco.com Email: mamille2@cisco.com
Peter Saint-Andre Peter Saint-Andre
&yet &yet
P.O. Box 787
Parker, CO 80134
USA
Email: ietf@stpeter.im Email: peter@andyet.com
 End of changes. 77 change blocks. 
250 lines changed or deleted 239 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/