Tdoc List

2019-06-28 16:12

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑191800 Agenda WG Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No    
S3‑191801 Report from last SA3 meeting/s MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
Yes
 		approved No    
S3‑191802 SA3 Work Plan MCC Work Plan  
9.1Review of work plan
 		Yes
Yes
 		noted No    
S3‑191803 Report from last SA meeting WG Chairman report  
4.2Report from SA Plenary
 		Yes
Yes
 		noted No    
S3‑191804 SA3 meeting calendar MCC other  
10Future Meeting Dates and Venues
 		Yes
YesNov 2020 may be IF3. Some resistance to have adhoc meetings in 2020. The Chair commented that these were reserved dates and not confirmed meetings. Preliminary dates for 2021 to be discussed during the next meeti
 		noted No    
S3‑191805 Work Plan input from Rapporteurs MCC other  
9.2Rapporteur input on status of WID or SID
 		Yes
YesTo be done next meeting.
 		noted No    
S3‑191806 Evaluation of Solution Solution #18 Futurewei pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		merged No S3‑192401  
S3‑191807 Secuirty threat for RRCResumeRequest tampering. Futurewei pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		withdrawn Yes    
S3‑191808 Solution for protecting RRCResumeRequest against tampering Futurewei pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		withdrawn Yes    
S3‑191809 Draft LS to RAN2 on UECapabilitiesEnquire after AS SMC Futurewei LS out Approval
6.10CVDs and Research
 		Yes
Yes
 		noted No    
S3‑191810 Update of Solution Solution #4 Futurewei pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191811 Evaluation of Solution #4 Futurewei pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191812 Conclusion for KI#2 for RRC based solutions Futurewei pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191813 Conclusion for KI#3 for RRC signaling based solutions Futurewei pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191814 TCG progress report InterDigital, Inc. report Information
6.6TCG
 		Yes
