draft-ietf-httpbis-unprompted-auth-12.txt   draft-ietf-httpbis-unprompted-auth-latest.txt 
HTTPBIS Working Group D. Schinazi Internet Engineering Task Force (IETF) D. Schinazi
Internet-Draft Google LLC Request for Comments: 9729 Google LLC
Intended status: Standards Track D. Oliver Category: Standards Track D. Oliver
Expires: March 23, 2025 Guardian Project ISSN: 2070-1721 Guardian Project
J. Hoyland J. Hoyland
Cloudflare Inc. Cloudflare Inc.
September 19, 2024 February 2025
The Concealed HTTP Authentication Scheme The Concealed HTTP Authentication Scheme
draft-ietf-httpbis-unprompted-auth-12
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. Prior to this document, 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 defines a new non-probeable authentication. This document defines a new non-probeable
cryptographic authentication scheme. cryptographic authentication scheme.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
<https://httpwg.org/http-extensions/draft-ietf-httpbis-unprompted-
auth.html>. Status information for this document may be found at
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-unprompted-
auth/>.
Discussion of this document takes place on the HTTP Working Group
mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. Working Group
information can be found at <https://httpwg.org/>.
Source for this draft and an issue tracker can be found at
<https://github.com/httpwg/http-extensions/labels/unprompted-auth>.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on March 23, 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9729.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 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
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 Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. The Concealed Authentication Scheme . . . . . . . . . . . . . 4 2. The Concealed HTTP Authentication Scheme . . . . . . . . . . 3
3. Client Handling . . . . . . . . . . . . . . . . . . . . . . . 4 3. Client Handling . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Key Exporter Context . . . . . . . . . . . . . . . . . . 4 3.1. Key Exporter Context . . . . . . . . . . . . . . . . . . 4
3.1.1. Public Key Encoding . . . . . . . . . . . . . . . . . 6 3.1.1. Public Key Encoding . . . . . . . . . . . . . . . . . 5
3.2. Key Exporter Output . . . . . . . . . . . . . . . . . . . 6 3.2. Key Exporter Output . . . . . . . . . . . . . . . . . . . 6
3.3. Signature Computation . . . . . . . . . . . . . . . . . . 7 3.3. Signature Computation . . . . . . . . . . . . . . . . . . 6
4. Authentication Parameters . . . . . . . . . . . . . . . . . . 7 4. Authentication Parameters . . . . . . . . . . . . . . . . . . 7
4.1. The k Parameter . . . . . . . . . . . . . . . . . . . . . 8 4.1. The k Parameter . . . . . . . . . . . . . . . . . . . . . 7
4.2. The a Parameter . . . . . . . . . . . . . . . . . . . . . 8 4.2. The a Parameter . . . . . . . . . . . . . . . . . . . . . 8
4.3. The p Parameter . . . . . . . . . . . . . . . . . . . . . 8 4.3. The p Parameter . . . . . . . . . . . . . . . . . . . . . 8
4.4. The s Parameter . . . . . . . . . . . . . . . . . . . . . 8 4.4. The s Parameter . . . . . . . . . . . . . . . . . . . . . 8
4.5. The v Parameter . . . . . . . . . . . . . . . . . . . . . 8 4.5. The v Parameter . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Server Handling . . . . . . . . . . . . . . . . . . . . . . . 9 6. Server Handling . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Frontend Handling . . . . . . . . . . . . . . . . . . . . 9 6.1. Frontend Handling . . . . . . . . . . . . . . . . . . . . 9
6.2. Communication between Frontend and Backend . . . . . . . 10 6.2. Communication Between Frontend and Backend . . . . . . . 9
6.3. Backend Handling . . . . . . . . . . . . . . . . . . . . 10 6.3. Backend Handling . . . . . . . . . . . . . . . . . . . . 10
6.4. Non-Probeable Server Handling . . . . . . . . . . . . . . 11 6.4. Non-Probeable Server Handling . . . . . . . . . . . . . . 11
7. Requirements on TLS Usage . . . . . . . . . . . . . . . . . . 12 7. Requirements on TLS Usage . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. HTTP Authentication Schemes Registry . . . . . . . . . . 13 9.1. HTTP Authentication Schemes Registry . . . . . . . . . . 13
9.2. TLS Keying Material Exporter Labels . . . . . . . . . . . 13 9.2. TLS Keying Material Exporter Labels . . . . . . . . . . . 13
9.3. HTTP Field Name . . . . . . . . . . . . . . . . . . . . . 13 9.3. HTTP Field Name . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
HTTP authentication schemes (see Section 11 of [HTTP]) allow origins HTTP authentication schemes (see Section 11 of [HTTP]) allow origins
to restrict access for some resources to only authenticated requests. to restrict access for some resources to only authenticated requests.
While these schemes commonly involve a challenge where the origin While these schemes commonly involve a challenge where the origin
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
or offer access to limited special capabilities for specific offer access to limited special capabilities for specific employees
employees, while making discovering (or probing for) such while making discovering (or probing for) such capabilities
capabilities difficult. As another example, members of less well- difficult. As another example, members of less well-defined
defined communities might use more ephemeral keys to acquire access communities might use more ephemeral keys to acquire access to
to geography- or capability-specific resources, as issued by an geography- or capability-specific resources, as issued by an entity
entity whose user base is larger than the available resources can whose user base is larger than the available resources can support
support (by having that entity metering the availability of keys (by having that entity metering the availability of keys temporally
temporally or geographically). 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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].
2. The Concealed Authentication Scheme Various examples in this document contain long lines that may be
folded, as described in [RFC8792].
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
using authentication parameters (see Section 4). Once the server using authentication parameters (see Section 4). Once the server
receives these, it can check whether the signature validates against receives these, it can check whether the signature validates against
an entry in its database of known keys. The server can then use the an entry in its database of known keys. The server can then use the
validation result to influence its response to the client, for validation result to influence its response to the client, for
example by restricting access to certain resources. example, by restricting access to certain resources.
3. Client Handling 3. Client Handling
When a client wishes to use 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
Section 7.5 of [TLS], while TLS 1.2 keying material exporters are Section 7.5 of [TLS], while TLS 1.2 keying material exporters are
defined in [KEY-EXPORT]. defined in [KEY-EXPORT].
3.1. Key Exporter Context 3.1. Key Exporter Context
The TLS key exporter context is described in Figure 1, using the The TLS key exporter context is described in Figure 1, using the
notation from Section 1.3 of [QUIC]: notation from Section 1.3 of [QUIC]:
skipping to change at page 5, line 38 skipping to change at page 5, line 16
signature provided by the client. Its encoding is described in signature provided by the client. Its encoding is described in
Section 3.1.1. Section 3.1.1.
Scheme: The scheme for this request, encoded using the format of the Scheme: The scheme for this request, encoded using the format of the
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 Note that the port is either included in the URI or is the default
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 a 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].
This document does not define the public key encodings for other This document does not define the public key encodings for other
algorithms. In order for a SignatureScheme to be usable with the algorithms. In order for a SignatureScheme to be usable with the
Concealed HTTP authentication scheme, its public key encoding needs Concealed HTTP authentication scheme, its public key encoding needs
skipping to change at page 7, line 15 skipping to change at page 6, line 41
3.3. Signature Computation 3.3. Signature Computation
Once the Signature Input has been extracted from the key exporter Once the Signature Input has been extracted from the key exporter
output (see Section 3.2), it is prefixed with static data before output (see Section 3.2), it is prefixed with static data before
being signed. The signature is computed over the concatenation of: being signed. The signature is computed over the concatenation of:
o A string that consists of octet 32 (0x20) repeated 64 times o A string that consists of octet 32 (0x20) repeated 64 times
o The context string "HTTP Concealed Authentication" o The context string "HTTP Concealed Authentication"
o A single 0 byte which serves as a separator o A single 0 byte that serves as a separator
o The Signature Input extracted from the key exporter output (see o The Signature Input extracted from the key exporter output (see
Section 3.2) Section 3.2)
For example, if the Signature Input has all its 32 bytes set to 01, For example, if the Signature Input has all its 32 bytes set to 01,
the content covered by the signature (in hexadecimal format) would the content covered by the signature (in hexadecimal format) would
be: be:
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
skipping to change at page 7, line 49 skipping to change at page 7, line 30
"p" Parameter (see Section 4.3). "p" Parameter (see Section 4.3).
4. Authentication Parameters 4. Authentication Parameters
This specification defines the following authentication parameters. This specification defines the following authentication parameters.
All of the byte sequences below are encoded using base64url (see All of the byte sequences below are encoded using base64url (see
Section 5 of [BASE64]) without quotes and without padding. In other Section 5 of [BASE64]) without quotes and without padding. In other
words, the values of these byte-sequence authentication parameters words, the values of these byte-sequence authentication parameters
MUST NOT include any characters other than ASCII letters, digits, MUST NOT include any characters other than ASCII letters, digits,
dash and underscore. dash, and underscore.
The integer below is encoded without a minus and without leading The integer below is encoded without a minus and without leading
zeroes. In other words, the value of this integer authentication zeroes. In other words, the value of this integer authentication
parameter MUST NOT include any characters other than digits, and MUST parameter MUST NOT include any characters other than digits and MUST
NOT start with a zero unless the full value is "0". NOT start with a zero unless the full value is "0".
Using the syntax from [ABNF]: Using the syntax from [ABNF]:
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]).
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
Figure 5: Example Header Field Figure 5: Example Header Field
6. Server Handling 6. Server Handling
In this section, we subdivide the server role in two: In this section, we subdivide the server role in two:
o the "frontend" runs in the HTTP server that terminates the TLS or o The "frontend" runs in the HTTP server that terminates the TLS or
QUIC connection created by the client. QUIC connection created by the client.
o the "backend" runs in the HTTP server that has access to the o The "backend" runs in the HTTP server that has access to the
database of accepted key identifiers and public keys. database of accepted key identifiers and public keys.
In most deployments, we expect the frontend and backend roles to both 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
machine, this can be handled by a simple function call. machine, this can be handled by a simple function call.
If the roles are split between two separate HTTP servers, then the If the roles are split between two separate HTTP servers, then the
backend won't be able to directly access the TLS keying material backend won't be able to directly access the TLS keying material
exporter from the TLS connection between the client and frontend, so exporter from the TLS connection between the client and frontend, so
the frontend needs to explictly send it. This document defines the the frontend needs to explicitly send it. This document defines the
"Concealed-Auth-Export" request header field for this purpose. The "Concealed-Auth-Export" request header field for this purpose. The
Concealed-Auth-Export header field's value is a Structured Field Byte Concealed-Auth-Export header field's value is a Structured Field Byte
Sequence (see Section 3.3.5 of [STRUCTURED-FIELDS]) that contains the Sequence (see Section 3.3.5 of [STRUCTURED-FIELDS]) that contains the
48-byte key exporter output (see Section 3.2), without any 48-byte key exporter output (see Section 3.2), without any
parameters. Note that Structured Field Byte Sequences are encoded parameters. Note that Structured Field Byte Sequences are encoded
using the non-URL-safe variant of base64. For example: using the non-URL-safe variant of base64. For example:
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Concealed-Auth-Export: :VGhpc+BleGFtcGxlIFRMU/BleHBvcn\ Concealed-Auth-Export: :VGhpc+BleGFtcGxlIFRMU/BleHBvcn\
skipping to change at page 11, line 21 skipping to change at page 10, line 50
o validate that the public key from the database is equal to the one o validate that the public key from the database is equal to the one
in the Authorization (or Proxy-Authorization) header field in the Authorization (or Proxy-Authorization) header field
o validate that the verification field from the Authorization (or o validate that the verification field from the Authorization (or
Proxy-Authorization) header field matches the one extracted from Proxy-Authorization) header field matches the one extracted from
the key exporter output the key exporter output
o verify the cryptographic signature as defined in Section 3.3 o verify the cryptographic signature as defined in Section 3.3
If all of these checks succeed, the backend can consider the request If all of these checks succeed, the backend can consider the request
to be properly authenticated, and can reply accordingly (the backend to be properly authenticated and can reply accordingly (the backend
can also forward the request to another HTTP server). can also forward the request to another HTTP server).
If any of the above checks fail, the backend MUST treat it as if the If any of the above checks fail, the backend MUST treat it as if the
Authorization (or Proxy-Authorization) header field was missing. Authorization (or Proxy-Authorization) header field was missing.
6.4. Non-Probeable Server Handling 6.4. Non-Probeable Server Handling
Servers that wish to introduce resources whose existence cannot be Servers that wish to introduce resources whose existence cannot be
probed need to ensure that they do not reveal any information about probed need to ensure that they do not reveal any information about
those resources to unauthenticated clients. In particular, such those resources to unauthenticated clients. In particular, such
servers MUST respond to authentication failures with the exact same servers MUST respond to authentication failures with the exact same
response that they would have used for non-existent resources. For response that they would have used for nonexistent resources. For
example, this can mean using HTTP status code 404 (Not Found) instead example, this can mean using HTTP status code 404 (Not Found) instead
of 401 (Unauthorized). of 401 (Unauthorized).
The authentication checks described above can take time to compute, The authentication checks described above can take time to compute,
and an attacker could detect use of this mechanism if that time is and an attacker could detect use of this mechanism if that time is
observable by comparing the timing of a request for a known non- observable by comparing the timing of a request for a known
existent resource to the timing of a request for a potentially nonexistent resource to the timing of a request for a potentially
authenticated resource. Servers can mitigate this observability by authenticated resource. Servers can mitigate this observability by
slightly delaying responses to some non-existent resources such that slightly delaying responses to some nonexistent resources such that
the timing of the authentication verification is not observable. the timing of the authentication verification is not observable.
This delay needs to be carefully considered to avoid having the delay This delay needs to be carefully considered to avoid having the delay
itself leak the fact that this origin uses this mechanism at all. itself leak the fact that this origin uses this mechanism at all.
Non-probeable resources also need to be non-discoverable for Non-probeable resources also need to be non-discoverable for
unauthenticated users. For example, if a server operator wishes to unauthenticated users. For example, if a server operator wishes to
hide an authenticated resource by pretending it does not exist to hide an authenticated resource by pretending it does not exist to
unauthenticated users, then the server operator needs to ensure there unauthenticated users, then the server operator needs to ensure there
are no unauthenticated pages with links to that resource, and no are no unauthenticated pages with links to that resource and no other
other out-of-band ways for unauthenticated users to discover this out-of-band ways for unauthenticated users to discover this resource.
resource.
7. Requirements on TLS Usage 7. Requirements on TLS Usage
This authentication scheme is only defined for uses of HTTP with TLS This authentication scheme is only defined for uses of HTTP with TLS
[TLS]. This includes any use of HTTP over TLS as typically used for [TLS]. 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 HTTP/2 [H2], or HTTP/3 [H3] where the transport protocol uses TLS as
its authentication and key exchange mechanism [QUIC-TLS]. its authentication and key exchange mechanism [QUIC-TLS].
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:
o The TLS version in use is greater or equal to 1.3 [TLS]. o The TLS version in use is greater than or equal to 1.3 [TLS].
o The TLS version in use is 1.2 and the Extended Master Secret o 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.
This allows the server to accept authenticated clients without This allows the server to accept authenticated clients without
revealing that it supports or expects authentication for some revealing that it supports or expects authentication for some
resources. It also allows authentication without the client leaking resources. It also allows authentication without the client leaking
the presence of authentication to observers due to clear-text TLS the presence of authentication to observers due to cleartext TLS
Client Hello extensions. Client Hello extensions.
Since the freshness described above is provided by a TLS key Since the freshness described above is provided by a TLS key
exporter, it can be as old as the underlying TLS connection. Servers exporter, it can be as old as the underlying TLS connection. Servers
can require better freshness by forcing clients to create new can require better freshness by forcing clients to create new
connections using mechanisms such as the GOAWAY frame (see connections using mechanisms such as the GOAWAY frame (see
Section 5.2 of [H3]). Section 5.2 of [H3]).
The authentication proofs described in this document are not bound to The authentication proofs described in this document are not bound to
individual HTTP requests; if the key is used for authentication individual HTTP requests; if the key is used for authentication
proofs on multiple requests on the same connection, they will all be proofs on multiple requests on the same connection, they will all be
identical. This allows for better compression when sending over the identical. This allows for better compression when sending over the
wire, but implies that client implementations that multiplex wire, but it implies that client implementations that multiplex
different security contexts over a single HTTP connection need to different security contexts over a single HTTP connection need to
ensure that those contexts cannot read each other's header fields. ensure that those contexts cannot read each other's header fields.
Otherwise, one context would be able to replay the Authorization Otherwise, one context would be able to replay the Authorization
header field of another. This constraint is met by modern Web header field of another. This constraint is met by modern web
browsers. If an attacker were to compromise the browser such that it browsers. If an attacker were to compromise the browser such that it
could access another context's memory, the attacker might also be could access another context's memory, the attacker might also be
able to access the corresponding key, so binding authentication to able to access the corresponding key, so binding authentication to
requests would not provide much benefit in practice. requests would not provide much benefit in practice.
Authentication asymmetric keys used for the Concealed HTTP Authentication asymmetric keys used for the Concealed HTTP
authentication scheme MUST NOT be reused in other protocols. Even authentication scheme MUST NOT be reused in other protocols. Even
though we attempt to mitigate these issues by adding a static prefix though we attempt to mitigate these issues by adding a static prefix
to the signed data (see Section 3.3), reusing keys could undermine to the signed data (see Section 3.3), reusing keys could undermine
the security guarantees of the authentication. the security guarantees of the authentication.
Origins offering this scheme can link requests that use the same key. Origins offering this scheme can link requests that use the same key.
However, requests are not linkable across origins if the keys used However, requests are not linkable across origins if the keys used
are specific to the individual origins using this scheme. are specific to the individual origins using this scheme.
9. IANA Considerations 9. IANA Considerations
9.1. HTTP Authentication Schemes Registry 9.1. HTTP Authentication Schemes Registry
This document, if approved, requests IANA to register the following IANA has registered the following entry in the "HTTP Authentication
entry in the "HTTP Authentication Schemes" Registry maintained at Schemes" registry maintained at <<https://www.iana.org/assignments/
<<https://www.iana.org/assignments/http-authschemes>>: http-authschemes>>:
Authentication Scheme Name: Concealed Authentication Scheme Name: Concealed
Reference: This document Reference: RFC 9729
Notes: None Notes: None
9.2. TLS Keying Material Exporter Labels 9.2. TLS Keying Material Exporter Labels
This document, if approved, requests IANA to register the following IANA has registered the following entry in the "TLS Exporter Labels"
entry in the "TLS Exporter Labels" registry maintained at registry maintained at <<https://www.iana.org/assignments/tls-
<<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: This document Reference: RFC 9729
9.3. HTTP Field Name 9.3. HTTP Field Name
This document, if approved, requests IANA to register the following IANA has registered the following entry in the "Hypertext Transfer
entry in the "Hypertext Transfer Protocol (HTTP) Field Name" registry Protocol (HTTP) Field Name Registry" maintained at
maintained at <<https://www.iana.org/assignments/http-fields/http- <<https://www.iana.org/assignments/http-fields>>:
fields.xhtml>>:
Field Name: Concealed-Auth-Export Field Name: Concealed-Auth-Export
Status: permanent Status: permanent
Structured Type: Item Structured Type: Item
Reference: This document 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/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
skipping to change at page 15, line 22 skipping to change at page 15, line 7
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/info/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/info/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 8941, DOI 10.17487/RFC8941, February 2021, HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc8941>. <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/info/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/info/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)", ISO/IEC 8824-1:2021 , February 2021. (DER)", ITU-T Recommendation X690, ISO/IEC 8825-1: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/info/rfc8410>. <https://www.rfc-editor.org/info/rfc8410>.
[H2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, [H2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
skipping to change at page 16, line 25 skipping to change at page 16, line 11
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 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/info/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", 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, November 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, Reese particular, the authors would like to thank David Benjamin, Reese
Enghardt, Nick Harper, Dennis Jackson, Ilari Liusvaara, Francois Enghardt, Nick Harper, Dennis Jackson, Ilari Liusvaara, Francois
Michel, Lucas Pardue, Justin Richer, Ben Schwartz, Martin Thomson, Michel, Lucas Pardue, Justin Richer, Ben Schwartz, Martin Thomson,
and Chris A. Wood for their reviews and contributions. The and Chris A. Wood for their reviews and contributions. The
mechanism described in this document was originally part of the first mechanism described in this document was originally part of the first
 End of changes. 64 change blocks. 
132 lines changed or deleted 109 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/