Section: 13.2.4.4.1 N32-f key hierarchy
Content: 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: N32-KDF (label, L) = HKDF-Expand (N32-f master key, "N32" || N32-Context-ID || label, L), where - label is a string used for key separation, - L is the length of output keying material in octets. 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. NOTE: In AES-GCM re-use of one IV may reveal the integrity key (Joux’s Forbidden attack). The binding of session keys and IV salts to N32-f context IDs and labels is essential to protect against inadvertent use of the same key with a repeated IV. 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]: Nonce = IV salt || SEQ. 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.