YesHighlights: • Publication of new or revised deliverables (incremental changes from the status reported at SA3#95) • TCG TPM 2.0 Auto Thin Profile – publication in June 2019 • TCG Trusted Attestation Protocol (TAP) Info Model – publication in June 2019 • TCG Trusted Attestation Protocol (TAP) Use Cases – public review June 2019 • TCG TPM 2.0 r1.55 – X.509 Certs & Attached Components – public review May 2019 • TCG TSS 2.0 TAB and Resource Manager – published April 2019 • TCG TSS 2.0 TPM Command Transmission Interface (TCTI) – published April 2019 • TCG TSS 2.0 System Level API (SAPI) – public review April 2019 • TCG TSS 2.0 Enhanced System Level API (ESAPI) – public review April 2019 • TCG PC Client Device Driver Design Principles for TPM 2.0 – public review February 2019 • TCG Platform Certificate Profile – public review February 2019 • IETF Remote ATtestation ProcedureS (RATS) WG in IETF Security Area About: https://datatracker.ietf.org/wg/rats/about/ Charter: https://datatracker.ietf.org/doc/charter-ietf-rats/ Documents: https://datatracker.ietf.org/wg/rats/documents/ Problem Space - Verifiable remote attestation - architecture and secure protocols - Solutions spanning from IoT devices to Data Center systems and Cloud infrastructure - Compact implementation solutions for resource-constrained systems - Composition and correlation for complex systems (e.g., rack-mount routers) - Primary support for CBOR Web Token (CWT) https://tools.ietf.org/html/rfc8392 - Secondary support for JSON Web Token (JWT) https://tools.ietf.org/html/rfc7519 - Multiple security components (GP SE, TCG TPM, TCG DICE, TCG MARS, etc.) 2. Meetings • TCG Annual Members Meeting in Warsaw, Poland – 10-13 June 2019 o Sessions of Cyber Resilience, Network Equipment, DICE, IoT, Industrial, etc. o Kickoff of Measurement and Attestation RootS (MARS) in Embedded Systems • TCG Annual Members Meeting in Toronto, Canada - 15-17 October 2019 • MPWG meets every Thursday 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
 		noted No    
S3‑191815 Evaluation for solution for (D)DoS attack mitigation in PNI NPN for KI#6.1 InterDigital, Inc. pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191816 Discussion on S-NSSAI privacy protection InterDigital, Inc. discussion Endorsement
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: this increases the complexity. ORANGE: the requirement on confidentiality protection of the NSSAI should be applied here. I prefer it to run in the RAN network. This is also adding complexity.
 		noted No    
S3‑191817 Protection of S-NSSAI transmitted in the AS layer using T-S-NSSAI InterDigital, Inc. pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesQualcomm: If the S-TMSI is stationary a dictionary attack is possible. Nokia agreed. An editor's note was agreed on this point. An sdditional editor's note were added as requested by Nokia.
 		revised No S3‑192374  
S3‑191818 Protection of S-NSSAI transmitted in the AS layer InterDigital, Inc. pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191819 Evaluation for solution #4 InterDigital, Inc. pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192260  
S3‑191820 Solution for (D)DoS attack mitigation in PNI NPN InterDigital, Inc. pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesHuawei: not in the scope of 3GPP. Qualcomm disagreed, as CAG ID was not long enough for them.
 		noted No    
S3‑191821 Solution for (D)DoS attack mitigation in PNI NPN InterDigital, Inc. pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesHuawei: not in the scope of SA3. It is not a security solution. The Chair commented that there was a key issue about this. Nokia supported Interdigital, they considered it within scope.
 		revised No S3‑192341  
S3‑191822 Solution for Privacy protection for unicast messages over PC5 InterDigital, Inc. pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesLG: more explanation about Kd session ID is needed. Add an editor's note on this. This was agreed. Editor's note: protection of messages; more explanation is needed. Editor's note on why the number of messages is different from SA2 spec (2 instead of 3). MCC: Reformulate NOTE not to mention SA2 but refer to stage 2 work.
 		revised No S3‑192415  
S3‑191823 Solution for Security for eV2X unicast messages over PC5 InterDigital, Inc. pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesLG: there is no ProSe for NR yet. Qualcomm proposed another editor's note for comparison with SA2's procedures.
 		revised No S3‑192417  
S3‑191824 Solution for Security for eV2X unicast messages over PC5 InterDigital, Inc. pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		revised No S3‑192418  
S3‑191825 Solution for Privacy protection for unicast messages over PC5 using rekeying InterDigital, Inc. pCR  
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQualcomm proposed an editor's note on integrity protection of SMC being cyphered causing an impact. This was agreed.
 		revised No S3‑192419  
S3‑191826 TR 33.813 - Evaluation for Solution X - S-NSSAI transmitted in the AS layer using T-S-NSSAI InterDigital, Inc. pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesIt was clarified that this evaluated tdoc 817. ORANGE: this is still under study, as we have added editor's notes in tdoc 817. An editor's note was added to express that more evaluation was needed.
 		revised No S3‑192375  
S3‑191827 TR 33.813 - Evaluation for Solution Y - S-NSSAI transmitted in the AS layer InterDigital, Inc. pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191828 TR 33.819 – KI #6.2 – Threats and Requirements InterDigital, Inc. pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192195  
S3‑191829 LS on ETSI Plugtest standards Issues C1-193601 LS in  
7.8.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		replied to No    
S3‑191830 Reply LS on Security failure of NAS container in HO command C1-193708 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesAready taken care of.
 		noted No    
S3‑191831 LS on handling of native non-current 5G NAS security context after an inter-system change from S1 mode to N1 mode in idle mode C1-193944 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		withdrawn Yes    
S3‑191832 Reply LS on Clarification for N32 security C4-192467 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191833 NGMN 5G End-to-End Architecture Framework NGMN LS in  
6.11Other Groups
 		Yes
Yes
 		noted No    
S3‑191834 Observations on standards and technical constraints from 3rd MCX remote Plugtests ETSI CTI LS in  
7.3eMCSec R16 security (MCXSec) (Rel-16)
 		Yes
YesMotorola commented that CT1 proposed that everything went all through them, given that there was an additional LS from CT1 to which SA3 will reply directly instead of this one. CTI will be in copy in that LS whereas this one will be noted.
 		noted No    
S3‑191835 LS on RRC Connection Re-Establishment for CP for NB-IoT connected to 5GC R2-1908264 LS in  
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		replied to No    
S3‑191836 LS on Ciphering solution for broadcast of Assistance Data R2-1908473 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		replied to No    
S3‑191837 GTP Recovery Counter & GSN node behaviour GSMA LS in  
6.4GSMA
 		Yes
YesNokia: the choice of options require some study from SA3. Vodafone: we need a study item for this, and reply to them with an LS that we will do a study. Better not to postpone this LS. The Chair noted that this was an LS asking CT4 and not SA3, so no specific action for SA3 was required. Nokia: CT4 will not give a proper answer on the security of this.
 		replied to No    
S3‑191838 Reply LS on Authentication for UEs not Supporting NAS S1-191595 LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE: they seem to interpret the requirement in a different way. They are not really answering our question.A laptop is not an IoT device.
 		noted No    
S3‑191839 Further LS relating to “Response LS on reporting all Cell IDs in 5G” S2-1906170 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191840 LS reply on Nudr Sensitive Data Protection S2-1906761 LS in  
5Items for early consideration
 		Yes
Yes
 		noted No    
S3‑191841 Reply LS on Nudr Sensitive Data Protection SP-190581 LS in  
5Items for early consideration
 		Yes
YesVodafone queried if changes implemented in Rel-15 had to be reversed. The Chair replied that was the case. NTT-Docomo: massive security work needed here, not even ready for Rel-16. It was decided to send an LS to SA2 and CT4 and postpone the reply to SA for the next meeting.
 		postponed No    
S3‑191842 Reply LS on Clarification request on NF authorization in UE Reachability Notification Request procedure S2-1906636 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191843 LS to BBF on WWC status S2-1906821 LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191844 LS on the availability of and requesting feedback on the stable draft TR 103 582 from ETSI STF555 - "Study of use cases and communications involving IoT devices in emergency situations ETSI SC EMTEL LS in  
6.11Other Groups
 		Yes
YesDocomo: we should feedback requirements for roaming users need to be clear with regards to PWS messages in IoT devices.There is some work in SA1 and CT1 for ePWS. If we receive more LS about this work we should keep EMTEL in the loop.
 		noted No    
S3‑191845 Diameter IPX Network End-to-End Security Solution GSMA LS in  
6.4GSMA
 		Yes
YesVodafone: I expect CRs for TS 33.401 as a result of this.A study item is needed. Iko (KPN): there is non 3GPP functionality here, that does not concern us. NCSC agreed with KPN. Nokia: on the Diameter solution we can give some feedback in the next meeting. AT&T: IETF has been working on Diameter security for years. How is it that GSMA has better security expertise on this issue? Vodafone commented that they had better knowledge of how the networks are implemented and deployed.
 		replied to No    
S3‑191846 LS on support of non-3GPP only UE and support for PEI in IMEI format S2-1904836 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑191847 Response LS on support of non-3GPP only UE and support for PEI in IMEI format s3i190363 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191848 Handling of UE radio network capabilities in 4G and 5G GSMA LS in  
6.10CVDs and Research
 		Yes
Yes
 		replied to No    
S3‑191849 Virtualisation Study Conf Call Output BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191850 pCR Virtualisation Study Key Issue 10 Merger with Key issue 1 (was S3-191569) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191851 Virtualisation Study Key Issue 11 (was S3-191570) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191852 Virtualisation Study Key Issue 12 (was S3-191571) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑192368  
S3‑191853 Virtualisation Study Key Issue 19 (was S3-191580) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑192395  
S3‑191854 Virtualisation Study Key Issue 20 (was S3-191581) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑192446  
S3‑191855 Virtualisation Study Key Issue 21 (was S3-191582) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191856 Virtualisation Study Key Issue 22 (was S3-191583) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑192396  
S3‑191857 Virtualisation Study Key Issue 23 (was S3-191583) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191858 Virtualisation Study Key Issue 24 (was S3-191585) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191859 Virtualisation Study Key Issue 25 (was S3-191587) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191860 [33.180] R15 - Fix hash result Motorola Solutions Germany CR Agreement
7.8.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑191861 [33.180] R16 - Fix hash result (mirror) Motorola Solutions Germany CR Agreement
7.3eMCSec R16 security (MCXSec) (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑191862 Moving Forward on Storing Authentication Data Hewlett-Packard Enterprise discussion Endorsement
5Items for early consideration
 		Yes
YesVodafone: there would be security interoperability issues between the ARPF and UDR, no assurance for backwards compatibility.There is no time to do any security assesments anymore for Rel-15. It was clarified that SA3 was requrested to align with stage 3. Huawei: against adding requirements for this in 33.501 Rel-16. Alex(BT): we need to accept that SA made the decision of keeping the UDR. All companies were OK with that in SA, except Vodafone. Go with the Plenary's decision, keep it in Rel-15 "it's in the UDR", and look at it in Rel-16. The Chair commented that the issue on Rel-15 would the priority and work forward in Rel-16 would be discussed afterwards.
 		noted No    
S3‑191863 Resolve EN on signaling details of how the UE hands over to false base station Huawei, HiSilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191864 Handover Attempts failure counter Huawei, HiSilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191865 Solution #4: Resolving EN on network verification of the hashes of MIB/SIBs Huawei, HiSilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191866 Solution #4: Resolving EN on Impact on UE power consumption Huawei, HiSilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191867 Solution #4: Details on the hash algorithm used for MIB/SIB hashes Huawei, HiSilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191868 Address EN in solution #1 Huawei, HiSilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191869 Enabling UE to detect FBS Huawei, HiSilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191870 Conclusion to KI #5 Huawei, HiSilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesDiscussed together with tdoc 2020. Ericsson: the solution will not make a difference if the attacker is a bit more sophisticated. Supported by Qualcomm.
 		noted No    
S3‑191871 Mitigate DDoS Attacks on RAN based on RAN coordination Huawei, HiSilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesSamsung didn’t agree with this.
 		noted No    
S3‑191872 New KI: Sleep deprivation attacks to CIOT terminals Huawei, HiSilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesNokia: this will not work as it is proposed. Intel agreed and commented that the UE has to wake up to verify the integrity protection anyway. Futurewei: 5G-TMSI cannot be leaked. They also disagreed with the contribution. Alf: delete requirements, keep the key issue for security analysis purposes. Ericsson: we agree with Futurewei, 5G-TMSI is sent after security activation. There was no support for this paper.
 		noted No    
S3‑191873 A solution to protect CIOT terminals from sleep deprivation attacks Huawei, HiSilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191874 Requirement for key issue 5 in TR 33.814 (FS_eLCS_Sec) Philips International B.V. pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesSprint: what about the fake measurements that are obtained by the UE but where the UE doesn't know that they are fake (e.g. spoofed messages)? Add a statement saying that the messages faked by the source are not covered. ESA: limit the scope of the requirement, as 5G positioning service can come from RAN dependent or RAN independent accesses. Ericsson: the solution for this problem doesn’t need to be standardised. Qualcomm: it's a "should" requirement and add mechanisms to ensure the reliability of the location. Alf: clarify which part needs to be standardised. Huawei: keep the requirement, watch the solution. Ericsson: we need to be specific on what problem needs to be solved.
 		noted No    
S3‑191875 New solution to key issue 5 in TR 33.814 (FS_eLCS_Sec) Philips International B.V. pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191876 Update of Solution #6 - Use of UE Configuration Update KPN pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191877 Update of solution #17 - Efficient key derivation for e2e security KPN pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No    
S3‑191878 AKMA solution set analysis KPN discussion Discussion
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		noted No    
S3‑191879 Proposal for editor's note in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesNokia didn’t agree with the change. Futurewei wasn't convinced about the way the editor's notes were handled either.The first two changes went away.
 		revised No S3‑192398  
S3‑191880 Proposal for FS_UP_IP_Sec Key Issue #3 and 5: Zero-overhead user plane integrity protection on the link layer Philips International B.V. pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesEricsson: this was already noted and our opinion is the same. Vodafone: this is technically correct and I see no reason not to document this solution. Qualcomm agreed with Ericsson. There were technical comments that haven’t been addressed. Philips: Technical comments have been taken care of. Nokia, Futurewei: remove the evaluation. Nokia: it affects multiple protocol stacks, PHY and MAC for sure.Add an editor's note on this. Qualcomm proposed several editor's notes to record their concerns.
 		revised No S3‑192422  
S3‑191881 [DRAFT] LS to SA2 for Moving Forward on Storing Authentication Data Hewlett-Packard Enterprise LS out Approval
7.1.8Primary authentication
 		Yes
Yes
 		noted No    
S3‑191882 [DRAFT] LS to CT4 for Moving Forward on Storing Authentication Data Hewlett-Packard Enterprise LS out Approval
7.1.8Primary authentication
 		Yes
Yes
 		noted No    
S3‑191883 DraftCR - update Annex B to support the authentication of non-3GPP UE CableLabs draftCR Discussion
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑191884 SoR-MAC-IUE verification failure handling by UDM NEC Europe Ltd CR Agreement
7.1.7Visibility and Configurability
 		Yes
YesThe Chair asked if this had impact on stage 3. NEC couldn’t answer. Ericsson: if it's a malicious AMF why it would forward the malitious message? Vodafone: if there is no match it would just fail. Qualcomm: this is a CT1 problem, not to be addressed here. Samsung added that this increased complexity.
 		not pursued No    
S3‑191885 Adding references, definitions and abbreviations to SCAS UDM NEC Europe Ltd pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		revised No S3‑192130  
S3‑191886 Adding introduction text to SCAS UDM NEC Europe Ltd pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		revised No S3‑192134  
S3‑191887 Adding content to clause 4.2.3, 4.3 and 4.4 in SCAS UDM NEC Europe Ltd pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		revised No S3‑192136  
S3‑191888 New test case to SCAS UDM: SoR-MAC-IUE verification failure handling NEC Europe Ltd pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		noted No    
S3‑191889 Discussion on AKMA overall conclusions NEC Europe Ltd discussion Endorsement
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesKPN disagreed with the contribution. Qualcomm: endorse proposal one. Nokia supported this. The Chair asked for a show of hands: ORANGE, Nokia, ZTE,Qualcomm,china mobile,Huawei, NEC supported proposal one. Ericsson, KPN,Gemalto, Vodafone didn’t support endorsing this.
 		noted No    
S3‑191890 Resolving Editor’s Notes and adding conclusion to solution #18 NEC Europe Ltd pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No    
S3‑191891 Resolving Editor’s Notes and adding conclusion to solution #20 NEC Europe Ltd pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191892 Editorial corrections of AKMA TR 33.835 v0.4.0 NEC Europe Ltd pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No    
S3‑191893 Editorial correction of TR 33.861 NEC Europe Ltd pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191894 Evaluation text for solution #5 in TR 33.825 NEC Europe Ltd pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191895 New Key Issue on Identification of Multiple NPN Subscriptions NEC Europe Ltd pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE: subscription to several PLMNs doesn’t mean that you are connected to all of them at the same time. The number of valid active contexts here does not correspond to what's agreed in SA2. Qualcomm: it's possible to have multiple subscriptions although is not standardized. This contribution on the other hand is out of scope of SA3. Interdigital was in favour of the contribution although with an editor's note. Ericsson didn't find this necessary either. Qualcomm, IDEMIA didn’t support it either.
 		noted No    
S3‑191896 Solution for Identification and Selection of Multiple NPN Subscriptions NEC Europe Ltd pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191897 New Key Issue on separation and storage of multiple NPN credentials NEC Europe Ltd pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE: we have decided not to handle the storage of security credentials.Qualcomm, Gemalto agreed. NEC: the intent is different, it's about how to store.
 		noted No    
S3‑191898 Solution for separation of multiple NPN credentials NEC Europe Ltd pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191899 New solution for KI #4 NEC Europe Ltd pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesQualcomm: too much high level. More detail is needed. An editor's note was added to detail this better in the future. Telecom Italia: I don’t understand bullet 3 in 6.x.3.
 		revised No S3‑192423  
S3‑191900 Proposed solution to key issue 6.3 on modifying the CAG list Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191901 Security for non-public networks Qualcomm Incorporated, Nokia, Nokia Shanghai Bell draftCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE needed more differentiation between non-standalone and standalone networks. This had to be taken offline.
 		revised No S3‑192453  
S3‑191902 Proposed conclusion details for key issue #1.1 in TR 33.819 Qualcomm Incorporated, Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191496
S3‑191903 Proposed updates to the draft CR on SRVCC from 5G to UTRAN CS Qualcomm Incorporated other Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesDeleting the editor's note that’s being modified by China Unicom in 2012.
 		revised No S3‑192336  
S3‑191904 Assigning a FC value to TS 33.501 for K5GSRVCC calculation Qualcomm Incorporated CR Agreement
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		revised No S3‑192337  
S3‑191905 Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC Qualcomm Incorporated CR Agreement
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		revised No S3‑192338  
S3‑191906 Revision of SRVCC WID Qualcomm Incorporated WID revised Agreement
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesORANGE: it doesn’t make sense to keep the UICC being modified "don’t know". IDEMIA and Gemalto disagreed with having to revise the WID to change the impact.
 		agreed No    
S3‑191907 Key issue on protecting the SQN during a re-synchronisation procedure in AKA Qualcomm Incorporated pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
YesNCSC supported Qualcomm. Apple supported the solution. It was agreed to modify the requirement to replace void with "should protect against the effect of". Qualcomm commented that this meant updating the SID since it was very specific in its scope.This could be done for the next meeting.
 		revised No S3‑192433  
S3‑191908 Using MACS to provide freshness for the protection of SQN during a re-synchronisation procedure in AKA Qualcomm Incorporated pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191909 Evaluation of the integrity protection provided by EDT solutions #4 and #18 Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei: in LTE the air interface has no user plane,there is no such bidding down attack. The LTE technology does not support integrity protection. Qualcomm: integrity protection is added in order to have it modified it over the air. Why are we having integrity protection then?
 		noted No    
S3‑191910 Adding some details to solution #10 on protecting S-NSSAI at AS layer Qualcomm Incorporated pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia didn’t find this very clear. The procedure to allocate and refresh the needed parameters needs to be clarified. An editor's note was added for this. Interdigital: add an editor's note on the encrypted NSSAI per UE. They were also concerned on the possibility of user tracking.
 		revised No S3‑192373  
S3‑191911 Discussion on possible solutions to AMF relocation issues Qualcomm Incorporated discussion Endorsement
7.1.5NAS security
 		Yes
YesOverlaps with 2148.Huawei didn’t agree and preferred to go for their proposal in 2148.
 		noted No    
S3‑191912 Missing security context handling during registration procedures Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
Yes
 		agreed No    
S3‑191913 Evaluation of solution #5: Security for redundant data transmission Qualcomm Incorporated, Ericsson, Nokia pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192347  
S3‑191914 Conclusion on KI #1 for Study on the security for URLLC Qualcomm Incorporated, Ericsson, Nokia pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
YesDiscussed together with tdoc 2120.
 		revised No S3‑192348  
S3‑191915 Conclusion on KI #2 for Study on the security for URLLC Qualcomm Incorporated, Ericsson, Nokia pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
YesDiscussed together with tdoc 2122. Huawei: make it more generic, not only over-the-air.
 		merged No S3‑192349  
S3‑191916 Issues of resetting NAS COUNT values in 5G to 4G mobility Qualcomm Incorporated discussion Endorsement
7.1.10Interworking
 		Yes
YesQualcomm insisted that there was an issue to be considered here.
 		noted No    
S3‑191917 NAS Count values in the mapped EPS security context in 5GS to EPS change Qualcomm Incorporated CR Agreement
7.1.10Interworking
 		Yes
YesEricsson: The COUNT value was created for replay protection. If we set the values the same as in 4G we'll be having some issues. Qualcomm: our choice is the simplest, otherwise we need to address this in other WG's specs like CT4. The MME is not aware about the idle mobility between 5G and 4G, for the MME we are only in 4G. This had to be taken offline.
 		not pursued No    
S3‑191918 Evaluation of solution #4.1: F1 interface security for IAB Qualcomm Incorporated pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		revised No S3‑192414  
S3‑191919 Conclusion of KI #4.1: F1 interface security for IAB Qualcomm Incorporated pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesHuawei: too early to reach a conclusion. Samsung: we support this contribution. AT&T as well as they believed this needed to be finished in a timely manner.
 		approved No    
S3‑191920 Solution for integrity protection of EDT Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesFuturewei objected to having this solution because there was a whole study item dedicated to this: user plane integrity protection. This didn’t belong here. Qualcomm: Evaluation in solution 4 and 18 that there is a bidding down risk but we don’t have proper protection against that. Qualcomm: what is the key issue for? Futurewei: it's for when we don’t use the user plane integrity protection completely. Intel supported Qualcomm but proposed to add the evaluation later when the UP IP study had a conclusion.
 		noted No    
S3‑191921 Evaluation against MitM false base station attacks Qualcomm Incorporated discussion Endorsement
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191922 Evaluation of the shared key based MIB/SIB protection solution Qualcomm Incorporated pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑191923 Reply LS on handling of native non-current 5G NAS security context Qualcomm Incorporated LS out Approval
7.1.10Interworking
 		Yes
YesQualcomm: The problem is that there is integrity protection in the Registration request only when there is a native 5G security context. When moving from 5G to 4G the UE shall discard the 5G security context to avoid problems. This wasn't clear for Huawei.
 		revised No S3‑192279  
S3‑191924 Ciphering of broadcast assistance data for UE-based positioning Qualcomm Incorporated discussion Decision
6.13GPP Working Groups
 		Yes
YesEricsson: integrity protection is needed. Qualcomm replied that the agreement was that integrity protection was not needed. Interdigital: passive attacks are considered? When the UE is receiving coordinates from the gNodeB?. Qualcomm: high location accuracy is needed for some Ues, apps or the operator. Access control is for Ues that are subscribed for it. This is an use case that needed cyphering. Alf (Docomo): keystream could be used for something else. A predicted or extracted keystream should be looked at. Vodafone: publishing the location of the gNodeBs is a usual procedure among operators. It's publicly available data. Qualcomm: there is no security risk when using cyphering the static broadcast assistance data. Ericsson: add a reminder that Unicast uses NAS security and integrity protection can be added.
 		noted No    
S3‑191925 Proposed conclusion for PARLOS Qualcomm Incorporated, Intel, Samsung, Sprint, Verizon UK Ltd pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesAdd an editor's note on the mitigations. Second part was removed. It was asked to be minuted: The group agreed that solution one is considered to be too complex to be the way forward.
 		noted No    
S3‑191926 pCR: Resolution of EN in Solution 2 evaluation Qualcomm Incorporated, Intel, Samsung, Sprint, Verizon UK Ltd pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191927 A key issue on forward secracy Huawei, HiSilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
YesVodafone: LTKUP mitigates this in a separate study.
 		noted No    
S3‑191928 A solution to forward secracy Huawei, HiSilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191929 Conclusion to KI #1 (slice authentication) Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: not right for key issue 1.
 		revised No S3‑192366  
S3‑191930 Conclusions to KI#2 (AMF Key separation) Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192367  
S3‑191931 Conclusions to KI#3 (NSaaS) Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191932 Add evalution to solution 3 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesORANGE objected to having this approved and preferred to to postpone the evaluation.There are some considerations in the solution that haven’t been sufficiently assesed.
 		noted No    
S3‑191933 Amendment to solution 6 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: what is being protected here? Is there any additional protection apart from NAS security? Huawei: EAP mechanisms. Qualcomm: this breaks the EAP model. You cannnot encypt the EAP ID (which is the user ID) you cannot do any routing. ORANGE: we don’t have stable requirements today that justify the statement "meets the requirement of the key issue". This was left open.
 		noted No    
S3‑191934 Solution details on solution 8 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: RAND per UE or per NSSAI? Huawei replied that per UE. Nokia suggested that this would have to be clarified. Ericsson: if the UE goes to IDLE and the RAND removes the context? Huawei: you would need to restart.
 		revised No S3‑192371  
S3‑191935 Evalution for solution 8 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: Complexity in gNB needs to be considered. Qualcomm: add an editor's note on what happens when the UE changes of NG-RAN node.
 		revised No S3‑192372  
S3‑191936 Requirements on UDM/ARPF Gemalto, Nokia CR Approval
7.1.8Primary authentication
 		Yes
YesORANGE: why are the UDM and ARPF together? Nokia: we are not consider them as separate identities and SA2 is wrong in their specification. Vodafone didn't support the CR. The main issue comes from the virtualization, and the virtualization study should take care of this. The same with the following CRs. Alf(Docomo): we would need a WID to have something normative agreed in Rel-16. I'd rather have a separate SID rather than putting it into the virtualization. The Chair commented that the objective was to create CRs to follow SA's guidance on the Release 15 open issues. Alex (BT): this CR doesn't fix the security issue requested in SA, which is the key storage not being done somewhere else necessarily ideal. This is not easy work and it needs further consideration. He suggested to drop the standardization in Rel-15 and fix it properly in Release 16. That would save a lot of time. Telecom Italia: practical consequences of doing nothing? The Chair understood that there would be none. Alex: the risk exists in 4G equally.In practical terms for the implementations in Rel-15 is to reduce the level of virtualization in some of the interfaces around ARPF. We leave it to the vendors to solve this. This was left open for offline discussion.
 		not pursued No    
S3‑191937 Requirement on authenticating unpublish requests Ericsson CR  
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16)
 		Yes
YesSamsung: we don't need this requirement, it’s already covered.
 		not pursued No    
S3‑191938 Nokia comments on R2-1908467 reply LS to GSMA UE capability Nokia discussion Endorsement
6.10CVDs and Research
 		Yes
YesFuturewei supported this proposal.
 		noted No    
S3‑191939 Nokia comments on GSMA LS on UE radio capability exchange Nokia discussion  
6.10CVDs and Research
 		Yes
YesORANGE: what's the privacy issue? Nokia: fingerprinting of the device. The device type can be identified, software version, capability. Also whether the user has instantiated a particular application, watssapp or whatever. ORANGE: for 5G the IMSI is cyphered, not the same problem. We cannot hide the IMSI so it's not possible to provide backward compatibility in 4G. Besides, in Nokia's examples of privacy issues the user's identity is never exposed. Futurewei: this has been discussed before with RAN2. They don’t have a problem with mandating for the security in the Uecapabilityenquiry procedure. NTT-Docomo: I agree with the issue in 5G with device fingerprinting.
 		noted No    
S3‑191940 Nokia comments on GSMA LS on UE radio capbility exchange Nokia, Nokia Shangahi Bell LS out Approval
6.10CVDs and Research
 		Yes
Yes
 		noted No    
S3‑191941 Nokia comments on R2-1908473 UE DL assistance data. Nokia, Nokia Shanghai Bell discussion Discussion
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑191942 Draft reply LS on R2-1908473 UE DL assistance data. Nokia , Nokia Shanghai Bell LS out  
6.13GPP Working Groups
 		Yes
Yes
 		revised No S3‑192268  
S3‑191943 Nokia comments on R2-1908264 LS on RRC Connection Re-establishment Nokia, Nokia Shanghai Bell discussion Discussion
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei: this is not a security perspective. Nokia: without an ID the solution will not work.
 		noted No    
S3‑191944 Way forward on Emergency solution for PARLOS Nokia, Nokia Shanghai Bell pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesDocomo: part of the evaluation contains part of the solution. An editor's note was added for this.
 		revised No S3‑192380  
S3‑191945 Addressing EN in solution#1 Nokia, Nokia Shanghai bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesLenovo: You don’t want the serving network know all users' IDs. Huawei: this solution provides protection of User ID for the slice authentication between UE and serving network. This statement was added.
 		revised No S3‑192363  
S3‑191946 2. Addressing EN in KI#4. Nokia, Nokia Shanghai bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesLenovo: editor's note not addressed properly. The user could be compromised by the AMF and over the air protection would not be enough. Qualcomm: we have a big problem if the AMF is compromised, it is trusted.
 		noted No    
S3‑191947 Adding text to Clause 9 Recommendations Nokia, Nokia Shanghai Bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192376  
S3‑191948 Draft WID for normative work on eNS. Nokia, Nokia Shangahi Bell WID new Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesHuawei: make it more generic. Vodafone preferred to have it more specific, more detailed. ORANGE: no reference to SA2's work. MCC commented that this was a feature, not a WID. They added that the normative CRs in 33.501 would be part of the objectives and not the justification. The SA2 work in parent WIDs table should be added in the related work items.
 		revised No S3‑192377  
S3‑191949 DraftCR - update Annex B to support the authentication of non-3GPP devices CableLabs, Charter, Nokia, Nokia Shanghai Bell draftCR Discussion
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192283  
S3‑191950 Evaluation to Solution 6.6 Intel China Ltd. pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191951 Security solution for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) with legacy fall back Intel China Ltd. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑192328  
S3‑191952 Evaluation to Security solution 4 for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) Intel China Ltd. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191953 Evaluation to Security solution 18 for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) Intel China Ltd. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		merged No S3‑192401  
S3‑191954 Clarification of NIA0 with SgNB for UE NR capability Intel China Ltd. CR  
7.8.1SAE/LTE Security
 		Yes
