6.5 Confidentiality and Integrity Protection of sensitive XML content

24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS

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

6.5.1 General

6.5.1.1 Applicability and exclusions

The procedures in clauses 6.5 apply in general to all procedures described in clause 9, clause 10, clause 12 and clause 13 with the exception that the confidentiality and integrity protection procedures for the registration and service authorisation procedures are described in clause 7.

6.5.1.2 Performing XML content encryption

Whenever the MCData UE includes XML elements or attributes pertaining to the data specified in clause 4.6 in SIP requests or SIP responses, the MCData UE shall perform the procedures in clause 6.5.2.3.1.

Whenever the MCData server includes XML elements or attributes pertaining to the data specified in clause 4.6 in SIP requests or SIP responses, the MCData server shall perform the procedures in clause 6.5.2.3.2, with the exception that when the MCData server receives a SIP request with XML elements or attributes in an MIME body that need to be copied from the incoming SIP request to an outgoing SIP request without modification, the MCData server shall perform the procedures specified in clause 6.5.2.5.

NOTE: The procedures in clause 6.5.2.3.1 and clause 6.5.2.3.2 first determine (by referring to configuration) if confidentiality protection is enabled and then call the necessary procedures to encrypt the contents of the XML elements if confidentiality protection is enabled.

6.5.1.3 Performing integrity protection on an XML body

The functional entity shall perform the procedures in this clause just prior to sending a SIP request or SIP response.

1) The MCData UE shall perform the procedures in clause 6.5.3.3.1; and

2) The MCData server shall perform the procedures in clause 6.5.3.3.2.

NOTE: The procedures in clause 6.5.3.3.1 and clause 6.5.3.3.2 first determine if integrity protection of XML MIME bodies is required and then calls the necessary procedures to integrity protect each XML MIME body if integrity protection is required. Each XML MIME body has its own signature.

6.5.1.4 Verifying integrity of an XML body and decrypting XML elements

Whenever the functional entity (i.e. MCData UE or MCData server) receives a SIP request or a SIP response, the functional entity shall perform the following procedures before performing any other procedures.

1) The functional entity shall determine if integrity protection has been applied to an XML MIME body by following the procedures in clause 6.5.3.4.1 and if integrity protection has been applied:

a) shall use the keying information described in clause 6.5.3.2 and the procedures described in clause 6.5.3.4.2 to verify the integrity of the XML MIME body; and

b) if the integrity protection checks fail shall not perform any further procedures in this clause;

2) The functional entity shall determine whether confidentiality protection has been applied to XML elements in XML MIME bodies in a SIP request or SIP response, pertaining to the data specified in clause 4.6, by following the procedures in clause 6.5.2.4.1, and if confidentiality protection has been applied:

a) shall use the keying information described in clause 6.5.2.2 along with the procedures described in clause 6.5.2.4.2 to decrypt the received values; and

b) if any decryption procedures fail, shall not perform any further procedures in this clause.

6.5.2 Confidentiality Protection

6.5.2.1 General

In general, confidentiality protection is applied to specific XML elements and attributes in XML MIME bodies in SIP requests and responses as specified in clause 4.6.

Configuration for applying confidentiality protection is not selective to a specific XML element or attribute of the data described in clause 4.6. If configuration for confidentiality protection is turned on, then all XML elements and attributes described in clause 4.6 are confidentiality protected. If configuration for confidentiality protection is turned off, then no XML content in SIP requests and SIP responses are confidentiality protected.

6.5.2.2 Keys used in confidentiality protection procedures

Confidentiality protection uses an XPK to encrypt the data which (depending on who is the sender and who is the receiver of the encrypted information) can be a CSK or an SPK as specified in clause 4.6. An XPK-ID (CSK-ID/SPK-ID) is used to key the XPK (CSK/SPK). It is assumed that before the procedures in this clause are called, the CSK/CSK-ID and/or SPK/SPK-ID are available on the sender and recipient of the encrypted content as described in clause 4.6.

