6 Profiling

33.3103GPPAuthentication Framework (AF)Network Domain Security (NDS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Certificate profiles

NOTE: The present clause contains the general 3GPP certificate profile. Other 3GPP specifications (e.g. TS 33.203 [9], TS 33.220 [10], etc.) point to the present clause. Thus parts of the present clause may also apply to devices and network nodes as specified in other specifications. New specifications using certificates should refer to this profile with as few exceptions as possible.

The present clause profiles the certificates to be used for NDS/AF. An NDS/AF component shall not expect any specific behaviour from other entities, based on certificate fields not specified in this section.

Certificate profiling requirements as contained in this specification have to be applied in addition to those contained within RFC5280 [14]. In case of conflicting requirements, the requirements in this specification override and obsolete the requirements in RFC5280 [14]. This applies for the SEG, NE, the TLS entity, the SEG CA and the Interconnection CA.

A receiving SEG or TLS entity shall be able to process an extension marked as critical in the present document.

Before fulfilling any certificate signing request, the NE CA, SEG CA and Interconnection CA shall make sure that the request suits the profiles defined in this section. Furthermore, the CAs shall check the Subject’s DirectoryString order for consistency, and that the Subject’s DirectoryString belongs to its own administrative domain.

NEs, SEGs and TLS entities shall check compliance of certificates with the NDS/AF profiles and shall only accept compliant certificates.

6.1.1 Common rules to all certificates

– Version 3 certificate according to RFC5280 [14].

– Hash algorithm for use before signing certificate: SHA-256 shall be supported, SHA-384 should be supported, MD5, MD2, and SHA-1 shall not be supported.

NOTE 1: Void.

– Signature algorithm: RSAEncryption and ecdsa shall be supported. RSAEncryption is not recommended as it uses PKCS#1v1.5 padding.

– Public key algorithm: rsaEncryption and id-ecPublicKey shall be supported.

– Parameters: For ecdsa and id-ecPublicKey, secp256r1 shall be supported. secp384r1 should be supported.

– ECDSA is recommended for newly created certificates.

– For RSA certificates: The public key length shall be at least 2048-bit. A public key length of at least 4096-bit shall be supported. Public key lengths of less than 2048-bit shall not be supported. PKCS#1v1.5 padding and key lengths less than 3072-bits should not be used in certificates that expire after 2030. RSA public exponent shall be no less than 65537.

– For ECDSA certificates: Except curve25519, ed25519, and W-25519, elliptic curve groups of less than 256 bits shall not be supported. A public key length of at least 384-bit shall be supported. Deterministic ECDSA [58] may be used.

NOTE 2: Void.

NOTE 3: In practice, certificates often have a long lifetime, for example about ten years. The use of RSA with PKCS#1v1.5 padding and key lengths less than 3072-bits is planned to be prohibited by several organisations no later than 2030.

– The security level of the public key used to sign the certificate shall be at least the same as the public keys in the certificate.

– Subject and issuer name format.

– (C=<country>), O=<Organization Name>, CN=<Some distinguishing name>. Organization and CN shall be in UTF8 format. Note that C is optional element.

– cn=<hostname>, (ou=<servers>), dc=<domain>, dc=<domain>. Note that ou is optional element.

– CRLs as specified in subclause 6.1a shall be supported for certificate revocation verification.

– OCSP as specified in subclause 6.1b should be supported for certificate revocation verification.

– Certificate extensions which are not mandated by this specification but which are mentioned within RFC5280 [14] are optional for implementation. If present, such optional extensions shall be marked as “non critical“.

NOTE 3: The above requirement implies that an NE, SEG or TLS entity receiving such optional extensions marked as “critical” will react with an error because, according to the introduction to clause 6.1 of the present document, NEs, SEGs and TLS entities shall only accept compliant certificates.

6.1.2 Interconnection CA Certificate profile

In addition to clause 6.1.1, the following requirements apply:

– 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 unlimited or at least 1.

6.1.3 SEG Certificate profile

SEG certificates shall be directly signed by the SEG CA in the operator domain that the SEG belongs to. Any SEG shall use exactly one certificate to identify itself within the NDS/AF.

In addition to clause 6.1.1 and the provisions of RFC4945 [15], the following requirements apply:

– Issuer name is the same as the subject name in the SEG CA certificate.

– Extensions:

– Optionally non critical authority key identifier;

– Optionally non critical subject key identifier;

– Mandatory non-critical subjectAltName;

– Mandatory critical key usage: At least digitalSignature or nonRepudiation bits shall be set;

– Mandatory non-critical Distribution points: CRL distribution point;

NOTE: Depending on the availability of DNS between peer SEGs, the following rule is applied:

– subjectAltName should contain IP address (in case DNS is not available);

– subjectAltName should contain FQDN (in case DNS is available).

6.1.3a TLS entity certificate profile

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

In addition to clause 6.1.1, the following requirements apply:

– For SIP domain certificates, the recommendations in RFC 5922 [21] and RFC 5924 [22] should be followed.

– Issuer name is the same as the subject name in the TLS CA certificate.

– Extensions:

– Optionally non critical authority key identifier;

– Optionally non critical subject key identifier;

– Mandatory critical key usage: At least digitalSignature or keyEncipherment shall be set; According to RFC 8446 [49] keyAgreement shall be set on Diffie-Hellman certificates;

– Optional non-critical extended key usage: If present, at least id-kp-serverAuth shall be set for TLS server certificates, and at least id-kp-clientAuth shall be set for TLS client certificates;

– Mandatory non-critical Distribution points: CRL distribution point.

6.1.3b NE Certificate profile

NE certificates shall be directly signed by the NE CA in the operator domain that the NE belongs to. Any NE shall use exactly one certificate to identify itself within the NDS/AF.

The same requirements as listed in section 6.1.3 apply.

6.1.3c SBA Certificate profile

6.1.3c.1 Introduction

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

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

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

NOTE: RFC 6125 [52] describes guidelines and procedures for representing and verifying the identity of application service using X.509 PKIX certificates with TLS. It mandates use of subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over the use of the subject field (CN-ID) where available. Furthermore, it is stated that a client does not seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client. Additionally, CA-browser forum [59] has the following requirement on the CN-ID: if CN-ID is present, this field contains exactly one entry that is one of the values contained in the Certificate’s subjectAltName extension.

In addition to clause 6.1.1 and the provisions of RFC 5280 [14] 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 [55])
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
				keyEncipherment for TLS 1.2 [54] servers NF that may be both TLS 1.2 [54] client and server shall have both flags set.
