9 Signalling protection

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

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

9.1 General

Signalling between entities in the MC System are defined as:

– RTCP signalling (e.g. floor control),

– XML signalling (within SIP messages) , or

– MCData Data signalling (withing SIP or MSRP messages).

To allow this signalling to be protected, key distribution mechanisms are required to distribute the associated keys.

For protecting signalling between the client and the server, there are two key distribution mechanisms:

– ‘CSK upload’ procedure (as defined in clause 5.4).

– ‘Key download’ procedure (as defined in clause 5.8).

For protecting signalling between MCX Servers, there is one key distribution mechanism:

– manual SPK configuration (as defined in clause 5.5).

9.2 Key distribution for signalling protection

9.2.1 Client-Server Key (CSK)

9.2.1.1 General

A Client-Server Key is required to protect unicast RTCP signalling between the MC client and the MCX Server. The use of the CSK in this context is defined in clause 9.4.

Additionally, the MC Service provider may require that MC identities, access tokens and other sensitive information transferred between clients and MC domain on the SIP-1 and SIP-2 interfaces be protected at the application layer from any viewing, including protection from viewing at the SIP signalling layer. Symmetric key based protection of SIP payload using CSK may be used to satisfy this requirement. The use of CSK in this context is defined in clause 9.3.

The uses of the CSK are shown in Figure 9.2.1-1.

Figure 9.2.1-1: Uses of the Client-Server Key

9.2.1.2 Creation of the CSK

The 128-bit CSK is initially generated by the client and provided encrypted to the server through the SIP interface along with the CSK-ID identifying the CSK.

The key remains in use until: a new CSK is required, the SIP session is torn down, the MC user logs off, or some other indication. If during the active SIP session an update of the CSK is required, the server generates a CSK and provides it to the client using the mechanism defined in clause 5.8.

9.2.1.3 Initial ‘CSK Upload’ Procedure

The CSK is initially distributed via the ‘CSK upload’ procedure as defined in clause 5.4. The ‘CSK upload’ procedure creates a security association between the MC client and the MCX Server and occurs during the client’s initial connection with the MC Server.

The following steps describe how the client obtains the user specific key material and securely transfers the CSK to a server within the MC domain.

Prior to beginning of this procedure, the client would have obtained user-specific key material from the KMS.

1) The client randomly generates the CSK and encapsulates the CSK as described in clause 5.4.

2) The client includes the encapsulated CSK in its initial SIP REGISTER or in a SIP PUBLISH message that is used to perform the MC user authorization procedure, and sends the SIP message addressed to the PSI of the server.

An illustration is provided below as an example of how this message in included in the body of the SIP REGISTER message. The MIME media type "application/mikey" IETF RFC 3830 [22] is used in this example to insert a MIKEY I_MESSAGE in the SIP payload:

EXAMPLE:

Via: SIP/2.0/UDP den3.level3.com

Max-Forwards:70

From: MCPTT client IMPU

To:

Call-ID: <>

CSeq: 1 REGISTER

Contact: <URI>

Content-Type: multipart/mixed;boundary="boundary1"

Content-Length: 619

–boundary1

Content-Type: application/mikey

MIKEY I_MESSAGE

–boundary1

Content-Type: application/…

Encrypted Access token, MCPTT ID

–boundary1—

The following steps describe how the MCX Server retrieves the CSK from the SIP message:

1) The server receives the SIP message and decrypts the encapsulated the CSK as described in clause 5.4.

2) Once the CSK has been extracted, MC user specific information (e.g. the access token) protected in the SIP message as defined in clause 9.3.4, may be decrypted.

9.2.1.4 CSK update via ‘key download’

The MCX Server may decide to update an existing CSK at any time. This may be due to CSK revocation or expiry.

The CSK shall be updated by the MCX Server using the ‘key download’ procedure, defined in clause 5.8. Upon receipt of a CSK via a ‘key download’ procedure, the MC client shall identify the type of key as a CSK via the 4 most significant bits of the CSK-ID. The MC client shall:

– discard any previous CSKs associated with the MC Server FQDN, and

– use the new CSK for uplink signaling with the MC Server.

9.2.2 Multicast Signalling Key (MuSiK)

The Multicast Signalling Key (MuSiK) is required to protect multicast RTCP signalling from the MCX Server to the MC client. This includes MBMS floor control, media control and transmission control messages.

The MuSiK shall be distributed using the ‘key download’ procedure.

A ‘key download’ procedure is described in clause 5.8.

The use of the MuSiK is shown in Figure 9.2.2-1.

Figure 9.2.2-1: Uses of the Multicast Signalling Key (MuSiK)

The MCX Server distributes the Multicast Signalling Key (MuSiK) to a client when:

