Content for  TS 33.501  Word version:  19.0.0

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:

1. Modification policy. A modification policy, as specified in clause 13.2.3.4, indicates which IEs can be modified by a Roaming Intermediary (RI) of the sending SEPP.
2. Data-type encryption policy. A data-type encryption policy, as specified in clause 13.2.3.2, indicates which types of data will be encrypted by the sending SEPP.
3. Cipher suites for confidentiality and integrity protection, when application layer security is used to protect HTTP messages between them.
4. N32-f context ID. As specified in clause 13.2.2.4.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.

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 errors are relevant for the Roaming intermediaries, the error message shall be sent over N32-f to the peer SEPP, and shall be sent over N32-c if delivery over N32-f failed. 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 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 Roaming Intermediaries. 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 roaming 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 RI 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 RI 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 RI provider. To cover the whole N32 connection, both involved roaming partners shall exchange their modification policies. The IEs that the RI 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 RI 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 RI provider and modification policies that are specific per RI 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 RI 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:

1. 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 5.9.3.3.
   • For the modification policy, the basic validation rules defined in clause 13.2.3.4.
2. Manually configured policies:
   • For the data-type encryption policy: rules according to clause 13.2.3.2, on a per roaming partner basis.
   • For the modification policy: rules according to clause 13.2.3.4, per roaming partner and per RI 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 13.2.2.2, it shall compare it to the one that has been manually configured for this specific roaming partner and RI 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 as specified in clause 6.1.4.3.2 of TS 29.573, to the peer SEPP.
• Create a local warning.