extendedKeyUsage	{id-ce 37}	TRUE	FALSE	id-kp-clientAuth TLS clients
				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 clause 4.2.1.2 of RFC 5280 [14] 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 clause 4.2.1.2 of RFC 5280 [14] to generate the value for this extension.
cRLDistributionPoint	{id-ce 31}	TRUE	FALSE	distributionPoint Ac cording to RFC 5280 [14] 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.
authorityInfoAccess	{id-pe 1}	FALSE	FALSE	id-ad-caIssuers According to RFC 5280 [14] 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.
				id-ad-ocsp According to RFC 5280 [14] 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 [53] 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 should (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 [57].

NOTE 1: Since the format of the NF instance ID according to clause 5.3.2 of TS 29.571 [57] is a universally unique identifier (UUID), the URN formed using the UUID is the string "urn:uuid:" followed by a hexadecimal representation of the UUID. For example, "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" is the string representation of the NF Instance ID "f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 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 [51].

– 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 in TS 29.510 [56], and in general as described in clause 28.3 of TS 23.003 [55] (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 [55]; for NRF, this is the NRF FQDN as described in clause 28.3.2.3.2 of TS 23.003 [55]; the rules for using wildcard certificates in DNS-ID are defined in RFC 6125 [51].

NOTE 2: RFC 7540 [50] mandates using the Server Name Indication (SNI) extension to TLS with HTTP/2. RFC 6066 [51], 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 [51] 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.

– subjectAltName should (in TLS client certificates) contain NF type as DNS-ID (that is, using dNSName subjectAltName) for the Network Function instance using the Enumerated NF Type format according to clause 6.1.6.3.3 of TS 29.510 [56].

NOTE 3: If NF type is used in DNS-ID format in subjectAltName then it is considered as case-insensitive.

– subjectAltName shall not contain only IP address in TLS server certificates.

6.1.3c.4 SCP certificate profile

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 [51]".

6.1.3c.5 SEPP certificate profiles

6.1.3c.5.1 Introduction

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

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 6.1.3c.3 apply for SEPP intra-domain certificate profiles.

6.1.4 SEG CA certificate profile

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

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

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

6.1a CRL profile

– Version 2 CRL according to RFC5280 [14].

– Hash algorithm for use before signing CRL: SHA-256 shall be supported SHA-384 should be supported, MD5 MD2, and SHA-1 shall not be supported.

NOTE: Void.

– Signature algorithm: RSAEncryption and ecdsa shall be supported. RSAEncryption is not recommended as it uses PKCS#1v1.5 padding.

– Parameters: For ecdsa, secp256r1 shall be supported, secp384r1 should be supported.

– ECDSA is recommended for newly created CRLs.

– The security level of the public key used to sign the CRL shall be at least the same as the public keys used to sign the revoked certificates.

– For RSA: The key length shall be at least 2048-bit. A key length of at least 4096-bit shall be supported. Key lengths of less than 2048-bit shall not be supported. PKCS#1v1.5 padding and key lengths less than 3072-bits should not be used in certificates that expire after 2030.

– For ECDSA: Except curve25519, ed25519, and W-25519, elliptic curve groups of less than 256 bits shall not be supported. A key length of at least 384-bit shall be supported.

NOTE 1: In practice, certificates often have a long lifetime, for example about ten years. The use of RSA with PKCS#1v1.5 padding and key lengths less than 3072-bits is planned to be prohibited by several organisations no later than 2030.

CRL retrieval with LDAPv3 [5] shall be supported as the primary method. HTTP may be used for checking the revocation status of TLS and NE certificates.

6.1b OCSP profile

OCSP is protocol for obtaining the revocation status of an X.509 certificate. It can be used in addition to or instead of CRL. With OCSP stapling, a OSCP response is transported together with the certificate in the security protocol and can therefore be used also by offline nodes. The following requirements apply:

– Version 1 OCSP according to RFC6960 [47].

– Hash algorithm for use before signing OCSP response: SHA-256 and SHA-384 shall be supported, MD5 MD2, and SHA-1 shall not be supported.

– Signature algorithm: RSAEncryption and ecdsa shall be supported. RSAEncryption is not recommended as it uses PKCS#1v1.5 padding.

– Parameters: For ecdsa, secp256r1 and secp384r1 shall be supported.

– ECDSA is recommended for newly created OCSP servers.

– The security level of the public key used to sign OCSP shall be at least the same as the public keys used to sign the certificates.

– For ECDSA: Except curve25519, ed25519, and W-25519, elliptic curve groups of less than 256 bits shall not be supported. A key length of at least 384-bit shall be supported.

OCSP over HTTP shall be supported as the primary transport mechanism.

6.2 IKE negotiation and profiling

For certificate based establishment of IPsec SAs between NDS/IP elements, the IKE profile in this clause shall be used.

6.2.1 Void

6.2.1b IKEv2 profile

The following requirements on certificate based IKEv2 authentication in addition to those specified in NDS/IP [1] shall be applied:

For the IKE_INIT_SA and IKE_AUTH exchanges:

– Following algorithms shall be supported:

– Authentication: Method 1 – RSA Digital Signature [42];

– Implementations shall support signatures that use SHA-256, should support signatures that use SHA-384, and shall not support signatures that use SHA-1. Implementations should use SHA-256 as the default hash function when generating signatures.

– Usage of Method 1 is not recommended as it uses PKCS#1v1.5 padding.

– Hash Algorithm Notification [43]

– Implementations shall support SHA2-256, should support SHA2-384, and shall not support SHA1.

– Authentication: Method 14 – Digital Signature [43].

– Implementations shall support ecdsa-with-sha256 and should support ecdsa-with-sha384, and should support RSASSA-PSS with SHA-256. Implementations shall not support sha1WithRSAEncryption, dsa-with-sha1, ecdsa-with-sha1, RSASSA-PSS with Empty Parameters, and RSASSA-PSS with Default Parameters.

– The identity of the CERT payload (including the end entity certificate) shall be used for policy checks;

– Initiating/responding end entities are required to send certificate requests in the IKE_INIT_SA exchange for the responder and in the IKE_AUTH exchange for the initiator;

– Cross-certificates shall not be sent by the peer end entity as they are pre-configured in the end entity;

– The certificates in the certificate payload shall be encoded as type 4 (X.509 Certificate – Signature);

– An end entity shall rekey the IKE SA when any used end entity certificate expires.

NOTE 2: Depending on the availability of DNS between peer end entities, the following rule is applied:

– subjectAltName and IKEv2 policy should both contain IP address (in case DNS is not available);

– subjectAltName and IKEv2 policy should both contain FQDN (in case DNS is available).

6.2.2 Potential interoperability issues

Some PKI-capable VPN gateways do not support fragmentation of IKE packets, which becomes an issue when more than one certificate is sent in the certificate payloads, forcing IKE packet fragmentation. This means that direct cross-certification or manually importing the peer CA certificate to the local SEG and trusting it is preferable to bridge CA systems. When IKE is run over pure IPv6 the typical MTU sizes do not increase and long packets still have to be fragmented (allowed for end UDP hosts even for IPv6, see Path MTU Discovery for IPv6 – RFC 8201 [48), so this is a potential interoperability issue.

Certificate encoding with PKCS#7 is supported by some PKI-capable VPN gateways, but it shall not be used.

6.2a TLS profiling

For 3GPP uses of TLS for inter-operator security, the TLS profile in this clause shall be used.

6.2a.1 TLS profile

The following requirements are mandatory:

– The TLS server shall always send its own end entity certificate in the ServerCertificate message;

– The TLS client shall send its own end entity certificate in the Certificate message if requested by the TLS server;

– Cross-certificates shall not be sent by the TLS entities in the TLS handshake as they are available locally to the TLS entities.

6.2a.2 Potential interoperability issues

No general interoperability issues are identified.

6.3 Path validation

6.3.1 Path validation profiling

– Validity of certificates received from the peer end entity shall be verified by CRLs or OCSP responses retrieved via the mechanisms specified in section 6.1.1, based on the CRL Distribution Point or Authority Information Access extensions in the certificates.

– Validity of certificates received from the TLS entity shall be verified by CRLs or OCSP responses retrieved via the mechanisms specified in section 6.1.1, based on the CRL Distribution Point or Authority Information Access extensions in the certificates.

– Any NE, SEG or TLS entity shall not validate received certificates from a peer entity whose validity time has expired, but end the path validation with a negative result.

– Any NE, SEG shall not validate received certificates from a peer entity whose CRL distribution point field is empty, but end the path validation with a negative result.

– Certificate validity calculation results shall not be cached in a SEGs or NEs for longer than the lifetime enforced by the end entity.

– Certificate validity calculation results shall not be cached in TLS entities for longer than the TLS connection lifetime.