Content for TS 33.310 Word version: 18.2.0

0… 5… 5.2… 5.2.4… 6.1.3c… 6.1a… 7… 8 9… 10… B… C… G… I…

6.1.3c SBA Certificate profile |R16| p. 26

6.1.3c.1 Introduction p. 26

Clause 6.1.3c profiles the certificates to be used for 5GC Service Based Architecture (SBA).

Different TLS entity certificate profile requirements may be applied to intra-domain and/or inter-domain SBA for NF producers, NF consumers and NRF instances, Service Communication Proxy (SCP) nodes, and Security Edge Protection Proxy (SEPP) nodes applicable to 3GPP 5GC roaming.

A separate TLS entity certificate profile is also needed to cover the usage of the certificates issued by the InterconnectionCA(s) for inter-domain SBA context for TLS connections between SEPP nodes.

Furthermore, separate TLS entity certificate profile requirements may be applied forService Communication Proxy (SCP) needed for 3GPP 5GC SBA Indirect Communication model architectural Options C and D.

6.1.3c.2 General SBA Certificate profile p. 26

The following additions and deviations to the common profiles shall hold for all SBA-related entities (NFs, SCPs, SEPPs):

Signature algorithm: RSAEncryption need not be supported.
ECDSA is recommended for TLS entity certificates with 5GC Service Based Architecture (SBA).

6.1.3c.3 NF Certificate profile p. 27

TLS certificates shall be directly signed by the CA in the operator domain that the entity belongs to.

In addition to clause 6.1.1 and the provisions of RFC 5280 the following Table captures the certificate profile for NF:

Table 6.1.3c.3-1: NF TLS Client and Server Certificate Profile

NF TLS Client and Server Certificate Profile
Version	v3
Serial Number	Unique Positive Integer in the context of the issuing Root CA and not longer than 20 octets.
Subject DN	C=<Country> O= Home Domain Name (e.g., in "5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" format) as defined in clause 28.2 of TS 23.003)
Validity Period	3 years or less
Signature	See clause 6.1.1 for the list of supported signature algorithms.
Subject Public Key Info	See clause 6.1.1 for the list of supported public key types.

Extensions	OID	Mandatory	Criticality	Value
keyUsage	{id-ce 15}	TRUE	TRUE	digitalSignature for TLS clients and servers
extendedKeyUsage	{id-ce 37}	TRUE	FALSE	id-kp-clientAuth TLS clients
extendedKeyUsage	{id-ce 37}	TRUE	FALSE	id-kp-serverAuth for TLS servers NF that may be both client and server shall have both OIDs set.
authorityKeyIdentifier	{id-ce 35}	TRUE	FALSE	This shall be the same as subjectKeyIdentifier of the Issuer's certificate. CA shall utilitize the method (1) as defined in Section 4.2.1.2 of RFC 5280 to generate the value for this extension.
subjectKeyIdentifier	{id-ce 14}	FALSE	FALSE	This shall be calculated by the issuing CA utilitizing the method (1) as defined in Section 4.2.1.2 of RFC 5280 to generate the value for this extension.
cRLDistributionPoint	{id-ce 31}	TRUE	FALSE	distributionPoint According to RFC 5280 this indicates if the CRL is available for retrieval using access protocol and location with LDAP or HTTP URI.
subjectAltName	{id-ce 17}	TRUE	TRUE	Multiple subjectAltName entries can be used as a sequence, see below for the detailed instructions.
nfTypes	{id-pe 34}	TRUE	FALSE	id-pe-nftypes specified in RFC 9310 enables including Network Function types (NFTypes) for the 5G System in X.509 v3 public key certificates.
authorityInfoAccess	{id-pe 1}	FALSE	FALSE	id-ad-caIssuers According to RFC 5280 id-ad-caIssuers describes the referenced description server and the access protocol and location, for example, using one or multiple HTTP and/or LDAP URIs.
authorityInfoAccess	{id-pe 1}	FALSE	FALSE	id-ad-ocsp According to RFC 5280 id-ad-ocsp defines the location of the OCSP responder using HTTP URI.
TLS feature extension	{id-pe 24}	FALSE	FALSE	id-pe-tlsfeature This can be used according to RFC 7633 to prevent downgrade attacks that are not otherwise prevented by the TLS protocol; also to be used with OCSP stapling with TLS server end-entity certificates.

