3GPP Technical Document Summary: LS Reply on LI Requirements on IMS Data Channel

Document Information

• Source: SA3
• Target Groups: SA2, SA3-LI (CC: SA4, CT1)
• Meeting: SA3#124 (Wuhan, China, October 2025)
• Document Number: S3-253806
• Release: Rel-18
• Work Item: NG_RTC_SEC

Overall Context

This document is an LS reply from SA3 to SA2 regarding Lawful Intercept (LI) requirements for IMS Data Channel. SA3 provides feedback on three specific scenarios identified by SA2 concerning LI implementation challenges.

Technical Contributions by Scenario

Scenario 1: Roaming Cases with S8HR/N9HR Model

Issue Raised by SA2:
How can VPLMN decrypt Data Channel content when UE is in roaming state?

SA3 Position:
SA3 identifies significant security concerns with the proposed approach:

• Current Constraint: S8HR/N9HR are direct interfaces between roaming UE and HPLMN, and LI requirements imply these interfaces should not be confidentiality protected
• Technical Possibility: VPLMN could access DC content copy without confidentiality protection by using DTLS1.2 with NULL cipher
• Strong Recommendation Against NULL Cipher:
• NULL cipher not possible in DTLS1.3 and not recommended in DTLS1.2
• DTLS1.3 is recommended from Rel-19 onwards
• Security downgrade must be applied to all HPLMN UEs to avoid LI detectability
• Conflicts with regulatory requirements (e.g., EU Cyber Resilience Act) mandating state-of-the-art encryption for data in transit and storage by default

Scenario 2: Interoperability Between CSPs and P2P Direct Communications

SA2 Analysis:
- HTTP Proxy Mode: P2A and P2A2P Data Channels terminated in MF, which can provide decrypted DC content copy for LI
- DC Application Proxy Mode: Serving IMS network can anchor P2P Data Channel of target UE in MF for LI support
- UDP Proxy Mode: LI requirements cannot be fulfilled

SA3 Feedback:
- Clarification Request: According to TS 23.228, "DC Application Proxy" is only applicable when network initiates P2P session
- Open Question: SA3 requests clarification whether SA2 considers "DC Application Proxy" applicable for UE-initiated P2P sessions for LI purposes

Scenario 3: Interoperability Between CSP with and Without IMS Data Channel

SA2 Analysis:
- When target UE uses IMS without Data Channel feature, interworking between DCMTSI UE and MTSI UE occurs
- IMS DC content from DCMTSI UE terminated in MF or DC AS
- MF/DC AS supports interworking with MTSI UE via IMS video flow or other mechanisms (SMS, HTTP via Internet DN)
- Existing LI specifications assumed sufficient for these interworking scenarios
- No gaps identified by SA2

SA3 Position:
Since SA2 identified no gaps, SA3 will not explore these scenarios further.

Actions Requested

SA3 requests:
1. To SA2 and SA3-LI: Consider the security concerns raised for Scenario 1
2. To SA2: Provide clarification on the question regarding Scenario 2 (applicability of DC Application Proxy for UE-initiated P2P sessions)

Key Technical Implications

• Security vs. LI Trade-off: The document highlights fundamental tension between LI requirements and modern security best practices
• DTLS Version Migration: Transition from DTLS1.2 to DTLS1.3 eliminates NULL cipher option, creating architectural challenges for LI
• Regulatory Compliance: EU CRA requirements conflict with LI approaches requiring weakened encryption
• Proxy Architecture Limitations: Different MF proxy modes have varying LI capabilities, with UDP Proxy mode unable to support LI requirements