One document matched: draft-ietf-xmpp-posh-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2782 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY rfc2818 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY rfc4033 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4648 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY rfc5226 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc5246 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5280 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc5785 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!ENTITY rfc6120 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml">
<!ENTITY rfc6125 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY rfc6335 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY rfc6555 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6555.xml">
<!ENTITY rfc6698 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY rfc6797 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6797.xml">
<!ENTITY rfc7030 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml">
<!ENTITY rfc7159 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7159.xml">
<!ENTITY rfc7230 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY rfc7231 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml">
<!ENTITY rfc7469 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7469.xml">
<!ENTITY rfc7525 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml">
<!ENTITY rfc7538 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7538.xml">
]>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<rfc category="std" docName="draft-ietf-xmpp-posh-05" ipr="trust200902">
<front>
<title abbrev="POSH">PKIX over Secure HTTP (POSH)</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>mamille2@cisco.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>&yet</organization>
<address>
<email>peter@andyet.com</email>
<uri>https://andyet.com/</uri>
</address>
</author>
<date/>
<area>RAI</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>federation</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>We begin with a thought experiment.</t>
<t>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).</t>
<t>In order to properly secure each customer's SPICE instance via Transport Layer Security (TLS) <xref target='RFC5246'/>, you need to obtain and deploy PKIX certificates <xref target='RFC5280'/> containing identifiers such as bar.example.com, as explained in the "CertID" specification <xref target='RFC6125'/>. Unfortunately, you can't obtain and deploy such certificates because:</t>
<t>
<list style='symbols'>
<t>Certification authorities won't issue such certificates to you because you work for the hosting company, not the customer organization.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>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) <xref target='RFC6125'/>.</t>
<t>This situation is both insecure and unsustainable. You have investigated the possibility of using DNS Security <xref target="RFC4033"/> and DNS-Based Authentication of Named Entities (DANE) <xref target="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.</t>
<t>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.</t>
<t>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) <xref target="I-D.ietf-xmpp-dna"/>, it can be applied to any non-HTTP application protocol.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits security terminology from <xref target="RFC5280"/>. The terms "Source Domain", "Delegated Domain", "Derived Domain", and "Reference Identifier" are used as defined in the "CertID" specification <xref target="RFC6125"/>.</t>
<t>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 <xref target="RFC2119"/>.</t>
<t>Additionally, this document uses the following terms:
<list style="hanging">
<t hangText="POSH client:">A client that uses the application service and that uses POSH to obtain material for verifying the service's identity.</t>
<t hangText="POSH server:">A server that hosts the application service and that uses POSH to provide material for verifying its identity.</t>
</list>
</t>
</section>
<section title="Obtaining Verification Material" anchor="obtain">
<t>Server identity checking (see <xref target='RFC6125'/>) involves three different aspects:</t>
<t>
<list style='numbers'>
<t>A proof of the POSH server's identity (in PKIX, this takes the form of a PKIX end-entity certificate <xref target='RFC5280'/>).</t>
<t>Rules for checking the certificate (which vary by application protocol, although <xref target='RFC6125'/> attempts to harmonize those rules).</t>
<t>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 <xref target='RFC5280'/>, <xref target='RFC6125'/>, and the relevant application protocol specification).</t>
</list>
</t>
<t>When POSH is used, the first two aspects remain the same: the POSH server proves its identity by presenting a PKIX certificate <xref target="RFC5280"/> and the certificate is checked according to the rules defined in the appropriate application protocol specification (such as <xref target="RFC6120"/> for XMPP). However, the POSH client obtains the material it will use to verify the server's proof by retrieving a JSON document <xref target='RFC7159'/> containing hashes of the PKIX certificate over HTTPS (<xref target="RFC7230"/> and <xref target="RFC2818"/>) from a well-known URI <xref target="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 <xref target='RFC2818'/> apply to this "bootstrapping" step to provide a secure basis for all subsequent POSH operations.</t>
<t>A PKIX certificate is retrieved over secure HTTP in the following way.</t>
<t>
<list style="numbers">
<t>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 <xref target="authors"/> 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:
<figure>
<artwork><![CDATA[
GET /.well-known/posh/spice.json HTTP/1.1
Host: bar.example.com
]]></artwork>
</figure>
</t>
<t>The Source Domain HTTPS server responds in one of three ways:
<list style="symbols">
<t>If it possesses PKIX certificate information for the requested path, it responds as detailed in <xref target="prooftype-possess"/>.</t>
<t>If it has a reference to where the PKIX certificate information can be obtained, it responds as detailed in <xref target="prooftype-ref"/>.</t>
<t>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 <xref target='RFC7231'/>.</t>
</list>
</t>
</list>
</t>
<section title="Source Domain Possesses PKIX Certificate Information" anchor="prooftype-possess">
<t>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 <xref target='RFC7159'/>; the document is "fingerprints document", i.e., a JSON object with the following members:</t>
<t>
<list style="symbols">
<t>A "fingerprints" member whose value is a JSON array of fingerprint descriptors (the member MUST include at least one fingerprint descriptor).</t>
<t>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 <xref target='caching'/>).</t>
</list>
</t>
<t>The JSON document returned MUST NOT contain a "url" member as described in <xref target='prooftype-ref'/>.</t>
<t>Each included fingerprint descriptor is a JSON object, where each member name is the textual name of a hash function (as listed in <xref target='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 <xref target='RFC4648'/> and where the padding bits are set to zero).</t>
<t>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.)</t>
<t>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.</t>
<t>
<figure>
<preamble>Example Fingerprints Response</preamble>
<artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 135
{
"fingerprints": [
{
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ="
}
],
"expires": 604800
}
]]></artwork>
</figure>
</t>
<t>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 <xref target='caching'/> for how to reconcile this "expires" member with the reference's "expires" member.</t>
<t>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:</t>
<figure>
<artwork><![CDATA[
{
"fingerprints": [
{
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ"
},
{
"sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="
}
],
"expires": 806400
}
]]></artwork>
</figure>
<t>Matching on any of these fingerprints is acceptable.</t>
<t>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.</t>
</section>
<section title="Source Domain References PKIX Certificate" anchor="prooftype-ref">
<t>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:</t>
<t>
<list style='symbols'>
<t>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 <xref target='authors'/>, but it need not be. (For historical reasons, the member name is "url", not "uri".)</t>
<t>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 <xref target='caching'/>).</t>
</list>
</t>
<t>
<figure>
<preamble>Example Reference Response</preamble>
<artwork><![CDATA[
HTTP/1.1 200 Ok
Content-Type: application/json
Content-Length: 82
{
"url":"https://hosting.example.net/.well-known/posh/spice.json",
"expires":86400
}
]]></artwork>
</figure>
</t>
<t>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 <xref target='prooftype-possess'/>. 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.</t>
<t><list style='empty'><t>Note: See <xref target='security'/> for discussion about HTTPS redirects.</t></list></t>
<t>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 <xref target='caching'/> for guidelines about reconciling this "expires" member with the "expires" member of the fingerprints document.</t>
</section>
<section title="Performing Verification" anchor="prooftype-verify">
<t>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 <xref target='RFC6698'/>).</t>
</section>
</section>
<section title="Secure Delegation" anchor="delegation">
<t>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.</t>
</section>
<section title="Order of Operations" anchor="order">
<t>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 <xref target='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 <xref target='RFC6555'/>.</t>
<t>The following diagram illustrates the possession flow:</t>
<t>
<figure anchor='figure-1' title='Order of Events for Possession Flow'>
<artwork><![CDATA[
POSH Source POSH
Client Domain Server
------ ------ ------
| | |
| POSH Request | |
|------------------------->| |
| | |
| Return POSH fingerprints | |
|<-------------------------| |
| |
| Service TLS Handshake |
|<===================================================>|
| |
| Service Data |
|<===================================================>|
| |
]]></artwork>
</figure>
</t>
<t>While the following diagram illustrates the reference flow:</t>
<t>
<figure anchor='figure-2' title='Order of Events for Reference Flow'>
<artwork><![CDATA[
POSH Source Delegated POSH
Client Domain Domain Server
------ ------ ------ ------
| | | |
| POSH Request | | |
|----------------->| | |
| | | |
| Return POSH url | | |
|<-----------------| | |
| | |
| POSH Request | |
|-------------------------------->| |
| | |
| Return POSH fingerprints | |
|<--------------------------------| |
| |
| Service TLS Handshake |
|<===================================================>|
| |
| Service Data |
|<===================================================>|
| |
]]></artwork>
</figure>
</t>
</section>
<section title="Caching Results" anchor="caching">
<t>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 operation 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" member(s), or not cache results at all.</t>
<t>The foregoing considerations apply to handling of the "expires" values in POSH documents; naturally a POSH client MUST NOT consider an expired PKIX certificate to be valid, in accordance with <xref target='RFC5280'/>.</t>
<t>The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead using the expiration hints provided in the POSH reference document or fingerprints document. 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 fingerprints) is not appropriate to cache at the HTTP layer.</t>
</section>
<section title="Guidance for Server Operators" anchor="operators">
<t>POSH is intended to ease the operational burden of securing application services, especially in multi-tenant environments. It does so by obviating the need to obtain certificates for hosted domains, so that an operator can obtain a certificate only for its hosting service (naturally, this certificate needs to be valid according to <xref target='RFC5280'/> and contain the proper identifier(s) in accordance with <xref target='RFC6125'/> and the relevant application protocol specification).</t>
<t>However, in order to use POSH, an operator does need to coordinate with its customers so that the appropriate POSH documents are provided via HTTPS at a well-known URI at each customer's domain (i.e., at the Source Domain), thus ensuring delegation to the operator's hosting service (i.e., the Delegated Domain). Because correct hosting of the POSH document at the Source Domain is essential for successful functioning of the POSH "chain", errors at the Source Domain will result in authentication problems, certificate warnings, and other operational issues.</t>
<t>Furthermore, if the POSH document is a reference document instead of a fingerprints document, the operational burden is further decreased because the operator does not need to provision its customers with updated POSH documents when the certificate for the Delegated Domain expires or is replaced.</t>
</section>
<section title="Guidance for Protocol Authors" anchor="authors">
<t>Protocols that use POSH are expected to register with the POSH Service Names registry defined under <xref target='iana-posh'/>.</t>
<t>For POSH-using protocols that rely on DNS SRV records <xref target='RFC2782'/>, the service name SHOULD be same as the DNS SRV "Service". As an example, the POSH service name for XMPP server-to-server connections would be "xmpp-server" because <xref target='RFC6120'/> registers a DNS SRV "Service" of "xmpp-server". One example of the resulting well-known URI would be "https://example.com/.well-known/posh/xmpp-server.json".</t>
<t>For other POSH-using protocols, the service name MAY any unique string or identifier for the protocol, which might be a service name registered with the IANA in accordance with <xref target='RFC6335'/> or which might be an unregistered name. As an example, the well-known URI for the hypothetical SPICE application might be "spice".</t>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="Well-Known URI" anchor="iana-wellknown">
<t>The IANA is requested to register "posh" in the Well-Known URI Registry as defined by <xref target='RFC5785'/>. The completed template follows.</t>
<t>
<list style='hanging'>
<t hangText='URI suffix:'>posh</t>
<t hangText='Change controller:'>IETF</t>
<t hangText='Specification:'>[[ this document ]]</t>
<t hangText='Related information:'>The suffix "posh" is expected to be followed by an additional path component consisting of a service name (say, "spice") and a file extension of ".json", resulting in a full path of, for instance, "/.well-known/posh/spice.json". Registration of service names shall be requested by developers of the relevant application protocols.</t>
</list>
</t>
</section>
<section title="POSH Service Names" anchor="iana-posh">
<t>The IANA is requested to establish a registry for POSH service names within the Uniform Resource Identifier (URI) Schemes group of registries.</t>
<t>The IANA registration policy <xref target='RFC5226'/> is Expert Review or IETF Review (this was chosen instead of the more liberal policy of First Come First Served to help ensure that POSH serices are defined in ways that are consistent with this specification). One or more Designated Experts are to be appointed by the IESG or their delegate.</t>
<t>Registration requests are to be sent to the posh@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for POSH service name: example").</t>
<t>Before a period of 14 days has passed, the Designated Expert(s) will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@iesg.org mailing list) for resolution.</t>
<section title="Registration Template" anchor="iana-posh-template">
<t>
<list style='hanging'>
<t hangText='Service name:'>The name requested, relative to "/.well-known/posh/"; e.g., a service name of "example" would result in a well-known URI such as "https://example.com/.well-known/posh/example.json".</t>
<t hangText='Change controller:'>For Standards-Track RFCs, state "IETF". In all other cases, provide the name and email address of the responsible party. Other details (e.g., postal address or website URI) may also be included.</t>
<t hangText='Definition and usage:'>A brief description that defines the service name and mentions where and how it is used (e.g., in the context of a particular application protocol).</t>
<t hangText='Specification:'>Optionally, reference to a document that specifies the service or application protocol that uses the service name, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required.</t>
</list>
</t>
</section>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>This document supplements but does not supersede the security considerations provided in specifications for application protocols that decide to use POSH (e.g., <xref target="RFC6120"/> and <xref target="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 <xref target="RFC2818"/> as well as following the most modern best practices for TLS as specified in <xref target='RFC7525'/>. Additionally, the security of POSH can benefit from other HTTP hardening protocols, such as HSTS <xref target="RFC6797"/> and key pinning <xref target="RFC7469"/>, especially if the POSH client shares some information with a common HTTPS implementation (e.g., platform-default web browser).</t>
<t>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 <xref target='RFC7030'/>.</t>
<t>A web server at the Source Domain might redirect an HTTPS request to another HTTPS URI. The location provided in the redirect response MUST specify an HTTPS URI. Source domains SHOULD use only temporary redirect mechanisms, such as HTTP status codes 302 (Found) and 307 (Temporary Redirect) <xref target='RFC7231'/>. Clients MAY treat any redirect as temporary, ignoring the specific semantics for 301 (Moved Permanently) <xref target='RFC7231'/> and 308 (Permanent Redirect) <xref target='RFC7538'/>. To protect against circular references, it is RECOMMENDED that POSH clients follow no more than 10 redirects, although applications or implementations can require that fewer redirects be followed.</t>
<t>Hash function agility is an important quality to ensure secure operations in the face of attacks against the fingerprints obtained within verification material. Because POSH verification material is 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 documents if the hash functions are found to be subject to realistic attacks.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2818;
&rfc4648;
&rfc5246;
&rfc5280;
&rfc5785;
&rfc6125;
&rfc7159;
&rfc7230;
&rfc7231;
&rfc7525;
</references>
<references title="Informative References">
<reference anchor='I-D.ietf-dane-srv'>
<front>
<title>Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records</title>
<author initials='T' surname='Finch' fullname='Tony Finch'>
<organization />
</author>
<author initials='M' surname='Miller' fullname='Matthew Miller'>
<organization />
</author>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='April' day='23' year='2015' />
<abstract><t>The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dane-srv-14' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dane-srv-14.txt' />
</reference>
<reference anchor='I-D.ietf-xmpp-dna'>
<front>
<title>Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<author initials='M' surname='Miller' fullname='Matthew Miller'>
<organization />
</author>
<author initials='P' surname='Hancke' fullname='Philipp Hancke'>
<organization />
</author>
<date month='March' day='24' year='2015' />
<abstract><t>This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server host name (e.g., hosting.example.net), which is especially important in multi-tenant environments where the same target server hosts a large number of domains.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-dna-10' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-dna-10.txt' />
</reference>
&rfc2782;
&rfc4033;
&rfc5226;
&rfc6120;
&rfc6335;
&rfc6555;
&rfc6698;
&rfc6797;
&rfc7030;
&rfc7469;
&rfc7538;
<reference anchor='HASH-NAMES' target='http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml'>
<front>
<title>Hash Function Textual Names</title>
<author/>
<date/>
</front>
</reference>
</references>
<section title="Acknowledgements" anchor="acks">
<t>Thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias Markmann for their implementation feedback, and to Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their input on the specification.</t>
<t>During IESG review, Stephen Farrell, Barry Leiba, and Kathleen Moriarty provided helpful input that resulted in improvements in the document.</t>
<t>Thanks also to Dave Cridland as document shepherd, Joe Hildebrand as working group chair, and Ben Campbell as area director.</t>
<t>Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:27 |