Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.501  Word version:  18.4.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.2 N32-c connection between SEPPs  13.2.2.1 General  13.2.2.2 Procedure for Key agreement and Parameter exchange  13.2.2.3 Procedure for error detection and handling in SEPP  13.2.2.4 N32-f Context  13.2.2.4.0 N32-f parts  13.2.2.4.1 N32-f context ID  13.2.2.4.2 N32-f peer information  13.2.2.4.3 N32-f security context  13.2.2.4.4 N32-f context information  13.2.3 Protection policies for N32 application layer solution  13.2.3.1 Overview of protection policies  13.2.3.2 Data-type encryption policy  13.2.3.3 NF API data-type placement mapping  13.2.3.4 Modification policy  13.2.3.5 Provisioning of the policies in the SEPP  13.2.3.6 Precedence of policies in the SEPP 
...

 

13.2.2  N32-c connection between SEPPs  p. 169

13.2.2.1  General  p. 169

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 an IPX provider 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.
Up

13.2.2.2  Procedure for Key agreement and Parameter exchange  p. 170

Step 1.
The two SEPPs shall perform the following cipher suite negotiation to agree on a cipher suite to use for protecting NF service related signalling over N32-f.
Step 1a.
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.
Step 1b.
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.
Step 1c.
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.
Step 2.
The two SEPPs may perform the following exchange of Data-type encryption policies and Modification policies. Both SEPPs shall store protection policies sent by the peer SEPP:
Step 2a.
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 13.2.3.2, and Modification policies, as described in clause 13.2.3.4.
Step 2b.
The responding SEPP shall store the policies if sent by the initiating SEPP.
Step 2c.
The responding SEPP shall send a Security Parameter Negotiation Response message to the initiating SEPP with the responding SEPP's suite of protection policies.
Step 2d.
The initiating SEPP shall store the protection policy information if sent by the responding SEPP.
Step 3.
The two SEPPs shall exchange IPX security information lists that contain information on IPX public keys or certificates that are needed to verify IPX modifications at the receiving SEPP.
Step 4.
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 13.2.4.4.1.
Step 5.
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.
Step 6.
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.
Up

13.2.2.3  Procedure for error detection and handling in SEPP  p. 171

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.
Up

13.2.2.4  N32-f Context  p. 171

13.2.2.4.0  N32-f parts  p. 171
The N32-f context consists of the following main parts as illustrated in Figure 13.2.2.4.0-1:
  1. N32-f context ID
  2. N32-f peer information
  3. N32-f security context
  4. N32-f context information
Reproduction of 3GPP TS 33.501, Fig. 13.2.2.4.0-1: N32-f context overview
Figure 13.2.2.4.0-1: N32-f context overview
Up
13.2.2.4.1  N32-f context ID  p. 172
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 13.2.4.2. The receiving SEPP shall use this information to apply the correct key and parameters during decryption and validation.
Up
13.2.2.4.2  N32-f peer information  p. 172
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:
  • Remote PLMN ID;
  • Remote SEPP ID;
  • Remote SEPP address.
13.2.2.4.3  N32-f security context  p. 172
The N32-c initial handshake described in clause 13.2.2.2 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:
  • Session keys
  • Negotiated cipher suites
  • Data type encryption policy IDs
  • Modification policy list (if IPXs are used)
    • Modification policy IDs
    • IPX provider identifier
  • Counters
  • IVs
  • 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
Up
13.2.2.4.4  N32-f context information  p. 172
The N32-f context information shall consist of the following parameters:
  • Validity.
  • Usage (PRINS).

13.2.3  Protection policies for N32 application layer solution  p. 173

13.2.3.1  Overview of protection policies  p. 173

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 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.
Up

13.2.3.2  Data-type encryption policy  p. 173

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.
Up

13.2.3.3  NF API data-type placement mapping  p. 173

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.
Up

13.2.3.4  Modification policy  p. 174

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.
Up

13.2.3.5  Provisioning of the policies in the SEPP  p. 174

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.
Up

13.2.3.6  Precedence of policies in the SEPP  p. 174

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 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 13.2.2.2, 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:
Up

Up   Top   ToC