Content for TS 33.310 Word version: 19.3.1

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 profiles 6.1.3c.1 Introduction 6.1.3c.2 General SBA Certificate profile 6.1.3c.3 NF Certificate profile 6.1.3c.4 SCP certificate profile 6.1.3c.5 SEPP certificate profiles 6.1.3c.5.1 Introduction 6.1.3c.5.2 SEPP intra-domain certificate profile 6.1.3c.5.3 SEPP inter-domain certificate profile 6.1.3c.5.3.0 General 6.1.3c.5.3.1 SEPP inter-domain certificate profile for inter-PLMN 6.1.3c.5.3.2 SEPP inter-domain certificate profile for inter-SNPN 6.1.4 SEG CA certificate profile 6.1.4a TLS client/server CA certificate profile 6.1.4b NE CA certificate profile
...

6.1.3c SBA Certificate profiles |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). Those end entity certificates may be used for the following purposes:

TLS client and server certificates.
Signing validation of OAuth 2.0 access tokens.
- Signing validation of CCA (JWT based authentication) tokens.

Different end 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 end entity certificate profile is also needed to cover the usage of the certificates issued by the Interconnection CA(s) for inter-domain SBA context for TLS connections between SEPP nodes.

Furthermore, separate end entity certificate profile requirements may be applied for Service Communication Proxy (SCP) needed for 3GPP 5GC SBA Indirect Communication models 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 end entity certificates in 5GC Service Based Architecture (SBA).

6.1.3c.3 NF Certificate profile p. 27

End entity 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 TLS client and server:

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:

The certificates for use in OAuth 2.0 access tokens and CCA tokens may be configured with the following values for the keyUsage and extendedKeyUsage extensions (the rest of extensions remains the same as in Table 6.1.3c.3-2, except for TLS feature extension that it is not applicable in this case):

Table 6.1.3c.3-2: NF OAuth 2.0 Access Token and CCA Token Certificate Profile

Extensions	OID	Mandatory	Criticality	Value
keyUsage	{id-ce 15}	TRUE	TRUE	digitalSignature for JWS signing keys in OAuth 2.0 with JWT access tokens and CCA tokens. nonRepudiation (also known as "contentCommitment") is optional when digitalSignature is used instead.
extendedKeyUsage	{id-ce 37}	TRUE	FALSE	id-kp-jwt for validating the JWS signature in JWT (RFC 9509), for example for CCA token.
extendedKeyUsage	{id-ce 37}	TRUE	FALSE	id-kp-oauthAccessTokenSigning for signing OAuth 2.0 access tokens (RFC 9509).

subjectAltName shall (in TLS client and server certificates, and also in X.509 PKIX certificates used for signing validation of OAuth 2.0 JWT access tokens and/or CCA tokens) 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 RFC 4122".The URN formed using the UUID is the string "urn:uuid:" followed by a hexadecimal representation of the UUID. According to RFC 4122, 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.

NOTE 1b:
Without URI for the NF Instance ID in subjectAltName in the X.509 PKIX certificates used for signing, the identity of the NRF in JWT access token "iss" Issuer claim (i.e., in the context of Home Domain Name defined in Subject DN) cannot be securely validated by NF producers as part of the JWS signature and trust path validation procedures.
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 may (in X.509 PKIX certificates used for signing validation of OAuth 2.0 access tokens) contain URI-ID with the HTTPS URI for the "Token Endpoint" URI ("{nrfApiRoot}/oauth2/token") of an NRF instance for the Nnrf_AccessToken service API that it provides according to clause 5.4.2.2 in TS 29.510; using wildcard URIs shall 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 9525.
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 9525.

NOTE 2:
RFC 9113 states that if the server is identified by a domain name, "clients MUST send the server_name TLS extension unless an alternative mechanism to indicate the target host is used". The server_name TLS extension is commonly referred to as the Server Name Indication (SNI). TS 29.510 states that for the "https" URI scheme "the FQDN shall be provided in the NF Profile or the NF Service profile" and "it shall be used to construct the target URI". In practice, this means that literal IPv4 and IPv6 addresses are not permitted in the hostname of a "https" URI, and at least one DNS-ID subjectAltName attribute with FQDN is to be included in server-side TLS end-entity certificates.
nfTypes shall 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. 30

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

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

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

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

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