7A.1  Provision of content of communications

7A.1.A  Decryption for IMS Media Plane Security |R12|

This clause describes how the TSP can meet the national requirements in Clause 5.1.2 of TS 33.106 to deliver intercepted communications decrypted when the TSP uses TS 33.328 IMS Media Plane Security options. If an ICE, in TSP IMS network using Security options TS 33.328, allows interception of Content of Communication in clear then this clause does not apply.

If Session Description Protocol (SDP) Security Descriptions for Media Streams (SDES) is used, the DF2 shall identify the SDES keys from the SDP offer and SDP answer messages and provide the DF3 with the necessary SDES related parameters. In this case, the DF3 shall perform the decryption prior to delivery to the LEMF. For the CC delivered to the LEMF in a decrypted form, the DF2 shall remove the SDES keys when present from the SDP offer and SDP answer messages sent to the LEMF over HI2. The interface between the DF2 and DF3 to support the transfer of session keys is outside the scope of this specification.

When SDES is used in end-to-access edge mode, the P-CSCF shall intercept SDES keys from SDP messages and shall deliver them to the DF2.

If a Key Management Service (KMS) and Multimedia Internet KEYing ticket (MIKEY-TICKET) is used, the TSP may use the mechanism as defined in Clause 7A.7.1, which results in the DF2 receiving the sessions keys needed to decrypt the intercepted communications. Clause 7A.7.1 defines that the DF2 delivers the keys to the LEMF as IRI in order for the LEMF to decrypt the intercepted traffic.

If the network is to decrypt the content of communications prior to delivery to the LEMF via HI3, the DF2 shall provide the DF3 with the sessions keys as defined in Clause 7A.7.1 instead of to the LEMF. In this case, the DF3 shall perform the decryption prior to delivery to the LEMF. The interface between the DF2 and DF3 to support the transfer of session keys is outside the scope of this specification.

7A.2  Provision of IRI  Word‑p. 70

7A.2.1  Provision of IRI with SIP messaging |R12|

SIP messaging is reported as Intercept Related Information for the interception of multi-media service. As shown in figure 22 below, all SIP messages executed on behalf of a target are subject to intercept at the S-CSCF and Optionally P-CSCF. Based upon network configuration, the ADMF shall provision P-CSCFs, or S-CSCFs, or both P-CSCFs and S-CSCFs with SIP URI, TEL URI, or IMEI target identifiers. For Non-Local ID interception, the target identifiers are SIP URI or TEL URI. These resulting intercepted SIP messages shall be sent to DF2 for mediation prior to transmittal across the HI2 interface.

For roaming scenarios, interception at the P-CSCF shall be Mandatory, in order to provide IRI Interception in the visited network, where the P-CSCF is located in the Visited Network. Where the P-CSCF is located in the Home Network, interception at the P-CSCF shall be Optional, subject to national regulation. When S8HR is the roaming architecture, the P-CSCF is located in the HPLMN. Refer to clause 20 for the description of related lawful interception capabilities.

[not reproduced yet]

Figure 22: Provision of Intercept Related Information for multi-media

When Non-Local ID interception is required for incoming calls, ICE shall trigger interception by target id in any of the SIP headers used to identify the calling party information and redirecting party information present in the incoming SIP message. The examples are: P-Asserted Id, From headers and History-Info, Diversion headers.

When Non-Local ID interception is required for outgoing calls, ICE shall trigger interception by target id in any of the SIP headers used to identify the called party information present in the outgoing SIP message. The examples are: Request URI and To headers.

7A.2.2  Provision of IRI with XCAP messages |R12|

The AS that store the XCAP data of the target shall intercept and transmit to the DF2 any XCAP based messages related to actions by the target, related to the supplementary service and other target's service settings, defined in TS 24.623:

• on the Ut interface,
• on other interface to any AS with XCAP server capability that uses XCAP protocol.

The DF2 will encapsulate the information as an IRI to the LEMF.

Every successful or unsuccessful IMS supplementary services setting modification management request and response between UEs and IMS service nodes, or from other access to the target's XCAP servers shall be reported. In case of IRI only, any filtering of XCAP messages based on operator policy or national regulation is for further studies.

