9 Protection of floor control and sensitive application signalling

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

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

9.1 Key agreement for protection of floor control and sensitive application data (Client to Server)

9.1.1 Identity-based key management for Client Server Key (CSK)

A Client-Server Key is required to protect floor and media control signalling between the MCPTT client and the MCPTT Server.

Additionally, the MCPTT Service provider may require that MCPTT related identities and other sensitive information transferred between clients and MCPTT 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.

Identity based Public Key Cryptography (IDPKC) based on MIKEY-SAKKE IETF RFC 6509 [11] may be used to establish the CSK between two SIP endpoints. Before IDPKC can be used by client to securely share the encryption key, the MCPTT user shall first be authorized by KMS for MCPTT key management services. Once the MCPTT user is authorized, the KMS distributes the user’s key material to the client as specified in clause 7.2.3.

MIKEY-SAKKE IETF RFC 6509 [11] shall be used by the client to securely transport the CSK over SIP to all the servers within an MCPTT domain.

The server receives the SIP message with the protected CSK and retrieves it from the message. It associates the MCPTT User’s SIP Core identity (IMPU), MCPTT ID and the received CSK. Identity binding is used to uniquely identify the CSK used in protection of the SIP payload in subsequent SIP messages sent by both the client and the servers within an MCPTT domain.

The purpose of the CSK is the following:

– Protection of floor and media control signalling between the MCPTT client and MCPTT Server.

– Protection of sensitive MCPTT application data in the signalling plane.

– Protection of the Access Token in the signalling plane.

The uses of the CSK are shown in Figure 9.1-1:

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

9.1.2 Creation of the CSK

The 128-bit CSK is 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 MCPTT user logs off, or some other indication. If during the active SIP session an update of the CSK is required, the client may establish a new CSK and provide it to the server.

9.1.3 Secure distribution of the CSK

9.1.3.0 General

The CSK is created by the client and distributed to the servers within an MCPTT domain using MIKEY-SAKKE IETF RFC 6509 [11].The shared CSK is distributed in the MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [11], which ensure the confidentiality, integrity and authenticity of the payload.

9.1.3.1 MIKEY-SAKKE I_MESSAGE

The key is encrypted to the identity associated to the MCPTT domain (UID), and inserted in the SAKKE payload of the I_MESSAGE. The UID used to encrypt the data will be derived from the MCPTT Domain Security Identifier (MDSI) and a time-related parameter (e.g. the current year and month) as described in clause 7.2. The MDSI is added to the recipient field (IDRr) of the message.

The I_MESSAGE message also contains a signature in the SIGN payload, which is based on the user identity (UID) of the MCPTT User. This identity is derived from the MCPTT ID of the user and a time-related parameter (e.g. the current year and month). The MCPTT ID is added to the initiator field (IDRi) of the message. Where the MCPTT ID is sensitive, the identity mechanism defined in clause E.7 is used to define the initiator field of the message.

Clause E.4 provides MIKEY message structure for CSK distribution.

The resulting MIKEY-SAKKE message is sent over SIP (for example, during MCPTT User authorization).

9.1.3.2 Distribution of CSK during MCPTT Service Authorization and group subscription

The client shall include the MIKEY message, containing the CSK, in the SIP message that is used to perform the MCPTT user authorization procedure.

An illustration is provided below as an example of how this message in included in the body of the SIP REGISTER message.

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 MIME media type "application/mikey" IETF RFC 3830 [22], is used in this example to insert MIKEY I_MESSAGE in the SIP payload.

9.1.3.3 Obtaining CSK from the I_MESSAGE

The server performs the following steps when it receives the SIP message with the MIKEY I_MESSAGE containing the encrypted CSK:

1. Where the MCPTT ID is sensitive and is encrypted with CSK key,use the client’s UID obtained from the IDRi field in the message to compute the signature and verify it with the value in the SIGN payload of the MIKEY message.

2. The SAKKE based encryption scheme defined in IETF RFC 6509 [11], is used to extract the CSK from the SAKKE payload of the MIKEY message.

3. Compute client’s UID based on the MCPTT ID decrypted using the CSK key, and compare the UID with the UID obtained from the IDRi field of the MIKEY message.

9.1.3.4 Procedure

The following steps describe how the client obtains the user specific key material and securely transfers the CSK to a server within the MCPTT 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. The client computes MCPTT Domain UID from the MCPTT Domain Security Identifier (MDSI) and uses it to encrypt the CSK based on SAKKE based encryption IETF RFC 6509 [11].

2) The client generates MIKEY-SAKKE I_MESSAGE. The message shall encapsulate the encrypted CSK and shall be signed using the key associated with the MCPTT User’s UID generated from the MCPTT ID.