With (intra-domain) SBA, the following rules are applied:

subjectAltName shall (in TLS client and server certificates) contain a URI-ID with the URI for the NF Instance ID as an URN; this URI-ID shall contain the nfInstanceID of the Network Function instance using the format of the NFInstanceId as described in clause 5.3.2 of TS 29.571.

NOTE 1:
According to clause 5.3.2 of TS 29.571 "The format of the NF Instance ID shall be a Universally Unique Identifier (UUID) version 4, as described in IETF RFC 4122 [x]".The URN formed using the UUID is the string "urn:uuid:" followed by a hexadecimal representation of the UUID. According to IETF RFC 4122 [x], in a version 4 UUID, the 13th hex digit is '0100' i.e., '4' and the 17th hex digit is '10xx' i.e., in the range '8'-'b'. For example, "urn:uuid: c84792af-f99f-4eca-a17c-ed0c9699e225" is the string representation of the NF Instance ID " c84792af-f99f-4eca-a17c-ed0c9699e225" as a URN.

NOTE 1a:
Without URI for the NF Instance ID in subjectAltName in the TLS client and/or server certificates, the identity of the NF instance can not be securely validated when using the NF instance certificate by the receiving peer.
subjectAltName should (in TLS server certificates) contain URI-ID with the HTTPS URI(s) for the apiRoot of a Network Function producer instance for the NF service API(s) that it provides; using wildcard URIs should be avoided;.
subjectAltName should (in TLS server certificates) contain DNS-ID with the FQDN(s) (host DNS name) of the NF service callback URI(s) that a Network Function consumer instance provides; the rules for using wildcard certificates in DNS-ID are described in RFC 6125.
subjectAltName should (in TLS client certificates) or shall (for TLS server certificates) contain a DNS-ID with the FQDN (host DNS name) for the Network Function instance, for example, using the instructions for Network Function (host DNS) names in FQDN format as used for Network Function producers in NFProfile and/or in NFService profile according to clause 6.1.6.2 of TS 29.510, and in general as described in clause 28.3 of TS 23.003 (regardless if DNS is available or not); for AMF, this is the AMF Name as described in clause 28.3.2.5 of TS 23.003; for NRF, this is the NRF FQDN as described in clause 28.3.2.3.2 of TS 23.003; the rules for using wildcard certificates in DNS-ID are defined in RFC 6125.

NOTE 2:
RFC 9113 mandates using the Server Name Indication (SNI) extension to TLS with HTTP/2. RFC 6066, which is applicable to TLS 1.2, defines that currently only server names supported in SNI extension to TLS are DNS hostnames where "HostName" contains the fully qualified DNS hostname (FQDN) of the TLS server. RFC 6066 also defines that literal IPv4 and IPv6 addresses are not permitted in "HostName". In practice, this means that at least one subjectAltName attribute with FQDN is to be included in server-side TLS end-entity certificates.
nfTypes shall (in TLS client and server certificates) contain NF type for the Network Function instance formatted according to RFC 9310 using the Enumerated NF Type format according to clause 6.1.6.3.3 of TS 29.510.

NOTE 3:
Void.
subjectAltName shall not contain only IP address in TLS server certificates.

NOTE 4:
Void.

6.1.3c.4 SCP certificate profile p. 29

TLS certificates shall be directly signed by the CA in the operator domain that the SCP entity belongs to.

The same requirements to the NF certificate profile as listed in clause 6.1.3c.3 apply, except for the following requirements:

The following requirement is not applicable: "subjectAltName should (in TLS server certificates) contain URI-ID with the HTTPS URI(s) for the apiRoot of a Network Function producer instance for the NF service API(s) that it provides; using wildcard URIs should be avoided";
The following requirement is not applicable: "subjectAltName should (in TLS server certificates) contain DNS-ID with the FQDN(s) (host DNS name) of the NF service callback URI(s) that a Network Function consumer instance provides; the rules for using wildcard certificates in DNS-ID are described in RFC 6125".

6.1.3c.5 SEPP certificate profiles p. 30

6.1.3c.5.1 Introduction p. 30

