draft-ietf-rtcweb-security-arch-16.txt		draft-ietf-rtcweb-security-arch-17.txt
	RTCWEB E. Rescorla		RTCWEB E. Rescorla
	Internet-Draft RTFM, Inc.		Internet-Draft RTFM, Inc.
	Intended status: Standards Track October 22, 2018		Intended status: Standards Track November 17, 2018
	Expires: April 25, 2019		Expires: May 21, 2019
	WebRTC Security Architecture		WebRTC Security Architecture
	draft-ietf-rtcweb-security-arch-16		draft-ietf-rtcweb-security-arch-17
	Abstract		Abstract
	This document defines the security architecture for WebRTC, a		This document defines the security architecture for WebRTC, a
	protocol suite intended for use with real-time applications that can		protocol suite intended for use with real-time applications that can
	be deployed in browsers - "real time communication on the Web".		be deployed in browsers - "real time communication on the Web".
	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
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 April 25, 2019.		This Internet-Draft will expire on May 21, 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
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	3.1. Authenticated Entities . . . . . . . . . . . . . . . . . 5		3.1. Authenticated Entities . . . . . . . . . . . . . . . . . 5
	3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . 6		3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . 6
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8		4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8
	4.2. Media Consent Verification . . . . . . . . . . . . . . . 10		4.2. Media Consent Verification . . . . . . . . . . . . . . . 10
	4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . 11		4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . 11
	4.4. Communications and Consent Freshness . . . . . . . . . . 11		4.4. Communications and Consent Freshness . . . . . . . . . . 11
	5. SDP Identity Attribute . . . . . . . . . . . . . . . . . . . 12		5. SDP Identity Attribute . . . . . . . . . . . . . . . . . . . 12
	5.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13		5.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13
	5.1.1. Generating the Initial SDP Offer . . . . . . . . . . 13		5.1.1. Generating the Initial SDP Offer . . . . . . . . . . 13
	5.1.2. Answerer Processing of SDP Offer . . . . . . . . . . 14		5.1.2. Generating of SDP Answer . . . . . . . . . . . . . . 14
	5.1.3. Generating of SDP Answer . . . . . . . . . . . . . . 14		5.1.3. Processing an SDP Offer or Answer . . . . . . . . . . 14
	5.1.4. Offerer Processing of SDP Answer . . . . . . . . . . 14		5.1.4. Modifying the Session . . . . . . . . . . . . . . . . 14
	5.1.5. Modifying the Session . . . . . . . . . . . . . . . . 14
	6. Detailed Technical Description . . . . . . . . . . . . . . . 14		6. Detailed Technical Description . . . . . . . . . . . . . . . 14
	6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14		6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14
	6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15		6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15
	6.3. Communications Consent . . . . . . . . . . . . . . . . . 17		6.3. Communications Consent . . . . . . . . . . . . . . . . . 17
	6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17		6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17
	6.5. Communications Security . . . . . . . . . . . . . . . . . 18		6.5. Communications Security . . . . . . . . . . . . . . . . . 18
	7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20		7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20
	7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21		7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21
	7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22		7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22
	7.3. Items for Standardization . . . . . . . . . . . . . . . . 24		7.3. Items for Standardization . . . . . . . . . . . . . . . . 24
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 4 ¶
	7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22		7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22
	7.3. Items for Standardization . . . . . . . . . . . . . . . . 24		7.3. Items for Standardization . . . . . . . . . . . . . . . . 24
	7.4. Binding Identity Assertions to JSEP Offer/Answer		7.4. Binding Identity Assertions to JSEP Offer/Answer
	Transactions . . . . . . . . . . . . . . . . . . . . . . 24		Transactions . . . . . . . . . . . . . . . . . . . . . . 24
	7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25		7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25
	7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26		7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26
	7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27		7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27
	7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 27		7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 27
	7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 27		7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 27
	7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 28		7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 28
	8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29		8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29
	8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 29		8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 29
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 30		9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	9.1. Communications Security . . . . . . . . . . . . . . . . . 30		9.1. Communications Security . . . . . . . . . . . . . . . . . 31
	9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 31		9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 31
	9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32		9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32
	9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 33		9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 33
	9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 33		9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 33
	9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34		9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34
	9.4.3. Privacy of IdP-generated identities and the hosting		9.4.3. Privacy of IdP-generated identities and the hosting
	site . . . . . . . . . . . . . . . . . . . . . . . . 34		site . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 34		9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 34
	9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 34		9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 35
	9.4.5. Web Security Feature Interactions . . . . . . . . . . 35		9.4.5. Web Security Feature Interactions . . . . . . . . . . 35
	9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 35		9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 35
	9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 35		9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 35
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
	12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36		12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 36		12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 36
	12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 36		12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 36
	12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 36		12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37
	12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37		12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37
	12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 37		12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 37
	12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 37		12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 37
	12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 37		12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38
	12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 37		12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	13.1. Normative References . . . . . . . . . . . . . . . . . . 38		13.1. Normative References . . . . . . . . . . . . . . . . . . 38
	13.2. Informative References . . . . . . . . . . . . . . . . . 41		13.2. Informative References . . . . . . . . . . . . . . . . . 41
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Introduction		1. Introduction
	The Real-Time Communications on the Web (WebRTC) working group is		The Real-Time Communications on the Web (WebRTC) working group is
	tasked with standardizing protocols for real-time communications		tasked with standardizing protocols for real-time communications
	between Web browsers. The major use cases for WebRTC technology are		between Web browsers. The major use cases for WebRTC technology are
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 7 ¶
	SDP session that contains an SDP "identity" attribute.		SDP session that contains an SDP "identity" attribute.
	5.1.1. Generating the Initial SDP Offer		5.1.1. Generating the Initial SDP Offer
	When an offerer sends an offer, in order to provide its identity		When an offerer sends an offer, in order to provide its identity
	assertion to the peer, it includes an 'identity' attribute in the		assertion to the peer, it includes an 'identity' attribute in the
	offer. In addition, the offerer includes one or more SDP		offer. In addition, the offerer includes one or more SDP
	'fingerprint' attributes. The 'identity' attribute MUST be bound to		'fingerprint' attributes. The 'identity' attribute MUST be bound to
	all the 'fingerprint' attributes in the session description.		all the 'fingerprint' attributes in the session description.
	5.1.2. Answerer Processing of SDP Offer		5.1.2. Generating of SDP Answer
	When an answerer receives an offer that contains an 'identity'
	attribute, the answerer can use the the attribute information to
	contact the IdP, and verify the identity of the peer. If the
	identity verification fails, the answerer MUST reject the offer.
	5.1.3. Generating of SDP Answer
	If the answerer elects to include an 'identity' attribute, it follows		If the answerer elects to include an 'identity' attribute, it follows
	the same steps as those in Section 5.1.1. The answerer can choose to		the same steps as those in Section 5.1.1. The answerer can choose to
	include or omit an 'identity' attribute independently, regardless of		include or omit an 'identity' attribute independently, regardless of
	whether the offerer did so.		whether the offerer did so.
	5.1.4. Offerer Processing of SDP Answer		5.1.3. Processing an SDP Offer or Answer
	Offer processing of an 'identity' attribute is the same as that		When an endpoint receives an offer or answer that contains an
	described in Section 5.1.2.		'identity' attribute, the answerer can use the the attribute
			information to contact the IdP, and verify the identity of the peer.
			If the identity verification fails, the answerer MUST discard the
			offer or answer as malformed.
	5.1.5. Modifying the Session		5.1.4. Modifying the Session
	When modifying a session, if the set of fingerprints is unchanged,		When modifying a session, if the set of fingerprints is unchanged,
	then the sender MAY send the same 'identity' attribute. In this		then the sender MAY send the same 'identity' attribute. In this
	case, the established identity SHOULD be applied to existing DTLS		case, the established identity SHOULD be applied to existing DTLS
	connections as well as new connections established using one of those		connections as well as new connections established using one of those
	fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1		fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1
	requires that each media section use the same set of fingerprints for		requires that each media section use the same set of fingerprints for
	every media section.		every media section.
	If the set of fingerprints changes, then the sender MUST either send		If the set of fingerprints changes, then the sender MUST either send
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 5 ¶
	All media channels MUST be secured via SRTP and SRTCP. Media traffic		All media channels MUST be secured via SRTP and SRTCP. Media traffic
	MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,		MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,
	implementations MUST NOT negotiate cipher suites with NULL encryption		implementations MUST NOT negotiate cipher suites with NULL encryption
	modes. DTLS-SRTP MUST be offered for every media channel. WebRTC		modes. DTLS-SRTP MUST be offered for every media channel. WebRTC
	implementations MUST NOT offer SDP Security Descriptions [RFC4568] or		implementations MUST NOT offer SDP Security Descriptions [RFC4568] or
	select it if offered. A SRTP MKI MUST NOT be used.		select it if offered. A SRTP MKI MUST NOT be used.
	All data channels MUST be secured via DTLS.		All data channels MUST be secured via DTLS.
	All implementations MUST implement DTLS 1.0, with the cipher suite		All Implementations MUST implement DTLS 1.2 with the
	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve		TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256
	[FIPS186]. The DTLS-SRTP protection profile		curve [FIPS186]. Earlier drafts of this specification required DTLS
			1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
			at the time of this writing some implementations do not support DTLS
			1.2; endpoints which support only DTLS 1.2 might encounter
			interoperability issues. The DTLS-SRTP protection profile
	SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.		SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
	Implementations SHOULD implement DTLS 1.2 with the
	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
	Implementations MUST favor cipher suites which support (Perfect		Implementations MUST favor cipher suites which support (Perfect
	Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD		Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD
	over non-AEAD cipher suites.		over non-AEAD cipher suites.
	Implementations MUST NOT implement DTLS renegotiation and MUST reject		Implementations MUST NOT implement DTLS renegotiation and MUST reject
	it with a "no_renegotiation" alert if offered.		it with a "no_renegotiation" alert if offered.
	API Requirement: The API MUST generate a new authentication key pair		API Requirement: The API MUST generate a new authentication key pair
	for every new call by default. This is intended to allow for		for every new call by default. This is intended to allow for
	unlinkability.		unlinkability.
	skipping to change at page 30, line 5 ¶		skipping to change at page 30, line 4 ¶
	"contents": "{\"fingerprint\":[ ... ]}"		"contents": "{\"fingerprint\":[ ... ]}"
	}		}
	Figure 6: Example verification result		Figure 6: Example verification result
	8.1. Identity Formats		8.1. Identity Formats
	The identity provided from the IdP to the RP browser MUST consist of		The identity provided from the IdP to the RP browser MUST consist of
	a string representing the user's identity. This string is in the		a string representing the user's identity. This string is in the
	form "<user>@<domain>", where "user" consists of any character except		form "<user>@<domain>", where "user" consists of any character except
	'@', and domain is an internationalized domain name [RFC5890].		'@', and domain is an internationalized domain name [RFC5890] encoded
			as a sequence of U-labels.
	The PeerConnection API MUST check this string as follows:		The PeerConnection API MUST check this string as follows:
	1. If the domain portion of the string is equal to the domain name		1. If the domain portion of the string is equal to the domain name
	of the IdP proxy, then the assertion is valid, as the IdP is		of the IdP proxy, then the assertion is valid, as the IdP is
	authoritative for this domain. Comparison of domain names is		authoritative for this domain. Comparison of domain names is
	done using the label equivalence rule defined in Section 2.3.2.4		done using the label equivalence rule defined in Section 2.3.2.4
	of [RFC5890].		of [RFC5890].
	2. If the domain portion of the string is not equal to the domain		2. If the domain portion of the string is not equal to the domain
	name of the IdP proxy, then the PeerConnection object MUST reject		name of the IdP proxy, then the PeerConnection object MUST reject
	the assertion unless:		the assertion unless:
	1. the IdP domain is trusted as an acceptable third-party IdP;		1. the IdP domain is trusted as an acceptable third-party IdP;
	and		and
	2. local policy is configured to trust this IdP domain for the		2. local policy is configured to trust this IdP domain for the
	domain portion of the identity string.		domain portion of the identity string.
	Sites that have identities that do not fit into the RFC822 style (for		Any "@" or "%" characters in the "user" portion of the identity MUST
	instance, identifiers that are simple numeric values, or values that		be escaped according to the "Percent-Encoding" rules defined in
	contain '@' characters) SHOULD convert them to this form by escaping		Section 2.1 of [RFC3986]. Characters other than "@" and "%" MUST NOT
	illegal characters and appending their IdP domain (e.g.,		be percent-encoded. For example, with a user of "user@133" and a
	user%40133@identity.example.com), thus ensuring that they are		domain of "identity.example.com", the resulting string will be
	authoritative for the identity.		encoded as "user%40133@identity.example.com".
			Implementations are cautioned to take care when displaying user
			identities containing escaped "@" characters. If such characters are
			unescaped prior to display, implementations MUST distinguish between
			the domain of the IdP proxy and any domain that might be implied by
			the portion of the <user> portion that appears after the escaped "@"
			sign.
	9. Security Considerations		9. Security Considerations
	Much of the security analysis of this problem is contained in		Much of the security analysis of this problem is contained in
	[I-D.ietf-rtcweb-security] or in the discussion of the particular		[I-D.ietf-rtcweb-security] or in the discussion of the particular
	issues above. In order to avoid repetition, this section focuses on		issues above. In order to avoid repetition, this section focuses on
	(a) residual threats that are not addressed by this document and (b)		(a) residual threats that are not addressed by this document and (b)
	threats produced by failure/misbehavior of one of the components in		threats produced by failure/misbehavior of one of the components in
	the system.		the system.
	skipping to change at page 41, line 21 ¶		skipping to change at page 41, line 26 ¶
	Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0:		Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0:
	Real-time Communication Between Browsers", October 2011.		Real-time Communication Between Browsers", October 2011.
	Available at http://dev.w3.org/2011/webrtc/editor/		Available at http://dev.w3.org/2011/webrtc/editor/
	webrtc.html		webrtc.html
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-rtcweb-jsep]		[I-D.ietf-rtcweb-jsep]
	Uberti, J., Jennings, C., and E. Rescorla, "JavaScript		Uberti, J., Jennings, C., and E. Rescorla, "JavaScript
	Session Establishment Protocol", draft-ietf-rtcweb-jsep-24		Session Establishment Protocol", draft-ietf-rtcweb-jsep-25
	(work in progress), October 2017.		(work in progress), October 2018.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,		Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
	March 2010, <https://www.rfc-editor.org/info/rfc5705>.		March 2010, <https://www.rfc-editor.org/info/rfc5705>.
End of changes. 18 change blocks.
	39 lines changed or deleted		45 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/