– The MCX Server requires protected signalling over the MBMS bearer to the MC client. In this case, an initial MuSiK (MuSiK_All) is distributed to the client using the key download procedure. By default, this MuSiK is used to protect all multicast signalling excluding bearer announcement messages.

– The MCX Server requires the transmission of group-related signalling (e.g. media control or floor control) over an MBMS bearer to the MC client, and the group configuration indicates that cryptographic protection is required for multicast group signalling. In this case, a new MuSiK (MuSiK_GRP) is created, assigned to the group and distributed to Group clients using the key download procedure. – The MCX Server requires an existing MuSiK to be replaced. This may be due to revocation or expiry.

– A participating UE (MC client) of the multicast group roams into the MBMS bearer coverage area.

NOTE: The participating MCX Server could use a single MuSiK for its MCX Groups and MBMS bearers. Where a MCX Group or MBMS bearer has privacy requirements, these procedures allow a new MuSiK to be distributed specifically for that purpose. A new MuSiK may not need to be distributed before each new bearer is established.

Upon receipt of a MuSiK the MC client shall store the MuSiK and MuSiK-ID. Should the MuSiK be rejected by the MC client, the MCX Server shall only use a unicast bearer when distributing signalling to the MC client.

Upon receipt of group-related signalling (e.g. media control or floor control) in the form of multicast SRTCP, the MC client shall inspect the MKI of the SRTCP packet which shall contain the MuSiK-ID. The MuSiK-ID shall be used to lookup the correct MuSiK for decrypting the SRTCP packet.Upon receipt of multicast MCData Data Signalling payloads, the MC client shall inspect the DPPK-ID element of the payload and extract the MuSiK-ID. The MuSiK-ID shall be used to lookup the correct MuSiK for decrypting the payload.

9.2.3 Signalling Protection Key (SPK)

The SPK is used to protect communications between MCX Servers. The SPK is distributed as defined in clause 5.5. The uses of the SPK for inter-server protection are shown in Figure 9.2.3-1.

Figure 9.2.3-1: Uses of the Signalling Protection Key

9.3 Application signalling security (XML protection)

9.3.1 General

Certain values, keys and identifiers transferred in XML between a server in the MC domain and client may be treated as sensitive by public safety users and may require protection. To protect these values from all other entities outside of the MC Domain, this clause defines an optional mechanism to provide confidentiality protection on these values using XML encryption. Additionally, as some public safety users may require integrity protection on transmitted content, this clause defines an optional mechanism to provide integrity protection using XML signatures.

NOTE 1: The protection mechanism specified in this clause is for public-safety use only.

NOTE 2: The introduction of XML security mechanisms increases the size of the XML document. Consideration should be given to the impact of this size increase.

Editor’s Note: It needs to be confirmed that the virtual proxy techniques being studied in SA3-LI (LIV8 S8HR study) can be extended to control use of MCPTT encryption in VPLMN roaming scenarios.

9.3.2 Protected content

Confidentiality protection may be applied to the entire XML document or to the following individual identifiers and values:

– MCX service user ID (e.g. MCPTT ID, MCData ID, MCVideo ID).

– MCX Group ID.

– User location information.

– Alerts.

– Access token.

– KMS provisioned key material.

– Functional aliases.

NOTE 1: The use of functional aliases for mission critical communications is defined in clause 5.9a of 22.280 [47] and may be included as part of MCPTT communications call setup and signaling as described in 23.379 [2].

Where confidentiality protection is applied to the entire XML document, the ‘type’ of message shall be clearly stated within the EncryptedData payload. The name shall reflect the names used in the message flows defined in TS 23.379 [2], TS 23.280 [36], TS 23.281 [37] and TS 23.282 [38]. This will allow the serving network to understand how their network is being used.

NOTE 2: Where the MCPTT Server is supporting legacy clients, these clients may not support confidentiality protection of the entire XML document. In this case, only individual identifiers and values should be confidentiality protected.

Integrity protection may be applied to the entire XML document, and to individual KMS certificates.

9.3.3 Key agreement

The confidentiality and integrity protection mechanisms defined in F.1.4 rely on a shared XML Protection Key (XPK) to be able to encrypt and sign XML.

For connections between the client and the MC Domain, the XPK shall be the 128-bit shared Client-Server Key (CSK) established as defined in clause 9.2.1. The XPK-ID shall be the CSK-ID.

For connections between servers inside and across MC Domains the XPK shall be the 128-bit manually provisioned Signalling Protection Key (SPK) established as defined in clause 9.2.3. The XPK-ID shall be the SPK-ID

For connections between the KMS and the MC KM client (as described in clause 5.3.3), confidentiality protection shall use the 256-bit TrK as the XPK and the TrK-ID as the XPK-ID. Integrity protection shall use the InK as the XPK and the XPK-ID shall be the InK-ID.