The procedures in clause 6.5.2.3 and clause 6.5.2.4 are used with a XPK equal to the CSK and a XPK-ID equal to the CSK-ID in the following circumstances as described in 3GPP TS 33.180 [26]:

1) MCData client sends confidentiality protected content to an MCData server; and

2) MCData server sends confidentiality protected content to an MCData client.

The procedure in clause 6.5.2.3 and clause 6.5.2.4 are used with a XPK equal to the SPK and a XPK-ID equal to the SPK-ID when the MCData server sends confidentiality protected content to an MCData server.

6.5.2.3 Procedures for sending confidentiality protected content

6.5.2.3.1 MCData client

1) shall use the appropriate keying information specified in clause 6.5.2.2;

2) shall perform the procedures in clause 6.5.2.3.3 to confidentiality protect XML elements containing the content described in clause 4.6; and

3) shall perform the procedures in clause 6.5.2.3.4 to confidentiality protect URIs in XML attributes for URIs described in clause 4.6.

If the <confidentiality-protection> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "false", then sending confidentiality protected content from the MCData client to the MCData server is disabled, and content is included in XML elements and attributes without encryption.

6.5.2.3.2 MCData server

If the <confidentiality-protection> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "true" or no <confidentiality-protection> element is present in the MCData Service Configuration document, then sending confidentiality protected content from the MCData server to the MCData client is enabled. If the <allow-signalling-protection> element of the <protection-between-mcdata-servers> element is set to "true" in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] or no <allow-signalling-protection> element is present in the MCData Service Configuration document, then sending confidentiality protected content between MCData servers is enabled.

When sending confidentiality protected content, the MCData server:

1) shall use the appropriate keying information specified in clause 6.5.2.2;

2) shall perform the procedures in clause 6.5.2.3.3 to confidentiality protect XML elements containing the content described in clause 4.6, and

3) shall perform the procedures in clause 6.5.2.3.4 to confidentiality protect URIs in XML attributes for URIs described in clause 4.6.

If the <confidentiality-protection> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "false", then sending confidentiality protected content from the MCData server to the MCData client is disabled, and then content is included in XML elements and attributes without encryption.

If the <allow-signalling-protection> element of the <protection-between-mcdata-servers> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "false", then sending confidentiality protected content between MCData servers is disabled, and content is included in XML elements and attributes without encryption.

6.5.2.3.3 Content Encryption in XML elements

The following procedures shall be performed by an MCData client or an MCData server:

1) perform encryption as specified in W3C: "XML Encryption Syntax and Processing Version 1.1", https://www.w3.org/TR/xmlenc-core1/ [28] clause 4.3, using the "AES-128-GCM algorithm HMAC" as the encryption algorithm and the XPK as the key; and

2) follow the semantic for the element of the MIME body as described in Annex F of the present document, to include the encrypted content in the MIME body ensuring that the necessary XML elements required for confidentiality protection are included as specified in 3GPP TS 33.180 [26].

6.5.2.3.4 Attribute URI Encryption

The following procedures shall be performed by an MCData client or an MCData server:

1) perform encryption as specified in [aes-gcm], using the "AES-128-GCM algorithm HMAC" as the encryption algorithm and the XPK as the key, with a 96 bit randomly selected IV; and

2) replace the URI to be protected in the attribute by a URI constructed as follows:

a) the URI schema is "sip:";

b) the first part of the userinfo part is the base64 encoded result of the encryption of the original attribute value;

c) the string ";iv=" is appended to the result of step b);

d) the base64 encoding of the IV (section 5 of IETF RFC 4648 [30]) is appended to the result of step c);

e) the string ";key-id=" is appended to the result of step d);

f) the base64 encoding of the XPK-ID according to 3GPP 33.180 [26] is appended to the result of step e);

g) the string ";alg=128-aes-gcm" is appended to the result of step f); and

h) the string "@" followed by the domain name for MC Services confidentiality protection as specified in 3GPP TS 23.003 [31] is appended to the result of step g).

6.5.2.4 Procedures for receiving confidentiality protected content

