]> Independent

ietf@nritz.com

OAuth DPoP RATS HPKE This document describes IDPoP, an extension to DPoP that uses a key derivation scheme to separate access control from identity. It mitigates credential exfiltration risks by requiring fresh hardware attestation to unseal identity keys via an interactive challenge.

Introduction Standard DPoP binds tokens to keys but recent events have increased risks to exfiltration attacks where autonomous systems (such as agentic AI) leak valid credentials via prompt injection. Likewise, when malware compromises a device filesystem, attackers steal credentials and impersonate users until explicit revocation. This proposal introduces a derivation scheme separating access control (encapsulate/decapsulate) from identity (signing).

Three-Factor Interface Model Factors:

• PF (Provisioning Factor): Represents authorization intent (client_id + scope + audience).
• EF (Evidence Factor): Confidential attestation proof (TPM quote, YubiKey HMAC-secret, biometric), never transmitted.
• VF (Vault Factor): High-entropy secret, encapsulated by Evidence derived key.

Two-Stage Derivation:

1. Access gating: K_kem = HKDF(salt=PF, ikm=EF, info="seal")
2. Identity derivation: K_attest = HKDF(salt=PF, ikm=VF, info="dpop")

| AS-B (OAuth) | | Client | 4. Present | Token Issuer | | (Attester) | AR grant '---+------+--------' | |<-| | ^ '------+------. +---------------+ | | 5. Validate AR | 6. Present token Issue access token | + DPoP proof | | (signed with K_dpop_priv) | v | .------+-------. 7. Validate token cnf | RS-B +------------> DPoP signature | (Resource | with K_dpop_pub | Server) | '--------------' ]]> Figure 1: OAuth Identity Chaining Flow with RATS Verifier as AS-A and "IDPoP"-aware OAuth AS-B as delegated notary NOTE: K_kem controls access to VF (identity key seed material). K_attest is the identity. Compromise of the identity key alone is insufficient—attacker needs to demonstrate access to notorized Evidence (EF) to derive K_kem and unseal.

Algorithms

Algorithm 1: DeriveKEM (Client)

Algorithm 2: EncapsulateSecret (AS-A)

Algorithm 3: DeriveIdentity (Client) Convergence: Client derives K_dpop_priv from (PF, VF) only after unsealing the encapsulated VF secret.

OAuth Identity Chaining Flow Setup (Client → AS-A):

1. Client generates attestation evidence (EF)
2. Client: K_kem_priv = DeriveKEM(PF, EF)
3. Client sends attestation to AS-A with K_kem_pub

Notarization (RATS Verifier as AS-A):

1. AS-A Appraises attestation Evidence
2. AS-A: (VF_sealed, K_dpop_pub) = EncapsulateSeed(PF, K_kem_pub)
3. AS-A creates JWT grant to AS-B:

Token Issuance (AS-B):

1. AS-B validates grant, issues DPoP-bound access token:

The access token JWT contains:

Interactive Challenge & Proofs Interactive Challenge (AS-B → Client):

1. Client sends request with DPoP proof (no nonce or cached nonce)
2. AS-B decides: "I need hardware liveness proof"
3. AS-B → 401 Unauthorized

]]> Client Proof:

1. VF = HPKE.Unseal(K_kem_priv, VF_sealed) [proves fresh EF]
2. Client extracts sealed nonce from header
3. Client: nonce = HPKE.AuthUnseal(nonce_sealed, K_kem_priv, AS_B_pubkey)
4. Client: K_dpop_priv = HKDF(PF, VF, "dpop")
5. Client creates new DPoP proof with unsealed nonce and retries:

Verification (AS-B or RS-B):