The TLS certificate requirements on the SEPP depend on whether the certificate is used in intra-domain or inter-domain cases.

SEPP intra-domain certificate profile requirements are applied for SEPP when connecting to other NFs/ SCPs/ SEPPs in the same operator domain. For example, it is applied for SEPP when providing the Nsepp_Telescopic_FQDN_Mapping service to the NFs/SEPPs in the same operator domain.

SEPP inter-domain certificate profile requirements are applied for SEPP when connecting to SEPPs in other operator domains.

6.1.3c.5.2 SEPP intra-domain certificate profile p. 30

TLS certificates used between a SEPP and other NFs/SCPs/SEPPs in the same operator domain shall be directly signed by the root CA or an intermediate CA whose certificate has a valid certificate chain up to this root CA in the operator domain that the SEPP entity belongs to.

The NF certificate profile requirements in clause 6.1.3c.2 and clause 6.1.3c.3 apply for SEPP intra-domain certificate profiles.

6.1.3c.5.3 SEPP inter-domain certificate profile |R18| p. 30

6.1.3c.5.3.0 General p. 30

The SEPP inter-domain certificate is used when a SEPP interconnects to other SEPPs in the different network domain, e.g., a PLMN or a SNPN.

6.1.3c.5.3.1 SEPP inter-domain certificate profile for inter-PLMN p. 30

In general, the same requirements to the NF certificate profile as listed in clause 6.1.3c.2 and 6.1.3c.3 apply for SEPP inter-domain certificate profiles, except for the the contents of the Subject DN field as well as the subjectAltName field.

For inter-PLMN domain N32 certificates, the contents of the Subject DN field as well as the subjectAltName field are specified in GSMA FS.34 [60].

6.1.3c.5.3.2 SEPP inter-domain certificate profile for inter-SNPN p. 30

For inter-SNPN domain N32 certificates, the SEPP certificates shall include all PLMN IDs and Network identifiers (NIDs) identify the SNPN in SAN fields as DNS name for where it runs the N32 connection, and the subjectAltName field SHALL be structured as

<SEPP-id>.sepp. 5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org

where SEPP-id is the SEPP ID as specified in the TS 33.501, and NID is the Network Identifier as specified in the TS 23.003.

6.1.4 SEG CA certificate profile p. 30

In addition to clause 6.1.1, the following requirements apply:

Subject name is the same as the issuer name in the SEG certificate;
Issuer name depends on the usage of the certificates issued by the SEG CA:
- if used for interconnections between security domains with different root CAs the issuer name is the same as the subject name in the Interconnection CA certificate;
- if used for connections with elements having the same root CA certificate installed as used in the domain the SEG CA is located in, the issuer name is the subject name of either this root CA or an intermediate CA whose certificate has a valid certificate chain up to this root CA;
Extensions:
- Optionally non critical authority key identifier;
- Optionally non critical subject key identifier;
- Mandatory critical key usage: At least keyCertSign and cRLSign, should be asserted;
- Mandatory critical basic constraints: CA=True, path length 0.

6.1.4a TLS client/server CA certificate profile |R7| p. 31

In addition to clause 6.1.1, the following requirements apply:

Subject name is the same as the issuer name in the TLS entity certificate;
Issuer name depends on the usage of the certificates issued by the TLS client/server CA:
- if used for interconnections between security domains with different root CAs the issuer name is the same as the subject name in the Interconnection CA certificate;
- if used for connections with elements having the same root CA certificate installed as used in the domain the TLS client/server CA is located in, the issuer name is the subject name of either this root CA or an intermediate CA whose certificate has a valid certificate chain up to this root CA;
- if used for TLS clients with certificates not issued by an operator CA, the issuer name is the subject name of either a root CA trusted by the operator or an intermediate CA whose certificate has a valid certificate chain up to a root CA trusted by the operator;
Extensions:
- Optionally non critical authority key identifier;
- Optionally non critical subject key identifier;
- Mandatory critical key usage: At least keyCertSign and cRLSign, should be asserted;
- Mandatory critical basic constraints: CA=True, path length 0.

6.1.4b NE CA certificate profile |R8| p. 31

The same requirements as listed in clause 6.1.4 apply except that there is no restriction in the issuer name.