Secure Service Delegation

Today many organization out source services such as XMPP to third party providers. In theory there are many ways to security do this but in practice the actually deployments introduce many constraints of what is easy to deploy on various servers. For many TLS based services, handling of private keys for certificates is one of the key stumbling blocks to successfully out souring. This specification defines a simple JSON based HTTPS page where an organization can securely publish where they out source various services too. A client can fetch this document over HTTPS, then use the information inside it to decide where to connect. To show and example of this, consider an client of organization A (example.net) that wants to connect via XMPP to a service at organization B (example.org, that had outshouted a services such as XMPP to organization C (example.com). The names are confusing but key point is .org our source the service to .com and the .net is trying to connect to the service. A would start by doing a HTTPS request to get the document at www.example.org/.well-known/services/xmpp/ which would return a JSON document that looked like:

This document tells the client to connect to service xmpp.example.com at port 5269 for this service and to expect a certificate that would be valid for a TLS connection to the domain example.com. At this point the client would from an XMPP connection to xmpp.example.com:5269 and check that the TLS certificate for the server was valid using the normal rules for XMPP when connecting to a domain of example.com.

There are other approaches to solve this problem. For example,using DNS SRV records to delegate another domain and with the domain running the service having an appropriate certificate and private key for the domain that did the delegation. That solution is preferable where it can be deployed.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119.

A client that implements this specification looks up service delegation in the following way. First it forms the URL to look for the service delegation by concatenating the strings "https://" followed by the domain name of the service being requested then the string "//.well-knonw/service/" then the service names as defined in the IANA ports registry to form the URL. It MUST use HTTPS to retrieve this resource at this URL. If the server has a resource at that URL, it MUST be a JSON document that represents an array of objects. Each object has the following fields:

IANA will make the following "Well Known URI" registration as described in : URI suffix: service Change controller: IETF <iesg@ietf.org> Specification document(s): [RFC-AAAA] Related information: None

IANA will make the following port registration: Registration Technical Contact Cullen Jennings <fluffy@cisco.com> Registration Owner IETF <iesg@ietf.org> Transport Protocol TCP Port Number TBD Service Name p2psip-enroll Description Peer to Peer Infrastructure Enrollment Reference [RFC-AAAA]

This system is only as secure as the connection used to retrieve the information. If the HTTPS session is compromised, or gasp even worse, someone uses HTTP instead of HTTP to retrieve this information, the security can be compromised in many ways. At first glance this appears to greatly increase the surface area for attack on the securiyt of the service. For example, if the HTTP webserver is compromised, now one can get comprimise the XMPP service. Howerver, given the way that CA typically aprove certificates, it is probably allready possibel to get the CA to issue an valid certificate for the service to an attacker that had comprimosed the webserver.

Be famous, get your name here, send comments.