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 220.127.116.11, 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 clause 18.104.22.168, 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 context ID. As specified in clause 22.214.171.124.1, N32-f context ID identifies the set of security related configuration parameters applicable to a 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 an initiating SEPP's N32-f context ID for the responding SEPP.
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 responding SEPP's N32-f context 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 126.96.36.199, and Modification policies, as described in clause 188.8.131.52.
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 184.108.40.206.1.
When the responding SEPP needs to initiate traffic, e.g., error reporting, in the reverse direction to the sending SEPP, the responding SEPP in the first N32-c connection shall now setup a second N32-c connection by establishing a mutually authenticated TLS connection with the peer SEPP.
The two SEPPs start exchanging NF to NF service related signalling over N32-f and tear down the N32-c connection. The SEPPs may initiate new N32-c TLS sessions for any further N32-c communication that may occur over time while application layer security is applied to N32-f.
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 to send the signalling message to the peer SEPP. If the old N32-c connection has been terminated, it uses a new N32-c connection instead.
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 receiving peer which security context to use for decryption of a received message.
The initiating SEPP shall send the initiating SEPP's N32-f context ID to the responding SEPP which the responding SEPP shall use to identify the N32-f connection with this initiating SEPP. Vice versa, the responding SEPP shall send the responding SEPP's N32-f context ID to the initiating SEPP which the initiating SEPP shall use to identify the N32-f connection with this responding SEPP. To avoid collision of the N32-f context ID value, the SEPPs shall select the N32-f context 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 220.127.116.11. 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 18.104.22.168 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-f security context shall consist of the following parameters:
Negotiated cipher suites
Data type encryption policy IDs
Modification policy list (if IPXs are used)
Modification policy IDs
IPX provider identifier
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.
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 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 22.214.171.124.
For the modification policy, the basic validation rules defined in clause 126.96.36.199.
Manually configured policies:
For the data-type encryption policy: rules according to clause 188.8.131.52, on a per roaming partner basis.
For the modification policy: rules according to clause 184.108.40.206, 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 220.127.116.11, 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: