All network functions shall support TLS. Network functions shall support both server-side and client-side certificates.
The TLS profile shall follow the profile given in clause 6.2 of TS 33.210 with the restriction that it shall be compliant with the profile given by HTTP/2 as defined in RFC 7540 .
TLS shall be used for transport protection within a PLMN unless network security is provided by other means.
To allow for TLS protection between the SEPP and Network Functions or SCPs within a PLMN, the SEPP shall support:
TLS wildcard certificate for its domain name and generation of telescopic FQDN based on an FQDN obtained from the received N32-f message.
using the custom HTTP header 3gpp-Sbi-Target-apiRoot, defined in clause 18.104.22.168.4 of TS 29.500, in the HTTP request originated by the NF within the SEPP's PLMN, to forward the protected HTTP Request message towards the remote PLMN.
A telescopic FQDN is an FQDN with a single label as the first element and the SEPP's domain as the trailer component. The label uniquely represents the original FQDN.
The SEPP shall generate a telescopic FQDN for the following messages received over N32-f:
Nnrf_NFDiscovery_Get response HTTP message with FQDNs of a set of the discovered NF or NF service instance(s) (cf. TS 29.510). The cSEPP generates a telescopic FQDN for each target Network Function FQDN in the Discovery response, rewrites the original FQDN with the telescopic FQDN and forwards the modified Discovery response to the NRF.
Subscription message with the Callback URI in the payload of the message (cf. TS 29.501). The pSEPP generates a telescopic FQDN from the Callback URI in the Subscription message, rewrites the original FQDN in the callback URI, and forwards the modified Subscription message to the producer Network Function.
Nsmf_PDUSession_POST HTTP message from a V-SMF with PduSessionCreateData containing the URI representing the PDU session in the V-SMF (cf. TS 29.502). The pSEPP generates a telescopic FQDN from the Callback URI in the message, rewrites the original FQDN in the callback URI, and forwards the modified message to the target H-SMF.
The following procedure illustrates how SEPPs use telescopic FQDN and wildcard certificate to establish a TLS connection between a Network Function or a SCP and the SEPP:
When the SEPP receives one of the messages identified in a-c above, it shall rewrite the FQDN from the received message with a telescopic FQDN and it forwards the modified HTTP message to the target Network Function or SCP inside the PLMN.
When the Network Function or SCP that received the telescopic FQDN in step 1 is ready to communicate with the target Network Function or SCP in another PLMN, it uses the telescopic FQDN in the Request URI of the HTTP Request. When communication between the Network Function or SCP and the SEPP that generated the telescopic FQDN is based on using the 3gpp-Sbi-Target-apiRoot custom HTTP header as specified in TS 29.500, clause 22.214.171.124.4, the Network Function or SCP uses the telescopic FQDN in the 3gpp-Sbi-Target-apiRoot custom HTTP header of the HTTP Request. During TLS setup between the Network Function and the SEPP, the SEPP shall authenticate towards the Network Function or SCP using the wildcard certificate.
When the SEPP receives a HTTP request from the Network Function or SCP, the SEPP shall rewrite the telescopic FQDN with the original FQDN by replacing the unique delimiter in the label with the period character and removing its own suffix part.
The NF uses the 3gpp-Sbi-Target-apiRoot HTTP header in the HTTP Request to convey the target FQDN to the SEPPs.
If PRINS is used on the N32-f interface, the following applies: The sending SEPP shall use the 3gpp-Sbi-Target-apiRoot header to obtain the apiRoot to be used in the request URI of the protected HTTP Request. It removes the 3gpp-Sbi-Target-apiRoot header before forwarding the protected HTTP Request on the N32-f interface.
If TLS is used on the N32 interface, the following applies: The sending SEPP shall replace the authority header in the HTTP Request with the FQDN of the receiving SEPP before forwarding the protected HTTP Request on the N32 interface. The sending SEPP shall not change the 3gpp-Sbi-Target-apiRoot header.
If there are no IPX entities between the SEPPs, TLS shall be used between the SEPPs. If there are IPX entities between SEPPs, PRINS (application layer security on the N32-f interface) shall be used for protection between the SEPPs. PRINS is specified in clause 5.9.3 (requirements) and clause 13.2 (procedures).
If PRINS is used on the N32-f interface, one of the following additional transport protection methods should be applied between SEPP and IPX provider for confidentiality and integrity protection:
The internetwork interconnect allows secure communication between service-consuming and a service-producing NFs in different PLMNs. Security is enabled by the Security Edge Protection Proxies of both networks, henceforth called cSEPP and pSEPP respectively. The SEPPs enforce protection policies regarding application layer security thereby ensuring integrity and confidentiality protection for those elements to be protected.
It is assumed that there are interconnect providers between cSEPP and pSEPP. The interconnect provider the cSEPP's operator has a business relationship with is called cIPX, while the interconnect provider the pSEPP's operator has a business relationship with is called pIPX. There could be further interconnect providers in between cIPX and pIPX, but they are assumed to be transparent and simply forward the communication.
The SEPPs use JSON Web Encryption (JWE, specified in RFC 7516 ) for protecting messages on the N32 interface, and the IPX providers use JSON Web Signatures (JWS, specified in RFC 7515 ) for signing their modifications needed for their mediation services.
For illustration, consider the case where a service-consuming NF sends a message to a service-producing NF. If this communication is across PLMN operators over the N32 interface, as shown in Figure 13.2.1-1 below, the cSEPP receives the message and applies symmetric key based application layer protection, as defined in clause 13.2 of the present document. The resulting JWE object is forwarded to intermediaries. The pIPX and cIPX can offer services that require modifications of the messages transported over the interconnect (N32) interface. These modifications are appended to the message as digitally signed JWS objects which contain the desired changes. The pSEPP, which receives the message from pIPX, validates the JWE object, extracts the original message sent by the NF, validates the signature in the JWS object and applies patches corresponding to the modifications by intermediaries. The pSEPP then forwards the message to the destination NF.
The N32 interface consists of:
N32-c connection, for management of the N32 interface, and
N32-f connection, for sending of JWE and JWS protected messages between the SEPPs.
The application layer security protocol for the N32 interface described in clause 13.2 of the present document is called PRINS.
When the negotiated security mechanism to use over N32, according to the procedure in clause 13.5, is PRINS (described in clause 13.2), the SEPPs use the established TLS connection (henceforth referred to as N32-c connection) to negotiate the N32-f specific associated security configuration parameters required to enforce application layer security on HTTP messages exchanged between the SEPPs. A second N32-c connection is established by the receiving SEPP to enable it to not only receive but also send HTTP Requests.
The N32-c connection is used for the following purposes:
Key agreement: The SEPPs independently export keying material associated with the first N32-c connection between them and use it as the pre-shared key for generating the shared session key required.
Parameter exchange: The SEPPs exchange security related configuration parameters that they need to protect HTTP messages exchanged between the two Network Functions (NF) in their respective networks.
Error handling: The receiving SEPP sends an error signalling message to the peer SEPP when it detects an error on the N32-f interface.
The following security related configuration parameters may be exchanged between the two SEPPs:
Modification policy. A modification policy, as specified in clause 126.96.36.199, indicates which IEs can be modified by an IPX provider of the sending SEPP.
Data-type encryption policy. A data-type encryption policy, as specified in 188.8.131.52, indicates which types of data will be encrypted by the sending SEPP.
Cipher suites for confidentiality and integrity protection, when application layer security is used to protect HTTP messages between them.
N32-f precontext identifier values.N32-f precontext identifier values, as specified in clause 184.108.40.206.1, are used by each SEPP to construct a common N32-f context ID that identifies the set of security related configuration parameters applicable toa protected message received from a SEPP in a different PLMN.
The SEPP which initiated the first N32-c connection shall send a Security Parameter Exchange Request message to the responding SEPP including the initiating SEPP's supported cipher suites. The cipher suites shall be ordered in initiating SEPP's priority order. The SEPP shall provide a N32-f precontext ID for the responding SEPP. The precontext IDs are 32-bit random integers, represented as 0-left padded strings of hexadecimal digits.
The responding SEPP shall compare the received cipher suites to its own supported cipher suites and shall select, based on its local policy, a cipher suite, which is supported by both initiating SEPP and responding SEPP.
The responding SEPP shall send a Security Parameter Exchange Response message to the initiating SEPP including the selected cipher suite for protecting the NF service related signalling over N32. The responding SEPP shall provide a N32-f precontext ID for the initiating SEPP.
The SEPP which initiated the first N32-c connection shall send a Security Parameter Exchange Request message to the responding SEPP including the initiating SEPP's Data-type encryption policies, as described in clause 220.127.116.11, and Modification policies, as described in clause 18.104.22.168.
The two SEPPs shall export keying material from the TLS session established between them using the TLS export function. For TLS 1.2, the exporter specified in RFC 5705  shall be used. For TLS 1.3, the exporter described in section 7.5 of RFC 8446  shall be used. The exported key shall be used as the master key to derive session keys and IVs for the N32-f context as specified in clause 22.214.171.124.1.
Errors can occur on an active N32-c connection or on one or more N32-f connections between two SEPPs.
When an error is detected, the SEPP shall map the error to an appropriate cause code. The SEPP shall create a signalling message to inform the peer SEPP, with cause code as one of its parameters.
The SEPP shall use the N32-c connection it initiated to send the signalling message to the peer SEPP.
If the error occurred in the processing of the one or more N32-f message(s), the SEPP shall include the corresponding message ID (s), obtained from the metadata section of the N32-f message, as a parameter in the signalling message. This allows the peer SEPP to identify the source message(s) (HTTP Request or Response) on which the other SEPP found the error.
The N32-f context ID is used to refer to an N32-f context. The SEPPs shall create the N32-f context ID during the N32-c negotiation and use it over N32-f to inform the reveiving peer which security context to use for decryption of a received message.
The SEPPs shall create the N32-f context ID by combining the two N32-f precontext IDs, obtained during the N32-c negotiation.To avoid collision of the N32-f context ID value, the SEPPs shall select the N32-f precontext ID as a random value during the exchange over N32-c.
During transfer of application data over N32-f, the SEPP shall include the N32-f context ID in a separate IE in the metadata part of the JSON structure, see clause 126.96.36.199. The receiving SEPP shall use this information to apply the correct key and parameters during decryption and validation.
The N32-f connection between SEPPs is bidirectional and consists of the two SEPP endpoints and possibly up to two IPX providers. The SEPPs are identified by the PLMN ID and additionally a SEPP ID to distinguish between several SEPPs in the same PLMN. The remote SEPP address is necessary for routing the messages to the correct destination.
The N32-f peer information shall consist of the following parameters:
The N32-c initial handshake described in clause 188.8.131.52 establishes session keys, IVs and negotiated cipher suites. Counters are used for replay protection. Modification policies are identified by modification policy IDs, to be able to verify received messages that have undergone IPX modifications.
The N32 security context shall consist of the following parameters:
Negotiated cipher suites
Data type encryption policy IDs
Modification policy IDs (if IPXs are used)
List of security information of the IPX providers connected to the SEPPs (IPX security information list)
IPX provider identifier
List of raw public keys or certificates for that IPX
The protection policy suite is comprised of a data-type encryption policy and a modification policy. Together, these policies determine which part of a certain message shall be confidentiality protected and which part of a certain message shall be modifiable by IPX providers. The SEPP shall apply the protection policies for application layer protection of messages on the N32-f interface.
There are two types of protection policies, namely:
Data-type encryption policy: specifies which data types need to be confidentiality protected;
Modification policy: specifies which IEs are modifiable by intermediaries.
In addition, there is a mapping between the data-types in the data-type encryption policy and the IEs in NF API descriptions which is given in a NF-API data-type placement mapping.
The SEPP shall contain an operator-controlled protection policy that specifies which types of data shall be encrypted. The data-types defined are the following:
Data of the type 'SUPI';
Data of the type 'authentication vector';
Data of the type 'location data';
Data of the type 'cryptographic material';
Data of the type 'authorization token'.
The policy shall be specific per roaming partner. The policy shall contain a policy identifier and a release number referring to the release it is applicable for.
The data-type encryption policies in the two partner SEPPs shall be equal to enforce a consistent ciphering of IEs on N32-f.
Each NF API data-type placement mapping shall contain the following:
Which IEs contain data of the type 'SUPI' or type 'NAI'.
Which IEs contain data of the type 'authentication vector'.
Which IEs contain data of the type 'location data'.
Which IEs contain data of the type 'cryptographic material'.
Which IEs contain data of the type 'authorization token'.
The location of the IEs refers to the location of the IEs after the SEPP has rewritten the message for transmission over N32-f.
An NF API data-type placement mapping shall furthermore contain data that identifies the NF API, namely
The name of the NF;
The API version;
An identifier for the NF API data-type placement mapping;
The NF's 3GPP Release version.
The NF API data-type placement mapping shall reside in the SEPP.
The SEPP shall contain an operator-controlled policy that specifies which IEs can be modified by the IPX provider directly related to this particular SEPP. These IEs refer to the IEs after the sending SEPP has rewritten the message.
Each PLMN-operator shall agree the modification policy with the IPX provider it has a business relationship with prior to establishment of an N32 connection. Each modification policy applies to one individual relation between PLMN-operator and IPX provider. To cover the whole N32 connection, both involved roaming partners shall exchange their modification policies. Both complementary modification policies shall comprise the overall modification policy for this specific N32 connection.
The IEs that the IPX is allowed to modify shall be specified in a list giving an enumeration of JSON paths within the JSON object created by the SEPP. Wildcards may be used to specify paths.
This policy shall be specific per roaming partner and per IPX provider that is used for the specific roaming partner.
The modification policy shall reside in the SEPP.
For each roaming parter, the SEPP shall be able to store a policy for sending in addition to one for receiving.
The following basic validation rules shall always be applied irrespective of the policy exchanged between two roaming partners:
IEs requiring encryption shall not be inserted at a different location in the JSON object.
The SEPP shall contain an interface that the operator can use to manually configure the protection policies in the SEPP.
The SEPP shall be able to store and process the following policies for outgoing messages:
A generic data-type encryption policy;
Roaming partner specific data-type encryption policies that will take precedence over a generic data-type encryption policy if present;
NF API data-type placement mappings;
Multiple modification policies, to handle modifications that are specific per IPX provider and modification policies that are specific per IPX provider and roaming partner.
The SEPP shall also be able to store and process the following policies for incoming messages during the initial connection establishment via N32-c:
Roaming partner specific data-type encryption policies;
Roaming partner specific modification policies that specify which fields can be modified by which of its IPX providers.
This clause specifies the order of precedence of data-type encryption policies and modification policies available in a SEPP.
In increasing order of precedence, the following policies apply for a message to be sent on N32:
The set of default rules specified in the present specification:
For the data-type encryption policy, the rules on data-types that are mandatory to be encrypted according to clause 184.108.40.206.
For the modification policy, the basic validation rules defined in clause 220.127.116.11.
Manually configured policies:
For the data-type encryption policy: rules according to clause 18.104.22.168, on a per roaming partner basis.
For the modification policy: rules according to clause 22.214.171.124, per roaming partner and per IPX provider that is used for the specific roaming partner.
When a SEPP receives a data-type encryption or modification policy on N32-c as specified in clause 126.96.36.199, it shall compare it to the one that has been manually configured for this specific roaming partner and IPX provider. If a mismatch occurs for one of the two policies, the SEPP shall perform one of the following actions, according to operator policy:
Send the error message <TBD> to the peer SEPP.
Editor's Note: The error message type needs to be specified by CT4.
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:
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.
It reformats the message to produce the input to JSON Web Encryption (JWE)  as described in clause 188.8.131.52.
It applies JWE to the input created in b) to protect the reformatted message as described in clause 184.108.40.206.
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 cIPX and pIPX nodes. These IPX nodes may modify messages as follows:
a) The IPX node 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 220.127.116.11.1.
b) The IPX node uses the temporary JSON object as input into JSON Web Signature (JWS)  to create a JWS object, as described in clause 18.104.22.168.2.
c) The IPX node appends the JWS object to the received message and sends it to the next hop.
The JWS objects generated by the two IPX 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 IPX has not moved or copied an encrypted IE to a location that would be reflected from the producer NF in an IE without encryption.
The SEPP reformats an HTTP message received from an internal Network Function into two temporary JSON objects that will be intput to JWE:
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.
The dataToIntegrityProtectAndCipher: contains attribute values of the original message that require both encryption and integrity protection.
[not reproduced yet]
Figure 22.214.171.124-1: Example of JSON representation of a reformatted HTTP message
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.
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.
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, the value shall be replaced by null. The SEPP shall calculate a JSON patch document, dataToIntegrityProtectAndCipher (described in clause 126.96.36.199.2), that replaces any nulls with the required values. This is an array of objects as per RFC 6902 .
The JSON object containing information added by the sending SEPP. It shall contain:
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.
authorizedIPX ID: String identifying the first hop IPX (cIPX or pIPX) that is authorized to update the message. This field shall always be present. When there is no IPX that is authorized to update, the value of this field is set to null. The sending SEPP selects one of the IPX providers from the list exchanged with the other SEPP during parameter exchange over N32-c and includes its identifier value in this field.
N32-f context ID: Unique identifier representing the N32-f context information used for protecting the message. This is obtained from N32-f precontext IDs exchanged during parameter exchange over N32-c (clause 188.8.131.52.1).
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 dataToIntegrityProtectAndCipher is an array of JSON objects. If no IEs require protection, then this shall be an array with no elements. The sending SEPP shall construct the JSON patch document so that the receiving SEPP can insert the attribute values into the clearTextEncapsulatedMessage by applying the JSON patch document.
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 184.108.40.206.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 220.127.116.11.
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 initiatior 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 "EXPORTER_3GPP_N32_MASTER", the Context shall be "" (the empty string) and the Length shall be 64.
Editor's Note: The exporter label for this usage should be registered with IANA
The N32 key derivation function N32-KDF shall be based on HKDF  and shall use only the HKDF-Expand function as the initial key material has been generated securely:
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:
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:
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  :
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.
\fig:tinv-33-501-ny#Figure 18.104.22.168.1-1 Example of JSON representation of IPX provider modifications
This is a temporary JSON object generated by an IPX provider as it modifies the original message. It shall contain the following:
Operations - This is a JSON patch document that captures IPX modifications based on RFC 6902 . If no patch is required, the operations element shall be set to null.
Identity - This is the identity of the IPX performing the modification.
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 cIPX and pIPX shall be able to modify messages between cSEPP and pSEPP. In cases of messages from cSEPP to pSEPP, the cIPX is the first intermediary, while the pIPX is the second intermediary. In cases of messages from pSEPP to cSEPP the pIPX is the first intermediary, while the cIPX is the second intermediary.
The first intermediary shall parse the encapsulated request (i.e. the clearTextEncapsulationMsg in the dataToIntegrityProtect block) and determine which changes are required. The first intermediary 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 intermediary shall create a modifiedDataToIntegrityProtect JSON object as described in clause 22.214.171.124.1. The JSON object shall include the intermediary's identity and the JWE authentication tag, which associates this update by the intermediary with the JWE object created by the sending SEPP.
The first intermediary shall use the modifiedDataToIntegrityProtect JSON object as input to JWS to create a JWS object. The first intermediary shall append the generated JWS object to the payload in the HTTP message and then send the messageto the next hop.
The second intermediary shall parse the encapsulated request, apply the modifications described in the JSON patch appended by the first intermediary and determine further modifications required for obtaining the desired request. The second intermediary shall record these modifications in an additional JSON patch against the JSON object resulting from application of the first intermediary's JSON patch. If no patch is required, the operations element for the second JSON patch is null.
The second intermediary shall create a modifiedDataToIntegrityProtect JSON object as described in clause 126.96.36.199.1. It shall include its identity and the JWE authentication tag, which associates this update by the second intermediary with the JWE object created by the sending SEPP.
The second intermediary shall use the modifiedDataToIntegrityProtect JSON object as input to JWS to create a JWS object. The second intermediary shall append the generated JWS object to the payload in the HTTP message and then send the message to the receiving SEPP.
The IPX providers shall use JSON Web Signature (JWS) as specified in RFC 7515  for the protection of IPX provider modified attributes. The mechanism described in this clause uses signatures, i.e. asymmetric methods, with private/public key pairs.
More specifically, when an IPX 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 IPX 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 188.8.131.52.
The Flattened JWS JSON Serialization syntax shall be used to represent JWS as a JSON object.
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 shall apply the decrypted JSON patch in the dataToIntProtectAndCipher to the clearTextEncapsulatedMessage. The receiving SEPP shall use the NF API data type placement mapping and the encryption policy to verify that the correct information elements have been encrypted.
The receiving SEPP shall next verify IPX provider updates, if included, by verifying the JWS signatures added by the intermediaries. The SEPP shall verify the JWS signature, using the corresponding raw public key or certificate that is contained in the IPX provider'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. It shall then check that the raw public key or certificate of the JWS signature IPX's Identity in the modifiedDataToIntegrity block matches to the IPX provider referred to in the "authorizedIPX ID" field added by the sending SEPP, based on the information given in the IPX provider security information list.
The receiving SEPP shall check whether the modifications performed by the intermediaries were permitted by the respective modification policies. 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" clearTextEncapsulatedMessage.
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.
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.
The cSEPP shall reformate the HTTP Request message as follows:
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:
HTTP_Headers with one element per header of the original request.
Payload that contains the message body of the original request.
For the attributes that require end-to-end encryption between the two SEPPs, the cSEPP shall create a JSON patch document, whose application inserts the values to the clearTextEncapsulatedMessage. The SEPP shall replace the attribute's value in the clearTextEncapsulatedMessage by null.
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 184.108.40.206. This results in a single JWE object representing the protected HTTP Request message.
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.
The first intermediary (e.g. visited network's IPX provider) shall create a new modifiedDataToIntegrityProtect JSON object with three elements:
The Operations JSON patch document contains modifications performed by the first intermediary as per RFC 6902 .
The first intermediary shall include its own identity in the Identity field of the modifiedDataToIntegrityProtect.
The first 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 intermediary.
The intermediary shall execute JWS on the modifiedDataToIntegrityProtect JSON object and append the resulting JWS object to the message.
The second intermediary shall perform further modifications as in step 4 if required. The second intermediary shall further execute JWS on the modifiedDataToIntegrityProtect JSON object and shall append the resulting JWS object to the message.
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 applying the JSON patch document in the dataToIntegrityProtectAndCipher block. The receiving SEPP shall use the NF API data type placement mapping and the encryption policy to verify that the correct information elements have been encrypted, as described in clause 220.127.116.11.
The pSEPP then verifies IPX provider updates of the attributes in the modificationsArray. It checks whether the modifications performed by the 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.
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 7516  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 IPXs shall follow the JWS profile as defined in TS 33.210 with the restriction that they shall only use ES256 algorithm.