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.210  Word version:  17.1.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   A… 
6 Other 3GPP profiles  6.1 General  6.2 TLS protocol profiles  6.3 JWE and JWS profiles 

 

6  Other 3GPP profiles |R15|  p. 17

6.1  General  p. 17

The present document also serves as a repository for 3GPP profiles of protocols above the IP layer. These are collected in the present clause.

6.2  TLS protocol profiles  p. 17

6.2.1  General  p. 17

The present clause contains the general 3GPP TLS profile. Other 3GPP specifications 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 TLS should refer to this profile with as few exceptions as possible.
TLS end points shall support TLS with the following restrictions and extensions:
TLS versions
  • SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and DTLS 1.0 shall not be supported.
  • TLS 1.2 as specified in RFC 5246 shall be supported. TLS 1.3 as specified in RFC 8446 shall be supported. If DTLS is supported then DTLS 1.2 as specified in RFC 6347 shall be supported.
Other
  • If the TLS connection is used to transport HTTP over TLS as specified in RFC 2818, then the client shall not establish a connection "upgraded to TLS Within HTTP/1.1" per RFC 2817, but shall only establish the tunnel over a raw TCP connection.
Up

6.2.2  Profiling for TLS 1.3  p. 18

TLS 1.3 shall support the following restrictions and extensions:
TLS cipher suites and Diffie-Hellman groups
  • The requirements given in of Section 9.1 of RFC 8446 TLS 1.3 shall be followed. In addition:
  • Key exchange with secp384r1 should be supported.
TLS signature schemes
  • ecdsa_secp384r1_sha384 should be supported.
TLS extensions
  • The requirements given in of Section 9.2 of RFC 8446 TLS 1.3 shall be followed. In addition:
  • The OCSP Status extension (a.k.a. certificate status request), as defined in RFC 6066 and RFC 8466 should be supported.
Up

6.2.3  Profiling for TLS 1.2  p. 18

TLS 1.2 (RFC 5246) shall support the following restrictions and extensions:
TLS cipher suites
  • The rules on allowed cipher suites given in TLS 1.2 (RFC 5246) shall be followed.
  • In addition, the following cipher suites are mandatory to support and recommended to use:
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
  • Support of the following cipher suites is recommended:
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
  • Only cipher suites with AEAD (e.g. GCM) and PFS (e.g. ECDHE, DHE) shall be supported.
Diffie-Hellman groups
  • For ECDHE, the curve secp256r1 (P-256) as defined in RFC 8422 shall be supported, secp384r1 (P-384) as defined in RFC 8422 should be supported. Except curve25519, ed25519, and W-25519, elliptic curve groups of less than 256 bits shall not be supported.
  • For DHE, Diffie-Hellman groups of at least 4096 bits should be supported. Diffie-Hellman groups smaller than 2048 bits shall not be supported.
TLS hash algorithms and signature algorithms
  • Hash algorithms: SHA-256 shall be supported. SHA-384 should be supported. MD5 and SHA-1 shall not be supported.
  • Signature algorithms: ecdsa, rsa_pss_rsae, and rsa_pkcs1 shall be supported. Usage of rsa_pkcs1 is not recommended.
  • ecdsa_secp384r1_sha384 should be supported.
TLS compression
  • The "null" compression method as specified in TLS 1.2 RFC 5246 is mandatory to support. All other compression methods shall not be supported.
TLS extensions
  • If TLS Extensions are used in conjunction with TLS, then for RFC 6066 shall apply.
  • The Server Name Indication (SNI) extension defined in RFC 6066 shall be supported.
  • The Truncated HMAC extension, defined in RFC 6066 shall not be supported.
  • TLS Session Resumption based on RFC 5246 or RFC 5077 should be supported.
  • TLS servers and TLS clients shall support RFC 5746. The server shall accept client-initiated renegotiation only if secured according to RFC 5746.
  • The Extended Master Secret extension, defined in RFC 7627 shall be supported.
  • Signature Algorithms, defined in RFC 5246 shall be supported.
  • The Supported Groups extension, defined in RFC 8422 and RFC 7919 shall be supported.
  • The OCSP Status (a.k.a. certificate status request) extension, defined in RFC 6066 should be supported.
PSK cipher suites
  • If pre-shared key (psk) cipher suites are implemented in TLS, then RFC 5489 shall apply and the following cipher suites are mandatory to support and recommended to use:
  • TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 as defined in RFC 5487.
  • TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 as defined in RFC 8442.
  • Support of the following cipher suite is recommended:
    • TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 as defined in RFC 8442.
Up

6.3  JWE and JWS profiles  p. 19

6.3.1  General  p. 19

JWS (JSON Web Signature) [46] and JWE (JSON Web Encryption) [47] are used to integrity protect and encrypt JSON objects. The JWE profile and JWS profile describe the restrictions and extensions to the RFCs for 3GPP entities or functions that support JWS and/or JWE.
The cipher suites used in clause 6.2 are described in RFC 7518.
Up

6.3.2  JWE profile  p. 19

All entities and functions that support JWE according to RFC 7516 shall follow the following restrictions and extensions:
  • "enc" parameter A128GCM (AES GCM with a 128-bit key) shall be supported. "enc" parameter A256GCM (AES GCM using 256-bit key) should be supported.
  • "alg" parameter "dir" (Direct use of a shared symmetric key as the CEK) shall be supported.
If ECDH is used as a key agreement protocol, the receiving party shall perform public key validation and check that the received public key is on the agreed upon curve.
Up

6.3.3  JWS profile  p. 20

All entities and functions that support JWS according to RFC 7515 shall follow the following restrictions and extensions:
  • "alg" parameter ES256 (ECDSA using P-256 and SHA-256) shall be supported.
  • The "none" "alg" parameter shall not be supported.
  • The "kid" field shall be supported. End points may establish the expected signing algorithm and associated keys out-of-band (e.g. N32-c) and use this field to pass a key identifier. If the "kid" field is used the end point shall check the indicated "alg" matches that specified by the parameters.
  • If an end point has established a public key and algorithm out of band (e.g. N32-c) and the "kid" field is not used, then the end point shall check the indicated "alg" parameter against the established algorithm
  • The "jwk" field shall not be supported.
Up

7  Void

Up   Top   ToC