< draft-zubov-snif-03.txt		draft-zubov-snif-04.txt >
	Network Working Group J. Zubov		Network Working Group J. Zubov
	Internet-Draft VESvault Corp		Internet-Draft VESvault Corp
	Intended status: Experimental 10 February 2022		Intended status: Experimental 16 February 2022
	Expires: 14 August 2022		Expires: 20 August 2022
	Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based		Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based
	End-to-End TLS Forwarding (SNIF)		End-to-End TLS Forwarding (SNIF)
	draft-zubov-snif-03		draft-zubov-snif-04
	Abstract		Abstract
	This document proposes a solution, referred as SNIF, that provides		This document proposes a solution, referred as SNIF, that provides
	the means for any Internet connected device to:		the means for any Internet connected device to:
	* allocate a globally unique anonymous hostname;		* allocate a globally unique anonymous hostname;
	* obtain and maintain a publicly trusted X.509 certificate issued		* obtain and maintain a publicly trusted X.509 certificate issued
	for the allocated hostname;		for the allocated hostname;
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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 14 August 2022.		This Internet-Draft will expire on 20 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. SNIF CA Proxy Protocol . . . . . . . . . . . . . . . . . . . 4		3. SNIF CA Proxy Protocol . . . . . . . . . . . . . . . . . . . 4
	3.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 5		3.1. Protocol Variables . . . . . . . . . . . . . . . . . . . 5
	3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. CN Allocation Request . . . . . . . . . . . . . . . . . . 6		3.3. CN Allocation Request . . . . . . . . . . . . . . . . . . 7
	3.4. CSR Submission Request . . . . . . . . . . . . . . . . . 7		3.4. CSR Submission Request . . . . . . . . . . . . . . . . . 7
	3.5. Certificate Download Request . . . . . . . . . . . . . . 7		3.5. Certificate Download Request . . . . . . . . . . . . . . 8
	4. SNIF Relay Protocol Suite . . . . . . . . . . . . . . . . . . 8		4. SNIF Relay Protocol Suite . . . . . . . . . . . . . . . . . . 9
	4.1. SNIF Messages . . . . . . . . . . . . . . . . . . . . . . 9		4.1. SNIF Messages . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. SNIF Control Connection Protocol . . . . . . . . . . . . 9		4.2. SNIF Control Connection Protocol . . . . . . . . . . . . 9
	4.3. SNIF Service Connection Protocol . . . . . . . . . . . . 12		4.3. SNIF Service Connection Protocol . . . . . . . . . . . . 12
	4.4. SNIF Client Connection Protocol . . . . . . . . . . . . . 13		4.4. SNIF Client Connection Protocol . . . . . . . . . . . . . 13
	4.5. SNIF IPC FIFO Protocol . . . . . . . . . . . . . . . . . 14		4.5. SNIF IPC FIFO Protocol . . . . . . . . . . . . . . . . . 14
	4.6. Abuse Management . . . . . . . . . . . . . . . . . . . . 16		4.6. Abuse Management . . . . . . . . . . . . . . . . . . . . 16
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 16		5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.1. Normative References . . . . . . . . . . . . . . . . . . 18		7.1. Normative References . . . . . . . . . . . . . . . . . . 19
	7.2. Informative References . . . . . . . . . . . . . . . . . 19		7.2. Informative References . . . . . . . . . . . . . . . . . 20
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	A typical Internet-of-Things (IoT) device connects to the Internet		A typical Internet-of-Things (IoT) device connects to the Internet
	using a dynamic IP address, and is usually unable to accept incoming		using a dynamic IP address, and is usually unable to accept incoming
	connections to TCP ports. A dedicated trusted relay is needed to		connections to TCP ports. A dedicated trusted relay is needed to
	facilitate the communications between the IoT device and its intended		facilitate the communications between the IoT device and its intended
	users. While all communications are recommended to be TLS encrypted,		users. While all communications are recommended to be TLS encrypted,
	the trusted relay will terminate each TLS connection and therefore		the trusted relay will terminate each TLS connection and therefore
	have access to unencrypted traffic between IoT devices and user		have access to unencrypted traffic between IoT devices and user
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	the scope of this document.		the scope of this document.
	3. SNIF CA Proxy Protocol		3. SNIF CA Proxy Protocol
	SNIF CA Proxy Protocol is designed for securely acquiring and		SNIF CA Proxy Protocol is designed for securely acquiring and
	maintaining a publicly trusted TLS/SSL X.509 certificate issued by a		maintaining a publicly trusted TLS/SSL X.509 certificate issued by a
	Certificate Authority to a uniquely allocated hostname, by an agent		Certificate Authority to a uniquely allocated hostname, by an agent
	that has no direct control over that hostname, or over a server the		that has no direct control over that hostname, or over a server the
	hostname is pointing to.		hostname is pointing to.
	3.1. Protocol Summary
	SNIF CA Proxy accepts requests from SNIF Connectors via HTTP / HTTPS.		SNIF CA Proxy accepts requests from SNIF Connectors via HTTP / HTTPS.
	SNIF CA Proxy interacts with the CA using protocols supported by the		SNIF CA Proxy interacts with the CA using protocols supported by the
	CA, such as ACME [RFC8555], not covered by this document.		CA, such as ACME [RFC8555], not covered by this document.
	Each SNIF Connector is configured with a specific initiation URL		3.1. Protocol Variables
			Each SNIF Connector MUST be configured with an initiation URL
	({initUrl}), which is specific to the SNIF CA Proxy server the		({initUrl}), which is specific to the SNIF CA Proxy server the
	Connector intends to work with. Depending on the CA Proxy rules,		Connector intends to work with. Depending on the CA Proxy rules,
	{initUrl} might be unique for each Connector, or common for multiple		{initUrl} might be unique for each Connector, or common for multiple
	Connectors.		Connectors.
			The canonical name {cn} is received by a SNIF Connector in response
			to the CN Allocation Request (Section 3.3), and might be either a
			single hostname or a wildcard starting with "*.", depending on the CA
			Proxy rules.
			{cn_host} is a hostname derived from the {cn} - it is identical to
			{cn} in case of a single-host CN, or is the {cn} with truncated
			initial "*." in case of a wildcard CN. Note that {cn_host} is
			different than the SNIF hostname in case of a wildcard CN.
			Each SNIF Connector MAY be configured with an API URL base -
			{apiUrl}. If configured, the {apiUrl} SHOULD be HTTPS.
			In case if {apiUrl} is not configured - the SNIF Connector MUST
			derive {apiUrl} from the {cn_host}, upon allocating the CN, as
			following:
			{apiUrl} := http://{cn_host}/snif-cert/
	3.2. Protocol Flow		3.2. Protocol Flow
	Upon the initial start or after a hard reset, the Connector SHALL		Upon the initial start or after a hard reset, the Connector SHALL
	generate a Private Key, which needs to be securely permanently stored		generate a Private Key, which needs to be securely permanently stored
	by the Connector. Any key algorithm acceptable by the CA can be		by the Connector. Any key algorithm acceptable by the CA can be
	used, generally RSA-4096 is recommended.		used, the choice of the algorithm should be made according to the CA
			guidelines and industry practices.
	The Connector SHALL send a CN Allocation Request using the {initUrl}.		The Connector SHALL send a CN Allocation Request using the {initUrl}.
	Having the canonical name {cn}, the Connector SHALL generate a CSR		Having the canonical name {cn}, the Connector SHALL generate a CSR
	[RFC2986] using the Private Key, the subject containing the {cn}. The		[RFC2986] using the Private Key, the subject containing the {cn}. The
	CSR subject may or may not have other fields besides {cn}, according		CSR subject may or may not have other fields besides {cn}, according
	to the specific requirements of the CA.		to the specific requirements of the CA.
	The Connector SHALL issue a CSR Submission Request to send the CSR to		The Connector SHALL issue a CSR Submission Request to send the CSR to
	the CA Proxy.		the CA Proxy.
	skipping to change at page 5, line 48 ¶		skipping to change at page 6, line 21 ¶
	the {cn} in the subject until it gets replaced with a trusted		the {cn} in the subject until it gets replaced with a trusted
	certificate issued by the CA.		certificate issued by the CA.
	A this point, the Connector will normally know the SNIF hostname it		A this point, the Connector will normally know the SNIF hostname it
	will be using with the SNIF Relay - it matches the {cn} in case of a		will be using with the SNIF Relay - it matches the {cn} in case of a
	single host CN, or is a one sub-level down from a wildcard {cn}, the		single host CN, or is a one sub-level down from a wildcard {cn}, the
	name being derived by the Connector in a way that is not		name being derived by the Connector in a way that is not
	deterministically derivable from the {cn} and the public key, e.g. a		deterministically derivable from the {cn} and the public key, e.g. a
	hash of the Private Key.		hash of the Private Key.
	The Connector can now send a Certificate Download Request, and SHOULD		The Connector can now send a Certificate Download Request, and MUST
	verify the returned Certificate. If the Certificate is valid - the		verify the returned Certificate. If the Certificate is valid - the
	Connector MUST permanently store it.		Connector MUST permanently store it.
	If the Certificate Download Request fails - the Connector SHOULD		If the Certificate Download Request fails - the Connector SHOULD
	repeat the request after certain delay. In case if the response was		repeat the request after certain delay. In case if the response was
	401 and the {authUrl} is returned in a header, and the Connector has		401 and the {authUrl} is returned in a header, and the Connector has
	the means of communicating with the device user - the Connector also		the means of communicating with the device user - the Connector also
	SHOULD alert the user and bring {authUrl} to their attention by some		SHOULD alert the user and bring {authUrl} to their attention by some
	means, so the user can complete the required authorization steps. If		means, so the user can complete the required authorization steps. If
	the Connector has no means of alerting the user, which is often the		the Connector has no means of alerting the user, which is often the
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 33 ¶
	Request. The Connector SHOULD ignore the response body.		Request. The Connector SHOULD ignore the response body.
	Any other response: Error, try again later.		Any other response: Error, try again later.
	3.4. CSR Submission Request		3.4. CSR Submission Request
	Connection from: SNIF Connector		Connection from: SNIF Connector
	Connection to: SNIF CA Proxy		Connection to: SNIF CA Proxy
	Protocol: http		Protocol: https or http
	PUT http://{cn_host}/snif-cert/{cn_host}.csr		PUT {apiUrl}{cn_host}.csr
	Content-Type: application/pkcs10		Content-Type: application/pkcs10
	{cn_host} is a hostname derived from the {cn} - it is identical to
	{cn} in case of a single-host CN, or is the {cn} with truncated
	initial "*." in case of a wildcard CN.
	The request body MUST contain a PEM encoded PKCS#10 CSR [RFC5967],		The request body MUST contain a PEM encoded PKCS#10 CSR [RFC5967],
	the newlines are either <CR><LF> or <LF>, the length of the body		the newlines are either <CR><LF> or <LF>, the length of the body
	SHOULD NOT exceed 16384 bytes.		SHOULD NOT exceed 16384 bytes.
	Note that a CSR for the specific allocated CN can be submitted to the		Note that a CSR for the specific allocated CN can be submitted to the
	CA Proxy once in a lifetime. In case of an incorrect submission the		CA Proxy once in a lifetime. In case of an incorrect submission the
	Connector SHOULD hard reset the storage and restart the flow from the		Connector SHOULD hard reset the storage and restart the flow from the
	beginning, including allocating a new CN.		beginning, including allocating a new CN.
	Response 201: the CSR is successfully submitted. The response		Response 201: the CSR is successfully submitted. The response
	skipping to change at page 7, line 51 ¶		skipping to change at page 8, line 20 ¶
	Response 404: the CN was not allocated.		Response 404: the CN was not allocated.
	Any other response: Error, try again later.		Any other response: Error, try again later.
	3.5. Certificate Download Request		3.5. Certificate Download Request
	Connection from: SNIF Connector		Connection from: SNIF Connector
	Connection to: SNIF CA Proxy		Connection to: SNIF CA Proxy
	Protocol: http		Protocol: https or http
	GET http://{cn_host}/snif-cert/{cn_host}.crt
	{cn_host} is a hostname derived from the {cn} - it is identical to		GET {apiUrl}{cn_host}.crt
	{cn} in case of a single-host CN, or is the {cn} with truncated
	initial "*." in case of a wildcard CN.
	The CA Proxy SHOULD check for a cached previously generated		The CA Proxy SHOULD check for a cached previously generated
	Certificate chain for the {cn}. If the cached Certificate chain is		Certificate chain for the {cn}. If the cached Certificate chain is
	found and if it expires in more that 10 days in the future - the		found and if it expires in more that 10 days in the future - the
	cached Certificate chain SHOULD be returned with status 200.		cached Certificate chain SHOULD be returned with status 200.
	Otherwise, if the {cn} has a valid CSR and a proper authorization to		Otherwise, if the {cn} has a valid CSR and a proper authorization to
	issue a certificate - the CA Proxy SHOULD return status 503 and		issue a certificate - the CA Proxy SHOULD return status 503 and
	SHOULD launch a background process that communicates with the CA to		SHOULD launch a background process that communicates with the CA to
	issue or renew the certificate, and caches the issued Certificate		issue or renew the certificate, and caches the issued Certificate
	chain for subsequent Certificate Download Requests.		chain for subsequent Certificate Download Requests.
	skipping to change at page 9, line 52 ¶		skipping to change at page 10, line 13 ¶
	pointing to the SNIF Relay, and a Private Key that matches the		pointing to the SNIF Relay, and a Private Key that matches the
	Certificate. Normally, the SNIF Connector will generate the Private		Certificate. Normally, the SNIF Connector will generate the Private
	Key and use SNIF CA Proxy Protocol (Section 3) to obtain and maintain		Key and use SNIF CA Proxy Protocol (Section 3) to obtain and maintain
	the Certificate, although other means can be used.		the Certificate, although other means can be used.
	To initiate the Control Connection, the SNIF Connector opens a TCP		To initiate the Control Connection, the SNIF Connector opens a TCP
	connection to the hostname matching the Certificate's CN, that points		connection to the hostname matching the Certificate's CN, that points
	to the Relay.		to the Relay.
	Upon accepting the incoming TCP connection, the SNIF Relay MUST		Upon accepting the incoming TCP connection, the SNIF Relay MUST
	initiate a reversed TLS session as a client peer.		initiate a reversed TLS session as a client peer. If the Relay
			expects connections from Connectors that have been configured with
			{apiUrl} (Section 3.1) - it MAY supply a trusted client TLS
			certificate issued to a host matching such {apiUrl}.
	The SNIF Connector MUST initiate the TLS as a server peer, using the		The SNIF Connector MUST initiate the TLS as a server peer, using the
	Certificate and the Private Key.		Certificate and the Private Key.
	Upon successful TLS negotiation, the SNIF Relay MUST validate the		Upon successful TLS negotiation, the SNIF Relay MUST validate the
	SNIF Connector's certificate. If the certificate is not trusted, the		SNIF Connector's certificate. If the certificate is not trusted, the
	SNIF Relay MUST shut down the TLS session and the TCP socket		SNIF Relay MUST shut down the TLS session and the TCP socket
	immediately.		immediately.
	If the certificate is accepted, both SNIF Relay and SNIF Connector		If the certificate is accepted, both SNIF Relay and SNIF Connector
	skipping to change at page 17, line 7 ¶		skipping to change at page 17, line 19 ¶
	alternate CSR for the issued CN prior to the legitimate Connector,		alternate CSR for the issued CN prior to the legitimate Connector,
	will result in a certificate that doesn't match the Connector's		will result in a certificate that doesn't match the Connector's
	private key, therefore the Connector will need to hard reset and redo		private key, therefore the Connector will need to hard reset and redo
	the initialization. If the intruder alters the X-SNIF-CN: response		the initialization. If the intruder alters the X-SNIF-CN: response
	sent to the Connector, the CSR submission for a bad CN will be		sent to the Connector, the CSR submission for a bad CN will be
	rejected by the CA Proxy, which will also require to hard reset the		rejected by the CA Proxy, which will also require to hard reset the
	Connector.		Connector.
	The content of the Certificate Download Request response is an X.509		The content of the Certificate Download Request response is an X.509
	certificate which is safe to be exposed to any parties. If the		certificate which is safe to be exposed to any parties. If the
	intruder alters the response to the CSR Submission Request or to the		intruder alters the HTTP response to the CSR Submission Request or to
	Certificate Download request, the Connector won't receive a valid		the Certificate Download request, the Connector won't receive a valid
	certificate and will need a hard reset.		certificate and will need a hard reset.
	SNIF Connector SHOULD NOT send its hostname to any parties until it		SNIF Connector SHOULD NOT send its hostname to any parties until it
	downloads and successfully validates the Certificate from the CA		downloads and successfully validates the Certificate from the CA
	Proxy.		Proxy.
	To mitigate request flooding potentially resulting in denial of		To mitigate request flooding potentially resulting in denial of
	service, it is RECOMMENDED for SNIF CA Proxy to require a Certificate		service, it is RECOMMENDED for SNIF CA Proxy to require a Certificate
	issuance authorization. For SNIF Connectors that have a means of		issuance authorization. For SNIF Connectors that have a means of
	interacting with the user such as a built-in web browser, the CA		interacting with the user such as a built-in web browser, the CA
	skipping to change at page 17, line 37 ¶		skipping to change at page 18, line 18 ¶
	implemented. As an example of such mechanism, each SNIF Connector		implemented. As an example of such mechanism, each SNIF Connector
	can have a unique {initUrl} that MUST be HTTPS to avoid possible		can have a unique {initUrl} that MUST be HTTPS to avoid possible
	interception, and each device is supplied with a unique setup URL		interception, and each device is supplied with a unique setup URL
	presented to the user, the CA Proxy properly mapping each setup URL		presented to the user, the CA Proxy properly mapping each setup URL
	to the mathing {initUrl}, and using the setup URL to authorize the		to the mathing {initUrl}, and using the setup URL to authorize the
	certificate issuance and to communicate the SNIF Connector's hostname		certificate issuance and to communicate the SNIF Connector's hostname
	to the user's browser. Such mechanism MUST have a means of alerting		to the user's browser. Such mechanism MUST have a means of alerting
	the user about misrouted setup, when some other agent other than the		the user about misrouted setup, when some other agent other than the
	legitimate user has used the same setup URL during the device setup		legitimate user has used the same setup URL during the device setup
	process, in such case the user MUST be instructed to immediately hard		process, in such case the user MUST be instructed to immediately hard
	reset the device and repeat the setup. Such mechanism also MUST		reset the device and repeat the setup. Such mechanism is RECOMMENDED
	provide a means to prevent or detect intercepted setup when an		to use an HTTPS {apiUrl} (Section 3.1); otherwise it MUST provide a
	intruder alters a submitted CSR, such as status lights on the device		means to prevent or detect intercepted setup when an intruder alters
	to indicate the completion of SNIF setup. The details of such		a submitted CSR, such as status lights on the device to indicate the
	mechanism are not covered by this document.		completion of SNIF setup. The details of such mechanism are not
			covered by this document.
	Since each certificate issued by a CA remains on the certificate		Since each certificate issued by a CA remains on the certificate
	transparency public records, it is RECOMMENDED for SNIF CA Proxy to		transparency public records, it is RECOMMENDED for SNIF CA Proxy to
	only issue Certificates with a wildcard CN. This way, the actual		only issue Certificates with a wildcard CN. This way, the actual
	Connector's hostname (Section 3.2) will not be listed on the public		Connector's hostname (Section 3.2) will not be listed on the public
	records.		records.
	SNIF Control Connection Protocol communicates all sensitive		SNIF Control Connection Protocol communicates all sensitive
	information over a TLS connection with a trusted certificate.		information over a TLS connection with a trusted certificate supplied
			by the SNIF Connector. In high security settings, the SNIF Relay
			SHOULD provide a trusted client certificate when initiating the
			Control Connection, and the Connector SHOULD be configured with an
			HTTPS {apiUrl} (Section 3.1). If the client certificate is not valid
			for the {apiUrl} - the Connector SHOULD immediately terminate the
			Control Connection. In case if the Connector doesn't validate a
			client certificate from the Relay - the Connector MUST NOT send any
			sensitine information in SNIF MSG messages, and MUST NOT consider any
			messages received from the Relay to be trusted.
	SNIF Service Connection Protocol communicates a randomly generated		SNIF Service Connection Protocol communicates a randomly generated
	{conn_id} over an unsecure TCP connection. Except if used over a		{conn_id} over an unsecure TCP connection. Except if used over a
	trusted SNIF IPC FIFO, the {conn_id} can be used only once to accept		trusted SNIF IPC FIFO, the {conn_id} can be used only once to accept
	the Client's TLS connection, which in turn can only be successfully		the Client's TLS connection, which in turn can only be successfully
	negotiated by the targeted SNIF Connector. All further		negotiated by the targeted SNIF Connector. All further
	communications are comprised of end-to-end encrypted TLS traffic.		communications are comprised of end-to-end encrypted TLS traffic.
	The security of the TLS encrypted content between the Client and the		The security of the TLS encrypted content between the Client and the
	Connector is specific to the protocols involved. The underlying		Connector is specific to the protocols involved. The underlying
	protocol SHOULD require proper authentication specific to the		protocol SHOULD require proper authentication specific to the
End of changes. 21 change blocks.
	38 lines changed or deleted		64 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/