HTTP K. Rampalli Internet-Draft Glyphzero Labs Inc. Intended status: Standards Track 25 April 2026 Expires: 27 October 2026 SURADAR: Context-Bound Per-Request Authentication for Machine-to-Machine APIs draft-rampalli-suradar-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Rampalli Expires 27 October 2026 [Page 1] Internet-Draft SURADAR April 2026 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Enrollment Phase (Once Per Client) . . . . . . . . . . . 6 3.2. Per-Request Phase (Zero Roundtrips) . . . . . . . . . . . 6 4. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Seed Derivation . . . . . . . . . . . . . . . . . . . . . 7 4.3. Seed Delivery . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Seed Storage (Client) . . . . . . . . . . . . . . . . . . 7 4.5. RSK Management . . . . . . . . . . . . . . . . . . . . . 8 5. Token Generation (Client) . . . . . . . . . . . . . . . . . . 8 5.1. Compute Time Band . . . . . . . . . . . . . . . . . . . . 8 5.2. Compute Context Fingerprint . . . . . . . . . . . . . . . 8 5.3. Derive Partial Key . . . . . . . . . . . . . . . . . . . 8 5.4. Generate Client Nonce . . . . . . . . . . . . . . . . . . 8 5.5. Derive Full Key . . . . . . . . . . . . . . . . . . . . . 8 5.6. Compute Signature . . . . . . . . . . . . . . . . . . . . 9 5.7. Encode Token . . . . . . . . . . . . . . . . . . . . . . 9 5.8. Set HTTP Headers . . . . . . . . . . . . . . . . . . . . 9 6. Token Verification (Server) . . . . . . . . . . . . . . . . . 9 6.1. Parse Headers . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Validate Time Band . . . . . . . . . . . . . . . . . . . 9 6.3. Re-derive Seed . . . . . . . . . . . . . . . . . . . . . 10 6.4. Recompute Key Chain . . . . . . . . . . . . . . . . . . . 10 6.5. Verify Signature . . . . . . . . . . . . . . . . . . . . 10 6.6. Check Replay . . . . . . . . . . . . . . . . . . . . . . 10 6.7. Return Principal . . . . . . . . . . . . . . . . . . . . 11 7. Replay Prevention . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Nonce Store Requirements . . . . . . . . . . . . . . . . 11 7.2. Bloom Filter Implementation . . . . . . . . . . . . . . . 11 7.3. Distributed Implementation . . . . . . . . . . . . . . . 11 8. HTTP Header Registration . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Stolen Token Analysis . . . . . . . . . . . . . . . . . . 12 9.3. Scope Escalation Prevention . . . . . . . . . . . . . . . 12 Rampalli Expires 27 October 2026 [Page 2] Internet-Draft SURADAR April 2026 9.4. Body Integrity . . . . . . . . . . . . . . . . . . . . . 12 9.5. Nonce Store Poisoning Resistance . . . . . . . . . . . . 13 9.6. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 13 9.7. Key Material Lifetime . . . . . . . . . . . . . . . . . . 13 9.8. Clock Synchronization . . . . . . . . . . . . . . . . . . 13 9.9. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 13 9.10. Comparison with HTTP Message Signatures (RFC 9421) . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.1. HTTP Authentication Scheme Registration . . . . . . . . 14 10.2. HTTP Header Field Registration . . . . . . . . . . . . . 14 10.3. SURADAR Algorithm Registry . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 17 A.1. Context Fingerprint . . . . . . . . . . . . . . . . . . . 17 A.2. Full Token Generation . . . . . . . . . . . . . . . . . . 17 A.3. Cross-Language Byte Identity . . . . . . . . . . . . . . 18 Appendix B. Comparison with Existing Schemes . . . . . . . . . . 18 B.1. Attack Resistance Matrix . . . . . . . . . . . . . . . . 18 B.2. Performance Comparison . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Existing HTTP authentication mechanisms -- Bearer tokens [RFC6750], JSON Web Tokens [RFC7519], OAuth 2.0 [RFC6749], and HTTP Message Signatures [RFC9421] -- 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 Rampalli Expires 27 October 2026 [Page 3] Internet-Draft SURADAR April 2026 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. 1.1. 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. 1.2. Non-Goals Key distribution Seed enrollment is specified at the minimum level required for interoperability (Section 4). 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Rampalli Expires 27 October 2026 [Page 4] Internet-Draft SURADAR April 2026 2.1. 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 | +--------------+------------------------------------------------+ Table 1: SURADAR Notation 2.2. Algorithms SURADAR uses HMAC-SHA-256 [RFC2104] [RFC6234] for key derivation and request authentication, and SHA-256 [FIPS180-4] for context fingerprinting. 3. Protocol Overview Rampalli Expires 27 October 2026 [Page 5] Internet-Draft SURADAR April 2026 3.1. 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. Client Server |--- [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 3.2. Per-Request Phase (Zero Roundtrips) Each HTTP request is independently authenticated with no additional roundtrips. Client Server | T = floor(now / 30) | | ctx = SHA-256(method||0x00||path||0x00||orgID||0x00||scope) | K1 = HMAC-SHA-256(S, T_bytes || ctx) | | R = rand(16) | | K = HMAC-SHA-256(K1, R) | | sig = HMAC-SHA-256(K, body) | | zero(K1, K) | | token = base64url(R || sig) | |--- HTTP request with headers: --------->| | 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 ---------| 4. Enrollment Rampalli Expires 27 October 2026 [Page 6] Internet-Draft SURADAR April 2026 4.1. 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. 4.2. Seed Derivation The server generates a 16-byte enrollment nonce using a cryptographically secure pseudorandom number generator (CSPRNG) [RFC4086]: enrollNonce = CSPRNG(16) S = HMAC-SHA-256(RSK, clientID || enrollNonce) 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). 4.3. Seed Delivery The server delivers the seed to the client encrypted under the client's public key: encrypted_S = XOR(S, SHA-256(clientPubKey)) The client recovers S: S = XOR(encrypted_S, SHA-256(privKey)) Alternative delivery mechanisms (e.g., direct TLS-protected transport, envelope encryption) are permitted provided confidentiality and integrity of S are maintained. 4.4. 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. Rampalli Expires 27 October 2026 [Page 7] Internet-Draft SURADAR April 2026 4.5. 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. 5. Token Generation (Client) 5.1. Compute Time Band The client computes the time band index: T = floor(unix_seconds / TBandSeconds) T is encoded as an 8-byte big-endian unsigned integer (T_bytes). 5.2. Compute Context Fingerprint The context fingerprint binds the token to the specific request: ctx = SHA-256(method || 0x00 || path || 0x00 || orgID || 0x00 || scope) 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. 5.3. Derive Partial Key K1 = HMAC-SHA-256(S, T_bytes || ctx) K1 MUST be zeroed from memory immediately after K is derived. 5.4. Generate Client Nonce The client generates a 16-byte random nonce: R = CSPRNG(16) 5.5. Derive Full Key K = HMAC-SHA-256(K1, R) K MUST be zeroed from memory immediately after the signature is computed. Rampalli Expires 27 October 2026 [Page 8] Internet-Draft SURADAR April 2026 5.6. Compute Signature sig = HMAC-SHA-256(K, body) For requests with no body (e.g., GET), body is the empty byte string. K MUST be zeroed after this step. 5.7. Encode Token token = base64url_no_pad(R || sig) R is 16 bytes and sig is 32 bytes, producing 48 bytes total, which encodes to exactly 64 base64url characters (no padding) per Section 5 of [RFC4648]. 5.8. Set HTTP Headers The client sets the following HTTP headers on the request: +==================+=================================+ | Header | Value | +==================+=================================+ | X-SURADAR-Auth | token (64 base64url characters) | +------------------+---------------------------------+ | X-SURADAR-Client | clientID | +------------------+---------------------------------+ | X-SURADAR-TBand | T (decimal integer) | +------------------+---------------------------------+ Table 2: SURADAR Request Headers 6. Token Verification (Server) 6.1. 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. 6.2. Validate Time Band The server computes T_server = floor(now / TBandSeconds) and checks: |T_client - T_server| <= TBandSkew If the time band is outside the acceptable skew window, the server MUST reject the request with HTTP 401. Rampalli Expires 27 October 2026 [Page 9] Internet-Draft SURADAR April 2026 6.3. Re-derive Seed The server looks up enrollNonce for the given clientID, then re- derives the seed: S' = HMAC-SHA-256(RSK, clientID || enrollNonce) During RSK rotation, the server MUST attempt verification with both the current and previous RSK values. 6.4. 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): 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) The server MUST NOT use any client-supplied values for method, path, or orgID in this computation. 6.5. Verify Signature expected = HMAC-SHA-256(K', body) valid = constant_time_equal(sig_from_token, expected) The comparison MUST use a constant-time equality function to prevent timing side-channel attacks. K' MUST be zeroed after use. 6.6. 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. Rampalli Expires 27 October 2026 [Page 10] Internet-Draft SURADAR April 2026 6.7. Return Principal Upon successful verification, the server makes the following values available to downstream authorization logic: * clientID * orgID * scope 7. Replay Prevention 7.1. Nonce Store Requirements The nonce store provides a single operation: Check(T, ctx, R) -> OK | REPLAY The store MUST be concurrent-safe. Entries MUST expire after NonceTTL seconds (default: 90). 7.2. 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. 7.3. Distributed Implementation For distributed deployments, a Redis SETNX with TTL equal to NonceTTL is RECOMMENDED: key = "suradar:nonce:" || hex(SHA-256(T || ctx || R)) result = SETNX(key, 1) EXPIRE(key, NonceTTL) Rampalli Expires 27 October 2026 [Page 11] Internet-Draft SURADAR April 2026 If SETNX returns 0 (key already exists), the request is a replay. 8. 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. 9. Security Considerations 9.1. 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. 9.2. 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. 9.3. 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. 9.4. Body Integrity The HMAC signature covers the full request body. Any modification to the body invalidates the signature. Rampalli Expires 27 October 2026 [Page 12] Internet-Draft SURADAR April 2026 9.5. 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. 9.6. 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. 9.7. Key Material Lifetime +==========+=======================+============================+ | 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 | +----------+-----------------------+----------------------------+ Table 3: Key Material Lifetime and Storage 9.8. 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. 9.9. 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. Rampalli Expires 27 October 2026 [Page 13] Internet-Draft SURADAR April 2026 9.10. Comparison with HTTP Message Signatures (RFC 9421) +=================+=========================+=============+ | 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 | Yes | No | | support | | | +-----------------+-------------------------+-------------+ | Replay | Not specified | Built-in | | prevention | | | +-----------------+-------------------------+-------------+ Table 4: SURADAR vs RFC 9421 Comparison 10. IANA Considerations 10.1. HTTP Authentication Scheme Registration This document requests registration of the following HTTP authentication scheme in the "HTTP Authentication Scheme Registry" established by [RFC9421]: 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. 10.2. 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 Rampalli Expires 27 October 2026 [Page 14] Internet-Draft SURADAR April 2026 Reference: Section 8 of this document X-SURADAR-Client Status: permanent Reference: Section 8 of this document X-SURADAR-TBand Status: permanent Reference: Section 8 of this document 10.3. 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 [RFC8126]: +================+===============+===============+===============+ | Algorithm Name | HMAC Function | Hash Function | Reference | +================+===============+===============+===============+ | SURADAR-SHA256 | HMAC-SHA-256 | SHA-256 | This document | +----------------+---------------+---------------+---------------+ Table 5: SURADAR Algorithm Registry Initial Contents 11. References 11.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . Rampalli Expires 27 October 2026 [Page 15] Internet-Draft SURADAR April 2026 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, DOI 10.17487/RFC8174, May 2017, . [FIPS180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015, . 11.2. Informative References [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", RFC 8179, DOI 10.17487/RFC8179, May 2017, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . Rampalli Expires 27 October 2026 [Page 16] Internet-Draft SURADAR April 2026 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, . Appendix A. Test Vectors A.1. Context Fingerprint Input parameters: method = "GET" path = "/api/v1/findings" orgID = "acme-corp" scope = "api:read" Concatenated input (hex): 474554 # "GET" 00 # separator 2f6170692f76312f66696e64696e6773 # "/api/v1/findings" 00 # separator 61636d652d636f7270 # "acme-corp" 00 # separator 6170693a72656164 # "api:read" Context fingerprint: ctx = SHA-256(above) = e3b7a0... (implementors: compute from the above byte sequence) A.2. Full Token Generation Input parameters: seed = 0x0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 (32 bytes) clientID = "ci-runner-01" orgID = "acme-corp" method = "GET" path = "/api/v1/findings" scope = "api:read" body = "" (empty) unix_ts = 1709769600 TBandSeconds = 30 R = 0xdeadbeefdeadbeefdeadbeefdeadbeef (16 bytes, fixed for test) Derivation steps: Rampalli Expires 27 October 2026 [Page 17] Internet-Draft SURADAR April 2026 T = floor(1709769600 / 30) = 56992320 T_bytes = 0x0000000003660000 (8-byte big-endian) ctx = SHA-256("GET" || 0x00 || "/api/v1/findings" || 0x00 || "acme-corp" || 0x00 || "api:read") K1 = HMAC-SHA-256(seed, T_bytes || ctx) K = HMAC-SHA-256(K1, R) sig = HMAC-SHA-256(K, "") token = base64url_no_pad(R || sig) Implementors MUST verify that their implementation produces identical intermediate values at each step. A.3. 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. Appendix B. Comparison with Existing Schemes B.1. Attack Resistance Matrix +====================+========+======+=========+=========+ | 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 | +--------------------+--------+------+---------+---------+ Rampalli Expires 27 October 2026 [Page 18] Internet-Draft SURADAR April 2026 Table 6: Attack Resistance: Bearer vs JWT vs JWT+JTI vs SURADAR B.2. Performance Comparison Benchmarks measured on Apple M3, Go 1.26.1, single-threaded, 1000 iterations, median values: +================+========+=========+=========+=========+ | 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 | +----------------+--------+---------+---------+---------+ Table 7: Performance: Bearer vs JWT vs JWT+JTI vs SURADAR Author's Address Karthik Rampalli Glyphzero Labs Inc. Email: karthik@phantomcorgi.com Rampalli Expires 27 October 2026 [Page 19]