11 Interconnection, interworking and migration security
33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS
11.1 Interconnection
11.1.1 Overview
MC Systems may interconnect as described in TS 23.379 [2], TS 23.280 [36] and TS 23.281 [37]. This allows inter-system communications to occur.
To ensure interconnection is secure, MC clients only connect to MC Servers within their own system (unless migrating). When information is required by a MC client from another interconnected system, the information is first transferred from the interconnected partner system to the interconnected primary system via MCX server to MCX server communications followed by the distribution of that information to the MC client. For example, group management information is transferred between Group Management Servers in Clause 10.2.7 of TS 23.280 [36], prior to distribution to MC clients.
MC systems should protect themselves at the system border from external attackers. During interconnection, the MC system should use an HTTP proxy and an MC gateway containing an IS proxy as described in clause 11.1.3 to enforce policies and apply security functions (such as topology hiding). Among the security functions that can be performed at both proxies are preventing any direct MC client connection over this interface. Cross-system authentication of interconnection signalling requests may be implicit or explicit, subject to the policy of each MC system. Where authentication is implicit, the HTTP Proxy and IS Proxy should prevent messages that do not have an external MC service ID in the source of the request. MC servers should enforce policy to limit the information provided to a signalling requests from external MC service IDs.
Where authentication is explicit, the signalling request shall contain an Element for Authenticating Requests, (EAR), as defined in Clause 9.6. It is recommended that an authorised identity should be used within the EAR, to convey the source’s authorisation to make the request.
11.1.2 Security procedures for interconnection
11.1.2.1 General
This clause defines security procedures that are used to support interconnection between MC systems
11.1.2.2 GMK transfer between MC systems
To allow a group to span two, or more, MC Systems, the GMK and GMK-ID needs to be transferred between the GMSs in different MC systems. The procedure follows an equivalent security procedure to that defined in Clause 7.3.3 for group regrouping. In this case, the GMK is transported within a ‘group information notify request’ as defined in Clause 10.2.7.5 of TS 23.280 [36].
Pre-conditions:
– Both the primary and partner GMS have been keyed by their KMS.
The notify group configuration procedure is shown in Figure 11.1.2.2-1.
Figure 11.1.2.2-1: Inter-system GMK transfer
1. The GMS in the primary MC system of the MC service group provides the notification to the GMS in the partner MC system of the MC service group. The primary GMS includes a Group Key Transport payload following the procedures in Clause 5.7, treating the partner GMS as another user within the group. Accordingly, the payload encrypts the GMK to the identity of the partner GMS and is signed using the identity of the primary GMS. The GUK-ID is derived using the User Salt generated from the partner GMS’s URI.
NOTE 1: If the choice of initiator KMS (IDRkmsi) or receiver KMS (IDRkmsr) within the MIKEY message is unacceptable, a KMS Redirect Response may be returned to the primary GMS providing KMS information. In this case, the primary GMS may re-attempt the above procedures.
NOTE 2: In this case, the partner GMS may discard the GUK-ID once the GMK-ID has been extracted.
2. Further signalling occurs as defined in TS 23.280 [36].
Upon receipt of the GMK, the partner GMS shall distribute the GMK and GMK-ID on to group MC clients as described in Clause 5.7.
11.1.3 Interconnection security with MC gateway server
A MC gateway server is part of the mission critical architecture for interconnection as defined in 3GPP TS 23.280 [36]. The MC gateway server includes an IS Proxy for inter-domain security as defined in Annex I. The IS Proxy provides protection of the SIP-3 interface (i.e. SIP payload and RTCP protection using a SPK as defined in clause 9 and clause 6.3.2). The SIP-3 interface is covered as part of the interconnection MCX-1 reference point.
Figure 11.1.3-1 shows an interconnection architecture between two MC domains (MC domain A and MC Domain B) each with the MC gateway server which contains the IS proxy for interconnection security. The MC gateway provides the necessary topology hiding and address translation along with signalling protection via the IS proxy. HTTP communications for interconnection over the HTTP-3 reference point are provided for via the HTTP proxy as described in 3GPP TS 23.280 [36] and protected as defined in clause 6.1.3 of this specification.
Figure 11.1.3-1: Interconnection security using MC gateway with HTTP and IS proxies
In Figure 11.1.3-1, the interface between the MC domains shall be protected hop-by-hop as defined in Clause 6.3.2. The SIP-3 interface between IS Proxies may be protected at the application layer using a shared SPK as defined in Clause 9 and the HTTP-3 interface between HTTP Proxies may be protected using TLS as defined in Clause 6.1.3.For interconnection communications with an MC gateway server (e.g. MC domain A to MC domain B in this example), HTTP and SIP messages are sent by an MC service server or a server in the common services core within the MC domain, towards the MC gateway server or HTTP proxy for processing, protection, and external routing to a partner MC domain.
For HTTP messages, the HTTP proxy applies topology hiding by replacing the internal to/from addresses in the HTTP message with the associated external HTTP routing addresses. The HTTP proxy determines the target HTTP proxy for MC domain B and choses the certificates appropriate for that TLS tunnel. The HTTP message is protected and sent towards MC domain B on the HTTP-3 interface. The HTTP proxy in MC domain B receives the HTTP message where it is decrypted from the external TLS tunnel. The HTTP proxy in MC domain B then replaces any external HTTP routing addresses with internal HTTP addresses applicable to MC domain B and forwards the message to the appropriate server within MC domain B.
For SIP messages, the MC gateway server in MC domain A applies topology hiding by replacing the internal to/from SIP addresses (e.g. Public Service Identities) in the SIP header with the associated external SIP routing addresses and passes the SIP message to the MC gateway IS proxy. The IS proxy removes any internal SIP payload encryption, then based on the target MC domain (MC domain B) selects the appropriate inter-domain SPK to re-encrypt the SIP payload(s). The SIP message is then sent towards the MC gateway server in MC domain B over the SIP-3 interface where the MC gateway IS proxy in MC domain B receives the SIP message and decrypts it using the inter-domain SPK it has in common with MC domain A. The IS proxy in MC domain B may then re-encrypt the SIP payload(s) with an internal MC domain B SPK. The topology hiding function of the MC gateway server in MC domain B then replaces the external SIP routing addresses with internal SIP addresses applicable to MC domain B and forwards the message to the appropriate server within MC domain B.
11.2 Interworking
11.2.1 General
The 3GPP security architecture supports the transfer of interworking signalling and media.
For media sent towards the 3GPP system, the IWF shall apply 3GPP security prior to sending the media to the 3GPP system. This is performed using MC Security Gateway functionality as defined in Annex L.
For media sent from the 3GPP system, the IWF shall remove 3GPP security prior to performing any further processing of the media. This is performed using MC Security Gateway functionality as defined in Annex L.
Interworking media may be end-to-end protected using LMR mechanisms that are out-of-scope of this specification. 3GPP MC application security shall be applied, regardless of whether the LMR security mechanism is used. For further details of LMR end-to-end security mechanisms see Annex K.
When signalling protection is used by the 3GPP MC system, the IWF shall apply the applicable 3GPP signalling protection mechanisms to the signalling packets sent towards the 3GPP system and shall remove the applicable 3GPP signalling protection mechanisms for signalling packets received from the 3GPP system. This is performed using MC Security Gateway functionality as defined in Annex L.
When signalling protection is not used by the 3GPP MC system, the signaling packets sent towards the 3GPP system shall be forwarded by the IWF without signalling protection.
11.2.2 Transport of non-3GPP interworking security data (InterSD)
To support the exchange of end-to-end interworking security data (a.k.a. Key Management Messages) between 3GPP MC UEs and the non-3GPP system when the interworking keys are home to the non-3GPP system, transport of the interworking security data is carried out using an Interworking Security Data (InterSD) message as defined in 23.283 [48]. An InterSD message may be generated by either the IWF or the 3GPP interworking MC UE.
The formatting and content of non-3GPP security data payloads are defined by the non-3GPP system or the non-3GPP layer of the 3GPP interworking MC UE and are out of scope for this document. The InterSD message shall support the transfer of non-3GPP security data payloads regardless of the security data payload content, format, or the architecture of the non-3GPP system beyond the IWF.
Signalling protection may be applied to the InterSD message as defined in clause 9.
An interworking key management record as defined in clause 11.2.3 may be required to enable secure InterSD messaging between a MC UE and a non-3GPP system.
11.2.3 Interworking key management enablement
To support interworking key management with a non-3GPP system (i.e. InterSD messaging), an interworking MC UE may require provisioning of an interworking key management record (InterKMRec) that supports the secure transfer of InterSD messages. Generally speaking, an InterKMRec provides initial key management parameters needed to send, receive, address, protect, or otherwise interpret InterSD messages passed between an interworking 3GPP MC UE and the non-3GPP interworking system (e.g. interworking key management addressing, interworking key management identifiers, interworking key management root keys, or other interworking key management related parameters).
The InterKMRec is provided from the MC KMS to the interworking MC UE during MC user key management authorization.
The format of an InterKMRec is shown in figure 11.2.3-1 and consists of a Primary InterKMRec ID, a Secondary InterKMRec ID, and the InterKMRec Payload.
|
IEI |
Information Element |
Presence |
Format |
Length |
|
Primary InterKMRec ID |
M |
TLV |
varies |
|
|
Secondary InterKMRec ID |
M |
TLV |
varies |
|
|
InterKMRec Payload |
M |
LV-E |
varies |
Figure 11.2.3-1 Interworking key management record (InterKMRec) structure
The Primary InterKMRec ID and Secondary InterKMRec ID are used in combination to identify and manage interworking MC UE clients for a single MC user (i.e. the same MC Service ID such as a MCPTT ID) when that MC user might log onto multiple interworking MC UEs at the same time. The MC service ID of a particular interworking MC user shall be coupled to the Primary InterKMRec ID and the Secondary InterKMRec ID shall be used to distinguish between the multiple MC clients in use by that MC service ID (e.g. the client ID).
For example, when an interworking MC user performs key management authorization, the MC service ID of the user is used to identify the set of InterKMRecs associated to that MC service ID. The KMS selects one of the associated InterKMRecs (assuming at least one record exists) and then further makes a dynamic association between the client ID making the request and the Secondary InterKMRec ID, this way uniquely identifying the interworking MC user and each interworking MC client the MC user is using.
The exact format and contents of the InterKMRec Payload is defined by the non-3GPP system and is out of scope for this document. The method used to provision an InterKMRec into the KMS is out of scope for this document. The method used to associate an MC service ID to a Primary InterKMRec ID and the method used to associate an MC UE client to a Secondary InterKMRec ID is also out of scope for this document.
When an interworking MC user performs key management authorization at the KMS and the access token has been validated, the KMS shall check to see if the MC service ID provided in the access token has an associated InterKMRec. If more than one InterKMRec exists for the MC service ID, the KMS shall check to see if the Secondary InterKMRec ID is also already associated to a specific client for that MC Service ID. If the client cannot be matched, then the KMS shall select one of the InterKMRecs and associate the client ID to the Secondary InterKMRec ID of that InterKMRec. The KMS shall then deliver the selected InterKMRec to the interworking MC UE during MCX user key management authorization as defined in clause 5.1.3.1.
It is out of scope of this document as to when and how the KMS disassociates a client from a particular InterKMRec ID.
When required by the MC system, the InterKMRec shall be transported from the KMS to the interworking MC UE encrypted on the TrK of the interworking MC UE. The InterKMRec may be signed and if so, shall be signed by either the Ink if the InK is present, or signed by the TrK if the InK is not present.
Annex A (normative):
Security requirements
A.1 Introduction
Stage 1 requirements pertaining to MCX security are found in 3GPP TS 22.179 [3] and 3GPP TS 22.280 [47]. Stage 2 Architectural requirements pertaining to MCX security are found in 3GPP TS 23.179 [2], 3GPP TS 23.280 [36], 3GPP TS 23.281 [37], and 3GPP TS 23.282 [38]. The following are MCX derived security requirements:
A.2 Configuration & service access
[33.180 MCX-A.2-001] The MC UE and the network entity providing the MCX configuration data, shall mutually authenticate each other prior to MC UE configuration to use the MCX service.
[33.180 MCX-A.2-002] The MC User and the MCX Service shall mutually authenticate each other prior to providing the MC UE with the MCX Service User profile and access to user-specific services.
[33.180 MCX-A.2-003] The transmission of configuration data and user profile data between an authorized MCX server in the network and the MC UE shall be confidentiality protected, integrity protected and protected from replays.
A.3 Group key management
[33.180 MCX-A.3-001] Group key material shall be integrity and confidentiality protected for a specific MC User during distribution from the MCX service to MC UEs.
[33.180 MCX-A.3-002] Group key material shall be authenticated as coming from a valid, authorized source. The authorized source may be an MC Administrator or may be another authorized entity (e.g. an authorized MCX User or Dispatcher).
[33.180 MCX-A.3-003] It shall be possible for authorized entities to dynamically create and distribute a new group security context at any time. This may be as part of a group creation process, be due to a periodic update to maintain key freshness, or due to compromise of group key material.
[33.180 MCX-A.3-004] The creation of a new group security context (e.g. via User-Regroup operation) shall not change or compromise an existing group security context.
[33.180 MCX-A.3-005] It shall be possible for an authorized, authenticated entity to revoke and update a group security context from use.
A.4 On-network operation
[33.180 MCX-A.4-001] All users of the MCX service shall be authenticated to prevent an adversary impersonating a user for the purpose of denial of service.
[33.180 MCX-A.4-002] The MCX service should take measures to detect and mitigate DoS attacks to minimize the impact on the network and on MC users.
[33.180 MCX-A.4-003] The MC user shall be authenticated by the MCX application.
[33.180 MCX-A.4-004] A mechanism shall exist that allows the MCX application to be authenticated by the MCX user.
[33.180 MCX-A.4-005] The MC UE and MCX service should enforce the result of the authentication for the duration of communications (e.g. by integrity protection or implicit authentication by encryption with a key that is derived from the authentication and is unknown to the adversary).
[33.180 MCX-A.4-006] The security solution should minimize the impact of a compromised MC UE on other MC UEs.
[33.180 MCX-A.4-007] The MCX Service shall provide a means to ensure integrity of all MCX user signalling at the application layer.
[33.180 MCX-A.4-008] The MCX Service shall protect the administrative and security management parameters from manipulation by individuals who are not explicitly authorized by the Mission Critical Organization.
[33.180 MCX-A.4-009] The MCX service shall provide a means to support confidentiality of MCX user identities from all entities outside the MCX service.
[33.180 MCX-A.4-010] The MCX service shall provide a means to support confidentiality of MCX signalling from all entities outside the MCX service.
[33.180 MCX-A.4-011] The MCX Service shall provide a means to support end-to-end confidentiality and integrity protection for all media traffic transmitted between MC UEs.
[33.180 MCX-A.4-012] The MCX Service shall provide a means to support the confidentiality and integrity protection of location information transmitted from the MC UE to the MCX application server.
A.5 Ambient listening
[33.180 MCX-A.5-001] Specific roles in the organization and shall be identified to authorize and activate Ambient Listening and privileges shall be assigned to these roles to activate and register the use of ambient listening.
[33.180 MCX-A.5-002] The activation of the Ambient Listening functionality shall be automatically registered by the system and will be stored as an ‘event’ by the system.
[33.180 MCX-A.5-003] Any decision to activate Ambient Listening, or review of such a decision, may also be recorded in a suitable incident log unless to do so would interfere with the purpose for which the functionality is being used i.e. an investigation tool for evidence gathering in cases of suspected gross misconduct of staff or evidence gathering in criminal cases. If this is the case the authorization needs to be recorded elsewhere as appropriate.
[33.180 MCX-A.5-004] A radio user should be told as soon as possible that they are, or have been, subject to Ambient Listening and the reason why the functionality was activated. The fact they have been informed, by whom and when, should be recorded in a suitable log.
A.6 Data communication between MCX network entities
[33.180 MCX-A.6-001] A security mechanism shall exist that allows transmission of data between 3GPP MCX network entities to be authenticated, confidentiality protected, integrity protected and protected from replays.
NOTE: UE-to-UE and UE-to-network relays are not considered to be ‘network entities’.
A.7 Key stream re-use
[33.180 MCX-A.7-001] The MCX system shall ensure that key streams are not reused.
A.8 Late entry to group communication
[33.180 MCX-A.8-001] An authorized MCX User shall be able to obtain the information necessary to derive the group security context for the MCX Group while an MCX Group communication is on-going. As a result, the MC User shall be able to listen to the group communication within 350ms. This requirement applies for both on-network and off-network MCX operations.
A.9 Private call confidentiality
[33.180 MCX-A.9-001] It shall be possible to establish a unique Private Call security context between any pair of authorized MCX users within the MCX system. The security context shall not be available to other MCX users, except, where necessary, authorized MCX monitoring functions (e.g. LI, Discreet Listening). If the security context is made available to monitoring functions, appropriate controls and logging shall exist. This requirement applies when MCX UEs are operating both on-network and off-network.
[33.180 MCX-A.9-002] The Private Call security context shall provide a means to provide confidentiality and integrity protection of user traffic, and authenticate the MCX users involved in the Private Call.
A.10 Off-network operation
[33.180 MCX-A.10-001] The MCX service should take measures to detect and mitigate DoS attacks to minimize the impact to relays and to off-network MCX users.
[33.180 MCX-A.10-002] The MCX Service shall provide a means to support end-to-end security for all media traffic transmitted between MCPTT UEs, including where relays are used.
[33.180 MCX-A.10-003] The MCX Service shall provide a means to support the confidentiality and integrity protection of location information transmitted from the MCX UE to the MCX application server, including where relays are used.
[33.180 MCX-A.10-004] MCX off-network UEs shall be explicitly or implicitly authenticated to each other.
[33.180 MCX-A.10-005] MCX off-network UEs and MC relays shall be explicitly or implicitly authenticated to each other.
[33.180 MCX-A.10-006] The security solution should minimize the impact of a compromised MCX UE on other MCX UEs.
[33.180 MCX-A.10-007] The MCX Service shall provide a means to ensure integrity of all MCX user signalling at the MCX application layer.
[33.180 MCX-A.10-008] The MCX service shall provide a means to support confidentiality of MCX service user identities from all entities outside the MCX service.
[33.180 MCX-A.10-009] The MCX service shall provide a means to support confidentiality of MCX signalling from all entities outside the MCX service.
A.11 Privacy of MCX service identities
[33.180 MCX-A.11-001] The MCX service user identities of each plane shall be used within the corresponding plane and concealed to other planes.
[33.180 MCX-A.11-002] When required by the MCX Service provider, MCX application services layer identities (such as the Mission Critical user identity, MCPTT ID, MCVideo ID, MCData ID and MCX Group IDs) and other application services sensitive information (as further described in 3GPP TS 23.179 [2], clause 8.2), shall be contained within the application plane and shall provide a means to support confidentiality and integrity of the application plane from the SIP signaling plane.
[33.180 MCX-A.11-003] When protection of identities and other sensitive MCX application information is NOT required by the MCX Service provider, the MCX application services layer identities (such as the Mission Critical user identity, MCPTT ID, MCVideo ID, MCData ID and MCX Group IDs) and other application services sensitive information (as further described in 3GPP TS 23.179 [2], clause 8.2), shall remain contained within the application plane. While confidentiality protection is not required, integrity protection may be applied.
A.12 User authentication and authorization
[33.180 MCX-A.12-001] User authentication and authorization interoperability between different networks and different manufacturers’ clients and servers shall satisfy the requirements for mission critical roaming and migration.
[33.180 MCX-A.12-002] User authentication and authorization shall support all deployment models listed in 3GPP TS 23.179 [2].
[33.180 MCX-A.12-003] User authentication and authorization shall support interchangeable MC user authentication solutions, allowing implementations to use different means to authenticate the user, e.g. Web SSO, SIP digest, GBA, biometric identifiers, username+password.
[33.180 MCX-A.12-004] User authentication and authorization shall support scalability (number of users), providing efficient support for small MCX systems with few users, to large MCX systems with hundreds of thousands of users.
[33.180 MCX-A.12-005] User authentication and authorization shall support extensibility, providing authorization for additional mission critical services including group aware services, additional interfaces, etc.
[33.180 MCX-A.12-006] All users of the MCX Service shall be authenticated to prevent an adversary impersonating a user for the purpose of denial of service.
A.13 Inter-domain
[33.180 MCX-A.13-001] An MCX Service shall provide mechanisms to allow an MCX User to operate in a Partner MCX Service System, subject to authorization from both the Partner and the Primary MCX Service Systems of the MCX User (R-6.17.2-001 [47]).
[33.180 MCX-A.13-002] The authentication of an MCX User with an MCX Service in a Partner MCX Service System shall be based on security parameters obtained from the Primary MCX Service System of the MCX User (R-6.17.2-002 [47]).
NOTE 1: This is an application layer authentication and not 3GPP network authentication.
[33.180 MCX-A.13-003] An MCX Service shall provide mechanisms to allow an MCX User on the Primary MCX Service System to affiliate to an MCX Service Group from a Partner MCX Service System, subject to authorization from the Primary MCX Service System and the Partner MCX Service System where the MCX Service Group is defined (R-6.17.2-004 [47]).
[33.180 MCX-A.13-004] An MCX Service shall provide mechanisms to allow a roaming MCX User to affiliate to an MCX Service Group from the Partner MCX Service System, subject to authorization from the Partner MCX Service System where the MCX Service Group is defined (R-6.17.2-005 [47]).
[33.180 MCX-A.13-005] An MCX Service shall provide mechanisms to allow an MCX User that receives service from a Partner MCX Service System to affiliate to an MCX Service Group from another Partner MCX Service System, subject to authorization from the Partner MCX Service System where the MCX Service Group is defined (R-6.17.2-006 [47]).
NOTE 2: It is assumed that once affiliation from a User to a Group is successful, subsequent communication within that Group are available to the User.
[33.180 MCX-A.13-006] End to end security of an MCX Service Group communication (including in Partner MCX Service Systems) shall be based on parameters obtained from the MCX Service system where the MCX Service Group is defined (R-6.17.2-007 [47]).
[33.180 MCX-A.13-007] All Mission Critical Users shall be authenticated with their home identity management service prior to authentication or authorisation with a partner domain.
[33.180 MCX-A.13-008] A user requiring services at a partner domain shall first acquire a verifiable credential from the user’s primary identity management service.
[33.180 MCX-A.13-009] An identity management service shall authenticate a visiting user based on a verifiable credential from the user’s primary identity management service prior to authorising that user for local service(s).
[33.180 MCX-A.13-010] A visiting user shall be authorised with the local server(s) at the partner MCX System before being granted local services.
[33.180 MCX-A.13-011] The partner identity management service shall have full and overruling authorisation control of all visiting users requesting services in the partner MCX System.
[33.180 MCX-A.13-012] When using external security domains, the Home Security Domain shall apply policies which ensure that only trusted external security domains are used.
[33.180 MCX-A.13-013] Use of external security domains shall be logged to detect impersonation and misuse.
[33.180 MCX-A.13-014] MCX Services shall be able to permit/deny the use of security domains over their service.
A.14 MCData
[33.180 MCX-A.14-001] The MCData Service shall provide a means to support end-to-end confidentiality and integrity protection for messaging transmitted between MCX UEs in both media and signalling streams.
[33.180 MCX-A.14-002] The MCData Service shall provide a means to authenticate messages in both media and signalling streams.
A.15 Multimedia Broadcast/Multicast Service
[33.180 MCX-A.15-001] The security of signalling transmitted between the MCX client and MCX server shall be controlled by the MCX server. As a consequence of this requirement, the MCX Server shall not require key material from external MC Domains to enable the use of MBMS.
[33.180 MCX-A.15-002] The MCX Service shall provide means to support confidentiality and integrity protection for the MBMS subchannel control messages.