draft-ietf-httpbis-unprompted-auth-07.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: December 6, 2024 Guardian Project Expires: December 15, 2024 Guardian Project
J. Hoyland J. Hoyland
Cloudflare Inc. Cloudflare Inc.
June 04, 2024 June 13, 2024
The Concealed HTTP Authentication Scheme The Concealed HTTP Authentication Scheme
draft-ietf-httpbis-unprompted-auth-07 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. At the time of writing, there
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 December 6, 2024. This Internet-Draft will expire on December 15, 2024.
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 2, line 44 skipping to change at page 2, line 44
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4
2. The Concealed Authentication Scheme . . . . . . . . . . . . . 4 2. The Concealed Authentication Scheme . . . . . . . . . . . . . 4
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.2. Key Exporter Output . . . . . . . . . . . . . . . . . . . 6 3.2. Key Exporter Output . . . . . . . . . . . . . . . . . . . 6
3.3. Signature Computation . . . . . . . . . . . . . . . . . . 7 3.3. Signature Computation . . . . . . . . . . . . . . . . . . 7
4. Authentication Parameters . . . . . . . . . . . . . . . . . . 7 4. Authentication Parameters . . . . . . . . . . . . . . . . . . 7
4.1. The k Parameter . . . . . . . . . . . . . . . . . . . . . 8 4.1. The k Parameter . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . 12
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
skipping to change at page 5, line 28 skipping to change at page 5, line 28
Figure 1: Key Exporter Context Format Figure 1: Key Exporter Context Format
The key exporter context contains the following fields: The key exporter context contains the following fields:
Signature Algorithm: The signature scheme sent in the "s" Parameter Signature Algorithm: The signature scheme sent in the "s" Parameter
(see Section 4.4). (see Section 4.4).
Key ID: The key ID sent in the "k" Parameter (see Section 4.1). Key ID: The key ID sent in the "k" Parameter (see Section 4.1).
Public Key: The public key used by the server to validate the Public Key: The public key used by the server to validate the
signature provided by the client (the encoding is described signature provided by the client. Its encoding is described in
below). 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 port for the scheme in use; see Section 3.2.3 of [URI]. default port for the scheme in use; see Section 3.2.3 of [URI].
skipping to change at page 6, line 9 skipping to change at page 6, line 9
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.
The encoding of the public key is determined by the Signature 3.1.1. Public Key Encoding
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
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 which are not DER
MUST be rejected. MUST be rejected.
ECDSA algorithms: The public key is a ECDSA algorithms: The public key is a
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.
skipping to change at page 6, line 48 skipping to change at page 6, line 52
Verification (128), Verification (128),
Figure 2: Key Exporter Output Format Figure 2: Key Exporter Output Format
The key exporter context contains the following fields: The key exporter context contains the following fields:
Signature Input: This is part of the data signed using the client's Signature Input: This is part of the data signed using the client's
chosen asymmetric private key (see Section 3.3). chosen asymmetric private key (see Section 3.3).
Verification: The verification is transmitted to the server using Verification: The verification is transmitted to the server using
the v Parameter (see Section 4.5). the "v" Parameter (see Section 4.5).
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 to mitigate issues caused by key reuse. The signature being signed to mitigate issues caused by key reuse. The signature
is computed over the concatenation of: 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
skipping to change at page 7, line 33 skipping to change at page 7, line 33
be: be:
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
48545450205369676E61747572652041757468656E7469636174696F6E 48545450205369676E61747572652041757468656E7469636174696F6E
00 00
0101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101
Figure 3: Example Content Covered by Signature Figure 3: Example Content Covered by Signature
This constructions mirrors that of the TLS 1.3 CertificateVerify This construction mirrors that of the TLS 1.3 CertificateVerify
message defined in Section 4.4.3 of [TLS]. message defined in Section 4.4.3 of [TLS].
The resulting signature is then transmitted to the server using the The resulting signature is then transmitted to the server using the
"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, these byte sequence authentication parameters values MUST NOT words, the values of these byte-sequence authentication parameters
include any characters other then ASCII letters, digits, dash and MUST NOT include any characters other then ASCII letters, digits,
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 integer authentication parameters value zeroes. In other words, the value of this integer authentication
MUST NOT include any characters other than digits, and MUST NOT start parameter MUST NOT include any characters other than digits, and MUST
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
can for example be used to point to an entry into a server-side can, for example, be used to point to an entry in a server-side
database of known keys. database of known keys.
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
contains 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. 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) Parameter is an integer that specifies
the signature scheme used to compute the proof transmitted in the "p" the signature scheme used to compute the proof transmitted in the "p"
directive. Its value is an integer between 0 and 65535 inclusive Parameter. Its value is an integer between 0 and 65535 inclusive
from the IANA "TLS SignatureScheme" registry maintained at 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, the key ID "basement" authenticating using Ed25519
[ED25519] could produce the following header field: [ED25519] could produce the following header field:
skipping to change at page 12, line 41 skipping to change at page 12, line 41
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 clear-text TLS
Client Hello extensions. Client Hello extensions.
Since the freshness described above is provided by a TLS key
exporter, it can be as old as the underlying TLS connection. Servers
can require better freshness by forcing clients to create new
connections using mechanisms such as the GOAWAY frame (see
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 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
 End of changes. 21 change blocks. 
24 lines changed or deleted 36 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/