1. Verify DPoP signature with K_dpop_pub (from token's cnf.jkt)
2. Verify proof.nonce == SHA256(expected_nonce)
3. Accept request

Note: The interactive challenge (Steps 8-10) introduces a round-trip. To mitigate latency, this challenge MAY be performed once per session or upon detecting high-risk context. The resulting nonce acts as a session binding signal for subsequent DPoP proofs, reducing overhead for high-frequency API calls.

Security Properties

1. No durable secrets at AS-A. Post-issuance compromise of AS-A yields no client key material. RATS Verifier (AS-A) computes K_dpop_priv transiently, extracts K_dpop_pub, discards both K_dpop_priv and secret seed material (VF).
2. Sealed grant confidentiality. Interception without K_kem_priv yields nothing. VF_sealed is HPKE-encrypted to K_kem_pub.
3. Attestation-bound unsealing. Stolen VF_sealed without device access is unusable. K_kem_priv = HKDF(PF, EF). Unsealing VF requires fresh hardware attestation.
4. Key separation. K_kem controls access. K_dpop asserts identity. Compromise of signing key doesn't grant unsealing; compromise of unsealing requires live EF.
5. Convergent derivation. No key transport. Client derives K_dpop from (PF, VF) independently.

Security Considerations

Authorization Server as Root of Trust The architecture described in this document leverages the Authorization Server (AS-A in the RATS flow, or the OAuth AS) as a Trusted Third Party (TTP). This aligns with the standard OAuth 2.0 threat model , where the AS is already trusted to generate access tokens, sign ID tokens, and manage client credentials. While IDPoP introduces the generation and sealing of the Identity Key seed (VF) by the AS, this does not introduce a new root of trust. An AS capable of issuing a valid access_token can already impersonate the user to the Resource Server. Therefore, entrusting the AS with the transient generation of the VF seed is consistent with its existing role. The security goal of IDPoP is not to protect the client from the AS, but to protect the client's credentials from exfiltration after issuance.

Encapsulated Secret Transport This specification utilizes a Key Transport pattern where the Identity Key material (VF) is generated by the server and transmitted to the client in an HPKE-sealed envelope (VF_sealed). While Key Transport is sometimes disfavored in comparison to Key Agreement, it is necessary here to bind the identity to the specific hardware attestation presented by the client. The security of this transport relies on Hardware Binding: The VF is sealed to K_kem_pub, which is derived from the client's hardware-bound Evidence Factor (EF). Even if VF_sealed is intercepted, it remains "inert" (unusable) without the corresponding hardware-bound private key K_kem_priv.

"Harvest Now, Decrypt Later" and Forward Secrecy A prominent concern with any encrypted transport of secrets is the "Harvest Now, Decrypt Later" (HNDL) strategy, where an adversary records encrypted traffic today to decrypt it in the future once quantum computing breaks current asymmetric primitives (e.g., X25519). In the context of IDPoP, the impact of HNDL is significantly mitigated by the ephemeral nature of the Identity Key:

• Short-Lived Credential Utility: The VF seed is used solely to derive the DPoP signing key (K_dpop). This key is only useful for signing DPoP proofs for the validity period of the associated access token (defined by exp).
• Obsolescence upon Decryption: If an adversary successfully breaks the KEM algorithm years in the future and recovers a historical VF, the associated access token will have long since expired. Unlike confidentiality keys used to encrypt persistent data (where future decryption is catastrophic), recovering an authentication key after the session window has closed yields no advantage, provided the AS enforces standard expiration (exp) and replay protection (jti).

Post-Quantum Agility To further mitigate HNDL risks and ensure long-term resistance, implementations SHOULD support cryptographic agility in the HPKE configuration.

• Hybrid KEMs: Implementations can adopt hybrid KEMs such as X-Wing (combining X25519 and ML-KEM-768) to provide post-quantum resistance while maintaining classical security guarantees.
• Algorithm Negotiation: The alg parameter in the attestation request or metadata allows the client and AS to negotiate Quantum-Resistant KEMs (e.g., ML-KEM) as they become standardized, ensuring the VF_sealed remains secure against future quantum cryptanalysis.

DPoP Proof Replay and Pre-Computation To prevent an attacker with temporary access to the signing key (or the ability to predict nonces) from pre-computing proofs, this specification mandates the use of HPKE-sealed nonces.

• Liveness Requirement: By sealing the nonce to the client's K_kem_pub, the AS ensures that only a client with active access to the hardware-bound K_kem_priv can recover the nonce and sign the proof.
• Mitigation of Malware: Malware capable of stealing a cached K_dpop from memory cannot pre-generate valid proofs for future requests because it cannot decrypt the future nonces without invoking the hardware anchor.

Normative References This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes. SPIRL SPIRL MITRE NSA-CCSS Ping Identity This specification defines a mechanism to preserve identity and authorization information across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining.

Acknowledgments TODO