YesEricsson: there is impact on CT1. Qualcomm was fine with the change.
 		agreed No    
S3‑191955 Clarification on Procedure for steering of UE in VPLMN during mobility registration update Intel China Ltd., NEC CR  
7.1.7Visibility and Configurability
 		Yes
YesQualcomm: this scenario doesn’t apply here. Vodafone agreed; this only takes place in the initial registration.
 		not pursued No    
S3‑191956 Security solution for UE to avoid connecting to the false base station during a handover procedure Intel China Ltd. pCR  
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191957 Update of key issue #2 on PC5 unicast mode LG Electronics pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQualcomm: rewording of requirements would be benefitial.
 		revised No S3‑192420  
S3‑191958 Solution for security of V2X service authorisation LG Electronics pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑191959 Discussion on the reply LS for PC5 unicast groupcast security protection LG Electronics discussion Discussion
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑191960 Reply LS on PC5 unicast and groupcast security protection LG Electronics LS out Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		revised No S3‑192421  
S3‑191961 Add abbreviation and correct references Futurewei Technologies CR Agreement
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		agreed No    
S3‑191962 pCR to TR33.814 - Key issue for the ciphering key management of broadcast assistance data CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesEricsson, Qualcomm: this is not needed. Nokia: SA2 hasn’t decided whether the key is stored in the AMF yet. We don’t support this document.
 		noted No    
S3‑191963 Solution for anchor keys security Gemalto N.V. pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191964 Mitigation against linkability issue Gemalto N.V. pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191965 pCR to TR33.814 - The solution for the ciphering key management of broadcast assistance data CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191966 pCR to TR33.814 - The analysis of security architecture of eLCS CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesEricsson didn’t agree with this.
 		noted No    
S3‑191967 pCR to TR33.814 - Conclusions for TR33.814 CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesHuawei: let's go through the evaluations first before approving this conclusion. Alex (BT): the second point should be something like "no new mechanisms are needed". Dependent on tdoc 2076.
 		revised No S3‑192362  
S3‑191968 pCR to TR33.814 - Add reference for TR 33.814 CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑192359  
S3‑191969 pCR to TR33.814 - Addition of definition and abbreviation CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191970 New SID on Study on user plane security termination point in 5GC CATT, China Unicom, Qihoo360 SID new Approval
8.23New study item proposals
 		Yes
YesORANGE: UP protection protect the data sent over the air only.Is this protection to be built on top of the current protection or to be a replacement? If it's a replacement, we need to see how and who's providing the keys and this has legal implications. I don’t think we are going anywhere with this. Qualcomm: it would be part of the study. Vodafone: EN-DC already does this. Qualcomm: there is a need for this, and it's not intended to be a replacement. Solutions should be restricted to the UPF. If this is the case we will support. Huawei: this may not meeting LI requirements. It's problematic. Nokia: this was studied in SA2 in CIoT. They didn't go along wih these proposals for Rel-16. Work should start in SA2 and then we will follow. Alf (Docomo): I don’t see the problem with LI. I don’t think there is time for this now and this is a proposal for Rel-17. I disagree with having SA2 starting the job. ORANGE and Huawei objected to this. Interdigital and Qualcomm conditionally supported this. The Chair wondered if it was appropriate to start bringing Rel-17 WIDs at this stage where priority relied on Rel-16 work. Eventually this was noted.
 		noted No    
S3‑191971 length of ARFCN-DL ZTE Corporation CR Agreement
7.1.2Key derivation
 		Yes
YesVodafone: Why is the length coded in two bytes? What's the point of the first 00? Qualcomm: it was defined like that (look at L0). Nokia: this is not a new parameter, why do we need a new definition?
 		agreed No    
S3‑191972 uplink NAS Count for KeNB derivation in idle mode mobility to EPS ZTE Corporation CR Agreement
7.1.3Mobility
 		Yes
YesOverlap with tdocs 1916,1917. This had to be taken offline.
 		not pursued No    
S3‑191973 CAG ID privacy ZTE Corporation discussion Discussion
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191974 Security threats and requirements on CAG ID privacy ZTE Corporation pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192343  
S3‑191975 Structure RAND for authentication ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191976 Handling of Sync failure ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191977 Modification on linkability issue1 ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
YesVodafone: why the change in the clause numbering? Zte: just correcting a mistake. Vodafone: why is the requirement deleted? ZTE: this was hard to achieve. Gemalto: no need to remove the requirement. Vodafone: the new text needs rewriting.
 		revised No S3‑192431  
S3‑191978 Conclusion on linkability issues ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191979 uplink NAS Count for Kasme derivation in idle mode mobility to EPS ZTE Corporation CR Agreement
7.1.6Security context
 		Yes
YesSuresh (Nokia) didn’t agree with this change. ZTE: we guarantee that we use always the same value this way when the last COUNT is increased. Huawei: we agree with the problem they're trying to solve, not with the solution here.Scenario too specific, NAS uplink count value would be the more generic problem. It was agreed the existence of the problem, but the resolution/clarification needed to be taken offline.
 		revised No S3‑192284  
S3‑191980 Conclusion on Key Issue #7 Lenovo, Motorola Mobility pCR  
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEricsson: the conclusion is better rely on existing mechanisms. Nokia: this is not necessary.
 		noted No    
S3‑191981 Removal of Editor’s Notes of solution #5 Lenovo, Motorola Mobility pCR  
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesORANGE: considerations of provisioning of public keys are being made when removing these editor's notes. We need to add a note on saying that these mechanisms will not be studied. The contribution found some additional opposition and it was finally noted.
 		noted No    
S3‑191982 Update of Solution #15 Lenovo, Motorola Mobility pCR  
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191983 Conclusion for Key Issue #6 Lenovo, Motorola Mobility pCR  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191984 Discussion on UDM-UDR-ARPF issues Nokia, Nokia Shanghai Bell discussion Endorsement
5Items for early consideration
 		Yes
YesVodafone found quite a lot to disagree in here. The document seems to imply that we take the SA's view as long term. The Chair clarified that SA3 will follow the guidance of SA in Rel-15. There is no choice here. Some proposals wanted to add something in Rel-15, some proposals said that nothing should be done in Rel-15. Vodafone: implementation problems as Rel-15 is showing now. Gemalto: Authentication data and suscription credentials are different concepts and SA is confusing them. Vodafone: there is a problem with addressing the storage of sensitive data in the UDR or proprietary repository. China Mobile: Rel-15 is frozen in SA3 too, no need to change anything in there. ORANGE: the definition of subscription credentials need to change. Georg Mayer (SA Chair) commented that these were defined in CT4 specifications. The deployment may be done differently but then they would not follow CT4 specs. Extending the definition or putting a note would be helpful. ORANGE: add a note: "Security storage in the UDR is out of scope of this document". Anders (HP): we cannot say all storage is out of scope.
 		noted No    
S3‑191985 Material related to UDM-ARPF-UDR discussion Nokia, Nokia Shanghai Bell discussion Information
5Items for early consideration
 		Yes
Yes
 		noted No    
S3‑191986 Definition of authentication subscription data Nokia, Nokia Shanghai Bell CR Agreement
7.1.8Primary authentication
 		Yes
YesDocomo: second change should not be part of a definition, it's a requirement. Alf (Docomo): on the subscription credential(s) definition: these kind of discussion should not happen in a definition clause. This is not even a proper defintion format. The first definition on authentication subscription data was also discussed. Vodafone and MCC expressed their concerns that the definition was not used anywhere in the specification. Telecom Italia: a list of full parameters that are subscription credentials cannot be even agreed in SA3 so we cannot expect that CT groups assume them. Telecom Italia wished that it was clear for the operator that the security processes in the second note were not described anywhere else. MCC also noted that the term "in the present release" was redundant and just saying "not defined" would be clear enough.
 		revised No S3‑192276  
S3‑191987 Removal of Editor’s Note and Addition of Evaluation Lenovo, Motorola Mobility pCR  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192386  
S3‑191988 Conclusion for Key Issue #5 Lenovo, Motorola Mobility pCR  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191989 Living doucment for 5G_UTRAN_SEC China Unicom draftCR  
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesEricsson noted that this needed to show the changes are revision marks.
 		revised No S3‑192335  
S3‑191990 New solution (SERSI - SERving network controlled SI signatures) Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesFuturewei didn’t agree with the new solution, only the delta should be shown. Ericsson: we have shown different aspects of the same solution in other TRs. Apple supported this solution. ORANGE: protection before the first registration is not covered. There was some strong disagreement with some other parts and the document was noted.
 		noted No    
S3‑191991 Conclusion on KI#3'S second requirement (reactive action) Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191992 Proposal for handling of UE radio network capabilities in 4G and 5G Ericsson discussion Endorsement
6.10CVDs and Research
 		Yes