7A.2.3  Provision of IRI with Diameter or MAP messages related to HSS |R13|  Word‑p. 71

7A.2.3.0  General

National regulations may require IRI produced by a Delivery Function 2 associated to the HSS.

HSS shall support LI based on SIP-URI, Tel-URI, IMPI.

IMSI shall be supported as target identity if it is available in the subscription data stored in the HSS and the association with IMS identities can be done.

IMEI and MSISDN shall be supported as target identities if the HSS is shared with access services (e.g. PS, EPS) and the association with IMS identities can be done.

Intercept Related Information (Events) are listed as follows:

• Serving System;
• When IMPU or IMPI is changed in a HSS subscriber record change
• Registration termination
• Location information request.

Table 7A.2.3.0 below shows the set of information that may be associated with the events if available. The events trigger the transmission of the information from the HSS to DF2.

Table 7A.2.3.0: Information Elements for HSS Event records

Element

Description

---

Observed IMPI or Tel URI or SIP URI

Target Identifier with the IMPI, Tel URI or SIP URI of the target (if available).

Observed IMSI

Target Identifier with the IMSI of the target.

Observed IMEI

Target Identifier with the IMEI of the target (if available).

Observed MSISDN

Target Identifier with the MSISDN of the target (if available).

Event type

Description which type of event is delivered: Subscriber record change, Serving System,

Registration Termination, location information request.

Event date

Date of the event generation in the HSS.

Event time

Time of the event generation in the HSS.

Network Code (Country Code included)

In case of roaming, the country code and the network code of the serving network, or of a third network in the

diameter message to or from the HSS (AVP name such as Visited-PLMN-Id)

Network Element Identifier

Unique identifier for the element reporting the ICE.

Reason of de-registration (Deregistration-Reason AVP, Reason-code AVP)

Serving System Identifier

Provides an identifier that allows the home network to identify the visited network.

Any Associated-Identities (AVP Name):

any change of any associated identities of the target

Other Public User Identities

Other IMPU or IMPI that was allocated to Target and will be deregistered (if available)

Requesting network identifier

The requesting network identifier PLMN id (Mobile Country Code and Mobile Network Code).

Requesting node identifier

The identifier of the node requesting location/routing information for a target to the HSS

Requesting node type

It indicates the type of node that requests the location of the target (if available)

---

7A.2.3.1  Serving system  Word‑p. 72

The Serving System report event is generated at the HSS during the IMS registration process, when the HSS has detected that the target has roamed.

In addition, the event shall be provided in case of mobility events between different access types, if they are visible at the HSS, unless they are already provided by the HSS itself at access level (e.g. PS, EPS).

Such events could be mainly triggered by Diameter messages such as:

• Through Cx interface, Query and Select Pull in case of command of User-Authorization-Request from I-CSCF to HSS: see clause A.2 of TS 29.228;
• Through Cx interface, AuthDataReq in case of command of Multimedia-Authentication-Request from S-CSCF to HSS: see clause A.2 of TS 29.228;
• Through Sh interface, Pull in case of User-Data-Request from AS (with interworking to AS from target) to HSS: see clause A.2 of TS 29.328.
• Through Cx interface, Server-Assignment-Request in case of command of S-CSCF to HSS (see clause A.2 of TS 29.228);
• Through SWx interface, Server-Assignment-Request in case of command of 3GPP AAA to HSS (see clause A of TS 29.273, and clause 5 of GSMA IR.61 [65]).

The elements of table 7A.2.3.1 will be delivered to the DF2 if available.

Table 7A.2.3.1: Information Elements for Serving System Event

Information Element

---

Observed MSISDN

Observed TEL URI

Observed SIP URI

Observed IMSI

Observed IMEI

Event Type

Event Time

Event Date

Network Element Identifier

Current Serving System Identifier (AVP name such as Visited-PLMN-Id)

Any other IMPU or IMPI of the target (if available)

---

7A.2.3.2  Subscriber record change  Word‑p. 73

This event will be only used to report when there is a change of association between IMSI, MSISDN/IMPU/IMPI/TEL URI/ SIP URI, or IMEI of the target. It is induced mainly by Subscriber Profile management by the HSS or the CSP administration tools through the HSS.

