Diff: rfc9729v1.md - rfc9729.md

	rfc9729v1.md	rfc9729.md

	skipping to change at line 43 ¶	skipping to change at line 43 ¶
	uri: https://guardianproject.info	uri: https://guardianproject.info
	-	-
	ins: J. Hoyland	ins: J. Hoyland
	name: Jonathan Hoyland	name: Jonathan Hoyland
	org: Cloudflare Inc.	org: Cloudflare Inc.
	email: jonathan.hoyland@gmail.com	email: jonathan.hoyland@gmail.com

	normative:	normative:
	RFC8792:	RFC8792:
	X.690:	X.690:

		target: https://www.itu.int/rec/T-REC-X.690
	title: "Information technology - ASN.1 encoding Rules: Specification of Ba sic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Enc oding Rules (DER)"	title: "Information technology - ASN.1 encoding Rules: Specification of Ba sic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Enc oding Rules (DER)"
	date: 2021-02	date: 2021-02
	author:	author:
	org: ITU-T	org: ITU-T
	seriesinfo:	seriesinfo:
	ITU-T: Recommendation X690	ITU-T: Recommendation X690
	ISO/IEC: 8825-1:2021	ISO/IEC: 8825-1:2021

	informative:	informative:
	H2:	H2:

	skipping to change at line 130 ¶	skipping to change at line 131 ¶
	makes the origin probeable as it sends the challenge to unauthenticated	makes the origin probeable as it sends the challenge to unauthenticated
	clients. This document defines a new signature-based authentication scheme tha t	clients. This document defines a new signature-based authentication scheme tha t
	is not probeable.	is not probeable.

	## Conventions and Definitions {#conventions}	## Conventions and Definitions {#conventions}

	{::boilerplate bcp14-tagged}	{::boilerplate bcp14-tagged}

	This document uses the notation from {{Section 1.3 of !QUIC=RFC9000}}.	This document uses the notation from {{Section 1.3 of !QUIC=RFC9000}}.


	<!-- [rfced] FYI, we have added the following sentence to Section 1.1
	("Conventions and Definitions") in order to include a citation for RFC 8792 in
	the text. Please let us know of any objections.

	Current:
	Various examples in this document contain long lines that may be folded,
	as described in [RFC8792].

	Various examples in this document contain long lines that may be folded,	Various examples in this document contain long lines that may be folded,
	as described in [RFC8792].	as described in [RFC8792].


	<!--[rfced] Throughout the text, "Concealed HTTP authentication scheme" and
	# The Concealed HTTP Authentication Scheme	# The Concealed HTTP Authentication Scheme

	"Concealed authentication scheme" appear to be used inconsistently. Please
	review these occurrences and let us know if/how they be made consistent.
	Some examples are listed here:

	Original:
	When a client wishes to use the Concealed HTTP authentication scheme
	with a request, it SHALL compute the authentication proof using a TLS
	keying material exporter with the following parameters:
	...
	If a frontend is configured to check the Concealed authentication
	scheme, it will parse the Authorization (or Proxy-Authorization)
	header field.

	# The Concealed Authentication Scheme

	This document defines the "Concealed" HTTP authentication scheme. It uses	This document defines the "Concealed" HTTP authentication scheme. It uses
	asymmetric cryptography. Clients possess a key ID and a public/private key	asymmetric cryptography. Clients possess a key ID and a public/private key
	pair, and origin servers maintain a mapping of authorized key IDs to associate d	pair, and origin servers maintain a mapping of authorized key IDs to associate d
	public keys.	public keys.

	The client uses a TLS keying material exporter to generate data to be signed	The client uses a TLS keying material exporter to generate data to be signed
	(see {{client}}) then sends the signature using the Authorization (or	(see {{client}}) then sends the signature using the Authorization (or
	Proxy-Authorization) header field (see {{Section 11 of HTTP}}). The signature	Proxy-Authorization) header field (see {{Section 11 of HTTP}}). The signature
	and additional information are exchanged using authentication parameters (see	and additional information are exchanged using authentication parameters (see

	skipping to change at line 195 ¶	skipping to change at line 171 ¶

	Note that TLS 1.3 keying material exporters are defined in {{Section 7.5 of	Note that TLS 1.3 keying material exporters are defined in {{Section 7.5 of
	TLS}}, while TLS 1.2 keying material exporters are defined in	TLS}}, while TLS 1.2 keying material exporters are defined in
	{{!KEY-EXPORT=RFC5705}}.	{{!KEY-EXPORT=RFC5705}}.

	## Key Exporter Context {#context}	## Key Exporter Context {#context}

	The TLS key exporter context is described in {{fig-context}}, using the	The TLS key exporter context is described in {{fig-context}}, using the
	notation from {{Section 1.3 of QUIC}}:	notation from {{Section 1.3 of QUIC}}:


	<!-- [rfced] Please review sourcecode types within the markdown file, and
	let us know if they should be set and/or have been set correctly.

	The current list of preferred values for sourcecode types is available at
	<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
	If the current list does not contain an applicable type, feel free to
	suggest additions for consideration. Note that it is also acceptable
	to leave the sourcecode type not set.

	~~~	~~~
	Signature Algorithm (16),	Signature Algorithm (16),
	Key ID Length (i),	Key ID Length (i),
	Key ID (..),	Key ID (..),
	Public Key Length (i),	Public Key Length (i),
	Public Key (..),	Public Key (..),
	Scheme Length (i),	Scheme Length (i),
	Scheme (..),	Scheme (..),
	Host Length (i),	Host Length (i),
	Host (..),	Host (..),

	skipping to change at line 227 ¶	skipping to change at line 193 ¶
	Realm (..),	Realm (..),
	~~~	~~~
	{: #fig-context title="Key Exporter Context Format"}	{: #fig-context title="Key Exporter Context Format"}

	The key exporter context contains the following fields:	The key exporter context contains the following fields:

	Signature Algorithm:	Signature Algorithm:

	: The signature scheme sent in the `s` Parameter (see {{parameter-s}}).	: The signature scheme sent in the `s` Parameter (see {{parameter-s}}).


	<!-- [rfced] We see that the capitalization of "Key ID" is inconsistent. Pleas
	e let how we should update it.

	Key ID:	Key ID:

	: The key ID sent in the `k` Parameter (see {{parameter-k}}).	: The key ID sent in the `k` Parameter (see {{parameter-k}}).

	Public Key:	Public Key:

	: The public key used by the server to validate the signature provided by the	: The public key used by the server to validate the signature provided by the
	client. Its encoding is described in {{public-key-encoding}}.	client. Its encoding is described in {{public-key-encoding}}.

	Scheme:	Scheme:

	skipping to change at line 273 ¶	skipping to change at line 236 ¶

	The Signature Algorithm and Port fields are encoded as unsigned 16-bit integer s	The Signature Algorithm and Port fields are encoded as unsigned 16-bit integer s
	in network byte order. The Key ID, Public Key, Scheme, Host, and Realm fields	in network byte order. The Key ID, Public Key, Scheme, Host, and Realm fields
	are length-prefixed strings; they are preceded by a Length field that	are length-prefixed strings; they are preceded by a Length field that
	represents their length in bytes. These length fields are encoded using the	represents their length in bytes. These length fields are encoded using the
	variable-length integer encoding from {{Section 16 of QUIC}} and MUST be	variable-length integer encoding from {{Section 16 of QUIC}} and MUST be
	encoded in the minimum number of bytes necessary.	encoded in the minimum number of bytes necessary.

	### Public Key Encoding {#public-key-encoding}	### Public Key Encoding {#public-key-encoding}


	<!--[rfced] As "Signature Algorithm" is being used in a general way and not as
	a field name, may we make it lowercase in this sentence?

	Original:
	The encoding of the public key is determined by the Signature
	Algorithm in use as follows:

	Perhaps:
	The encoding of the public key is determined by the signature
	algorithm in use as follows:

	Both the "Public Key" field of the TLS key exporter context (see above) and th e	Both the "Public Key" field of the TLS key exporter context (see above) and th e
	`a` Parameter (see {{parameter-a}}) carry the same public key. The encoding of	`a` Parameter (see {{parameter-a}}) carry the same public key. The encoding of

	the public key is determined by the Signature Algorithm in use as follows:	the public key is determined by the signature algorithm in use as follows:

	<!--[rfced] For clarity, may we update "which" to "that" here? It depends on t
	he
	intended meaning, as noted below.

	Original:
	The public key is an RSAPublicKey structure
	[PKCS1] encoded in DER [X.690]. BER encodings which are not DER
	MUST be rejected.

	Perhaps (restrictive "that", meaning some BER encodings):
	The public key is an RSAPublicKey structure
	[PKCS1] encoded in DER [X.690]. BER encodings that are not DER
	MUST be rejected.

	Or (nonrestrictive "which", meaning all BER encodings):
	The public key is an RSAPublicKey structure
	[PKCS1] encoded in DER [X.690]. BER encodings, which are not DER,
	MUST be rejected.

	RSASSA-PSS algorithms:	RSASSA-PSS algorithms:

	: The public key is an RSAPublicKey structure {{!PKCS1=RFC8017}} encoded in DE R	: The public key is an RSAPublicKey structure {{!PKCS1=RFC8017}} encoded in DE R

	{{X.690}}. BER encodings which are not DER MUST be rejected.	{{X.690}}. BER encodings that are not DER MUST be rejected.

	ECDSA algorithms:	ECDSA algorithms:

	: The public key is an UncompressedPointRepresentation structure defined in	: The public key is an UncompressedPointRepresentation structure defined in
	{{Section 4.2.8.2 of TLS}}, using the curve specified by the SignatureScheme.	{{Section 4.2.8.2 of TLS}}, using the curve specified by the SignatureScheme.

	EdDSA algorithms:	EdDSA algorithms:

	: The public key is the byte string encoding defined in {{!EdDSA=RFC8032}}.	: The public key is the byte string encoding defined in {{!EdDSA=RFC8032}}.


	skipping to change at line 445 ¶	skipping to change at line 377 ¶
	## The v Parameter {#parameter-v}	## The v Parameter {#parameter-v}

	The REQUIRED "v" (verification) Parameter is a byte sequence that specifies th e	The REQUIRED "v" (verification) Parameter is a byte sequence that specifies th e
	verification that the client provides to attest to possessing the key exporter	verification that the client provides to attest to possessing the key exporter
	output (see {{output}} for details). This avoids issues with signature schemes	output (see {{output}} for details). This avoids issues with signature schemes
	where certain keys can generate signatures that are valid for multiple inputs	where certain keys can generate signatures that are valid for multiple inputs
	(see {{SEEMS-LEGIT}}).	(see {{SEEMS-LEGIT}}).

	# Example {#example}	# Example {#example}


	<!-- [rfced] We having difficulty parsing the following sentence.	For example, a client using the key ID "basement" and the signature algorithm
	Does the key ID authenticate or does the client?	Ed25519 {{?ED25519=RFC8410}} could produce the following header field:

	Current:
	For example, the key ID "basement" authenticating using Ed25519
	[ED25519] could produce the following header field

	Perhaps:
	For example, a client authenticating with the key ID "basement"
	and using Ed25519 [ED25519] could produce the following header
	field

	For example, the key ID "basement" authenticating using Ed25519
	{{?ED25519=RFC8410}} could produce the following header field:

	~~~ http-message	~~~ http-message
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	Authorization: Concealed \	Authorization: Concealed \
	k=YmFzZW1lbnQ, \	k=YmFzZW1lbnQ, \
	a=VGhpcyBpcyBh-HB1YmxpYyBrZXkgaW4gdXNl_GhlcmU, \	a=VGhpcyBpcyBh-HB1YmxpYyBrZXkgaW4gdXNl_GhlcmU, \
	s=2055, \	s=2055, \
	v=dmVyaWZpY2F0aW9u_zE2Qg, \	v=dmVyaWZpY2F0aW9u_zE2Qg, \
	p=QzpcV2luZG93c_xTeXN0ZW0zMlxkcml2ZXJz-ENyb3dkU\	p=QzpcV2luZG93c_xTeXN0ZW0zMlxkcml2ZXJz-ENyb3dkU\

	skipping to change at line 492 ¶	skipping to change at line 411 ¶
	accepted key identifiers and public keys.	accepted key identifiers and public keys.

	In most deployments, we expect both the frontend and backend roles to be	In most deployments, we expect both the frontend and backend roles to be
	implemented in a single HTTP origin server (as defined in {{Section 3.6 of	implemented in a single HTTP origin server (as defined in {{Section 3.6 of
	HTTP}}). However, these roles can be split such that the frontend is an HTTP	HTTP}}). However, these roles can be split such that the frontend is an HTTP
	gateway (as defined in {{Section 3.7 of HTTP}}) and the backend is an HTTP	gateway (as defined in {{Section 3.7 of HTTP}}) and the backend is an HTTP
	origin server.	origin server.

	## Frontend Handling	## Frontend Handling


	If a frontend is configured to check the Concealed authentication scheme, it	If a frontend is configured to check the Concealed HTTP authentication scheme, it
	will parse the Authorization (or Proxy-Authorization) header field. If the	will parse the Authorization (or Proxy-Authorization) header field. If the
	authentication scheme is set to "Concealed", the frontend MUST validate that	authentication scheme is set to "Concealed", the frontend MUST validate that
	all the required authentication parameters are present and can be parsed	all the required authentication parameters are present and can be parsed
	correctly as defined in {{auth-params}}. If any parameter is missing or fails	correctly as defined in {{auth-params}}. If any parameter is missing or fails
	to parse, the frontend MUST ignore the entire Authorization (or	to parse, the frontend MUST ignore the entire Authorization (or
	Proxy-Authorization) header field.	Proxy-Authorization) header field.

	The frontend then uses the data from these authentication parameters to comput e	The frontend then uses the data from these authentication parameters to comput e
	the key exporter output, as defined in {{output}}. The frontend then shares th e	the key exporter output, as defined in {{output}}. The frontend then shares th e
	header field and the key exporter output with the backend.	header field and the key exporter output with the backend.

	## Communication Between Frontend and Backend	## Communication Between Frontend and Backend

	If the frontend and backend roles are implemented in the same machine, this ca n	If the frontend and backend roles are implemented in the same machine, this ca n
	be handled by a simple function call.	be handled by a simple function call.


	<!-- [rfced] RFC 8941 has been obsoleted by RFC 9651. May we replace RFC
	8941 with RFC 9651?

	If the roles are split between two separate HTTP servers, then the backend	If the roles are split between two separate HTTP servers, then the backend
	won't be able to directly access the TLS keying material exporter from the TLS	won't be able to directly access the TLS keying material exporter from the TLS
	connection between the client and frontend, so the frontend needs to explicitl y	connection between the client and frontend, so the frontend needs to explicitl y
	send it. This document defines the "Concealed-Auth-Export" request header fiel d	send it. This document defines the "Concealed-Auth-Export" request header fiel d
	for this purpose. The Concealed-Auth-Export header field's value is a	for this purpose. The Concealed-Auth-Export header field's value is a
	Structured Field Byte Sequence (see {{Section 3.3.5 of	Structured Field Byte Sequence (see {{Section 3.3.5 of

	!STRUCTURED-FIELDS=RFC8941}}) that contains the 48-byte key exporter output	!STRUCTURED-FIELDS=RFC9651}}) that contains the 48-byte key exporter output
	(see {{output}}), without any parameters. Note that Structured Field Byte	(see {{output}}), without any parameters. Note that Structured Field Byte
	Sequences are encoded using the non-URL-safe variant of base64. For example:	Sequences are encoded using the non-URL-safe variant of base64. For example:

	~~~ http-message	~~~ http-message
	NOTE: '\' line wrapping per RFC 8792	NOTE: '\' line wrapping per RFC 8792

	Concealed-Auth-Export: :VGhpc+BleGFtcGxlIFRMU/BleHBvcn\	Concealed-Auth-Export: :VGhpc+BleGFtcGxlIFRMU/BleHBvcn\
	Rlc+BvdXRwdXQ/aXMgNDggYnl0ZXMgI/+h:	Rlc+BvdXRwdXQ/aXMgNDggYnl0ZXMgI/+h:
	~~~	~~~
	{: #fig-int-hdr-example title="Example Concealed-Auth-Export Header Field"}	{: #fig-int-hdr-example title="Example Concealed-Auth-Export Header Field"}

	skipping to change at line 610 ¶	skipping to change at line 525 ¶
	{{!TLS=RFC8446}}. This includes any use of HTTP over TLS as typically used for	{{!TLS=RFC8446}}. This includes any use of HTTP over TLS as typically used for
	HTTP/2 {{H2}}, or HTTP/3 {{H3}} where the transport protocol uses TLS as its	HTTP/2 {{H2}}, or HTTP/3 {{H3}} where the transport protocol uses TLS as its
	authentication and key exchange mechanism {{?QUIC-TLS=RFC9001}}.	authentication and key exchange mechanism {{?QUIC-TLS=RFC9001}}.

	Because the TLS keying material exporter is only secure for authentication whe n	Because the TLS keying material exporter is only secure for authentication whe n
	it is uniquely bound to the TLS session {{!RFC7627}}, the Concealed	it is uniquely bound to the TLS session {{!RFC7627}}, the Concealed
	authentication scheme requires either one of the following properties:	authentication scheme requires either one of the following properties:

	* The TLS version in use is greater than or equal to 1.3 {{TLS}}.	* The TLS version in use is greater than or equal to 1.3 {{TLS}}.


	<!-- [rfced] Please review the "Inclusive Language" portion of the online
	Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	and let us know if any changes are needed. Updates of this nature typically
	result in more precise language, which is helpful for readers.

	* The TLS version in use is 1.2, and the extended master secret extension	* The TLS version in use is 1.2, and the extended master secret extension
	{{RFC7627}} has been negotiated.	{{RFC7627}} has been negotiated.


	Clients MUST NOT use the Concealed authentication scheme on connections that d o	Clients MUST NOT use the Concealed HTTP authentication scheme on connections t hat do
	not meet one of the two properties above. If a server receives a request that	not meet one of the two properties above. If a server receives a request that
	uses this authentication scheme on a connection that meets neither of the abov e	uses this authentication scheme on a connection that meets neither of the abov e
	properties, the server MUST treat the request as if the authentication were no t	properties, the server MUST treat the request as if the authentication were no t
	present.	present.

	# Security Considerations {#security}	# Security Considerations {#security}

	The Concealed HTTP authentication scheme allows a client to authenticate to an	The Concealed HTTP authentication scheme allows a client to authenticate to an
	origin server while guaranteeing freshness and without the need for the server	origin server while guaranteeing freshness and without the need for the server
	to transmit a nonce to the client. This allows the server to accept	to transmit a nonce to the client. This allows the server to accept

	skipping to change at line 747 ¶	skipping to change at line 656 ¶
	{:numbered="false"}	{:numbered="false"}

	The authors would like to thank many members of the IETF community, as this	The authors would like to thank many members of the IETF community, as this
	document is the fruit of many hallway conversations. In particular, the author s	document is the fruit of many hallway conversations. In particular, the author s
	would like to thank {{{David Benjamin}}}, {{{Reese Enghardt}}}, {{{Nick	would like to thank {{{David Benjamin}}}, {{{Reese Enghardt}}}, {{{Nick
	Harper}}}, {{{Dennis Jackson}}}, {{{Ilari Liusvaara}}}, {{{François Michel}}},	Harper}}}, {{{Dennis Jackson}}}, {{{Ilari Liusvaara}}}, {{{François Michel}}},
	{{{Lucas Pardue}}}, {{{Justin Richer}}}, {{{Ben Schwartz}}}, {{{Martin	{{{Lucas Pardue}}}, {{{Justin Richer}}}, {{{Ben Schwartz}}}, {{{Martin
	Thomson}}}, and {{{Chris A. Wood}}} for their reviews and contributions. The	Thomson}}}, and {{{Chris A. Wood}}} for their reviews and contributions. The
	mechanism described in this document was originally part of the first iteratio n	mechanism described in this document was originally part of the first iteratio n
	of MASQUE {{?MASQUE-ORIGINAL=I-D.schinazi-masque-00}}.	of MASQUE {{?MASQUE-ORIGINAL=I-D.schinazi-masque-00}}.


	<!--[rfced] References. May we add the following URL to this reference for the
	ease of the reader?

	https://www.itu.int/rec/T-REC-X.690

	Current:

	[X.690] ITU-T, "Information technology - ASN.1 encoding Rules:
	Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X690, ISO/IEC 8825-1:2021,
	February 2021.

End of changes. 16 change blocks.
	92 lines changed or deleted	8 lines changed or added
This html diff was produced by rfcdiff 1.48.