]> Glyphzero Labs Inc.

karthik@phantomcorgi.com

Security HTTP authentication HMAC machine-to-machine context-bound agentic AI This document defines SURADAR (Subsurface Undertow RADAR), an HTTP authentication scheme in which each request is authenticated by a one-time HMAC tag derived from a shared seed, the current time band, and the full request context (method, path, organisation, scope, and body). Unlike bearer-token schemes, a captured SURADAR token is cryptographically bound to exactly one request and cannot be reused, replayed, or re-scoped. The protocol requires zero per-request handshakes, produces 48-byte tokens, and relies solely on HMAC-SHA-256 and SHA-256 -- no asymmetric cryptography.

Introduction Existing HTTP authentication mechanisms -- Bearer tokens , JSON Web Tokens , OAuth 2.0 , and HTTP Message Signatures -- authenticate the caller but not the request. A valid token for one endpoint is equally valid for any other endpoint within its scope, for any request body, until the token expires. This creates a class of attacks where a stolen or intercepted token can be reused for unintended purposes. SURADAR addresses this by deriving a unique one-time key for each request from:

• A shared secret seed (established at enrollment)
• The current time band (30-second window)
• A context fingerprint: SHA-256(method || path || orgID || scope)
• A random client nonce
• The request body

The resulting token is valid for exactly one HTTP request, at one endpoint, with one scope, within one time window, with exactly the body that was sent.

Goals

Zero per-request handshakes

Token generation is entirely local; the client never contacts the server before sending the authenticated request.

Context binding

The HTTP method, path, organisation identifier, and scope are cryptographically embedded in the key derivation, not merely carried as metadata.

Body integrity

The full request body is covered by the HMAC, preventing body-swap attacks.

Minimal blast radius

A captured token is valid for exactly one request; it cannot be replayed, re-scoped, or used against a different endpoint.

Symmetric simplicity

The protocol uses only HMAC-SHA-256 and SHA-256. No asymmetric cryptography is required.

Non-Goals

Key distribution

Seed enrollment is specified at the minimum level required for interoperability (). Full key lifecycle management is out of scope.

Authorization

SURADAR authenticates requests; authorization policy is left to the application.

Transport security

TLS MUST still be used. SURADAR provides authentication and integrity within the application layer, not confidentiality.

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.

Notation SURADAR Notation

Symbol	Definition
S	Shared seed (32 bytes)
RSK	Root Server Key (32 bytes)
T	Time band index: floor(unix_seconds / TBandSeconds)
TBandSeconds	Time band width (default: 30)
TBandSkew	Adjacent bands accepted (default: 1)
ctx	Context fingerprint: SHA-256(method || 0x00 || path || 0x00 || orgID || 0x00 || scope)
K1	Partial key: HMAC-SHA-256(S, T_bytes || ctx)
R	Client nonce: 16 random bytes
K	Full one-time key: HMAC-SHA-256(K1, R)
sig	Request authenticator: HMAC-SHA-256(K, body)
token	Wire encoding: base64url(R || sig) -- 64 chars, 48 bytes
||	Byte concatenation
0x00	Null byte separator

Algorithms SURADAR uses HMAC-SHA-256 for key derivation and request authentication, and SHA-256 for context fingerprinting.

Protocol Overview

Enrollment Phase (Once Per Client) The enrollment phase establishes a shared seed S between client and server. It occurs once per client over an authenticated channel. | | clientID, orgID, pubKey | | enrollNonce = rand(16) | | S = HMAC-SHA-256(RSK, clientID || enrollNonce) | encrypted_S = XOR(S, SHA-256(pubKey))| |<-- enrollNonce, encrypted_S ------------| | S = XOR(encrypted_S, SHA-256(privKey)) | Store S in secure keychain | Server stores: (clientID, orgID, enrollNonce) Server NEVER stores S ]]>

Per-Request Phase (Zero Roundtrips) Each HTTP request is independently authenticated with no additional roundtrips. | | X-SURADAR-Auth: | | X-SURADAR-Client: | | X-SURADAR-TBand: | | S' = HMAC-SHA-256(RSK, clientID || enrollNonce) | ctx' = SHA-256(method||0x00||path||0x00||orgID||0x00||scope) | K1' = HMAC-SHA-256(S', T_bytes || ctx') | K' = HMAC-SHA-256(K1', R_from_token) | | verify: sig == HMAC-SHA-256(K', body)| | replay_check(T, ctx, R) | | zero(K1', K') | |<-- 200 OK or 401 Unauthorized ---------| ]]>

Enrollment

Prerequisites The client MUST authenticate via an existing mechanism (OAuth 2.0, mutual TLS, or a one-time enrollment token) before requesting seed enrollment. The enrollment channel MUST be protected by TLS.

Seed Derivation The server generates a 16-byte enrollment nonce using a cryptographically secure pseudorandom number generator (CSPRNG) : The RSK MUST be stored in a hardware security module (HSM) or equivalent secure storage. The server MUST NOT store S. The server stores the tuple (clientID, orgID, enrollNonce).

