4 Overview of Mission Critical Security

33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS

4.1 General

The mission critical security architecture defined in this document is designed to meet the security requirements defined in Annex A. The security architecture provides signalling and application plane security mechanisms to protect metadata and communications used as part of the MC service. The following signalling plane security mechanisms are used by the MC service:

– Protection of the signalling plane used by the MC Service, defined in clause 6.1 and 6.2.

– Protection of inter/intra domain interfaces, defined in clause 6.3.

The following application plane security mechanisms are used by the MC service:

– Authentication and authorisation of users to the MC Service, defined in clause 5.1.

– Protection of sensitive application signalling within the MC Service, defined in clause 9.

– Security of RTCP (e.g. floor control, transmission control) within the MC Service, defined in clause 9.

– Security of data signalling within the MCData Service, defined in clause 8.

– End-to-end security of user media within the MC Service. Defined in clause 7 for MCPTT and MCVideo services and defined in clause 8 for the MCData service.

Security mechanisms in the signalling and application plane are independent of each other, but may both be required for a secure MC system.

4.2 Signalling plane security architecture

Within a MC system, signalling plane security protects the interfaces used by the MC application. Figure 4.2-1 provides an overview of these interfaces.

Figure 4.2-1: Signalling plane security architecture

Signalling from the MC client is passed over both HTTP and SIP. The signalling plane security mechanisms for client to server interfaces and between network elements are defined in clause 6.

4.3 MC system security architecture

4.3.1 General

The MC system security architecture provides protection both between MC clients, between the MC client and the MC domain, and also between MC domains. MC system security on the client is bound to the MC user associated with the client and not to the MC UE. Consequently, user authentication and authorisation to the MC domain is required prior to access to the majority of MC services.

Application plane signalling security allows protection of MC-specific signalling from all entities outside of the MC system (potentially including the SIP core). Application plane signalling security is applied from the MC client to the client’s primary MC domain. It may also be applied between MC domains.

Media security allows protection of MC media within the MC system. It is applied end-to-end between MC clients or in some cases from the MC client to the MCX server (e.g. One-to-server video push or one-from-server video pull). Under normal operation however, MC network entities such as the MCX Servers are typically unable to decrypt the media.

Additionally, signalling plane protection is applied to all HTTP and SIP connections into the MC domain. While signalling plane protection and signalling plane entities are not shown in this subclause, including the SIP core and HTTP proxy, it is assumed that signalling plane protection mechanisms are in use.

4.3.2 User authentication and authorisation

Prior to connecting to the MC domain, the MCX user application requires a ‘token’ authorising its access to MC services. To obtain authorisation token(s), the MCX user application authenticates the MC user to an Identity Management Server which provides the authorisation token.

The authorisation token is provided to MCX network entities, such as the MCX Server, over an MCX signalling interface (either a HTTP interface or SIP interface). The MCX network entity will provide access to MCX services based upon the token provided.

The architecture for user authentication and authorisation is shown in Figure 4.3.2-1.

Figure 4.3.2-1: User authentication and authorisation

While the HTTP proxy and SIP core is not shown in Figure 4.3.2-1, authorisation occurs over HTTP or SIP and hence uses signalling plane protection to encrypt authorisation requests carried over HTTP to a HTTP proxy and authorisation requests carried in SIP messages through the SIP core to the MCX domain.

The mechanism to perform user authentication and authorisation is defined in clause 5.1.

4.3.3 Identity keying of users and services

Once a MC client has obtained user authorisation to access the MCX domain, the client may obtain key material associated with the user’s identity using the authorisation token. Identity keys are required to support key distribution for application signalling, floor control, transmission control and media. Identity key material is obtained via an HTTP request to a Key Management Server as shown in Figure 4.3.3-1.

Identitiy keying is repeated periodically (e.g. monthly). This ensures that user identities are regularly verified and that users that are no longer part of the MCX domain are removed from the system.

Figure 4.3.3-1: Identity keying of MC entities

While not shown in Figure 4.3.3-1, the UE connection to the KMS is over HTTP and hence is secured using TLS directly between the MC client and KMS or between the MC client and the HTTP proxy or directly to the KMS. When the HTTP proxy is in the path between the MC client and the KMS, key material is wrapped using a transport key (TrK) distributed out-of-band (reference clause 5.3.2). The TrK or a shared Integrity key (InK) may be used to sign the key material.

A number of MC network entities also require identity key material including the MCX Server and Group Management Server. This key material is obtained via the same HTTP interface.

The mechanism to perform identity keying is defined in clause 5.3.

4.3.4 Protection of application plane signalling

4.3.4.1 Application plane signalling security

Application plane signalling security protects application signalling between the MC client and the MCX server. Initial key distribution for application signalling is performed by sending a client-server key (CSK) from the MC client to the MCX Server over the SIP interface. The key is secured using the identity key material provisioned by the Key Management Server. Following initial key distribution, the MCX server may perform a ‘key download’ procedure to update key material, and to key the client to allow multicast signalling to be protected.

There are a variety of types of application plane signalling, including:

– XML signalling within SIP payloads

– Control signalling (e.g. RTCP for floor control or transmission control).

– MCData signalling payloads within SIP payloads.

In each case, the same root key material is used to protect the signalling when the signalling is unicast on the uplink or downlink. Should the signalling be multicast on the downlink, the MCX Server will distribute key material for this purpose and use this key material to protect multicast signalling.

The security architecture is shown in Figure 4.3.4.1-1.

