Network Working Group                                          M. Miller
Internet-Draft                                            P. Saint-Andre
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: December 29, 2012                                 June 27, 2012


 Using PKIX over Secure HTTP (POSH) as a Prooftype for XMPP Domain Name
                              Associations
                  draft-miller-xmpp-posh-prooftype-00

Abstract

   This document defines a prooftype involving PKIX over Secure HTTP
   (POSH) for associating a domain name with an XML stream in the
   Extensible Messaging and Presence Protocol (XMPP).  It also defines a
   method involving HTTPS redirects (appropriate for use with the POSH
   prooftype) for securely delegating a source domain to a derived
   domain in XMPP.

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 December 29, 2012.

Copyright Notice

   Copyright (c) 2012 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



Miller & Saint-Andre    Expires December 29, 2012               [Page 1]


Internet-Draft             XMPP POSH Prooftype                 June 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Prooftype . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Secure Delegation . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Caching Results . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

































Miller & Saint-Andre    Expires December 29, 2012               [Page 2]


Internet-Draft             XMPP POSH Prooftype                 June 2012


1.  Introduction

   The [XMPP-DNA] specification defines a framework for secure
   delegation and authenticated domain name associations (DNA) in the
   Extensible Messaging and Presence Protocol (XMPP).  This document
   defines a prooftype for DNA, using PKIX certificates obtained over
   secure HTTP ("POSH"), as well as a secure delegation method, based on
   HTTPS redirects, that is appropriate for use with the POSH prooftype.

   The rationale for POSH is driven by current operational realities.
   It is effectively impossible for a hosting service to provide and
   maintain PKIX certificates [RFC5280] that include the appropriate
   [RFC6125] identifiers for each hosted domain.  It is true that DNS-
   based technologies are emerging for secure delegation, in the form of
   DNS Security [RFC4033] and [DANE]); however, these technologies are
   not yet widely deployed and might not be deployed in the near future
   for domains outside the most common top-level domains (e.g., ".COM",
   ".NET", ".EDU").  Because the XMPP community wishes to deploy secure
   delegation and authenticated domain name associations as widely and
   as quickly as possible, this document specifies how to use secure
   HTTP [RFC2616] and PKIX certificates [RFC5280] to verify that a
   domain is delegated to a hosting provider and authenticate an
   assocation between a domain name and an XML stream.


2.  Terminology

   This document inherits XMPP-related terminology from [RFC6120] and
   security-related terminology from [RFC5280].  The terms "source
   domain", "derived domain", "reference identifier", and "presented
   identifier" are used as defined in the "CertID" specification
   [RFC6125].

   This document is applicable to connections made from an XMPP client
   to an XMPP server ("_xmpp-client._tcp") or between XMPP servers
   ("_xmpp-server._tcp").  In both cases, the XMPP initiating entity
   acts as a TLS client and the XMPP receiving entity acts as a TLS
   server.  Therefore, to simplify discussion this document uses "_xmpp-
   client._tcp" to describe both cases, unless otherwise indicated.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].







Miller & Saint-Andre    Expires December 29, 2012               [Page 3]


Internet-Draft             XMPP POSH Prooftype                 June 2012