YesFuturewei supported proposal 1 and 4. ORANGE: combine 1 and 2 in a new proposal 5. Nokia: proposal 2 doesn’t address the issue and 3 is a new issue. Vodafone also liked proposal 1. The Chair saw that most companies supported proposal 1. Qualcomm liked proposal 2, Docomo supported proposal 1 and 2. In case RAN2 had issues with proposal 2, the shalls could be replaced with "should".
 		noted No    
S3‑191993 URLLC: Recommendation for KI#3 Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑192357  
S3‑191994 URLLC: Table with available solutions in the TR Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192346  
S3‑191995 Recommendation to run AKA after IW HO from 4G to 5G Ericsson CR Agreement
7.1.10Interworking
 		Yes
YesNokia: why the recommendation? Ericsson: this is due to the written text under step 10. To take care of the "else" part of this statement. ORANGE wanted to add some statement for the operator. Vodafone: if we have a mapped 5G security context recommended at some point in the authentication why does it go here? Huawei: this is not needed. Docomo: we agreed not force this reauthentication. If you come from a mapped 4G context that is coming from a mapped 5G context you would need this. An operator recommended policy would have an unclear situation where to be applied. It was agreed to refer to the operator's policy and what triggers this. Docomo add a note about the reason for the triggering being the mapped context coming from the 3G context, otherwise there is no way of tracking why we are doing this whenever operators are switching off the 3G network. Nokia commented that this would give an additional requirement on the AMF. This was taken offline.
 		revised No S3‑192285  
S3‑191996 Co-existence of LTKUP and PFS Ericsson discussion Discussion
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191997 New KI: Leakage of long-term key Ericsson pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
YesVodafone: very improbable case which will require a substantial amount of work. ORANGE supported this. Alex (BT): the only way of attacking here would be not to secure the UDR.
 		noted No    
S3‑191998 New solution: EAP-AKA´ PFS Ericsson pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191999 Correction of reference to draft-ietf-emu-rfc5448bis Ericsson CR Agreement
7.1.8Primary authentication
 		Yes
YesQualcomm didn't agree with the change. No update here until the IETF document is updated. The change should also be done in Rel-16. not Rel-15. Qualcomm: leave the annex F as it is in Rel-15. As for the rest, wait until the IETF is updated. ORANGE supported this. China Mobile: we don’t reference drafts in 3GPP. The Chair clarified that this draft-referencing was currently done in 3GPP. The Chair added that the use of a reference in an editor's note was incorrect according to the current procedure with CT1. Qualcomm: delete the editor's note in Release 15 and follow Annex F; come back with this issue in Release 16, where it will not produce any issues. This was kept open in order to resolve the reference issue. Finally not pursued but he way forward will be performed for the next meeting.
 		not pursued No    
S3‑192000 Solution 2 evaluation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: second bullet point in the advantages needs to go away. Qualcomm: authentication procedure overhead needs to be pointed out.
 		revised No S3‑192450  
S3‑192001 Solution 3 evaluation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		revised No S3‑192451  
S3‑192002 Solution #15 updates including evaluation update Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑192003 Solution #13 evaluation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑192004 Security handling in registration procedure at AMF reallocation caused by slicing Ericsson discussion Endorsement
7.1.3Mobility
 		Yes
Yes
 		revised No S3‑192262  
S3‑192005 New solution: Integrating GBA to 5GC Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		revised No S3‑192263  
S3‑192006 STRIDE diagram for the gNB Ericsson discussion Discussion
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
YesHuawei: Is this for the TR or TS? Ericsson: this is for discussion purposes only. Assest and threats would be the next step.
 		noted No    
S3‑192007 Discussion Document on the evolution of BEST VODAFONE Group Plc discussion Discussion
7.8.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑192008 WID on BEST Test Specificationd for HSE and UE VODAFONE Group Plc WID new Agreement
7.8.16Other work items
 		Yes
YesQualcomm: test specs are developed in RAN5. Vodafone: we did it for TUAK and all algorithms we've had in the past. Qualcomm: test specs that we agree that are in our scope.RAN5 write tests not only for RAN, but for other groups.Interoperability and protocol performance test cases are done in RAN5. They even have for IMS. Interdigital agreed. Vodafone: RAN5 has no expertise for this work. Alf (Docomo): ask RAN5 with an LS. Vodafone: we will not go to RAN5 under any circumstances. MCC: this cannot be done for Release 15 as a Rel-16 version of TS 33.163 already exists and the work will be done there. This had to be taken offline.
 		noted No    
S3‑192009 pCR to TR33.935 - Addition of Diffie - Helman Key agreements section VODAFONE Group Plc pCR Agreement
8.16Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑192010 Rename the derived key China Unicom draftCR  
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		merged No S3‑192336  
S3‑192011 SRVCC keys China Unicom draftCR  
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192012 key generation in MME_SRVCC China Unicom other  
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesQualcomm: this implies additional signalling that we don’t need. It overlaps with our proposal in 903. It was agreed to go for Qualcomm's contribution that deleted the editor's note where both overlapped.
 		noted No    
S3‑192013 CIoT: Update to Solution #18 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesFuturewei: "potential enhancement" is not referring to anything. I'm against this. Remove reference to key issue integrty protection. This was agreed.
 		revised No S3‑192400  
S3‑192014 CIoT: Evaluation to Solution #18 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesOverlapping with 806, 953.
 		revised No S3‑192401  
S3‑192015 CIoT: Conclusion to KI#2 and KI#3 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192016 CIOT: add evaluation to solution #4 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192017 CIOT: Optional support of RRC Inactive in eMTC connected to 5GC Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesFuturewei: If you read RAN2 agreement, NB-IoT is not supported.
 		noted No    
S3‑192018 CIOT: New solution for UP IP in PDCP to protect UL EDT data in Msg3 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192019 DDoS protection based on NWDAF and Overload Control Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei: out of scope of this key issue. The key issue is about how to detect and what to do after detection.
 		noted No    
S3‑192020 Conslusion for KI#5 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192021 Conslusion for KI#4 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesSupported by Nokia.
 		noted No    
S3‑192022 Adding evaluation and resolving EN in Solution 7 Ericsson pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesORANGE: remove the evaluation. We don’t have the requirement for this. Huawei agreed with the document.
 		revised No S3‑192369  
S3‑192023 Discussion paper on NSSAI in AS layer protection Ericsson pCR Discussion
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesORANGE: encrypting the NSSAI brings a lot of overhead.
 		noted No    
S3‑192024 Conclusion on KI#1 (bluetooth positioning) Ericsson pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192025 Conclusion on KI#2 (TBS positioning) Ericsson pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192026 Conclusion on KI#3 (WLAN positioning) Ericsson pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192027 Resolving EN in KI#4 Ericsson pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesHuawei: don’t remove "system". Qualcomm: the 5GS includes the UE and the core network, we don’t need the change. The editor's note can be removed. Alex (BT): LCS is a server-control applicationwhereas this reads like the UE will implement the provacy and user's consent in the handset. Qualcomm: SA2 has done this work already, no need to work on this requirement anymore. Huawei supported this.
 		noted No    
S3‑192028 Conclusion on KI#4 (privacy control) Ericsson pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesHuawei, Qualcomm didn’t agree as it was covered by SA2 already.
 		noted No    
S3‑192029 New KI: Protection of recovery from backhaul-RLF Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesFuturewei: Why is RLF recovery mechanism signalled? Ericsson: this is done below F1 interface IPSec. Futurewei: remove security threats and requirements. Add "reference to transportation layer for RLF recovery messages is FFS". Samsung: communication between the nodes to be confirmed with RAN2.
 		revised No S3‑192407  
S3‑192030 New solution: Secure recovery from backhaul-RLF Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑192031 Update to solution #2.1 (Authentication and authorization of IAB Node) Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesORANGE: IAB nodes are authenticated to the Home network, into the UDM. IAB nodes are like Ues but the storage is not handled at all. The credentials for the IAB node are handled like the UE? This is not mentioned here. Futurewei: why are not we referencing the clauses and now it's the whole specification? Samsung supported this. Telecom Italia: why are the other clauses of other specifications staying?
 		revised No S3‑192408  
S3‑192032 New solution on authentication and authorization of IAB Node in 5G Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑192033 New solution: Token-based authorization for Scenario D using stateless SeCoP Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192439  
S3‑192034 New solution: Token-based authorization for Scenario C using stateless SeCoP Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192440  
S3‑192035 Correction of implementation of S3-191671 Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑192036 UP IP: New key issue for UE indicating support of UP IP in NR PDCP with a ng-eNB connected to 5GC Ericsson pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesQualcomm: we need the key issue but it is valid for all options except option 2. Remove all references to NR PDCP, it should be E-UTRAN. Qualcomm: clarify what UE we are talking about in the requirement.
 		revised No S3‑192425  
S3‑192037 Corrections on IP packet forwarding Ericsson CR Agreement
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No    
S3‑192038 Corrections on IP packet forwarding Ericsson CR Agreement
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192319  
S3‑192039 Corrections on IP packet forwarding Ericsson CR Agreement
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192320  
S3‑192040 Threat analysis for OAM configurator spoofing Ericsson discussion Discussion
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		noted No    
S3‑192041 Living document: generic assets and threats Ericsson draftCR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192321  
S3‑192042 STRIDE diagram for the AUSF Ericsson discussion Discussion
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes
 		noted No    
S3‑192043 Attack tree for sensitive data in AUSF Ericsson discussion Discussion
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes
 		noted No    
S3‑192044 AUSF assets and threats Ericsson discussion Discussion
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes
 		noted No    
S3‑192045 Living document: AUSF aspects in 33.926 Ericsson draftCR Approval
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
YesOverlap with tdoc 172.
 		merged No S3‑192302  
S3‑192046 Requirements for credential storage in the UDR Ericsson CR Agreement
7.1.8Primary authentication
 		Yes
YesVodafone: not for Rel-15, but good input for virtualization.
 		not pursued No    
S3‑192047 New WID on evolution of Cellular IoT security for the 5G System Ericsson WID new Agreement
7.9New Work Item proposals
 		Yes
YesVodafone: the WID doesn’t detail enough the justification and objectives. MCC agreed, it seemed too brief and it needed some more wording.
 		revised No S3‑192354  
S3‑192048 Scope of a SECAM SCAS for 3GPP virtualized network products China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192049 TR terminology Nokia, Nokia Shanghai Bell discussion Endorsement
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192050 Cleaning of 33819-040 Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192051 Headline clash in TR resolved Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192052 Mandating time based generation of SQNs Nokia, Nokia Shanghai Bell CR Agreement
7.1.1Key hierarchy
 		Yes
YesEricsson didn't agree with this recommendation. There are problems in the deployments when having different clocks. There are other ways of mitigating this attack. Qualcomm: our understanding was to enhance the authentication to address this problem. We have a key issue related to this for the study item. It was agreed to follow this in the related study work.
 		not pursued No    
S3‑192053 Requirement on UDR Nokia, Nokia Shanghai Bell CR Agreement
7.1.8Primary authentication
 		Yes
YesTelecom Italia: the "e,g, permanent key" is not enough. We are not being precise enough. Alex (BT): the requirement should be on the subscription to the UDR data only. And the authentication is separable from the authentication of any other type of data.
 		not pursued No    
S3‑192054 Missing UDR description in alignment with 29.505 Nokia, Nokia Shanghai Bell CR Agreement
7.1.8Primary authentication
 		Yes
YesORANGE: having the "may be stored in the UDR" means that it is possible to store it somewhere else than the UDM. We need to require the storage somewhere with a "shall". Vodafone objected to this contribution as well.
 		not pursued No   S3‑191420
S3‑192055 Update on ARPF Nokia, Nokia Shanghai Bell CR Agreement
7.1.8Primary authentication
 		Yes
YesVodafone: same comment as the previous CR. We only need to change the definition. Alex (BT): UDM cannot encrypt this. ORANGE didn’t agree with the second change at all. This had to be taken offline.
 		not pursued No    
S3‑192056 Adding Nudr service Nokia, Nokia Shanghai Bell CR Agreement
7.1.8Primary authentication
 		Yes
YesORANGE: don't agree with the bullet "identifier store in UDM/ARPF…". It's implementation specific. Nokia: this is what's done in CT4. China Mobile: this looks like a new feature rather than a correction. Vodafone rejeted the document.
 		not pursued No   S3‑191421
S3‑192057 LS-UDR Nokia LS out Approval
5Items for early consideration
 		Yes
Yes
 		noted No    
S3‑192058 NPN references in existing text Nokia, Nokia Shanghai Bell CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE didn't agree with this CR. There was no previous agreement on adding an Annex.They had some other issues that were shared by Gemalto.Vodafone didn’t agree with referencing to Annex Z this way. Anja(Nokia) commented that she would bring another proposal for the next meeting. Gemalto: each time there's a new annex, the 5G core part would be impacted and we would need to be changing it constantly.
 		not pursued No    
S3‑192059 Key issue on Secure device identity creation for constrained devices Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192060 Secure device identity creation for UEs in SNPNs Nokia, Nokia Shanghai Bell pCR Endorsement
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192061 Scope of SECAM evaluation for 3GPP virtualized network products China Mobile, Nokia, Nokia Shanghai Bell pCR  
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑192062 Scope of SECAM evaluation for 3GPP virtualized network products China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192063 Scope of SECAM Accreditation for 3GPP virtualized network products China Mobile pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
YesAlex (BT) disagreed. This is outside of the scope of the 3GPP, and he didn’t agree with the new text in the gap anlysis. An editor's note was added on the evaluation of the differences between the two types of network classes for acreditation purposes.
 		revised No S3‑192436  
S3‑192064 Adding roles in SECAM for 3GPP virtualized network products into clause 4.6 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
YesAlex (BT): more of an answer, not a real gap analysis.The text doesn’t fit the title. ORANGE: the text needs a language check. ORANGE: remove the last clause. Added a new editor's note on further analysis needed as well.
 		revised No S3‑192437  
S3‑192065 Resovle Editor's notes in Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑192066 mitigate the linkability attack Huawei, Hisilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑192067 Dicussion on security handling after voice call ends Huawei, Hisilicon discussion Endorsement
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesAlex (BT): the call drops down to the lower technology and stays down as agreed in SA. This is against that and I object to this proposal.
 		noted No    
