Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.310  Word version:  19.1.0

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

 

5.2.4  SEG/TLS CA registrationp. 21

In principle only one SEG CA, one TLS client CA and one TLS server CA shall be used within the operator's network, but using more than one of each of these CAs is possible. The involved actions are those as described in the cross-certification part of clause 5.2.1: 'Operator Registration: creation of interconnect agreement'. Such a situation of having multiple CAs of each type may exist if the CA functions are to be moved from one responsible organisation to another (e.g. outsourcing of CA services).
Up

5.2.5  SEG/TLS CA deregistrationp. 21

If a SEG CA or TLS CA is removed from the network, it shall be assured that the SEG CA or TLS CA certificates and all certificates that have been issued by the SEG CA or TLS CA to SEGs or TLS entities, and have not expired yet, shall be listed in CRLs or OCSP servers. The cross-certificates that are issued to these SEG CAs or TLS CAs, and have not expired yet, should also be listed in CRLs and OCSP servers.

5.2.6  SEG/TLS CA certificate creationp. 21

The involved actions are those as described in the cross-certification part of clause 5.2.1: 'Operator Registration: creation of interconnect agreement'.
The SEG CA or TLS CA certificate does not have to be the top-level CA of the operator, which means that the SEG CA or TLS CA certificate is not self-signed. One option is to sign the operator's SEG CA and TLS CAs with the operator's own Interconnection CA, as this will already be a trust point established in the operator's own SEGs and TLS entities. If the SEG CA or TLS CA certificates are self-signed then they should be securely transferred to each of the operator's SEGs and TLS entities and stored within secure memory (see NOTE to clause 7.5).
Up

5.2.7  SEG/TLS CA certificate revocationp. 21

This compromise is a serious event as it will require all the cross-certificates issued by other operators' Interconnection CAs to that SEG CA or TLS CA to be revoked.
Existing secure connections need not be torn down, unless they were formed very recently i.e. after the time at which the operator suspects the CA key became compromised, but before the cross-certificate used to establish the tunnel was revoked.
It shall be assured that the SEG CA or TLS CA certificates and all certificates that have been issued by the SEG CA or TLS CA to SEGs or TLS entities, and have not expired yet, shall be listed in CRLs or OCSP servers. The cross-certificates that are issued to these SEG CAs or TLS CAs, and have not expired yet, should also be listed in CRLs or OCSP servers.
To restore inter-domain interoperability, the operator has to create a new SEG CA or TLS CA key pair and use it to issue certificates to all the SEGs and TLS entities in the operator's own domain. The operator shall then provide a cross-certification request (see clause 5.2.1) for the new SEG CA or TLS CA key pair to the operators with whom it has interconnect agreements.
It is recommended that operators carefully protect their SEG CA and TLS CA keys to limit this knock-on effect across the operator community.
Up

5.2.8  SEG/TLS CA certificate renewalp. 22

The SEG CA and TLS CA certificate has to be renewed before the old SEG CA and TLS CA certificate expires. The renewing of a SEG CA or TLS CA certificate involves repeating the actions as described in the cross-certification part of clause 5.2.1: 'Operator Registration: creation of interconnect agreement'. This should be done before the old certificate expires.

5.2.9  End entity registrationp. 22

5.2.9.1  SEG registration |R7|p. 22

If not already done, a SEG certificate has to be created (see clause 5.2.11 for a description on certificate creation).
If a SEG is added to the network, the policy database of this SEG has to be configured using device-specific management methods.
Other operators have to be informed of the new SEG: The SEG policy databases of SEGs in other networks may have to be adapted.

5.2.9.2  TLS client registration |R7|p. 22

If not already done, a TLS client certificate has to be created (see clause 5.2.11 for a description on certificate creation).
If a TLS client is added to the network, then some local configuration may be needed to take the new TLS client into use for secure inter-operator communication. In addition, other operators may need to be informed of the new TLS client.

5.2.9.3  TLS server registration |R7|p. 22