The integrity key and confidentiality key for application data protection shall be derived from the XPK as defined in annex F.1.4. The XPK-ID may be listed in the XML to aid decryption.

9.3.4 Confidentiality protection using XML encryption (xmlenc)

9.3.4.1 General

This clause defines an optional mechanism to allow specific XML content within the XML elements and XML URI attributes to be encrypted between the client and the server.

NOTE: Encryption of XML element content according to XML Encryption Syntax [27] and XML URI attribute encryption according to clause 9.3.4.3 is supported.

9.3.4.2 XML content encryption

XML content within XML elements is encrypted as defined by XML Encryption Syntax, Version 1.1 [27].

To encrypt content within a specific XML element, the content shall be replaced with the <EncryptedData> element. The <EncryptedData> element shall contain a <CipherData> element, containing a <CipherValue> element containing the encrypted content. Encryption shall be performed as defined in [27] using the CSK as the cipher key.

Where protecting content, the <EncryptedData> element may:

– Use the ‘Type’ attribute specifying that content is encrypted (‘http://www.w3.org/2001/04/xmlenc#Content’).

– Contain <KeyData><KeyInfo> element containing the base64 encoded XPK-ID.

– Contain <EncryptionMethod> element listing the encryption algorithm used for encrypting the XML content. The AES-128-GCM algorithm shall be supported, as identified by the algorithm identifier: ‘http://www.w3.org/2009/xmlenc11#aes128-gcm’.

Where protecting key material, the <EncryptedData> element may:

– Use the ‘Type’ attribute specifying that content is encrypted (‘http://www.w3.org/2001/04/xmlenc# EncryptedKey’).

– Contain <KeyData><KeyInfo> element containing the base64 encoded XPK-ID.

– Contain <EncryptionMethod> element listing the encryption algorithm used for encrypting the XML key material. The AES-256 key wrap algorithm as defined in RFC 3394 [34] shall be supported, as identified by the algorithm identifier ‘http://www.w3.org/2001/04/xmlenc#kw-aes256’.

Where these elements do not occur, the information they contain shall be known to both the client and server in the MC domain through other means.

The following is an example of unprotected XML content:

EXAMPLE:

sensitive.data@example.org

</ExampleTag>

When XML encryption is applied, the following is an example of the encrypted content:

EXAMPLE:

<EncryptedData xmlns=’http://www.w3.org/2001/04/xmlenc#’

Type=’http://www.w3.org/2001/04/xmlenc#Content’>

<ds:KeyInfo>

<ds:KeyName>base64XpkId</KeyName>

</ds:KeyInfo>

</CipherData>

</EncryptedData>

</ExampleTag>

9.3.4.3 XML URI attribute encryption

XML attribute encryption shall be performed by encrypting the URI and embeddeding the encrypted ciphertext within a new URI. The appended domain name of the new URI identifies the attribute as having confidentiality protection. Encryption shall be performed using the AES-128-GCM [42], as the encryption algorithm, XPK as the key, and the use of a 96 bit randomly selected IV.

The output URI is structured to contain:

– the base64 encoded encrypted URI;

– the string ";iv=" followed by the base64 encoded 96-bit random initialisation vector (IV) which is used by the AES-128 encryption algorithm (as described in TS 33.203 subclause 6.4).

– the string ";key-id=" followed by the base64 encoded encryption key identifier (XPK-ID);

– the string ";alg=" followed by the encryption algorithm identifier (128-bit encryption algorithm "128-AES-GCM");

– the appended domain name of the new URI e.g. “@mc1-encryption.3gppnetwork.org”.

An example of the resultant sip-uri after encryption is:

sip:98yudFG45tx_89TYGedb4ujF;iv=FGD567kjhfH7d4-D;key-id=eV9kl7;alg=128-aes-gcm@mc1-encryption.3gppnetwork.org

The following is an example of unprotected XML URI content within XML attributes:

EXAMPLE:

Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>

</status>

</tuple>

</presence>

When XML URI attribute encryption is applied, the following is an example of encrypted URIs within XML attributes:

EXAMPLE:

Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>

</status>

</tuple>

</presence>

9.3.5 Integrity protection using XML signature (xmlsig)

Where integrity protection is required, an XML HMAC signature may be applied using the XPK to key the HMAC to a whole XML MIME body.

The XML HMAC signature mechanism is specified by W3C [28]. The HMAC-SHA256 signature method shall be supported.

When integrity protection is enabled, all XML MIME bodies transported in SIP requests and responses are integrity protected. If one or more of the XML MIME bodies are included in a SIP request or SIP response, then a MIME body is included in the SIP request or SIP response containing one or more signatures pointing to those XML MIME bodies as illustrated in the figure 9.3.5-1.

In order to integrity protect the XML MIME bodies in SIP requests and SIP responses, the MC client and MCX server shall for each MIME body, include the Content-ID header field as specified in IETF RFC 2045 [40] containing a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [41].

Figure 9.3.5-1: Integrity Protection of XML MIME bodies in SIP requests and SIP responses

Each MIME body that is integrity protected is assigned a unique signature contained in a <Signature> element.

The <Signature> element shall contain the following child element:

<SignatureValue> HMAC signature of the content

The <Signature> element may contain the following child elements:

– <CanonicalizationMethod> element listing an appropriate algorithm.

– <SignatureMethod> element listing an appropriate algorithm. HMAC-SHA256 shall be supported for signatures.

– <KeyInfo><KeyName> element containing the base64 encoded XPK-ID.

– <Reference> element containing a URI identifying the content to be signed and the method for hashing the content. SHA-256 shall be supported for hashing content.

Where these elements do not occur, the information they contain shall be known to both the client and server in the MC domain through other means.

9.4 RTCP signalling protection (SRTCP)

9.4.1 General

RTCP encryption is required between the MC UE and MCX Server and between a pair of MCX Servers. RTCP is protected hop-by-hop, meaning that RTCP is always decrypted by the MCX server and then re-encrypted to its destination.

The following signalling uses RTCP and is protected using the procedures in this clause:

– MCPTT floor control signalling (MBCP or TBCP).

– Unicast uplink and downlink (online), multicast downlink (online) and off-network transmission.

– MCVideo transmission control (online/off-network).

– Unicast uplink and downlink (online), multicast downlink (online) and off-network transmission.

– MCPTT/MCVideo media signalling.

– Unicast uplink and downlink (online), multicast downlink (online) and off-network transmission.

– MBMS subchannel control signalling (from MCX Server to MC UE).

– multicast downlink (online).

All RTCP (floor control, media control and MBMS subchannel control signalling) is protected in the same way. RTCP is protected using SRTCP. The master key for SRTCP is derived from a Key For Control signalling (KFC). The KFC is shared between the transmitter and receiver(s) prior to distribution of the SRTCP packets. A 32-bit identifier for the key (KFC-ID) and a 128-bit random value (KFC-RAND) is also established.

There are a number of key distribution mechanisms for establishing the KFC based on the interface over which RTCP is being transmitted.

9.4.2 Unicast RTCP protection between client and server

In Clause 9.2.1, a Client-Server Key (CSK) is generated and shared between the MC client and MCX Server along with the CSK identifier (CSK-ID). For floor and media control, the KFC shall be the CSK and the KFC-ID shall be the CSK-ID. KFC-RAND shall be the MIKEY RAND value transmitted in the MIKEY message used to distribute the CSK.

9.4.3 Multicast RTCP protection between client and server

In clause 9.2.2, a Multicast Signalling Key (MuSiK) is generated and shared from the MCX Server to the MC client, along with the MuSiK identifier (MuSiK-ID). For the protection of multicast floor and media control, the KFC shall be the MuSiK and the KFC-ID shall be the MuSiK-ID. KFC-RAND shall be the MIKEY RAND value transmitted in the MIKEY message used to distribute the MuSiK.

To support multicast signalling protection, the MSCCK and the legacy MKFCs may also be used for this purpose as defined in Annex H.

9.4.4 Off-network floor and transmission control protection

Off-network, the KFC is the PCK (for private communications) or the GMK (for group communications) as described in clause 7.3.4, and the KFC-ID is the PCK-ID or GMK-ID (respectively).

9.4.5 RTCP protection between servers

In Clause 9.2.3, a Signalling Protection Key (SPK) is shared between MCX Servers along with a SPK-ID. For floor and media control signalling transferred between MCX Servers, the KFC shall be the SPK, the KFC-ID shall be the SPK-ID and the KFC-RAND shall be the SPK-RAND.

9.4.6 Key derivation for SRTCP

As a result of the key agreement process, the entities (MCX client and server, or MCX servers) shall share a KFC, a KFC-ID and a KFC-RAND. The KFC shall be used as the MIKEY Traffic Generating Key (TGK), the KFC-ID shall be used as the MIKEY CSB ID and the KFC-RAND shall be used as the MIKEY RAND value. The MIKEY CS-ID shall be set as defined in table E.1.3-1. These shall be used to generate the SRTCP Master Key and SRTCP Master Salt as specified in IETF RFC 3830 [22]. The key derivation function defined in section 4.1.3 of IETF RFC 3830 [22] using the PRF-HMAC-SHA-256 Pseudo-Random Function described in section 6.1 of IETF RFC 6043 [25], shall be supported for generating the SRTCP Master Key and Salt. SRTCP session keys are generated from the SRTCP Master Key and Salt as defined in clause 9.4.8.

NOTE: Within RFC 3830 [22], the SRTCP Master Key and SRTCP Master Salt are referred to as the SRTP Master Key and the SRTP Master salt respectively.

Figure 9.4.6-1: Key derivation for on-network floor and media control protection

To identify the security context from the SRTCP stream a SRTCP Master Key Identifier (MKI) is required. The MKI shall be the 32-bit KFC-ID.

9.4.7 Security procedures for transmission of RTCP content

After key establishment, RTCP protection does not require any signalling mechanism to convey information. The RTCP is protected within an SRTCP packet. The information necessary for decryption is provided within each SRTCP Packet.

Figure 9.4.7-1: Security procedure for media stream protection

Figure 9.4.7-1 shows the security mechanism.

0) Prior to beginning this procedure the MC entities (MC UEs and/or MCX Server) involved in the communication shall have established a security context for SRTCP (Master Key, Master Salt, MKI).

1) The transmitting entity (MC UE or MCX Server) shall send SRTCP packets using the format described in IETF RFC 3711 [13]. The packet shall include a Master Key Identifier (MKI) field which contains the information required to locate the Master Key and Master Salt. On receipt of a SRTCP packet, a terminating entity (MC UE or MCX Server) shall use the contents of the MKI to look up the appropriate Master Key and Salt and generate the appropriate SRTCP session key and salt if it satisfies the key derivation rate criteria as specified in IETF RFC 3711 [13].