3.  Prooftype

   POSH stands for PKIX Over Secure HTTP: the verification materials
   consist of a PKIX certificate [RFC5280], they are obtained by
   retrieving the certificate over HTTPS [RFC2818] from a well-known URI
   [RFC5785], the certificate is checked according to the rules from
   [RFC6120] and [RFC6125], and secure DNS is not necessary since the
   HTTPS retrieval mechanism relies on the chain of trust based on the
   public key infrastructure.

   The process for retrieving a PKIX certificate over secure HTTP is as
   follows.

   1.  The initiating entity performs an HTTPS GET to the path "/.well-
       known/tls/_<service>._tcp<source domain>.cer" at the source
       domain; where "_<service>" MUST be either "_xmpp-client" for XMPP
       client-to-server connections or "_xmpp-server" for XMPP server-
       to-server connections:

   HTTP GET /.well-known/_xmpp-server._tcp.im.example.com.cer HTTP/1.1
   Host: im.example.com


   2.  If the source domain HTTPS server has a certificate for the
       requested path, it MUST respond with a success status code, with
       the message body as the DER certificate (optionally encoded as
       base64 [RFC4684]) that the XMPP server at the source domain will
       present during the TLS negotiation phase of XMPP stream setup:

   HTTP/1.1 200 OK
   Content-Type: application/pkix-cert
   Content-Length: 839

   -----BEGIN CERTIFICATE-----
   MIICPTCCAaYCCQDDVeBaBmWC/jANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJV
   UzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEXMBUGA1UEChMO
   aW0uZXhhbXBsZS5jb20xFzAVBgNVBAMTDmltLmV4YW1wbGUuY29tMB4XDTEyMDYx
   MTIxNTQ0NFoXDTIyMDYwOTIxNTQ0NFowYzELMAkGA1UEBhMCVVMxETAPBgNVBAgT
   CENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxFzAVBgNVBAoTDmltLmV4YW1wbGUu
   Y29tMRcwFQYDVQQDEw5pbS5leGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
   jQAwgYkCgYEA4hoKhi/B07eQH+1NB9gWiNFDT//AbTHQOEC0AOr4Gh/o9PUp7kD0
   gklU4uv7rSAhAyCe4WaOiQ/HShzEryGfHiZmWht0BaYmj19iuPWRecZOXWqKZji9
   NtAxn9l3kdon/YLJcrPGyNTGK66+ggNaqy8LkQQpI4rff60yHHZ/0XkCAwEAATAN
   BgkqhkiG9w0BAQUFAAOBgQDcwiu30bSMlykWYz+tTDSlQ3wLSVB9RsR8jXmJvMo7
   y7icXwg54a9M3xipjZtrfAhYM5I5iqUTQPki6s26n9SQpRm5bonEFDA3WGwrwma3
   5biP9+NSBWzSaDF8AztwFNKXXl6/U6hWwG05G/NdeS11gpww9NUDraJgVoDpRK04
   tg==
   -----END CERTIFICATE-----



Miller & Saint-Andre    Expires December 29, 2012               [Page 4]


Internet-Draft             XMPP POSH Prooftype                 June 2012


4.  Secure Delegation

   When PKIX Over Secure HTTP (POSH) is the DNA prooftype, it is
   possible to use HTTPS redirects in determining if a domain is
   securely delegated, as follows:

   1.  The initiating entity performs an HTTPS GET to the path "/.well-
       known/tls/_<service>._tcp<source-domain>.cer" at the source
       domain; where "_<service>" MUST be either "_xmpp-client" for XMPP
       client-to-server connections or "_xmpp-server" for XMPP server-
       to-server connections.  Here is an example:

   GET /.well-known/_xmpp-server._tcp.im.example.com.cer HTTP/1.1
   Host: im.example.com


   2.  If the source domain HTTPS server has delegated to a derived
       domain, it MUST respond with one of the redirect mechanisms
       provided by HTTP (e.g., using the 302, 303, or 307 response).
       The 'Location' header MUST specify an HTTPS URL, where the
       hostname and port is the derived domain HTTPS server, and the
       path MUST match the pattern "_<service>._tcp.<derived
       domain>.cer"; where "_<service>" MUST be identical to the
       "_<service>" portion of the original request (line breaks added
       for readability):

   HTTP/1.1 302 Found
   Location: https://hosting.example.com/.well-known
             /tls/_xmpp-server._tcp.hosting.example.net.cer


   3.  The initiating entity performs an HTTPS GET to the URL specified
       in the 'Location' header:

   GET /.well-known/tls/_xmpp-server._tcp.hosting.example.cer HTTP/1.1
   Host: hosting.example.net


   4.  If the derived domain HTTPS server has a certificate, it MUST
       respond with a success status code, with the message body as the
       DER certificate (optionally encoded as base64 [RFC4684]) that the
       XMPP server at the derived domain will present during the TLS
       negotiation phase of XMPP stream setup:








