]> Zscaler

yrosomakho@zscaler.com

Defakto Security

arndts.ietf@gmail.com

Web and Internet Transport HTTP http tunnels signatures This document specifies client authentication for HTTP tunnel establishment using HTTP Message Signatures. It covers the CONNECT method, extended CONNECT in HTTP/2 and HTTP/3, and HTTP/1.1 Upgrade. It defines signature coverage and replay protection using either a client-generated nonce or a server-provided nonce obtained through an Accept-Signature challenge. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction HTTP endpoints that establish tunnels often need to authenticate clients before granting access to network resources. HTTP Message Signatures provide a flexible mechanism for authenticating selected components of an HTTP message, but their use requires a profile that specifies the components to cover and the verification requirements for a particular application. This document defines such a profile for tunnel establishment using the CONNECT method , extended CONNECT in HTTP/2 and HTTP/3 , and HTTP/1.1 Upgrade . These mechanisms support uses such as UDP proxying and WebSockets . The profile specifies signature coverage and replay protection for each tunnel establishment request. Clients can send unsolicited signatures with client-generated nonces; servers can accept these or require a fresh nonce through an Accept-Signature challenge. One motivating use case is authentication of software workloads at CONNECT proxies. WIMSE Workload-to-Workload Authentication with HTTP Signatures uses workload credentials and HTTP Message Signatures to authenticate workload requests. This document is intended to support that use case while remaining independent of WIMSE and applicable to other client authentication deployments. Authentication applies to the tunnel establishment request. Key identification, trust establishment, and authorization policy are outside the scope of this document. The mechanism does not require TLS or signed responses, and does not provide confidentiality or integrity protection for subsequent tunnel traffic.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Protocol Overview The client sends a tunnel establishment request, optionally signed using a fresh client-generated nonce. According to its policy, the server can accept an unsolicited signature or require a signature using a server-provided nonce. If authentication is needed, the server returns an Accept-Signature challenge with a fresh nonce and the required signature coverage. The client retries with the requested signature. Before accepting a request, the server verifies the signature, enforces nonce single use, and applies its authorization policy.

Authentication exchange when a challenge is required | | | | Accept-Signature challenge | |<--------------------------------------------| | | | Signed request with server nonce | |-------------------------------------------->| | | | Successful establishment response | |<--------------------------------------------| | | | Tunnel traffic | |<===========================================>| ]]>

If the server accepts an unsolicited signature, it sends the successful establishment response directly. Each establishment requires a fresh nonce. Retries can use a different connection; authentication of one request does not authenticate other requests on either connection.

Signature Requirements The server MUST enforce the signature requirements below, whether the client sends an unsolicited signature or responds to an Accept-Signature challenge. The client MUST generate the signature in accordance with . The Signature-Input and Signature fields MUST be sent in the request header section so that authentication can complete before tunnel establishment. A signature accepted for authentication MUST satisfy all applicable requirements; coverage from separate signatures MUST NOT be combined to satisfy them.

Covered Components The signature MUST cover the components listed below for the request form in use. The server MUST reject authentication if any required component is not covered, even if the signature is otherwise valid.

Request form	Required components
Standard CONNECT	@method, @authority
Extended CONNECT	@method, @authority, @scheme, @path, @query, @protocol
HTTP/1.1 Upgrade	@method, @authority, @scheme, @path, @query, upgrade

For standard CONNECT, @authority identifies the target host and port. Coverage of @path and @query is not required. For extended CONNECT and HTTP/1.1 Upgrade, the URI components identify the requested resource, including any destination information conveyed in its path or query. The @query component MUST be covered even when no query is present, using the value defined in . The server MUST require coverage of any additional request fields on which it relies to determine client identity, the tunnel destination, or permissions for the requested tunnel. When issuing a challenge, it MUST include all required components in Accept-Signature. Clients MAY cover components beyond these requirements. When responding to a challenge, components not requested by the server can be covered by a separate signature, as described in . The upgrade component covers the Upgrade field using the field canonicalization rules in .

The @protocol Derived Component The @protocol derived component identifies the protocol requested by an extended CONNECT request. Its value is the value of the :protocol pseudo-header field defined in and used in HTTP/3 by , without case conversion or other normalization. For example, a request containing :protocol with the value connect-udp produces the following signature base line: This component is derived from a request. It can also be referenced in a response signature using the req parameter as defined in . If the request is not an extended CONNECT request with a valid :protocol pseudo-header field, the component cannot be derived and signature base generation MUST fail. In particular, @protocol is not derived from the HTTP/1.1 Upgrade field.

