Diff: rfc9729v2.txt - rfc9729.txt

	rfc9729v2.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 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

	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>.
	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]).


	skipping to change at line 586 ¶	skipping to change at line 585 ¶
	http-authschemes>:	http-authschemes>:

	Authentication Scheme Name: Concealed	Authentication Scheme Name: Concealed
	Reference: RFC 9729	Reference: RFC 9729
	Notes: None	Notes: None

	9.2. TLS Keying Material Exporter Labels	9.2. TLS Keying Material Exporter Labels

	IANA has registered the following entry in the "TLS Exporter Labels"	IANA has registered the following entry in the "TLS Exporter Labels"
	registry maintained at <https://www.iana.org/assignments/tls-	registry maintained at <https://www.iana.org/assignments/tls-

	parameters#exporter-labels>:	parameters>:

	Value: EXPORTER-HTTP-Concealed-Authentication	Value: EXPORTER-HTTP-Concealed-Authentication
	DTLS-OK: N	DTLS-OK: N
	Recommended: Y	Recommended: Y
	Reference: RFC 9729	Reference: RFC 9729

	9.3. HTTP Field Name	9.3. HTTP Field Name

	IANA has registered the following entry in the "Hypertext Transfer	IANA has registered the following entry in the "Hypertext Transfer
	Protocol (HTTP) Field Name Registry" maintained at	Protocol (HTTP) Field Name Registry" maintained at

	<https://www.iana.org/assignments/http-fields/http-fields.xhtml>:	<https://www.iana.org/assignments/http-fields>:

	Field Name: Concealed-Auth-Export	Field Name: Concealed-Auth-Export
	Status: permanent	Status: permanent
	Structured Type: Item	Structured Type: Item
	Reference: RFC 9729	Reference: RFC 9729
	Comments: None	Comments: None

	10. References	10. References

	10.1. Normative References	10.1. Normative References

	[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax	[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,	Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,	DOI 10.17487/RFC5234, January 2008,

	<https://www.rfc-editor.org/rfc/rfc5234>.	<https://www.rfc-editor.org/info/rfc5234>.

	[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data	[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,

	<https://www.rfc-editor.org/rfc/rfc4648>.	<https://www.rfc-editor.org/info/rfc4648>.

	[EdDSA] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital	[EdDSA] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
	Signature Algorithm (EdDSA)", RFC 8032,	Signature Algorithm (EdDSA)", RFC 8032,
	DOI 10.17487/RFC8032, January 2017,	DOI 10.17487/RFC8032, January 2017,

	<https://www.rfc-editor.org/rfc/rfc8032>.	<https://www.rfc-editor.org/info/rfc8032>.

	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,	Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,	DOI 10.17487/RFC9110, June 2022,

	<https://www.rfc-editor.org/rfc/rfc9110>.	<https://www.rfc-editor.org/info/rfc9110>.

	[KEY-EXPORT]	[KEY-EXPORT]
	Rescorla, E., "Keying Material Exporters for Transport	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/rfc/rfc5705>.	March 2010, <https://www.rfc-editor.org/info/rfc5705>.

	[PKCS1] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,	[PKCS1] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
	"PKCS #1: RSA Cryptography Specifications Version 2.2",	"PKCS #1: RSA Cryptography Specifications Version 2.2",
	RFC 8017, DOI 10.17487/RFC8017, November 2016,	RFC 8017, DOI 10.17487/RFC8017, November 2016,

	<https://www.rfc-editor.org/rfc/rfc8017>.	<https://www.rfc-editor.org/info/rfc8017>.

	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,	Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,	DOI 10.17487/RFC9000, May 2021,

	<https://www.rfc-editor.org/rfc/rfc9000>.	<https://www.rfc-editor.org/info/rfc9000>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,

	<https://www.rfc-editor.org/rfc/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,	[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
	Langley, A., and M. Ray, "Transport Layer Security (TLS)	Langley, A., and M. Ray, "Transport Layer Security (TLS)
	Session Hash and Extended Master Secret Extension",	Session Hash and Extended Master Secret Extension",
	RFC 7627, DOI 10.17487/RFC7627, September 2015,	RFC 7627, DOI 10.17487/RFC7627, September 2015,

	<https://www.rfc-editor.org/rfc/rfc7627>.	<https://www.rfc-editor.org/info/rfc7627>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	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/info/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/info/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 9651, DOI 10.17487/RFC9651, September 2024,	HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,

	<https://www.rfc-editor.org/rfc/rfc9651>.	<https://www.rfc-editor.org/info/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/info/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/info/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, <https://www.itu.int/rec/T-REC-X.690>.	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/info/rfc8410>.

	[HOBA] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-	[HOBA] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-
	Bound Authentication (HOBA)", RFC 7486,	Bound Authentication (HOBA)", RFC 7486,
	DOI 10.17487/RFC7486, March 2015,	DOI 10.17487/RFC7486, March 2015,

	<https://www.rfc-editor.org/rfc/rfc7486>.	<https://www.rfc-editor.org/info/rfc7486>.

	[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,	[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
	DOI 10.17487/RFC9113, June 2022,	DOI 10.17487/RFC9113, June 2022,

	<https://www.rfc-editor.org/rfc/rfc9113>.	<https://www.rfc-editor.org/info/rfc9113>.

	[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,	[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,

	June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.	June 2022, <https://www.rfc-editor.org/info/rfc9114>.

	[MASQUE-ORIGINAL]	[MASQUE-ORIGINAL]
	Schinazi, D., "The MASQUE Protocol", Work in Progress,	Schinazi, D., "The MASQUE Protocol", Work in Progress,
	Internet-Draft, draft-schinazi-masque-00, 28 February	Internet-Draft, draft-schinazi-masque-00, 28 February
	2019, <https://datatracker.ietf.org/doc/html/draft-	2019, <https://datatracker.ietf.org/doc/html/draft-
	schinazi-masque-00>.	schinazi-masque-00>.

	[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure	[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,

	<https://www.rfc-editor.org/rfc/rfc9001>.	<https://www.rfc-editor.org/info/rfc9001>.

	[SEEMS-LEGIT]	[SEEMS-LEGIT]
	Jackson, D., Cremers, C., Cohn-Gordon, K., and R. Sasse,	Jackson, D., Cremers, C., Cohn-Gordon, K., and R. Sasse,
	"Seems Legit: Automated Analysis of Subtle Attacks on	"Seems Legit: Automated Analysis of Subtle Attacks on
	Protocols That Use Signatures", CCS '19: Proceedings of	Protocols That Use Signatures", CCS '19: Proceedings of
	the 2019 ACM SIGSAC Conference on Computer and	the 2019 ACM SIGSAC Conference on Computer and
	Communications Security, pp. 2165-2180,	Communications Security, pp. 2165-2180,
	DOI 10.1145/3319535.3339813, November 2019,	DOI 10.1145/3319535.3339813, November 2019,
	<https://doi.org/10.1145/3319535.3339813>.	<https://doi.org/10.1145/3319535.3339813>.


End of changes. 25 change blocks.
	32 lines changed or deleted	31 lines changed or added
This html diff was produced by rfcdiff 1.48.