Generic Security Domain Framework

With 3GPP Release 5, the need for confidentiality, integrity, authentication and anti-replay protection for control plane traffic on core network interfaces was identified. Therefore, a general framework for security of Internet Protocol (IP)-based protocols used in 3GPP and fixed broadband networks was introduced. This framework is specified in [TS33.210], and is known under the acronym NDS/IP as abbreviation of ‘Network Domain Security for IP-based protocols’. Besides describing the network architecture and security mechanisms to be used for protection of IP traffic between different security domains and between single network entities within one security domain, it also contains a basic framework for cryptographic key management that mandates support for pre-shared keys only. Later in Release 6 this specification was augmented with a separate specification on Public Key Infrastructure (PKI) support in [TS33.310]. This specification is often referred to as NDS/AF for ‘Network Domain Security/Authentication Framework’.

In order to be compliant with the NDS/IP framework, a network needs to apply it for control plane traffic only, while user plane traffic is not covered by NDS/IP in general.

Still the framework may also be applied to user plane traffic, either based on decision of the operator, or even mandatorily if required by other 3GPP specifications. One example is the security of user plane data for the evolved NodeB (eNB) backhaul link as required by [TS33.401] – see Chapter 8.

NDS Architecture

A basic concept for NDS is the notion of a security domain, which is defined as being a part of or a complete network administrated by a single authority, and typically providing the same level of security and the same type of security services to all elements and connections contained within this domain. A security domain is normally confined to a single operator, while any operator is free to subdivide their network into separate security domains. Different security domains are connected by secure channels, which terminate in Security Gateways (SEGs) at the borders of these security domains. The reference point for these secure channels between security domains is called Za.

The above requirement implicitly disallows any direct connection between network ele-ments (NEs) located in different security domains. But the specification does not prevent an NE and the related SEG to be co-located. The only restriction here is that such a co-located SEG should only act on behalf of this one NE, and not as a general SEG at the border of a security domain.

Insecure Network

Security Domain B Security Domain A

SEG_A SEG_B

NE_A−1

NE_A−2

Za

Zb Zb

Zb Zb

Zb

Zb NE_B−1

NE_B−2

Figure 4.6 NDS/IP architecture.

Additionally, it is often assumed implicitly that the connections between the NEs within one security domain are secure, and thus do not need any explicit security measures in the NDS/IP framework. This assumption is not always fulfilled, so NDS/IP provides also security mechanisms for intra-domain connections using the reference point Zb. As SEGs are not required within security domains, the Zb reference point may be used between NEs and SEGs, but also directly between two different NEs of the same security domain.

Anyway, NDS/IP is clear on the fact that the application of cryptographic security to intra-domain connections is up to operator policy and thus also the implementation of the Zb interface in NEs is optional.

Figure 4.6 shows the basic architecture of NDS/IP with the Za and Zb reference points.

It can be clearly seen that the underlying security model of this architecture is ‘hop-by-hop’ security in a tunnel/hub-and-spoke model, where each pair of SEGs and their tunnel in between act as hub and the connections to other NEs constitute the spokes.

Security Services Provided by NDS/IP

The following security services are provided by NDS/IP:

• data integrity;

• data origin authentication;

• anti-replay protection;

• confidentiality and

• limited protection against traffic flow analysis (only when confidentiality is applied).

Note that confidentiality protection is optional. When confidentiality protection is used, there is also limited protection against traffic flow analysis when tunnel mode (see Section 4.5.2) is used. Then only the IP addresses of the SEGs are visible, and the internal traffic sources and destinations within the security domains are hidden.

Third-Generation Security (UMTS) 61

Security Gateways (SEGs)

The SEGs have a twofold task, as they terminate the secure connections over the Za reference point, and act as policy enforcement point for the security policies bound to the security domain. The mechanisms for the secure connection are detailed in the NDS/IP and NDS/AF specifications and described further in this chapter, while the policies are out of scope of standardization. Such policies depend a lot on the type of Za interface, be it intra-operator or inter-operator, and, in the latter case, on the agreements between different operators. Mechanisms deployed for the enforcement of such policies may be simple packet filters or more complex firewall rules, but also sophisticated content-related inspections, relating to network signalling or even application-level content.

IKE and IPsec Profiles

As the Internet Key Exchange (IKE) and the IP Security Protocol (IPsec) are used through-out different 3GPP security specifications, and in order to avoid specifying all profiling details separately in each specification, the NDS specifications were seen as best place to specify common IKE and IPsec profiles, used within and outside NDS. Other 3GPP specifications, for example in scope of this book [TS33.234], [TS33.401] and [TS33.402], reference these common profiles. Thus in case the IETF protocols are updated, or the algo-rithm profiles are adjusted to new security requirements, then only the NDS specifications have to be corrected.

[TS33.210] gives the profile for IPsec and the basic profile for IKE. [TS33.310] adds profiling for IKEv2 used in conjunction with certificates.

Certificate Profiles

If a PKI infrastructure is used for authentication, the format and content of the certificates has to be standardized. In the realm of NDS/AF, only X.509 certificates [ITU X.509]

are used with the particular profiling in [RFC5280]. Clause 6 of NDS/AF [TS33.310]

further profiles these certificates for usage in 3GPP NDS/AF. This profiling reduces the variants to be implemented and thus helps to keep 3GPP-conformant implementations simple, while still fully functional, for 3GPP network purposes.

In addition to providing the certificate profiles for all NDS use cases, [TS33.310] is also used for specifying common certificate profiles referenced by other 3GPP specifications.

TLS Protocol and Certificate Profiles

While NDS/IP only specifies the usage of IKE and IPsec (see Section 4.5.2), the specification on NDS/AF [TS33.310] extends the definition of certificate profiles and interconnection/cross-signing infrastructure to entities using Transport Layer Security (TLS). Connections secured by TLS are not handled in NDS/IP [TS33.210], therefore no SEGs are defined for TLS usage either. As there is no restriction on TLS client and server location, the roles of client and server are only defined by the fact of who initiates the TLS handshake. Thus this TLS certificate usage applies to both connections between entities within the same security domain and in different security domains.

Even if TLS is not specified to be used in basic NDS, Annex E of [TS33.310] gives a TLS profile which is a blueprint for all TLS usage within 3GPP. This annex contains provisions about the mandatory to support TLS versions and cipher suites, and some other 3GPP specific profiling of TLS.

TLS is not specifically used in EPS procedures; but, for example the security specifi-cation for IMS [TS33.203] allows the usage of TLS between IMS CSCF (Call Session Control Function) elements and other SIP proxies. For details on IMS the reader is referred to Chapter 12. Other nonstandardized deployments of TLS are commonly found for securing O&M connections.