Tdoc List
2022-11-23 15:41
Agenda | Topic | TDoc | Title | Source | Type | For | Avail | Treated | Decision | Wdrn | Replaced-by | Replaces |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Agenda and Meeting Objectives | S3‑223140 | Agenda | SA WG3 Chair | agenda | Yes |
YesThe WG Chair welcomed the attendees and thanked for their attendance after three years of remote meetings.
A video from the Toulouse mayor of Toulouse was shown. Mireille (Thales) gave the welcome speech on behalf of 3GPP.
| approved | No | |||
S3‑223143 | Process for SA3#109 | SA WG3 Chair | other | Yes |
Yes
| noted | No | |||||
S3‑223145 | Process and agenda planning for SA3#109 | SA WG3 Chair | other | Yes |
Yes
| noted | No | |||||
2 | Meeting Reports | S3‑223141 | Report from SA3#108e | MCC | report | Yes |
Yes
| approved | No | |||
S3‑223142 | Report for SA3#108e ad-Hoc | SA WG3 Chair | other | Yes |
Yes
| approved | No | |||||
S3‑223144 | Report from last SA | SA WG3 Chair | report | Yes |
YesChristine asked about stage 2 freeze dates and SA3 dependency on SA2. Suresh clarified that this dependency is well understood in SA2.
| noted | No | |||||
3 | Reports and Liaisons from other Groups | S3‑223148 | LS on clarification for UE_NOT_FOUND cause code for UP in CT1 | C1-226279 | LS in | Yes |
Yes
| replied to | No | |||
S3‑223317 | LS Reply on UE_NOT_FOUND cause code | InterDigital, Europe, Ltd. | LS out | Approval | Yes |
YesHelena (Ericsson): this LS is for Rel-18 and they have frozen the specifications in Rel-17.
It was decided to discuss this in the related CRs.
| revised | No | S3‑223903 | |||
S3‑223903 | LS Reply on UE_NOT_FOUND cause code | InterDigital, Europe, Ltd. | LS out | Approval | Yes |
Yes
| revised | No | S3‑223317 | |||
S3‑223149 | LS on user’s consent for EDGEAPP | C3-223780 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑223181 | Reply LS on user’s consent for EDGEAPP | S6-222555 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223620 | Reply LS on user’s consent for EDGEAPP (S3-223149) | Apple | LS out | Approval | Yes |
Yes
| merged | No | S3‑223904 | |||
S3‑223649 | [DRAFT] Reply LS on user’s consent for EDGEAPP | Ericsson | LS out | Approval | Yes |
Yes
| merged | No | S3‑223904 | |||
S3‑223482 | Reply LS on User Consent for EDGEAPP | Huawei, HiSilicon | LS out | Approval | Yes |
YesVodafone: user consent better left for regulators.
| revised | No | S3‑223904 | |||
S3‑223904 | Reply LS on User Consent for EDGEAPP | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| approved | No | S3‑223482 | |||
S3‑223162 | Reply LS on the user consent for trace reporting | R3-225250 | LS in | Yes |
YesEricsson didn’t agree with Apple's and Huawei's proposal.
| postponed | No | |||||
S3‑223229 | Reply LS to Reply LS on the user consent for trace reporting | Nokia, Nokia Shanghai Bell | LS out | Yes |
Yes
| revised | No | S3‑223905 | ||||
S3‑223905 | Reply LS to Reply LS on the user consent for trace reporting | Nokia, Nokia Shanghai Bell | LS out | - | Yes |
Yes
| noted | No | S3‑223229 | |||
S3‑223621 | Reply LS on the user consent for trace reporting (S3-223162) | Apple | LS out | Approval | Yes |
Yes
| merged | No | S3‑223905 | |||
S3‑223492 | Reply LS on the User Consent for Trace Reportings | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| merged | No | S3‑223905 | |||
S3‑223163 | LS on user consent of Non-public Network | R3-226006 | LS in | Yes |
YesQualcomm: user content not important if the user is not human.
Ericsson: better handle it next meeting. There is no reply submitted to this meeting.
The Chair commented that better not to postpone.
| postponed | No | |||||
S3‑223906 | Reply to: LS on user consent of Non-public Network | Qualcomm | LS out | approval | Yes |
Yes
| noted | No | ||||
S3‑223178 | LS on User consent for Application Detection | S2-2209973 | LS in | Yes |
YesEricsson: user consent not applicable here.
Huawei: check SA2's info. If the SUPI is connected the user consent is needed.
Interdigital agreed that user consent was needed.
Vodafone: we would end up pressing content for everything and I'm not sure we need to standardise this as it is done in the handset anyway.
| replied to | No | |||||
S3‑223454 | Reply LS on User consent for Application Detection | OPPO | LS out | Approval | Yes |
Yes
| merged | No | S3‑223907 | |||
S3‑223686 | Reply LS on User consent for Application Detection | Ericsson | LS out | Approval | Yes |
YesQualcomm supported Ericsson's proposal.
| revised | No | S3‑223907 | |||
S3‑223907 | Reply LS on User consent for Application Detection | Ericsson | LS out | Approval | Yes |
Yes
| approved | No | S3‑223686 | |||
S3‑223179 | Reply LS on User Consent Updating | S5-225321 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223151 | LS on Authentication Result Removal | C4-224418 | LS in | Yes |
YesNokia preferred Ericsson's view.
Huawei commented that SA3 could align with CT4.
Ericsson: SA3 didn’t see a need some years ago. Remove it from stage 3 to avoid CT's work and then SA3 checking it out.
BT: this is a security function without a stage 2 requirement. IT should be removed.
| postponed | No | |||||
S3‑223609 | Reply LS on autentication result removal | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| merged | No | S3‑223908 | |||
S3‑223833 | Reply LS on Authentication Result Removal | Ericsson | LS out | Approval | Yes |
Yes
| revised | No | S3‑223908 | |||
S3‑223908 | Reply LS on Authentication Result Removal | Ericsson | LS out | Approval | Yes |
Yes
| noted | No | S3‑223833 | |||
S3‑223152 | Reply LS on PLMN ID used in Roaming Scenarios | C4-224444 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑223165 | Reply LS On PLMN ID used in Roaming Scenarios | S2-2207391 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑223204 | Reply LS on PLMN ID used in Roaming Scenarios | Nokia, Nokia Shanghai Bell | LS out | Yes |
Yes
| noted | No | |||||
S3‑223909 | Reply LS on PLMN ID used in Roaming Scenarios | Nokia, Nokia Shanghai Bell | LS out | - | No |
Yes
| withdrawn | Yes | ||||
S3‑223153 | Reply LS on handling of the modification policy in the IPX and receiving SEPP | C4-224467 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223157 | LS to 3GPP - Hosted SEPP | GSMA | LS in | Yes |
Yes
| replied to | No | |||||
S3‑223386 | LS to GSMA DESS on SEPP certificates | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| revised | No | S3‑223910 | |||
S3‑223910 | LS to GSMA DESS on SEPP certificates | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑223386 | |||
S3‑223676 | Discussion paper on SEPP inter-domain certificate on N32 interface | Ericsson | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑223154 | LS on Indication of Network Assisted Positioning method | C4-224626 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223155 | Reply LS on Facilitating roaming adoption across 3GPP NPN deployments | C6-220475 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223183 | Reply LS on Facilitating roaming adoption across 3GPP NPN deployments | SP-220985 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223185 | Facilitating roaming adoption across 3GPP NPN deployment | WBA | LS in | Yes |
Yes
| noted | No | |||||
S3‑223156 | Completion of SGP.22 v3.0 | GSMA | LS in | Yes |
Yes
| noted | No | |||||
S3‑223159 | Re-use of CAPIF by ETSI MEC | ETSI ISG MEC | LS in | Yes |
Yes
| noted | No | |||||
S3‑223195 | Reply LS on Re-use of CAPIF by ETSI MEC | S6-223027 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223160 | Reply LS on null security algorithm | R2-2208832 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223161 | Reply LS on authenticity and replay protection of system information | R2-2208985 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑223166 | LS on protection of the URSP rules from HPLMN | S2-2207501 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑223472 | Reply LS about Protection of URSP rules from HPLMN | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| merged | No | S3‑223911 | |||
S3‑223801 | Reply to LS on protection of the URSP rules from HPLMN | Nokia, Nokia Shanghai Bell | LS out | Yes |
Yes
| merged | No | S3‑223911 | ||||
S3‑223740 | Discussion on protection of the URSP rules from HPLMN | Samsung | discussion | Discussion | Yes |
YesSamsung: no possibility of changing the access technology type would be the attack scenario here.
Qualcomm: Observation 1 not correct. VPLMN can change the traffic routing.
Vodafone: I don’t agree with observation 1.
Cable Labs: we support Qualcomm's proposal.
BT: The threat exists but there are easier ways for the VPLMN to override this. If we don’t trust the VPLMN to do this what do we trust it for? I don’t see the value of this one.
VPLMN can be trusted for URSP rules: Docomo, Cable Labs, Huawei, Qualcomm,Thales, Deutsche Telekom, BT, Vodafone,China Mobile, Charter communications.
VPLMN cannot be trusted, URSP rules need to be protected: Samsung, Interdigital, Nokia,Lenovo, Phillips.
BT commented that all operators are the ones who take the risk here, it’s them who decide who to trust.
| noted | No | ||||
S3‑223379 | Reply LS on protection of the URSP rules from HPLMN | Qualcomm Incorporated | LS out | Approval | Yes |
Yes
| revised | No | S3‑223911 | |||
S3‑223911 | Reply LS on protection of the URSP rules from HPLMN | Qualcomm Incorporated | LS out | Approval | Yes |
Yes
| approved | No | S3‑223379 | |||
S3‑223173 | LS on impact of URSP rule enforcement report to 5GC | S2-2209327 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑223622 | LS on impact of URSP rule enforcement report to 5GC (S3-223173) | Apple | LS out | Approval | Yes |
Yes
| merged | No | S3‑223912 | |||
S3‑223298 | Reply LS on impact to URSP rules enforcement report to 5GC | vivo | LS out | Approval | Yes |
YesORANGE: what’s the privacy issue?
Vivo: it can check how frequeht reports are.
Vodafone: UE reporting something because we don’t trust it and by doing that we have privacy concerns.
Google: Questions 1 and 3 are OK, but we see a privacy issue here. There is a very detailed profile for the UE. URSP is not known by the user,
Qualcomm: we don’t see the privacy issue here. The rules are provided by the operator, who knows what needs to be provided by the UE,
Huawei: we don’t see privacy issues in question 1. NAS signal is protected against eavesdroppers. We don’t see an issue in question 2 either.
Interdigital: we trust the UE for some things and we don’t trust the UE for other things. It's strange.
Vodafone: the UE can be trusted and such mechanism is not needed.
Google agreed that there was no issue to be fixed here. Misbehaving UE can be dealt with in RAN5.
| revised | No | S3‑223912 | |||
S3‑223912 | Reply LS on impact to URSP rules enforcement report to 5GC | vivo | LS out | Approval | Yes |
Yes
| noted | No | S3‑223298 | |||
S3‑223800 | Discussion paper on a way forward for LS on protection of the URSP rules from HPLM | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑223167 | Reply LS on Inter-PLMN Handover of VoLTE calls and idle mode mobility of IMS sessions | S2-2207697 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223184 | LS from NG to 3GPP SA3 on IMS Data Channel Security Mode | GSMA | LS in | Yes |
Yes
| replied to | No | |||||
S3‑223844 | Reply LS on the IMS Data Channel Security Mode | Ericsson | LS out | Approval | Yes |
YesNokia: LI aspects to be handled in SA3-LI?
BT: end to end would be an issue. IF you can turn it off or provide the keys it should be OK.
| revised | No | S3‑223913 | |||
S3‑223913 | Reply LS on the IMS Data Channel Security Mode | Ericsson | LS out | Approval | Yes |
Yes
| approved | No | S3‑223844 | |||
S3‑223169 | LS Reply on EAC Mode for NSAC | S2-2209260 | LS in | Yes |
YesHuawei clarified that there was no change in SA3 specs.
| noted | No | |||||
S3‑223170 | Response LS on Identifier availability for Lawful Interception during Inter-PLMN handover | S2-2209262 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223862 | Response LS on Identifier availability for Lawful Interception during Inter-PLMN handover | S3i220660 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223171 | Response LS on Clarifications for AF specific UE ID retrieval | S2-2209270 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223180 | Forward on S6-222332, LS on Network federation interface for Telco edge consideration | S6-222543 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑223584 | Reply LS on Network federation interface for Telco edge consideration | Huawei, HiSilicon | LS out | Approval | Yes |
YesEricsson had issues with point 3 to be taken offline.
Nokia had also issues with point 3.
| revised | No | S3‑223914 | |||
S3‑223914 | Reply LS on Network federation interface for Telco edge consideration | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| approved | No | S3‑223584 | |||
S3‑223174 | LS on Satellite coverage data transfer to a UE using UP versus CP | S2-2209684 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223176 | LS on Time Synchronization Status notification towards UE(s) | S2-2209876 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑223213 | Reply LS on Time Synchronization Status notification towards UE(s) | Nokia, Nokia Shanghai Bell | LS out | Information | Yes |
Yes
| revised | No | S3‑223915 | |||
S3‑223915 | Reply LS on Time Synchronization Status notification towards UE(s) | Nokia, Nokia Shanghai Bell,Ericsson | LS out | Information | Yes |
Yes
| noted | No | S3‑223213 | |||
S3‑223848 | Reply LS on Time Synchronization Status notification towards UE(s) | Ericsson | LS out | Approval | Yes |
YesHuawei needed time to consider this.
| merged | No | S3‑223915 | |||
S3‑223177 | Reply LS on User plane solution for 5GC information exposure to UE | S2-2209910 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223147 | 5G capabilities exposure for factories of the future - identified gaps | 5G-ACIA | LS in | Yes |
YesThe Chair commented that SA will answer to the GSMA. There was no time to gather all answers to 5G-ACIA so it was decided to postpone for the next meeting encouraging all parties interested in solve all these questions.
| postponed | No | |||||
S3‑223182 | LS on new work item X.5Gsec-ctrl: Security controls for operation and maintenance of 5G network systems | ITU-T SG17 | LS in | Yes |
Yes
| noted | No | |||||
S3‑223199 | TCG progress - report from TCG rapporteur | InterDigital, Inc. | other | Information | Yes |
YesAlec (Interdigital) presented this report.
1. TCG – Highlights
Publication of new or revised deliverables (incremental changes from the status reported at SA3#108-e)
• TCG Measurement and Attestation RootS (MARS) Library – publication Q4 2022
• TCG Component Class Registry – public review October 2022
• TCG Storage Component Class Registry – public review October 2022
• TCG PC Client Platform Physical Presence Interface – public review July 2022
• TCG DICE Endorsement Architecture for Devices – public review May 2022
• TCG EK Credential Profile for TPM 2.0 – public review March 2022
• TCG Cyber Resilient Module & Building Block Requirements – public review March 2022
• TCG Canonical Event Log Format – published February 2022
2. Meetings
• TCG Members Meeting Hybrid F2F (Vancouver, BC) 21-23 February 2022
• MP WG meets every Monday at 10-11 ET
• TMS WG meets every Monday and Friday at 12-13 ET
• CyRes WG meets every Wednesday at 11-12:30 ET
3. Conclusion
| noted | No | ||||
S3‑223612 | LS to inform about the new GSMA Task Force | GSMA | LS in | Yes |
YesIIT Bihlai: asked whether GSMA was considering the recommendations of NIST Post Quantum Competition in preparing the road-map to adoption of Post Quantum Cryptography in its task force.
ORANGEL we need chipmakers and manufacturers to participate in this task force (companies who are not GSMA members can be invited). Todor suggested to send them info on the SA3 study in the 256 bit-study.
ORANGE clarified that the roadmap of algorithms from different organizations like NIST would be the first step as an overview of the quantum computing work.
Apple:TR 33.801 has no information on the Quantum algorithms yet. Will the GSMA impact the work in SA3?
Vodafone: we have made progress since that TR. There is a collection of things that we can send them with a LS, including SAGE's work on 256-bit algorithms.
ORANGE: GSMA cannot change 3GPP's work, the decisions are taken here.
OPPO: what input from UE vendors? ORANGE replied that an assesment needed to be done on the impact on the devices by the UE vendors.
MCC commented that the TR was 3GPP internal only and it was important to clarify this to GSMA.ORANGE agreed and commented that GSMA had seen the TR already as it was a public document,
MCC commented that it had to be pointed out very carefully that the internal TR was only for information and nothing can be considered normative in them.
Apple: no necessary to reply, everything is public already.There are no questions for us. Apple objected to this LS.
NCSC: this information is useful for them.
| noted | No | |||||
S3‑223916 | Reply to: LS to inform about the new GSMA Task Force | ORANGE | LS out | approval | Yes |
Yes
| noted | No | ||||
S3‑223902 | Specification of the 256-bit air interface algorithms | ETSI SAGE | LS in | Yes |
YesKDDI was happy to trigger a Study Item based on this work.
IDEMIA: SA3's prefreence is AES rather than Rijvendel. Let’s ask SAGE to publish the details on AES as well.
MCC commented that ETSI needed to investigate how to share the work of SAGE as it was not clear whether this needed to be confidential. A registration with the French anuthorities needed to be done most likely as well, as ETSI would be the host of the algorithms. In the mean time a SID or a WID could be started in SA3 to use SAGE's output.
Apple: companies need to study this information internally. We need more time.
| postponed | No | |||||
4 | Work areas (Rel-18) |   | ||||||||||
4.1 | New WID on Security Assurance Specification for Management Function (MnF) | S3‑223533 | Editorial changes to the living document for MnF SCAS | Huawei, HiSilicon | other | Approval | Yes |
Yes
| revised | No | S3‑224121 | |
S3‑224121 | Editorial changes to the living document for MnF SCAS | Huawei, HiSilicon | other | Approval | Yes |
Yes
| approved | No | S3‑223533 | |||
S3‑223541 | Updates to clause 4.2 of MnF SCAS | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223567 | Living document for MnF SCAS | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| revised | No | S3‑224122 | |||
S3‑224122 | Living document for MnF SCAS | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| approved | No | S3‑223567 | |||
S3‑223571 | Updates to clause 4.3 of MnF SCAS | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| revised | No | S3‑224123 | |||
S3‑224123 | Updates to clause 4.3 of MnF SCAS | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223571 | |||
S3‑224163 | Draft TS 33.526 | Huawei | draft TS | Approval | Yes |
Yes
| approved | No | ||||
4.2 | New WID on SECAM and SCAS for 3GPP virtualized network products | S3‑223458 | Adding description about overview of vendor development and product lifecycle processes and test laboratory accreditation to clause 6.1 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑224080 | |
S3‑224080 | Adding description about overview of vendor development and product lifecycle processes and test laboratory accreditation to clause 6.1 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223458 | |||
S3‑223459 | Adding description about audit and accreditation of vendor development and product lifecycle processes to clause 6.2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑224081 | |||
S3‑224081 | Adding description about audit and accreditation of vendor development and product lifecycle processes to clause 6.2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223459 | |||
S3‑223460 | Adding description about Audit and accreditation of test laboratories to clause 6.3 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑224082 | |||
S3‑224082 | Adding description about Audit and accreditation of test laboratories to clause 6.3 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223460 | |||
S3‑223461 | Adding description about monitoring to clause 6.4 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223553 | Adding description about SCAS instantiation documents creation to clause 7.1 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223554 | Adding description about network product development process and network product lifecycle management to clause 7.2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223555 | Adding description about SCAS instantiation evaluation overview to clause 7.2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223556 | Adding description about content and process of SCAS instantiation evaluation to clause 7.2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑224083 | |||
S3‑224083 | Adding description about content and process of SCAS instantiation evaluation to clause 7.2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223556 | |||
S3‑223564 | Adding description about testing to clause 7.2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223572 | Adding description about self-declaration to clause 7.3 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223575 | Adding contents into clause 7.5 and 7.6 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223632 | Adding description about partial compliance and use of SECAM requirements in network product development cycle to clause 7.4 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑224084 | |||
S3‑224084 | Adding description about partial compliance and use of SECAM requirements in network product development cycle to clause 7.4 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223632 | |||
S3‑223633 | Adding missing content from last implementation | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223634 | Adding clause 4.4 in TR 33.927 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑224085 | |||
S3‑224085 | Adding clause 4.4 in TR 33.927 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223634 | |||
S3‑223637 | Adding clause 5 Generic assets and threats in TR 33.927 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223640 | Adding clause 6 in TR 33.927 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑224086 | |||
S3‑224086 | Adding clause 6 in TR 33.927 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223640 | |||
S3‑223642 | Proposal to add 4.1 in TS33.527 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑224096 | Draft TR 33.936 | China Mobile | draft TR | Approval | Yes |
Yes
| approved | No | ||||
S3‑224097 | Draft TR 33.927 | China Mobile | draft TR | Approval | Yes |
Yes
| approved | No | ||||
4.3 | New WID on Mission critical security enhancements phase 3 | S3‑223186 | [33.180] R18 MC client clarification | Motorola Solutions Danmark A/S | CR | Agreement | Yes |
Yes
| withdrawn | Yes | ||
4.4 | New WID on Security Assurance Specification (SCAS) for 5G Rel-17 Features | S3‑223933 | Adding non-Uu user plane text cases to TS 33.511 | Qualcomm Incorporated | draftCR | Agreement | Yes |
Yes
| approved | No | ||
S3‑223206 | Clarification for IPSec in UPF interfaces | Keysight Technologies UK Ltd | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑224089 | Clarification for IPSec in UPF interfaces | Keysight Technologies UK Ltd | draftCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223207 | Correction of requirement references in UPF test case | Keysight Technologies UK Ltd | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑223208 | Update gNB test case for UP integrity protection | Keysight Technologies UK Ltd | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223493 | New Test Case on UP IP policy selection in S1 Handover | Huawei, HiSilicon | other | Approval | Yes |
Yes
| approved | No | ||||
S3‑223494 | New Threat on Bidding down prevention for UP IP Policy | Huawei, HiSilicon | other | Approval | Yes |
Yes
| approved | No | ||||
S3‑223495 | New Test Case on Bidding down prevention for UP IP Policy | Huawei, HiSilicon | other | Approval | Yes |
Yes
| approved | No | ||||
S3‑223506 | living doc to TR33.926 | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| revised | No | S3‑224155 | |||
S3‑224155 | living doc to TR33.926 | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| approved | No | S3‑223506 | |||
S3‑223507 | living doc to TR33.216 | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| revised | No | S3‑224156 | |||
S3‑224156 | living doc to TR33.216 | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| approved | No | S3‑223507 | |||
S3‑223508 | living doc to TS33.117 | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223509 | Update requirement and add new test case to clause 4.2.3.4.3.1 | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223510 | Update requirement and add new test case to clause 4.2.3.4.3.2 | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223607 | add test case to include SNPN snenario in PLMNID verification | Huawei, HiSilicon | draftCR | Approval | Yes |
Yes
| noted | No | ||||
4.5 | New WID on Security Assurance Specification for the Authentication and Key Management for Applications (AKMA) Anchor Function Function (AAnF) | S3‑223205 | New SCAS test case for AUSF | Keysight Technologies UK Ltd | draftCR | Approval | Yes |
Yes
| noted | No | ||
S3‑223422 | Adding AKMA subscription and AKMA context asynchronization threats to TR 33.926 | ZTE Corporation | draftCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223423 | Security Assurance Requirement and Test for AKMA subscription data and AKMA context synchronization | ZTE Corporation | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223457 | Adding a test case of AKMA key strorage and update | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223674 | Adding AAnF critical assets and threats to TR 33.926 | China Mobile (Suzhou) Software | draftCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑224098 | Draft TR 33.537 | China Mobile | draft TR | Approval | Yes |
Yes
| approved | No | ||||
S3‑224135 | Living document for AAnF SCAS – draftCR to TR 33.926 | China Mobile | draftCR | Approval | Yes |
Yes
| approved | No | ||||
4.6 | New WID on SCAS for split-gNB product classes | S3‑223342 | Draft CR: Introducing split gNBs into TR 33.926 | Qualcomm Incoporated | draftCR | Approval | Yes |
Yes
| revised | No | S3‑224169 | S3‑222322 |
S3‑224169 | Draft CR: Introducing split gNBs into TR 33.926 | Qualcomm Incoporated | draftCR | Approval | Yes |
Yes
| approved | No | S3‑223342 | |||
S3‑223343 | Proposed text for gNB-CU part of draft CR to TR 33.926 | Qualcomm Incoporated | other | Approval | Yes |
Yes
| approved | No | S3‑221815 | |||
S3‑223344 | Proposed text for gNB-CU-CP part of draft CR to TR 33.926 | Qualcomm Incoporated | other | Approval | Yes |
Yes
| approved | No | S3‑221816 | |||
S3‑223345 | Add user plane threats for gNB-DU to the draft CR to TR 33.926 | Qualcomm Incoporated | other | Approval | Yes |
Yes
| approved | No | ||||
S3‑223346 | Correcting the threats references for the gNB-CU | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223347 | Adding user plane test cases for the gNB-CU | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223348 | Correcting the threats references for the gNB-CU-CP | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223349 | Adding test cases for the gNB-CU-CP | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223350 | Correcting the threats references for the gNB-CU-UP | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223351 | Adding test cases for the gNB-CU-UP | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223352 | Correcting the threats references for the gNB-DU | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223353 | Adding user plane test cases for the gNB-DU | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223354 | Adding non-501 test cases for the gNB-CU | Qualcomm Incoporated | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑224103 | Draft TR 33.742 | Qualcomm | draft TR | Approval | Yes |
Yes
| approved | No | ||||
4.7 | Service Based Architecture (Rel-15/16/17) | S3‑223203 | Clarification on N32-f connection establishment with TLS | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑223951 | S3‑221841 |
S3‑223951 | Clarification on N32-f connection establishment with TLS | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223203 | |||
S3‑223260 | Discussion on authorization issue in inter NF mobility | Nokia, Nokia Shanghai Bell | discussion | Information | Yes |
Yes
| noted | No | ||||
S3‑223261 | Clarification on authorization for inter NF mobility | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesEricsson: not needed. It can be done in CT3, CT4.
Mavenir: we support this CR. This doesn’t need a study.Not sure that the CR reflects the discussion paper.
The Chair asked if it was ageed that there was a problem here. Ericsson agreed but the question was for which group. Ericsson had an input for solving this issue in CT3,CT4.
| not pursued | No | ||||
S3‑223404 | Revise the pre-requisite of access token request | China Telecommunications | CR | Yes |
Yes
| agreed | No | |||||
S3‑223399 | Revise the pre-requisite of access token request(mirror) | China Telecommunications | CR | Yes |
Yes
| agreed | No | |||||
S3‑223590 | Discussion on notification URI disclosure in "Subscribe-Notify" scenarios | Huawei, HiSilicon | discussion | Discussion | Yes |
YesHuawei clarified that the issue can be solved by CT4 and identified by SA3.
Ericsson: there could be different solutions apart from this one and we would ike to discuss them in the next meeting.
| noted | No | ||||
S3‑223591 | LS on notification URI disclosure | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑223672 | Editor's note resolution on NF instance id in cert profile | Nokia, Nokia Shanghai Bell | CR | Yes |
YesHuawei: fine with the note, some rewording suggested.This had to be taken offline.
| agreed | No | |||||
S3‑223677 | Correct SCP certificate profile | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223678 | Correct SCP certificate profile | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223679 | Clarify SEPP intra-domain certificate profile | Ericsson, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesCableLAbs: roaming interface?
Ericsson: to be done later.
| agreed | No | ||||
S3‑223680 | Clarify SEPP intra-domain certificate profile | Ericsson, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223681 | Correct NF certificate profile | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223682 | SEPP to include and verify the source PLMN-ID | Ericsson, Mavenir, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesHuawei didn’t agree with the first paragraph.
Mavenir: CT4 approved this already.We have to include the PLMN id, this has arrived in GSMA.
Huawei still had concerns despite that.
Ericsson: this is coming from an approved draft CR.It should not be taken back.
NTT-Docomo: The deployment limitations are not detailed. They should be added here. Maybe with an editor's note.
Mavenir: GSMA is already using this information based on CT4, not SA3.
| revised | No | S3‑223953 | S3‑221998 | ||
S3‑223953 | SEPP to include and verify the source PLMN-ID | Ericsson, Mavenir, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑223682 | |||
S3‑223683 | SEPP to include and verify the source PLMN-ID | Ericsson, Nokia, Nokia Shanghai Bell, Mavenir | draftCR | Approval | Yes |
YesMCC clarified that this was already approved in a previous meeting, so it wasn’t necessary to resubmit it unless there were changes. It could be noted but it had to be taken into account that the content was approved before already.
| noted | No | S3‑221998 | |||
S3‑223684 | Clarification on access token requests for NF Producers of a specific NF type and token-based authorization for indirect communication with delegated discovery | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑223954 | |||
S3‑223954 | Clarification on access token requests for NF Producers of a specific NF type and token-based authorization for indirect communication with delegated discovery | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑223684 | |||
S3‑223709 | TargetNFServiceSetId to be part of access token claims | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesNokia: brought back because people thought this was a new feature when it is an alignment instead.
Ericsson: changes are on the wrong clause.
Huawei had issues with caoturing Service Set in the token.
This had to be taken offline.
| revised | No | S3‑223955 | S3‑221840 | ||
S3‑223955 | TargetNFServiceSetId to be part of access token claims | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223709 | |||
S3‑223398 | Revise the pre-requisite of access token request | China Telecommunications | CR | Yes |
Yes
| withdrawn | Yes | |||||
S3‑223825 | Clarification on N32-f connection establishment with TLS - SNPN use case | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| withdrawn | Yes | S3‑221841 | |||
4.8 | Security Aspects of Proximity based services in 5GS ProSe (Rel-17) | S3‑223409 | Figure CR in 6.3.3.3.2 of TS33.503 | China Telecom Corporation Ltd.,CATT | CR | Approval | Yes |
Yes
| merged | No | S3‑223956 | |
S3‑223552 | Update to UE-to-Network relay security procedures | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| merged | No | S3‑223956 | |||
S3‑223703 | Renaming 5GPRUK, 5GPRUK ID, PRUK and PRUK ID | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑223956 | |||
S3‑223956 | Renaming 5GPRUK, 5GPRUK ID, PRUK and PRUK ID | Ericsson,China Telecom, Huawei, HiSilicon,CATT | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223703 | |||
S3‑223368 | Corrections in privacy protection of 5G ProSe UE-to-Network relay procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| revised | No | S3‑223957 | |||
S3‑223957 | Corrections in privacy protection of 5G ProSe UE-to-Network relay procedure | Qualcomm Incorporated,eijing Xiaomi Mobile Software | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223368 | |||
S3‑223772 | Correction to privacy protection of UP-PRUK ID and RSC in DCR | Beijing Xiaomi Mobile Software | CR | Approval | Yes |
Yes
| merged | No | S3‑223957 | |||
S3‑223463 | Clarifies to the match report procedures under UE-to-Network relay scenario | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| merged | No | S3‑223958 | |||
S3‑223743 | Match Report in U2N Relay Discovery Security Procedure | Xiaomi Technology | CR | Approval | Yes |
Yes
| revised | No | S3‑223958 | |||
S3‑223958 | Match Report in U2N Relay Discovery Security Procedure | Xiaomi Technology,Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | S3‑223743 | |||
S3‑223427 | Add a Note to address the subscription synchronization between PAnF and UDM | ZTE Corporation | CR | Approval | Yes |
YesEricsson preferred this option to make it implementation dependent.
Supported by Nokia.
| not pursued | No | ||||
S3‑223429 | Clarification of subscription information in PAnF | ZTE Corporation | CR | Approval | Yes |
YesMCC commented that the reference to TS23.501 was missing.
This was revised to address Huawei comments.
| revised | No | S3‑223960 | |||
S3‑223960 | Clarification of subscription information in PAnF | ZTE Corporation | CR | Approval | Yes |
Yes
| agreed | No | S3‑223429 | |||
S3‑223573 | CR on Remote UE Authorization check before using 5GPRUK generate KNR_ProSe | Huawei, HiSilicon | CR | Yes |
YesInterdigital: we don’t see the need of this new interface, we prefer the ZTE version in 429 where an existing interface is impacted.
Ericsson didn’t support this CR.
| not pursued | No | |||||
S3‑223428 | Add functionality description of PAnF | ZTE Corporation | CR | Approval | Yes |
Yes
| revised | No | S3‑223961 | |||
S3‑223961 | Add functionality description of PAnF | ZTE Corporation,CATT | CR | Approval | Yes |
Yes
| agreed | No | S3‑223428 | |||
S3‑223671 | CR to TS33.503 PAnF definition and reference point to UDM | CATT | CR | Approval | Yes |
YesDepedent on 671.
| merged | No | S3‑223961 | |||
S3‑223430 | Add FC Value in 33.503 | ZTE Corporation | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑223705 | Nudm servcie operation correction | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑223962 | |||
S3‑223962 | Nudm servcie operation correction | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑223705 | |||
S3‑223822 | Discussion on RID used in ProSe | Nokia, Nokia Shanghai Bell | discussion | Endorsement | Yes |
YesInterdigitak: there is no routing id for PAnF.
Huawei disagreed to have separate IDs.
Ericsson agreed with Huawei and Interdigital. ZTE as well.
| noted | No | ||||
S3‑223823 | include RID of AUSF in DCR | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223824 | include RID of AUSF in CP PRUK ID | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223819 | Discussion on Serving Network Name used in ProSe | Nokia, Nokia Shanghai Bell | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑223820 | use relay UE SNN to generate AV for ProSe authentication | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223821 | use remote UE SNN to generate AV for ProSe authentication | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223316 | Handling of PRUK desynchronization issue with 5G ProSe UE-to-Network Relay | InterDigital, Europe, Ltd. | CR | Agreement | Yes |
YesQualcomm: this is better handled in CT1.
Interdigital: there is a security issue that we can handle.
| agreed | No | ||||
S3‑223462 | Clarifies to clause 6.3.5 to include the CP mechanism key identifier | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| merged | No | S3‑223956 | |||
S3‑223702 | Correction to authentication mechanism selection | Ericsson, Xiaomi | CR | Agreement | Yes |
Yes
| revised | No | S3‑224161 | |||
S3‑224161 | Correction to authentication mechanism selection | Ericsson, Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223702 | |||
S3‑223704 | Correcting the handling of synchronisation error | Ericsson | CR | Agreement | Yes |
YesQualcomm: no need to update the existing text.The problem is addressed already.
| revised | No | S3‑224133 | |||
S3‑224133 | Correcting the handling of synchronisation error | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223704 | |||
S3‑223706 | CP-PRUK refresh | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223742 | DDNFM Selection during U2N Relay Discovery Security Procedure | Xiaomi Technology, Ericsson | CR | Approval | Yes |
YesInterdigital had several issues, including some that may be under SA2's scope. This was taken offline.
| not pursued | No | ||||
S3‑223744 | Security Method Check during U2N Relay Discovery Procedure | Xiaomi Technology | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223745 | Updates to Key Definitions | Xiaomi Technology | CR | Approval | Yes |
YesQualcomm couldn’t agree with these changes.
Interdigital couldn’t agree either.
| not pursued | No | ||||
S3‑223315 | Alignment of Link Identifier Update (LIU) procedure | InterDigital, Europe, Ltd. | CR | Agreement | Yes |
YesQualcomm: this is not missing in the existent specification. It is already covered.
Interdiigta didn’t agree, the spec wasn't referring to the privacy related procedure.
Qualcomm needed to check the spec.
ZTE: this is existent in SA2 but not in SA3. Just one line referring to SA2.
Interdigital: the SA2 refers to us, it creates a loop.
| revised | No | S3‑224170 | |||
S3‑224170 | Alignment of Link Identifier Update (LIU) procedure | InterDigital, Europe, Ltd. | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223315 | |||
S3‑223318 | Resolution of Remote UE permanent identity in Remote UE Report procedure (CP) | InterDigital, Europe, Ltd. | CR | Agreement | Yes |
Yes
| not treated | No | ||||
S3‑223319 | Resolution of Remote UE permanent identity in Remote UE Report procedure (UP) | InterDigital, Europe, Ltd. | CR | Agreement | Yes |
Yes
| not treated | No | ||||
S3‑223320 | Discussion on Lawful Interception support for 5G ProSe Layer-3 UE-to-Network Relay | InterDigital, Europe, Ltd. | discussion | Endorsement | Yes |
Yes
| not treated | No | ||||
S3‑223321 | LS on support for Lawful Intercept target identities for 5G ProSe Remote UE | InterDigital, Europe, Ltd. | LS out | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223367 | LS on Source user info in Direct Communication Request in UE-to-Network Relay | Qualcomm Incorporated | LS out | Approval | Yes |
YesInterdigital: too late for Rel-17.
Huawei disagreed with this LS.
| noted | No | ||||
S3‑223431 | Allocate FC Value for 33.503 | ZTE Corporation | CR | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑223557 | Allocate FC Value for 33.503 | ZTE Corporation | CR | Approval | Yes |
Yes
| revised | No | S3‑224171 | |||
S3‑224171 | Allocate FC Value for 33.503 | ZTE Corporation | CR | Approval | Yes |
Yes
| agreed | No | S3‑223557 | |||
4.9 | All topics (Rel-15/16/17/18 ) | S3‑223164 | Reply LS on Security architecture for 5G multicast/broadcast services | S2-2207390 | LS in | Yes |
Yes
| replied to | No | |||
S3‑223172 | Reply LS on the impact of MSK update on MBS multicast session update procedure | S2-2209287 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑223527 | CR on control-plane procedure in MBS | Huawei, HiSilicon | CR | Approval | Yes |
YesQualcomm agreed with this proposal but had some minor wording comments.
MCC: number the Notes.
| revised | No | S3‑223917 | |||
S3‑223917 | CR on control-plane procedure in MBS | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| not pursued | No | S3‑223527 | |||
S3‑223528 | Reply LS on the impact of MSK update on MBS multicast session update procedure | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| revised | No | S3‑223918 | |||
S3‑223918 | Reply LS on the impact of MSK update on MBS multicast session update procedure | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| noted | No | S3‑223528 | |||
S3‑223365 | Clarification on 5G MBS user-plane procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| merged | No | S3‑223920 | |||
S3‑223529 | CR on authentication in user plane procedure in MBS | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| revised | No | S3‑223920 | |||
S3‑223920 | CR on authentication in user plane procedure in MBS | Huawei, HiSilicon,Qualcomm | CR | Approval | Yes |
Yes
| agreed | No | S3‑223529 | |||
S3‑223366 | Reply LS on Security architecture for 5G multicast/broadcast services | Qualcomm Incorporated | LS out | Approval | Yes |
Yes
| merged | No | S3‑223919 | |||
S3‑223530 | Reply LS on Security architecture for 5G multicast/broadcast services | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| revised | No | S3‑223919 | |||
S3‑223919 | Reply LS on Security architecture for 5G multicast/broadcast services | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| approved | No | S3‑223530 | |||
S3‑223266 | AKMA API enhancement based on the LS | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesQualcomm: SA3 decided to have the separate service for security isolation purposes.
Docomo: separate APIs makes sense.
| not pursued | No | ||||
S3‑223265 | LS reply on AKMA API | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| revised | No | S3‑223921 | |||
S3‑223921 | LS reply on AKMA API | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑223265 | |||
S3‑223424 | Add Context_Remove into table 7.1.1-1 | ZTE Corporation | CR | Approval | Yes |
YesEricsson: is this FASMO? Isn’t this OAM?
ZTE: we are open to discuss the relationship with OAM.
Huawei: this is not needed.Services to be consumed by MnF are not up to SA3.
ZTE: this is not a new service, it was missing in the table.
| not pursued | No | ||||
S3‑223425 | Add MnF in clause 6.6.1and 6.7 | ZTE Corporation | CR | Approval | Yes |
YesDependent on the previous CR.
| not pursued | No | ||||
S3‑223426 | Add one note about AKMA subscription data and AKMA context asynchronization in clause 6.6.1 | ZTE Corporation | CR | Approval | Yes |
YesNokia: I agree with the issue. This is also related with the OAM question on the previous CRs.
Huawei: the note seems to be a strict requirement, not appropriate.
| not pursued | No | ||||
S3‑223711 | AAnF sending GPSI to internal AKMA AF | China Mobile (Suzhou) Software | CR | Approval | Yes |
YesNokia: no need to introduce this conversion at the AAnF.
Qualcomm: we discussed this for long and it has been raised by Qualcomm. Some operators already said that they don’t want to provide the SUPI for security reasons.It can be a compromise to add this in Release 18 instead of Rel-17. This is needed as AKMA cannot be used in many services.
China Mobile: This should be a service requirement.
Verizon (remotely) supported China Mobile and Qualcomm.
Huawei supported this, it was needed.
Nokia: this is one more layer of trust. This will open other security issues.
| not pursued | No | ||||
S3‑223831 | KAF lifetime recommendations and Ua* protocol requirements | Ericsson | CR | Agreement | Yes |
YesLenovo: nor pursued, as this is studied in Rel-18 already.
Qualcomm: this clarification is welcome.
OPPO: we don’t support this because there is a study in Rel-18 already.
Huawei: this requires reformulation.
Samsung: we see multiple issues with maximizing the lifetime of KAF.
Lenovo: conclude the issue in Rel-18 and bring this CR back.
| not pursued | No | ||||
S3‑223646 | Rel-15 Correcting the OAuth 2.0 roles in CAPIF | Ericsson | CR | Agreement | Yes |
YesHuawei: remove first sentence.
Nokia needed some offline discussion for this as well.
| revised | No | S3‑223922 | |||
S3‑223922 | Rel-15 Correcting the OAuth 2.0 roles in CAPIF | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223646 | |||
S3‑223647 | Rel-16 Correcting the OAuth 2.0 roles in CAPIF | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑223923 | |||
S3‑223923 | Rel-16 Correcting the OAuth 2.0 roles in CAPIF | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223647 | |||
S3‑223648 | Rel-17 Correcting the OAuth 2.0 roles in CAPIF | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑223924 | |||
S3‑223924 | Rel-17 Correcting the OAuth 2.0 roles in CAPIF | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223648 | |||
S3‑223619 | CR on AES-GCM/GMAC in IMS SIP security | Apple | CR | Approval | Yes |
YesQualcomm: not convinved that in this use case there are multiple IP tunnels, so there are no issues here.
| revised | No | S3‑223925 | |||
S3‑223925 | CR on AES-GCM/GMAC in IMS SIP security | Apple | CR | Approval | Yes |
YesRevised due to file not being able to be opened.
| not pursued | No | S3‑223619 | |||
S3‑223588 | Addressing authentication and authorization for EDGE-9 | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑223650 | Correction and clarification in user consent requirements | Ericsson | CR | Agreement | Yes |
YesHuawei didn’t agree with the removal of the sentence. Let the operator decide.
Nokia: let's not use stage 3 arguments here.
Huawei: we will cause misalignment if we remove the requirement.
| not pursued | No | ||||
S3‑223777 | CR_33.501 R17 Remove the redundant part of Figure I.2.3.2-1 | Xiaomi Communication | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑223781 | CR_33.501 R17 Update step 15 of clause I.2.2.2.1 | Xiaomi Communication | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑223845 | Clarification on AF authorization for the NSACF notification procedure | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑223926 | |||
S3‑223926 | Clarification on AF authorization for the NSACF notification procedure | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑223845 | |||
S3‑223846 | Alignment of NSACF notification procedure with existing procedures | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223860 | Verification of NSSAIs for preventing slice attack | CableLabs, Ericsson, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesHuawei: the SBA study has this key issue for Rel-18, although this was presented in Rel-16 and Rel-17 already.
Nokia: the WID associated is coming for this meeting.
Mavenir: why cat-F?
Nokia: it's addressing a vulnerability.
It was commented that since there was an associated WID this could be cat-B.
Verizon supported this CR.
Conditionally agreed depending on the status of the WID for this meeting.
| agreed | No | ||||
S3‑223332 | Resolving the EN on CAA level ID during UUAA procedures | Qualcomm Incorporated | CR | Agreement | Yes |
YesLenovo preferred not to pursue this document.
Interdigital: step 7 is OK.
Qualcomm: just turning the editor's note into a note.
| not pursued | No | S3‑221827 | |||
S3‑223927 | Resolving the EN on CAA level ID during UUAA procedures | Qualcomm Incorporated | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑223333 | Resolving the ENs on CAA level ID during revocation | Qualcomm Incorporated | CR | Agreement | Yes |
YesLenovo didn’t agree with this CR.
This was taken offline.
| revised | No | S3‑223928 | S3‑221828 | ||
S3‑223928 | Resolving the ENs on CAA level ID during revocation | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | S3‑223333 | |||
S3‑223418 | Address ENs in revocation procedures | Huawei, HiSilicon | CR | Agreement | Yes |
YesLenovo had issues with this contribution as well.
| merged | No | S3‑223928 | |||
S3‑223419 | Address ENs in UUAA procedures | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| merged | No | S3‑223927 | |||
S3‑223522 | Editorial change on USS authorization | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑223889 | [MCPTT] 33179 R13 Incorrect example | Airbus | CR | Decision | Yes |
Yes
| revised | No | S3‑223944 | |||
S3‑223944 | [MCPTT] 33179 R13 Incorrect example | Airbus | CR | Decision | Yes |
Yes
| revised | No | S3‑224172 | S3‑223889 | ||
S3‑224172 | [MCPTT] 33179 R13 Incorrect example | Airbus | CR | Decision | Yes |
Yes
| agreed | No | S3‑223944 | |||
S3‑223890 | [MCSec] 33180 R14 Incorrect example | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223891 | [eMCSec] Mirror 33180 R14 Incorrect example | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223892 | [MCXSec] Mirror 33180 R14 Incorrect example | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223893 | [MCXSec2] Mirror 33180 R14 Incorrect example | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223896 | [MCPTT] 33179 R13 Incorrect reference | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223897 | [MCSec] 33180 R14 Incorrect reference | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223898 | [eMCSec] 33180 R15 Incorrect reference (Mirror) | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223899 | [MCXSec] 33180 R16 Incorrect reference (Mirror) | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223900 | [MCXSec2] 33180 R17 Incorrect reference (Mirror) | Airbus | CR | Decision | Yes |
Yes
| agreed | No | ||||
S3‑223187 | Clarification of hashing | BSI (DE) | CR | Approval | Yes |
YesMavenir: state of art non cryptographic?
BSI: not broken.
Mavenir: you need to use a standard term for that, it is ambiguous.
BT: this is a TS, we specify down to the last bits of the algorithm. Requirement is fine, link up to the appropriate NIST document in line with previous comments.
BSI: we can add the NIST document and cross check with a BSI guideline,
| not pursued | No | ||||
S3‑223188 | Clarification of authorization verification | BSI (DE) | CR | Approval | Yes |
YesMavenir: this is adding authorization but it is not saying how to do it.
BT: the principle of adding it is fine.
| not pursued | No | ||||
S3‑223189 | Clarification of brute force mitigation mechanism verification | BSI (DE) | CR | Approval | Yes |
YesHuawei: change step 7. It is describing another condition, it shouldn’t be a new step. It should be a NOTE.
BT: the requirement makes it mandatory, but it looks like we are weakening the requirement with the note.
| not pursued | No | ||||
S3‑223945 | Clarification of brute force mitigation mechanism verification | BSI (DE) | CR | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑223190 | Clarification of privilege escalation methods to check for | BSI (DE) | CR | Approval | Yes |
YesHuawei: what kind of used capabilities?
BSI: We can clarify that.
NTT_Docomo: add how to check in the execution steps.
| not pursued | No | ||||
S3‑223946 | Clarification of privilege escalation methods to check for | BSI (DE) | CR | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑223191 | Clarification of service reachability restriction verification | BSI (DE) | CR | Approval | Yes |
YesMCC: all these CRs have the wrong WID. It should be eSCAS_5G.
Some changes in the text were proposed as well.
BT: there is a danger of adding requirements from the back door in the test cases. We need to discuss offline, whether the test cases are for existent requirements or defining new ones.
| not pursued | No | ||||
S3‑223947 | Clarification of service reachability restriction verification | BSI (DE) | CR | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑223192 | Clarification of auto-launch verification | BSI (DE) | CR | Approval | Yes |
YesHuawei: remove the check in the RAN and Core Network field in the cover page.
Vodafone: "any kind of autostart file" is ambiguous.
BT: don’t replace any kind with "all". We should not forbid all kinds of autostart files as we need something for operational reasons. Maybe "unauthorised".
Vodafone: it depends on where you are in the operational process. BT meant when the service was not built, still fresh.
BSI: we need to discuss this internally.
| not pursued | No | ||||
S3‑223193 | Clarification of SYN Flood attack prevention test | BSI (DE) | CR | Approval | Yes |
YesInterdigital: format is not defined here.
Mavenir: are we making this use case vendor specific? On the first precondition.
BT had also issues with the execution steps.
| not pursued | No | ||||
S3‑223194 | Clarification of privilege verification | BSI (DE) | CR | Approval | Yes |
YesHuawei: it conflicts with the original purpose. We need to discuss offline.
| not pursued | No | ||||
S3‑223197 | Clarification of CGI/Scripting component directory check | BSI (DE) | CR | Approval | Yes |
YesMavenir: about all these CRs. They are all for Release 17, which is frozen. These enhancements are good, but these are being used out there.We need time to check that these are expansions or new tests. If they are new they should go for Release 18, otherwise they are impacting on current implementations.
Huawei: these proposals could go to a draft CR in Release 18.
BT: from the ENISA perspective we may have to do these in Release 17 anyway, otherwise somebody else would take this task, Not keen on delaying to Release 18 just because they are difficult.
Mavenir: just one meeting cycle to make sure that these are added properly.
| not pursued | No | ||||
S3‑223198 | Clarification of SSI System Command Excecution test | BSI (DE) | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223602 | Clarification on TC_ IP_MULTICAST_HANDLING | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑223603 | Clarification on TC_ IP_MULTICAST_HANDLING | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑223604 | Clarification on IP_FWD_DISABLING | Huawei, HiSilicon | CR | Approval | Yes |
YesQualcomm: the note is referring to the removed sentence so it should be deleted as well.
| revised | No | S3‑223929 | |||
S3‑223929 | Clarification on IP_FWD_DISABLING | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | S3‑223604 | |||
S3‑223605 | Clarification on IP_FWD_DISABLING | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| revised | No | S3‑223930 | |||
S3‑223930 | Clarification on IP_FWD_DISABLING | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | S3‑223605 | |||
S3‑223880 | Remove password complexity criteria, password expiry and password history requirements | Ericsson | CR | Agreement | Yes |
YesHuawei didn’t understand the change. Vodafone had the same question.
Ericsson: the tests were created years ago, the guidelines have been updated.
China Mobile: we don’t want this change, it would weaken the requirements.
NCSC: this doesn’t necessarily reduce the security, the length of the password is more important.
Jeff (NIST) agreed: longer passwords are more secure according to the studies.
Mavenir: the combination is also important (e.g. capital letters).
Docomo: list of non acceptable passwords would help. Make it harder to create memorable passwords.
| revised | No | S3‑223931 | |||
S3‑223931 | Remove password complexity criteria, password expiry and password history requirements | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑223880 | |||
S3‑223884 | Remove password complexity criteria, password expiry and password history requirements | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑223932 | |||
S3‑223932 | Remove password complexity criteria, password expiry and password history requirements | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑223884 | |||
S3‑223336 | Corrections to the test cases in TS 33.511 | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223337 | Corrections to the test cases in TS 33.511 | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223338 | Corrections to the threat references in TS 33.511 | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223339 | Corrections to the threat references in TS 33.511 | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223340 | Adding non-Uu user plane text cases to TS 33.511 | Qualcomm Incorporated | CR | Agreement | Yes |
YesMCC commented that this should be Rel-18.
To be added to the draft CR for Rel-18 in tdoc 933.
| not pursued | No | ||||
S3‑223341 | Adding non-Uu user plane text cases to TS 33.511 | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223334 | Correction to the gNB threats in TR 33.926 | Qualcomm Incorporated | CR | Agreement | Yes |
YesIt needed to be taken offline for discussions with Lenovo.
| agreed | No | ||||
S3‑223335 | Correction to the gNB threats in TR 33.926 | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑223582 | Discussion on IMS SCAS status | Huawei, HiSilicon | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑223583 | LS on IMS SCAS to GSMA | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| revised | No | S3‑223934 | |||
S3‑223934 | LS on IMS SCAS to GSMA | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| approved | No | S3‑223583 | |||
S3‑223854 | Authentication for UE behind 5G-RG and FN-RG using NSWO | CableLabs | CR | Agreement | Yes |
YesEricsson: this is not a small correction but a major feature.
CableLabs: no new feature, no major impact here.
Qualcomm, AT&T: not a correction or alignment.
It was taken offline to check the SA2 spec.
| not pursued | No | ||||
S3‑223835 | Living document for DUMMY: draftCR to TS 33.535, IETF OSCORE as AKMA Ua* protocol | Ericsson, Deutsche Telekom | draftCR | Approval | Yes |
YesHuawei: this depends on the agreement on the WID.
| not pursued | No | ||||
S3‑223730 | Living document for SERP: draftCR to TS 33.501 on the Protection of the RRC Resume Request message | Samsung | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223847 | Living document for SERP: draftCR to TS 33.501 on the Protection of the RRC Resume Request message | Ericsson, Apple | draftCR | Approval | Yes |
YesQuakcomm: there is a lot of contradicting text across the CR.
| noted | No | ||||
S3‑223613 | SERP - LS on security protection on RRCResumeRequest message | Apple | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑223631 | User consent clarification | Ericsson | CR | Agreement | Yes |
YesHuawei: not needed.It's a legal statement, not appropriate for this specification.
NTT-Docomo:I don’t know the purpose of this.
Google: this defintion of user consent is too narrow.
Nokia supported the above companies.
Qualcomm: maybe useful to have a clarification, because this sounds confusing. Offline work could improve this.
Nokia: the first sentence already does the job.
BT: first and second change are incompatible. GDPR is data protection not privacy.
This was taken offline.
| not pursued | No | ||||
S3‑223517 | Discussion on Kiab handling in IAB migration | Huawei, HiSilicon | discussion | Approval | Yes |
Yes
| noted | No | ||||
S3‑223518 | CR on Kiab handling in IAB migration_new psk | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223519 | CR on Kiab handling in IAB migration_old psk | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| revised | No | S3‑223950 | |||
S3‑223950 | CR on Kiab handling in IAB migration_old psk | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| not pursued | No | S3‑223519 | |||
S3‑223735 | [IAB] IAB inter-CU topology adaptation procedure | Samsung | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223520 | LS on Kiab handling in IAB migration | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑223773 | CR_33.501 R15 Update A.18 to define SoR-XMAC-IUE | Xiaomi Communication | CR | Approval | Yes |
YesEricsson: why Rel-15? It is better to start in Release 16.
The Chair commented that this wasn’t FASMO and MCC confirmed that if implementations were not affected below Rel-18 starting the change in Rel-18 was fine.
It was commented that it was better not to create a Rel-18 version of TS 33.501 for this so eventually the change was agreed for Rel-17.
Huawei: add missing reference.
| not pursued | No | ||||
S3‑223775 | CR_33.501 R16 Update A.18 to define SoR-XMAC-IUE (mirror) | Xiaomi Communication | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223779 | CR_33.501 R17 Update A.18 to define SoR-XMAC-IUE (mirror) | Xiaomi Communication | CR | Approval | Yes |
Yes
| revised | No | S3‑223935 | |||
S3‑223935 | CR_33.501 R17 Update A.18 to define SoR-XMAC-IUE (mirror) | Xiaomi Communication | CR | Approval | Yes |
Yes
| agreed | No | S3‑223779 | |||
S3‑223778 | CR_33.501 R17 Update A.17 for SoR transparent container | Xiaomi Communication | CR | Approval | Yes |
YesDocomo: it should be normative "shall" instead of "should" and don’t make it a note.
| revised | No | S3‑223936 | |||
S3‑223936 | CR_33.501 R17 Update A.17 for SoR transparent container | Xiaomi Communication | CR | Approval | Yes |
Yes
| agreed | No | S3‑223778 | |||
S3‑223774 | CR_33.501 R15 Update A.20 to define UPU-XMAC-IUE | Xiaomi Communication | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223776 | CR_33.501 R16 Update A.20 to define UPU-XMAC-IUE (mirror) | Xiaomi Communication | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑223780 | CR_33.501 R17 Update A.20 to define UPU-XMAC-IUE (mirror) | Xiaomi Communication | CR | Approval | Yes |
YesHuawei: reference missing here.
It was agreed to make the change only in Rel-17.
| revised | No | S3‑223937 | |||
S3‑223937 | CR_33.501 R17 Update A.20 to define UPU-XMAC-IUE (mirror) | Xiaomi Communication | CR | Approval | Yes |
Yes
| agreed | No | S3‑223780 | |||
S3‑223331 | Clarification to the UPU procedures | Qualcomm Incorporated | CR | Agreement | Yes |
YesQualcomm: CT4 created a non backwards compatible change it will be treated next meeting.
| not pursued | No | ||||
S3‑223262 | Correction in UPU procedure to align with stage 3 | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesQualcomm: the UE cannot make the decision whether the network included the UDP header or not. Othe UDP header is ptional in one interface mandatory in other interfaces.
Huawei supports Qualcomm. The UE will always get the header.
This had to be taken offline.
| not pursued | No | ||||
S3‑223263 | Correction in UPU procedure to align with stage 3 | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223264 | UPU procedure align with stage 3 for AMF not registered case | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesQualcomm: the not should read "if step 1…".
NTT-Docomo: I don’t think this is a note, it is mandatory behaviour.
Huawei didn’t fully understand what it was needed, but agreed that this should not be a note.
| revised | No | S3‑223938 | |||
S3‑223938 | UPU procedure align with stage 3 for AMF not registered case | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑223264 | |||
S3‑223707 | Clarification to multiple registrations in different PLMNs\access types | Ericsson | CR | Agreement | Yes |
YesNokia didn’t agree with the wording.CT4 specs are clear.
NTT-Docomo: this should be specified somewhere else instead of putting a long text. Just refer to the place where it is written in CT4.
| not pursued | No | ||||
S3‑223807 | Discussion paper on restriction for multi registrations in two PLMNs | Nokia, Nokia Shanghai Bell | discussion | Endorsement | Yes |
YesNO need to endorse, we discuss the CRs.
| noted | No | ||||
S3‑223809 | Add restriction for multi registrations in two PLMNs | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesHuawei: we don’t agree with the notes.
Qualcomm: we don’t agree with this CR. The problem is solved in the network not in the UE, and the change is not simple.
Huawei: we think it is a valid case but we miss a different network here. We are not sure how to solve this.
Ericsson: we are fine with the CRs.
BT: this is just a small piece of a bigger puzzle, we feel.
Huawei: even with two different internal implementations you can still maintain two paralel NAS connections with the same or different PLMNs.
| not pursued | No | ||||
S3‑223811 | Add restriction for multi registrations in two PLMNs | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223416 | Address issue in NSSAA procedures for multiple registration | Huawei, HiSilicon | CR | Agreement | Yes |
YesEricsson commented that this had been brought for several years and we sent our comments several times. They noted that this wasn’t applicable for a frozen release either.
Nokia: same comments as Ericsson. They had another proposal in tdoc 810.
| not pursued | No | ||||
S3‑223417 | Address issue in NSSAA procedures for multiple registration (mirror) | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223808 | Discussin paper on control on NSSAA procedures for multi registrations in two PLMNs | Nokia, Nokia Shanghai Bell | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑223810 | control on NSSAA procedures for multi registrations in two PLMNs | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesEricsson: second sentence in first change should be a NOTE.
NOTE 1 may not be applied in certain cases.
Qualcomm: this is SA3 stuff, irrelevant for security.
Interdigital: some changes are not really coming from SA2 at all.
The Chair queried whether some LS to SA2 would answer the questions and get some clarification.
| not pursued | No | ||||
S3‑223812 | control on NSSAA procedures for multi registrations in two PLMNs | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑223202 | CR NRF deployments | Nokia, Nokia Shanghai Bell, Ericsson, Mavenir, Huawei, HiSilicon | CR | Agreement | Yes |
YesMavenir: conclusion of the key issue in the study should be this CR.
Nokia: we want a parallel WID to capture the normative content together with the study.
| agreed | No | S3‑221867 | |||
S3‑223394 | User plane security for Non-SBA based interfaces | Nokia, Nokia Shanghai Bell | CR | Approval | Yes |
YesNTT-Docomo: clarify that it shall be used unless security is provided by other means.
Ericsson: N4 is not an user interface.
Docomo: shall be used instead of supported.
MCC: remove the revision marks on the cover page.
| revised | No | S3‑223949 | S3‑221789 | ||
S3‑223949 | User plane security for Non-SBA based interfaces | Nokia, Nokia Shanghai Bell | CR | Approval | Yes |
Yes
| agreed | No | S3‑223394 | |||
S3‑223414 | Address EN1 on S-NSSAI mapping | Huawei, HiSilicon | CR | Agreement | Yes |
YesEricsson: the SA2 term is aligned with SA3 actually.
| not pursued | No | ||||
S3‑223415 | Address EN2 on AF Authorization | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| merged | No | S3‑223926 | |||
S3‑223606 | clarification on PLMN ID verification in SNPN | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| revised | No | S3‑223941 | |||
S3‑223941 | clarification on PLMN ID verification in SNPN | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | S3‑223606 | |||
S3‑223662 | SECOP correction | Nokia, Nokia Shanghai Bell | CR | Yes |
YesEricsson: start in an earlier release. This is a correction.
Huawei: check the baseline, we think this was addressed already.
| revised | No | S3‑223942 | ||||
S3‑223942 | SECOP correction | Nokia, Nokia Shanghai Bell | CR | - | Yes |
Yes
| not pursued | No | S3‑223662 | |||
S3‑223685 | Aligning DNS and ICMP security for non-3GPP access with 3GPP access | Ericsson | CR | Agreement | Yes |
Yes
| endorsed | No | ||||
S3‑223782 | CR_33.501 R17 Update Subscription and unsubscription procedure of NSACF notification service | Xiaomi Communication | CR | Approval | Yes |
Yes
| merged | No | S3‑223926 | |||
S3‑223214 | Introduction of DTLS 1.3 | Nokia, Nokia Shanghai Bell | CR | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑223456 | Adding AAnF critical assets and threats to TR 33.926 | China Mobile (Suzhou) Software | CR | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑223901 | [MCXSec3] 33180 R18 Incorrect reference (Mirror) | Airbus | CR | Decision | No |
Yes
| withdrawn | Yes | ||||
S3‑223150 | LS on anonymous user access to an AF | C3-224730 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑223943 | SECOP correction | Nokia | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑223948 | LS on NSSAA procedures for multiple registrations | Huawei | LS out | Approval | Yes |
Yes
| noted | No | ||||
5 | Rel-18 Studies |   | ||||||||||
5.1 | Study on 5G security enhancement against false base stations | S3‑223284 | FBS - Way forward for solutions based on digital signatures addressing KI#2 | Philips International B.V. | pCR | Endorsement | Yes |
Yes
| not treated | No | ||
S3‑223372 | Conclusion for KI #2 | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223732 | Conclusion for key issue#2 | Samsung, Intel, Apple | pCR | Approval | Yes |
YesORANGE: what are we protecting from? We have been getting the same conclusion after several years and I still object to this.
BT: given the discussions on post quantum activities in NIST we are not ready to conclude until we decide how we should work in the post-quantum environment, where we would need to rework a lot of stuff. If I had to choose I would go for Qualcomm's proposal.
Cablelabs: digital signature based solution is supported by us, but we will ready when the post quantum situation arrives. At the moment we should agree on this.
Huawei: there is an editor's note to be resolved, we are not concluded.
Intel: solution 19 works only in RRC connected state.
Nokia: ten solution proposals for key issue 2. Whatever solution we select will have a tricky part. Maybe we should categorise the solutions and consider a risk assessment.
Vodafone liked Nokia's comment. They also said that the problem was if the user could not connect due to the whole digital signature process.
ORANGE: not enough evaluation for this solution. We should stop this study, it has been running for too long.
CableLabs: let's do security, not performance.ORANGE replied that it was about solutions that work.
BT: either solution achieves the purpose of the study, which is stopping False Base Stations.
CableLabs: replay attack can be mitigated with this solution, we make it extremely hard for the FSB to attack like this.
Qualcomm: not diffficult to listen to the message and rebroacast.
CalbleLabs: with timestamp it is harder because we can detect the delay.
The Chair commented that there were multiple regulator agencies asking for solutions and that there were papers looking at the TR and pointing out the lack of solutions.
ORANGE replied that they didn’t oppose to the purpose, but it was the current state of the TR that didn’t allow progress.E.g. there is no way to handle the bidding down attacks. This can be solved with a new study in 6G.
Qualcomm: ask the regulators what threats need to be addressed.
The Chair replied that PWS and SIP protection. Qualcomm replied that for PWS there were application layer solutions, no impact on the network, and even that was difficult for some countries.
The Chair commented that one of the problems was that regulators didn’t come to SA3, so it was pretty hard to progress.
BT: PWS had a good solution in the beginning but no regulator agreed on who held the root key. BT commented that ENISA would come the next day so some input could be gathered.
Google: we support digital signature. Shared model is not relevant.
ORANGE: no authentication related, this is for FSBs.
Qualcomm: time to close the study so as not to repeat the same discussions again and again.
Apple: lack of progress is the result of objections of some companies.
| noted | No | ||||
S3‑223733 | Updates to Solution#7 SI verification using Digital Signatures | Samsung | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223734 | Resolving EN of solution#7 (TR 33.809) | Samsung | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223614 | 5GFBS - Addressing UE bahaviors on signature verification | Apple | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223883 | Addressing the editor’s note in 6.27.2.1.1 of Sol#27 | CableLabs | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223885 | Addressing EN on NR Repeater in 6.27.2.2.4 of Sol#27 | CableLabs | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223886 | Addressing the editor’s note in 6.27.2.2.1of Sol#27 | CableLabs, Deutsche Telekom, Philips International B.V. | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223285 | FBS - Additions in solution #25 | Philips International B.V. | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223286 | FBS - Evaluation of solution #25 | Philips International B.V. | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223373 | Conclusion for KI #3 | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223420 | Update to solution #25 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223615 | 5GFBS - Reply LS on authenticity and replay protection of system information | Apple | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑223708 | LS on Evaluation of Digital Signature schemes for the false base station study | Oy LM Ericsson AB | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑223731 | Reply LS on authenticity and replay protection of system information | Samsung, Apple, CableLabs | LS out | Approval | Yes |
YesQualcomm: we cannot reply if there is no consensus here.
Apple: this is not really the case.
ORANGE and Qualcomm pointed out that any outgoing LS on this topic would be objected.
| noted | No | ||||
5.2 | Study on Security Impacts of Virtualisation | S3‑223387 | Address EN on PACF and MANO Communication | Johns Hopkins University APL, US National Security Agency, CISA ECD | pCR | Approval | Yes |
Yes
| revised | No | S3‑224065 | |
S3‑224065 | Address EN on PACF and MANO Communication | Johns Hopkins University APL, US National Security Agency, CISA ECD | pCR | Approval | Yes |
Yes
| noted | No | S3‑223387 | |||
S3‑223393 | Address EN on Verifying Attestation Results for NRF and PACF | Johns Hopkins University APL, US National Security Agency, CISA ECD | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223496 | Evaluation on Solution 5 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223608 | New solution on boot time attestation at 3GPP function level | Huawei, HiSilicon | pCR | Approval | Yes |
YesEricsson objected to this contribution.
| noted | No | ||||
S3‑224066 | LS on embedding MnF in PACF security function | John Hopkins Univeristy | LS out | Approval | Yes |
YesHuawei: there was no agreement to send an LS during the breakout session.
| noted | No | ||||
5.3 | Study on Security Aspects of Proximity Based Services in 5GS Phase 2 | S3‑223233 | New Key issue for Updating security policy parameters when device is out of 5G coverage | Nokia, Nokia Shanghai Bell | pCR | Yes |
YesInterdigital: we don’t accept new key issues if there are no requirements.
Qualcomm agreed with that statement. Not clear what problem we are trying to solve.
ORANGE: We can add requirements later but not in this meeting.
| noted | No | |||
S3‑223421 | Discussion for L2 UE-to-Network Relay Multi-Path Security | OPPO | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑223447 | KI for L2 UE-to-Network Relay Multi-Path Security | OPPO | pCR | Approval | Yes |
YesQualcomm,Nokia and Ericsson: we cannot agree with this key issue.
| noted | No | ||||
S3‑223623 | New KI: Support for Emergency service over UE-to-Network Relaying | Ericsson | pCR | Approval | Yes |
YesInterdigital,Huawei and Vodafone: some more conten tneeds to be added to the threats.
MCC: just refer to the TR, no need to say SA2 and Release 18 here.
| revised | No | S3‑223996 | |||
S3‑223996 | New KI: Support for Emergency service over UE-to-Network Relaying | Ericsson | pCR | Approval | Yes |
Yes
| approved | No | S3‑223623 | |||
S3‑223721 | Key Issue for secure ProSe multi-path transmission for UE-to-Network relay | Samsung | pCR | Approval | Yes |
YesEricsson, Qualcomm didn’t agree with this.Some support from Nokia.
| noted | No | ||||
S3‑223817 | new KI for path switching between two indirect network communication paths | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
YesQualcomm couldn’t agree with this key issue. No necessity to align the security policies between both relay services.
| noted | No | ||||
S3‑223247 | Update KI#5 | OPPO | pCR | Approval | Yes |
Yes
| revised | No | S3‑223963 | |||
S3‑223963 | Update KI#5 | OPPO | pCR | Approval | Yes |
Yes
| approved | No | S3‑223247 | |||
S3‑223894 | KI #3 update: authorization synchronization | MITRE Corporation | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223248 | New solution for KI#5 | OPPO | pCR | Approval | Yes |
YesQualcomm: incorrect solution. Not clear which protection methods to use.
Vodafone: evaluation doesn't highlight some of the issues. Evaluation need to be ctritical.
| revised | No | S3‑224029 | |||
S3‑224029 | New solution for KI#5 | OPPO | pCR | Approval | Yes |
Yes
| approved | No | S3‑223248 | |||
S3‑223369 | A new solution for UE-to-UE Relay discovery message protection for Model A discovery | Qualcomm Incorporated | pCR | Approval | Yes |
YesORANGE: remove the evaluation part and put an editor's note.
| revised | No | S3‑223997 | |||
S3‑223997 | A new solution for UE-to-UE Relay discovery message protection for Model A discovery | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| approved | No | S3‑223369 | |||
S3‑223370 | A new solution for UE-to-UE Relay discovery message protection for Model B discovery | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| revised | No | S3‑223998 | |||
S3‑223998 | A new solution for UE-to-UE Relay discovery message protection for Model B discovery | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| approved | No | S3‑223370 | |||
S3‑223371 | A new solution for secure PC5 link establishment for UE-to-UE Relay | Qualcomm Incorporated | pCR | Approval | Yes |
YesInterdigital: Only works when relay is in coverage.
XIaomii: security can be provided by the application layer.
| revised | No | S3‑223999 | |||
S3‑223999 | A new solution for secure PC5 link establishment for UE-to-UE Relay | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| approved | No | S3‑223371 | |||
S3‑223469 | New solution to establish UE-to-UE security | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| revised | No | S3‑223964 | |||
S3‑223964 | New solution to establish UE-to-UE security | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223469 | |||
S3‑223624 | Support Emergency Service over UE-to-Network Relay | Ericsson | pCR | Approval | Yes |
Yes
| revised | No | S3‑224005 | |||
S3‑224005 | Support Emergency Service over UE-to-Network Relay | Ericsson | pCR | Approval | Yes |
Yes
| approved | No | S3‑223624 | |||
S3‑223664 | pCR to TR33.740 Solution for U2U Relay discovery message security | CATT | pCR | Approval | Yes |
Yes
| revised | No | S3‑223965 | |||
S3‑223965 | pCR to TR33.740 Solution for U2U Relay discovery message security | CATT | pCR | Approval | Yes |
Yes
| approved | No | S3‑223664 | |||
S3‑223722 | New solution for hop-by-hop security establishment for the UE-to-UE Relay | Samsung | pCR | Approval | Yes |
Yes
| revised | No | S3‑223966 | |||
S3‑223966 | New solution for hop-by-hop security establishment for the UE-to-UE Relay | Samsung | pCR | Approval | Yes |
Yes
| approved | No | S3‑223722 | |||
S3‑223766 | New solution on security for discovery integrated into PC5 link establishment | Beijing Xiaomi Mobile Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑223967 | |||
S3‑223967 | New solution on security for discovery integrated into PC5 link establishment | Beijing Xiaomi Mobile Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223766 | |||
S3‑223818 | security solution for path switching between two indirect network communication paths | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223276 | ProSe - Evaluation Solution #10 | Philips International B.V. | pCR | Approval | Yes |
YesQualcomm: further evaluation is FFS, on the choice for the application layer.
| revised | No | S3‑224006 | |||
S3‑224006 | ProSe - Evaluation Solution #10 | Philips International B.V. | pCR | Approval | Yes |
Yes
| approved | No | S3‑223276 | |||
S3‑223277 | ProSe - Evaluation Solution #15 | Philips International B.V. | pCR | Approval | Yes |
YesQualcomm: incorrect baseline, I cannot see what editor's note was removed.
Phillips admitted the omission of revision marks here.
Interdigital: add editor's note in evaluation.
Ericsson needed clarification on the evaluation, proposing more editor's notes.
The Chair proposed to come back in the next meeting with an update of this.
| noted | No | ||||
S3‑223278 | ProSe - Minnor editorial corrections in Solution #10 | Philips International B.V. | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223279 | ProSe - Minnor updates in Solution #10 | Philips International B.V. | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223310 | Update TR 33.740 solution #1 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
Yes
| revised | No | S3‑223969 | |||
S3‑223969 | Update TR 33.740 solution #1 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
Yes
| approved | No | S3‑223310 | |||
S3‑223311 | Update TR 33.740 solution #2 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
YesHuawei: we need the alignment with SA2. This was taken offline.
| approved | No | ||||
S3‑223312 | Update TR 33.740 solution #12 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
YesQualcomm: we need more time to evaluate this, an editor's note is needed.
| revised | No | S3‑224000 | |||
S3‑224000 | Update TR 33.740 solution #12 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
Yes
| approved | No | S3‑223312 | |||
S3‑223313 | Update TR 33.740 solution #13 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
YesQualcomm proposed to add an editor's note on the evaluation FFS
| revised | No | S3‑224001 | |||
S3‑224001 | Update TR 33.740 solution #13 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
Yes
| approved | No | S3‑223313 | |||
S3‑223314 | Update TR 33.740 solution #14 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
Yes
| revised | No | S3‑224007 | |||
S3‑224007 | Update TR 33.740 solution #14 | InterDigital, Europe, Ltd. | pCR | Approval | Yes |
Yes
| approved | No | S3‑223314 | |||
S3‑223400 | Update to solution#5 in TR 33.740 - align with SA2 | China Telecom Corporation Ltd. | pCR | Approval | Yes |
YesInterdigital: alignment with SA2 is needed.
| revised | No | S3‑223970 | |||
S3‑223970 | Update to solution#5 in TR 33.740 - align with SA2 | China Telecom Corporation Ltd. | pCR | Approval | Yes |
Yes
| approved | No | S3‑223400 | |||
S3‑223401 | Update to solution#5 in TR 33.740 - remove the EN | China Telecom Corporation Ltd. | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223451 | Update to ProSe Security Sol#6 | OPPO | pCR | Approval | Yes |
YesHuawei: there is SA2 content.
OPPO: this is a TR, not normative.
| revised | No | S3‑223972 | |||
S3‑223972 | Update to ProSe Security Sol#6 | OPPO | pCR | Approval | Yes |
Yes
| approved | No | S3‑223451 | |||
S3‑223452 | Address ENs in Sol#6 for ProSe Security | OPPO | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223453 | Add Evaluation for ProSe Security Sol#6 | OPPO | pCR | Approval | Yes |
YesInterdigital, Qualcomm proposed editor's notes.
| revised | No | S3‑224008 | |||
S3‑224008 | Add Evaluation for ProSe Security Sol#6 | OPPO | pCR | Approval | Yes |
Yes
| noted | No | S3‑223453 | |||
S3‑223475 | Evaluate to the solution #3 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| merged | No | S3‑223973 | |||
S3‑223476 | Evaluate to the solution #5 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| revised | No | S3‑224009 | |||
S3‑224009 | Evaluate to the solution #5 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223476 | |||
S3‑223477 | Evaluate to the solution #15 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| revised | No | S3‑223968 | |||
S3‑223968 | Evaluate to the solution #15 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223477 | |||
S3‑223478 | Evaluate to the solution #20 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223626 | Evaluation to solution #3 | Ericsson | pCR | Approval | Yes |
YesQualcomm: third paragraph already exists in security details. Huawei didn’t agree with this paragraph either.
Interdigital: add an editor's note for alignment with SA2.
| revised | No | S3‑223973 | |||
S3‑223973 | Evaluation to solution #3 | Ericsson | pCR | Approval | Yes |
Yes
| approved | No | S3‑223626 | |||
S3‑223627 | Evaluation to solution #4 | Ericsson | pCR | Approval | Yes |
YesIntgerdigital: we still need to analyze the auth token included in the DCR message, it may lead to privacy issues.
Huawei: not sure if the evaluation is needed, because we need to address first the editor's note on the need for auth token (under step2).
| noted | No | ||||
S3‑223628 | Resolve EN of U2U determination in target UE in Solution3 | Ericsson | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223629 | Resolve EN of Direct Communication Invite in Solution3 | Ericsson | pCR | Approval | Yes |
YesInterdigital: we don’t agree with the removal of the editor's note.
| revised | No | S3‑224002 | |||
S3‑224002 | Resolve EN of Direct Communication Invite in Solution3 | Ericsson | pCR | Approval | Yes |
Yes
| approved | No | S3‑223629 | |||
S3‑223636 | pCR to TR33.740 Update Solution16 for removing ENs | CATT | pCR | Approval | Yes |
Yes
| revised | No | S3‑223974 | |||
S3‑223974 | pCR to TR33.740 Update Solution16 for removing ENs | CATT | pCR | Approval | Yes |
Yes
| approved | No | S3‑223636 | |||
S3‑223638 | pCR to TR33.740 Update Solution17 for removing ENs | CATT | pCR | Approval | Yes |
YesHuawei: why are you excluding the PCF now?
| revised | No | S3‑224003 | |||
S3‑224003 | pCR to TR33.740 Update Solution17 for removing ENs | CATT | pCR | Approval | Yes |
Yes
| approved | No | S3‑223638 | |||
S3‑223641 | pCR to TR33.740 Update Solution18 for removing ENs | CATT | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223643 | pCR to TR33.740 Evaluation of Solution16 | CATT | pCR | Approval | Yes |
YesInterdigital: key issue#3 is not fully covered.
| revised | No | S3‑223975 | |||
S3‑223975 | pCR to TR33.740 Evaluation of Solution16 | CATT | pCR | Approval | Yes |
Yes
| approved | No | S3‑223643 | |||
S3‑223644 | pCR to TR33.740 Evaluation of Solution17 | CATT | pCR | Approval | Yes |
Yes
| revised | No | S3‑224004 | |||
S3‑224004 | pCR to TR33.740 Evaluation of Solution17 | CATT | pCR | Approval | Yes |
Yes
| approved | No | S3‑223644 | |||
S3‑223659 | pCR to TR33.740 Evaluation of Solution18 | CATT | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223723 | Updates to solution#19 and resolving EN #2 and #3 | Samsung | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223724 | Updates to solution#19 and resolving EN #5 | Samsung | pCR | Approval | Yes |
YesQualcomm needed more clarification how the new text addresses the editor's note on the impact on the protocol stack.
Huawei: this is not addressing layer 3. An editor's note was added about this.
| revised | No | S3‑223976 | |||
S3‑223976 | Updates to solution#19 and resolving EN #5 | Samsung | pCR | Approval | Yes |
Yes
| approved | No | S3‑223724 | |||
S3‑223763 | Update to solution #8 in TR 33.740 | Beijing Xiaomi Mobile Software | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223764 | Update to solution #9 in TR 33.740 | Beijing Xiaomi Mobile Software | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223765 | Update to solution #20 in TR 33.740 | Beijing Xiaomi Mobile Software | pCR | Approval | Yes |
YesEricsson didn’t understand step 2 as it appeared as a new interface and how it aligned with SA2 architecture.
Qualcomm also had several issues.
| revised | No | S3‑223977 | |||
S3‑223977 | Update to solution #20 in TR 33.740 | Beijing Xiaomi Mobile Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223765 | |||
S3‑223470 | Conclusion on UE-to-UE relay security | Huawei, HiSilicon | pCR | Approval | Yes |
YesInterdigital: note it because the solution needs reworking in another contribution.
Ericsson and Qualcomm had the same comment.
| revised | No | S3‑224095 | |||
S3‑224095 | Conclusion on UE-to-UE relay security | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223470 | |||
S3‑223471 | Conclusion on UE-to-UE relay Authorisation | Huawei, HiSilicon | pCR | Approval | Yes |
YesCATT had a different view, they had their own proposal in 667.
Samsung asked to postpone boht conclusions.
| revised | No | S3‑223995 | |||
S3‑223995 | Conclusion on UE-to-UE relay Authorisation | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223471 | |||
S3‑223666 | pCR to TR33.740 Conclusion of key issue #1 | CATT | pCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑223667 | pCR to TR33.740 Conclusion of key issue #3 | CATT | pCR | Approval | Yes |
YesHuawei had issues with this conclusion.
Ericsson also wanted to postpone this.
Interdigital thought it was too early for this conclusion.
| noted | No | ||||
S3‑223661 | pCR to TR33.740 Update Abbreviations | CATT | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223322 | Living document to TS 33.503 for Prose Secondary Authentication | InterDigital, Europe, Ltd. | draftCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223625 | [Draft] LS on ProSe Secondary Authentication | Ericsson | LS out | Agreement | Yes |
Yes
| not treated | No | ||||
S3‑223971 | Draft TR 33.740 | CATT | draft TR | Approval | Yes |
Yes
| approved | No | ||||
5.4 | Study on privacy of identifiers over radio access | S3‑223200 | PCR to 33.870 Changes to Solution #2 | InterDigital, Inc. | pCR | Approval | Yes |
Yes
| revised | No | S3‑224069 | |
S3‑224069 | PCR to 33.870 Changes to Solution #2 | InterDigital, Inc. | pCR | Approval | Yes |
Yes
| noted | No | S3‑223200 | |||
S3‑223201 | PCR to 33.870 - New clause for mapping solutions and KIs | InterDigital, Inc. | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223223 | PCR to 33.870 - Aggregate changes | InterDigital, Inc. | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223237 | New solution for prevention of detection of priority access | Nokia, Nokia Shanghai Bell | pCR | Yes |
Yes
| not treated | No | |||||
S3‑223238 | EN removal for privacy prevention of NAI solution | Nokia, Nokia Shanghai Bell | pCR | Yes |
Yes
| revised | No | S3‑224114 | ||||
S3‑224114 | EN removal for privacy prevention of NAI solution | Nokia, Nokia Shanghai Bell | pCR | - | Yes |
Yes
| approved | No | S3‑223238 | |||
S3‑223376 | Resolution of an EN in solution #8 | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223377 | Evaluation of solution #8 | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| revised | No | S3‑224176 | |||
S3‑224176 | Evaluation of solution #8 | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| approved | No | S3‑223377 | |||
S3‑223406 | Remove EN to Key Issue #2 | Johns Hopkins University APL, US National Security Agency, InterDigital, Apple, CableLabs | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223446 | Remove EN and Provide Evaluation for Solution #4 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| revised | No | S3‑224174 | |||
S3‑224174 | Remove EN and Provide Evaluation for Solution #4 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| noted | No | S3‑223446 | |||
S3‑223540 | Updates to solution 3 based on pseudonyms | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| revised | No | S3‑224134 | |||
S3‑224134 | Updates to solution 3 based on pseudonyms | Huawei, HiSilicon | pCR | Approval | Yes |
YesHuawei: we need the evaluation uniform for all solutions. Ericsson agreed.
| approved | No | S3‑223540 | |||
S3‑223561 | Policy-based C-RNTI and TMSI refresh | Intel | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223578 | Resolution of EN in solution #8 | THALES, Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223826 | Updating Solution #9: Concealing length of SUPIs in SUCIs by padding the SUPIs | Oy LM Ericsson AB | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223870 | Update to Solution #1 in ID Privacy | Lenovo | pCR | Approval | Yes |
Yes
| revised | No | S3‑224033 | |||
S3‑224033 | Update to Solution #1 in ID Privacy | Lenovo | pCR | Approval | Yes |
Yes
| approved | No | S3‑223870 | |||
S3‑224164 | Draft TR 33.870 | Interdigital | draft TR | Approval | Yes |
Yes
| approved | No | ||||
5.5 | Study on Standardising Automated Certificate Management in SBA | S3‑223380 | Evaluation for Solution #3 | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
YesEricsson: private CA term is misleading.
CableLabs: change the privacy terminology.
| revised | No | S3‑223986 | |
S3‑223986 | Evaluation for Solution #3 | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| approved | No | S3‑223380 | |||
S3‑223381 | Evaluation for Solution #11 | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
YesHuawei: questionable as optimization.Fine to keep it for the record but not good for normative work.
| revised | No | S3‑223987 | |||
S3‑223987 | Evaluation for Solution #11 | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| approved | No | S3‑223381 | |||
S3‑223382 | Resolving EN and evaluation for Solution #10 | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
YesEricsson had some issues with the evaluation. ExtendedKeyUsage not only for client and server TLS.
Vodafone: evaluation is incomplete.
Huawei: this is not new.
| noted | No | ||||
S3‑223383 | Resolving EN and evaluation for Solution #12 | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
YesCisco liked the contribution overall, but the initial trust is mentioned as implementation specific. Some more content was needed here. Point the solution.
Vodafone: evaluation should be a quick analysis not a repetition of what is above. It should be completed or removed.
Huawei: third party interaction needs to be standardised? Too ambitious. Good for the record but not good for normative phase.
Ericsson suggested adding some editor's notes.
| revised | No | S3‑223991 | |||
S3‑223991 | Resolving EN and evaluation for Solution #12 | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| approved | No | S3‑223383 | |||
S3‑223514 | address EN for solution #8 and add evaluation | Huawei, HiSilicon | pCR | Approval | Yes |
YesEricsson: impact on OAM interfaces.
MCC: reword to remove the "must".
| revised | No | S3‑223992 | |||
S3‑223992 | address EN for solution #8 and add evaluation | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223514 | |||
S3‑223515 | address EN for solution #9 and add evaluation | Huawei, HiSilicon | pCR | Approval | Yes |
YesEricsson wanted to have some more issues captured in the evaluation.
MCC: check spelling and add reference to TS 23.501.
| revised | No | S3‑223993 | |||
S3‑223993 | address EN for solution #9 and add evaluation | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223515 | |||
S3‑223543 | Update to solution #3 | Huawei, HiSilicon | pCR | Approval | Yes |
YesEricsson: revocation is done by the authorities. We are not OK with the note.
| revised | No | S3‑223994 | |||
S3‑223994 | Update to solution #3 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223543 | |||
S3‑223407 | Clarify the use of cross-certificates | China Telecommunications | pCR | Yes |
Yes
| not treated | No | |||||
S3‑223385 | Preliminary conclusion for KI #1 | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
YesHuawei: we support the conclusion,the analysis not so much.
Ericsson: clarification on the conclusion needed.
CableLabs: include ACME as part of the solution. The Chair replied that this was discarded before.
Google: we are not against this proposal, we just want an editor's note opening the door for enhancements in other studies. The Chair replied that SA3 didn’t include such notes and that enhancements were always part of studies.
ORANGE: the conclusion has an editor's note about this already.
Huawei: don’t make it dependent on ACME or we will object.
| approved | No | ||||
S3‑223516 | add conclusion for KI # 6 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223384 | Solution for ensuring the management of bulk certificate updates | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
YesEricsson: not OK, we prefer Huawei solution in 544 from the operations point of view.
Nokia: opinion of operators?
Nokia: this is a study phase, it's not about liking/not liking.
Huawei: both solutions can go in, but the other solution is the one which will go to normative work.
The Chair commented that objecting to competing solutions was not the way to go in a study. You can compare later and decide.
ORANGE: what we include in the TR must be agreed by consensus.
Qualcomm: don’t include any solution that comes in a study, it needs to be viable so the companies can make better use of the time when evaluating them later.
Huawei: we don’t understand the link to the radio celll network oad. This should be removed.
| revised | No | S3‑224139 | |||
S3‑224139 | Solution for ensuring the management of bulk certificate updates | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| approved | No | S3‑223384 | |||
S3‑223544 | Policy based certificate update/renewal | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| revised | No | S3‑224140 | |||
S3‑224140 | Policy based certificate update/renewal | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223544 | |||
S3‑223895 | Proposal Solution #XX ACME use in 3GPP | Google Inc. | pCR | Approval | Yes |
YesEricsson: we need more time to study the proposal in the context of SBA.
Nokia: similar comments to Ericsson. This doesn’t explain how ACME fits in the SBA. We have certificates already defined in TS 33.310. IPX is out of scope.
Huawei: related more to IPX, it looks like it’s in scope of GSMA.
CableLabs supported this as an option to be added to the TR as further analysis
Google: not IPX but 5GC.We are happy to clarify further on how this worls in TS 33.310.
Ericsson: it's a new protocol in telecoms. Token signing will not work without DNS and many other dependecies that need to be checked.
Nokia: timing is an issue here, we would like to conclude the key issue next meeting.
| noted | No | ||||
S3‑223827 | PCR to TR33.876 - Addition of Key Issue - Protection of private keys at rest | Vodafone España SA | pCR | Agreement | Yes |
YesHuawei: no need for a solution. It's more like a deployment guidelines. Vodafone confirmed this.
| merged | No | S3‑224138 | |||
S3‑223828 | PCR to 33.876 - Addition of Key Issue: security of internal NF service communicaitons | Vodafone España SA | pCR | Agreement | Yes |
YesVodafone: securing services to services talking together.
Ericsson agreed with the contribution.
| revised | No | S3‑224138 | |||
S3‑224138 | PCR to 33.876 - Addition of Key Issue: security of internal NF service communicaitons | Vodafone España SA | pCR | Agreement | Yes |
Yes
| approved | No | S3‑223828 | |||
S3‑224165 | Draft TR 33.876 | Nokia | draft TR | Approval | Yes |
Yes
| approved | No | ||||
5.6 | New SID on AKMA phase 2 | S3‑223215 | Terminology update of solution #6 | Lenovo | pCR | Approval | Yes |
Yes
| approved | No | ||
S3‑223267 | alignment for solution1 for vAAnF or a new NF | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223268 | alignment for solution1 related to internal AF | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223269 | solution 1 evaluation | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| revised | No | S3‑224078 | |||
S3‑224078 | solution 1 evaluation | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| approved | No | S3‑223269 | |||
S3‑223287 | AKMA - Evaluation Solution #10 | Philips International B.V. | pCR | Approval | Yes |
Yes
| revised | No | S3‑224010 | |||
S3‑224010 | AKMA - Evaluation Solution #10 | Philips International B.V. | pCR | Approval | Yes |
Yes
| approved | No | S3‑223287 | |||
S3‑223432 | Address EN and add evaluation for solution 9 | ZTE Corporation | pCR | Approval | Yes |
Yes
| revised | No | S3‑224032 | |||
S3‑224032 | Address EN and add evaluation for solution 9 | ZTE Corporation | pCR | Approval | Yes |
Yes
| approved | No | S3‑223432 | |||
S3‑223433 | Address EN and update solution 3 | ZTE Corporation | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223436 | Update the solution 4 | ZTE Corporation | pCR | Approval | Yes |
Yes
| approved | No | ||||
S3‑223579 | Resolution of ENs in solution #14 | THALES | pCR | Approval | Yes |
Yes
| revised | No | S3‑224115 | |||
S3‑224115 | Resolution of ENs in solution #14 | THALES | pCR | Approval | Yes |
Yes
| approved | No | S3‑223579 | |||
S3‑223580 | Update of LI requirements on solution #5 | LG Electronics France | pCR | Approval | Yes |
Yes
| revised | No | S3‑224057 | |||
S3‑224057 | Update of LI requirements on solution #5 | LG Electronics France | pCR | Approval | Yes |
Yes
| approved | No | S3‑223580 | |||
S3‑223581 | Update of LI requirements on solution #12 | LG Electronics France | pCR | Approval | Yes |
Yes
| revised | No | S3‑224058 | |||
S3‑224058 | Update of LI requirements on solution #12 | LG Electronics France | pCR | Approval | Yes |
Yes
| approved | No | S3‑223581 | |||
S3‑223717 | Resolving EN and adding evaluation for solution#13 | Samsung | pCR | Approval | Yes |
Yes
| revised | No | S3‑224030 | |||
S3‑224030 | Resolving EN and adding evaluation for solution#13 | Samsung | pCR | Approval | Yes |
Yes
| approved | No | S3‑223717 | |||
S3‑223785 | KI#1 New sol AKMA roaming for external AF in the Data Network | Xiaomi Communication | pCR | Approval | Yes |
Yes
| revised | No | S3‑224071 | |||
S3‑224071 | KI#1 New sol AKMA roaming for external AF in the Data Network | Xiaomi Communication | pCR | Approval | Yes |
Yes
| approved | No | S3‑223785 | |||
S3‑223832 | New solution for AKMA roaming with VPLMN AKMA Support NF for inbound roamers | Ericsson | pCR | Approval | Yes |
Yes
| revised | No | S3‑224141 | |||
S3‑224141 | New solution for AKMA roaming with VPLMN AKMA Support NF for inbound roamers | Ericsson | pCR | Approval | Yes |
Yes
| approved | No | S3‑223832 | |||
S3‑223455 | Discussion Paper on evaluations and conclusions of key issue#1 | China Mobile (Suzhou) Software | discussion | Endorsement | Yes |
YesQualcomm: merge solutions for the next meeting, since we need to pick up components from different solutions.
Ericsson: focus on the conclusions now and it will help find the solutions.
| noted | No | ||||
S3‑223270 | KI1 conclusion | Nokia, Nokia Shanghai Bell, Lenovo, OPPO | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223675 | Conclusion for KI#1 case 2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
YesIt was commented the role of LI aspects here.
NTT-Docomo: if the AF is in VPLMN no normative work is required.
| revised | No | S3‑224137 | |||
S3‑224137 | Conclusion for KI#1 case 2 | China Mobile (Suzhou) Software | pCR | Approval | Yes |
Yes
| approved | No | S3‑223675 | |||
S3‑223434 | Conclusion for KI#1 | ZTE Corporation | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223505 | conclusion on AKMA roaming | Huawei, HiSilicon | pCR | Approval | Yes |
YesDiscussions on LI aspects.
Mark (National Technical Assistance) : uncomfortable with conclusions that forget about LI aspects. An editor's note on this was added.
Vodafone: if this affects the visited network I have an issue.
| revised | No | S3‑224136 | |||
S3‑224136 | conclusion on AKMA roaming | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223505 | |||
S3‑223271 | Discussion on privacy issue in AKMA | Nokia, Nokia Shanghai Bell, Samsung | discussion | Endorsement | Yes |
Yes
| not treated | No | ||||
S3‑223272 | key issue on AKMA privacy | Nokia, Nokia Shanghai Bell, Samsung | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223715 | Key Issue on KAF refresh | Samsung, Nokia, Nokia Shanghai Bell, OPPO, ZTE | pCR | Approval | Yes |
YesQualcomm didn’t agree with this contribution. The Kecs refresh needs to be studied further. The key issue needs to be rewritten to algin with the study approved in SA.
| noted | No | ||||
S3‑223716 | New solution on AKMA KAF refresh | Samsung | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223435 | Update the Key issue of AKMA roaming | ZTE Corporation | pCR | Approval | Yes |
Yes
| not treated | No | ||||
S3‑223535 | Discussion | Huawei, HiSilicon | discussion | Discussion | No |
Yes
| withdrawn | Yes | ||||
S3‑224109 | Draft TR 33.737 | China Mobile | draft TR | Approval | Yes |
Yes
| approved | No | ||||
5.7 | Study of Security aspect of home network triggered primary authentication | S3‑223359 | Adding a K_AUSF refresh use case | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| noted | No | ||
S3‑223511 | Update KI#1 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| revised | No | S3‑224011 | |||
S3‑224011 | Update KI#1 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| approved | No | S3‑223511 | |||
S3‑223274 | KI#1 conclusion | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| merged | No | S3‑224013 | |||
S3‑223361 | Proposed conclusion for the study | Qualcomm Incorporated | pCR | Approval | Yes |
Yes
| merged | No | S3‑224013 | |||
S3‑223542 | Conclusion on KI#1 and KI#2 in TR 33.741 | Huawei, HiSilicon | pCR | Approval | Yes |
Yes
| merged | No | S3‑224013 | |||
S3‑223610 | Discussion paper on way forward for conclusion | Huawei, HiSilicon | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑223720 | Conclusion on KI#1 | Samsung | pCR | Approval | Yes |
Yes
| merged | No | S3‑224013 | |||
S3‑223769 | Conclusion on KI#1 | Beijing Xiaomi Mobile Software | pCR | Approval | Yes |
Yes
| merged | No | S3‑224013 | |||
S3‑223840 | Conlusions | Ericsson | pCR | Approval | Yes |
YesQualcomm: I will object if you are tie with any use case. It should be generic.
Nokia: generic statements will open new discussions. We have three use cases clearly defined.
Huawei: different use cases will have specific issues. Let's leave this for the normative work.
Ericsson wanted to handle the interworking case.
Qualcomm: plesae address this use case in a different way (another WID or CR, etc…), this is supposed to be generic.
| revised | No | S3‑224013 | |||
S3‑224013 | Conlusions | Ericsson | pCR | Approval | Yes |
Yes
| approved | No | S3‑223840 | |||
S3‑223273 | solution 1 evaluation | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
Yes
| revised | No | S3‑224014 | |||
S3‑224014 | solution 1 evaluation | Nokia, Nokia Shanghai Bell | pCR | Approval | Yes |
YesAddressing Ericsson's and Lenovo's comments.
| approved | No | S3‑223273 | |||
S3‑223360 | Adding an evaluation of solution #5 | Qualcomm Incorporated | pCR | Approval | Yes |
YesLenovo: this solution opens to any AMF and we would like to see the use case for this scenario.
| revised | No | S3‑224015 | |||