NOTE 1: Assuming entities have been keyed/pre-provisioned at some point in the past, this security mechanism is entirely stateless.

NOTE 2: The receiver does not need to generate an appropriate SRTCP session key and salt each time it receives a SRTCP packet. The key derivation rate defined in IETF RFC 3711 [13] determines the session key generation frequency. Refer to RFC 3711 [13] for more information.

A diagram of the SRTCP packet format is within figure 9.4.7-2.

Figure 9.4.7-2: SRTCP packet format showing security parameters

The length of the MKI is determined by the key distribution mechanism.

9.4.8 RTCP protection profile

Integrity and confidentiality protection for communications using RTCP for floor control, transmission control, and media control is achieved using SRTCP, as defined in IETF RFC 3711 [13]. The mechanism described in IETF RFC 3711 [13] is used to encrypt the RTCP payload. A diagram of the key derivation mechanism (as described in IETF RFC 3711 [13]) is shown in figure 9.4.8-1.

Figure 9.4.8-1: Security mechanism for floor control, transmission control, and media control protection

The AES-CM-128 algorithm as defined in IETF RFC 3711 [13] shall be supported as the SRTCP PRF (which is used to derive the SRTCP session key and salt). A SRTP key derivation rate of 0 shall be used to indicate that session keys and salts shall not be refreshed. The AEAD_AES_128_GCM algorithm as defined in IETF RFC 7714 [26] shall be supported for providing confidentiality and data authentication of SRTCP packets. The AEAD_AES_128_GCM algorithm requires that the SRTCP session key is 16 octets in length and the session salt is 12 octets in length.