Such events could be mainly triggered by Diameter messages such as:

• Through Sh interface, Pull Resp in case of command of User-Data-Answer from HSS to AS, see clause A.2 of TS 29.328;
• Through Sh interface, Update Resp in case of command of Profile-Update-Answer from HSS to AS, see clause A.2 of TS 29.328;
• Through Sh interface, Subs-Notif Resp in case of command of Subscribe-Notifications-Answer from HSS to AS, see clause A.2 of TS 29.328;
• Through Sh interface, Notif Resp in case of command of Push Notification-Answer from AS to HSS, see clause A.2 of TS 29.328;
• Through Cx interface, Update_Subscr_Data Resp in case of command that update the target profile from S-CSCF to HSS. The message may include the elements, such as old and new IMSI or MSISDN/TEL URI/SIP URI or IMEI: see clause A.2 of TS 29.228;
• Through Cx interface, Push-Profile-Answer This message is sent by the HSS to S-CSCF to update profile on S-CSCF if profile is changed by administrator at HSS: see clause A.2 of TS 29.228;
• Through SWx interface, -Push-Profile-Request (PPR) in case of command of HSS to 3GPP AAA Server: see clause A of TS 29.273.

The elements of table 7A.2.3.2 will be delivered to DF2, if available.

Table 7A.2.3.2: Information Elements for Subscriber Record Change Event

Information Element

---

New observed MSISDN

New observed TEL URI

New observed SIP URI

New observed IMSI

New Observed IMEI (if available)

New observed IMPI

Old observed MSISDN

Old observed TEL URI

Old observed SIP URI

Old observed IMSI

Old observed IMEI (if available)

Old observed IMPI

Event Type

Event Time

Event Date

Network Element Identifier (HSS id...)

Other update: carrier specific.

---

7A.2.3.3  Registration Termination  Word‑p. 74

This event "Registration Termination" will be used to report to DF2 when HSS send to S-CSCF or 3GPP AAA Server. It is the equivalent of cancel location or purge to serving system in CS domain. This kind of event is induced by the registration of the target. The event will be triggered by the following Diameter messages:

• Through Cx interface, Server-Assignment-Request indicating deregistration from S-CSCF to HSS: see clause A.2 of TS 29.228;
• Through Cx interface, Registration-Termination- Request from HSS to S-CSCF: see clause A.2 of TS 29.228;
• Through SWx interface, Server-Assignment-Request indicating deregistration from 3GPP AAA Server to HSS: see clause A of TS 29.273;
• Through SWx interface, Registration-Termination- Request from HSS to 3GPP AAA Server: see clause A of TS 29.273.

The elements of table 7A.2.3.3 such as the previous serving system of the target will be delivered to DF2.

Table 7A.2.3.3: Information Elements for Registration Termination Event

Information Element

---

Observed MSISDN

Observed TEL URI

Observed SIP URI

Observed IMSI

Observed IMEI

Event Type

Event Time

Event Date

Other Public User Identities

Other IMPU or IMPI that was allocated to Target and will be deregistered (if available)

Reason of de-registration (Deregistration-Reason AVP, Reason-code AVP) (if available)

Network Element Identifier (HSS Id...)

Previous serving system identifier (VPLMN id…) (if available)

---

7A.2.4  Provision of IRI for WebRTC |R13|  Word‑p. 75

The enhanced P-CSCF (eP-CSCF) shall adhere to all LI requirements pertaining to the P-CSCF described in clause 7A.2.1. Any additional LI requirements pertaining to the support of WebRTC Interworking, as specified in TS 23.228, that only apply to the eP-CSCF are described distinctly.

WebRTC Web Server Function (WWSF), if provided by the CSP, is an ICE that is used to copy and transmit via the DF to the LEMF the IP address and port used by the target as viewed by the WWSF. This IP address may be a public or private address depending on how the target accesses the WWSF.

WebRTC Authorisation Function (WAF), if provided by the CSP, is an ICE that creates a time-stamped authentication event associated with the target including relevant information such as the user's identity provided to the WAF.

Further details of the WWSF and WAF are FFS.

7A.3  Multi-media events

7A.3.0  General |R12|

