draft-ietf-oauth-security-topics-07.txt   draft-ietf-oauth-security-topics-08.txt 
Open Authentication Protocol T. Lodderstedt, Ed. Open Authentication Protocol T. Lodderstedt, Ed.
Internet-Draft YES.com AG Internet-Draft YES.com AG
Intended status: Best Current Practice J. Bradley Intended status: Best Current Practice J. Bradley
Expires: February 25, 2019 Yubico Expires: April 18, 2019 Yubico
A. Labunets A. Labunets
Facebook Facebook
D. Fett D. Fett
YES.com AG YES.com AG
August 24, 2018 October 15, 2018
OAuth 2.0 Security Best Current Practice OAuth 2.0 Security Best Current Practice
draft-ietf-oauth-security-topics-07 draft-ietf-oauth-security-topics-08
Abstract Abstract
This document describes best current security practices for OAuth This document describes best current security practices for OAuth
2.0. It updates and extends the OAuth 2.0 Security Threat Model to 2.0. It updates and extends the OAuth 2.0 Security Threat Model to
incorporate practical experiences gathered since OAuth 2.0 was incorporate practical experiences gathered since OAuth 2.0 was
published and covers new threats relevant due to the broader published and covers new threats relevant due to the broader
application of OAuth 2.0. application of OAuth 2.0.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 February 25, 2019. This Internet-Draft will expire on April 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Protecting redirect-based flows . . . . . . . . . . . . . 4 2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 4
2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 5
2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 5
2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 5 2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 5
2.3. Access Token Privilege Restriction . . . . . . . . . . . 5 2.3. Access Token Privilege Restriction . . . . . . . . . . . 5
3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 6 3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 6
3.1. Insufficient redirect URI validation . . . . . . . . . . 6 3.1. Insufficient Redirect URI Validation . . . . . . . . . . 6
3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 6 3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 7
3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 7 3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 8
3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 9 3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 9
3.2. Code or State Leakage from Client or AS via Referrer 3.2. Code or State Leakage from Client or AS via Referrer
Headers . . . . . . . . . . . . . . . . . . . . . . . . . 9 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Proposed Countermeasures . . . . . . . . . . . . . . 10 3.2.1. Proposed Countermeasures . . . . . . . . . . . . . . 10
3.3. Attacks through the Browser History . . . . . . . . . . . 11 3.3. Attacks through the Browser History . . . . . . . . . . . 11
3.3.1. Code in Browser History . . . . . . . . . . . . . . . 11 3.3.1. Code in Browser History . . . . . . . . . . . . . . . 11
3.3.2. Access Token in Browser History . . . . . . . . . . . 11 3.3.2. Access Token in Browser History . . . . . . . . . . . 12
3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Attack Description . . . . . . . . . . . . . . . . . 12 3.4.1. Attack Description . . . . . . . . . . . . . . . . . 12
3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 14 3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 14
3.5. Code Injection . . . . . . . . . . . . . . . . . . . . . 14 3.5. Code Injection . . . . . . . . . . . . . . . . . . . . . 15
3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 16 3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 17
3.6. Cross Site Request Forgery . . . . . . . . . . . . . . . 18 3.6. Cross Site Request Forgery . . . . . . . . . . . . . . . 18
3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 18 3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 18
3.7. Access Token Leakage at the Resource Server . . . . . . . 18 3.7. Access Token Leakage at the Resource Server . . . . . . . 19
3.7.1. Access Token Phishing by Counterfeit Resource Server 18 3.7.1. Access Token Phishing by Counterfeit Resource Server 19
3.7.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 19 3.7.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 19
3.7.1.2. Sender Constrained Access Tokens . . . . . . . . 20 3.7.1.2. Sender Constrained Access Tokens . . . . . . . . 21
3.7.1.3. Audience Restricted Access Tokens . . . . . . . . 23 3.7.1.3. Audience Restricted Access Tokens . . . . . . . . 23
3.7.2. Compromised Resource Server . . . . . . . . . . . . . 24 3.7.2. Compromised Resource Server . . . . . . . . . . . . . 24
3.8. Open Redirection . . . . . . . . . . . . . . . . . . . . 25 3.8. Open Redirection . . . . . . . . . . . . . . . . . . . . 25
3.8.1. Authorization Server as Open Redirector . . . . . . . 25 3.8.1. Authorization Server as Open Redirector . . . . . . . 25
3.8.2. Clients as Open Redirector . . . . . . . . . . . . . 25 3.8.2. Clients as Open Redirector . . . . . . . . . . . . . 26
3.9. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 25 3.9. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 26
3.10. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 26 3.10. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 27
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 28 7.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Document History . . . . . . . . . . . . . . . . . . 31 Appendix A. Document History . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
It's been a while since OAuth has been published in RFC 6749 It's been a while since OAuth has been published in RFC 6749
[RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has [RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has
gotten massive traction in the market and became the standard for API gotten massive traction in the market and became the standard for API
protection and, as foundation of OpenID Connect [OpenID], identity protection and, as foundation of OpenID Connect [OpenID], identity
providing. While OAuth was used in a variety of scenarios and providing. While OAuth was used in a variety of scenarios and
skipping to change at page 3, line 19 skipping to change at page 3, line 20
It's been a while since OAuth has been published in RFC 6749 It's been a while since OAuth has been published in RFC 6749
[RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has [RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has
gotten massive traction in the market and became the standard for API gotten massive traction in the market and became the standard for API
protection and, as foundation of OpenID Connect [OpenID], identity protection and, as foundation of OpenID Connect [OpenID], identity
providing. While OAuth was used in a variety of scenarios and providing. While OAuth was used in a variety of scenarios and
different kinds of deployments, the following challenges could be different kinds of deployments, the following challenges could be
observed: observed:
o OAuth implementations are being attacked through known o OAuth implementations are being attacked through known
implementation weaknesses and anti-patterns (XSRF, referrer implementation weaknesses and anti-patterns (CSRF, referrer
header). Although most of these threats are discussed in the header). Although most of these threats are discussed in the
OAuth 2.0 Threat Model and Security Considerations [RFC6819], OAuth 2.0 Threat Model and Security Considerations [RFC6819],
continued exploitation demonstrates there may be a need for more continued exploitation demonstrates there may be a need for more
specific recommendations or that the existing mitigations are too specific recommendations or that the existing mitigations are too
difficult to deploy. difficult to deploy.
o Technology has changed, e.g., the way browsers treat fragments in o Technology has changed, e.g., the way browsers treat fragments in
some situations, which may change the implicit grant's underlying some situations, which may change the implicit grant's underlying
security model. security model.
skipping to change at page 4, line 17 skipping to change at page 4, line 19
working group for every OAuth implementor. Afterwards, a detailed working group for every OAuth implementor. Afterwards, a detailed
analysis of the threats and implementation issues which can be found analysis of the threats and implementation issues which can be found
in the wild today is given along with a discussion of potential in the wild today is given along with a discussion of potential
countermeasures. countermeasures.
2. Recommendations 2. Recommendations
This section describes the set of security mechanisms the OAuth This section describes the set of security mechanisms the OAuth
working group recommendeds to OAuth implementers. working group recommendeds to OAuth implementers.
2.1. Protecting redirect-based flows 2.1. Protecting Redirect-Based Flows
Authorization servers shall utilize exact matching of client redirect Authorization servers SHALL utilize exact matching of client redirect
URIs against pre-registered URIs. This measure contributes to the URIs against pre-registered URIs. This measure contributes to the
prevention of leakage of authorization codes and access tokens prevention of leakage of authorization codes and access tokens
(depending on the grant type). It also helps to detect mix-up (depending on the grant type). It also helps to detect mix-up
attacks. attacks.
Clients shall avoid any redirects or forwards which can be Clients SHALL avoid any redirects or forwards which can be
parameterized by URI query parameters, in order to provide a further parameterized by URI query parameters, in order to provide a further
layer of defence against token leakage. If there is a need for this layer of defence against token leakage. If there is a need for this
kind of redirects, clients are advised to implement appropriate kind of redirects, clients are advised to implement appropriate
countermeasures against open redirection, e.g., as described by the countermeasures against open redirection, e.g., as described by the
OWASP [owasp]. OWASP [owasp].
Clients shall ensure to only process redirect responses of the OAuth Clients SHALL ensure to only process redirect responses of the OAuth
authorization server they send the respective request to and in the authorization server they send the respective request to and in the
same user agent this request was initiated in. In particular, same user agent this request was initiated in. In particular,
clients shall implement appropriate XSRF prevention by utilizing one- clients SHALL implement appropriate CSRF prevention by utilizing one-
time use XSRF tokens carried in the "state" parameter, which are time use CSRF tokens carried in the "state" parameter, which are
securely bound to the user agent. Moreover, the client shall securely bound to the user agent. Moreover, the client SHALL
memorize which authorization server it sent an authorization request memorize which authorization server it sent an authorization request
to and bind this information to the user agent and ensure any sub- to and bind this information to the user agent and ensure any sub-
sequent messages are sent to the same authorization server. sequent messages are sent to the same authorization server.
Furthermore, clients should use AS-specific redirect URIs as a means Furthermore, clients SHOULD use AS-specific redirect URIs as a means
to identify the AS a particular response came from. Matching this to identify the AS a particular response came from. Matching this
with the before mentioned information regarding the AS the client with the before mentioned information regarding the AS the client
sent the request to helps to detect mix-up attacks. sent the request to helps to detect mix-up attacks.
Note: [I-D.bradley-oauth-jwt-encoded-state] gives advice on how to Note: [I-D.bradley-oauth-jwt-encoded-state] gives advice on how to
implement XSRF prevention and AS matching using signed JWTs in the implement CSRF prevention and AS matching using signed JWTs in the
"state" parameter. "state" parameter.
Clients shall use PKCE [RFC7636] in order to (with the help of the 2.1.1. Authorization Code Grant
authorization server) detect and prevent attempts to inject (replay)
authorization codes into the authorization response. The PKCE
challenges must be transaction-specific and securely bound to the
user agent, in which the transaction was started. OpenID Connect
clients may use the "nonce" parameter of the OpenID Connect
authentication request as specified in [OpenID] in conjunction with
the corresponding ID Token claim for the same purpose.
Note: although PKCE so far was recommended as mechanism to protect Clients utilizing the authorization grant type SHALL use PKCE
[RFC7636] in order to (with the help of the authorization server)
detect and prevent attempts to inject (replay) authorization codes
into the authorization response. The PKCE challenges must be
transaction-specific and securely bound to the user agent in which
the transaction was started. OpenID Connect clients MAY use the
"nonce" parameter of the OpenID Connect authentication request as
specified in [OpenID] in conjunction with the corresponding ID Token
claim for the same purpose.
Note: although PKCE so far was recommended as a mechanism to protect
native apps, this advice applies to all kinds of OAuth clients, native apps, this advice applies to all kinds of OAuth clients,
including web applications. including web applications.
Authorization servers shall consider the recommendations given in Authorization servers SHALL consider the recommendations given in
[RFC6819], Section 4.4.1.1, on authorization code replay prevention. [RFC6819], Section 4.4.1.1, on authorization code replay prevention.
2.1.2. Implicit Grant
Clients utilizing the implicit grant SHALL either use
[I-D.ietf-oauth-token-binding] in order to allow the RS to detect and
prevent attempts to inject (replay) access tokens or consider use of
alternative grant types supporting injection detection, such as
o Authorization code grant type in conjunction with PKCE as
specified above
o OpenID Connect with response type "token id_token" and the "nonce"
parameter
2.2. Token Replay Prevention 2.2. Token Replay Prevention
Authorization servers SHOULD use TLS-based methods for sender Authorization servers SHOULD use TLS-based methods for sender
constrained access tokens as described in Section 3.7.1.2, such as constrained access tokens as described in Section 3.7.1.2, such as
token binding [I-D.ietf-oauth-token-binding] or Mutual TLS for OAuth token binding [I-D.ietf-oauth-token-binding] or Mutual TLS for OAuth
2.0 [I-D.ietf-oauth-mtls] in order to prevent token replay. It is 2.0 [I-D.ietf-oauth-mtls] in order to prevent token replay. It is
also recommend to use end-to-end TLS whenever possible. also recommended to use end-to-end TLS whenever possible.
2.3. Access Token Privilege Restriction 2.3. Access Token Privilege Restriction
The privileges associated with an access token SHOULD be restricted The privileges associated with an access token SHOULD be restricted
to the minimum required for the particular application or use case. to the minimum required for the particular application or use case.
This prevents clients from exceeding the privileges authorized by the This prevents clients from exceeding the privileges authorized by the
resource owner. It also prevents users from exceeding their resource owner. It also prevents users from exceeding their
privileges authorized by the respective security policy. Privilege privileges authorized by the respective security policy. Privilege
restrictions also limit the impact of token leakage although more restrictions also limit the impact of token leakage although more
effective counter-measures are described in Section 2.2. effective counter-measures are described in Section 2.2.
skipping to change at page 6, line 16 skipping to change at page 6, line 36
serve the respective request. Clients and authorization servers MAY serve the respective request. Clients and authorization servers MAY
utilize the parameter "scope" as specified in [RFC6749] to determine utilize the parameter "scope" as specified in [RFC6749] to determine
those resources and/or actions. those resources and/or actions.
3. Attacks and Mitigations 3. Attacks and Mitigations
This section gives a detailed description of attacks on OAuth This section gives a detailed description of attacks on OAuth
implementations, along with potential countermeasures. This section implementations, along with potential countermeasures. This section
complements and enhances the description given in [RFC6819]. complements and enhances the description given in [RFC6819].
3.1. Insufficient redirect URI validation 3.1. Insufficient Redirect URI Validation
Some authorization servers allow clients to register redirect URI Some authorization servers allow clients to register redirect URI
patterns instead of complete redirect URIs. In those cases, the patterns instead of complete redirect URIs. In those cases, the
authorization server, at runtime, matches the actual redirect URI authorization server, at runtime, matches the actual redirect URI
parameter value at the authorization endpoint against this pattern. parameter value at the authorization endpoint against this pattern.
This approach allows clients to encode transaction state into This approach allows clients to encode transaction state into
additional redirect URI parameters or to register just a single additional redirect URI parameters or to register just a single
pattern for multiple redirect URIs. As a downside, it turned out to pattern for multiple redirect URIs. As a downside, it turned out to
be more complex to implement and error prone to manage than exact be more complex to implement and error prone to manage than exact
redirect URI matching. Several successful attacks have been observed redirect URI matching. Several successful attacks have been observed
skipping to change at page 23, line 11 skipping to change at page 23, line 28
This document therefore recommends implementors to consider one of This document therefore recommends implementors to consider one of
TLS-based approaches wherever possible. TLS-based approaches wherever possible.
3.7.1.3. Audience Restricted Access Tokens 3.7.1.3. Audience Restricted Access Tokens
An audience restriction essentially restricts the resource server a An audience restriction essentially restricts the resource server a
particular access token can be used at. The authorization server particular access token can be used at. The authorization server
associates the access token with a certain resource server and every associates the access token with a certain resource server and every
resource server is obliged to verify for every request, whether the resource server is obliged to verify for every request, whether the
access token send with that request was meant to be used at the access token sent with that request was meant to be used at the
particular resource server. If not, the resource server must refuse particular resource server. If not, the resource server must refuse
to serve the respective request. In the general case, audience to serve the respective request. In the general case, audience
restrictions limit the impact of a token leakage. In the case of a restrictions limit the impact of a token leakage. In the case of a
counterfeit resource server, it may (as described see below) also counterfeit resource server, it may (as described see below) also
prevent abuse of the phished access token at the legitimate resource prevent abuse of the phished access token at the legitimate resource
server. server.
The audience can basically be expressed using logical names or The audience can basically be expressed using logical names or
physical addresses (like URLs). In order to prevent phishing, it is physical addresses (like URLs). In order to prevent phishing, it is
necessary to use the actual URL the client will send requests to. In necessary to use the actual URL the client will send requests to. In
skipping to change at page 29, line 25 skipping to change at page 29, line 52
[I-D.ietf-oauth-mix-up-mitigation] [I-D.ietf-oauth-mix-up-mitigation]
Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up
Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work
in progress), July 2016. in progress), July 2016.
[I-D.ietf-oauth-mtls] [I-D.ietf-oauth-mtls]
Campbell, B., Bradley, J., Sakimura, N., and T. Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual TLS Client Authentication Lodderstedt, "OAuth 2.0 Mutual TLS Client Authentication
and Certificate Bound Access Tokens", draft-ietf-oauth- and Certificate Bound Access Tokens", draft-ietf-oauth-
mtls-10 (work in progress), July 2018. mtls-11 (work in progress), August 2018.
[I-D.ietf-oauth-pop-key-distribution] [I-D.ietf-oauth-pop-key-distribution]
Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, Bradley, J., Hunt, P., Jones, M., and H. Tschofenig,
"OAuth 2.0 Proof-of-Possession: Authorization Server to "OAuth 2.0 Proof-of-Possession: Authorization Server to
Client Key Distribution", draft-ietf-oauth-pop-key- Client Key Distribution", draft-ietf-oauth-pop-key-
distribution-03 (work in progress), February 2017. distribution-03 (work in progress), February 2017.
[I-D.ietf-oauth-resource-indicators] [I-D.ietf-oauth-resource-indicators]
Campbell, B., Bradley, J., and H. Tschofenig, "Resource Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", draft-ietf-oauth-resource- Indicators for OAuth 2.0", draft-ietf-oauth-resource-
skipping to change at page 31, line 23 skipping to change at page 31, line 47
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
[webappsec-referrer-policy] [webappsec-referrer-policy]
Google Inc. and Google Inc., "Referrer Policy", April Google Inc. and Google Inc., "Referrer Policy", April
2017, <https://w3c.github.io/webappsec-referrer-policy>. 2017, <https://w3c.github.io/webappsec-referrer-policy>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-08
o added recommendations re implicit and token injection
o uppercased key words in Section 2 according to RFC 2119
-07 -07
o incorporated findings of Doug McDorman o incorporated findings of Doug McDorman
o added section on HTTP status codes for redirects o added section on HTTP status codes for redirects
o added new section on access token privilege restriction based on o added new section on access token privilege restriction based on
comments from Johan Peeters comments from Johan Peeters
-06 -06
 End of changes. 31 change blocks. 
47 lines changed or deleted 69 lines changed or added

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