6.5.2.4.1 Determination of confidentiality protected content

The following procedure is used by the MCData client or MCData server to determine if an XML element is confidentiality protected.

1) if an XML element contains the <EncryptedData> XML element, then the content of the XML element is confidentiality protected; and

2) if an XML element does not contain the <EncryptedData> XML element, then the content of the XML element is.not confidentiality protected.

The following procedure is used by the MCData client or MCData server to determine if a URI in the XML attribute is confidentiality protected.

1) if an XML attribute is a URI with the domain name for MC Services confidentiality protection as specified in the 3GPP TS 23.003 [31], then the URI is confidentiality protected; and

2) if an XML attribute is a URI without the domain name for MC Services confidentiality protection as specified in the 3GPP TS 23.003 [31], then the URI is not confidentiality protected.

6.5.2.4.2 Decrypting confidentiality protected content in XML elements

The following procedure shall be performed by an MCData client or an MCData server to decrypt an individual XML element that has a type of "encrypted" within an XML MIME body:

1) if the <EncryptedData> XML element or any of its sub-elements as described in 3GPP TS 33.180 [26] are not present in the MIME body then send a SIP 403 (Forbidden) response with the warning text set to "140 unable to decrypt XML content" in a Warning header field as specified in clause 4.9, and exit this procedure. Otherwise continue with the rest of the steps;

2) perform decryption on the <EncryptedData> element as specified in W3C: "XML Encryption Syntax and Processing Version 1.1", https://www.w3.org/TR/xmlenc-core1/ [28] clause 4.4 to decrypt the contents of the <CipherValue> element contained within the <CipherData> element;

3) if the decryption procedure fails, then send a SIP 403 (Forbidden) response with the warning text set to "140 unable to decrypt XML content" in a Warning header field as specified in clause 4.9. Otherwise continue with the rest of the steps; and

4) return success of this procedure together with the decrypted XML element.

6.5.2.4.3 Decrypting confidentiality protected URIs in XML attributes

The following procedure shall be performed by an MCData client or an MCData server to decrypt a URI in an attribute in a XML document:

1) the value between ";iv=" and the next ";" provides the base64 encoded value of the 96 bit IV and the value between ";=key-id" and the next ";" defines the key which has been used for encryption, i.e. "CSK" or "SPK"; and

2) the original URI is obtained by decrypting the base64 encoded string between the "sip:" URI prefix and the next ";" using the "AES-128-GCM algorithm HMAC" as the decryption algorithm with IV and key as determined in step 1). This value replaces the encrypted URI as the value of the XML attribute.

6.5.2.5 MCData server copying received XML content

The following procedure is executed when an MCData server receives a SIP request containing XML MIME bodies, where the content needs to be copied from the incoming SIP request to the outgoing SIP request.

The MCData server:

1) shall copy the XML elements from the XML MIME body of the incoming SIP request that do not contain a <EncryptedData> XML element, to the same XML body in the outgoing SIP request;

2) for each encrypted XML element in the XML MIME body of the incoming SIP request as determined by clause 6.5.2.4.1:

a) shall use the keying information described in clause 6.5.2.2 to decrypt the content within the XML element by following the procedures specified in clause 6.5.2.4.2, and shall continue with the steps below if the encrypted XML element was successfully decrypted;

b) if confidentiality protection is enabled as specified in clause 6.5.2.3.2, then for each decrypted XML element:

i) shall re-encrypt the content within the XML element using the keying information described in clause 6.5.2.2 and by following the procedures specified in clause 6.5.2.3.3; and

ii) shall include the re-encrypted content into the same XML MIME body of the outgoing SIP request; and

c) if confidentiality protection is disabled as specified in clause 6.5.2.3.2, shall include the decrypted content in the same XML MIME body of the outgoing SIP request.

3) for each encrypted XML URI attribute in the XML MIME body of the incoming SIP request as determined by clause 6.5.2.4.1:

a) shall use the keying information described in clause 6.5.2.2 to decrypt the URI value of the XML attribute by following the procedures specified in clause 6.5.2.4.3, and shall continue with the steps below if the encrypted XML attribute value was successfully decrypted;

b) if confidentiality protection is enabled as specified in clause 6.5.2.3.2, then for each decrypted XML element:

i) shall re-encrypt the URI value of the XML attribute using the keying information described in clause 6.5.2.2 and by following the procedures specified in clause 6.5.2.3.4; and

ii) shall include the re-encrypted attribute value into the same XML MIME body of the outgoing SIP request; and

c) if confidentiality protection is disabled as specified in clause 6.5.2.3.2, shall include the decrypted value in the same XML MIME body of the outgoing SIP request.

6.5.3 Integrity Protection of XML documents

6.5.3.1 General

Integrity protection can be applied to a whole XML MIME body. When integrity protection is enabled, all XML MIME bodies transported in SIP requests and responses are integrity protected. The following XML MIME bodies used in the present specification in SIP signalling can be integrity protected:

– application/vnd.3gpp.mcdata-info+xml;

– application/vnd.3gpp.mcdata-mbms-usage-info+xml;

– application/vnd.3gpp.mcdata-location-info+xml;

– application/poc-settings+xml;

– application/resources-list+xml;

– application/vnd.3gpp.mcdata-affiliation-command+xml;

– application/pidf+xml; and

– application/xcap-diff+xml.

If integrity protection is enabled, and one or more of the XML MIME bodies complying to the types listed above are included in a SIP request or SIP response, then a MIME body of type application/vnd.3gpp.mcptt-signed+xml specified in 3GPP TS 24.379 [10] is included in the SIP request or SIP response containing one or more signatures pointing to those XML MIME bodies as illustrated in Figure 6.5.3.1-1.

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

Figure 6.5.3.1-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.

Configuration for applying integrity protection is not selective to a specific MIME body. If configuration for integrity protection is turned on, then all XML MIME bodies in SIP requests and responses are integrity protected. If configuration for integrity protection is turned off, then no XML MIME bodies in SIP requests and SIP responses are integrity protected.

6.5.3.2 Keys used in integrity protection procedures

Integrity protection uses an XPK to sign the data which (depending on who is the sender and who is the receiver of the signed information) can be a CSK or an SPK as specified in clause 4.6. An XPK-ID (CSK-ID/SPK-ID) is used to key the XPK (CSK/SPK). It is assumed that before the procedures in clause 6.5.3.3 and clause 6.5.3.4 are called, the CSK/CSK-ID and/or SPK/SPK-ID are available on the sender and recipient of the integrity protected content, as described in clause 4.6.

The procedures in clause 6.5.3.3 and clause 6.5.3.4 shall be used with a XPK equal to the CSK and a XPK-ID equal to the CSK-ID in the following circumstances as described in 3GPP TS 33.180 [26]:

1) MCData client sends integrity protected content to an MCData server; and

2) MCData server sends integrity protected content to an MCData client.

The procedure in clause 6.5.3.3 and clause 6.5.3.4 shall be used with a XPK equal to the SPK and a XPK-ID equal to the SPK-ID when the MCData server sends integrity protected content to an MCData server

6.5.3.3 Sending integrity protected content

6.5.3.3.1 MCData client

If the <integrity-protection> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "true" or no <integrity-protection> element is present in the MCData Service Configuration document, then sending integrity protected content from the MCData client to the MCData server is enabled, and the MCData client shall use the appropriate keying information specified in clause 6.5.3.2 and shall perform the procedures in clause 6.5.3.3.3 to integrity protect XML MIME bodies.

NOTE: Each XML MIME body is integrity protected separately.

If the <integrity-protection> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "false", then sending integrity protected content from the MCData client to the MCData server is disabled, and all XML MIME bodies are sent without integrity protection.

6.5.3.3.2 MCData server