• All SIP messages to or from a target, and all SIP messages executed on behalf of a target for multi-media session control are intercepted by the S-CSCF and Optionally P-CSCF and sent to DF2. The target identifier used to trigger the intercept will also be sent with the SIP message. This standard does not require nor prohibit redundant information from being reported to DF2.
  • Where a CSCF which provides lawful interception makes changes to a SIP message, sent to or from or executed on behalf of a target then the CSCF shall report both the original message and the modified message to the DF2.
  • Where a CSCF which provides lawful interception changes identities within a SIP message ( e.g. IMPI/IMPU changes or due to call forwarding etc.) and the new identity is the target, then both the original and modified SIP messages shall be reported to DF2.
  • Where a CSCF which provides lawful interception changes identities within a SIP message (e.g. IMPI/IMPU changes or due to call forwarding etc.) and the new identity is not the target, then both the original and modified SIP messages shall be reported to DF2.
• P-CSCF event reports may be redundant with S-CSCF event reports when the P-CSCF and S-CSCF reside in the same network, however, this standard does not require nor prohibit redundant information from being reported to DF2.
• Non-Local ID interception will be made by S-CSCF or P-CSCF (optional in a non-roaming case, and mandatory in the roaming case when LBO approach is used as the roaming architecture). As national option, the interception functions may also be provided by the IBCF or MGCF for a non-roaming case. Of the two approaches S-CSCF/P-CSCF Vs IBCF/MGCF used for non-roaming case, only one approach is required to be supported within a CSP's network. With S8HR as the roaming architecture, the Non-Local ID interception in the VPLMN will be made by the LMISF (see clause 20).
• For interception of incoming calls of Non-Local ID, any of the SIP headers used to identify the calling party information and redirecting party information present in the incoming SIP message. The examples are: P-Asserted Id, From headers and History-Info, Diversion headers.
• For interception of outgoing calls of Non-Local ID, any of the SIP headers used to identify the called party information present in the outgoing SIP message. The examples are: Request URI and To headers.
• The IRI should be sent to DF2 with a reliable transport mechanism.
• Correlation for SIP to bearer shall be supported within the domain of one provider.
• An intercepted SIP event sent to DF2 is shown below:
  • Observed SIP URI
  • Observed TEL URI
  • Observed IMEI (Not in the case of Non-Local ID interception)
  • Event Time and Date
  • Network element identifier
  • SIP Message Header
  • SIP Message Payload
  • VPLMN ID
• All IMS XCAP messages to or from a target for multi-media or supplementary services are intercepted by the AS, or the group of AS in charge to transmit, manipulate and store any IMS XCAP of that target. The data have to be transmitted either "en clair" or encrypted with all elements to let the LEMF decrypt the data. The generated IRI should be sent in any case to DF2.
  1. other data (XCAP management and the XCAP documents modification by the target) to be transmitted but related to other multimedia services;
  2. the case of XCAP messages that are based on different interfaces than Ut interface;
  3. the specific architecture related to encrypted data;
  4. Detailed XCAP events, related to authentication.
• An intercepted XCAP report sent to DF2 is shown below:
  • Observed SIP URI or Tel URI, based on XUI (described in IETF RFC 4825 [56]) or information in the XCAP payload (if available).
  • Observed XUI or any other identities (if available).
  • Event Time and Date.
  • Network element identifier.
  • XCAP Message (the entire elements of the HTTP Header and the XCAP payload).

The interpretation of XCAP messages, such as HTTP request through the Ut interface between the target's UE and related XCAP server may sometime be insufficient to let the LEA to understand what was modified as directed by the UE, therefore a later HTTP response is needed to understand the success or failure of the request.

• Specific Diameter messages, to or from or related to a target, are intercepted by the HSS in charge of that target. The generated IRI should be sent in any case to DF2. Events and IRI are described below:
• Such events are:
  • Serving System;
  • When IMPU or IMPI is changed in a HSS subscriber record change;
  • Registration termination
  • Location information request.
• Contents of such IRI report related to HSS sent to DF2, is shown below:
  • Observed SIP URI or Tel URI or IMSI;
  • Observed any other identities (if available);
  • Event Time and Date;
  • Network element identifiers;
  • Network Identifier (if available and only in case of roaming)
  • Target profile or data elements (if available).