Seed Delivery The server delivers the seed to the client encrypted under the client's public key: The client recovers S: Alternative delivery mechanisms (e.g., direct TLS-protected transport, envelope encryption) are permitted provided confidentiality and integrity of S are maintained.

Seed Storage (Client) The client MUST store S in one of the following:

• Operating system keychain (e.g., macOS Keychain, Windows Credential Manager)
• Hardware security element or TPM
• Secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager)

The client MUST NOT store S in plaintext on disk or in environment variables.

RSK Management The RSK MUST be stored in an HSM or secrets manager. RSK rotation is supported: the server MUST accept tokens derived from the previous RSK for a grace period equal to NonceTTL (default: 90 seconds) after rotation. During this period, both old and new RSK values are tried during verification.

Token Generation (Client)

Compute Time Band The client computes the time band index: T is encoded as an 8-byte big-endian unsigned integer (T_bytes).

Compute Context Fingerprint The context fingerprint binds the token to the specific request: Null byte (0x00) separators prevent field boundary ambiguity. For example, without separators, method="GETX" path="Y" and method="GET" path="XY" would produce the same hash input.

Derive Partial Key K1 MUST be zeroed from memory immediately after K is derived.

Generate Client Nonce The client generates a 16-byte random nonce:

Derive Full Key K MUST be zeroed from memory immediately after the signature is computed.

Compute Signature For requests with no body (e.g., GET), body is the empty byte string. K MUST be zeroed after this step.

Encode Token R is 16 bytes and sig is 32 bytes, producing 48 bytes total, which encodes to exactly 64 base64url characters (no padding) per .

Set HTTP Headers The client sets the following HTTP headers on the request: SURADAR Request Headers

Header	Value
X-SURADAR-Auth	token (64 base64url characters)
X-SURADAR-Client	clientID
X-SURADAR-TBand	T (decimal integer)

Token Verification (Server)

Parse Headers The server extracts X-SURADAR-Auth, X-SURADAR-Client, and X-SURADAR-TBand from the request. If any header is absent, the server MUST respond with HTTP 401 Unauthorized.

Validate Time Band The server computes T_server = floor(now / TBandSeconds) and checks: If the time band is outside the acceptable skew window, the server MUST reject the request with HTTP 401.

Re-derive Seed The server looks up enrollNonce for the given clientID, then re-derives the seed: During RSK rotation, the server MUST attempt verification with both the current and previous RSK values.

Recompute Key Chain The server recomputes the context fingerprint and key chain from the actual HTTP request (method, path, orgID looked up from the client record, scope from application context): The server MUST NOT use any client-supplied values for method, path, or orgID in this computation.

Verify Signature The comparison MUST use a constant-time equality function to prevent timing side-channel attacks. K' MUST be zeroed after use.

Check Replay Replay checking MUST occur after HMAC verification succeeds. This ordering prevents an attacker from poisoning the nonce store with garbage tuples. The server checks the tuple (T, ctx, R) against the nonce store. If the tuple is already present, the request is a replay and MUST be rejected with HTTP 401. The nonce store entry TTL MUST be at least (TBandSkew + 1) * TBandSeconds seconds. With defaults, this is (1 + 1) * 30 = 60 seconds. A default of 90 seconds is RECOMMENDED to account for clock drift.

Return Principal Upon successful verification, the server makes the following values available to downstream authorization logic:

• clientID
• orgID
• scope

Replay Prevention

Nonce Store Requirements The nonce store provides a single operation: OK | REPLAY ]]> The store MUST be concurrent-safe. Entries MUST expire after NonceTTL seconds (default: 90).

Bloom Filter Implementation A Bloom filter implementation is RECOMMENDED for single-server deployments. The following parameters provide approximately 0.01% false positive rate:

• m = 10,000,000 bits (~1.2 MB)
• k = 7 hash functions

The implementation uses dual-rotating filters: the active filter receives new entries, while the previous filter is kept for the duration of NonceTTL before being cleared and rotated. Hash functions for the Bloom filter are derived from SHA-256 of the (T, ctx, R) tuple by splitting the 256-bit output into segments.

Distributed Implementation For distributed deployments, a Redis SETNX with TTL equal to NonceTTL is RECOMMENDED: If SETNX returns 0 (key already exists), the request is a replay.

HTTP Header Registration This document registers the following HTTP header fields:

X-SURADAR-Auth

Contains the SURADAR authentication token: 64 base64url characters encoding the 16-byte client nonce concatenated with the 32-byte HMAC-SHA-256 signature.

X-SURADAR-Client

Contains the client identifier used to look up the enrollment record on the server.

X-SURADAR-TBand

Contains the time band index as a decimal integer, allowing the server to verify the token was generated within an acceptable time window.

Security Considerations

Threat Model The attacker is assumed to be able to observe network traffic (despite TLS, e.g., via compromised middlebox), capture tokens, and attempt to reuse them. The attacker cannot obtain the shared seed S or the Root Server Key RSK.