3) The client includes the I_MESSAGE in the SIP payload and sends the SIP message addressed to the PSI of the server.

The following steps describe how the server retrieves the encryption key from the SIP message:

1) The server receives the SIP message with the I_MESSAGE embedded in the SIP payload.

2) The server checks the signature on the I_MESSAGE message using client’s UID.

3) If the signature is valid, the server extracts and decrypts the encapsulated CSK using the key associated with the MCPTT Domain’s UID generated from the MCPTT Domain Security Identifier (MDSI).

4) Once the CSK has been extracted, MCPTT specific information including access token protected in the SIP message as defined in clause 9.3.4, may be decrypted.

Figure 9.1.3-.4-1 shows the functional diagram for the client and a server within the MCPTT domain. The server is shown in this example.

Figure 9.1.3.4-1: Functional diagram for Identity based distribution of CSK

9.2 Key agreement for protection of floor control and sensitive application data between servers

Floor and media control between MCPTT servers may need to be protected. Additionally, certain values and identifiers transferred in the signalling plane between servers within an MCPTT domain, or between MCPTT domains may be treated as sensitive by public safety users.

To protect information from all other entities outside of the MCPTT domain(s), a shared 128-bit Signalling Protection Key (SPK) needs to be established between the servers. The SPK is provided along with a 32-bit identifier, the SPK-ID and 128-bit random value SPK-RAND. The most significant four bits of the identifier (the Purpose Tag) of the SPK-ID shall be ‘3’ to denote the purpose of the SPK is for signalling protection, as described in clause 7.3.3.

The SPK and associated values shall be directly provisioned into the communicating servers, along with the SPK-ID. With the SPK provisioned, floor and media control and XML content within the SIP may be protected as defined in clause 9.3.

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

The uses of the SPK for inter-server protection are shown in Figure 9.2-1.

Figure 9.2-1: Uses of the Signalling Protection Key

9.3 Protection of XML content

9.3.1 General

Certain values, keys and identifiers transferred in XML between a server in the MCPTT domain and client may be treated as sensitive by public safety users. To protect these values from all other entities outside of the MCPTT 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 only be applied to the following identifiers and values:

– MCPTT ID.

– MCPTT Group ID.

– User location information.

– Alerts.

– Access token.

– KMS provisioned key material.

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

9.3.3 Key agreement

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

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

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

For connections between the KMS and the MCPTT client, the XPK shall be the 256-bit manually provisioned TrK, described in clause 7.2.3. The XPK-ID shall be the TrK-ID.

The integrity key and confidentiality key for application data protection shall be derived from the XPK as defined in clause 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: Only encryption of XML simple content within XML elements and XML URI attributes is supported. Encryption of XML tags is not 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 MCPTT 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 MCPTT confidentiality protection. Encryption shall be performed using the AES-128-GCM [36], 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 Signature syntax is defined by W3C in [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 MCPTT client and MCPTT server shall for each MIME body, include the Content-ID header field as specified in IETF RFC 2045 [37] containing a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [38].

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 MCPTT domain through other means.

9.4 Key agreement for online floor control (SRTCP)

9.4.1 General

Floor control encryption is required between the MCPTT UE and MCPTT Server and between a pair of MCPTT Servers. Floor control security is protected hop-by-hop, meaning that floor control traffic is always decrypted by the floor control server within the MCPTT server and then re-encrypted to its destination.

The purpose of key agreement is to establish a Key for Floor Control (KFC) from which the master key for the SRTCP protocol can be derived. A 32-bit identifier for the key (KFC-ID) and a 128-bit random value (KFC-RAND) is also established. Media control is protected in the same way as floor control, using the same key material.

9.4.2 Key agreement between MCPTT client and MCPTT Server

In Clause 9.1, a Client-Server Key is generated and shared between the MCPTT client and MCPTT Server, along with the 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 Key agreement between MCPTT Servers

In Clause 9.2, a Signalling Protection Key (SPK) is shared between MCPTT Servers along with a SPK-ID. For floor and media control signalling transferred between MCPTT 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.4 Key agreement for multicast from MCPTT Server

In clause 7.3.2, a Multicast Key for Floor Control (MKFC) is generated and shared from the GMS to the MCPTT Server and MCPTT client, along with an identifier (MKFC-ID). For the protection of multicast floor control, the KFC shall be the MKFC and the KFC-ID shall be the MKFC-ID. KFC-RAND shall be the MIKEY RAND value transmitted in the MIKEY message used to distribute the MKFC.

9.4.5 Derivation of SRTCP key material

As a result of the key agreement process, the entities (MCPTT client and server, or MCPTT 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. 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 as described in IETF RFC 6043 [25], section 6.1 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 7.6.

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.5-1: Key derivation for on-network floor and media control protection

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

Annex A (normative):
Security requirements