7A.3.1  Mid IMS Session Interception |R12|  Word‑p. 77

7A.3.1.0  General

Mid IMS Session interception functionality applies in addition to other IMS LI functional requirements as defined in section 7A.

Where LI is activated on a target within a CSCF after an IMS session has already been established the CSCF shall do one of the following;

• Where the CSCF has stored the media session information which occurred prior to the interception activiation, the CSCF shall provide a "start of interception with IMS session" event message, to the DF2/MF over the X2 interface, including the parameter and information listed in table 7A.3.1, if available.
• Where the CSCF has not stored media session information which occurred prior to the interception activation, the CSCF shall report all future SIP messages which the CSCF is able to identify as associated with an ongoing target session. In this case, the event "start of interception with IMS session" is not applicable.

It is a national option whether the CSCF shall be mandated to store the necessary information to support reporting of session establishment parameters, in order to support mid IMS session interception, or whether the CSCF shall only report SIP messages which occur after the interception is applied and the CSCF is able to identify as related to an ongoing target session. If information is stored then it shall be possible to set a maximum storage time according to national and/or operator requirements.

Table 7A.3.1: Start of interception with established IMS session event

Information Element

---

Observed SIP URI

Observed TEL URL

Observed IMEI

Event type

Event Time

Event Date

Network Element Identifier

SIP message header offer (NOTE)

SIP message header answer (NOTE)

SDP offer

SDP answer

Correlation information

VPLMN ID

---

The SIP messages that carry the SDP offer and answer shall be reported. In case there are multiple SDP offers/answers during the session establishment, the SIP messages that carry the latest SDP offer/answer shall be provided.

The points above on requirements in this clause applicable to CSCF support of mid IMS Session interception, shall apply to IBCF which incorporate ICE for Non-Local ID interception.

7A.3.1.1  SDES Media Security  Word‑p. 78

If an SDES crypto attribute is included in the SDP, the DF2/MF forwards the "start of interception with IMS session" event message to the LEMF over HI2 without additional key processing.

If SDES mid session support is required then storing of media information as per 7A.3.1 is mandatory.

7A.4  Multi-media Call State Control Service Scenarios

7A.5  Push to talk over Cellular (PoC) |R6|

7A.6  SMS over IMS |R7|

7A.7  LI for KMS based IMS Media Security |R10|

7A.7.1  LI Architecture and functions

KMS based IMS media security is specified in TS 33.328. The present clause specifies LI architecture and functions needed to provide session encryption keys generated by the KMS to protect IMS media for a subscriber who is a target for interception in the IMS nodes. This section is applicable to the cases in which the KMS is under responsibility of the Operator providing the IMS network infrastructure. Other scenarios such as the one in which the KMS is run by an independent legal entity are outside the scope of this specification.

Figure 7A.7.1 shows the LI architecture for the case in which decryption is performed by the LEMF and a KMS is used to support IMS media security, with a Xk interface defined between the DF2/MF and the KMS, in addition to the interfaces and functional entities needed to support LI in the P-CSCF/S-CSCF.

[not reproduced yet]

Figure 7A.7.1: KMS Intercept configuration

When LI has been activated in the P/S-CSCF for a target, the node will report SIP messages events on the X2 interface, as specified in section 7.A and subsections. The DF2/MF shall extract from the intercepted SIP signalling the information related to the encryption and send a request over the Xk interface to the KMS to derive the encryption keys; the request will carry also the reference to the ticket transferred by the SIP signalling between the parties involved in the communication. The KMS shall then, based on the information received from the DF2, resolve the ticket and provide the session keys to the DF2/MF over the Xk interface.

7A.7.2  Signalling over the Xk interfaces and LI events  Word‑p. 79

The following messages are defined over the Xk interface:

• get_keys
• get_keys_response

The message get_keys shall be sent by the DF2/MF to the KMS in order to ask the KMS to provide session keys for an ongoing communication.

The message get_keys_response shall be sent by the KMS to the DF2/MF in order to provide the session keys.