If the <integrity-protection> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "true", or no <integrity-protection> element is present in the MCData Service Configuration document, then sending integrity protected content from the MCData server to the MCData client is enabled. If the <allow-signalling-protection> element of the <protection-between-mcdata-servers> element is set to "true" in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] or no <allow-signalling-protection> element is present in the MCData Service Configuration document, then sending integrity protected content between MCData servers is enabled.

When sending integrity protected content, the MCData server shall use the appropriate keying information specified in clause 6.5.3.2 and shall perform the procedures in clause 6.5.3.3.3 to integrity protect XML MIME bodies.

NOTE: Each XML MIME body is integrity protected separately.

If the <integrity-protection> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "false", then sending integrity protected content from the MCData server to the MCData client is disabled, and all XML MIME bodies are sent without integrity protection.

If the <allow-signalling-protection> element of the <protection-between-mcdata-servers> element in the MCData Service Configuration document as specified in 3GPP TS 24.484 [12] is set to "false", then sending integrity protected content between MCData servers is disabled, and content is included in XML elements without encryption.

6.5.3.3.3 Integrity protection procedure

The following procedure shall be performed by the MCData client and MCData server to integrity protect the XML bodies defined by the MIME types listed in clause 6.5.3.1:

1) include a Content-Type header field set to "application/vnd.3gpp.mcptt-signed+xml" defined in 3GPP TS 24.379 [10];

2) for each of the MIME types defined in clause 6.5.3.1 where the content defined by these MIME types is to be integrity protected:

a) perform reference generation as specified in W3C: "XML Signature Syntax and Processing (Second Edition)", http://www.w3.org/TR/xmldsig-core [29] clause 3.1.1 using the SHA256 algorithm to produce a hash of the MIME body and continue with the procedures below if reference generation is successful;

b) perform signature generation as specified in W3C: "XML Signature Syntax and Processing (Second Edition)", http://www.w3.org/TR/xmldsig-core [29] clause 3.1.2 using the HMAC-SHA256 signature method and the XPK as the key and continue with the procedures below if signature generation is successful; and

3) follow the schema defined in Annex F.6.2 and the semantic described in Annex F.6.3 to create the application/vnd.3gpp.mcptt-signed+xml MIME body, defined in 3GPP TS 24.379 [10], containing signatures referring to the XML MIME bodies included in the SIP request or SIP response.

6.5.3.4 Receiving integrity protected content

6.5.3.4.1 Determination of integrity protected content

The following procedure is used by the MCData client or MCData server to determine if an XML MIME body is integrity protected.

1) if the <Signature> XML element is not present in the XML MIME body, then the content is not integrity protected; and

2) if the <Signature> XML element is present in the XML MIME body, then the content is integrity protected.

6.5.3.4.2 Verification of integrity protected content

The following procedure is used by the MCData client or MCData server to verify the integrity of an XML MIME body:

1) if the required sub-elements of the <Signature> as described in 3GPP TS 33.180 [26] are not present in the MIME body and if not present, are not known to the sender and recipient by other means, then the integrity protection procedure fails and exit this procedure. Otherwise continue with the rest of the steps;

2) perform reference validation on the <Reference> element as specified in W3C: "XML Signature Syntax and Processing (Second Edition)", http://www.w3.org/TR/xmldsig-core [29] clause 3.2.1;

3) if reference validation fails, then send a SIP 403 (Forbidden) response towards the functional entity with the warning text set to: "139 integrity protection check failed" in a Warning header field as specified in clause 4.9, and do not continue with the rest of the steps in this clause;

4) obtain the XPK using the XPK-ID in the received XML body and use it to perform signature validation of the value of the <SignatureValue> element as specified in W3C: "XML Signature Syntax and Processing (Second Edition)", http://www.w3.org/TR/xmldsig-core [29] clause 3.2.2;

5) if signature validation fails, then send a SIP 403 (Forbidden) response towards the functional entity with the warning text set to: "139 integrity protection check failed" in a Warning header field as specified in clause 4.9, and do not continue with the rest of the steps in this clause; and

6) return success of the integrity protection of the XML document passes the integrity protection procedure.