4 Overview of MCPTT security

33.1793GPPRelease 13Security of Mission Critical Push To Talk (MCPTT) over LTETS

4.1 General

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

– Protection of the signalling plane used by the MCPTT Service, defined in clause 6.

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

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

– Authentication and authorisation of users to the MCPTT Service, defined in clause 5.

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

– Security of floor control within the MCPTT Service, defined in clause 7.

– End-to-end security of user media within the MCPTT Service, also defined in clause 7.

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

4.2 Signalling plane security architecture

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

Figure 4.2-1: Signalling plane security architecture

MCPTT signalling from the UE is passed over both HTTP and SIP. The signalling plane security mechanisms for UE to Server interfaces are defined in clause 6. Additionally, MCPTT data is passed between MCPTT network elements, either inter or intra MCPTT domain. The security mechanism for protecting data between MCPTT network elements is defined in clause 8.

4.3 Application plane security architecture

4.3.1 General

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

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

Media security allow protection of MCPTT media within the MCPTT system. It is applied end-to-end between MCPTT clients. It is a configuration option whether MCPTT network entities, including the MCPTT Server is able to access the content of MCPTT media.

Additionally, signalling plane protection is applied to all HTTP and SIP connections into the MCPTT 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 MCPTT domain, the MCPTT user application requires a ‘token’ authorising its access to MCPTT services. To obtain authorisation token(s), the MCPTT user application authenticates the MCPTT user to an Identity Management Server which provides the authorisation token.

The authorisation token is provided to MCPTT network entities, such as the MCPTT Server, over an MCPTT signalling interface (either a HTTP interface or SIP interface). The MCPTT network entity will provide access to MCPTT 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 not shown in Figure 4.3.2-1, authorisation occurs over HTTP or SIP and hence uses signalling plane protection to encrypt HTTP to a HTTP proxy and to encrypt SIP to a SIP core.

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

4.3.3 Identity keying of users and services

Once a MCPTT client has obtained user authorisation to access the MCPTT 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 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 MCPTT domain are removed from the system.

Figure 4.3.3-1: Identity keying of MCPTT entities

While not shown in Figure 4.3.3-1, the connection to the KMS is over HTTP and hence is secured up to the HTTP proxy. Additionally, key material may be wrapped using a transport key distributed out-of-band.

A number of MCPTT network entities also require identity key material including the MCPTT 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 7.2.

4.3.4 Protection of application plane signalling

Application plane signalling security protects application signalling between the MCPTT user application and the MCPTT server. Key distribution for application signalling is performed by sending a key material from the MCPTT client to the MCPTT Server over the SIP interface. The key is secured using the identity key material provisioned by the Key Management Server. The security architecture is shown in Figure 4.3.4-1.

The mechanism to provide application plane signalling is defined in clause 9.

Figure 4.3.4-1: Application plane signalling security

Application plane signalling security can also be applied between MCPTT servers. In this case the MCPTT 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.5 Media security

4.3.5.1 General

Media security establishes an end-to-end security context between MCPTT users to support group communications and private calls. The intention is for media to be able to be encrypted end-to-end between MCPTT 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 connection.

Key distribution for groups is performed by the Group Management Server. Key distribution for private calls is performed by the initiating MCPTT client. Once a security context is established, the method for encrypting media for groups and private calls is the same. Aditionally, when MCPTT UEs are offline, the security context that is used to protect media security is also used to protect floor control signalling.

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 sends a 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 individual MCPTT users that are members of the group. The Group Management Server may choose to distribute the group key to MCPTT Server(s) to allow the media mixing function within the MCPTT Server(s) to be used. MCPTT users and MCPTT services 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 7.3.

Figure 4.3.5.2-1: Group keying for media security

Once a group key has been shared with MCPTT users, keys are derived from that group key to protect media (and floor control when the UE is offline). Key derivation is based on the MCPTT users’ identity, hence every member of the group encrypts media using a different key.

Media is encrypted using the SRTP protocol. When the MCPTT UE has a network connection the encrypted media is routed to other MCPTT clients via the media distribution function in the MCPTT Server. Media may be distributed over unicast (MCPTT-7) or multicast (MCPTT-8). When the MCPTT UE is offline, the encrypted media is routed directly to MCPTT clients on other MCPTT UEs. The security procedure for protecting media is the same in either case. Details of media encryption is provided in clause 7.5.

Floor control is encrypted using the SRTCP protocol. Unlike media, floor control is protected differently when the UE has a network connection and when it is offline. When the UE has a network connection, floor control traffic is encrypted to the floor control server within the MCPTT Server. When it is offline, floor control is encrypted directly to group UEs using a key derived from the group security context. Details of floor control encryption is provided in clause 7.6. Media control is protected in the same way as floor control.

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 setting up a private call, the call initiator provides a key to the terminating client. The key is encrypted to the MCPTT user that is currently registered on the terminating client. As a result, MCPTT users require identity keying by a KMS prior to performing group management.

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, MCPTT network entities will not have the private call key material and hence will not be 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 7.4.

Once private call key distribution has been completed, media, floor control and media control is protected as described for group communications in clause 4.3.5.2. Media will be routed via the media distribution function in the MCPTT Server when the UE is online, and directly when the UE is offline. The media security context shall also be used to protect floor and media control when the MCPTT UE is offline. Details of media and floor control protection may be found in clauses 7.5 and 7.6 respectively.