The message get_key_response defines a LI event provided by the KMS to the DF2/MF which shall then be sent by the DF2/MF to the LEMF in a proper IRI record over the HI2 interface.

Table 7A.7.2.1 provides the list of parameters, which shall be carried by the message get_keys, in order to transfer to the KMS the information, as specified in TS 33.328, needed to provide the session encryption keys:

Table 7A.7.2.1: Parameters and information in message get_keys

Information Element

---

Public KMS Identity of the target user

TRANSFER_INIT

TRANSFER_RESP

---

Upon reception of get_keys message, the KMS shall verify that the key management information is related to the targeted user.

A timer may be defined in the DF2/MF in order to specify the amount of time that the DF2/MF shall wait for the response from the KMS. If this timer expires, a failure indication shall be sent to the LEMF.

Table 7A.7.2.2 provides the list of parameters, which shall be carried by the message get_keys_response, in order to provide the DF2/MF with the session keys:

Table 7A.7.2.2: Parameters and information in message get_keys_response

Information Element

---

Crypto Session ID

Session key

Salt

Failure indication (optional)

---

With reference to table 7A.7.2.2, in case of failure in providing any of the decryption information, the KMS may provide a decryption failure indication.

Upon reception of get_keys_response message or in case of timer expiry, the following information shall be provided to the LEMF by the DF2/MF:

• Lawful interception identifier
• Observed target identity(ies)
• Correlation number (in order to correlate the keys to IMS session under interception at the CSCF(s))
• Event type (session encryption keys available)
• Crypto Session ID (if provided by the KMS)
• Session key (if provided by the KMS)
• Salt (if provided by the KMS)
• MediaSec key retrieval failure indication (in case of e.g. timer expiry, or failure indication received from the KMS).

7A.7.3  Cooperating KMSs  Word‑p. 80

As specified in TS 33.328, in some scenarios the parties involved in an encrypted IMS based communication may use two different KMSs. In these cases, no additional LI specific signalling between the KMSs shall take place. The KMS may need to cache the session keys retrieved as result of the ticket resolution for possible LI needs at later stage.

7A.7.4  Security

Xk interface and its configuration shall only be accessible to authorized personnel.

The Xk interface shall have strong integrity and confidentiality protection. The Xk interface shall be protected by TLS unless protected by IPsec for LI purposes. TLS and certificate profiling shall be according to TS 33.310; IPsec profiling shall be according to TS 33.310 and TS 33.210.

7A.7.5  Start of interception for an already established IMS media secured session |R12|

This function is invoked when LI is activated in the network for a target who has already established an IMS session with secure media.

In order to provide information needed to decrypt the content of communication, the LI function in the CSCFs needs to have access to SDP information and SIP headers exchanged in the SIP signalling between the parties during the IMS session setup for possible later retrieval in case LI is activated during the ongoing session.

With reference to fig. 7A.7.1, if LI is activated by the ADMF over the X1_1 interface for a target, the CSCF shall check if the given target has an ongoing IMS media secured session. In this case, the CSCF shall provide a "Start of interception with established IMS session" event message to the DF2/MF over the X2 interface, as specified in section 7A.3.1.

Upon reception of Start of interception with established IMS secure session event, the DF2/MF shall check if a MIKEY-TICKET is included in the SDP. In this case the DF2/MF, in addition to forwarding the event to the LEMF over HI2, shall contact the KMS to resolve the ticket and retrieve the session keys and additional encryption related information as specified in in section 7A.7.2.

7A.8  IMS IMEI Interception |R11|  Word‑p. 81

The use of Instance ID in TS 24.229 is mandatory in IMS in order to support IMEI based LI in the CSCF. The CSCF is required to have access to the Instance IDs for all active IMS registrations regardless of whether LI has been requested prior to UE registration for a given IMEI. The CSCF shall be responsible for extracting the IMEI from the Instance ID where required for a specific target interception and providing the IMEI to the DF2. The IMEI (when available) shall be provided by the CSCF to the DF2 for all intercepted communication regardless of whether the IMEI or another identifier has been used as the target for interception.

Based on the national regulations, IMEI-based LI shall be possible for IMS sessions originated from, or terminated to, the UE with that IMEI.

7A.9  Void