S3‑192068 security handling after voice call ends Huawei, Hisilicon CR Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		not pursued No    
S3‑192069 Address EN in key issue 5 Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192070 A solution to identify UEs that provides faked/altered location estimate or measurements Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192071 Delete EN in solution12 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192072 A solution to MIB and SIB protection Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192073 Clarification on length of EARFCN-DL in key derivation Huawei, Hisilicon CR Approval
7.1.2Key derivation
 		Yes
YesRelated to tdoc 1971 (ZTE).
 		not pursued No    
S3‑192074 KI on protection of F1-U Huawei, Hisilicon pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑192075 KI on toplogy discovery Huawei, Hisilicon pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesNokia: configuration issue, this topology discovery is not needed. It was agreed to remove the requirement.
 		revised No S3‑192405  
S3‑192076 Add evualtion to solution 4 Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesAlex (BT): we have to assume that the serving network is behaving. This and other remarks were added into the evaluation.
 		revised No S3‑192361  
S3‑192077 Add requirement to KI#2 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192078 Add threat and requirement to KI#10 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192079 Add requirement to KI#12 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE, Ericsson: we need a threat for this requirement.
 		revised No S3‑192388  
S3‑192080 Add threat and requirement to KI#11 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192387  
S3‑192081 Add requirement and delete EN for KI#14 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE: Keep the key issue and say that the scenario is not in scope of this document.
 		revised No S3‑192390  
S3‑192082 Add requirement and delete EN for KI#15 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192083 Delete Editor's in Solution#3 and add evaluation Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesDiscussed with 2222 and 2223. Vodafone: we shouldn’t write in a spec that we need input from BBF unless it's in an editor's note. MCC agreed with this. Nokia: we conclude with what's in our scope and in case BBF comes up with a solution we can update the study.
 		merged No S3‑192382  
S3‑192084 Delete Editor's in Solution#5 and add evaluation Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192383  
S3‑192085 Conclusion on KI#1 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192086 Conclusion on KI#14 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192391  
S3‑192087 Solution on Line ID protection Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192088 Mapping SUCI to SUPI Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192089 Merge S3-191319 to solution 4 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192090 Conclusion on KI#12 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192091 Conclusion on KI#16 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192092 Propose fuzz tests run 100 000 times Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesEricsson wasn't sure about stating out a number like 10000. Huawei: there should be a baseline about the number of runs for the tester. It was agreed to remove the number. Some errors on the CR cover page were also pointed out.
 		revised No S3‑192322  
S3‑192093 R15_clarification for Fuzz tests run Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192323  
S3‑192094 R14_clarification for Fuzz tests run Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192324  
S3‑192095 Clairication on the intention of the requirment Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192325  
S3‑192096 R15_Mirror_Clairication on the intention of the requirment Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192326  
S3‑192097 R14_Mirror_Clairication on the intention of the requirment Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192327  
S3‑192098 A document is needed to show the support features Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192350  
S3‑192099 R15_Mirror_A document is needed to show the support features Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192351  
S3‑192100 R14_Mirror_A document is needed to show the support features Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192352  
S3‑192101 Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192329  
S3‑192102 R15_Mirror_Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192330  
S3‑192103 R14_Mirror_Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑192331  
S3‑192104 WID on Security of the Wireless and Wireline Convergence for the 5G system architecture Huawei, Hisilicon WID new Approval
7.9New Work Item proposals
 		Yes
YesVodafone: the objectives need rewording.
 		revised No S3‑192355  
S3‑192105 Address EN in solution 17 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEricsson was concerned about how the black list was maintained since the constant change would lead to an increase in signalling. Otherwise they agreed with the change.
 		approved No    
S3‑192106 Update Solution 17 to Supplement Missing Part When Merging with S3-191389 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192107 Add Evaluation for Solution 17 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesNokia had the same comment as Ericsson in the previous contribution: maintaining the black list would cause overhead. Ericsson: in the practice they would be multiple black lists. Nokia: this gets complex when considering the mobility part.
 		revised No S3‑192399  
S3‑192108 Add Details and Evaluation for Solution 19 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑192402  
S3‑192109 Discussion Paper for Mitigation of DDoS Attack Huawei, Hisilicon discussion Endorsement
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192110 conclusion for KI#4 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEricsson: no need to do normative work. We agree with SA2 on the fact that we can rely on existing mechanisms. KPN: both Ericsson's (tdoc 2021) and Huawei's conclusions are not correct.
 		noted No    
S3‑192111 Key Issue for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEricsson: S-TMSI size, which is RAN2's concern, is not addressed here. Nokia: Impact of S-TMSI truncation needs a security issue. We will not make the decision of truncating but we need to study the security implications. This would mean rewriting the key issue to address the concerns of RAN2 raised in their LS.
 		revised No S3‑192393  
S3‑192112 Solution for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑192452  
S3‑192113 Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC Huawei, Hisilicon LS out Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑192394  
S3‑192114 Conclusion for KI#2 and KI#3 of frequent CIoT Ues Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192115 Solution for Protection of NAS Redirection Message Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEricsson: There is a requirement in Rel-15 and there is impact on UE and network, an overhead increase. Remove the evaluation and add another editor's note on why legacy mechanisms are not used here.
 		revised No S3‑192404  
S3‑192116 Solution for Protection of RRC Reject Message Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑192410  
S3‑192117 Solution for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑192411  
S3‑192118 Solution for Avoiding UE connecting to False Base Station during Conditional Handover Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192119 conclusion for key issue 3 Huawei, Hisilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192357  
S3‑192120 Deleting the EN of conclusion 7.1 Huawei, Hisilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑192348  
S3‑192121 Deleting the EN of conclusion 7.4 Huawei, Hisilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192358  
S3‑192122 conclusion for key issue 2 Huawei, Hisilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192349  
S3‑192123 Remove the paragraph of Introduction Huawei, Hisilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192124 Remove the unnecessary ENs of Key issue part Huawei, Hisilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
YesORANGE: removing the last editor's note is not editorial.
 		revised No S3‑192345  
S3‑192125 draftCR for URLLC TS Huawei, Hisilicon draftCR Approval
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
 		Yes
YesQualcomm: some parts of this are still in the air and we need some conclusions before agreeing on this. Let's wait for the next meeting. Nokia supported this. Huawei commented that this was a living document and could be changed anytime according to the discussions. Qualcomm didn’t agree with the introduction either. It was decided to come back to the next meeting with this. It was the general idea that the objective was to introduce this content in an annex to TS 33.501, so it was expected to bring back a similar contribution to the next meeting.
 		noted No    
S3‑192126 Evaluation for solution Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑192127 Adding contents into clause 4 China Mobile pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192128 Adding writing process overview into clause 5.1 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑192129 Adding general description and ToE into clause 5.2.1 and 5.2.2 China Mobile pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑192130 Adding references, definitions and abbreviations to SCAS UDM NEC Europe Ltd pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No   S3‑191885
S3‑192131 New solution: Integrity Protection of packet header in the User Plane China Mobile pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑192132 New solution: Integrity Protection of packet header in the User Plane China Mobile pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑192133 New solution: Integrity Protection of packet header in the User Plane China Mobile pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesNokia, Qualcomm: this is not feasible. Letf open for offline discussions.
 		revised No S3‑192455  
S3‑192134 Adding introduction text to SCAS UDM NEC Europe Ltd pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		merged No S3‑192296 S3‑191886
S3‑192135 Revisit the KAUSF desynchronization problem China Mobile discussion Endorsement
7.1.2Key derivation
 		Yes
YesNokia didn’t agree with this scenario. If the authentication happened already, how can the attacker trigger another authentication? Only the AMF can do this. Alex (BT) didn't see the issue here,it's just error handling when there is a de-synchronization. Qualcomm agreed: the system will recover itself.
 		noted No    
S3‑192136 Adding content to clause 4.2.3, 4.3 and 4.4 in SCAS UDM NEC Europe Ltd pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No   S3‑191887
S3‑192137 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.10Others
 		Yes
Yes
 		revised No S3‑192316  
S3‑192138 Addition Assets and Threats for Generic NFs Nokia, Nokia Shanghai Bell CR Approval
7.2.10Others
 		Yes
YesContent is merged in 317.
 		not pursued No    
S3‑192139 KAUSF synchronziation between the UE and AUSF China Mobile CR Approval
7.1.2Key derivation
 		Yes
Yes
 		not pursued No    
S3‑192140 Discussion of credential data protection China Mobile discussion Endorsement
5Items for early consideration
 		Yes
YesKPN, Nokia disagreed with the Rel-15 proposal. Something had to be done in Rel-15. Huawei supported this.
 		noted No    
S3‑192141 Updating the Living Document with Threat References Nokia, Nokia Shanghai Bell draftCR Approval
7.2.10Others
 		Yes
Yes
 		merged No S3‑192318  
S3‑192142 Correnction of Reference China Mobile CR Approval
7.1.16Others
 		Yes
Yes
 		revised No S3‑192333  
S3‑192143 Living Document: New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑192304  
S3‑192144 New solution for the linkability attack Huawei, Hisilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑192145 Resolving the ENs in solution #5 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192146 New KI: AKMA push Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesQualcomm: not sure that we need this. GBA Push is not really used. There is no use case for this.Vodafone commented that it was used. ORANGE: reword the requirement.
 		revised No S3‑192428  
S3‑192147 New KI: KAUSF storing at UE side Huawei, Hisilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
YesEricsson: not in scope. Qualcomm also disagreed with this.
 		noted No    
S3‑192148 Solving registraiton failure in ilde mobility registration procedure with AMF Reallocation China Telecom, Huawei, Hisilicon CR Approval
7.1.5NAS security
 		Yes
YesChina Mobile disagreed with this proposal. It wouldn’t work against a false base station attack. Ericsson: we may be finding security holes in this olution and it needs to be studied more carefully. Qualcomm: what happens when the AMF doesn’t talk to the old AMF and it doesn’t pull the old security context? Huawei warned that if this was not solved in Release 15 there would backward compatibility issues in Release 16. Qualcomm: Intra-AMF connection within a network would avoid this problem in Release 15. ZTE: We prefer a solution that doesn't impact the UE. The Chair asked the delegates if there was any chance of having this solved in Release 15. Noamen commented that more CRs would be welcome for the next meeting. Martin (AT&T): if we don’t solve this, we are getting to the situation of having to use a proprietary solution and it will cause once again that nothing will be standardized with many proprietary solutions already in the market. It was proposed to send an LS to CT1. This was discussed in tdoc 2281.
 		not pursued No    
S3‑192149 Evaluation to solution #9 and conclusion to KI#5 Huawei, Hisilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192370  
S3‑192150 Solution for NF service consumer verification during service access authorization Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192441  
S3‑192151 Clarification on security context transfer during handover from S1 mode to N1 mode Huawei, Hisilicon CR Approval
7.1.10Interworking
 		Yes
YesBased on option 2 of tdoc 2218. Huawei: There may be issues that need further study here. Qualcomm didn’t see any issues.
 		not pursued No    
S3‑192152 Evaluation of solution #15 in TR 33.855 - Delegated "Subscribe-Notify" interaction Authorization Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑192153 Update of solution #19 in TR 33.855 - Authorization within a NF Set Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192442  
S3‑192154 Issues on not removing the authentication result in the UDM Huawei, Hisilicon discussion Discussion
7.1.8Primary authentication
 		Yes
Yes
 		noted No    
S3‑192155 Removing the authentication result in the UDM Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
YesEricsson: this is not needed. Qualcomm supported this.
 		not pursued No    
S3‑192156 Description of issue of security context transfer following the handover from EPS to 5GS Huawei, Hisilicon CR Discussion
7.1.10Interworking
 		Yes
Yes
 		revised No S3‑192218  
S3‑192157 Discussion on the inconsistency of eKSI in idle mode mobility from 5GS to EPS over N26 Huawei, Hisilicon discussion Approval
7.1.10Interworking
 		No
Yes
 		withdrawn Yes    
S3‑192158 Clarification on the eKSI in idle mode mobility from 5GS to EPS over N26 Huawei, Hisilicon CR Approval
7.1.10Interworking
 		Yes
YesEricsson: we might have to involve CT1 here. The Chair clarified that CT1 may not do anything else for Release 15. This was left open for discussion.
 		not pursued No    
S3‑192159 Discussson paper on AMF reallocation China Telecom, Huawei, Hisilicon discussion Discussion
7.1.5NAS security
 		Yes
Yes
 		noted No    
S3‑192160 Solution for AKMA push Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: remove the evaluation. Ericsson: User identity should be clarified in step one of the figure.
 		revised No S3‑192429  
S3‑192161 Removing the authentication result in the UDM Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
YesSame comments as 2155. The Chair commented that Huawei was welcome to bring a key issue to the study for the next meeting in order to understand better the scenario.
 		not pursued No    
S3‑192162 Changes on handover from EPS to 5GS over N26 Huawei, Hisilicon CR Approval
7.1.10Interworking
 		Yes
YesORANGE: maybe you have to remove NOTE 2 as well.
 		agreed No    
S3‑192163 Completing TS 33.512 Huawei, Hisilicon, Deutsche Telekom AG pCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		revised No S3‑192288  
S3‑192164 Completing TS 33.513 Huawei, Hisilicon pCR Approval
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
Yes
 		revised No S3‑192291  
S3‑192165 Adding UPF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
YesEricsson: SBI interfaces should be listed too.
 		not pursued No    
S3‑192166 Completing TS 33.514 Huawei, Hisilicon pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		revised No S3‑192221  
S3‑192167 Adding UDM critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
YesEricsson: list SBI interfaces here, only reference points are mentioned. Huawei: the SBI interfaces area already specified somewhere else. It was agreed to address it later by adding an editor's note. Revised to include some comments from Ericsson's as well. Not pursued since its intention was to be a draftCR. Content will go into tdoc 294.
 		not pursued No    
