Diff: rfc9729v1.txt - rfc9729.txt

	rfc9729v1.txt	rfc9729.txt

	Internet Engineering Task Force (IETF) D. Schinazi	Internet Engineering Task Force (IETF) D. Schinazi
	Request for Comments: 9729 Google LLC	Request for Comments: 9729 Google LLC
	Category: Standards Track D. Oliver	Category: Standards Track D. Oliver
	ISSN: 2070-1721 Guardian Project	ISSN: 2070-1721 Guardian Project
	J. Hoyland	J. Hoyland
	Cloudflare Inc.	Cloudflare Inc.

	January 2025	February 2025

	The Concealed HTTP Authentication Scheme	The Concealed HTTP Authentication Scheme

	Abstract	Abstract

	Most HTTP authentication schemes are probeable in the sense that it	Most HTTP authentication schemes are probeable in the sense that it
	is possible for an unauthenticated client to probe whether an origin	is possible for an unauthenticated client to probe whether an origin
	serves resources that require authentication. It is possible for an	serves resources that require authentication. It is possible for an
	origin to hide the fact that it requires authentication by not	origin to hide the fact that it requires authentication by not
	generating Unauthorized status codes; however, that only works with	generating Unauthorized status codes; however, that only works with

	skipping to change at line 59 ¶	skipping to change at line 59 ¶
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the	include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described	Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.	in the Revised BSD License.

	Table of Contents	Table of Contents

	1. Introduction	1. Introduction
	1.1. Conventions and Definitions	1.1. Conventions and Definitions

	2. The Concealed Authentication Scheme	2. The Concealed HTTP Authentication Scheme
	3. Client Handling	3. Client Handling
	3.1. Key Exporter Context	3.1. Key Exporter Context
	3.1.1. Public Key Encoding	3.1.1. Public Key Encoding
	3.2. Key Exporter Output	3.2. Key Exporter Output
	3.3. Signature Computation	3.3. Signature Computation
	4. Authentication Parameters	4. Authentication Parameters
	4.1. The k Parameter	4.1. The k Parameter
	4.2. The a Parameter	4.2. The a Parameter
	4.3. The p Parameter	4.3. The p Parameter
	4.4. The s Parameter	4.4. The s Parameter

	skipping to change at line 131 ¶	skipping to change at line 131 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	This document uses the notation from Section 1.3 of [QUIC].	This document uses the notation from Section 1.3 of [QUIC].

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


	2. The Concealed Authentication Scheme	2. The Concealed HTTP Authentication Scheme

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

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

	skipping to change at line 206 ¶	skipping to change at line 206 ¶
	scheme portion of a URI as defined in Section 3.1 of [URI].	scheme portion of a URI as defined in Section 3.1 of [URI].

	Host: The host for this request, encoded using the format of the	Host: The host for this request, encoded using the format of the
	host portion of a URI as defined in Section 3.2.2 of [URI].	host portion of a URI as defined in Section 3.2.2 of [URI].

	Port: The port for this request, encoded in network byte order.	Port: The port for this request, encoded in network byte order.
	Note that the port is either included in the URI or is the default	Note that the port is either included in the URI or is the default
	port for the scheme in use; see Section 3.2.3 of [URI].	port for the scheme in use; see Section 3.2.3 of [URI].

	Realm: The realm of authentication that is sent in the realm	Realm: The realm of authentication that is sent in the realm

	authentication parameter (Section 11.5 of [HTTP]). If the realm	authentication parameter (see Section 11.5 of [HTTP]). If the
	authentication parameter is not present, this SHALL be empty.	realm authentication parameter is not present, this SHALL be
	This document does not define a means for the origin to	empty. This document does not define a means for the origin to
	communicate a realm to the client. If a client is not configured	communicate a realm to the client. If a client is not configured
	to use a specific realm, it SHALL use an empty realm and SHALL NOT	to use a specific realm, it SHALL use an empty realm and SHALL NOT
	send the realm authentication parameter.	send the realm authentication parameter.

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

	3.1.1. Public Key Encoding	3.1.1. Public Key Encoding

	Both the "Public Key" field of the TLS key exporter context (see	Both the "Public Key" field of the TLS key exporter context (see
	above) and the a Parameter (see Section 4.2) carry the same public	above) and the a Parameter (see Section 4.2) carry the same public

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

	RSASSA-PSS algorithms: The public key is an RSAPublicKey structure	RSASSA-PSS algorithms: The public key is an RSAPublicKey structure

	[PKCS1] encoded in DER [X.690]. BER encodings which are not DER	[PKCS1] encoded in DER [X.690]. BER encodings that are not DER
	MUST be rejected.	MUST be rejected.

	ECDSA algorithms: The public key is an	ECDSA algorithms: The public key is an
	UncompressedPointRepresentation structure defined in	UncompressedPointRepresentation structure defined in
	Section 4.2.8.2 of [TLS], using the curve specified by the	Section 4.2.8.2 of [TLS], using the curve specified by the
	SignatureScheme.	SignatureScheme.

	EdDSA algorithms: The public key is the byte string encoding defined	EdDSA algorithms: The public key is the byte string encoding defined
	in [EdDSA].	in [EdDSA].


	skipping to change at line 329 ¶	skipping to change at line 329 ¶
	concealed-byte-sequence-param-value = *( ALPHA / DIGIT / "-" / "_" )	concealed-byte-sequence-param-value = *( ALPHA / DIGIT / "-" / "_" )
	concealed-integer-param-value = %x31-39 1*4( DIGIT ) / "0"	concealed-integer-param-value = %x31-39 1*4( DIGIT ) / "0"

	Figure 4: Authentication Parameter Value ABNF	Figure 4: Authentication Parameter Value ABNF

	4.1. The k Parameter	4.1. The k Parameter

	The REQUIRED "k" (key ID) Parameter is a byte sequence that	The REQUIRED "k" (key ID) Parameter is a byte sequence that
	identifies which key the client wishes to use to authenticate. This	identifies which key the client wishes to use to authenticate. This
	is used by the backend to point to an entry in a server-side database	is used by the backend to point to an entry in a server-side database

	of known keys; see Section 6.3.	of known keys (see Section 6.3).

	4.2. The a Parameter	4.2. The a Parameter

	The REQUIRED "a" (public key) Parameter is a byte sequence that	The REQUIRED "a" (public key) Parameter is a byte sequence that
	specifies the public key used by the server to validate the signature	specifies the public key used by the server to validate the signature
	provided by the client. This avoids key confusion issues (see	provided by the client. This avoids key confusion issues (see
	[SEEMS-LEGIT]). The encoding of the public key is described in	[SEEMS-LEGIT]). The encoding of the public key is described in
	Section 3.1.1.	Section 3.1.1.

	4.3. The p Parameter	4.3. The p Parameter

	The REQUIRED "p" (proof) Parameter is a byte sequence that specifies	The REQUIRED "p" (proof) Parameter is a byte sequence that specifies
	the proof that the client provides to attest to possessing the	the proof that the client provides to attest to possessing the
	credential that matches its key ID.	credential that matches its key ID.

	4.4. The s Parameter	4.4. The s Parameter


	The REQUIRED "s" (signature) Parameter is an integer that specifies	The REQUIRED "s" (signature scheme) Parameter is an integer that
	the signature scheme used to compute the proof transmitted in the p	specifies the signature scheme used to compute the proof transmitted
	Parameter. Its value is an integer between 0 and 65535 inclusive	in the p Parameter. Its value is an integer between 0 and 65535
	from the IANA "TLS SignatureScheme" registry maintained at	inclusive from the IANA "TLS SignatureScheme" registry maintained at
	<https://www.iana.org/assignments/tls-parameters/tls-	<https://www.iana.org/assignments/tls-parameters/tls-
	parameters.xhtml#tls-signaturescheme>.	parameters.xhtml#tls-signaturescheme>.

	4.5. The v Parameter	4.5. The v Parameter

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

	5. Example	5. Example


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

	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\
	3RyaWtlXEMtMDAwMDAwMDAyOTEtMD-wMC0w_DAwLnN5cw	3RyaWtlXEMtMDAwMDAwMDAyOTEtMD-wMC0w_DAwLnN5cw

	skipping to change at line 398 ¶	skipping to change at line 398 ¶
	database of accepted key identifiers and public keys.	database of accepted key identifiers and public keys.

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

	6.1. Frontend Handling	6.1. Frontend Handling


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

	The frontend then uses the data from these authentication parameters	The frontend then uses the data from these authentication parameters
	to compute the key exporter output, as defined in Section 3.2. The	to compute the key exporter output, as defined in Section 3.2. The
	frontend then shares the header field and the key exporter output	frontend then shares the header field and the key exporter output
	with the backend.	with the backend.

	6.2. Communication Between Frontend and Backend	6.2. Communication Between Frontend and Backend

	If the frontend and backend roles are implemented in the same	If the frontend and backend roles are implemented in the same

	skipping to change at line 523 ¶	skipping to change at line 523 ¶
	Because the TLS keying material exporter is only secure for	Because the TLS keying material exporter is only secure for
	authentication when it is uniquely bound to the TLS session	authentication when it is uniquely bound to the TLS session
	[RFC7627], the Concealed authentication scheme requires either one of	[RFC7627], the Concealed authentication scheme requires either one of
	the following properties:	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].

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


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

	8. Security Considerations	8. Security Considerations

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

	skipping to change at line 665 ¶	skipping to change at line 665 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

	[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,	[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
	"Handling Long Lines in Content of Internet-Drafts and	"Handling Long Lines in Content of Internet-Drafts and
	RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,	RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
	<https://www.rfc-editor.org/rfc/rfc8792>.	<https://www.rfc-editor.org/rfc/rfc8792>.

	[STRUCTURED-FIELDS]	[STRUCTURED-FIELDS]
	Nottingham, M. and P. Kamp, "Structured Field Values for	Nottingham, M. and P. Kamp, "Structured Field Values for

	HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,	HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
	<https://www.rfc-editor.org/rfc/rfc8941>.	<https://www.rfc-editor.org/rfc/rfc9651>.

	[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol	[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/rfc/rfc8446>.	<https://www.rfc-editor.org/rfc/rfc8446>.

	[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform	[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,	Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,	RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/rfc/rfc3986>.	<https://www.rfc-editor.org/rfc/rfc3986>.

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

	February 2021.	February 2021, <https://www.itu.int/rec/T-REC-X.690>.

	10.2. Informative References	10.2. Informative References

	[ED25519] Josefsson, S. and J. Schaad, "Algorithm Identifiers for	[ED25519] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
	Ed25519, Ed448, X25519, and X448 for Use in the Internet	Ed25519, Ed448, X25519, and X448 for Use in the Internet
	X.509 Public Key Infrastructure", RFC 8410,	X.509 Public Key Infrastructure", RFC 8410,
	DOI 10.17487/RFC8410, August 2018,	DOI 10.17487/RFC8410, August 2018,
	<https://www.rfc-editor.org/rfc/rfc8410>.	<https://www.rfc-editor.org/rfc/rfc8410>.

	[HOBA] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-	[HOBA] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-

End of changes. 13 change blocks.
	27 lines changed or deleted	27 lines changed or added
This html diff was produced by rfcdiff 1.48.