Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑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… 
6.1a CRL profile  6.1b OCSP profile  6.2 IKE negotiation and profiling  6.2.1b IKEv2 profile  6.2.2 Potential interoperability issues  6.2a TLS profiling  6.2a.1 TLS profile  6.2a.2 Potential interoperability issues  6.3 Path validation  6.3.1 Path validation profiling 
...

 

6.1a  CRL profile |R9|  p. 31

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

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

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

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 issues  p. 33

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

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

6.2a.1  TLS profile  p. 33

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

No general interoperability issues are identified.

6.3  Path validation  p. 34

6.3.1  Path validation profiling  p. 34

  • 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