Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.3…   5.9…   5.10…   6…   6.1.3…   6.1.4…   6.2…   6.2.2…   6.3…   6.4…   6.5…   6.6…   6.7…   6.8…   6.9…   6.10…   6.11   6.12…   6.13   6.14…   6.15…   6.16…   7…   7A…   7A.2.3…   7B…   8…   9…   10…   11…   12…   13…   13.2.2…   13.2.4…   13.3…   13.4…   14…   15…   16…   A…   B…   C…   D…   E…   F…   G…   I…   I.9…   J…   K…   M…   N…   O…   P…   R   S…   T…   U…   V…   W…   X…   Y…   Z…

 

13.2.4  N32-f connection between SEPPsp. 181

13.2.4.1  Generalp. 181

The SEPP receives HTTP/2 request/response messages from the Network Function. It shall perform the following actions on these messages before they are sent on the N32-f interface to the SEPP in the other PLMN:
  1. It parses the incoming message and, if present, rewrites the telescopic FQDN of the receiving NF to obtain the original FQDN as described in clause 13.1.
  2. It reformats the message to produce the input to JSON Web Encryption (JWE) [59] as described in clause 13.2.4.3.
  3. It applies JWE to the input created in b) to protect the reformatted message as described in clause 13.2.4.4.
  4. It encapsulates the resulting JWE object into a HTTP/2 message (as the body of the message) and sends the HTTP/2 message to the SEPP in the other PLMN over the N32-f interface.
The message may be routed via the one or two Roaming Intermediaries, e.g., cIPX and pIPX. These RIs may modify messages as follows:
  1. The RI recovers the cleartext part of the HTTP message from the JWE object, modifies it according to the modification policy, and calculates an "operations" JSON Patch object. It then creates a temporary JSON object with the "operators" JSON Patch object and some other parameters for replay protection etc. as described in clause 13.2.4.5.1.
  2. The RI uses the temporary JSON object as input into JSON Web Signature (JWS) [45] to create a JWS object, as described in clause 13.2.4.5.2.
  3. The RI appends the JWS object to the received message and sends it to the next hop.
The JWS objects generated by the two RI providers form an auditable chain of modifications that to the receiving SEPP shall apply to the parsed message after verifying that the patches conform to the modification policy.
Encryption of IEs shall take place end to end between cSEPP and pSEPP.
A SEPP shall not include IEs in the clear that are encrypted elsewhere in the JSON object.
A SEPP shall verify that an intermediate RI has not moved or copied an encrypted IE to a location that would be reflected from the producer NF in an IE without encryption.
Up

13.2.4.2  Overall Message payload structure for message reformatting at SEPPp. 181

The SEPP reformats an HTTP message received from an internal Network Function into two temporary JSON objects that will be intput to JWE:
  1. The dataToIntegrityProtect, containing information that is only integrity protected. It consists of the following:
    • clearTextEncapsulationMessage: contains the complete original HTTP message, excluding attribute values which require encryption and, including the pseudo-header fields, HTTP headers and HTTP message body.
    • metadata: contains SEPP generated information i.e. authorizedIPX ID, N32-f message ID and N32-f context ID.
  2. The dataToIntegrityProtectAndCipher: contains attribute values of the original message that require both encryption and integrity protection.
For the details of JSON representation of a reformatted HTTP message, refer to TS 29.573.
Up

13.2.4.3  Message reformatting in sending SEPPp. 182

13.2.4.3.1  dataToIntegrityProtectp. 182
13.2.4.3.1.1  clearTextEncapsulatedMessagep. 182
The clearTextEncapsulatedMessage is a JSON object that contains the non-encrypted portion of the original message.Specifically, it consists of the following objects:
1.a)
Pseudo_Headers - the JSON object that includes all the Pseudo Headers in the message.
  • For HTTP Request messages, the object contains one entry for each of the ":method", ":path", ":scheme" and ":authority" pseudo headers. If the ":path" pseudoheader contains multiple parts separated by a slash (/) or includes a query parameter (following a "?"), an array is used to represent :path, with one element per part of the path (i.e. per "directory").
  • For HTTP Response messages, the object contains the ":status" pseudo header.
1.b)
HTTP_Headers - the JSON object that includes all the Headers in the message.
All the headers of the request are put into a JSON array called HTTP_Headers.Each entry contains a header name and value, where the value part can be an encoded index to the dataToIntegrityProtectAndCipher block, if the header value is encrypted.
1.c)
Payload - the JSON object that includes the content of the payload of the HTTP message.
Each attribute or IE in the payload shall form a single entry in the Payload JSON object. If there is any attribute value that requires encryption, it shall be moved into the dataToIntegrityProtectAndCipher JSON object (clause 13.2.4.2), and the original value in this element shall be replaced by the index in the form {"encBlockIdx": <num>} where "num" is the index of the corresponding entry in the dataToIntegrityProtectAndCipher array.
Up
13.2.4.3.1.2  metadatap. 182
The JSON object containing information added by the sending SEPP. It shall contain:
  1. N32-f message ID: Unique identifier (64-bit integer) representing a HTTP Request/Response transaction between two SEPPs. The N32-f message ID is generated by the sending SEPP and included in the HTTP Request sent over the N32 interface. The receiving SEPP uses the same N32-f message ID when it responds back with a HTTP Response. The N32-f message ID is included in the metadata portion of the JSON structure.
    b) authorizedIPX ID: String identifying the first hop RI (e.g., cIPX or pIPX) that is authorized to update the message. This field shall always be present. When there is no RI that is authorized to update, the value of this field is set to null. The sending SEPP selects one of the RI providers from the list exchanged with the other SEPP during parameter exchange over N32-c and includes its identifier value in this field.
  2. N32-f context ID: Unique identifier representing the N32-f context information used for protecting the message. This is exchanged during parameter exchange over N32-c (clause 13.2.2.4.1).