Stolen Token Analysis A captured token reveals R (not secret) and sig. The attacker cannot derive K without K1, cannot derive K1 without S, and cannot derive S without RSK. The blast radius of a stolen SURADAR token is exactly one request -- the request for which it was generated.

Scope Escalation Prevention The scope is embedded in ctx, which is embedded in the K1 derivation. Changing the scope changes ctx, which changes K1, which changes K, which changes sig. An attacker cannot re-scope a captured token -- this is a cryptographic guarantee, not a policy check.

Body Integrity The HMAC signature covers the full request body. Any modification to the body invalidates the signature.

Nonce Store Poisoning Resistance The replay check occurs after HMAC verification. An attacker who sends garbage tokens cannot poison the nonce store because those tokens will fail HMAC verification before the nonce is recorded.

Timing Attacks Implementations MUST use constant-time comparison for HMAC verification. Implementations MUST zero all key material (K1, K) immediately after use to limit the window for memory-disclosure attacks.

Key Material Lifetime Key Material Lifetime and Storage

Material	Lifetime	Storage
RSK	Long-lived, rotatable	HSM / Vault
S	Client lifetime	OS keychain
K1	~microseconds	Memory only
K	~microseconds	Memory only
R	Single request	Transmitted then discarded

Clock Synchronization Both client and server clocks SHOULD be synchronized via NTP or an equivalent protocol. The TBandSkew parameter (default: 1) allows for minor clock drift by accepting tokens from adjacent time bands.

Forward Secrecy K1 is derived from the time band T. Once a time band expires, the corresponding K1 cannot be recomputed without the seed S and the exact time band value. Past tokens are unrecoverable without the R values, which are ephemeral and not stored by the server after replay checking.

Comparison with HTTP Message Signatures (RFC 9421) SURADAR vs RFC 9421 Comparison

Property	RFC 9421	SURADAR
Key per request	Same key	Unique key
Context in key	No (in signature input)	Yes (in key derivation)
Body coverage	Optional	Always
Token size	Variable (large)	Fixed (48 bytes)
Asymmetric support	Yes	No
Replay prevention	Not specified	Built-in

IANA Considerations

HTTP Authentication Scheme Registration This document requests registration of the following HTTP authentication scheme in the "HTTP Authentication Scheme Registry" established by :

Authentication Scheme Name:

SURADAR

Reference:

This document

Notes:

The SURADAR scheme uses per-request HMAC-based authentication. The token is transmitted in the X-SURADAR-Auth header rather than the Authorization header to avoid conflicts with existing authentication infrastructure.

HTTP Header Field Registration This document requests registration of the following HTTP header fields in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

X-SURADAR-Auth

Status:

permanent

Reference:

of this document

X-SURADAR-Client

Status:

permanent

Reference:

of this document

X-SURADAR-TBand

Status:

permanent

Reference:

of this document

SURADAR Algorithm Registry IANA is requested to create a new registry titled "SURADAR Algorithm Registry" with the following initial entry, under the registration policy of Specification Required : SURADAR Algorithm Registry Initial Contents

Algorithm Name	HMAC Function	Hash Function	Reference
SURADAR-SHA256	HMAC-SHA-256	SHA-256	This document

References Normative References National Institute of Standards and Technology (NIST) Informative References

Test Vectors

Context Fingerprint Input parameters: Concatenated input (hex): Context fingerprint:

Full Token Generation Input parameters: Derivation steps: Implementors MUST verify that their implementation produces identical intermediate values at each step.

Cross-Language Byte Identity Implementations in different languages MUST produce byte-identical output for identical inputs. In particular:

• String-to-bytes conversion MUST use UTF-8 encoding.
• The time band T MUST be encoded as an 8-byte big-endian unsigned integer with leading zeros.
• The base64url encoding MUST NOT include padding characters.

Comparison with Existing Schemes

Attack Resistance Matrix Attack Resistance: Bearer vs JWT vs JWT+JTI vs SURADAR

Attack	Bearer	JWT	JWT+JTI	SURADAR
Token Replay	VULN	VULN	RESIST	RESIST
Scope Escalation	VULN	VULN	VULN	RESIST
Cross-Org Abuse	VULN	VULN	VULN	RESIST
Body Tampering	VULN	VULN	VULN	RESIST
Method Swap	VULN	VULN	VULN	RESIST
Path Swap	VULN	VULN	VULN	RESIST
Stolen Token Blast	VULN	VULN	VULN	RESIST
Score	0/7	0/7	2/7	7/7

Performance Comparison Benchmarks measured on Apple M3, Go 1.26.1, single-threaded, 1000 iterations, median values: Performance: Bearer vs JWT vs JWT+JTI vs SURADAR

Metric	Bearer	JWT	JWT+JTI	SURADAR
Generation	729 ns	1024 ns	1024 ns	1298 ns
Verification	52 ns	1107 ns	1868 ns	1630 ns
Token size	32 B	195 B	236 B	82 B
Security score	0/7	0/7	2/7	7/7