S.5 Network Domain Security for IMS

33.2033G Security3GPPAccess security for IP-based servicesTS

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

S.5.1 General

This clause describes security mechanisms for all communication except interfaces 1 and 2 of Figure S.1, including the Home Network, Serving Network, and any 3^rd party network nodes (such as SIP Application Servers). This clause is applicable independent of negotiated IMS access security mechanism.

When providing security between network elements, where at least one is in a 3GPP2 network (this includes both legacy 3GPP2 MMD networks and ones migrating to Common IMS), then the requirements in the rest of clause S.5 or TS 33.210 [5] may be used. Otherwise TS 33.210 [5] shall be used.

NOTE: For migration to Common IMS and scalability purposes, it is recommended that 3GPP2 systems migrate to using NDS/IP for securing inter-domain IMS signalling traffic as specified in TS 33.210 [5].

S.5.2 Inter-domain Domain Security

Referring to Figure S.1, interfaces 4 and 7 provides transport security between different networks for SIP capable nodes. Interface 6 provides security for communications between a SIP Application Server, residing in an external network, and the HSS. There may be other interfaces to nodes outside the Home Network, which are also intended to be covered by this clause. The involved nodes shall be capable of IPsec (cf. RFC 4301 [53)]. Privacy protection shall be applied with cryptographic strength greater than DES. Integrity protection shall be applied. IPsec may be used in either transport mode or tunnel mode; when used in tunnel mode, one or both of the network security domains may use Security Gateways. Security associations between nodes in different networks shall be negotiated using IPsec/IKE(cf. RFC 4301 53 [)].

It is necessary that nodes outside the home network should be secure and trustworthy, perhaps using mechanisms such as firewalls, packet filters, and so on. However such details are outside the scope of this clause.

S.5.3 Intra-domain Domain Security

The interface labeled 5 in Figure S.1 is between SIP-capable nodes in the same network security domain. The interface labeled 3 in Figure S.1 is between the I-CSCF/S-CSCF and the HSS. There may be other interfaces to nodes inside the Home Network, which are also intended to be covered by this clause. As these interfaces exist entirely within one network security domain, the administrative authority may choose any mechanism to secure this interface, including physical security where appropriate. Cryptographic methods of security, if applied, shall include both privacy and integrity protection, and be at least as strong as the IPsec(RFC 4301 [53], RFC 7296 [82]) profile defined in clause S.5.4).

S.5.4 Profiles of Network Domain Security Methods

S.5.4.1 General

The profiles specified in this clause shall apply to clauses S.5.2 and S.5.3.

S.5.4.2 Support of IPsec ESP

S.5.4.2.1 General

For the interfaces security protection between IMS network elements, this clause specifies the protection using IPsec as specified in RFC 4301 [53]. The key management and distribution architecture is based on the IPsec IKE (RFC 4301 [53], RFC 7296 [82]) protocols. IKEv2 shall follow the 3GPP IKEv2 profile as defined in clause 5.4 of TS 33.210 [5] and clause 6.2.1b of TS 33.310 [24].

The security services provided by network domain security are:

– data integrity;

– data origin authentication;

– anti-replay protection;

– confidentiality (optional);

– limited protection against traffic flow analysis when confidentiality is applied.

The IPsec security protocol shall always be ESP. Integrity protection/message authentication together with anti-replay protection shall always be used. IPsec ESP should be used with both encryption and integrity protection for all SIP signaling traversing inter-security domain boundaries.

IPsec offers a set of security services, which is determined by the negotiated IPsec security associations. That is, the IPsec SA defines which security protocol to be used, the mode, and the endpoints of the SA.

S.5.4.2.2 Support of ESP authentication and encryption

For IMS signaling traffic, ESP shall always be used to provide data integrity, data origin authentication, and anti-replay protection services, thus the ESP_NULL authentication algorithm shall not be allowed for use. ESP shall follow the 3GPP ESP profile as defined in clause 5.3 of TS 33.210 [5].

S.5.4.3 Support of TLS

This section specifies the use of TLS, for transport protection between IMS network elements. Where TLS is used for transport protection, implementations shall support TLS according to the TLS profile specified in TS 33.310 [24], Annex E. Implementations shall support mutual, certificate-based authentication, and may support (and attempt to negotiate the use of) other authentication methods such as pre-shared secret keys (PSK). The security services provided by network domain security are:

– data integrity;

– data origin authentication;

– anti-replay protection;

TLS provides transport-layer security over connection-oriented protocols (for the purposes of the present document, TCP); "tls" (signifying TLS over TCP) can be specified as the desired transport protocol within a “Via” header field value or a SIP-URI. TLS is most suited to architectures in which hop-by-hop security is required between hosts with no pre-existing trust association.

Implementations shall firstly prefer AES cipher suites, and secondly prefer ephemeral Diffie-Hellman cipher suites during TLS negotiation. Mutual authentication shall be required for all TLS connections.

Annex T (normative):
GPRS-IMS-Bundled Authentication (GIBA) for Gm interface