draft-ietf-httpauth-digest-18.txt   draft-ietf-httpauth-digest-19.txt 
HTTPAuth R. Shekh-Yusef, Ed. HTTPAuth R. Shekh-Yusef, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Obsoletes: 2617 (if approved) D. Ahrens Obsoletes: 2617 (if approved) D. Ahrens
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: October 12, 2015 S. Bremer Expires: October 25, 2015 S. Bremer
Netzkonform Netzkonform
April 10, 2015 April 23, 2015
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-18 draft-ietf-httpauth-digest-19
Abstract Abstract
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that can be used with the HTTP the HTTP Digest Authentication scheme that can be used with the HTTP
authentication mechanism. authentication mechanism.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 October 12, 2015. This Internet-Draft will expire on October 25, 2015.
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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Syntax Convention . . . . . . . . . . . . . . . . . . . . . . 4 2. Syntax Convention . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Digest Access Authentication Scheme . . . . . . . . . . . . . 4 3. Digest Access Authentication Scheme . . . . . . . . . . . . . 4
3.1. Overall Operation . . . . . . . . . . . . . . . . . . . . 4 3.1. Overall Operation . . . . . . . . . . . . . . . . . . . . 4
3.2. Representation of Digest Values . . . . . . . . . . . . . 4 3.2. Representation of Digest Values . . . . . . . . . . . . . 4
3.3. The WWW-Authenticate Response Header Field . . . . . . . 5 3.3. The WWW-Authenticate Response Header Field . . . . . . . 5
3.4. The Authorization Request Header Field . . . . . . . . . 8 3.4. The Authorization Request Header Field . . . . . . . . . 8
3.4.1. Response . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. Response . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. A1 . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2. A1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 38 skipping to change at page 3, line 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that can be used with the HTTP the HTTP Digest Authentication scheme that can be used with the HTTP
authentication mechanism. authentication mechanism.
This document extends but is generally backward compatible with
[RFC2617]. See Appendix A for the new capabilities introduced by
this specification.
The details of the challenge-response authentication mechanism are The details of the challenge-response authentication mechanism are
specified in the "Hypertext Transfer Protocol (HTTP/1.1): specified in the "Hypertext Transfer Protocol (HTTP/1.1):
Authentication" [RFC7235]. Authentication" [RFC7235].
The combination of this document with the definition of the "Basic" The combination of this document with the definition of the "Basic"
authentication scheme [BASIC], "The Hypertext Transfer Protocol authentication scheme [BASIC], "The Hypertext Transfer Protocol
(HTTP) Authentication-Info and Proxy-Authentication-Info Response (HTTP) Authentication-Info and Proxy-Authentication-Info Response
Header Fields" [AUTHINFO], and [RFC7235] obsolete [RFC2617]. Header Fields" [AUTHINFO], and [RFC7235] obsolete [RFC2617].
1.1. Terminology 1.1. Terminology
skipping to change at page 5, line 26 skipping to change at page 5, line 29
A string to be displayed to users so they know which username and A string to be displayed to users so they know which username and
password to use. This string should contain at least the name of password to use. This string should contain at least the name of
the host performing the authentication and might additionally the host performing the authentication and might additionally
indicate the collection of users who might have access. An indicate the collection of users who might have access. An
example might be "registered_users@gotham.news.com". (See example might be "registered_users@gotham.news.com". (See
Section 2.2 of [RFC7235] for more details). Section 2.2 of [RFC7235] for more details).
domain domain
A quoted, space-separated list of URIs, as specified in [RFC3986], A quoted, space-separated list of URIs, as specified in [RFC3986],
that define the protection space. If a URI is an abs_path, it is that define the protection space. If a URI is an path-absolute,
relative to the canonical root URL (See Section 2.2 of [RFC7235]). it is relative to the canonical root URL (See Section 2.2 of
An absolute-URI in this list may refer to a different server than [RFC7235]). An absolute-URI in this list may refer to a different
the web-origin [RFC6454]. The client can use this list to server than the web-origin [RFC6454]. The client can use this
determine the set of URIs for which the same authentication list to determine the set of URIs for which the same
information may be sent: any URI that has a URI in this list as a authentication information may be sent: any URI that has a URI in
prefix (after both have been made absolute) MAY be assumed to be this list as a prefix (after both have been made absolute) MAY be
in the same protection space. If this parameter is omitted or its assumed to be in the same protection space. If this parameter is
value is empty, the client SHOULD assume that the protection space omitted or its value is empty, the client SHOULD assume that the
consists of all URIs on the web-origin. protection space consists of all URIs on the web-origin.
This parameter is not meaningful in Proxy-Authenticate header This parameter is not meaningful in Proxy-Authenticate header
fields, for which the protection space is always the entire proxy; fields, for which the protection space is always the entire proxy;
if present it MUST be ignored. if present it MUST be ignored.
nonce nonce
A server-specified data string which should be uniquely generated A server-specified string which should be uniquely generated each
each time a 401 response is made. It is advised that this string time a 401 response is made. It is advised that this string be
be base64 or hexadecimal data. Specifically, since the string is base64 or hexadecimal data. Specifically, since the string is
passed in the header field lines as a quoted string, the double- passed in the header field lines as a quoted string, the double-
quote character is not allowed, unless suitably escaped. quote character is not allowed, unless suitably escaped.
The contents of the nonce are implementation dependent. The The contents of the nonce are implementation dependent. The
quality of the implementation depends on a good choice. A nonce quality of the implementation depends on a good choice. A nonce
might, for example, be constructed as the base 64 encoding of might, for example, be constructed as the base 64 encoding of
time-stamp H(time-stamp ":" ETag ":" secret-data) time-stamp H(time-stamp ":" ETag ":" secret-data)
where time-stamp is a server-generated time, which preferably where time-stamp is a server-generated time, which preferably
includes micro or nano seconds, or other non-repeating values, includes micro or nano seconds, or other non-repeating values,
ETag is the value of the HTTP ETag header field associated with ETag is the value of the HTTP ETag header field associated with
the requested entity, and secret-data is data known only to the the requested entity, and secret-data is data known only to the
server. With a nonce of this form a server would recalculate the server. With a nonce of this form a server would recalculate the
hash portion after receiving the client authentication header hash portion after receiving the client authentication header
field and reject the request if it did not match the nonce from field and reject the request if it did not match the nonce from
that header field or if the time-stamp value is not recent enough. that header field or if the time-stamp value is not recent enough.
skipping to change at page 6, line 43 skipping to change at page 6, line 48
A string of data, specified by the server, which SHOULD be A string of data, specified by the server, which SHOULD be
returned by the client unchanged in the Authorization header field returned by the client unchanged in the Authorization header field
of subsequent requests with URIs in the same protection space. It of subsequent requests with URIs in the same protection space. It
is RECOMMENDED that this string be base64 or hexadecimal data. is RECOMMENDED that this string be base64 or hexadecimal data.
stale stale
A case-insensitive flag indicating that the previous request from A case-insensitive flag indicating that the previous request from
the client was rejected because the nonce value was stale. If the client was rejected because the nonce value was stale. If
stale is TRUE, the client may wish to simply retry the request stale is true, the client may wish to simply retry the request
with a new encrypted response, without re-prompting the user for a with a new encrypted response, without re-prompting the user for a
new username and password. The server SHOULD only set stale to new username and password. The server SHOULD only set stale to
TRUE if it receives a request for which the nonce is invalid. If true if it receives a request for which the nonce is invalid. If
stale is FALSE, or anything other than TRUE, or the stale stale is false, or anything other than true, or the stale
parameter is not present, the username and/or password are parameter is not present, the username and/or password are
invalid, and new values MUST be obtained. invalid, and new values MUST be obtained.
algorithm algorithm
A string indicating an algorithm used to produce the digest and a A string indicating an algorithm used to produce the digest and a
unkeyed digest. If this is not present it is assumed to be "MD5". unkeyed digest. If this is not present it is assumed to be "MD5".
If the algorithm is not understood, the challenge SHOULD be If the algorithm is not understood, the challenge SHOULD be
ignored (and a different one used, if there is more than one). ignored (and a different one used, if there is more than one).
When used with the Digest mechanism, each one of the algorithms When used with the Digest mechanism, each one of the algorithms
has two variants: Session variant and non-Session variant. The has two variants: Session variant and non-Session variant. The
non-Session variant is denoted by "<algorithm>", e.g. "SHA-256", non-Session variant is denoted by "<algorithm>", e.g. "SHA-256",
and the Session variant is denoted by "<algorithm>-sess", e.g. and the Session variant is denoted by "<algorithm>-sess", e.g.
"SHA-256-sess". "SHA-256-sess".
skipping to change at page 12, line 15 skipping to change at page 12, line 18
username = H( unq(username) ":" unq(realm) ) username = H( unq(username) ":" unq(realm) )
3.4.5. Parameter Values and Quoted-String 3.4.5. Parameter Values and Quoted-String
Note that the value of many of the parameters, such as "username" Note that the value of many of the parameters, such as "username"
value, are defined as a "quoted-string". However, the "unq" notation value, are defined as a "quoted-string". However, the "unq" notation
indicates that surrounding quotation marks are removed in forming the indicates that surrounding quotation marks are removed in forming the
string A1. Thus if the Authorization header field includes the string A1. Thus if the Authorization header field includes the
fields fields
username="Mufasa", realm="myhost@testrealm.com" username="Mufasa", realm="myhost@example.com"
and the user Mufasa has password "Circle Of Life" then H(A1) would be and the user Mufasa has password "Circle Of Life" then H(A1) would be
H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks H(Mufasa:myhost@example.com:Circle Of Life) with no quotation marks
in the digested string. in the digested string.
No white space is allowed in any of the strings to which the digest No white space is allowed in any of the strings to which the digest
function H() is applied unless that white space exists in the quoted function H() is applied unless that white space exists in the quoted
strings or entity body whose contents make up the string to be strings or entity body whose contents make up the string to be
digested. For example, the string A1 illustrated above must be digested. For example, the string A1 illustrated above must be
Mufasa:myhost@testrealm.com:Circle Of Life Mufasa:myhost@example.com:Circle Of Life
with no white space on either side of the colons, but with the white with no white space on either side of the colons, but with the white
space between the words used in the password value. Likewise, the space between the words used in the password value. Likewise, the
other strings digested by H() must not have white space on either other strings digested by H() must not have white space on either
side of the colons which delimit their fields unless that white space side of the colons which delimit their fields unless that white space
was in the quoted strings or entity body being digested. was in the quoted strings or entity body being digested.
Also note that if integrity protection is applied (qop=auth-int), the Also note that if integrity protection is applied (qop=auth-int), the
H(entity-body) is the hash of the entity body, not the message body - H(entity-body) is the hash of the entity body, not the message body -
it is computed before any transfer encoding is applied by the sender it is computed before any transfer encoding is applied by the sender
skipping to change at page 13, line 40 skipping to change at page 13, line 42
nextnonce nextnonce
The value of the nextnonce parameter is the nonce the server The value of the nextnonce parameter is the nonce the server
wishes the client to use for a future authentication response. wishes the client to use for a future authentication response.
The server MAY send the Authentication-Info header field with a The server MAY send the Authentication-Info header field with a
nextnonce field as a means of implementing one-time or otherwise nextnonce field as a means of implementing one-time or otherwise
changing nonces. If the nextnonce field is present the client changing nonces. If the nextnonce field is present the client
SHOULD use it when constructing the Authorization header field for SHOULD use it when constructing the Authorization header field for
its next request. Failure of the client to do so MAY result in a its next request. Failure of the client to do so MAY result in a
request to re-authenticate from the server with the "stale=TRUE". request to re-authenticate from the server with the "stale=true".
Server implementations SHOULD carefully consider the Server implementations SHOULD carefully consider the
performance implications of the use of this mechanism; performance implications of the use of this mechanism;
pipelined requests will not be possible if every response pipelined requests will not be possible if every response
includes a nextnonce parameter that MUST be used on the next includes a nextnonce parameter that MUST be used on the next
request received by the server. Consideration SHOULD be given request received by the server. Consideration SHOULD be given
to the performance vs. security tradeoffs of allowing an old to the performance vs. security tradeoffs of allowing an old
nonce value to be used for a limited time to permit request nonce value to be used for a limited time to permit request
pipelining. Use of the "nc" parameter can retain most of the pipelining. Use of the "nc" parameter can retain most of the
security advantages of a new server nonce without the security advantages of a new server nonce without the
skipping to change at page 15, line 30 skipping to change at page 15, line 30
WWW-Authenticate challenge from any server in the protection space. WWW-Authenticate challenge from any server in the protection space.
A client SHOULD remember the username, password, nonce, nonce count A client SHOULD remember the username, password, nonce, nonce count
and opaque values associated with an authentication session to use to and opaque values associated with an authentication session to use to
construct the Authorization header field in future requests within construct the Authorization header field in future requests within
that protection space. The Authorization header field MAY be that protection space. The Authorization header field MAY be
included preemptively; doing so improves server efficiency and avoids included preemptively; doing so improves server efficiency and avoids
extra round trips for authentication challenges. The server MAY extra round trips for authentication challenges. The server MAY
choose to accept the old Authorization header field information, even choose to accept the old Authorization header field information, even
though the nonce value included might not be fresh. Alternatively, though the nonce value included might not be fresh. Alternatively,
the server MAY return a 401 response with a new nonce value, causing the server MAY return a 401 response with a new nonce value, causing
the client to retry the request; by specifying stale=TRUE with this the client to retry the request; by specifying stale=true with this
response, the server tells the client to retry with the new nonce, response, the server tells the client to retry with the new nonce,
but without prompting for a new username and password. but without prompting for a new username and password.
Because the client is REQUIRED to return the value of the opaque Because the client is required to return the value of the opaque
parameter given to it by the server for the duration of a session, parameter given to it by the server for the duration of a session,
the opaque data can be used to transport authentication session state the opaque data can be used to transport authentication session state
information. (Note that any such use can also be accomplished more information. (Note that any such use can also be accomplished more
easily and safely by including the state in the nonce.) For example, easily and safely by including the state in the nonce.) For example,
a server could be responsible for authenticating content that a server could be responsible for authenticating content that
actually sits on another server. It would achieve this by having the actually sits on another server. It would achieve this by having the
first 401 response include a domain parameter whose value includes a first 401 response include a domain parameter whose value includes a
URI on the second server, and an opaque parameter whose value URI on the second server, and an opaque parameter whose value
contains the state information. The client will retry the request, contains the state information. The client will retry the request,
at which time the server might respond with "HTTP Redirection" at which time the server might respond with "HTTP Redirection"
skipping to change at page 20, line 47 skipping to change at page 20, line 47
is vulnerable to dictionary attacks. Such attacks are much easier is vulnerable to dictionary attacks. Such attacks are much easier
than cryptographic attacks on any widely used algorithm, including than cryptographic attacks on any widely used algorithm, including
those that are no longer considered secure. In other words, those that are no longer considered secure. In other words,
algorithm agility does not make this usage any more secure. algorithm agility does not make this usage any more secure.
As a result, Digest authentication SHOULD be used only with passwords As a result, Digest authentication SHOULD be used only with passwords
that have a reasonable amount of entropy, e.g. 128-bit or more. Such that have a reasonable amount of entropy, e.g. 128-bit or more. Such
passwords typically cannot be memorized by humans but can be used for passwords typically cannot be memorized by humans but can be used for
automated web services. automated web services.
Digest authentication SHOULD be used over a secure channel like HTTPS If digest authentication is being used it SHOULD be over a secure
[RFC2818]. channel like HTTPS [RFC2818].
5.2. Storing passwords 5.2. Storing passwords
Digest authentication requires that the authenticating agent (usually Digest authentication requires that the authenticating agent (usually
the server) store some data derived from the user's name and password the server) store some data derived from the user's name and password
in a "password file" associated with a given realm. Normally this in a "password file" associated with a given realm. Normally this
might contain pairs consisting of username and H(A1), where H(A1) is might contain pairs consisting of username and H(A1), where H(A1) is
the digested value of the username, realm, and password as described the digested value of the username, realm, and password as described
above. above.
skipping to change at page 23, line 43 skipping to change at page 23, line 43
of previously used valid credentials, but see 4.8. of previously used valid credentials, but see 4.8.
5.6. Weakness Created by Multiple Authentication Schemes 5.6. Weakness Created by Multiple Authentication Schemes
An HTTP/1.1 server MAY return multiple challenges with a 401 An HTTP/1.1 server MAY return multiple challenges with a 401
(Authenticate) response, and each challenge MAY use a different auth- (Authenticate) response, and each challenge MAY use a different auth-
scheme. A user agent MUST choose to use the strongest auth-scheme it scheme. A user agent MUST choose to use the strongest auth-scheme it
understands and request credentials from the user based upon that understands and request credentials from the user based upon that
challenge. challenge.
Note that many browsers will only recognize Basic and will require
that it be the first auth-scheme presented. Servers SHOULD only
include Basic if it is minimally acceptable.
When the server offers choices of authentication schemes using the When the server offers choices of authentication schemes using the
WWW-Authenticate header field, the strength of the resulting WWW-Authenticate header field, the strength of the resulting
authentication is only as good as that of the of the weakest of the authentication is only as good as that of the of the weakest of the
authentication schemes. See Section 5.7 below for discussion of authentication schemes. See Section 5.7 below for discussion of
particular attack scenarios that exploit multiple authentication particular attack scenarios that exploit multiple authentication
schemes. schemes.
5.7. Online dictionary attacks 5.7. Online dictionary attacks
If the attacker can eavesdrop, then it can test any overheard nonce/ If the attacker can eavesdrop, then it can test any overheard nonce/
skipping to change at page 27, line 32 skipping to change at page 27, line 32
To clarify the purpose of the existing "HTTP Digest Algorithm Values" To clarify the purpose of the existing "HTTP Digest Algorithm Values"
registry and to avoid confusion between the two registries, IANA is registry and to avoid confusion between the two registries, IANA is
asked to add the following description to the existing "HTTP Digest asked to add the following description to the existing "HTTP Digest
Algorithm Values" registry: Algorithm Values" registry:
This registry lists the algorithms that can be used when creating This registry lists the algorithms that can be used when creating
digests of an HTTP message body, as specified in RFC 3230. digests of an HTTP message body, as specified in RFC 3230.
6.2. Digest Scheme Registration 6.2. Digest Scheme Registration
This specification updates the Digest scheme in Hypertext Transfer This specification updates the existing entry of the Digest scheme in
Protocol (HTTP) Authentication Scheme Registry. Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry and
adds a new reference to this specification.
Authentication Scheme Name: Digest Authentication Scheme Name: Digest
Pointer to specification text: this specification Pointer to specification text: this specification
7. Acknowledgments 7. Acknowledgments
The authors of this document would like to thank the authors of To provide a complete description for the Digest mechanism and its
[RFC2617], as this document heavily borrows text from their document operation, this document borrows text heavily from [RFC2617]. The
to provide a complete description of the digest scheme and its authors of this document would like to thank John Franks, Phillip M.
operations. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J.
Leach, Ari Luotonen, and Lawrence C. Stewart for their work on that
specification.
Special thanks to Julian Reschke for his many reviews, comments, Special thanks to Julian Reschke for his many reviews, comments,
suggestions, and text provided to various areas in this document. suggestions, and text provided to various areas in this document.
The authors would like to thank Stephen Farrell, Yoav Nir, Phillip The authors would like to thank Stephen Farrell, Yoav Nir, Phillip
Hallam-Baker, Manu Sporny, Paul Hoffman, Yaron Sheffer, Sean Turner, Hallam-Baker, Manu Sporny, Paul Hoffman, Yaron Sheffer, Sean Turner,
Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann, Martin Durst, Peter Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann, Martin Durst, Peter
Saint-Andre, Michael Sweet, Daniel Stenberg, Brett Tate, Paul Leach, Saint-Andre, Michael Sweet, Daniel Stenberg, Brett Tate, Paul Leach,
Ilari Liusvaara, Gary Mort, Alexey Melnikov, Benjamin Kaduk, Kathleen Ilari Liusvaara, Gary Mort, Alexey Melnikov, Benjamin Kaduk, Kathleen
Moriarty, Francis Dupont, and Hilarie Orman for their careful review Moriarty, Francis Dupont, and Hilarie Orman for their careful review
 End of changes. 22 change blocks. 
39 lines changed or deleted 44 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/