Prompt and scope
An enterprise service wants authorized-key clients to access selected resources without letting unauthenticated clients probe their existence through 401 responses or challenges. The team is considering IETF RFC 9729, a February 2025 Standards Track RFC. The scheme uses a TLS keying-material exporter to create connection-bound signature input and sends proof in Authorization: Concealed.
Design the client, edge gateway, and origin deployment. Explain the 48-byte exporter output, authentication parameters, TLS-version requirement, connection reuse, key revocation, legacy fallback, and rollout tests. Include the verified 2026 erratum in the implementation audit.
What the interviewer evaluates
The interviewer wants you to separate hiding authentication capability from guaranteeing freshness: RFC 9729 sends no challenge, but proof freshness is bounded by the lifetime of the underlying TLS connection.
A strong answer covers safe forwarding of Concealed-Auth-Export, protocol-specific keys, HTTP/2 and HTTP/3 multiplexing isolation, revocation-cache consistency, fallback behavior, and diagnosis of configuration errors rather than merely naming a few headers.
Clarifications to ask first
- Who issues client keys, are keys origin-specific, and are short-lived keys supported?
- Are the gateway and origin separate, and how is TLS exporter output passed between them?
- Does the resource require connection-level freshness or request-level freshness?
- If a legacy client only supports TLS 1.2, was Extended Master Secret negotiated?
- Must revocation take effect within seconds, or is a cache window acceptable?
A 30-second answer
“I would maintain a per-origin public-key directory. The client uses the RFC 9729 exporter on a TLS connection, signs the prescribed context, and sends the parameters; the gateway only parses and forwards trusted exporter material, while the origin makes the final authentication and authorization decision. TLS 1.3 satisfies the binding requirement; TLS 1.2 needs Extended Master Secret or the request is unauthenticated. I would use dual-read, single-write key rotation and short revocation caches. Because proof is connection-scoped, stronger freshness requires connection replacement. Rollout metrics cover parsing, verification, revocation, and fallback without revealing resource existence.”
Step-by-step solution
Build the key and origin directory
For each origin, map key IDs to public keys, algorithms, realms, issue times, and revocation state. A client private key is dedicated to Concealed authentication and is not reused in another protocol. RFC 9729 adds a fixed signature prefix, but deployment still owns key separation. Key IDs should not encode user privacy; audit logs use internal irreversible identifiers.
Compute the connection-bound proof
The client uses the exporter label EXPORTER-HTTP-Concealed-Authentication, the specified context, and a 48-byte output. The first 32 bytes feed the signature input and the last 16 bytes are sent as verification material. The context includes algorithm, key ID, public key, scheme, host, port, and realm. A mismatch is a verification failure; a permissive parser must not “repair” it.
exported = TLS-Exporter(label, context, 48)
signature_input = exported[0:32] + domain_separation_prefix
verification = exported[32:48]
Authorization: Concealed k=..., a=..., s=..., p=..., v=...Define the gateway-origin boundary
A monolithic origin can read the TLS exporter directly. When split, the gateway validates parameter syntax and sends the 48-byte exporter output in Concealed-Auth-Export over a trusted internal channel. A public client can forge a header with that name, so the gateway must overwrite or remove the external value. The origin still checks target fields, algorithm, key ID, public key, and signature; gateway parsing is not authorization.
Enforce TLS and protocol constraints
RFC 9729 requires TLS 1.3, or TLS 1.2 with Extended Master Secret. Otherwise the server treats the request as unauthenticated. HTTP/2 and HTTP/3 can use the binding, but connection-level proof may cover several requests on one connection. Clients and gateways must isolate security contexts so one tenant cannot read another tenant's Authorization headers.
Handle freshness, reuse, and replay
Exporter freshness lasts no longer than the TLS connection; it is not an independent nonce per HTTP request. If a resource needs a shorter window, require a new connection, for example by closing it or sending HTTP/3 GOAWAY, and combine that with short-lived key IDs and server time policy. Never treat v as a request nonce or accept a signature without checking host, port, and realm.
Rotate, revoke, and fall back
Use dual-read, single-write rotation: publish the new key, temporarily accept the old key ID, migrate clients, then revoke the old key. Revocation is checked before authorization and cache TTL plus invalidation are explicit. A legacy client may use the existing authentication path, but fallback responses keep the same external shape so they do not disclose whether a resource exists.
Observe and diagnose failures
Segment parameter parsing failures, unsupported TLS, unknown key IDs, public-key mismatch, signature failure, revocation hits, gateway forwarding errors, and fallback rate by origin, client version, protocol, and algorithm. Never log private keys, full signatures, or linkable user keys. Audit the verified erratum affecting the RFC 9729 Section 3.3 context string and the Section 4 integer ABNF.
Stage and test safely
Enable one origin and a revocable low-privilege resource first. Test TLS 1.3, TLS 1.2 plus EMS, HTTP/2, HTTP/3, split gateways, and connection replacement. Inject wrong host, port, realm, algorithm, key ID, exporter length, duplicate headers, stale revocation cache, and cross-tenant connection cases; each must be treated as unauthenticated. Rollback stops new key issuance and scheme acceptance while retaining the old directory and audit record.
Model high-quality answer
“RFC 9729 is connection-bound, non-probeable authentication, not a per-request nonce. The client builds the exporter context, obtains 48 bytes, and signs with a dedicated key. The gateway validates syntax and forwards trusted exporter output; the origin checks TLS conditions, target fields, key ID, public key, signature, revocation, and authorization. TLS 1.3 or TLS 1.2 plus EMS is required. Keys are origin-scoped and rotated with dual reads. Stronger freshness means replacing the connection. Rollout metrics cover parsing, verification, revocation, and fallback, and rollback stops new scheme use without exposing resource state.”
Common mistakes
- Treating the exporter as a per-request nonce → a proof can be reused on a long connection → state connection freshness and replace connections when needed.
- Verifying only at the gateway → the origin may trust a forged internal header → the origin verifies context and authorization.
- Accepting TLS 1.2 without EMS → exporter binding is insufficient → treat it as unauthenticated.
- Reusing keys across protocols → cross-protocol signature confusion → dedicate keys to the scheme and origin.
- Caching revocation too long → a revoked client keeps access → define TTL, invalidation, and precedence.
- Returning different resource errors on fallback → resource existence becomes observable → keep external state uniform and log the reason internally.
Follow-up questions and answers
Follow-up 1: Why not have the origin send a challenge?
A challenge tells an unauthenticated client that the resource expects authentication, defeating the non-probeable goal. RFC 9729 lets the client send proof derived from TLS exporter material bound to the connection.
Follow-up 2: Why split 48 bytes into 32 and 16?
The specification signs the first 32 bytes and sends the last 16 as verification material so the server can confirm the exporter output. Implementations must use those exact ranges, not treat all 48 bytes as a nonce.
Follow-up 3: Is forwarding the exporter from the gateway safe?
Only on a trusted, integrity-protected gateway-to-origin channel. A public client can forge the header name, so the gateway must overwrite or strip it, and the origin should authenticate the internal channel and validate length.
Follow-up 4: How do you handle revocation on an existing connection?
Check revocation on every authorization decision, not only when the connection is created. For stronger freshness, revoke the old key, signal connection closure, and require the client to reconnect with a new key.