draft-ietf-httpbis-unprompted-auth-10.txt		draft-ietf-httpbis-unprompted-auth-latest.txt
	HTTPBIS Working Group D. Schinazi		HTTPBIS Working Group D. Schinazi
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Intended status: Standards Track D. Oliver		Intended status: Standards Track D. Oliver
	Expires: March 1, 2025 Guardian Project		Expires: March 15, 2025 Guardian Project
	J. Hoyland		J. Hoyland
	Cloudflare Inc.		Cloudflare Inc.
	August 28, 2024		September 11, 2024
	The Concealed HTTP Authentication Scheme		The Concealed HTTP Authentication Scheme
	draft-ietf-httpbis-unprompted-auth-10		draft-ietf-httpbis-unprompted-auth-latest
	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
	non-cryptographic authentication schemes: cryptographic signatures		non-cryptographic authentication schemes: cryptographic signatures
	require a fresh nonce to be signed. At the time of writing, there		require a fresh nonce to be signed. Prior to this document, there
	was no existing way for the origin to share such a nonce without		was no existing way for the origin to share such a nonce without
	exposing the fact that it serves resources that require		exposing the fact that it serves resources that require
	authentication. This document proposes a new non-probeable		authentication. This document defines a new non-probeable
	cryptographic authentication scheme.		cryptographic authentication scheme.
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	The latest revision of this draft can be found at		The latest revision of this draft can be found at
	<https://httpwg.org/http-extensions/draft-ietf-httpbis-unprompted-		<https://httpwg.org/http-extensions/draft-ietf-httpbis-unprompted-
	auth.html>. Status information for this document may be found at		auth.html>. Status information for this document may be found at
	<https://datatracker.ietf.org/doc/draft-ietf-httpbis-unprompted-		<https://datatracker.ietf.org/doc/draft-ietf-httpbis-unprompted-
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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 March 1, 2025.		This Internet-Draft will expire on March 15, 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	asks the client to provide authentication information, it is possible		asks the client to provide authentication information, it is possible
	for clients to send such information unprompted. This is		for clients to send such information unprompted. This is
	particularly useful in cases where an origin wants to offer a service		particularly useful in cases where an origin wants to offer a service
	or capability only to "those who know" while all others are given no		or capability only to "those who know" while all others are given no
	indication the service or capability exists. Such designs rely on an		indication the service or capability exists. Such designs rely on an
	externally-defined mechanism by which keys are distributed. For		externally-defined mechanism by which keys are distributed. For
	example, a company might offer remote employee access to company		example, a company might offer remote employee access to company
	services directly via its website using their employee credentials,		services directly via its website using their employee credentials,
	or offer access to limited special capabilities for specific		or offer access to limited special capabilities for specific
	employees, while making discovering (or probing for) such		employees, while making discovering (or probing for) such
	capabilities difficult. Members of less well-defined communities		capabilities difficult. As another example, members of less well-
	might use more ephemeral keys to acquire access to geography- or		defined communities might use more ephemeral keys to acquire access
	capability-specific resources, as issued by an entity whose user base		to geography- or capability-specific resources, as issued by an
	is larger than the available resources can support (by having that		entity whose user base is larger than the available resources can
	entity metering the availability of keys temporally or		support (by having that entity metering the availability of keys
	geographically).		temporally or geographically).
	While digital-signature-based HTTP authentication schemes already		While digital-signature-based HTTP authentication schemes already
	exist (e.g., [HOBA]), they rely on the origin explicitly sending a		exist (e.g., [HOBA]), they rely on the origin explicitly sending a
	fresh challenge to the client, to ensure that the signature input is		fresh challenge to the client, to ensure that the signature input is
	fresh. That makes the origin probeable as it sends the challenge to		fresh. That makes the origin probeable as it sends the challenge to
	unauthenticated clients. This document defines a new signature-based		unauthenticated clients. This document defines a new signature-based
	authentication scheme that is not probeable.		authentication scheme that is not probeable.
	1.1. Conventions and Definitions		1.1. Conventions and Definitions
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	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].
	2. The Concealed Authentication Scheme		2. The Concealed 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 their 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. The signature and		Authorization (or Proxy-Authorization) header field (see Section 11
	additional information are exchanged using authentication parameters		of [HTTP]). The signature and additional information are exchanged
	(see Section 4).		using authentication parameters (see Section 4). Once the server
			receives these, it can check whether the signature validates against
			an entry in its database of known keys. The server can then use the
			validation result to influence its response to the client, for
			example by restricting access to certain resources.
	3. Client Handling		3. Client Handling
	When a client wishes to uses the Concealed HTTP authentication scheme		When a client wishes to use the Concealed HTTP authentication scheme
	with a request, it SHALL compute the authentication proof using a TLS		with a request, it SHALL compute the authentication proof using a TLS
	keying material exporter with the following parameters:		keying material exporter with the following parameters:
	o the label is set to "EXPORTER-HTTP-Concealed-Authentication"		o the label is set to "EXPORTER-HTTP-Concealed-Authentication"
	o the context is set to the structure described in Section 3.1		o the context is set to the structure described in Section 3.1
	o the exporter output length is set to 48 bytes (see Section 3.2)		o the exporter output length is set to 48 bytes (see Section 3.2)
	Note that TLS 1.3 keying material exporters are defined in		Note that TLS 1.3 keying material exporters are defined in
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 16 ¶
	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
	can, for example, be used to point to an entry in a server-side		is used by the backend to point to an entry in a server-side database
	database of known keys.		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
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 4 ¶
	Reference: This document		Reference: This document
	9.3. HTTP Field Name		9.3. HTTP Field Name
	This document, if approved, requests IANA to register the following		This document, if approved, requests IANA to register the following
	entry in the "Hypertext Transfer Protocol (HTTP) Field Name" registry		entry in the "Hypertext Transfer Protocol (HTTP) Field Name" registry
	maintained at <<https://www.iana.org/assignments/http-fields/http-		maintained at <<https://www.iana.org/assignments/http-fields/http-
	fields.xhtml>>:		fields.xhtml>>:
	Field Name: Concealed-Auth-Export		Field Name: Concealed-Auth-Export
	Template: None
	Status: permanent		Status: permanent
			Structured Type: Item
			Template: None
	Reference: This document		Reference: This document
	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,
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 31 ¶
	"Seems Legit: Automated Analysis of Subtle Attacks on		"Seems Legit: Automated Analysis of Subtle Attacks on
	Protocols That Use Signatures",		Protocols That Use Signatures",
	DOI 10.1145/3319535.3339813, CCS '19: Proceedings of the		DOI 10.1145/3319535.3339813, CCS '19: Proceedings of the
	2019 ACM SIGSAC Conference on Computer and Communications		2019 ACM SIGSAC Conference on Computer and Communications
	Security, pp. 2165-2180, 2019.		Security, pp. 2165-2180, 2019.
	Acknowledgments		Acknowledgments
	The authors would like to thank many members of the IETF community,		The authors would like to thank many members of the IETF community,
	as this document is the fruit of many hallway conversations. In		as this document is the fruit of many hallway conversations. In
	particular, the authors would like to thank David Benjamin, Nick		particular, the authors would like to thank David Benjamin, Reese
	Harper, Dennis Jackson, Ilari Liusvaara, Francois Michel, Lucas		Enghardt, Nick Harper, Dennis Jackson, Ilari Liusvaara, Francois
	Pardue, Justin Richer, Ben Schwartz, Martin Thomson, and Chris A.		Michel, Lucas Pardue, Justin Richer, Ben Schwartz, Martin Thomson,
	Wood for their reviews and contributions. The mechanism described in		and Chris A. Wood for their reviews and contributions. The
	this document was originally part of the first iteration of MASQUE		mechanism described in this document was originally part of the first
	[MASQUE-ORIGINAL].		iteration of MASQUE [MASQUE-ORIGINAL].
	Authors' Addresses		Authors' Addresses
	David Schinazi		David Schinazi
	Google LLC		Google LLC
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, CA 94043		Mountain View, CA 94043
	United States of America		United States of America
	Email: dschinazi.ietf@gmail.com		Email: dschinazi.ietf@gmail.com
End of changes. 14 change blocks.
	26 lines changed or deleted		31 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/