Up
13.2.4.3.2  dataToIntegrityProtectAndCipherp. 182
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.
Up

13.2.4.4  Protection using JSON Web Encryption (JWE)p. 183

13.2.4.4.0  Generalp. 183
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.
Up
13.2.4.4.1  N32-f key hierarchyp. 183
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.
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.
Up

13.2.4.5  Message modifications by roaming intermediaryp. 184

13.2.4.5.1  modifiedDataToIntegrityProtectp. 184
Reproduction of 3GPP TS 33.501, Fig. 13.2.4.5.1-1: Example of JSON representation for RI with modifications by IPX1
Up
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.
Up
13.2.4.5.2  Modifications by RIsp. 184
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.
Up
13.2.4.5.2a  Error messages originated by Roaming Hub |R18|p. 185
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.
Up

13.2.4.6  Protecting RI modifications using JSON Web Signature (JWS)p. 185

The RI providers shall use JSON Web Signature (JWS) as specified in RFC 7515 for the protection of RI provider modified attributes. The mechanism described in this clause uses signatures, i.e. asymmetric methods, with private/public key pairs.
More specifically, when an RI node modifies one or more attributes of the original HTTP message and creates a modifiedDataToIntegrityProtect object to record its modifications, it shall use JWS to integrity protect the modifiedDataToIntegrityProtect object.
The RI provider shall use its private key as input to JWS for generating the signature representing the contents of the modifiedDataToIntegrityProtect object.
The "alg" parameter in the JOSE header indicates the chosen signature algorithm. The 3GPP profile for supported algorithms is described in clause 13.2.4.9.
The Flattened JWS JSON Serialization syntax shall be used to represent JWS as a JSON object.
Up

13.2.4.7  Message verification by the receiving SEPPp. 186

The receiving SEPP determines that the received message is an error message generated by the Roaming Hub as Roaming Intermediary based on the reformattedData IE.
If the received messages is not generated by a Roaming Hub :
  • The receiving SEPP shall decrypt the JWE ciphertext using the shared session key and the following parameters obtained from the JWE object - Initialization Vector, Additional Authenticated Data value (clearTextEncapsulatedMessage in "aad") and JWE Authentication Tag ("tag").
  • The receiving SEPP shall check the integrity and authenticity of the clearTextEncapsulatedMessage and the encrypted text by verifying the JWE Authentication Tag in the JWE object with the JWE AAD algorithm. The algorithm returns the decrypted plaintext (dataToIntegrityProtectAndCipher) only if the JWE Authentication Tag is correct.
  • The receiving SEPP refers to the NF API in clearTextEncapsulatedMessage with values in the dataToIntegrityProtectAndCipher array.
  • The receiving SEPP shall next verify RI provider updates, if included, by verifying the JWS signatures added by the Roaming Intermediaries. The SEPP shall verify the JWS signature, using the corresponding raw public key or certificate that is contained in the Roaming Intermediary's security information list obtained during parameter exchange in the related N32-c connection setup or, alternatively, has been configured for the particular peer SEPP.
  • The receiving SEPP shall then check that the raw public key or certificate of the JWS signature RI's Identity in the modifiedDataToIntegrity block matches to the RI provider referred to in the "authorizedIPX ID" field added by the sending SEPP, based on the information given in the RI provider security information list.
  • The receiving SEPP shall check whether the modifications performed by the Roaming Intermediaries, i.e. cRI and pRI, were permitted by the respective modification policies. The receiving SEPP shall use the modification policy of the cRI obtained during parameter exchange in the related N32-c connection setup, and use the modification policy of pRI configured within the receiving SEPP.
  • If this is the case, the receiving SEPP shall apply the patches in the Operations field in order, perform plausibility checks, and create a new HTTP request according to the "patched" clearText­Encapsulated­Message.
  • The receiving SEPP shall verify that the PLMN-ID contained in the incoming N32-f message matches the PLMN-ID in the related N32-f context.
If the received message is an error message generated by a Roaming Hub:
  • The receiving SEPP shall check that the raw public key or certificate of the JWS signature RI's identity in the modifiedDataToIntegrityProtect block matches the adjacent Roaming Hub identity.
  • The receiving SEPP dertermines the message in which the error occurred, based on the N32-f message ID.
  • If the receiving SEPP determines from the error message that the Roaming Hub requires a modified request message, it can modify if allowed by the MNO's policy, and can resend the modified request message.
