TDoc: S4-260025

1) Technical Accuracy

1.1 Incorrect/unclear document identifiers and scope

• Title mismatch: The contribution is labeled S4-260025 but the content is a “Summary of S3-254551”. If this is intended as an S4 document, the relationship between S4-260025 and S3-254551 should be explicit (e.g., “S4-260025 contains S3-254551 for information” or “S4-260025 summarizes S3-254551”). As written, it is confusing and risks mis-tracking in the meeting records.


• LS references appear inconsistent: You cite “SA2’s LS (S3-254015/S2-2509593)”. An LS from SA2 would normally be tracked in SA2 (S2-…) and received/registered in SA3 (S3-…). That’s plausible, but the pairing should be explained (e.g., “received in SA3 as S3-254015, originating from SA2 as S2-2509593”). Right now it reads like two unrelated numbers.

1.2 Questionable claim: “fully specified” / “completion of Rel-19 security requirements”

• The statement that “security aspects … have been fully specified in normative Annex R of TS 33.328” is too strong unless you explicitly delimit what “security aspects” means (e.g., authentication, key management, media protection, identity, authorization, privacy, interop, lawful intercept considerations, etc.).


• TS 33.328 is typically a security specification for a particular service domain; claiming that Annex R alone “completes Rel-19 security requirements” for “IMS avatar communication” may be incomplete if other specs are involved (e.g., IMS security baseline in TS 33.203, SIP/IMS security procedures, media security, identity/privacy, certificate handling, etc.). At minimum, the claim should be scoped to “the security normative work item deliverables under NG_RTC_SEC_Ph2 for IMS Avatar as captured in TS 33.328 Annex R”.

1.3 Potential inconsistency: “normative Annex R” and CR status

• You state “Final CR (CR084) … agreed at SA3#124” and “Expected approval: SA#110 plenary”.


• If the CR is “Final” and “agreed” at SA3, it still needs TSG SA approval; that part is fine. However, the document should clarify whether it is for approval at SA#110 or merely planned (and whether any remaining dependencies exist).


• Also, “Final CR” terminology can be ambiguous: in 3GPP practice, “Final” is a CR category, but it does not automatically mean the work is complete—only that the CR is in a final state for approval. The text conflates “Final CR agreed” with “work completed”.

1.4 Work item naming and traceability

• “NG_RTC_SEC_Ph2” is plausible, but the document provides no WI identifier (e.g., SP-xxxx) or a link to the SA work plan. Without that, the claim is hard to verify and weak from a process/traceability standpoint.

2) Completeness

2.1 Missing technical substance for SA2 consumption

As a reply LS summary, it may be acceptable to be short, but it is missing key information SA2 needs to act:

- What exactly is covered in Annex R (high-level bullets): threat model assumptions, security objectives, procedures, interfaces, and whether it covers both control plane and media plane aspects.

- Dependencies on SA2 architecture: Are there any assumptions about IMS avatar signaling, media transport, identity binding, or network functions that SA2 must ensure?

- Any open issues / residual risks: Even if normative work is “complete”, there may be known limitations, deferred items, or implementation notes.

2.2 Missing references and cross-spec alignment

• Only TS 33.328 Annex R is referenced. If IMS avatar communication relies on other security specs (likely), the LS should point to:


• TS 33.203 (IMS security) and any relevant clauses impacted/assumed.


• Any relevant key management / media security specs (depending on whether SRTP/DTLS-SRTP, MIKEY, or other mechanisms are used in the avatar context).


• Any privacy/identity specs if avatars involve user representation, metadata, or biometric-like data.


• If SA2 asked specific questions in S3-254015/S2-2509593, the reply should explicitly map question → answer. The current text does not demonstrate that SA3 addressed SA2’s concerns; it only states completion.

2.3 Missing CR details

• “CR084” is mentioned without:


• CR title


• affected version/release


• summary of changes


• whether it introduces new requirements on UE/IMS core
  
  This makes it hard for SA2 to understand impact.

3) Impact Assessment

3.1 Impact on specifications

• If Annex R introduces new normative security procedures, it may affect:


• IMS procedures (SIP signaling security, authentication, authorization)


• Media security (if avatar streams are treated as media)


• Interworking with existing IMS services and NG RTC features


• The document does not assess whether SA2 specs need updates (e.g., new parameters, new SDP attributes, new SIP headers, new policy control hooks, new identifiers).

3.2 Impact on implementations

