Content for  TS 33.501  Word version:  19.0.0

The dataToIntegrityProtectAndCipher is a JSON patch document as per RFC 6902 that contains all the attribute values that require both encryption and integrity protection. Attribute values may come from any part of the original HTTP message - Pseudo_Headers, HTTP_Headers and Payload. The JSON array shall contain one array entry per attribute value that needs encryption. Each array entry represents the value of the attribute to be protected, and the index in the array is used to reference the protected value within the dataToIntegrityProtect block. This associates each attribute in the dataToIntegrityProtectAndCipher block with the original attribute in the dataToIntegrityProtect block. This is needed to reassemble the original message at the receiving SEPP.

The SEPP shall use JSON Web Encryption (JWE) as specified in RFC 7516 for the protection of reformatted HTTP messages between the SEPPs. All encryption methods supported by JWE are AEAD methods, i.e. methods that encrypt and integrity protect in one single operation and can additionally integrity protect additional data. The dataToIntegrityProtectAndCipher and dataToIntegrityProtect blocks shall be input to JWE as plaintext and JWE Additional Authenticated Data (AAD) respectively. The JWE AEAD algorithm generates JWE encrypted text (ciphertext) and a JWE Authentication Tag (Message Authentication Code). The ciphertext is the output from symmetrically encrypting the plaintext, while the authentication tag is a value that verifies the integrity of both the generated ciphertext and the Additional Authenticated Data. The Flattened JWE JSON Serialization syntax shall be used to represent JWE as a JSON object. The session key shared between the two SEPPs, as specified in clause 13.2.4.4.1, shall be used as the Content Encryption Key (CEK) value to the algorithm indicated in the Encryption algorithm ("enc") parameter in the JOSE header. The algorithm ("alg") parameter in the JOSE header denoting the key exchange method shall be set to "dir", i.e. "Direct use of a shared symmetric key as the CEK". The 3GPP profile for supported cipher suites in the "enc" parameter is described in clause 13.2.4.9. The generated JWE object shall be transmitted on the N32-f interface in the payload body of a SEPP to SEPP HTTP/2 message.

The N32-f key hierarchy is based on the N32-f master key generated during the N32-c initial handshake by TLS key export. The N32-f key hierarchy consists of two pairs of session keys and two pairs of IV salts, which are used in two different HTTP/2 sessions. In one Session the N32-c initiator acts as the HTTP client and in the second the N32-c responder acts as the client. If the exported master secret is reused to set up multiple HTTP sessions or to set up new HTTP sessions on stream ID exhaustion, a new, unique, N32-f Context ID shall be generated to avoid key and IV re-use. The master key shall be obtained from the TLS exporter. The export function takes 3 arguments: Label, Context, Length (in octets) of the desired output. For the N32 Master key derivation, the Label shall be the IANA registered label "EXPORTER_3GPP_N32_MASTER" [89], the Context shall be "" (the empty string) and the Length shall be 64. The N32 key derivation function N32-KDF shall be based on HKDF [62] and shall use only the HKDF-Expand function as the initial key material has been generated securely: Each run of N32-KDF (label, L) produces either one session key or one IV salt. There are two pairs of session keys and IV salts to be derived. The labels for the JWE keys are:

• "parallel_request_key"
• "parallel_response_key"
• "reverse_request_key", and
• "reverse_response_key".

The keys derived with labels starting parallel shall be used for request/responses in an HTTP session with the N32-c initiating SEPP acting as the client (i.e. in parallel to the N32-c connection). The keys derived with the labels starting reverse shall be used for an HTTP session with the N32-c responding SEPP acting as the client. To generate the IV salts, the length is 8 and the labels are:

• "parallel_request_iv_salt",
• "parallel_response_iv_salt",
• "reverse_request_iv_salt", and
• "reverse_response_iv_salt".

The 96-bit nonce for AES_GCM shall be constructed as the concatenation of the IV salt (8 octets, 64-bits) and the sequence counter, SEQ, following Section 8.2.1 of NIST Special Publication 800-38D [63]: The sequence counter shall be a 32-bit unsigned integer that starts at zero and is incremented for each invocation of the encryption. A different sequence counter shall be maintained for each IV salt.

This is a temporary JSON object generated by a RI provider as it modifies the original message. It shall contain the following:

1. Operations - This is a JSON patch document that captures RI modifications based on RFC 6902. If no patch is required, the operations element shall be set to null.
2. Identity - This is the identity of the RI performing the modification.
3. Tag - A JSON string element to capture the "tag" value (JWE Authentication tag) in the JWE object generated by the sending SEPP. This is required for replay protection.

Only the maximum two RIs, e.g., cRI and pRI shall be able to modify messages between cSEPP and pSEPP. In cases of messages from cSEPP to pSEPP, the cRI is the first RI, while the pRI is the second RI. In cases of messages from pSEPP to cSEPP the pRI is the first RI, while the cRI is the second RI. The first RI shall parse the encapsulated request (i.e. the clearTextEncapsulationMsg in the dataToIntegrityProtect block) and determine which changes are required. The first RI creates an Operations JSON patch document to describe the differences between received and desired message, using the syntax and semantic from RFC 6902, such that, when applying the JSON patch to the encapsulated request the result will be the desired request. If no patch is required, the operations element is null. The first RI shall create a modifiedDataToIntegrityProtect JSON object as described in clause 13.2.4.5.1. The JSON object shall include the RI's identity and the JWE authentication tag, which associates this update by the RI with the JWE object created by the sending SEPP. The first RI shall use the modifiedDataToIntegrityProtect JSON object as input to JWS to create a JWS object. The first RI shall append the generated JWS object to the payload in the HTTP message and then send the messageto the next hop. The second RI shall parse the encapsulated request, apply the modifications described in the JSON patch appended by the first RI and determine further modifications required for obtaining the desired request. The second RI shall record these modifications in an additional JSON patch against the JSON object resulting from application of the first RI's JSON patch. If no patch is required, the operations element for the second JSON patch is null. The second RI shall create a modifiedDataToIntegrityProtect JSON object as described in clause 13.2.4.5.1. It shall include its identity and the JWE authentication tag, which associates this update by the second RI with the JWE object created by the sending SEPP. The second RI shall use the modifiedDataToIntegrityProtect JSON object as input to JWS to create a JWS object. The second RI shall append the generated JWS object to the payload in the HTTP message and then send the message to the receiving SEPP.

In case a roaming hub needs to originate an error message, then clause 13.2.4.5.2 shall also apply with the following addition: If an error message needs to be sent, the originating roaming hub shall insert a reformattedData JSON element including only the metadata IE as defined in TS 29.573, Table 6.2.5.2.2 for the Request, and Table 6.2.5.2.3 for the response, and the patches shall be based on a reformattedData JSON element including only the metadata. The reformattedData JSON element shall only contain metadata with N32-f message ID and N32-f context ID.