Up

13.2.4.8  Procedurep. 186

The following clause illustrates the message flow between the two SEPPs with modifications from RIs, e.g., cRI and pRI.
Reproduction of 3GPP TS 33.501, Fig. 13.2.4.8-1: Message flow between two SEPPs
Up
Step 1.
The cSEPP receives an HTTP request message from a network function. If the message contains a telescopic FQDN, the cSEPP removes its domain name from this FQDN to obtain the original FQDN as described in clause 13.1.
Step 2.
The cSEPP shall reformate the HTTP Request message as follows:
  1. The cSEPP shall generate blocks (JSON objects) for integrity protected data and encrypted data, and protecting them:
    The cSEPP shall encapsulate the HTTP request into a clearTextEncapsulatedMessage block containing the following child JSON objects:
    • Pseudo_Headers
    • HTTP_Headers with one element per header of the original request.
    • Payload that contains the message body of the original request.
    For each attribute that require end-to-end encryption between the two SEPPs, the attribute value is copied into a dataToIntegrityProtectAndCipher JSON object and the attribute's value in the clearTextEncapsulatedMessage is replaced by the index of attribute value in the dataToIntegrityProtectAndCipher block.
    The cSEPP shall create a metadata block that contains the N32-f context ID, message ID generated by the cSEPP for this request/response transaction and next hop identity.
    The cSEPP shall protect the dataToIntegrityProtect block and the dataToIntegrityProtectAndCipher block as per clause 13.2.4.4. This results in a single JWE object representing the protected HTTP Request message.
  2. The cSEPP shall generate payload for the SEPP to SEPP HTTP message:
    The JWE object becomes the payload of the new HTTP message generated by cSEPP.
Step 3.
The cSEPP shall use HTTP POST to send the HTTP message to the first Roaming Intermediary.
Step 4.
The first Roaming Intermediary (e.g. visited network's IPX provider) shall create a new modifiedDataToIntegrityProtect JSON object with three elements:
    a. The Operations JSON patch document contains modifications performed by the first Roaming Intermediary as per RFC 6902.
    b. The first Roaming Intermediary shall include its own identity in the Identity field of the modifiedDataToIntegrityProtect.
    c. The first Roaming Intermediary shall copy the "tag" element, present in the JWE object generated by the cSEPP, into the modifiedDataToIntegrityProtect object. This acts as a replay protection for updates made by the first Roaming Intermediary.
The Roaming Intermediary shall execute JWS on the modifiedDataToIntegrityProtect JSON object and append the resulting JWS object to the message.
Step 5.
The first Roaming Intermediary shall send the modified HTTP message request to the second Roaming Intermediary (e.g. home network's IPX) as in step 3.
Step 6.
The second Roaming Intermediary shall perform further modifications as in step 4 if required. The second Roaming Intermediary shall further execute JWS on the modifiedDataToIntegrityProtect JSON object and shall append the resulting JWS object to the message.
Step 7.
The second Roaming Intermediary shall send the modified HTTP message to the pSEPP as in step 3.
Step 8.
The pSEPP receives the message and shall perform the following actions:
  • The pSEPP extracts the serialized values from the components of the JWE object.
  • The pSEPP invokes the JWE AEAD algorithm to check the integrity of the message and decrypt the dataToIntegrityProtectAndCipher block. This results in entries in the encrypted block becoming visible in cleartext.
  • The pSEPP updates the clearTextEncapsulationMessage block in the message by replacing the references to the dataToIntegrityProtectAndCipher block with the referenced decrypted values from the dataToIntegrityProtectAndCipher block.
  • The pSEPP then verifies Roaming Intermediary updates of the attributes in the modificationsArray. It checks whether the modifications performed by the Roaming Intermediaries were permitted by policy.
    The pSEPP further verifies that the PLMN-ID contained in the message is equal to the "Remote PLMN-ID" in the related N32-f context.
  • The pSEPP updates the modified values of the attributes in the clearTextEncapsulationMessage in order.
The pSEPP shall re-assemble the full HTTP Request from the contents of the clearTextEncapsulationMessage.
Step 9.
The pSEPP shall send the HTTP request resulting from step 8 to the home network's NF.
Step 10.-18.
These steps are analogous to steps 1.-9.
Up

13.2.4.9  JOSE profilep. 189

SEPPs shall follow the JWE profile defined in TS 33.210 with the restriction that it shall only use AES GCM with a 128-bit or 256-bit key. The security considerations for the use of AES GCM in Section 8.4 of RFC 7518 shall be taken into account. In particular, the same key shall not be used more than 232 times and an IV value shall not be used more than once with the same key.
SEPPs and Roaming Intermediaries shall follow the JWS profile as defined in TS 33.210 with the restriction that they shall only use ES256 algorithm.
Up

Up   Top   ToC