Signature Parameters The signature MUST include the following parameters defined in :

• nonce: a fresh client-generated value for an unsolicited signature, or the exact value supplied by the server when responding to an Accept-Signature challenge. The client MUST NOT substitute its own value in a challenge response.
• created: the time at which the client generated the signature.
• expires: the signature expiration time, which MUST be later than created.

Client-generated nonces MUST be unpredictable and MUST NOT be reused with the same signing key. The server MUST enforce a maximum signature lifetime (expires minus created) and SHOULD keep it short, on the order of minutes. It MUST enforce the signature validity period and nonce single use. For a challenge response, it MUST also enforce the challenge lifetime; signature expiration does not extend that lifetime. These checks apply when authenticating the establishment request, not to the resulting tunnel's lifetime. Additional parameters can be required by the challenge or another applicable profile. This document does not mandate keyid, alg, or a particular tag value; their use follows and the applicable deployment or profile.

The proxy-authority Signature Parameter The proxy-authority signature metadata parameter identifies the intended proxy. It MUST be included in signatures authenticating standard CONNECT, whether unsolicited or challenged, and MUST NOT be used for extended CONNECT or HTTP/1.1 Upgrade. In Signature-Input, its value is a String containing the proxy hostname or IP address followed by a colon and an explicit port. It is protected by the signature through @signature-params as defined in . The client MUST derive the value from its proxy configuration, retaining the configured hostname rather than substituting a DNS-resolved address. The value MUST be normalized as follows:

• Hostnames are lowercase ASCII, with internationalized labels represented as A-labels and any final dot omitted.
• IPv4 addresses use four decimal octets without leading zeros. IPv6 addresses use the hexadecimal representation specified in Section 4 of , enclosed in square brackets. IPv6 zone identifiers are not permitted.
• The port is a decimal integer from 1 through 65535 without leading zeros. It MUST be included even when it is the default port for the configured proxy scheme. For example, https://proxy.example produces proxy.example:443.

The value MUST NOT contain a scheme, user information, path, query, or fragment. For example, proxy.example:8080 and [2001:db8::1]:443 are valid values. The proxy MUST reject authentication unless the value is in this normalized form and exactly matches one of its configured proxy identities. An identity MUST NOT be accepted solely because it appears in the request. An Accept-Signature challenge for standard CONNECT MUST include proxy-authority in its Boolean true form (;proxy-authority, equivalent to ;proxy-authority=?1). This requests inclusion of the parameter without specifying a proxy identity. The client MUST supply the normalized String value derived from its proxy configuration in Signature-Input. The proxy checks that value against its configured identities as described above.

Authentication Procedure

Unsolicited Signatures A client MAY sign its initial request using a fresh client-generated nonce and the requirements in . Signature selection follows the applicable profile or server policy; a particular signature label is not required. The server MAY accept the signature if its policy permits unsolicited authentication and all checks in succeed. Otherwise, it can require a server-provided nonce as described below. Servers that accept both kinds of nonce MUST distinguish challenge responses from unsolicited signatures, for example through a recognizable server nonce format or retained challenge metadata. An expired or consumed server nonce MUST NOT be accepted as a client-generated nonce. If the server cannot safely make this distinction, it MUST require a fresh challenge. A policy that requires a server-provided nonce MUST NOT fall back to unsolicited authentication.

Issuing a Challenge For an otherwise acceptable tunnel establishment request without a signature, or with an unsolicited signature when policy requires a server-provided nonce, the server MUST return 403 (Forbidden) with an Accept-Signature field. The field MUST contain one dictionary member specifying the signature required by this mechanism, using the syntax in . It MUST specify the coverage required by , a fresh nonce value, and the created and expires parameters in their Boolean true form. The response MUST include Cache-Control: no-store. For standard CONNECT, the challenge MUST also include proxy-authority as specified in . The nonce MUST be unpredictable and unique among challenges that the server can still accept. The server MUST assign each challenge a bounded lifetime and SHOULD keep that lifetime short, on the order of minutes. The server MUST associate the nonce with the requested signature label, coverage, parameters, expiration, and the request's method, target, and tunnel protocol. This association MUST be protected against modification by the client. A challenge MUST NOT be bound to the connection on which it was issued.