The mechanisms to provide application plane signalling security are defined in clause 9.

Figure 4.3.4.1-1: Application plane signalling security

Application plane signalling security can also be applied between MCX servers. In this case the MCX servers are keyed manually. While not shown in Figure 4.3.4-1, application plane signalling uses SIP and HTTP and hence is also secured up to the SIP core and HTTP proxy respectively.

4.3.4.2 Security enforcement at the network edge

Clause 4.3.4.1 describes the application plane signalling security functions between the MC client and MCX Servers and between MCX Servers. These security functions can be enforced by the MCX Servers themselves as described in Clause 4.3.4.1.

However, in some scenarios, there may be value in applying application plane signalling security at the edge of the MC Domain. This deployment option involves moving security functions out of the MCX Servers and into Signalling Proxies at the edge of the MC Domain as shown in Figure 4.3.4.2-1.

Figure 4.3.4.2-1: Signalling Proxies

There are two types of Signalling Proxy:

– Client Signalling proxy (CS Proxy), which controls security towards the MC clients.

– Interconnection Signalling Proxy (IS Proxy), which controls security towards other MC Domains.

Full details of both types of Signalling Proxy are provided in Annex I. The use of signalling proxies has the following advantages:

– The mission critical core network architecture is not exposed to Mission Critical clients or other external entitites. The client no longer needs to know the SIP URI of each distinct MCX Server.

– Intrusion detection within the XML signalling link is possible at the network edge.

– Policies can be assigned to signalling on entry to the Mission Critical network.

– The number of signalling protection keys required by the client and the MC Domain are reduced.

– Multicast bearers can be shared across multiple MCX Servers.

Effectively, for XML-protected application signalling, the Signalling Proxy is able to perform equivalent functions to a Session Border Controller (as defined in RFC 5853 [24]), or IMS IBCF (as defined in Annex I of 3GPP TS 23.228 [23]).

4.3.5 Media security

4.3.5.1 General

Media security establishes an end-to-end security context between MC users to support group communications and private communications for the MCPTT, MCVideo or MCData services. The intention is for media to be able to be encrypted end-to-end between MC clients, irrespective of whether the media is routed unicast via the media distribution server, multicast via the media distribution server, or transmitted over a direct or IOPS connection.

Key distribution for groups is performed by the Group Management Server. Key distribution for private calls is performed by the initiating MC client. Once a security context is established, the media is protected using the distributed key material. Aditionally, when MC UEs are off-network, the security context that is used to protect media security is also used to protect control signalling (e.g. RTCP).

4.3.5.2 Media security for group communications.

Media security for groups is secured by establishing a shared group security context between group members. Key distribution for the group security context is performed by a Group Management Server. The Group Management Server creates and sends group keys and group security parameters over SIP as part of group management.

Group keys and security parameters are encrypted by the Group Management Server to the identity of the individual MC users that are members of the group.. MC users and MCX servers require identity keying by a KMS prior to performing group management.

Figure 4.3.5.2-1 provides an overview of the group keying process. Details of the process may be found in clause 5.7.

Figure 4.3.5.2-1: Group keying for media security

Once a group key has been shared with MC users, keys are derived from that group key to protect media (and control signalling when the UE is off-network).

For MCPTT and MCVideo (specifically RTP), key derivation is based on the MCPTT or MCVideo user’s identity, hence every member of the group encrypts media using a different key. Media is encrypted using the SRTP protocol in this case. For MCData, the user-specific key derivation is not required. Media is encrypted within a MCData data payload in this case.

When the MC UE has a network connection the encrypted media is routed to other MC clients via the media distribution function in the MCX Server. Media from an MC client is distributed to group members by the MCX Server over either unicast or multicast. When the MC UE is off-network, the encrypted media is routed directly to MC clients on other MC UEs. The security procedure for protecting media is the same in either case. Details of media encryption are provided in clause 7 for MCPTT and MCVideo, and clause 8 for MCData.

Unlike media, control signalling (such as floor control or transmission control) is protected differently when the UE has a network connection and when it is off-network. When the UE has a network connection, control signalling traffic is encrypted to the identity of the MC Domain. When it is off-network, control signalling is encrypted directly to UEs using a key derived from the root key for the group or private communication. Details of control signalling encryption is provided in clause 9.4.

Figure 4.3.5.2-2 provides an overview of how media is protected for group communications.

Figure 4.3.5.2-2: Group media protection

4.3.5.3 Media security for private calls

As part of setting up a private call, the call initiator provides the session key to the terminating client. The key is encrypted to the MC user that is currently registered on the terminating client. As a result, MC users require identity keying by a KMS prior to performing private communications.

Figure 4.3.5.3-1: Media security for private calls

Figure 4.3.5.3-1 provides an overview of media protection for private calls. For clarity, MC network entities do not have access to the private call key material and hence are not able to decrypt the media for the private call communication (unless the monitoring function is specifically authorised for either user).

Details of private call key distribution are provided in clause 5.6, specific MCPTT and MCVideo procedures are described in clause 7 and specific MCData procedures are in clause 8.

Once private call key distribution has been completed, control signalling and application signalling are used to setup and control the media transport of a private communication. Media will be routed via the media distribution function in the MCX Server when the UE is online, and directly when the UE is off-network. Details of media protection are found in clauses 7 and 8, control signalling protection is found in clause 9.4 and application signalling protection is found in clause 9.3.

The media security context shall also be used to protect control signalling (e.g. floor control) when the MC UE is off-network.