JOSE T. Reddy Internet-Draft Nokia Intended status: Standards Track H. Tschofenig Expires: 7 August 2025 H-BRS 3 February 2025 Enhanced JWE Security with Detached Additional Authenticated Data (AAD) draft-reddy-jose-detached-aad-00 Abstract This draft introduces a mechanism to support detached Additional Authenticated Data (AAD) in JWE (JSON Web Encryption), allowing the AAD to be derived from context-specific information, such as session identifiers, algorithm identifiers, and identifiers of communication endpoints, rather than being transmitted in-band. This mechanism strengthens security by mitigating risk against unknown-key-share attacks and/or other exploitation techniques that depend on some type of confusion over the role played by each party. The document explains how to integrate this functionality into JWE, covering both JWE JSON Serialization and JWE Compact Serialization. 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 7 August 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Reddy & Tschofenig Expires 7 August 2025 [Page 1] Internet-Draft Enhanced JWE Security with Detached AAD February 2025 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 3 4. Benefits of Detached AAD . . . . . . . . . . . . . . . . . . 4 5. JWE JSON Serialization . . . . . . . . . . . . . . . . . . . 4 6. JWE Compact Serialization . . . . . . . . . . . . . . . . . . 5 6.1. Supporting Detached AAD in JWE Compact Serialization . . 5 6.2. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5 7. Deriving detached AAD . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9.1. JSON Web Signature and Encryption Header Parameters . . . 8 9.1.1. aad_detached . . . . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Encryption of payloads is performed using a symmetric content encryption key, which can be established through various key distribution mechanisms. Examples of such content key distribution mechanisms include public key encryption, such as HPKE, and ephemeral-static Diffie-Hellman. As part of this content key distribution mechanism an important design decision is what information is included about the context in which the encryption is use. This ensures that the content key material is "bound" to the context of the transaction. There are various techniques to ensure that the established content encryption key is not used across different contexts, such as incorporating the context into the key derivation function, adding extra context information in protected JOSE headers, or including out-of-band information in the Additional Authenticated Data (AAD). Reddy & Tschofenig Expires 7 August 2025 [Page 2] Internet-Draft Enhanced JWE Security with Detached AAD February 2025 This specification uses the AAD for including context information shared out of band. This approach reduces the amount of data transmitting directly within the message. It enhances security by ensuring the cryptographic binding of context information, by minimizing the attack surface. As a consequence, the AAD must be derived by both the sender and receiver independently. A JSON-based data structure is proposed to standardize the AAD information. The described approach is applicable to both JWE JSON Serialization and JWE Compact Serialization. This mechanism is particularly useful in scenarios like OpenID for Verifiable Credentials (OID4VC), where a verifier must validate context information without depending on in- band AAD. 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. 3. Motivation and Use Cases A common use case for detached AAD arises in protocols like OpenID for Verifiable Credentials (OID4VC), where a verifier receives a JWE response from a wallet application. In such scenarios: * The verifier sends a request to the wallet (typically a mobile app). * The wallet responds with an encrypted message that includes context information (e.g., the origin and the recipient of the request) as part of the AAD. * Without proper validation of AAD, attackers could exploit vulnerabilities by manipulating context data, potentially leading to malicious actions. By requiring the verifier and wallet to securely agree on a method for deriving the AAD, the encrypted response can be cryptographically bound to the request's context. This ensures the response is valid only within its intended context, reducing risks such as phishing, replay, and tampering attacks. Reddy & Tschofenig Expires 7 August 2025 [Page 3] Internet-Draft Enhanced JWE Security with Detached AAD February 2025 4. Benefits of Detached AAD The introduction of detached AAD offers several key benefits: * Improved Security: By deriving AAD directly from the context, the need to transmit and validate in-band AAD is eliminated. This minimizes the attack surface and reduces the risks of tampering and replay. * Enhanced Flexibility: Applications gain greater control over AAD usage, ensuring it is transmitted only when necessary and otherwise derived out-of-band. * Consistency Across Serializations: Supporting detached AAD in both JWE JSON Serialization and JWE Compact Serialization enables a consistent approach to context-specific AAD across various serialization formats. 5. JWE JSON Serialization When the AAD is detached, the "detached_aad" parameter is set to true, indicating that the AAD MUST be computed by both the sender and receiver from context information. * If the "detached_aad" parameter is true, the detached AAD MUST be derived out-of-band, following the process specified in Step 5 of Section 7. * If the "aad" parameter contains data, it is used directly as the AAD for encryption. * If both the "detached_aad" and "aad" parameters are present, the AADs are combined and used according to the process outlined in Step 5 of Section 7. * The derived AAD is treated as part of the encryption context but is never transmitted within the JWE structure. Example: A JSON Encoded JWE is shown below (with line-breaks added for readability). Reddy & Tschofenig Expires 7 August 2025 [Page 4] Internet-Draft Enhanced JWE Security with Detached AAD February 2025 { "protected": "eyJhbGciOiJIUEtFLVAyNTYtU0hBMjU2LUExMjhHQ00iLCJlbmMiOiJkaXIiLCJraWQiOiJ1cm46aWV0ZjpwYXJhbXM6b 2F1dGg6andrLXRodW1icHJpbnQ6c2hhLTI1NjpTNkFYZmRVXzZZZnp2dTBLRERKYjBzRnV3bklXUGs2TE1URXJZaFBiMzJzIiwicHNrX2l kIjoib3VyLXByZS1zaGFyZWQta2V5LWlkIiwiYXV0aF9raWQiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6andrLXRodW1icHJpbnQ6c2hhL TI1NjpTNkFYZmRVXzZZZnp2dTBLRERKYjBzRnV3bklXUGs2TE1URXJZaFBiMzJzIn0", "encrypted_key": "BD7QVodtG-FwYASgb36zuTzUCc80aiYwS6JOOE-6_heUGyAZt-cU0818e4oYqP7ebBuW3KTM9EQA0vM5fWp6hj0", "ciphertext": "ZxqtYoomgVQGctnv1I_EBVI1NIeJ7qJw2iVtqwUw3fXa8FK-", "aad": "8J-PtOKAjeKYoO-4jyBiZXdhcmUgdGhlIGFhZCE" } After verification: { "protectedHeader": { "alg": "HPKE-0", "enc": "dir", "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s", "psk_id": "our-pre-shared-key-id", "auth_kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s", "aad_detached": true }, "plaintext": "This is plaintext!", "aad": "This is aad!" } In this case, the "aad_detached" parameter set to true indicates that the AAD must be derived from context information shared between the sender and receiver. 6. JWE Compact Serialization 6.1. Supporting Detached AAD in JWE Compact Serialization To enable the use of detached Additional Authenticated Data (AAD) without introducing backward compatibility issues, this specification defines a mechanism that leverages external context-specific information and an optional protected header parameter to signal the presence of detached AAD. The existing JWE Compact Serialization format, as defined in Section 7.1 of [RFC7516], remains unchanged. 6.2. Mechanism Overview 1. External Metadata for Detached AAD: The detached AAD is not included in the JWE Compact Serialization format. 2. Optional Protected Header Parameter: Reddy & Tschofenig Expires 7 August 2025 [Page 5] Internet-Draft Enhanced JWE Security with Detached AAD February 2025 * A new optional parameter, "detached_aad", is introduced in the JWE Protected Header. * When set to true, this parameter indicates that the AAD is detached and must be obtained through an external context. 3. Backward Compatibility: This mechanism does not alter the structure of the JWE Compact Serialization format, ensuring full compatibility with existing implementations. The "aad_detached": true parameter is included in the JWE Protected Header. For example: { "alg": "HPKE-0", "enc": "A256GCM", "detached_aad": true } 7. Deriving detached AAD When using detached AAD, both the sender and receiver MUST follow the same derivation process to ensure consistency. The derived AAD is never transmitted; instead, it is independently computed by both parties. The process for deriving the AAD involves the following steps: 1. Identify Context Information Elements: Applications define the context information required for AAD derivation and they are shared by both sender and receiver. Example: { "session_id": "sess-1234", "sender": "alice@example.com", "receiver": "bob@example.com" } 1. Normalize Context Information Elements * Each context element MUST be encoded as a UTF-8 string. * The elements MUST be sorted in lexicographical order of their keys (as per [RFC8785]), ensuring consistent ordering during derivation. Example: Reddy & Tschofenig Expires 7 August 2025 [Page 6] Internet-Draft Enhanced JWE Security with Detached AAD February 2025 Normalize Elements (Sorted): { "sender": "alice@example.com", "session_id": "sess-1234", "receiver": "bob@example.com" } 1. Serialize the Canonicalized JSON: Serialize the canonicalized JSON object, ensuring it has no extra spaces or newlines. Example: Concatenated String: {"sender": "alice@example.com","session_id":"sess-1234","receiver":"bob@example.com"} 1. Apply Cryptographic Hashing: Apply a cryptographic hash function (e.g., SHA-256) to the serialized canonicalized JSON string to derive the AAD. The resulting hash will serve as the AAD used in the encryption operation. The use of SHA-256 is RECOMMENDED; however, other cryptographic hash functions MAY be used if they provide equivalent or stronger security properties. Example: Derived AAD: "SHA256({"session_id":"sess-1234","timestamp":"2025-01-10T12:00Z"})" 1. Use the Derived AAD in Encryption * Step 15 in Section 5.1 of [RFC7516] outlines how the AAD is used in the encryption operation. In the case of detached AAD, the derived AAD is treated as part of the encryption context, even though it is never transmitted within the JWE structure. * For a message that lacks the JWE AAD but includes the derived AAD, the derived AAD is used in conjunction with the Content Encryption Key (CEK), JWE IV, and the message M to generate the JWE Ciphertext and JWE Authentication Tag. The Additional Authenticated Data (AAD) encryption parameter is: ASCII(Encoded Protected Header || '.' ||BASE64URL(Detached AAD)). * In the case of a message containing both the JWE AAD and the derived AAD, the derived AAD is used in conjunction with the Content Encryption Key (CEK), JWE IV, JWE AAD, and the message M to generate the JWE Ciphertext and JWE Authentication Tag. The Additional Authenticated Data (AAD) encryption parameter is: ASCII(Encoded Protected Header || '.' ||BASE64URL(JWE AAD)|| '.' ||BASE64URL(Detached AAD)). Reddy & Tschofenig Expires 7 August 2025 [Page 7] Internet-Draft Enhanced JWE Security with Detached AAD February 2025 * Both the sender and receiver MUST independently compute the detached AAD to ensure consistency. * The detached AAD is not transmitted within the JWE structure; instead, it is derived from context information elements out-of- band. 1. Error Handling: If the derived AAD does not match the expected value during decryption, the JWE MUST be treated as invalid, and the decryption process MUST fail. 8. Security Considerations Detached AAD enhances security by ensuring that the AAD is tightly bound to the specific context shared by both the sender and recipient. However, the following considerations must be observed: * Both the sender and recipient MUST use the same method to derive the AAD from the context to avoid mismatches, as discrepancies will lead to decryption failures. * Applications using detached AAD must ensure that context information is validated and securely exchanged to prevent manipulation by attackers. * Implementations should account for potential synchronization issues, such as clock drift, when deriving the AAD from time- sensitive context. 9. IANA Considerations 9.1. JSON Web Signature and Encryption Header Parameters The following entry is requested to be added by IANA to the "JSON Web Signature and Encryption Header Parameters" registry: 9.1.1. aad_detached * Header Parameter Name: "detached_aad" * Header Parameter Description: Indicates that the AAD is detached and must be conveyed through an external mechanism. * Header Parameter Usage Location(s): JWE * Change Controller: IETF * Specification Document(s): RFCXXXX Reddy & Tschofenig Expires 7 August 2025 [Page 8] Internet-Draft Enhanced JWE Security with Detached AAD February 2025 Acknowledgments TODO Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . Authors' Addresses Tirumaleswar Reddy Nokia Bangalore Karnataka India Email: kondtir@gmail.com Hannes Tschofenig University of Applied Sciences Bonn-Rhein-Sieg Germany Email: Hannes.Tschofenig@gmx.net Reddy & Tschofenig Expires 7 August 2025 [Page 9]