• “Security work completed” can imply implementers should now implement Annex R. But the LS does not indicate:


• Whether the solution is backward compatible


• Whether it requires new credentials, new key derivations, new certificate validation, or new trust anchors


• Whether it impacts performance (e.g., additional handshakes, crypto overhead) or latency (important for real-time avatar use)


• Without this, SA2 and implementers cannot gauge rollout complexity.

3.3 Interoperability and deployment impact

• If the security solution introduces optional features, profiles, or negotiation, SA2 needs to know mandatory-to-implement vs optional to avoid fragmentation. The LS does not mention any profile/optionality.

4) Feasibility

4.1 Practical implementability not demonstrated

• The document provides no evidence that Annex R procedures are implementable within typical IMS/UE constraints:


• Key management feasibility (UE capabilities, SIM/USIM involvement, certificate storage)


• Compatibility with existing IMS security associations


• Handling of roaming, interconnect, and multi-operator trust


• If the avatar communication involves new media types or metadata, feasibility depends on how they are protected and negotiated; none of this is summarized.

4.2 Process feasibility: timing and approvals

• “Agreed at SA3#124” and “expected approval at SA#110” suggests the work is near completion, but the LS should state:


• Whether any parallel CRs exist in other specs


• Whether any late objections or pending alignment with SA2 remain
  
  Otherwise, SA2 may proceed assuming stability when changes could still occur.

5) Weaknesses

5.1 Over-reliance on a single statement of completion

• The core argument is essentially: “Annex R exists; therefore security is done.” This is weak because it does not:


• Demonstrate coverage of SA2’s concerns


• Provide a checklist of security aspects addressed


• Identify assumptions and constraints

5.2 Lack of traceability and verifiability

• No clause numbers, no CR title, no WI/SP reference, no version of TS 33.328, no link to the SA3 decision record. This makes the contribution hard to audit.

5.3 No explicit request to SA2 beyond “take into account”

• “Take the completion status into account” is vague. SA2 typically needs actionable guidance:


• “No further action needed”


• or “Please align architecture/spec X with security assumptions Y”


• or “Please reference TS 33.328 Annex R clause Z in your spec”
  
  The current wording risks being ignored or misinterpreted.

6) Suggestions for Improvement

6.1 Fix identifiers and improve clarity

• Explicitly state the relationship between S4-260025 and S3-254551 (attach, summarize, or forward).


• Clarify LS numbering: “Originating LS: S2-2509593; registered in SA3 as S3-254015”.

6.2 Provide a minimal technical summary of Annex R

Add 5–10 bullets summarizing what Annex R normatively specifies, for example:

- Security objectives and threat assumptions for IMS avatar communication

- Authentication/authorization model (reuse of IMS AKA? additional authorization?)

- Key establishment and media protection approach

- Integrity/confidentiality requirements for avatar-related signaling and media

- Privacy considerations (avatar metadata, user identifiers)

- Interop/negotiation and fallback behavior

6.3 Add traceability details

Include:

- TS 33.328 version and release

- CR084 title, affected clauses, and a 2–3 line change summary

- WI identifier (SP number) for NG_RTC_SEC_Ph2

6.4 Be precise about “completion”

Replace “fully specified” with scoped language, e.g.:

- “SA3 has completed the normative security specification deliverables for IMS Avatar communication under NG_RTC_SEC_Ph2, captured in TS 33.328 Annex R (CR084 agreed in SA3#124, pending SA#110 approval).”

Also state whether any non-normative guidance, test specs, or remaining study items exist.

6.5 Provide explicit actions for SA2

Depending on the intent, propose concrete actions such as:

- “SA2 to reference TS 33.328 Annex R clause R.x in the IMS Avatar stage-2 spec”

- “SA2 to ensure architecture supports [specific security assumption], e.g., binding of avatar stream to authenticated IMS identity”

- “SA2 to confirm no additional security requirements beyond Annex R are needed”

6.6 Add an impact note

Even a short paragraph would help:

- Backward compatibility expectations

- Any new network/UE capabilities required

- Any expected deployment constraints (roaming, interconnect, certificate/trust)

Bottom line

As a process/status reply, the document is directionally fine, but it is too thin and over-claims completion without scoping, traceability, or actionable guidance. Strengthening the LS with a concise technical summary, explicit mapping to SA2 questions, and clear references (CR title/clause/version/WI) would materially improve its usefulness and reduce the risk of misalignment between SA2 architecture and SA3 security specifications.