Miller & Saint-Andre    Expires December 29, 2012               [Page 5]


Internet-Draft             XMPP POSH Prooftype                 June 2012


   HTTP/1.1 200 OK
   Content-Type: application/pkix-cert
   Content-Length: 863

   -----BEGIN CERTIFICATE-----
   MIICUTCCAboCCQCtNQRNu3194zANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJV
   UzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEcMBoGA1UEChMT
   aG9zdGluZy5leGFtcGxlLm5ldDEcMBoGA1UEAxMTaG9zdGluZy5leGFtcGxlLm5l
   dDAeFw0xMjA2MTEyMTQ1MjZaFw0yMjA2MDkyMTQ1MjZaMG0xCzAJBgNVBAYTAlVT
   MREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDVQQKExNo
   b3N0aW5nLmV4YW1wbGUubmV0MRwwGgYDVQQDExNob3N0aW5nLmV4YW1wbGUubmV0
   MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi46kMWnCfg0DTrlcTc6AQUci5
   Lu1f2RKRWPEhz8qyt/CO0N5VpxKQMlGp6TApQzFdAfxCUA3rniYFpMq4Hemw2S74
   v1LRoWvROKviKRzunDP3EhPXf6GbgnHRlfBx4yvZtcR1BMnkxgJtbTAJu4/wTRXY
   RE5FKk3xT4IBXTIQFwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAAvRohCXSfSnHXjv
   84beqmFSYKcZvhVymgxQfhB2ZLNFQvfTO3Qsp/MR0hRRXrJ25n86t49EEXicjC0r
   EdmWaIhdDFhw7hva2byYziww7fJuelD0tpL9nfF5uOIMp3JYyXCBn/FKJhi9HMR1
   d8avm8gJ5Iu7L96qosWzL3epHYW7
   -----END CERTIFICATE-----



5.  Caching Results

   Ideally, the initiating entity relies on the expiration time of the
   certificate obtained via POSH, and not on HTTP caching mechanisms.
   To that end, the HTTPS servers for source and derived domains SHOULD
   specify a 'Cache-Control' header indicating a short duration (e.g.,
   max-age=60) or "no-cache" to indicate the response (redirect or
   content) is not appropriate to cache at the HTTP level.


6.  Examples

   Detailed examples will be provided in a future version of this
   specification.


7.  Security Considerations

   This document supplements but does not supersede the security
   considerations provided in [RFC2616], [RFC2818], [RFC6120], and
   [RFC6125].

   Specifically, communication via HTTPS depends on checking the
   identity of the HTTP server in accordance with [RFC2818].





Miller & Saint-Andre    Expires December 29, 2012               [Page 6]


Internet-Draft             XMPP POSH Prooftype                 June 2012


8.  IANA Considerations

   A future version of this specification will register the well-known
   URIs mentioned above, in accordance with [RFC5785].


9.  References

9.1.  Normative References

   [XMPP-DNA]
              Saint-Andre, P. and M. Miller, "Domain Name Associations
              (DNA) in the Extensible Messaging and Presence Protocol
              (XMPP)", draft-saintandre-xmpp-dna-00 (work in progress),
              June 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              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.

   [RFC4684]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.






Miller & Saint-Andre    Expires December 29, 2012               [Page 7]


Internet-Draft             XMPP POSH Prooftype                 June 2012


9.2.  Informative References

   [DANE]     Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", draft-ietf-dane-protocol-23 (work in
              progress), June 2012.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, May 2005.


Authors' Addresses

   Matthew Miller
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   USA

   Email: mamille2@cisco.com


   Peter Saint-Andre
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   USA

   Email: psaintan@cisco.com





















Miller & Saint-Andre    Expires December 29, 2012               [Page 8]