NOTE: Some SRTCP implementations are not compliant with RFC 3711 due to the size of the SRTCP index, as discussed in RFC 3711 Errata ID 3712 [51].

9.5 MCData signalling protection

9.5.1 Key distribution for signalling protection

Where MCData signalling parameters or MCData Data signalling payload protection is required, key distribution and key use for MCData signalling is equivalent to MCPTT and MCVideo. MCData signalling parameters or MCData Data signalling payload protection is defined in subclause 8.2.

The procedures for CSK distribution are defined in clause 9.2.1. The procudures for MuSiK distribution are defined in clause 9.2.2. The procedures for SPK distribution are defined in clause 9.2.3.

9.5.2 Protection of MCData application signalling payloads (XML)

Protection of MCData application signalling payloads, specifically XML content within SIP messages, is defined in clause 9.3. For the protection of MCData signalling, the XPK shall be the DPPK.

9.5.3 Protection of MCData signalling payloads

Protection of MCData Data signalling payloads is defined in clause 8.5.

9.6 Message origin authentication and authorisation

9.6.1 General

The MC System allows authorised service requests where the ‘requester’ may cause modification to the operation of the MC Domain service or initiate an action on a target MC client, potentially without that client’s permission.

Clauses 9.3 and 9.5 describe how on-network application signalling is protected hop-by-hop within the MC System. In an MC Domain which is interconnected or supporting migration, application signalling may pass through multiple MCX Servers from the requester to the target client. Using hop-by-hop signalling security alone, the target’s MCX Server and the target’s client would be unable to authenticate the identity of the requester, or whether the requester has permission to perform the action. This leaves the MC domain and MC client open to attack via misuse of signalling requests along the signalling path.

For example:

a) A ‘Group Affiliation Status Update’ could originate from a MCX Server in a different domain to the Group Management Server. In this case the GMS requires information to ensure that the MCX Server has permission to modify the affiliation status of the requested user.

b) An ‘Ambient Listening Request’ could originate from a different domain to the target user. The target’s MCPTT Server requires information to ensure that the originator is permitted to make the request.

c) An off-network ‘Call Setup Request’. The target client requires information to ensure that the originator is permitted to make the request prior to responding to the request.

The subsequent clauses define an optional Element for Authenticating Requests (EAR), which is a signed element which may be attached to signalling requests across the MC System, both on and off-network. Where authorisation information is required to support the request, the requesting MC entity may use an Authorised Identity to sign the request.

The EAR allows an MC client or MC network entity to verify the origin, target and purpose of a signalling request, and that the origin is authorised to make such a request. In the network, authorisation is given by the profiles within the Configuration Management Server (CMS) and enforced by the MCX Server. The EAR allows authorisation to also be verified at the client, based on the contents of the EAR. EAR authorisations are provided by the the IdM to MC user (via the KMS).

With the EAR mechanism enabled, permission to use privileged signalling (e.g. Ambient Listening) needs to be enabled by both the IdM and the CMS. This allows a duel-check approach where the requesting user’s permission is verified by both the network (based on the user’s profile in the CMS) and the target client (based on the requesting user’s Authorised Identity).

9.6.2 Origin authentication and authorisation in the MC System

9.6.2.1 Types of signalling

The purpose of authentication is to provide evidence to the receiver on the identity of the requester. The purpose of authorisation is to convey to the receiver that the requester has permission to take an action. In the MC System, MC client authentication and authorisation is primarily managed by the client’s MCX Server. The MCX Server uses the access token and CSK to authenticate the user’s MC client, and the user configuration to authorise the user’s MC client. However, local authentication and authorisation may be insufficient where the user or signalling is moving across domains.

The additional authentication and authorisation mechanisms defined in Clause 9.6 may be attached to any signalling messages in the MC system, but in some specific cases, the mechanisms should be used. The following situations describe where the mechanisms defined in Clause 9.6 should be used in the MC system:

Case 1: Privileged signalling sent within the MC System (e.g. Ambient listening request): Authentication should be provided by an EAR using an authorised user identity (MC Service ID). This allows the target’s MCX Server and MC client to assess whether the request is authorised.

NOTE 1: Privileged signalling is signalling which allows one client to remotely cause an intrusive action on a target client without the target user’s permission.

Case 2: Signalling between network entities in separate MC domains (e.g. group call request from partner MCPTT server to primary MCPTT server). Authentication should be provided by an EAR using an authorised server/domain identity. This allows the receiving MC domain to confirm the requesting entity is a MCPTT server from a known partner MC domain.

Case 3: Signalling between a group client attached to a partner MC Domain and the Group Management Server. Authentication from the client to the server should be provided by an EAR using the user’s identity (MC Service ID). Authentication from the server to the client should be provided by an EAR using an authorised server/domain identity.

NOTE 2: An authorised user identity is not required in this case as authorisation of the MC client is provided by the user configuration document.

Case 4: Signalling between the home network and a home client who has migrated to a partner MC Domain. Authentication from the client to the server should be provided by an EAR using the user’s identity (MC Service ID). Authentication from the server to the client should be provided by an EAR using an authorised server/domain identity.

NOTE 3: An authorised user identity is not required in this case as authorisation of the MC client is provided by the user configuration document.

Case 5: Off-network signalling between MC clients. Authentication should be provided by an EAR using an authorised user identity (MC Service ID).

Where the request, containing a EAR, is routed via a MCX Server, the MCX Server should copy the EAR from the received request to the out-going request. Multiple EARs can be attached to a signalling message. For example, one EAR may be attached to authenticate the user making the request, and another may be attached to authenticate the domain sending the request on behalf of the user.

9.6.2.2 Privileged Signalling

All Privileged Signalling sent within the network should be authenticated and authorised using a EAR signed using an Authorised Identity (MC Service ID). The following are privileged signalling requests which should be explicitly authenticated and authorised:

– MCPTT Private call request in automatic commencement mode (TS 23.379).

– MCPTT Ambient listening call request (TS 23.379).

– MCPTT Remotely initiated MCPTT call request, in unnotified mode (TS 23.379).

– MCVideo Private call request (including private call, video pull and video push) in automatic commencement mode (TS 23.281).

– MCVideo Remote video push request in automatic commencement mode (TS 23.281).

– MCVideo Ambient viewing call request (TS 23.281).

– MCData standalone data request for application consumption (TS 23.282).

– MCData standalone session data request for application consumption (TS 23.282).

– MCData session data request for application consumption (TS 23.282).

