Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 33.310  Word version:  17.2.0

Top   Top   Up   Prev   Next
0…   5…   5.2…   6…   7…   8   9…   B…   C…

 

6  ProfilingWord‑p. 22

6.1  Certificate profilesWord‑p. 22

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 RFC 5280. In case of conflicting requirements, the requirements in this specification override and obsolete the requirements in RFC 5280. 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.
Up

6.1.1  Common rules to all certificatesWord‑p. 23

  • Version 3 certificate according to RFC 5280.
  • 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.
  • 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.
    • 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.
        or
      • 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 RFC 5280 are optional for implementation. If present, such optional extensions shall be marked as "non critical".
Up

6.1.2  Interconnection CA Certificate profileWord‑p. 23

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 profileWord‑p. 24

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 RFC 4945, 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;
  • subjectAltName should contain IP address (in case DNS is not available);
  • subjectAltName should contain FQDN (in case DNS is available).
Up

6.1.3a  TLS entity certificate profile |R7|Word‑p. 24

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 and RFC 5924 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 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.
Up

6.1.3b  NE Certificate profile |R8|Word‑p. 25

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 clause 6.1.3 apply.

6.1.3c  SBA Certificate profile |R16|Word‑p. 25

6.1.3c.1  IntroductionWord‑p. 25

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, 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 SEPP CA(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 (SeCoP) needed for 3GPP 5GC SBA Indirect Communication model architectural Options C and D.
Up

6.1.3c.2  General SBA Certificate profileWord‑p. 25

The following additions and deviations to the common profiles shall hold for all SBA-related entities (NFs, SECOPs, 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 profileWord‑p. 25

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:
NF TLS Client and Server Certificate Profile
Versionv3
Serial NumberUnique 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 Period3 years or less
SignatureSee clause 6.1.1 for the list of supported signature algorithms.
Subject Public Key InfoSee clause 6.1.1 for the list of supported public key types.
Extensions OID Mandatory Criticality Value
keyUsage{id-ce 15}TRUETRUEdigitalSignature 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}TRUEFALSEid-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}TRUEFALSE 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}FALSEFALSE 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}TRUEFALSE 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}TRUETRUEMultiple subjectAltName entries can be used as a sequence, see below for the detailed instructions.
authorityInfoAccess{id-pe 1}FALSEFALSE 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.
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}FALSEFALSE 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 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.
  • 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 URI-IDs with the HTTPS URI(s) for the apiRoot of a Network Function consumer instance for the NF service callback URI(s) that it provides; using wildcard URIs should be avoided;
  • 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.
  • 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.
  • subjectAltName shall not contain only IP address in TLS server certificates;
Up

6.1.4  SEG CA certificate profileWord‑p. 27

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

6.1.4a  TLS client/server CA certificate profile |R7|Word‑p. 28

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

6.1.4b  NE CA certificate profile |R8|Word‑p. 28

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

6.1a  CRL profile |R9|Word‑p. 28

  • Version 2 CRL according to RFC 5280.
  • 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.
  • 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.
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.
Up

6.1b  OCSP profile |R17|Word‑p. 29

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 RFC 6960.
  • 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 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.
OCSP over HTTP shall be supported as the primary transport mechanism.
Up

6.2  IKE negotiation and profilingWord‑p. 29

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

6.2.1Void

6.2.1b  IKEv2 profile |R8|Word‑p. 29

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

6.2.2  Potential interoperability issuesWord‑p. 30

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

6.2a  TLS profiling |R7|Word‑p. 30

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

6.2a.1  TLS profileWord‑p. 30

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 issuesWord‑p. 30

No general interoperability issues are identified.

6.3  Path validationWord‑p. 31

6.3.1  Path validation profilingWord‑p. 31

  • Validity of certificates received from the peer end entity shall be verified by CRLs or OCSP responses retrieved via the mechanisms specified in clause 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 clause 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.
Up

Up   Top   ToC