Responding to a Challenge Clients MUST support responding to Accept-Signature challenges. On receiving a 403 response with Accept-Signature, the client MUST check that the challenge satisfies and is compatible with its signing policy. If it cannot satisfy the challenge, it MUST fail the establishment attempt rather than retry with weaker coverage or parameters. The client retries the establishment request with the same method, target, and tunnel protocol. It MUST generate the requested signature following , using the same signature label and exact set of component identifiers, including their parameters, as the challenge. It MUST include the supplied nonce and generate created and expires values as specified in . The retry MAY use the same connection or a different connection. The client MUST NOT reuse a signed request for another establishment attempt. If a retry is needed after a signed request fails or its outcome is unknown, the client MUST generate a fresh client nonce or obtain a fresh challenge, as permitted by server policy. A client challenged to use a server nonce MUST respond to that challenge or fail the attempt. Clients MUST limit automatic retries to avoid an unbounded challenge-response loop.

Validating and Accepting a Request Before accepting a signed request, the server MUST:

1. Select the signature under the applicable profile or policy. For a challenge response, identify the issued challenge using the nonce, select the requested signature label, and verify that the challenge is unexpired and applies to the request's method, target, and tunnel protocol. For an unsolicited signature, verify that server policy permits its use.
2. Check the signature coverage and parameters against and any issued challenge, and verify the signature according to . For standard CONNECT, this includes checking proxy-authority against the proxy's configured identities.
3. Check that the signature lifetime does not exceed the server's maximum and that the current time falls within the signature validity period. The server MAY allow a small, bounded tolerance for clock skew.
4. Atomically check that the nonce is unused and record its consumption. For a client-generated nonce, the replay record MUST be scoped to the verified signing key and nonce value, independent of signature labels, key identifier aliases, or request targets. For a server-provided nonce, the challenge MUST be consumed at most once. If already consumed, authentication MUST fail.

Single-use enforcement MUST apply across all connections and server instances that can accept the signature. Client nonce records MUST be retained through signature expiration, including any clock skew tolerance. Server nonce consumption MUST be recorded for the entire remaining challenge lifetime. If single-use enforcement cannot be guaranteed, the server MUST NOT accept the request. An invalid signature MUST NOT create a replay record or consume a challenge. Once consumed, a nonce MUST NOT become usable again during its acceptance window, including when authorization or subsequent tunnel establishment fails. After authentication, the server applies its authorization policy. It MUST NOT open the requested upstream connection, forward tunnel traffic, or send a successful establishment response before authentication and authorization succeed. Successful establishment uses the response defined by the applicable tunnel protocol: a 2xx response for CONNECT or a 101 (Switching Protocols) response for HTTP/1.1 Upgrade. Authentication applies only to this request.

Error Handling Malformed authentication fields SHOULD result in 400 (Bad Request). For well-formed requests, failed authentication, including an invalid signature, a replayed client nonce, or an expired or consumed server nonce, MUST result in 403 (Forbidden). The server MAY include a fresh Accept-Signature challenge if another attempt could succeed, and MUST do so in the cases specified in . If authentication succeeds but authorization fails, the server MUST return 403 without an Accept-Signature challenge. A client receiving a 403 response without a challenge MUST NOT automatically retry using this procedure. Other failures, such as an unreachable tunnel destination, use the error handling of the applicable tunnel protocol.

Examples These examples show successful exchanges at 2026-10-06T00:00:00Z. All request signatures use Ed25519 and expire 60 seconds later; the server accepts signatures and any challenges during that interval. Keys and nonce values are for illustration only and are not suitable for deployment. Long lines are folded using ; folding is not part of the messages. The client public key used in all three examples is:

Example client public key

Standard CONNECT with WIMSE Credentials A workload connects to the proxy at https://proxy.example and requests a TCP tunnel to service.example:443. The proxy uses WIMSE credentials and trusts the following issuer public key for the example.com trust domain:

Example WIT issuer public key

The Workload Identity Token (WIT) in the signed request identifies wimse://example.com/workload-a, is issued by https://issuer.example, and binds the client public key above in cnf.jwk. Its iat is 1791244740 and its exp is 1791248400. The token's protected header is:

WIT protected header

Editorial note: this example anticipates changes to WIMSE omitting @path and @query for standard CONNECT. It is not fully conformant to draft-ietf-wimse-http-signature-07. The proxy permits unsolicited signatures. The client sends its WIT and signature with a fresh client-generated nonce. The proxy-authority value is proxy.example:443, derived from the configured proxy URI. The wimse-aud value is the proxy identity configured for this WIMSE deployment. Both identify the intended proxy and are checked independently. The signing key and algorithm come from the WIT, so keyid and alg are absent from Signature-Input. Response signing is not requested.