– MCData group standalone data request for application consumption (TS 23.282).

– MCData group data request for application consumption (TS 23.282).

– MCData FD request with mandatory indication (TS 23.282).

– MCData group standalone FD request with mandatory indication (TS 23.282).

9.6.2.3 Signalling between network entities across domains

Where signalling is sent across domains, the servers used to send the signalling should be authenticated and authorised using a EAR signed using an Authorised Identity, indicating the server’s role. within the MC domain. This ensures that only Group Management Servers are authorised to send group notifications, and only MCX servers are authorised to send key download messages. The following roles are used:

– MCPTT Server

– MCVideo Server

– MCData Server

– CS Proxy

– IS Proxy

– Group Management Server

The IS Proxy is authorised to authenticate the functions of a MCPTT Server, MCVideo Server or MCData Server towards another MC domain. The CS proxy is authorised to authenticate the functions of a MCPTT Server, MCVideo Server or MCData Server towards a MC client. Consequently, the addition of EARs may be performed at the edge of the MC domain.

9.6.2.4 Signalling between the GMS and the GMC

Where signalling is sent between the group management server and the group management client, the entity at each end should be authenticated and authorised using a EAR. The EAR from the GMS should be signed using an Authorised Identity, indicating the server is able to perform GMS functions. The GM client is not required to use an Authorised Identity. The following Group management messages should be explicitly authenticated and authorised:

– Subscribe Group Configuration Request

– Subscribe Group Configuration Response

– Notify Group Configuration Request

– Notify Group Configuration Response

– MC Group affliation request

– Group affliation status update

9.6.2.5 Signalling between the MC domain and a migrated user

Where signalling is sent out of the domain towards a migrated MC client, the servers used to send the outbound signalling should be authenticated and authorised using a EAR signed using an Authorised Identity, indicating the server’s role. The server roles defined in Clause 9.6.2.3 shall be used.

The inbound signalling from the migrated client shall be authenticated and authorised using an EAR. The migrated MC client is not required to use an Authorised Identity.

This clause is applicable to all signalling sent to or from the migrated user.

9.6.2.6 Off-network signalling

All off-network signalling requests should be authenticated and authorised using a EAR signed using an Authorised Identity (MC Service ID). The client’s role should be explicitly authorised. The following roles are used:

– MCPTT client

– MCVideo client

– MCData client

The client should be authorised to use any off-network functionality. Furthermore, the following are the off-network signalling requests which the client should be authorised to use:

– MCPTT Group call announcement (TS 23.379).

– MCPTT emergency alert announcement (TS 23.379).

– MCPTT Call setup request (TS 23.379).

– MCVideo Group communication announcement (TS 23.281).

– MCVideo emergency alert announcement (TS 23.281).

– MCVideo Private communication request (TS 23.281).

– MCVideo Capability request (TS 23.281).

– MCVideo Activity request (TS 23.281).

– MCData standalone data request (Clause 7.4.3.3.2, TS 23.282).

– MCData group standalone data request (Clause 7.4.3.4.2, TS 23.282).

9.6.3 Authorised Identities

9.6.3.1 Format of an Authorised Identity

Authorisation is conveyed using the MC entity’s identity (e.g. MC Service ID) that is used to sign the EAR. This is known as the user/entity’s Authorised Identity.

Within an Authorised Identity, authorisation information is contained within a SIP URI Header (known as an MC authorisation field). Authorisation fields are added to the entity’s identity to provide information on the MC entity’s authorisations. Authorisation fields are name, value pairs. The value of the authorisation field provides a set of authorisations, formatted as a hexidecimal string. Authorisation fields are defined in Annex J.3.

9.6.3.2 Obtaining an Authorised Identity

Authorisation is originally requested and provided by the IdM. If authorisation is granted, the IdM provides the authorisation information within the scope of an access token. The scope values contained within the access token are defined in Clause J.3.3.

The access token is provided to the KMS as defined in Clause 5.1.

The KMS provisions the entity’s keys to the entity as defined in Annex D. As part of the key provisioning process, the KMS may provision the entity keys for multiple SIP URIs that are associated with the entity.

If supported, where the scope of an access token contains one of the values defined in Clause J.3.3, the KMS provides multiple authorised identities which includes authorisation fields as part of the identity. Specifically, for each SIP URI associated with the entity, the KMS provisions:

– Key material for the identity: the entity’s identity (e.g. MC Service ID).

– Key material for the Authorised Identity: the entity’s identity with the applicable authorisation fields included.

The keyed entity may use either identity when signing within the MC System, (depending on whether it is configured to disclose its authorisations).

9.6.4 Element for Authenticating Requests (EARs)

9.6.4.1 Overview