S3‑192168 Adding test case for UE security policy comparison during handover Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		revised No S3‑192298  
S3‑192169 Completing TS 33.515 Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		revised No S3‑192300  
S3‑192170 Adding SMF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
YesHuawei: add a paragraph on protecting the user traffic data. Ericsson: charging ID uniqueness is not security related. In the end, it was decided to leave it. This CR was not pursued but the content will go into a draft CR in tdoc 2297.
 		not pursued No    
S3‑192171 Completing TS 33.516 Huawei, Hisilicon pCR Approval
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes
 		approved No    
S3‑192172 Adding AUSF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes. This CR was not pursued but the contents will go into tdoc 302.
 		not pursued No    
S3‑192173 Completing TS 33.517 Huawei, Hisilicon pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑192311  
S3‑192174 Updating TS 33.518 Huawei, Hisilicon, Nokia, Nokia Shanghai Bell pCR Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		approved No    
S3‑192175 Completing TS 33.519 Huawei, Hisilicon pCR Approval
7.2.9Network Exposure Function (NEF) (TS 33.519)
 		Yes
Yes
 		revised No S3‑192314  
S3‑192176 Adding NEF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval
7.2.9Network Exposure Function (NEF) (TS 33.519)
 		Yes
YesNot pursued as the content will go into the draftCR in tdoc 313.
 		not pursued No    
S3‑192177 adding critical assets and threats to TR 33.926 for general SBA/SBI aspects Huawei, Hisilicon CR Approval
7.2.10Others
 		Yes
YesRevised content will go to the contribution to the draftCR in 317.
 		not pursued No    
S3‑192178 Update of living Document: General SBA/SBI aspects in TS 33.117 Huawei, Hisilicon draftCR Approval
7.2.10Others
 		Yes
Yes
 		revised No S3‑192318  
S3‑192179 Addition of AMF-related Security Problem Descriptions Huawei, Hisilicon CR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
YesNokia: what happens if we have incorrect handling in X.2.2.3? The title needs to be changed. Nokia: remove the "waste of time" statement. Ericsson: who's the attacker here? Can you clarify it in the text? Ericsson suggested some other editorials to be fixed as well. It was clarified that this was intended to be input for the draftCR (which appears as a baseline). The CR is not pursued but the input to the draftCR is revised into tdoc 2286.
 		not pursued No    
S3‑192180 Updating SEPP critical assets and threats in TR 33.926 Huawei, Hisilicon CR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
YesIt overlaps with 2184. The CR (should have been a draftCR) is not pursued butThe content will be merged into 310.
 		not pursued No    
S3‑192181 Adding a test case for charging id uniqueness Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		revised No S3‑192301  
S3‑192182 Clarification on authentication vector generation Nokia, Nokia Shanghai Bell CR Agreement
7.1.8Primary authentication
 		Yes
YesORANGE: don’t agree with the sentence about the proprietary repository of the operator. Not part of the standard. Vodafone rejected the document as well: Not Rel-15, better for virtualization part.
 		not pursued No    
S3‑192183 Meeting notes of NFV SCAS conf call China Mobile other  
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192184 Threat Analysis on Exposure of Confidential IEs in N32-f message Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑192310  
S3‑192185 Updating UDM with UE registration status Nokia, Nokia Shanghai Bell pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
YesEricsson: not in the scope of the study. Apple: requirements look like solutions. Qualcomm: not in the scope of the study.
 		noted No    
S3‑192186 Threat Analysis of Incorrect Handling for Protection Policies Mismatch by the SEPP Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑192305  
S3‑192187 Meeting minutes of AKMA conference calls China Mobile report Information
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		noted No    
S3‑192188 Discussion paper UE initiated PFS Nokia, Nokia Shanghai bell discussion Discussion
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192189 Test Case: Correct Handling of Protection Policy Mismatch in the SEPP Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑192306  
S3‑192190 Work Plan for moving forward AKMA China Mobile discussion  
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		noted No    
S3‑192191 pCR UE initiated PFS Nokia, Nokia Shanghai Bell pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192192 Threat Analysis on Weak JWS Algorithm Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑192308  
S3‑192193 Editorial Changes to TR 33.835 v0.4.0 China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No    
S3‑192194 Test Case: JWS Profile Restriction in the SEPP Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑192309  
S3‑192195 TR 33.819 – KI #6.2 – Threats and Requirements InterDigital, Inc. pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesDiscussed together with tdoc 974.
 		merged No S3‑192343 S3‑191828
S3‑192196 Individual Evaluation of solution #6 China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑192197 Updating TS 33.517 with the Threat Reference for the Test Case in 4.2.2.5 Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		merged No S3‑192311  
S3‑192198 Individual Evaluations of solution #7- #12 China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑192199 A Solution to authentication method negotiation Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesEricsson: what is the reason for re-iventing the EAP negotiation?Nokia, ORANGE had also problems with this contribution.
 		noted No    
S3‑192200 Updates on IAB Node authentication and authorization solution Samsung pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No    
S3‑192201 Discussion on AKMA overall evaluation methodology China Mobile, ZTE Corporation discussion Endorsement
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesVodafone: no evaluation on how this evolves from GBA here. This is replacing GBA. Qualcomm: don’t mix GBA and AKMA.They're different. This is a separate document. ORANGE didn’t understand the classification of the key issues.
 		noted No    
S3‑192202 Establishment of F1 security association using Shared Key Samsung pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No    
S3‑192203 Evaluation of Solution#1 Samsung pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesEricsson: remove "completely". Qualcomm: your solution only protects DNS queries.It doesn’t address the attacks due to lack of integrity protection. Apple: remove the last sentence.
 		revised No S3‑192426  
S3‑192204 skeleton of clause 7- evaluation and conclusion China Mobile pCR  
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: 7.5 will be the API on the UE, not implementations.
 		revised No S3‑192427  
S3‑192205 Conclusion to Key Issue #5 Samsung pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192206 Resolving EN on New and Last serving gNB interactions Samsung pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192207 Evaluation of solution#1- Introducing third party key to AKMA China Mobile pCR  
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑192208 Evaluation of Solution#2 Samsung pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑192447  
S3‑192209 Updates to Solution#7 on obtaining accurate clock information Samsung pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192210 Deletion of EN on Location update reject in Solution#7 Samsung pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192211 Meeting minutes of AKMA conference call on 4th June China Mobile report Information
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		noted No    
S3‑192212 Assessment of solution #7 to Annex A.3 Samsung pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesEricsson: sharing aspects are missing.It was sugested to add an editor's note on this assesment.
 		revised No S3‑192449  
S3‑192213 Security procedures for CAPIF-3e/4e/5e reference points Samsung CR Approval
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16)
 		Yes
YesNokia didn't agree with this contribution. NCSC: N32 is quite heavy weight, more complicated than it appears here.
 		not pursued No    
S3‑192214 Security aspects of CAPIF-7/7e reference points Samsung CR Approval
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑192339  
S3‑192215 Editorial correction of CAPIF-3e/4e/5e requirements clause Samsung CR Approval
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑192216 Conclusion to Key Issue #6.1 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑192217 Resolution of Editor’s note in Solution #3 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesEricsson: It doesn’t remove the privacy concern for this solution. It was agreed to reword the editor's note to make it a note.
 		revised No S3‑192342  
S3‑192218 Description of issue of security context transfer following the handover from EPS to 5GS Huawei, Hisilicon discussion Discussion
7.1.10Interworking
 		Yes
YesQualcomm disagreed with the scenario. Option 2 was not backward compatible hence not possible for Rel-15. Ericsson preferred option 1, although the CR was based on option 2. Nokia wasn't convinced about the issue.
 		noted No   S3‑192156
S3‑192219 Clarification to Initial NAS message protection Samsung CR Approval
7.1.5NAS security
 		Yes
YesMCC asked if this issue needed to be fixed, why it wasn't done in Rel-15. This was brought as TEI16, and it could be flagged out in SA.Samsung replied that it had been rejected to do it in Release 15 in the previous meeting, but in release 16 it was only introducing a new characteristic in the UE, not a new feature. Ericsson wasn't sure if this was affecting SA2's procedures and SA3 may have to consult them firstly.
 		revised No S3‑192282  
S3‑192220 Implicit bootstrapping using NEF as the AKMA Anchor Function Nokia, Nokia Shanghai Bell, China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No    
S3‑192221 Completing TS 33.514 Huawei, Hisilicon, NEC pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
YesOverlap with tdoc 2134.
 		revised No S3‑192296 S3‑192166
S3‑192222 Resolve Editor’s Note in solution 3 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192382  
S3‑192223 WWC - Evaluation of Solution #3 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑192382  
S3‑192224 WWC - Evaluation of Solution #4 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192225 WWC - Resolve Editor’s Note in solution 5 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑192383  
S3‑192226 Modification on the usage of Identity Request Apple (UK) Limited CR Endorsement
7.1.14Privacy
 		Yes
Yes
 		revised No S3‑192280  
S3‑192227 Resolve Editor’s Note in solution 6 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑192386  
S3‑192228 WWC - Resolve Editor’s Note on Authentication in solution 4 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192385  
S3‑192229 pCR to 33.815 on authentication of network NTT DOCOMO INC. pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesSprint: there is a requirement that reads that the user is always informed of whether they are using RLOS. RLOS is not only for calls as well. NTT-Docomo: if the user is not aware, we have the threat. If the UE-user interface fulfils the requirement, that's fine, but the issue is there. SA1 is giving a solution. Vodafone: our consumers are not aware, they don't know what RLOS is about. BT supported this. ORANGE supported NTT-Docomo's contribution. The feature should not impact the users and this is essential. Qualcomm: I don’t agree putting this key issue. We have discussed this with other 3GPP groups like SA1 and SA2. Vodafone: this is setting up a massive fake base station issue. BT: the user will be directed to confirm actions that he doesn’t understand. Alex (BT): if we don’t document this we will get CVDs about this in the future. False base stations are a real threat and this needs to be included. The Chair suggested to record the key issue and the threat without a requirement. NTT-Docomo: there is a solution in SA1's specification. We need the requirement to align with what SA1 has agreed. It was agreed to capture SA1's text, and a note on the user's interaction for incerasing their awareness.
 		revised No S3‑192378  
S3‑192230 WWC - Resolve Editor’s Note on trust in solution 4 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesTaken care of in 2089.
 		noted No    
S3‑192231 Privacy protection for non-3GPP in 33.402 Apple (UK) Limited CR Endorsement
7.1.16Others
 		Yes
Yes
 		revised No S3‑192275  
S3‑192232 WWC - Evaluation of Solution #5 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑192383  
S3‑192233 WWC - Add conclusion on KI #10 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192234 WWC - Add conclusion on KI #11 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192235 WWC - Add conclusion on KI #12 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑192236 WWC - Add conclusion on KI #12 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑192389  
S3‑192237 pCR to 33.815 on user awareness of PARLOS service NTT DOCOMO INC. pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesNokia supported adding a note on the user interacting and selecting the RLOS service as done in the previous contribution. The same note was added as a baseline. Same changes as the previous contribution as well. Vodafone: what happens with IoT devices? Docomo answered that NB-IoT are excluded, the other are not.
 		revised No S3‑192379  
S3‑192238 UE capability protection Apple pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192239 update of Certificate based solution Apple pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192240 update of Key issue#7 Apple pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		withdrawn Yes    
S3‑192241 update of solution #2 Apple pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		merged No S3‑192447  
S3‑192242 update of solution #14 Apple pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑192243 Meeting minutes of SA3 5GFBS conference call on June 2th Apple pCR Information
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑192244 LS on Integrity protection data rate enumeration Apple LS out Decision
7.1.16Others
 		Yes
Yes
 		revised No S3‑192434  
S3‑192245 UP IP data rate Apple (UK) Limited discussion Decision
7.1.16Others
 		Yes
YesVodafone supported this. No backward compatibilities issues here.ORANGE supported the LS as well. Alf (Docomo): Handsets that cannot do integrity protection are limited to 64Kb/s in software and in hardware have a determined supported data rate. I hope this will not be required. Colin (BT): concerns on something in the network not supporting this and having to be dropped down due to the high requirements. Vodafone: customers will need this integrity protection. Alf: If you have chispets that can do those values while supporting higher data rates there is no point in supporting this. Qualcomm: this proposal should be discussed in RAN2 if they want to revisit this. The Chair asked if this was for Rel-15 or Rel-16. Apple replied that ideally Rel-15 and if not rel-16. The Chair commented that Rel-15 was frozen and no more changes could be done as requested by CT groups. Nokia asked whether this values were coming from, what they were based on. Alex (BT): I support needing high data rates, but review CT1 specs for these values. This was taken offline.
 		noted No    
S3‑192246 Discussion paper on resource level authorization using OAuth 2.0 access tokens Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑192247 Key Issue on resource level authorization during service access Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192412  
S3‑192248 Privacy protection for non-3GPP in 33.402 Apple (UK) Limited discussion Agreement
7.1.16Others
 		Yes
Yes
 		revised No S3‑192274  
S3‑192249 pCR – Solution for resource level authorization using access tokens Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑192250 Discussion paper on policy-based authorization for indirect communication Nokia, Nokia Shanghai Bell discussion -
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑192251 pCR on Policy based authorization for Indirect communications Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192413  
S3‑192252 pCR on NF to SeCoP interface security in service-mesh based deployments Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑192253 Solution for Authorization of NFs within a NF Set Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑192442  
S3‑192254 pCR to 33.855 on SeCoP distribution NTT DOCOMO INC. pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192443  
S3‑192255 pCR on removing EN in Solution #21 Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192444  
S3‑192256 pCR to 33.855 on NF authorization with SeCoP NTT DOCOMO INC. pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑192258  
S3‑192257 Comments to S3-191960 [DRAFT] LS on PC5 unicast and groupcast security protection InterDigital, Inc. LS out Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑192258 pCR to 33.855 on NF authorization with SeCoP NTT DOCOMO INC. pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑192256
S3‑192259 Authentication Data Storage in 5G UDR for Release 15 Hewlett-Packard Enterprise CR Approval
7.1.8Primary authentication
 		Yes