Signed CONNECT request

The proxy validates the WIT, audience, proxy authority, and request signature, atomically records the client nonce under the verified signing key, and authorizes the tunnel. It responds without an Accept-Signature exchange:

CONNECT success

Extended CONNECT for UDP Proxying This example uses CONNECT-UDP over HTTP/2. The same fields and signature apply to HTTP/3. Pseudo-header fields and header fields are shown in decoded form; connection setup and protocol settings negotiation are omitted. The proxy maps client-key to the client public key in through local configuration and requires a server-provided nonce. The client requests a UDP tunnel to 192.0.2.1:443:

Initial CONNECT-UDP request

The proxy requests a signature:

CONNECT-UDP challenge

The client sends the signed request:

Signed CONNECT-UDP request

After validation and authorization, the proxy accepts the tunnel:

CONNECT-UDP success

HTTP/1.1 WebSocket Upgrade A client opens a WebSocket at ws://chat.example/socket. The server maps client-key to the public key in . The handshake follows and additionally covers its key and version fields. This example assumes a client capable of setting the signature fields. The server requires a server-provided nonce even for a valid unsolicited signature. The client initially sends an unsolicited signature with its own nonce:

Unsolicited signed WebSocket request

The server requires a fresh server nonce and challenges the client:

WebSocket challenge

The client retries with the server-provided nonce and a new signature:

Signed WebSocket request

After validation and authorization, the server switches protocols:

WebSocket success

Security Considerations The security considerations of apply. A valid signature proves possession of the signing key; the server still needs a trusted association between that key and a client identity and an authorization decision for the requested tunnel. Components used in that decision need to be covered as specified in . Uncovered fields can be modified without invalidating the signature. Replay protection depends on bounded signature lifetimes and atomic single-use enforcement across all server instances that accept a signature. Random client nonces do not prevent replay without this state. Server-provided nonces also bind signatures to fresh challenges, but expiring, self-contained challenges still require single-use enforcement. Loss or eviction of replay state MUST NOT allow previously accepted requests to be accepted again; affected requests MUST be rejected until that protection can be guaranteed. Without TLS or equivalent channel protection, an attacker can capture a signed establishment request and replay it on another connection, racing the client. Atomic single-use enforcement accepts at most one copy, but cannot ensure that the legitimate client's copy wins. With either client-generated or server-provided nonces, the attacker can therefore obtain the tunnel if its copy is accepted first. For standard CONNECT, @authority identifies the tunnel destination, not the proxy. The proxy-authority parameter binds the signature to the intended proxy, provided both parties check it against their configuration. Proxies sharing an accepted identity and signing-key trust MUST coordinate replay protection if they can accept the same signature. The parameter does not bind a transport scheme or authenticate the proxy to the client, and does not prevent live relay to the intended proxy. Additional audience requirements, such as WIMSE's wimse-aud, continue to apply independently. This mechanism does not authenticate the server or protect tunnel traffic. Without a protected transport, credentials and request details are visible, and an active attacker can alter challenges or forge responses. An attacker can also relay a server's challenge to a legitimate client and use the signed response to establish a tunnel under the attacker's control. Fresh, single-use nonces do not prevent this live relay or subsequent tunnel hijacking. TLS or equivalent channel protection can address these risks without being a prerequisite for this mechanism. Clients need to apply their signing policy to challenges, including restrictions on keys and algorithms, rather than treating Accept-Signature as authority to use arbitrary credentials. Servers need to enforce their own coverage and algorithm requirements even if a challenge has been altered in transit. Challenge issuance, signature verification, and replay records can be used to exhaust server resources. Servers SHOULD bound authentication state and rate-limit authentication attempts. Resource limits MUST NOT cause requests to be accepted without replay checks.

IANA Considerations This document requests registration of the following entry in the "HTTP Signature Derived Component Names" registry established by , using the template in :

• Name: @protocol
• Description: The value of the :protocol pseudo-header field in an extended CONNECT request
• Status: Active
• Target: Request
• Reference: of this document

This document also requests registration of the following entry in the "HTTP Signature Metadata Parameters" registry established by , using the template in :

• Name: proxy-authority
• Description: The hostname or IP address and explicit port of the intended proxy for a standard CONNECT request
• Reference: of this document

References Normative References This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] Informative References This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling). [STANDARDS-TRACK] Palo Alto Networks Independent The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism.

Acknowledgments TODO acknowledge.