When sending a sensitive signalling message, the requester creates the message as normal, then constructs and attaches an EAR to the message. The EAR contains the purpose and constraints of the request (type of request, restrictions on request, origin, destination) and is signed by the requester using the private signing key for the authorised identity. When used correctly, the EAR should provide a definitive record of the ‘request’ that was made, including evidence that the request was not disproportionate.

9.6.4.2 The EAR information element

The EAR payload shall contain the following information elements:

Table 9.6.4.2-1: Element for Authenticating Requests Payload

Information element	Status	Description
Date/Time	M	The date/time of the request
EAR ID	M	A unique identifier for the request
Origin ID	M	The identity associated with the requester. This will be the MC Service ID of the user or the Server’s URI. The identity may be an authorised identity, as defined in Clause 9.6.4.3.
Target ID	M	The identity associated with the intended receipient. This will be the MC Service ID of the user or the Server’s URI.
Request Type	M	The type of request (e.g. Ambient Listening), including limitations to the request (e.g. maximum session length). Details of the Request Type IE are provided in Annex J.2.

The EAR payload shall be signed using the approach defined in Clause 8.5.5. The signed payload is attached to signalling messages as an EAR.

9.6.4.3 EAR authorisation

The contents of an EAR are defined in Clause 9.6.4.2.

To add authorisation information to the EAR, the identity associated with the requester shall be an Authorised Identity. The identity-based signature used to sign the EAR will be an Authorised Identity. The receiver processes the Authorised Identity to extract the requester’s authorisations, and confirms that the type of request within the EAR is permitted given the requester’s authorisations.

NOTE: The only entity that could create the signature, and hence the whole EAR, is an entity granted the means to sign using Authorised Identity. The KMS provides the means to sign using a specific identity. By doing so, the KMS has provided authorisation to create the EAR signature and authorise the specific action.

9.6.5 Security procedures for origin authentication

9.6.5.1 General

Signalling in the MC System may use Elements for Authenticating Requests (EARs) for communicating origin authentication to the receiving entities.

9.6.5.2 SIP signalling

9.6.5.2.1 General

A sender or processor of a SIP message may add an EAR to any SIP message to authenticate the origin of the message.

To add origin authentication to a SIP message, an application/vnd.3gpp.mc-signalling-ear MIME body is added to tbe message containing an EAR message as defined in Clause 9.6.4.2. Such requests are known as a "Origin authenticated SIP message".

A SIP message may contain multiple application/vnd.3gpp.mc-signalling-ear MIME bodies.

9.6.5.2.2 Group affiliation and deaffiliation signalling

Group affiliation signalling requires the EAR to be transferred by the MC Server from the client’s request to the status update towards the GMS. The procedure is shown in Figure 9.6.5.2.2-1.

Figure 9.6.5.2.2-1: MC service group affiliation procedure

In this procedure, an EAR should be attached to Step 1 and passed to the MC service server. The MC service server should copy the client’s EAR into the Group affiliation status update message, transmitted by the MC service server to the GMS in Step 5b. The MC service server may also add an additional EAR authenticating the MC service server itself towards the GMS. On receipt of the EAR(s), the GMS has the necessary information to authorise the request to modify group affiliations.

The same procedures apply to the de-affiliation process. In this case, client EAR should be copied into the Group de-affiliation status update.

9.6.5.3 Off-network signalling

An EAR may be attached to any MONP signalling message to authenticate the origin of the message. The message then becomes an authenticated MONP message. Table 9.6.5.3-1 defines an authenticated MONP message.

Table 9.6.5.3-1: Authenticated MONP message

IEI	Information Element	Type/Reference	Presence	Format	Length
	Original MONP message	See Clause 15 in TS 24.379.	M	x	x
	Element for Authenticating Requests	EAR Annex J.1.2	O	TLV-E	3-x

9.6.5.4 Processing a received EAR

EARs may be processed by the receiver or routing network equipment to support an authentication and authorisation check on the signalling message. Clause 9.6.2 defines the types of requests where the EAR should be processed.

If supported by the receiver, upon receipt of a signalling message containing an EAR the receiver should:

1) Validate the signature on the EAR based on the provided UID.

2) Validate that the Target ID is associated with an apprpropriate user.

3) Check the date/time is within a recent window (e.g. 300 seconds) and the that a message with the EAR ID has not been already processed within that window.

4) Validate that the Origin ID of the EAR produces the UID.

5) If the request requires authorisation, extract the authorisation fields from the Origin ID. Validate that the Request Type is authorised by the authorisation fields, and that the KMS URI in the signature is permitted to authorise this type of request.

6) Verify that the Request Type corresponds to the SIP signalling message.

7) Verify that the Request Type parameters are not exceeded by the SIP signalling message.

8) Process the SIP message as normal.

If EARs are not supported by the receiver, the EAR shall be ignored.