draft-ietf-xmpp-posh-04.txt   draft-ietf-xmpp-posh-05.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 27, 2015 &yet Expires: March 2, 2016 &yet
February 23, 2015 August 30, 2015
PKIX over Secure HTTP (POSH) PKIX over Secure HTTP (POSH)
draft-ietf-xmpp-posh-04 draft-ietf-xmpp-posh-05
Abstract Abstract
Experience has shown that it is extremely difficult to deploy proper Experience has shown that it is difficult to deploy proper PKIX
PKIX certificates for TLS in multi-tenanted environments. As a certificates for TLS in multi-tenant environments. As a result,
result, domains hosted in such environments often deploy applications domains hosted in such environments often deploy applications using
using certificates that identify the hosting service, not the hosted certificates that identify the hosting service, not the hosted
domain. Such deployments force end users and peer services to accept domain. Such deployments force end users and peer services to accept
a certificate with an improper identifier, resulting in obvious a certificate with an improper identifier, resulting in degraded
security implications. This document defines two methods that make security. This document defines two methods that make it easier to
it easier to deploy certificates for proper server identity checking deploy certificates for proper server identity checking in non-HTTP
in non-HTTP application protocols. While these methods developed for application protocols. While these methods were developed for use in
use in the Extensible Messaging and Presence Protocol (XMPP) as a the Extensible Messaging and Presence Protocol (XMPP) as a Domain
Domain Name Association (DNA) prooftype, they might also be usable in Name Association (DNA) prooftype, they might also be usable in other
other non-HTTP application protocols. non-HTTP application protocols.
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 27, 2015. This Internet-Draft will expire on March 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Obtaining Verification Materials . . . . . . . . . . . . . . 4 3. Obtaining Verification Material . . . . . . . . . . . . . . . 4
3.1. Source Domain Possesses PKIX Certificate Information . . 5 3.1. Source Domain Possesses PKIX Certificate Information . . 5
3.2. Source Domain References PKIX Certificate . . . . . . . . 7 3.2. Source Domain References PKIX Certificate . . . . . . . . 7
3.3. Performing Verification . . . . . . . . . . . . . . . . . 8 3.3. Performing Verification . . . . . . . . . . . . . . . . . 8
4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8
5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 9
6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 10 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 10
7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10 7. Guidance for Server Operators . . . . . . . . . . . . . . . . 11
8. Guidelines for Protocols that Use POSH . . . . . . . . . . . 11 8. Guidance for Protocol Authors . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. POSH Service Names . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
We begin with a thought experiment. We begin 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 "SPICE" service (or email or instant messaging or that provides instances of the hypothetical "Secure Protocol for
social networking service) for ten thousand different customer Internet Content Exchange" (SPICE) service for ten thousand different
organizations. Each customer wants their service to be identified by customer organizations. Each customer wants their instance to be
the customer's domain name (e.g., bar.example.com), not the hosting identified by the customer's domain name (e.g., bar.example.com), not
company's domain name (e.g., hosting.example.net). the hosting company's domain name (e.g., hosting.example.net).
In order to properly secure each customer's "SPICE" service via In order to properly secure each customer's SPICE instance via
Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX Transport Layer Security (TLS) [RFC5246], you need to obtain and
certificates [RFC5280] containing identifiers such as deploy PKIX certificates [RFC5280] containing identifiers such as
bar.example.com, as explained in the "CertID" specification bar.example.com, as explained in the "CertID" specification
[RFC6125]. Unfortunately, you can't obtain such certificates
because: [RFC6125]. Unfortunately, you can't obtain and deploy such
certificates because:
o Certification authorities won't issue such certificates to you o Certification authorities won't issue such certificates to you
because you work for the hosting company, not the customer because you work for the hosting company, not the customer
organization. organization.
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 because your legal department is
is worried about liability, too. worried about liability, too.
o Even if your legal department is happy, this still means managing o Even if your legal department is happy, this still means managing
one certificate for each customer across the infrastructure, one certificate for each customer across the infrastructure,
contributing to a large administrative load. contributing to a large administrative load.
Given your inability to deploy public keys / certificates containing Given your inability to obtain and deploy public keys / certificates
the right identifiers, your back-up approach has always been to use a containing the right identifiers, your back-up approach has always
certificate containing hosting.example.net as the identifier. been to use a certificate containing hosting.example.net as the
However, more and more customers and end users are complaining about identifier. However, more and more customers and end users are
warning messages in user agents and the inherent security issues complaining about warning messages in user agents and the inherent
involved with taking a "leap of faith" to accept the identity security issues involved with taking a "leap of faith" to accept the
mismatch between what [RFC6125] calls the Source Domain identity mismatch between the Source Domain (bar.example.com) and the
(bar.example.com) and the Delegated Domain (hosting.example.net). Delegated Domain (hosting.example.net) [RFC6125].
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 it will be several years before they will be able to deploy 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 DNSSEC and DANE for all of your customers (because of tooling
updates, slow deployment of DNSSEC at some top-level domains, etc.). updates, slow deployment of DNSSEC at some top-level domains, etc.).
The product managers in your company are pushing you to find a method 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 that can be deployed more quickly to overcome the lack of proper
server identity checking for your hosted customers. server identity checking for your hosted customers.
One possible approach that your team has investigated is to ask each One possible approach that your team has investigated is to ask each
customer to provide the public key / certificate for the "SPICE" customer to provide the public key / certificate for its SPICE
service at a special HTTPS URL on their website service at a special HTTPS URI on their website ("https://
("https://bar.example.com/.well-known/posh.spice.json" is one bar.example.com/.well-known/posh/spice.json" is one possibility).
possibility). This could be a public key that you generate for the This could be a public key that you generate for the customer, but
customer, but because the customer hosts it via HTTPS, any user agent because the customer hosts it via HTTPS, any user agent can find that
can find that public key and check it against the public key you public key and check it against the public key you provide during TLS
provide during TLS negotiation for the "SPICE" service (as one added negotiation for the SPICE service (as one added benefit, the customer
benefit, the customer never needs to hand you a private key). never needs to hand you a private key). Alternatively, the customer
Alternatively, the customer can redirect requests for that special can redirect requests for that special HTTPS URI to an HTTPS URI at
HTTPS URL to an HTTPS URL at your own website, thus making it your own website, thus making it explicit that they have delegated
explicit that they have delegated the "SPICE" service to you. the SPICE 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 was 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) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP (DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP
application protocol. application protocol.
2. Terminology 2. Terminology
skipping to change at page 4, line 26 skipping to change at page 4, line 29
"Reference Identifier" are used as defined in the "CertID" "Reference 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].
Additionally, this document uses the following terms: Additionally, this document uses the following terms:
POSH client: The client utilizing the application service (e.g., an POSH client: A client that uses the application service and that
XMPP client). It relies on the protocol defined herein to verify uses POSH to obtain material for verifying the service's identity.
the POSH server's identity.
POSH server: The server hosting the application service (e.g., an POSH server: A server that hosts the application service and that
XMPP server). It expects clients to rely on the protocol defined uses POSH to provide material for verifying its identity.
herein to verify its identity.
3. Obtaining Verification Materials 3. Obtaining Verification Material
Server identity checking (see [RFC6125]) involves three different Server identity checking (see [RFC6125]) involves three different
aspects: aspects:
1. A proof of the POSH server's identity (in PKIX, this takes the 1. A proof of the POSH server's identity (in PKIX, this takes the
form of a PKIX end-entity certificate [RFC5280]). form of a PKIX end-entity 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).
3. The materials that a POSH client uses to verify the POSH server's 3. 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 identity or check the POSH server's proof (in PKIX, this takes
the form of chaining the end-entity certificate back to a trusted the 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 POSH When POSH is used, the first two aspects remain the same: the POSH
server proves it identity by presenting a PKIX certificate [RFC5280] server proves its 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 POSH client obtains the materials it will use to XMPP). However, the POSH client obtains the material it will use to
verify the server's proof by retrieving a JSON document [RFC7159] verify the server's proof by retrieving a JSON document [RFC7159]
containing hashes of the PKIX certificate over HTTPS ([RFC7230] and containing hashes of the PKIX certificate over HTTPS ([RFC7230] and
[RFC2818]) from a well-known URI [RFC5785] at the Source Domain. [RFC2818]) from a well-known URI [RFC5785] at the Source Domain.
(This means that the POSH client needs to verify the certificate of POSH servers MUST use HTTPS. This means that the POSH client MUST
the HTTPS service at the Source Domain in order to securely verify the certificate of the HTTPS service at the Source Domain in
"bootstrap" into the use of POSH; specifically, the rules of order to securely "bootstrap" into the use of POSH; specifically, the
[RFC2818] apply to this "bootstrapping" step to provide a secure rules of [RFC2818] apply to this "bootstrapping" step to provide a
basis for all subsequent POSH processing.) secure basis for all subsequent POSH operations.
The process for retrieving a PKIX certificate over secure HTTP is as A PKIX certificate is retrieved over secure HTTP in the following
follows. way.
1. The POSH client performs an HTTPS GET request at the Source 1. The POSH client performs an HTTPS GET request at the Source
Domain to the path "/.well-known/posh.{servicedesc}.json". The Domain to the path "/.well-known/posh.{servicedesc}.json". The
value of "{servicedesc}" is application-specific; see Section 9 value of "{servicedesc}" is application-specific; see Section 8
of this document for more details. For example, if the of this document for more details. For example, if the
application protocol is some hypothetical "SPICE" service, then application protocol is the hypothetical SPICE service, then
"{servicedesc}" could be "spice"; thus if an application client "{servicedesc}" could be "spice"; thus if an application client
were to use POSH to verify an application server for the Source were to use POSH to verify an application server for the Source
Domain "bar.example.com", the HTTPS GET request would be as Domain "bar.example.com", the HTTPS GET request would be as
follows: follows:
GET /.well-known/posh.spice.json HTTP/1.1 GET /.well-known/posh/spice.json HTTP/1.1
Host: bar.example.com Host: bar.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 PKIX certificate information for the requested * If it possesses PKIX certificate information for the requested
path, it responds as detailed in Section 3.1. path, it responds as detailed in Section 3.1.
* If it has a reference to where the PKIX certificate * If it has a reference to where the PKIX certificate
information can be obtained, it responds as detailed in information can be obtained, it responds as detailed in
Section 3.2. Section 3.2.
* If it does not have any PKIX certificate information or a * If it does not have any PKIX certificate information or a
reference to such information for the requested path, it reference to such information for the requested path, it
responds with an HTTP client error status code (e.g., 404). responds with an HTTP 404 Not Found status code [RFC7231].
3.1. Source Domain Possesses PKIX Certificate Information 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 request with a success information, it responds to the HTTPS GET request with a success
status code and the message body set to a JSON document [RFC7159]; status code and the message body set to a JSON document [RFC7159];
the document is a JSON object which MUST have the following: the document is "fingerprints document", i.e., a JSON object with the
following members:
o A "fingerprints" field whose value is a JSON array of fingerprint o A "fingerprints" member whose value is a JSON array of fingerprint
descriptors. descriptors (the member MUST include at least one fingerprint
descriptor).
o An "expires" field whose value is a JSON number specifying the o An "expires" member whose value is a JSON number specifying the
number of seconds after which the POSH client ought to consider number of seconds after which the POSH client ought to consider
the key information to be stale (further explained under the key information to be stale (further explained under
Section 6). Section 6).
The JSON document returned MUST NOT contain a "url" field as The JSON document returned MUST NOT contain a "url" member as
described in Section 3.2. described in Section 3.2.
Each included fingerprint descriptor is a JSON object, where each Each included fingerprint descriptor is a JSON object, where each
member name is the textual name of a hash function (as listed in member name is the textual name of a hash function (as listed in
[HASH-NAMES]) and its associated value is the base 64 encoded [HASH-NAMES]) and its associated value is the base 64 encoded
fingerprint hash generated using the named hash function (where the fingerprint hash generated using the named hash function (where the
encoding adheres to the definition in Section 4 of [RFC4648] and encoding adheres to the definition in Section 4 of [RFC4648] and
where the padding bits are set to zero). Each fingerprint descriptor where the padding bits are set to zero).
MUST possess at least one named hash function.
The fingerprint hash for a given hash algorithm is generated by The fingerprint hash for a given hash algorithm is generated by
performing the named hash function over the DER encoding of the PKIX performing the named hash function over the DER encoding of the PKIX
X.509 certifiate; for example, a "sha-1" fingerprint is generated by X.509 certifiate. (This implies that if the certificate expires or
performing the SHA-1 hash function over the DER encoding of the PKIX is revoked, the fingerprint value will be out of date.)
certificate.
The following example illustrates the usage described above. 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.
Example Content Response Example Fingerprints Response
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Content-Length: 134 Content-Length: 135
{ {
"fingerprints": [ "fingerprints": [
{ {
"sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=",
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=" "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ="
} }
], ],
"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. It MUST be a non-negative integer. If no "expires" field material. It MUST be a non-negative integer. If the "expires"
is included or its value is equal to 0, a POSH client SHOULD consider member has value of 0 (zero), a POSH client MUST consider the
these verification materials invalid. See Section 6 for how to verification material to be invalid. See Section 6 for how to
reconcile this "expires" field with the reference's "expires" field. reconcile this "expires" member with the reference's "expires"
member.
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:
{
"fingerprints": [
{
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ"
},
{
"sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="
}
],
"expires": 806400
}
Matching on any of these fingerprints is acceptable.
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.
3.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 request with a success information, it responds to the HTTPS GET request with a success
status code and message body set to a JSON document. The document is status code and message body set to a JSON document. The document is
a JSON object which MUST contain the following: a "reference document", i.e., a JSON object with the following
members:
o A "url" field whose value is a JSON string specifying the HTTPS o A "url" member whose value is a JSON string specifying the HTTPS
URL where POSH clients can obtain the actual certificate URI where POSH clients can obtain the actual certificate
information. information. The URI can be a well-known POSH URI as described in
Section 8, but it need not be. (For historical reasons, the
member name is "url", not "uri".)
o An "expires" field whose value is a JSON number specifying the o An "expires" member whose value is a JSON number specifying the
number of seconds after which the POSH client ought to consider number of seconds after which the POSH client ought to consider
the delegation to be stale (further explained under Section 6). 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: 79 Content-Length: 82
{ {
"url":"https://hosting.example.net/.well-known/posh.spice.json", "url":"https://hosting.example.net/.well-known/posh/spice.json",
"expires":86400 "expires":86400
} }
The client performs an HTTPS GET request for the URL specified in the In order to process a reference response, the client performs an
"url" field value. The HTTPS server for the URL to which the client HTTPS GET request for the URI specified in the "url" member value.
has been redirected responds to the request with a JSON document The HTTPS server for the URI to which the client has been referred
containing fingerprints as described in Section 3.1. The content responds to the request with a JSON document containing fingerprints
retrieved from the "url" location MUST NOT itself be a reference as described in Section 3.1. The document retrieved from the
(i.e., containing a "url" field instead of a "fingerprints" field), location specified by the "url" member MUST NOT itself be a reference
in order to prevent circular delegations. document (i.e., containing a "url" member instead of a "fingerprints"
member), in order to prevent circular delegations.
Note: See Section 10 for discussion about HTTPS redirects. Note: See Section 10 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. It MUST be a Domain's delegation of service to the Delegated Domain. It MUST be a
non-negative integer. If no "expires" field is included or its value non-negative integer. If the "expires" member has a value of 0
is equal to 0, a POSH client SHOULD consider the delegation invalid. (zero), a POSH client MUST consider the delegation invalid. See
See Section 6 for guidelines about reconciling this "expires" field Section 6 for guidelines about reconciling this "expires" member with
with the "expires" field of the fingerprints document. the "expires" member of the fingerprints document.
3.3. Performing Verification 3.3. Performing Verification
The POSH client compares the PKIX information obtained from the POSH The POSH client compares the PKIX information presented by the POSH
server against each fingerprint descriptor object in the POSH server against each fingerprint descriptor object in the POSH
results, until a match is found using the hash functions that the reference document, until a match is found using the hash functions
client suports, or until the collection of POSH verification that the client supports, or until the collection of POSH
materials is exhausted. If none of the fingerprint descriptor verification material is exhausted. If none of the fingerprint
objects match the POSH server PKIX information, the POSH client descriptor objects match the POSH server PKIX information, the POSH
SHOULD reject the connection (however, the POSH client might still client SHOULD reject the connection (however, the POSH client might
accept the connection if other verification schemes are successful). still accept the connection if other verification methods are
successful, such as DANE [RFC6698]).
4. 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 credentials offered by the POSH server match considered secure if the credentials offered by the POSH server match
the verification materials possessed by the client, regardless of how the verification material obtained by the client, regardless of how
those materials are obtained. the material was obtained.
5. Order of Operations 5. Order of Operations
In order for the POSH client to perform verification of Reference In order for the POSH client to perform verification of reference
Identifiers without potentially compromising data, POSH processes identifiers without potentially compromising data, POSH operations
MUST be complete before any application-layer data is exchanged for MUST be complete before any application-layer data is exchanged for
the Source Domain. In cases where the POSH client initiates an the Source Domain. In cases where the POSH client initiates an
application-layer connection, the client SHOULD perform all POSH application-layer connection, the client SHOULD perform all POSH
retrievals before initiating a connection (naturally this is not retrievals before initiating a connection (naturally this is not
possible in cases where the POSH client receives an application-layer possible in cases where the POSH client receives instead of initiates
connection). For application protocols that use DNS SRV (including an application-layer connection). For application protocols that use
queries for TLSA records in concert with SRV records as described in DNS SRV (including queries for TLSA records in concert with SRV
[I-D.ietf-dane-srv]), the POSH processes ideally ought to be done in records as described in [I-D.ietf-dane-srv]), the POSH operations
parallel with resolving the SRV records and the addresses of any ideally ought to be done in parallel with resolving the SRV records
targets, similar to the "happy eyeballs" approach for IPv4 and IPv6 and the addresses of any targets, similar to the "happy eyeballs"
[RFC6555]. approach for IPv4 and IPv6 [RFC6555].
The following diagram illustrates the possession flow: The following diagram illustrates the possession flow:
POSH Source POSH
Client Domain Server Client Domain Server
------ ------ ------ ------ ------ ------
| | | | | |
| Request POSH | | | POSH Request | |
|------------------------->| | |------------------------->| |
| | | | | |
| Return POSH fingerprints | | | Return POSH fingerprints | |
|<-------------------------| | |<-------------------------| |
| | | | |
| Service TLS Handshake | | Service TLS Handshake |
|<===================================================>| |<===================================================>|
| | | | |
| Service Data | | Service Data |
|<===================================================>| |<===================================================>|
| | | | |
Figure 1: Order of Events for Possession Flow 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 POSH Source Delegated POSH
------ ------ ------ Client Domain Domain Server
| | | ------ ------ ------ ------
| Request POSH | | | | | |
|------------------------->| | | POSH Request | | |
| | | |----------------->| | |
| Return POSH url | | | | | |
|<-------------------------| | | Return POSH url | | |
| | | |<-----------------| | |
| Request POSH | | | |
|---------------------------------------------------->| | POSH Request | |
| | | |-------------------------------->| |
| Return POSH fingerprints | | | |
|<----------------------------------------------------| | Return POSH fingerprints | |
| | | |<--------------------------------| |
| |
| Service TLS Handshake | | Service TLS Handshake |
|<===================================================>| |<===================================================>|
| | | | |
| Service Data | | Service Data |
|<===================================================>| |<===================================================>|
| | | | |
Figure 2: Order of Events for Reference Flow Figure 2: Order of Events for Reference Flow
6. Caching Results 6. Caching Results
The POSH client MUST NOT cache results (reference or fingerprints) The POSH client MUST NOT cache results (reference or fingerprints)
indefinitely. If the Source Domain returns a reference, the POSH indefinitely. If the Source Domain returns a reference, the POSH
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 fingerprints "expires" value, honor "expires" value is lower than the fingerprints "expires" value, honor
the reference "expires" value). Once the POSH client considers the the reference "expires" value). Once the POSH client considers the
results stale, it needs to perform the entire POSH process again results stale, it needs to perform the entire POSH operation again
starting with the HTTPS GET request to the Source Domain. The POSH starting with the HTTPS GET request to the Source Domain. The POSH
client MAY use a lower value than any provided in the "expires" client MAY use a lower value than any provided in the "expires"
field(s), or not cache results at all. member(s), or not cache results at all.
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
[RFC5280].
The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead
using the expiration hints provided in the POSH reference document or using the expiration hints provided in the POSH reference document or
fingerprints documents. To that end, the HTTPS servers for Source fingerprints document. To that end, the HTTPS servers for Source
Domains and Derived Domains SHOULD specify a 'Cache-Control' header Domains and Derived Domains SHOULD specify a 'Cache-Control' header
indicating a very short duration (e.g., max-age=60) or "no-cache" to indicating a very short duration (e.g., max-age=60) or "no-cache" to
indicate that the response (redirect, reference, or content) is not indicate that the response (redirect, reference, or fingerprints) is
appropriate to cache at the HTTP layer. not appropriate to cache at the HTTP layer.
7. Alternates and Roll-over
To indicate alternate PKIX certificates (such as when an existing 7. Guidance for Server Operators
certificate will soon expire), the returned fingerprints document 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:
{ POSH is intended to ease the operational burden of securing
"fingerprints": [ application services, especially in multi-tenant environments. It
{ does so by obviating the need to obtain certificates for hosted
"sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", domains, so that an operator can obtain a certificate only for its
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ" hosting service (naturally, this certificate needs to be valid
}, according to [RFC5280] and contain the proper identifier(s) in
{ accordance with [RFC6125] and the relevant application protocol
"sha-1":"T29tGO9d7kxbfWnUaac8+5+ICLM=", specification).
"sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="
}
],
"expires": 806400
}
Rolling over from one hosting provider to another is best handled by However, in order to use POSH, an operator does need to coordinate
updating the relevant SRV records, not primarily by updating the POSH with its customers so that the appropriate POSH documents are
files themselves. 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.
8. Guidelines for Protocols that Use POSH 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.
Protocols that use POSH will need to register well-known URIs wth the 8. Guidance for Protocol Authors
IANA in accordance with [RFC5785] (the IANA registration policy
[RFC5226] for well-known URIs is Specification Required).
For the sake of consistency, it would be best if the URIs registered Protocols that use POSH are expected to register with the POSH
by such protocols match the URI template [RFC6570] path "/.well- Service Names registry defined under Section 9.2.
known/posh.{servicedesc}.json"; that is, begin with "posh." and end
with ".json" (indicating a media type of application/json [RFC7159]).
For POSH-using protocols that rely on DNS SRV records [RFC2782], it For POSH-using protocols that rely on DNS SRV records [RFC2782], the
would be best if the "{servicedesc}" part of the well-known URI is service name SHOULD be same as the DNS SRV "Service". As an example,
"{service}.{proto}", where the "{service}" is the DNS SRV "Service" the POSH service name for XMPP server-to-server connections would be
prepended by the underscore character "_" and the "{proto}" is the "xmpp-server" because [RFC6120] registers a DNS SRV "Service" of
DNS SRV "Proto" also prepended by the underscore character "_". As "xmpp-server". One example of the resulting well-known URI would be
an example, the well-known URI for XMPP server-to-server connections "https://example.com/.well-known/posh/xmpp-server.json".
would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers
a service name of "xmpp-server" and uses TCP as the underlying
transport protocol.
For other POSH-using protocols, the "{servicedesc}" part of the well- For other POSH-using protocols, the service name MAY any unique
known URI can be any unique string or identifier for the protocol, string or identifier for the protocol, which might be a service name
which might be a service name registered with the IANA in accordance registered with the IANA in accordance with [RFC6335] or which might
with [RFC6335] or which might be an unregistered name. As an be an unregistered name. As an example, the well-known URI for the
example, the well-known URI for a hypothetical "SPICE" application hypothetical SPICE application might be "spice".
could be "posh.spice.json".
9. IANA Considerations 9. IANA Considerations
This document requests no actions of IANA. [Note to RFC Editor: 9.1. Well-Known URI
please remove this section before publication.]
The IANA is requested to register "posh" in the Well-Known URI
Registry as defined by [RFC5785]. The completed template follows.
URI suffix: posh
Change controller: IETF
Specification: [[ this document ]]
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.
9.2. POSH Service Names
The IANA is requested to establish a registry for POSH service names
within the Uniform Resource Identifier (URI) Schemes group of
registries.
The IANA registration policy [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.
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").
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.
9.2.1. Registration Template
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".
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.
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).
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.
10. Security Considerations 10. 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] as well as following the most modern best practices
other HTTP hardening protocols, such as HSTS [RFC6797] and key for TLS as specified in [RFC7525]. Additionally, the security of
pinning [I-D.ietf-websec-key-pinning], especially if the POSH client POSH can benefit from other HTTP hardening protocols, such as HSTS
[RFC6797] and key pinning [RFC7469], especially if the POSH client
shares some information with a common HTTPS implementation (e.g., shares some information with a common HTTPS implementation (e.g.,
platform-default web browser). platform-default web browser).
Note well that POSH is used by a POSH client to obtain the public key 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 of a POSH 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 POSH server to engage in HTTPS. POSH also does not enable a POSH 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 HTTPS URI. The location provided in the redirect response
specify an HTTPS URL. Source domains SHOULD use only temporary MUST specify an HTTPS URI. 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) [RFC7231]. Clients MAY treat any redirect as
ignoring the specific semantics for 301 (Moved Permanently) and 308 temporary, ignoring the specific semantics for 301 (Moved
(Permanent Redirect) [RFC7238]. To protect against circular Permanently) [RFC7231] and 308 (Permanent Redirect) [RFC7538]. To
references, it is RECOMMENDED that POSH clients follow no more than protect against circular references, it is RECOMMENDED that POSH
10 redirects, although applications or implementations can require clients follow no more than 10 redirects, although applications or
that fewer redirects be followed. implementations can require that fewer redirects be followed.
Hash function agility is an important quality to ensure secure Hash function agility is an important quality to ensure secure
operations in the face of attacks against the fingerprints obtained operations in the face of attacks against the fingerprints obtained
within verification materials. Because POSH verification materials within verification material. Because POSH verification material is
are relatively short-lived compared to long-lived credentials such as relatively short-lived compared to long-lived credentials such as
PKIX end-entity certificates (at least as typically deployed), PKIX end-entity certificates (at least as typically deployed),
entities that deploy POSH are advised to swap out POSH files if the entities that deploy POSH are advised to swap out POSH documents if
hash functions in use are found to be subject to realistic attacks. the hash functions are found to be subject to realistic attacks.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
skipping to change at page 13, line 18 skipping to change at page 15, line 9
(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.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014. 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-dane-srv] [I-D.ietf-dane-srv]
Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Based Authentication of Named Entities (DANE) TLSA Records Based Authentication of Named Entities (DANE) TLSA Records
with SRV Records", draft-ietf-dane-srv-11 (work in with SRV Records", draft-ietf-dane-srv-14 (work in
progress), February 2015. progress), April 2015.
[I-D.ietf-websec-key-pinning]
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", draft-ietf-websec-key-pinning-21
(work in progress), October 2014.
[I-D.ietf-xmpp-dna] [I-D.ietf-xmpp-dna]
Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
Associations (DNA) in the Extensible Messaging and Associations (DNA) in the Extensible Messaging and
Presence Protocol (XMPP)", draft-ietf-xmpp-dna-09 (work in Presence Protocol (XMPP)", draft-ietf-xmpp-dna-10 (work in
progress), February 2015. progress), March 2015.
[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, March 2005. 4033, March 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
skipping to change at page 14, line 14 skipping to change at page 16, line 14
[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)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011. 6335, August 2011.
[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.,
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, "HTTP 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 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
308 (Permanent Redirect)", RFC 7238, June 2014. Extension for HTTP", RFC 7469, April 2015.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7538, April 2015.
[HASH-NAMES] [HASH-NAMES]
"Hash Function Textual Names", "Hash Function Textual Names", <http://www.iana.org/
<http://www.iana.org/assignments/hash-function-text-names/ assignments/hash-function-text-names/
hash-function-text-names.xhtml>. hash-function-text-names.xhtml>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias
Tobias Markmann for their implementation feedback. Thanks also to Markmann for their implementation feedback, and to Dave Cridland,
Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their Chris Newton, Max Pritikin, and Joe Salowey for their input on the
input on the specification. specification.
During IESG review, Stephen Farrell, Barry Leiba, and Kathleen
Moriarty provided helpful input that resulted in improvements in the
document.
Thanks also to Dave Cridland as document shepherd, Joe Hildebrand as
working group chair, and Ben Campbell as area director.
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
employing him during his work on earlier draft versions of this
document.
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
 End of changes. 83 change blocks. 
243 lines changed or deleted 352 lines changed or added

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