< draft-ietf-httpbis-security-properties-03.txt		draft-ietf-httpbis-security-properties-04.txt >
	Network Working Group P. Hoffman		Network Working Group J. Hodges
	Internet-Draft VPN Consortium		Internet-Draft PayPal
	Intended status: Informational A. Melnikov		Intended status: Informational B. Leiba
	Expires: September 8, 2009 Isode Ltd.		Expires: September 2, 2009 Huawei Technologies
	March 7, 2009		March 2009
	Security Requirements for HTTP		Security Requirements for HTTP
	draft-ietf-httpbis-security-properties-03		draft-ietf-httpbis-security-properties-04
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 8, 2009.		This Internet-Draft will expire on September 2, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Abstract		Abstract
	Recent IESG practice dictates that IETF protocols must specify		Recent IESG practice dictates that IETF protocols must specify
	mandatory-to-implement security mechanisms, so that all conformant		mandatory-to-implement (MTI) security mechanisms, so that all
	implementations share a common baseline. This document examines all		conformant implementations share a common baseline. This document
	widely deployed HTTP security technologies, and analyzes the trade-		examines all widely deployed HTTP security technologies, and analyzes
	offs of each.		the trade-offs of each.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3		2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3
	2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 3		2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 4
	2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 5		2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 5
	2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5		2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 6
	2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5		2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 6
	2.2.3. Authentication Using Certificates in TLS . . . . . . . 6		2.2.3. Authentication Using Certificates in TLS . . . . . . . 7
	2.2.4. Other Access Authentication Schemes . . . . . . . . . 6		2.2.4. Other Access Authentication Schemes . . . . . . . . . 7
	2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7		2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 8
	2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 8
	2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8		2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 9
	3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 8		3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. Normative References . . . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 10		6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
			6.2. Informative References . . . . . . . . . . . . . . . . . . 11
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
			Appendix B. Document History . . . . . . . . . . . . . . . . . . 11
	B.1. Changes between draft-sayre-http-security-variance-00		B.1. Changes between draft-sayre-http-security-variance-00
	and draft-ietf-httpbis-security-properties-00 . . . . . . 10		and draft-ietf-httpbis-security-properties-00 . . . . . . 11
	B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 10		B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 11
	B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 11		B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		B.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 12
			B.5. Changes between -03 and -04 . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Recent IESG practice dictates that IETF protocols are required to		Recent IESG practice dictates that IETF protocols be required to
	specify mandatory to implement security mechanisms. "The IETF		specify mandatory-to-implement (MTI) security mechanisms. "The IETF
	Standards Process" [RFC2026] does not require that protocols specify		Standards Process" [RFC2026] does not require that protocols specify
	mandatory security mechanisms. "Strong Security Requirements for		mandatory security mechanisms. "Strong Security Requirements for
	IETF Standard Protocols" [RFC3365] requires that all IETF protocols		IETF Standard Protocols" [RFC3365] requires that all IETF protocols
	provide a mechanism for implementers to provide strong security. RFC		provide a mechanism for implementers to provide strong security. RFC
	3365 does not define the term "strong security".		3365 does not define the term "strong security".
	"Security Mechanisms for the Internet" [RFC3631] is not an IETF		"Security Mechanisms for the Internet" [RFC3631] is not an IETF
	procedural RFC, but it is perhaps most relevant. Section 2.2 states:		procedural RFC, but it is perhaps most relevant. Section 2.2 states:
	We have evolved in the IETF the notion of "mandatory to implement"		We have evolved in the IETF the notion of "mandatory to implement"
	skipping to change at page 3, line 34 ¶		skipping to change at page 3, line 34 ¶
	implementations may result. This is the consequence of the		implementations may result. This is the consequence of the
	selection of non-overlapping mechanisms being deployed in the		selection of non-overlapping mechanisms being deployed in the
	different implementations.		different implementations.
	This document examines the effects of applying security constraints		This document examines the effects of applying security constraints
	to Web applications, documents the properties that result from each		to Web applications, documents the properties that result from each
	method, and will make Best Current Practice recommendations for HTTP		method, and will make Best Current Practice recommendations for HTTP
	security in a later document version. At the moment, it is mostly a		security in a later document version. At the moment, it is mostly a
	laundry list of security technologies and tradeoffs.		laundry list of security technologies and tradeoffs.
			[[ OVERALL ISSUE: It isn't entirely clear to the present editors what
			the purpose of this document is. On one hand it could be a
			compendium of peer-entity authentication mechanisms (as it is
			presently) and make MTI recommendations thereof, or it could be a
			place for various security considerations (either coalesced here from
			the other httpbis specs, or reserved for the more gnarly cross-spec
			composite ones), or both. This needs to be clarified. ]]
	2. Existing HTTP Security Mechanisms		2. Existing HTTP Security Mechanisms
	For HTTP, the IETF generally defines "security mechanisms" as some		For HTTP, the IETF generally defines "security mechanisms" as some
	combination of access authentication and/or a secure transport.		combination of access authentication and/or a secure transport.
	[[ There is a suggestion that this section be split into "browser-		[[ There is a suggestion that this section be split into "browser-
	like" and "automation-like" subsections. ]]		like" and "automation-like" subsections. See:
			http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
			0180.html
			http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
			0183.html
			]]
	[[ NTLM (shudder) was brought up in the WG a few times in the		[[ NTLM (shudder) was brought up in the WG a few times in the
	discussion of the -00 draft. Should we add a section on it? ]]		discussion of the -00 draft. Should we add a section on it? See..
			http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
			0132.html
			http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
			0135.html
			]]
	2.1. Forms And Cookies		2.1. Forms And Cookies
			[[ JH: I am not convinced that this subsection properly belongs in
			this overall section in that "HTTP+HTML Form based authentication"
			<http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication>
			is not properly a part of HTTP itself. Rather, it is a piece of
			applications layered on top of HTTP. Use of cookies for state
			management (e.g. session maintanence) can be considered such, however
			(although there is no overall specification for HTTP user agents
			stipulating that they must implement cookies (nominally [RFC2109])).
			Perhaps this section should be should be retitled "HTTP
			Authentication".
			Note: The httpstate WG was recently chartered to develop a successor
			to [RFC2109]. See..
			http://www.ietf.org/dyn/wg/charter/httpstate-charter.html
			]]
	Almost all HTTP authentication that involves a human using a web		Almost all HTTP authentication that involves a human using a web
	browser is accomplished through HTML forms, with session identifiers		browser is accomplished through HTML forms, with session identifiers
	stored in cookies. For cookies, most implementations rely on the		stored in cookies. For cookies, most implementations rely on the
	"Netscape specification", which is described loosely in section 10 of		"Netscape specification", which is described loosely in section 10 of
	"HTTP State Management Mechanism" [RFC2109]. The protocol in RFC		"HTTP State Management Mechanism" [RFC2109]. The protocol in RFC
	2109 is relatively widely implemented, but most clients don't		2109 is relatively widely implemented, but most clients don't
	advertise support for it. RFC 2109 was later updated [RFC2965], but		advertise support for it. RFC 2109 was later updated [RFC2965], but
	the newer version is not widely implemented.		the newer version is not widely implemented.
	Forms and cookies have many properties that make them an excellent		Forms and cookies have many properties that make them an excellent
	skipping to change at page 5, line 44 ¶		skipping to change at page 6, line 34 ¶
	2.2.2. Digest Authentication		2.2.2. Digest Authentication
	In Digest Authentication, the client transmits the results of hashing		In Digest Authentication, the client transmits the results of hashing
	user credentials with properties of the request and values from the		user credentials with properties of the request and values from the
	server challenge. Digest is susceptible to man-in-the-middle attacks		server challenge. Digest is susceptible to man-in-the-middle attacks
	when not used over a secure transport.		when not used over a secure transport.
	Digest has some properties that are preferable to Basic and Cookies.		Digest has some properties that are preferable to Basic and Cookies.
	Credentials are not immediately reusable by parties that observe or		Credentials are not immediately reusable by parties that observe or
	receive them, and session data can be transmitted along side		receive them, and session data can be transmitted alongside
	credentials with each request, allowing servers to validate		credentials with each request, allowing servers to validate
	credentials only when absolutely necessary. Authentication data		credentials only when absolutely necessary. Authentication data
	session keys are distinct from other protocol traffic.		session keys are distinct from other protocol traffic.
	Digest includes many modes of operation, but only the simplest modes		Digest includes many modes of operation, but only the simplest modes
	enjoy any degree of interoperability. For example, most		enjoy any degree of interoperability. For example, most
	implementations do not implement the mode that provides full message		implementations do not implement the mode that provides full message
	integrity. Perhaps one reason is that implementation experience has		integrity. Perhaps one reason is that implementation experience has
	shown that in some cases, especially those involving large requests		shown that in some cases, especially those involving large requests
	or responses such as streams, the message integrity mode is		or responses such as streams, the message integrity mode is
	skipping to change at page 7, line 23 ¶		skipping to change at page 8, line 13 ¶
	inserted at will.		inserted at will.
	Unlike Digest, Negotiate authentication can take multiple round trips		Unlike Digest, Negotiate authentication can take multiple round trips
	(client sending authentication data in Authorization, server sending		(client sending authentication data in Authorization, server sending
	authentication data in WWW-Authenticate) to complete.		authentication data in WWW-Authenticate) to complete.
	Kerberos authentication is generally more secure than Digest.		Kerberos authentication is generally more secure than Digest.
	However the requirement for having a separate network authentication		However the requirement for having a separate network authentication
	service might be a barrier to deployment.		service might be a barrier to deployment.
			2.2.4.2. OAuth
			[[ See..
			http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt
			http://www.ietf.org/id/draft-hammer-oauth-10.txt
			]]
	2.3. Centrally-Issued Tickets		2.3. Centrally-Issued Tickets
	Many large Internet services rely on authentication schemes that		Many large Internet services rely on authentication schemes that
	center on clients consulting a single service for a time-limited		center on clients consulting a single service for a time-limited
	ticket that is validated with undocumented heuristics. Centralized		ticket that is validated with undocumented heuristics. Centralized
	ticket issuing has the advantage that users may employ one set of		ticket issuing has the advantage that users may employ one set of
	credentials for many services, and clients don't send credentials to		credentials for many services, and clients don't send credentials to
	many servers. This approach is often no more than a sophisticated		many servers. This approach is often no more than a sophisticated
	application of forms and cookies.		application of forms and cookies.
	skipping to change at page 7, line 51 ¶		skipping to change at page 8, line 51 ¶
	amalgam of HTTP technologies mentioned above, the XML-based protocols		amalgam of HTTP technologies mentioned above, the XML-based protocols
	are defined by an ever-changing combination of standard and vendor-		are defined by an ever-changing combination of standard and vendor-
	produced specifications, some of which may be obsoleted at any time		produced specifications, some of which may be obsoleted at any time
	[WS-Pagecount] without any documented change control procedures.		[WS-Pagecount] without any documented change control procedures.
	These protocols usually don't have much in common with the		These protocols usually don't have much in common with the
	Architecture of the World Wide Web. It's not clear why the term "Web"		Architecture of the World Wide Web. It's not clear why the term "Web"
	is used to group them, but they are obviously out of scope for HTTP-		is used to group them, but they are obviously out of scope for HTTP-
	based application protocols.		based application protocols.
	[[ This section could really use a good definition of "Web Services"		[[ This section could really use a good definition of "Web Services"
	to differentiate it from REST. ]]		to differentiate it from REST. See..
			http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
			0536.html
			]]
	2.5. Transport Layer Security		2.5. Transport Layer Security
	In addition to using TLS for client and/or server authentication, it		In addition to using TLS for client and/or server authentication, it
	is also very commonly used to protect the confidentiality and		is also very commonly used to protect the confidentiality and
	integrity of the HTTP session. For instance, both HTTP Basic		integrity of the HTTP session. For instance, both HTTP Basic
	authentication and Cookies are often protected against snooping by		authentication and Cookies are often protected against snooping by
	TLS.		TLS.
	It should be noted that, in that case, TLS does not protect against a		It should be noted that, in that case, TLS does not protect against a
	skipping to change at page 8, line 30 ¶		skipping to change at page 9, line 35 ¶
	Is is possible that HTTP will be revised in the future. "HTTP/1.1"		Is is possible that HTTP will be revised in the future. "HTTP/1.1"
	[RFC2616] and "Use and Interpretation of HTTP Version Numbers"		[RFC2616] and "Use and Interpretation of HTTP Version Numbers"
	[RFC2145] define conformance requirements in relation to version		[RFC2145] define conformance requirements in relation to version
	numbers. In HTTP 1.1, all authentication mechanisms are optional,		numbers. In HTTP 1.1, all authentication mechanisms are optional,
	and no single transport substrate is specified. Any HTTP revision		and no single transport substrate is specified. Any HTTP revision
	that adds a mandatory security mechanism or transport substrate will		that adds a mandatory security mechanism or transport substrate will
	have to increment the HTTP version number appropriately. All widely		have to increment the HTTP version number appropriately. All widely
	used schemes are non-standard and/or proprietary.		used schemes are non-standard and/or proprietary.
	4. Security Considerations		4. IANA Considerations
			This document has no actions for IANA.
			5. Security Considerations
	This entire document is about security considerations.		This entire document is about security considerations.
	5. Normative References		6. References
			6.1. Normative References
	[Apache_Digest]		[Apache_Digest]
	Apache Software Foundation, "Apache HTTP Server -		Apache Software Foundation, "Apache HTTP Server -
	mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/		mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
	mod_auth_digest.html>.		mod_auth_digest.html>.
	[PhishingHOWTO]		[PhishingHOWTO]
	Gutmann, P., "Phishing Tips and Techniques",		Gutmann, P., "Phishing Tips and Techniques",
	February 2008,		February 2008,
	<http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.		<http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.		3", BCP 9, RFC 2026, October 1996.
	[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
	Mechanism", RFC 2109, February 1997.
	[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use		[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
	and Interpretation of HTTP Version Numbers", RFC 2145,		and Interpretation of HTTP Version Numbers", RFC 2145,
	May 1997.		May 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	skipping to change at page 9, line 46 ¶		skipping to change at page 11, line 7 ¶
	RFC 4178, October 2005.		RFC 4178, October 2005.
	[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based		[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
	Kerberos and NTLM HTTP Authentication in Microsoft		Kerberos and NTLM HTTP Authentication in Microsoft
	Windows", RFC 4559, June 2006.		Windows", RFC 4559, June 2006.
	[WS-Pagecount]		[WS-Pagecount]
	Bray, T., "WS-Pagecount", September 2004, <http://		Bray, T., "WS-Pagecount", September 2004, <http://
	www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.		www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
			6.2. Informative References
			[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
			Mechanism", RFC 2109, February 1997.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Much of the material in this document was written by Rob Sayre, who		Much of the material in this document was written by Rob Sayre, who
	first promoted the topic. Many others on the HTTPbis Working Group		first promoted the topic. Many others on the HTTPbis Working Group
	have contributed to this document in the discussion.		have contributed to this document in the discussion.
	Appendix B. Document History		Appendix B. Document History
	[This entire section is to be removed when published as an RFC.]		[This entire section is to be removed when published as an RFC.]
	skipping to change at page 11, line 28 ¶		skipping to change at page 12, line 43 ¶
	B.3. Changes between -01 and -02		B.3. Changes between -01 and -02
	In section 2.1, added more to the paragraph on auto-completion of		In section 2.1, added more to the paragraph on auto-completion of
	HTML forms.		HTML forms.
	Added the section on TLS for authentication.		Added the section on TLS for authentication.
	Filled in section 2.5.		Filled in section 2.5.
			B.4. Changes between -02 and -03
			Changed IPR licensing from "full3978" to "pre5378Trust200902".
			B.5. Changes between -03 and -04
			Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with
			permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham
			(httpbis chair).
			Added "OVERALL ISSUE" to introduction.
			Added links to email messages on mailing list(s) where various
			suggestions for this document were brought up. I.e. added various
			links to those comments herein delimited by "[[...]]" braces.
			Noted JH's belief that "HTTP+HTML Form based authentication" aka
			"Forms And Cookies" doesn't properly belong in the section where it
			presently resides. Added link to httpstate WG.
			Added references to OAuth. Section needs to be filled-in as yet.
			Moved ref to RFC2109 to new "Informative References" section, and
			added a placeholder "IANA Considerations" section in order to satisfy
			IDnits checking.
	Authors' Addresses		Authors' Addresses
	Paul Hoffman		Jeff Hodges
	VPN Consortium		PayPal
	Email: paul.hoffman@vpnc.org		Email: Jeff.Hodges@PayPal.com
	Alexey Melnikov		Barry Leiba
	Isode Ltd.		Huawei Technologies
	Email: alexey.melnikov@isode.com		Phone: +1 646 827 0648
			Email: barryleiba@computer.org
			URI: http://internetmessagingtechnology.org/
End of changes. 25 change blocks.
	48 lines changed or deleted		147 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/