YesORANGE: not happy with the second change as it looks like a new requirement modifying the existing requirement. Alf (NTT-Docomo): similar problems with the second change. Vodafone: is trust boundary defined anywhere? They agreed with the rest of the change. The second change seemed to be allowing and forbidding SA3 at the same time. Alex (BT): you're forbidding anyone in the network to access the UDR except the ARPF.I get the concept but it's far more nuanced. ORANGE; "shall reside" is an implementation issue, not our problem here.
 		not pursued No    
S3‑192260 Evaluation for solution #4 InterDigital, Inc. pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia clarified that this was compliant with SA2's work.
 		approved No   S3‑191819
S3‑192261 Comments of S3-191922 Futurewei Technologies pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑192262 Security handling in registration procedure at AMF reallocation caused by slicing Ericsson Hungary Ltd discussion Endorsement
7.1.3Mobility
 		Yes
Yes
 		noted No   S3‑192004
S3‑192263 New solution: Integrating GBA to 5GC Ericsson Hungary Ltd pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE didn't support bringing old GBA into 5G. Something new should be created. Qualcomm and China Mobile supported this. Out of scope. Vodafone: how are GBA services evolving into 5G then?
 		noted No   S3‑192005
S3‑192264 LS on handling of native non-current 5G NAS security context after an inter-system change from S1 mode to N1 mode in idle mode C1-193944 LS in Information
7.1.15Incoming and outgoing Lses
 		Yes
YesQualcom's response reply in tdoc 923.
 		replied to No    
S3‑192265 Reply LS on Handling of UE radio network capabilities in 4G and 5G R2-1908467 LS in Information
6.10CVDs and Research
 		Yes
Yes
 		replied to No    
S3‑192266 Impersonation Attacks in 4G Networks GSMA LS in Discussion
6.10CVDs and Research
 		Yes
YesQualcomm: we are already studying UP IP for LTE. If we have this, the attack cannot be launched. Docomo: the billing issue is not here. You cannot create more traffic. Qualcomm was uncomfortable with replying with details to a paper that was not public yet. It was agreed to reply without much detail.
 		replied to No    
S3‑192267 LS on withdrawal of TS 103 383 “Smart Cards; Embedded UICC; Requirements Specification ETSI TC SCP LS in Information
6.11Other Groups
 		Yes
YesORANGE took the action point of preparing the CRs. A reply to this LS when the CRs were agreed would be done for the next meeting. Telecom Italia queried why the GSMA document was more important than the TCP document. Vodafone commented that the GSMA document was more widely implemented. ORANGE: SCP document is requirements-only and the GSMA documents has more things than requirements. Nokia: shouldn't we add other references after removing this one? ORANGE replied that it wasn't necessary.
 		postponed No    
S3‑192268 Reply LS on Cuiphering solution for broadcast of Assistance Data Nokia , Nokia Shanghai Bell LS out -
6.13GPP Working Groups
 		Yes
Yes
 		approved No   S3‑191942
S3‑192269 Reply to: GTP Recovery Counter & GSN node behaviour Nokia LS out approval
6.4GSMA
 		Yes
YesIt was agreed to send an LS reply where it would be stated that SA3 will look into this matter.
 		approved No    
S3‑192270 Reply to: Diameter IPX Network End-to-End Security Solution KPN LS out approval
6.4GSMA
 		Yes
Yes
 		approved No    
S3‑192271 Reply to: Handling of UE radio network capabilities in 4G and 5G NTT-Docomo LS out approval
6.10CVDs and Research
 		Yes
YesIncludes agreement on proposal 1 in tdoc 992.
 		approved No    
S3‑192272 Reply to: Impersonation Attacks in 4G Networks Nokia LS out approval
6.10CVDs and Research
 		No
Yes
 		approved No    
S3‑192273 Removing references in TS 33.501 of TS 103 383 ORANGE discussion Information
6.11Other Groups
 		Yes
YesCRs will come next meeting.
 		noted No    
S3‑192274 Privacy protection for non-3GPP in 33.402 Apple (UK) Limited discussion Agreement
7.1.16Others
 		Yes
Yes
 		noted No   S3‑192248
S3‑192275 Privacy protection for non-3GPP in 33.402 Apple (UK) Limited CR Agreement
7.1.16Others
 		Yes
YesORANGE: This is not applicable for 5G but only for 4G. Telecom Italia agreed. Ericsson: this is a category B CR (new feature) and it needs a WID. Huawei was also concerned about this since even 5G could be impacted. ORANGE preferred to discuss a study item on this. Ericsson: backward compatibility, bidding down, LI impact. Alex(BT): there are far more security holes in 4G that have preference over this one. I don’t mind having a study, though. I'd rather go to 5G issues first.
 		not pursued No   S3‑192231
S3‑192276 Definition of authentication subscription data Nokia, Nokia Shanghai Bell CR Agreement
7.1.8Primary authentication
 		Yes
YesNTT-Docomo: happy with this, but we need to verify that the definitions are being used in the text of the spec and that they are still correct. Maybe send a LS and have a conference call in between meetings.Gemalto and ORANGE agreed. NTT-Docomo: this should lead to a study item in Rel-16. Alf (Docomo): allowing the storage in the UDR goes beyond making a definition, things are being stored in the ARPF throughout the spec and we need to modify those parts as well. ORANGE disagreed with the requirements on the UDM. It was commented that this document would serve as a baseline for further work for the next meeting, but in the end the document was noted. Telecom Italia: realistic to have UDR co-located/inside the ARPF? This would mean different requirements to be considered. Hpe: implementation issue. Tim (Vodafone) proposed to organize a conference call before the next meeting. Adrian (Qualcomm) will chair the call. Minutes were to be created and delivered to the next SA3 meeting. Georg (SA Chair) proposed to sync with CT4 on the call.
 		not pursued No   S3‑191986
S3‑192277 Reply to: Reply LS on Nudr Sensitive Data Protection Nokia LS out approval
5Items for early consideration
 		Yes
YesIt was clarified that changes in Rel-15 were needed in CT4. The Chair replied that this was not what was asked in SA. ORANGE: we never said that we had a specific authentication that shall be used. Proprietary algorithms used currently by operators will not work. Alex(BT): as specified this resolves in 5G weaker than 4G, due to the use of proprietary algorithms by operators. Anja(Nokia): this means that we are in the same situation as last meeting. Gemalto replied that last meeting was about a new feature in the storage in the UDM whereas this was a correction. The Chair commented that this may lead to a correction in a CT4 specification. Who supports sending the LS: Telecom Italia, Nokia, ORANGE,China Mobile, BT, Gemalto,Docomo,Hpe supported sending the LS. Ericsson didn’t support sending the LS.
 		revised No S3‑192456  
S3‑192278 Reply to: LS on support of non-3GPP only UE and support for PEI in IMEI format BT LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
YesIt was agreed to reply with "Reuse the same as in 3GPP access."
 		approved No    
S3‑192279 Reply LS on handling of native non-current 5G NAS security context Qualcomm Incorporated LS out Approval
7.1.10Interworking
 		Yes
Yes
 		approved No   S3‑191923
S3‑192280 Modification on the usage of Identity Request Apple (UK) Limited CR Endorsement
7.1.14Privacy
 		Yes
YesORANGE: Identity request is part of the registration procedure. Docomo: There is value in this. Make it Rel-16. It protects the privacy of a single UE and it prevents DoS attacks. Qualcomm: we have this clarified in another clause. Not needed. Ahmad (Futurewei): the UE shall ignore if the request is coming out of the authentication procedure; I'm not sure if this is included in Release 15. Nokia: AMF can reauthenticate the UE anytime it wants, by sending the auth request to the UE. This is not needed. Qualcomm: we agreed to remove the requirement due to an LS from CT1 (S3-191121). Why adding this again? CT1 would have an issue. Intel: this is already covered somewhere else. Apple: we need to reconsider this. Qualcomm: after checking CT1 specs, we have found that this is not correct.
 		not pursued No   S3‑192226
S3‑192281 LS on registration issues in the AMF re-allocation Huawei LS out Approval
7.1.5NAS security
 		Yes
YesThe Chair warned that if this had an impact on Rel-15 stage 3, this could be rejected by CT groups. Vodafone commented that CT groups were meeting in the same location as SA3 next time, so this could be discussed with them. It was argued that this could have some impact on backward compatibility and the release could be discussed with CT.
 		approved No    
S3‑192282 Clarification to Initial NAS message protection Samsung CR Approval
7.1.5NAS security
 		Yes
YesSmall changes as proposed by Suresh (Nokia). Futurewei suggested to reword the consequences if not approved on the CR cover.
 		agreed No   S3‑192219
S3‑192283 DraftCR - update Annex B to support the authentication of non-3GPP devices CableLabs, Charter, Nokia, Nokia Shanghai Bell draftCR Discussion
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE: changes in B.1 not necessary. Some re-wording is needed as there is normative meaning in an informative annex.
 		noted No   S3‑191949
S3‑192284 uplink NAS Count for Kasme derivation in idle mode mobility to EPS ZTE Corporation CR Agreement
7.1.6Security context
 		Yes
Yes
 		agreed No   S3‑191979
S3‑192285 Recommendation to run AKA after IW HO from 4G to 5G Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		agreed No   S3‑191995
S3‑192286 Addition of AMF-related Security Problem Descriptions Huawei, Hisilicon other Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		approved No    
S3‑192287 DraftCR on Assests and threats specific to the AMF Huawei draftCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		approved No    
S3‑192288 Completing TS 33.512 Huawei, Hisilicon, Deutsche Telekom AG pCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		approved No   S3‑192163
S3‑192289 Adding UPF critical assets and threats to TR 33.926 Huawei, Hisilicon other Approval
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
Yes
 		approved No    
S3‑192290 DraftCR on Aspects of the network product class UPF Huawei draftCR Approval
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
Yes
 		approved No    
S3‑192291 Completing TS 33.513 Huawei, Hisilicon pCR Approval
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
Yes
 		approved No   S3‑192164
S3‑192292 Draft TS 33.513 Samsung draft TS Approval
7.2.3User Plane Function (UPF) (TS 33.513)
 		No
Yes
 		eft for email approval No    
S3‑192293 Draft TS 33.514 NEC draft TS Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		No
Yes
 		eft for email approval No    
S3‑192294 Adding UDM critical assets and threats to TR 33.926 Huawei, Hisilicon other Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No    
S3‑192295 DraftCR on aspects specific to the network product class UDM Huawei draftCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No    
S3‑192296 Completing TS 33.514 Huawei, Hisilicon, NEC pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No   S3‑192221
S3‑192297 DraftCR on Adding SMF critical assets and threats to TR 33.926 Huawei, Hisilicon draftCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No    
S3‑192298 Adding test case for UE security policy comparison during handover Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No   S3‑192168
S3‑192299 Draft TS 33.515 Huawei draft TS Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		No
Yes
 		eft for email approval No    
S3‑192300 Completing TS 33.515 Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No   S3‑192169
S3‑192301 Adding a test case for charging id uniqueness Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No   S3‑192181
S3‑192302 Adding AUSF critical assets and threats to TR 33.926 Huawei, Hisilicon draftCR Approval
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes
 		approved No    
S3‑192303 Draft TS 33.516 Ericsson draft TS Approval
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes
 		approved No    
S3‑192304 Living Document: New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑192143
S3‑192305 Threat Analysis of Incorrect Handling for Protection Policies Mismatch by the SEPP Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
YesClarify the mistmatch in the threat description. Removes IPX provider in the threat description and it fixes some typos.
 		approved No   S3‑192186
S3‑192306 Test Case: Correct Handling of Protection Policy Mismatch in the SEPP Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑192189
S3‑192307 Draft TS 33.517 Nokia draft TS Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No    
S3‑192308 Threat Analysis on Weak JWS Algorithm Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
YesRemoving examples from the threat description.
 		approved No   S3‑192192
S3‑192309 Test Case: JWS Profile Restriction in the SEPP Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑192194
S3‑192310 Threat Analysis on Exposure of Confidential IEs in N32-f message Nokia, Nokia Shanghai Bell,Huawei draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑192184
S3‑192311 Completing TS 33.517 Huawei, Hisilicon,Nokia pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑192173
S3‑192312 Draft TS 33.518 Nokia draft TS Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		approved No    
S3‑192313 Adding NEF critical assets and threats to TR 33.926 Huawei, Hisilicon draftCR Approval
7.2.9Network Exposure Function (NEF) (TS 33.519)
 		Yes
Yes
 		approved No    
S3‑192314 Completing TS 33.519 Huawei, Hisilicon pCR Approval
7.2.9Network Exposure Function (NEF) (TS 33.519)
 		Yes
Yes
 		approved No   S3‑192175
S3‑192315 Draft TS 33.519 ZTE draft TS Approval
7.2.9Network Exposure Function (NEF) (TS 33.519)
 		No
Yes
 		eft for email approval No    
S3‑192316 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.10Others
 		Yes
Yes
 		approved No   S3‑192137
S3‑192317 adding critical assets and threats to TR 33.926 for general SBA/SBI aspects Huawei, Hisilicon other Approval
7.2.10Others
 		Yes
Yes
 		approved No    
S3‑192318 Update of living Document: General SBA/SBI aspects in TS 33.117 Huawei, Hisilicon draftCR Approval
7.2.10Others
 		Yes
Yes
 		approved No   S3‑192178
S3‑192319 Corrections on IP packet forwarding Ericsson CR Agreement
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesFixing some cover page errors.
 		agreed No   S3‑192038
S3‑192320 Corrections on IP packet forwarding Ericsson CR Agreement
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192039
S3‑192321 Living document: generic assets and threats Ericsson draftCR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		approved No   S3‑192041
S3‑192322 R16_Carification for Fuzz tests run Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192092
S3‑192323 R15_clarification for Fuzz tests run Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192093
S3‑192324 R14_clarification for Fuzz tests run Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192094
S3‑192325 Clairication on the intention of the requirment Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192095
S3‑192326 R15_Mirror_Clairication on the intention of the requirment Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192096
S3‑192327 R14_Mirror_Clairication on the intention of the requirment Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192097
S3‑192328 Security solution for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) with legacy fall back Intel China Ltd. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		No
Yes
 		noted No   S3‑191951
