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