Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.1.3…   6.1.4   6.2…   6.2.2…   6.3…   6.5…   6.7…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7A.2.3…   7B…   8…   9…   10…   11…   13…   13.2.2…   13.2.4   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   I…   J…   K…   O…   P…   S…   U…   X…   Y…

 

13  Service Based Interfaces (SBI)p. 156

13.1  Protection at the network or transport layerp. 156

13.1.0  General |R16|p. 156

All network functions shall support mutually authenticated TLS and HTTPS as specified in RFC 7540 and RFC 2818. The identities in the end entity certificates shall be used for authentication and policy checks. Network functions shall support both server-side and client-side certificates. TLS client and server certificates shall be compliant with the SBA certificate profile specified in clause 6.1.3c of TS 33.310.
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 clients shall include the SNI extension as specified in RFC 7540.
TLS shall be used for transport protection within a PLMN unless network security is provided by other means.
Up

13.1.1  TLS protection between NF and SEPP |R16|p. 156

13.1.1.0  Generalp. 156

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 as specified in clause 13.1.1.1.
  • using the custom HTTP header 3gpp-Sbi-Target-apiRoot, defined in clause 5.2.3.2.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 as specified in clause 13.1.1.2.
Up

13.1.1.1  TLS protection based on telescopic FQDN and wildcard certificatep. 157

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:
    a. Nnrf_NFDiscovery_Get response HTTP message with FQDNs of a set of the discovered NF or NF service instance(s) (see 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.
    b. Subscription message with the Callback URI in the payload of the message (see 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.
    c. Nsmf_PDUSession_POST HTTP message from a V-SMF with PduSessionCreateData containing the URI representing the PDU session in the V-SMF (see 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:
  1. 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.
  2. 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 5.2.3.2.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.
  3. 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.
Up

13.1.1.2  TLS protection based on 3gpp-Sbi-Target-apiRoot HTTP headerp. 157

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

13.1.2  Protection between SEPPs |R16|p. 157

TLS shall be used for N32-c connections between the SEPPs.
If there are no IPX providers between the SEPPs, TLS shall be used for N32-f connections between the SEPPs. Different TLS connections are used for N32-c and N32-f. If there are IPX providers which only offer IP routing service between SEPPs, either TLS or PRINS (application layer security) shall be used for protection of N32-f connections between the SEPPs. PRINS is specified in clause 5.9.3 (requirements) and clause 13.2 (procedures).
If TLS is selected, the SEPP shall correlate the N32-f TLS connection with the N32-c connection. If the peer network is a PLMN, the SEPP compares the PLMN-IDs contained in the SEPP TLS certificates used to establish the N32-c and N32-f connections. If the peer network is an SNPN, the SEPP compares the SNPN-ID contained in the SEPP TLS certificates used to establish the N32-c and N32-f connections.
If there are IPX providers which, in addition to IP routing, offer other services that require modification or observation of the information and/or additions to the information sent between the SEPPs, PRINS shall be used for protection of N32-f connections between the SEPPs.
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:
Up

13.2  Application layer security on the N32 interfacep. 158

13.2.1  Generalp. 158

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-f 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-f 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.
Reproduction of 3GPP TS 33.501, Fig. 13.2.1-1: Overview of PRINS
Up

Up   Top   ToC