Secure Service Delegation
draft-jennings-secure-service-delegation-00

Abstract

TODO

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on September 2, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Applicability
3.  Terminology
4.  Mechanism
5.  IANA Considerations
    5.1.  Well-Known URI Registration
    5.2.  Port Registration
6.  Security Considerations
7.  Open Issues
8.  Acknowledgements
9.  Normative References
§  Authors' Addresses

1.  Introduction

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:

[{
  "NotBefore": "2010-08-30T19:59:30Z",
  "NotAfter": "2011-08-30T19:59:30Z",
  "Domain": "example.org",
  "Service": "xmpp-server",
  "Host": "xmpp.example.com",
  "Port": "5269",
  "HostCert": "example.com"
}]

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.

2.  Applicability

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.

3.  Terminology

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

4.  Mechanism

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:

5.  IANA Considerations

5.1.  Well-Known URI Registration

IANA will make the following "Well Known URI" registration as described in [RFC5785] (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” April 2010.):

5.2.  Port Registration

IANA will make the following port registration:

6.  Security Considerations

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.

7.  Open Issues

8.  Acknowledgements

Be famous, get your name here, send comments.

9. Normative References

Authors' Addresses