S3‑192329 Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192101
S3‑192330 R15_Mirror_Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192102
S3‑192331 R14_Mirror_Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192103
S3‑192332 Reply to: LS on ETSI Plugtest standards Issues Motorola Solutions LS out approval
7.8.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		approved No    
S3‑192333 Correnction of Reference China Mobile CR Approval
7.1.16Others
 		Yes
YesChanges on the cover sheet.
 		agreed No   S3‑192142
S3‑192334 Requirements on UDM/ARPF Gemalto, Nokia CR Approval
7.1.8Primary authentication
 		No
Yes
 		withdrawn Yes    
S3‑192335 Living doucment for 5G_UTRAN_SEC China Unicom draftCR -
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		No
Yes
 		approved No   S3‑191989
S3‑192336 Proposed updates to the draft CR on SRVCC from 5G to UTRAN CS Qualcomm Incorporated,China Unicom other Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		approved No   S3‑191903
S3‑192337 Assigning a FC value to TS 33.501 for K5GSRVCC calculation Qualcomm Incorporated CR Agreement
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		agreed No   S3‑191904
S3‑192338 Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC Qualcomm Incorporated CR Agreement
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		agreed No   S3‑191905
S3‑192339 Security aspects of CAPIF-7/7e reference points Samsung CR Approval
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16)
 		Yes
YesThird change goes away.
 		agreed No   S3‑192214
S3‑192340 Draft TR 33.819 Nokia draft TR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		No
Yes
 		eft for email approval No    
S3‑192341 Solution for (D)DoS attack mitigation in PNI NPN InterDigital, Inc. pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesAdding an editor's note in the evaluation addressing Ericsson's comment (FFS for the case of one CAG ID is left).
 		approved No   S3‑191821
S3‑192342 Resolution of Editor’s note in Solution #3 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192217
S3‑192343 Security threats and requirements on CAG ID privacy ZTE Corporation,Interdigital pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191974
S3‑192344 Draft TR 33.825 Huawei draft TR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		No
Yes
 		eft for email approval No    
S3‑192345 Remove the unnecessary ENs of Key issue part Huawei, Hisilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192124
S3‑192346 URLLC: Table with available solutions in the TR Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191994
S3‑192347 Evaluation of solution #5: Security for redundant data transmission Qualcomm Incorporated, Ericsson, Nokia pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191913
S3‑192348 Conclusion on KI #1 for Study on the security for URLLC Qualcomm Incorporated, Ericsson, Nokia,Huawei pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191914
S3‑192349 conclusion for key issue 2 Huawei, Hisilicon,Qualcomm pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192122
S3‑192350 A document is needed to show the support features Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192098
S3‑192351 R15_Mirror_A document is needed to show the support features Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192099
S3‑192352 R14_Mirror_A document is needed to show the support features Huawei, Hisilicon CR Approval
7.8.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑192100
S3‑192353 Report from session on registation failures with AMF reallocation Huawei report Information
7.1.5NAS security
 		Yes
Yes
 		noted No    
S3‑192354 New WID on evolution of Cellular IoT security for the 5G System Ericsson WID new Agreement
7.9New Work Item proposals
 		Yes
Yes
 		agreed No   S3‑192047
S3‑192355 WID on Security of the Wireless and Wireline Convergence for the 5G system architecture Huawei, Hisilicon WID new Approval
7.9New Work Item proposals
 		Yes
Yes
 		agreed No   S3‑192104
S3‑192356 New SID on Study on user plane security termination point in 5GC CATT, China Unicom, Qihoo360 SID new Approval
8.23New study item proposals
 		No
Yes
 		withdrawn Yes    
S3‑192357 conclusion for key issue 3 Huawei, Hisilicon,Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192119
S3‑192358 Deleting the EN of conclusion 7.4 Huawei, Hisilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192121
S3‑192359 pCR to TR33.814 - Add reference for TR 33.814 CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesIt Includes the content where the reference is used.
 		approved No   S3‑191968
S3‑192360 Draft TR 33.814 CATT draft TR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192361 Add evualtion to solution 4 Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192076
S3‑192362 pCR to TR33.814 - Conclusions for TR33.814 CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191967
S3‑192363 Addressing EN in solution#1 Nokia, Nokia Shanghai bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191945
S3‑192364 Draft TR 33.813 Nokia draft TR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		No
Yes
 		eft for email approval No    
S3‑192365 Minutes of the SBA offline session Ericsson report Information
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑192366 Conclusion to KI #1 (slice authentication) Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191929
S3‑192367 Conclusions to KI#2 (AMF Key separation) Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesIt was clarified that there was no conclusion was reached given that the use case in SA2 was not concluded either.
 		approved No   S3‑191930
S3‑192368 Virtualisation Study Key Issue 12 (was S3-191571) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191852
S3‑192369 Adding evaluation and resolving EN in Solution 7 Ericsson pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesFirst change was kept, evaluation was removed.
 		approved No   S3‑192022
S3‑192370 Evaluation to solution #9 and conclusion to KI#5 Huawei, Hisilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192149
S3‑192371 Solution details on solution 8 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191934
S3‑192372 Evalution for solution 8 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191935
S3‑192373 Adding some details to solution #10 on protecting S-NSSAI at AS layer Qualcomm Incorporated pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191910
S3‑192374 Protection of S-NSSAI transmitted in the AS layer using T-S-NSSAI InterDigital, Inc. pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191817
S3‑192375 TR 33.813 - Evaluation for Solution X - S-NSSAI transmitted in the AS layer using T-S-NSSAI InterDigital, Inc. pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191826
S3‑192376 Adding text to Clause 9 Recommendations Nokia, Nokia Shanghai Bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesRemoving the "shall"s as suggested by MCC and removing the second point.
 		approved No   S3‑191947
S3‑192377 WID for normative work on eNS. Nokia, Nokia Shangahi Bell WID new Agreement
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		agreed No   S3‑191948
S3‑192378 pCR to 33.815 on authentication of network NTT DOCOMO INC. pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192229
S3‑192379 pCR to 33.815 on user awareness of PARLOS service NTT DOCOMO INC. pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192237
S3‑192380 Way forward on Emergency solution for PARLOS Nokia, Nokia Shanghai Bell pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191944
S3‑192381 Draft TR 33.815 Sprint draft TR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		No
Yes
 		eft for email approval No    
S3‑192382 Resolve Editor’s Note in solution 3 Nokia, Nokia Shanghai Bell,Huawei pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192222
S3‑192383 Delete Editor's in Solution#5 and add evaluation Huawei, Hisilicon,Nokia pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192084
S3‑192384 Draft TR 33.807 Huawei draft TR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		No
Yes
 		eft for email approval No    
S3‑192385 WWC - Resolve Editor’s Note on Authentication in solution 4 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192228
S3‑192386 Removal of Editor’s Note and Addition of Evaluation Lenovo, Motorola Mobility pCR -
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191987
S3‑192387 Add threat and requirement to KI#11 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192080
S3‑192388 Add requirement to KI#12 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192079
S3‑192389 WWC - Add conclusion on KI #12 Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192236
S3‑192390 Add requirement and delete EN for KI#14 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192081
S3‑192391 Conclusion on KI#14 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192086
S3‑192392 Draft TR 33.861 Ericsson draft TR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		No
Yes
 		eft for email approval No    
S3‑192393 Key Issue for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192111
S3‑192394 Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC Huawei LS out Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192113
S3‑192395 Virtualisation Study Key Issue 19 (was S3-191580) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191853
S3‑192396 Virtualisation Study Key Issue 22 (was S3-191583) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191856
S3‑192397 Evaluation of Solution #4 Futurewei pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑192398 Proposal for editor's note in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191879
S3‑192399 Add Evaluation for Solution 17 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192107
S3‑192400 CIoT: Update to Solution #18 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192013
S3‑192401 CIoT: Evaluation to Solution #18 Ericsson,Futurewei,Intel pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192014
S3‑192402 Add Details and Evaluation for Solution 19 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesAdding an editor's note on the group of misbehaving UEs as proposed by Ericsson.
 		approved No   S3‑192108
S3‑192403 Draft TS 33.512 Huawei draft TS Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		No
Yes
 		eft for email approval No    
S3‑192404 Solution for Protection of NAS Redirection Message Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192115
S3‑192405 KI on toplogy discovery Huawei, Hisilicon pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑192075
S3‑192406 Draft TR 33.824 Samsung draft TR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		No
Yes
 		eft for email approval No    
S3‑192407 New KI: Protection of recovery from backhaul-RLF Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑192029
S3‑192408 Update to solution #2.1 (Authentication and authorization of IAB Node) Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑192031
S3‑192409 Report from offline discussions on 5GFBS Apple report Information
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑192410 Solution for Protection of RRC Reject Message Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No   S3‑192116
S3‑192411 Solution for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
No
Yes
 		noted No   S3‑192117
S3‑192412 Key Issue on resource level authorization during service access Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑192247
S3‑192413 pCR on Policy based authorization for Indirect communications Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesORANGE: SA2 is using the term SCP for something else. Change the name.
 		approved No   S3‑192251
S3‑192414 Evaluation of solution #4.1: F1 interface security for IAB Qualcomm Incorporated pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑191918
S3‑192415 Solution for Privacy protection for unicast messages over PC5 InterDigital, Inc. pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191822
S3‑192416 Draft TR 33.836 LG draft TR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑192417 Solution for Security for eV2X unicast messages over PC5 InterDigital, Inc. pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191823
S3‑192418 Solution for Security for eV2X unicast messages over PC5 InterDigital, Inc. pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesAdding several editor's notes addressing comments from Qualcomm among others.
 		approved No   S3‑191824
S3‑192419 Solution for Privacy protection for unicast messages over PC5 using rekeying InterDigital, Inc. pCR -
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191825
S3‑192420 Update of key issue #2 on PC5 unicast mode LG Electronics pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191957
S3‑192421 Reply LS on PC5 unicast and groupcast security protection LG Electronics LS out Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesTaking comments from Interdigitals contribution in 2257. It was clarifed that the original LS from SA2 had been replied already, so for database purposes this was a new LS instead of a reply.
 		approved No   S3‑191960
S3‑192422 Proposal for FS_UP_IP_Sec Key Issue #3 and 5: Zero-overhead user plane integrity protection on the link layer Philips International B.V. pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191880
S3‑192423 New solution for KI #4 NEC Europe Ltd pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191899
S3‑192424 Draft TR 33.853 Vodafone draft TR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		No
Yes
 		eft for email approval No    
S3‑192425 UP IP: New key issue for UE indicating support of UP IP in NR PDCP with a ng-eNB connected to 5GC Ericsson pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192036
S3‑192426 Evaluation of Solution#1 Samsung pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192203
S3‑192427 skeleton of clause 7- evaluation and conclusion China Mobile pCR -
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑192204
S3‑192428 New KI: AKMA push Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑192146
S3‑192429 Solution for AKMA push Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑192160
S3‑192430 Draft TR 33.835 China Mobile draft TR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
No
Yes
 		eft for email approval No    
S3‑192431 Modification on linkability issue1 ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191977
S3‑192432 Draft TR 33.846 Ericsson draft TR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		No
Yes
 		eft for email approval No    
S3‑192433 Key issue on protecting the SQN during a re-synchronisation procedure in AKA Qualcomm Incorporated pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191907
S3‑192434 LS on Integrity protection data rate enumeration Apple LS out Decision
7.1.16Others
 		Yes
YesVodafone asked to minute: this means that handsets will provide integrity protection at full rate/fastest speed possible. This is clearly a big problem, as a note for the companies rejecting this LS. ORANGE supported Vodafone. Alex (BT) supported Vodafone as well. Not all handsets high end and low end, will support this capability, it is not realistic. Vodafone asked to be minuted: we are disgusted that our customers will be insecure. ORANGE asked for reasons for not sending this LS but there was no reason given. This statement was asked to be minuted as well.
 		noted No   S3‑192244
S3‑192435 Draft TR 33.818 China Mobile draft TR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192436 Scope of SECAM Accreditation for 3GPP virtualized network products China Mobile pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192063
S3‑192437 Adding roles in SECAM for 3GPP virtualized network products into clause 4.6 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192064
S3‑192438 Draft TR 33.855 Ericsson draft TR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		No
Yes
 		eft for email approval No    
S3‑192439 New solution: Token-based authorization for Scenario D using stateless SeCoP Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesAdding two editor's notes.
 		approved No   S3‑192033
S3‑192440 New solution: Token-based authorization for Scenario C using stateless SeCoP Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesAdding three new edtior's notes.
 		approved No   S3‑192034
S3‑192441 Solution for NF service consumer verification during service access authorization Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑192150
S3‑192442 Update of solution #19 in TR 33.855 - Authorization within a NF Set Huawei, Hisilicon,Nokia pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑192153
S3‑192443 pCR to 33.855 on SeCoP distribution NTT DOCOMO INC. pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑192254
S3‑192444 pCR on removing EN in Solution #21 Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑192255
S3‑192445 Draft TR 33.848 BT draft TR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑192446 Virtualisation Study Key Issue 20 (was S3-191581) BT plc pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191854
S3‑192447 Evaluation of Solution#2 Samsung,Apple pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No   S3‑192208
S3‑192448 Draft TR 33.809 Apple draft TR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		left for email approval No    
S3‑192449 Assessment of solution #7 to Annex A.3 Samsung pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No   S3‑192212
S3‑192450 Solution 2 evaluation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑192000
S3‑192451 Solution 3 evaluation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑192001
S3‑192452 Solution for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑192112
S3‑192453 Security for non-public networks Qualcomm Incorporated, Nokia, Nokia Shanghai Bell draftCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191901
S3‑192454 AMF reallocation Huawei discussion Endorsement
7.1.5NAS security
 		Yes
YesIt takes the problem description of S3-192159 to be forwarded in the LS S3-192281.
 		noted No    
S3‑192455 New solution: Integrity Protection of packet header in the User Plane China Mobile pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesThe evaluation was removed and an editor's note added as proposed by Qualcomm.
 		approved No   S3‑192133
S3‑192456 LS on Nudr Sensitive Data Protection Nokia LS out approval
5Items for early consideration
 		Yes
Yes
 		approved No   S3‑192277