If not already done, a TLS server certificate has to be created (see clause 5.2.11 for a description on certificate creation).
If a TLS server is added to the network, then some local configuration may be needed to take the new TLS server into use for secure inter-operator communication. In addition, other operators may need to be informed of the new TLS server.

5.2.9.4  NE registration |R8|p. 22

If not already done, an NE certificate has to be created (see clause 5.2.11 for a description on certificate creation).
If an NE is added to the network, the policy database of this NE has to be configured using device-specific management methods.

5.2.10  End entity deregistrationp. 22

5.2.10.1  SEG deregistration |R7|p. 22

If a SEG is removed from the network, the SAs shall be removed using device-specific management methods. The operator of the SEG shall have the certificate of the SEG listed in his CRL or OCSP server. The SPD of the partner network may have to be adapted.

5.2.10.2  TLS client deregistration |R7|p. 22

If a TLS client is removed from the network, the TLS connections shall be terminated using device-specific management methods. The operator of the TLS client shall have the certificate of the TLS client listed in his CRL or OCSP server.

5.2.10.3  TLS server deregistration |R7|p. 23

If a TLS server is removed from the network, the TLS connections shall be terminated using device-specific management methods. The operator of the TLS server shall have the certificate of the TLS server listed in his CRL or OCSP server.

5.2.10.4  NE deregistration |R8|p. 23

If a NE is removed from the network, the SAs shall be removed using device-specific management methods. The operator of the NE shall have the certificate of the NE listed in his CRL or OCSP server.

5.2.11  End entity certificate creationp. 23

Using device-specific management methods, the certificate creation shall be initiated. As specified in clause 7.2, either the CMPv2 protocol for automatic certificate enrolment or manual certificate installation using PKCS#10 formats can be used. This is an operator decision depending for example on the number of NEs or SEGs and TLS entities.

5.2.12  End entity certificate revocationp. 23

If a SEG or TLS entity key pair gets compromised then the existing SAs shall be removed using device-specific management methods. The operator of the SEG or TLS entity shall include the revoked certificate in his CRL or OCSP server.

5.2.13  End entity certificate renewalp. 23

A new NE, SEG or TLS entity certificate needs to be in place before the old certificate expires. The procedure is similar to the certificate creation and can be either fully automated by using CMPv2 as specified in clause 7.2 or done manually using PKCS#10 formats. This is an operator decision depending for example on the number of NEs, SEGs and TLS entities.

5.2.14  NE CA deregistration |R8|p. 23

If an NE CA is removed from the network, it shall be assured that the NE CA certificate and all certificates that have been issued by the NE CA to the NEs, and have not expired yet, shall be listed in CRLs or OCSP server.

5.2.15  NE CA certification creation |R8|p. 23

The NE CA certificate does not have to be the top-level CA of the operator, which means that the NE CA certificate is not self-signed. If the NE CA certificates are self-signed then they should be securely transferred to each of the operator's NEs and stored within secure memory (see NOTE to clause 7.5).

5.2.16  NE CA certificate revocation |R8|p. 23

This serious event will require that all NE certificates needs to be revoked.
Existing intra-security domain security connections need not be torn down, unless they were formed very recently i.e. after the time at which the operator suspects the NE CA key became compromised but before the certificate has been listed as revoked.
It shall be assured that the NE CA certificate and all certificates that have been issued by the NE CA to NEs, and have not expired yet, shall be listed in CRLs or OCSP server.
To restore intra-domain security, the operator has to create a new NE CA key pair and use it to issue certificates to all the NEs in the operator's own domain.
Up

5.2.17  NE CA certificate renewal |R8|p. 24

The NE CA certificate has to be renewed before the old NE CA certificate expires.

6  Profilingp. 24

6.1  Certificate profilesp. 24

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 certificatesp. 24

  • 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 profilep. 25

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 profilep. 25

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|p. 26

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 shall be set;
    • 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|p. 26

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.

Up   Top   ToC