Tdoc List

2019-11-22 16:37

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑193900 Agenda WG Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		revised No S3‑194442  
S3‑193901 Report from SA3#96 MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
YesApproved with an editorial change in tdoc 2862 as commented by Qualcomm. (AS instead of AES). This will be corrected in the final version uploaded to the 3GPP server.
 		approved No    
S3‑193902 Report from SA3#96Ad-Hoc MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
YesMCC thanked the SA3 leadership for taking care of MCC tasks during the adhoc.
 		approved No    
S3‑193903 SA3 Work Plan MCC Work Plan  
9.1Review of work plan
 		Yes
Yes
 		noted No    
S3‑193904 Report from last SA meeting WG Chairman report  
4.2Report from SA plenary
 		Yes
YesHuawei asked when SA3 was going to start working on Release 17. The Chair answered that the release 17 work was based on the prioritization done in SA2, so SA3's work would depend on their progress. Vodafone asked about items such as SBA. Can SBA be classed as release 16? The Chair answered that it was release 16.
 		noted No    
S3‑193905 SA3 meeting calendar WG Chair other  
10Future Meeting Dates and Venues
 		Yes
YesAnja (Nokia) didn’t like to have SA3#100Bis. The Chair commented that the workload didn't seem to decrease and that the meeting could always be cancelled if not needed. Bath (UK) confirmed for SA3#100.
 		noted No    
S3‑193906 Work Plan input from Rapporteurs MCC other  
9.2Rapporteur input on status of WID or SID
 		Yes
Yes
 		revised No S3‑194699  
S3‑193907 Alignment with TR 33.926 Futurewei Technologies CR Agreement
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesOverlap with 908,347.
 		merged No S3‑194477  
S3‑193908 Reference Correction Futurewei Technologies CR Agreement
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		merged No S3‑194477  
S3‑193909 Adding missing abbreviations Futurewei Technologies CR Agreement
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑193910 TCG progress - report from TCG rapporteur InterDigital Communications other Information
6.5TCG
 		Yes
YesPublication of new or revised deliverables (incremental changes from the status reported at SA3#96). • TCG Mobile Device Runtime Integrity Preservation – publication November 2019. The following public URL is available starting on 11/11/2019: https://trustedcomputinggroup.org/resource/tcg-runtime-integrity-preservation-in-mobile-devices/ • TCG TPM 2.0 Mobile Command Response Buffer Errata – publication November 2019 • TCG Trusted Attestation Protocol (TAP) Use Cases – publication November 2019 • TCG TSS 2.0 Overview and Common Structures – published October 2019 • TCG TSS 2.0 Feature API (FAPI) – public review October 2019 • TCG TSS 2.0 JSON Datatypes and Policy Language – public review October 2019 • TCG TPM 2.0 Authenticated Countdown Timer (ACT) Command – public review October 2019 • TCG Platform Certificate Profile – public review October 2019 • TCG PC Client Specific TPM Protection Profile (PTP) – public review October 2019 • TCG Trusted Attestation Protocol (TAP) Info Model – published September 2019 • TCG TSS 2.0 Enhanced System Level API (ESAPI) – published September 2019 • TCG TSS 2.0 System Level API (SAPI) – published August 2019 • TCG Guidance for Secure Update of S/W and F/W – public review August 2019 • TCG RIV: Network Equipment Remote Attestation – public review June 2019 TCG Trusted Attestation Protocol (TAP) Info Model – publication August 2019 • TCG Trusted Attestation Protocol (TAP) Use Cases – public review August 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG Mobile Device Runtime Integrity Preservation – public review August 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG TPM 2.0 Auto Thin Profile – publication August 2019 • TCG TSS 2.0 Enhanced System Level API (ESAPI) – publication August 2019 • TCG TSS 2.0 System Level API (SAPI) – publication August 2019 2. Meetings • TCG Members Meeting in Miami, Florida USA – 10-13 February 2020 • 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‑193911 TR 33.813 - update for the evaluation for solution #11 InterDigital Communications pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesQualcomm: this solution doesn't protect from attacks of people with the same NSSAI. It exists for both insiders and non-insiders.Don’t remove the editor's note. Nokia: the group size is too big, it is not a corner case.
 		revised No S3‑194546  
S3‑193912 TR 33.819 – update for the evaluation of Hash based solution for CAG ID privacy InterDigital Communications pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑193913 New WID on Security Aspects of PARLOS SPRINT Corporation WID new Agreement
7.20New work item proposals
 		Yes
Yes
 		revised No S3‑194525  
S3‑193914 [MCXSec] 33180 R16 Missing Abbreviations (Mirror) Airbus CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		revised No    
S3‑193915 [MCXSec] 33180 R16 Reference Addition (Mirror) Airbus CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑193916 [MCXSec] 33180 R16 Correction concerning IdM client (Mirror) Airbus CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑193917 [eMCSec] 33180 R15 Missing Abbreviations (Mirror) Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193918 [eMCSec] 33180 R15 Reference Addition (Mirror) Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193919 [eMCSec] 33180 R15 Correction concerning IdM client (Mirror) Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193920 [MCSec] 33180 R14 Missing Abbreviations Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193921 [MCSec] 33180 R14 Reference Addition (Mirror) Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193922 [MCSec] 33180 R14 Correction concerning IdM client (Mirror) Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193923 [MCPTT] 33179 R13 Missing Abbreviations Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193924 [MCPTT] 33179 R13 Reference Addition Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193925 [MCPTT] 33179 R13 Correction concerning IdM client Airbus CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193926 LS on IANA assigned values for mission critical C1-195042 LS in  
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		replied to No    
S3‑193927 Reply LS on NAS Aspects of Mobile-terminated Early Data Transmission C1-195111 LS in  
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesPart of this LS was addressed as a new LS sent from last SA3's meeting. Ericsson believed that there were still open issues and wanted to have minuted that they would bring contributions in the future to address them: "Ericsson has noted that the UP case is different ass the GUTI is not revealed in the uplink and may not need GUTI reallocation. Therefore, Ericsson may bring related contributions next meeting."
 		noted No    
S3‑193928 Reply LS on Mobile-terminated Early Data Transmission R2-1911603 LS in  
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesNo actions for SA3.
 		noted No    
S3‑193929 LS on network slice-specific authentication and authorization C1-196903 LS in  
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesNo action for SA3.
 		noted No    
S3‑193930 LS on how the IWF obtains key material for interworking group and private communications C1-196979 LS in  
7.3eMCSec R16 security (Rel-16)
 		Yes
YesThe response will be included in the reply to tdoc 433.
 		noted No    
S3‑193931 LS on Clarification on the requirement for steering of roaming C1-197001 LS in  
7.19.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
YesNo action for SA3.
 		noted No    
S3‑193932 LS on O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs O-RAN Alliance LS in  
6.10Other Groups
 		Yes
YesNokia: there is no security group in O-RAN, so we don’t know what they are asking us to do.
 		noted No    
S3‑193933 Reply LS to “O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs” SP-190947 LS in  
6.10Other Groups
 		Yes
Yes
 		noted No    
S3‑193934 LS on AS key derivation for conditional handover R2-1911565 LS in  
6.13GPP Working Groups
 		Yes
YesRelated contributions: 4055, 4025.
 		replied to No    
S3‑193935 LS on impact on UTRAN of 5G SRVCC R2-1911753 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑193936 Reply LS on bulk authentication issue for IoT devices R2-1911790 LS in  
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		noted No    
S3‑193937 LS on misalignment in Counter Check Procedure R2-1911837 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑193938 Reply LS on Handling of UE radio network capabilities in 4G and 5G R2-1911850 LS in  
7.19.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		replied to No    
S3‑193939 LS on PC5-S Signaling and PC5-RRC connection for NR sidelink communication R2-1914151 LS in  
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		Yes
Yes
 		noted No    
S3‑193940 LS to SA3 on False Base Station Detection R3-196256 LS in  
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No    
S3‑193941 Reply LS to SA3 on FBS detection R2-1914224 LS in  
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		postponed No    
S3‑193942 LS on security for multi-CU-UP connectivity R3-194784 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		replied to No    
S3‑193943 Reply LS on eSBA NF Set S2-1910148 LS in  
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		noted No    
S3‑193944 Reply LS on LS on the IAB-indication to core network S2-1910281 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑193945 Reply LS on AUSF role in slice specific authentication S2-1910668 LS in  
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		postponed No    
S3‑193946 LS Response Reply LS on support of non-3GPP only UE and support for PEI in IMEI format S2-1910679 LS in  
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		noted No    
S3‑193947 LS Response on Security Aspects of AMF Re-allocation Procedure S2-1910724 LS in  
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		noted No    
S3‑193948 Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC S2-1910789 LS in  
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		replied to No    
S3‑193949 Reply LS on UP gateway function on the N9 interface S2-1910808 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		replied to No    
S3‑193950 256 bit radio interface algorithm performance ETSI SAGE LS in  
6.3ETSI SAGE
 		Yes
YesCATT: the question depends on the implementation, so it's hard to have a reply. Dedicated hardware needs to be used to achieve the required performance. We should focus on the security algorithm itself and not in its performance. Apple supported CATT: don’t focus on performance issues. Vodafone replied that there are criteria that needed to be taken into account by SAGE. SA3 could very well reply that it is up to them to decide on these parameters. Alex (BT) reminded that HTTP digest and IPSec had a similar issue in the past, and SA3 chose not to intervene so this lead to implementation problems.
 		replied to No    
S3‑193951 LS on Enhancing Location Information Reporting with Dual Connectivity S3i190671 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑193952 LS on SG17 new work item X.sles “Security measures for location enabled smart office services” ITU-T SG17 LS in  
6.10Other Groups
 		Yes
Yes
 		noted No    
S3‑193953 LS on SG17 new work item X.nsom-sec “Security requirements and architecture for network slice orchestration and management” ITU-T SG17 LS in  
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesNo action for SA3.
 		noted No    
S3‑193954 LS on status of draft Recommendation ITU-T Q.SR-Trust “Signalling requirements and architecture for interconnection between trustable network entities” ITU-T SG11 LS in  
6.10Other Groups
 		Yes
Yes
 		noted No    
S3‑193955 LS on SG11 activities related to improvement of the SS7 security including for digital financial services SP-190586 LS in  
6.10Other Groups
 		Yes
Yes
 		noted No    
S3‑193956 LS on SUCI computation from an NSI CP-192262 LS in  
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		replied to No    
S3‑193957 N9HR Regulatory Obligations S3i190548 LS in  
6.13GPP Working Groups
 		Yes
YesORANGE: gNode B encrypts the traffic in the visited network, why encrypting this in the UPF? BT: we have to turn off the encryption in the UPF for LI reasons. It would be nice to turn that back on. Amelia (Article 19): countries cooperating with each other, law enforcement, better than a technical solution like this. BT: make the security hole smaller would be preferable for us. ORANGE: I prefer to have a paper expalining the issues better. It was decided to note the document since the next step would be a Study Item.
 		noted No    
S3‑193958 LS on security consideration of performance measurement function protocol C1-196940 LS in  
6.13GPP Working Groups
 		Yes
YesThere were companies supporting either replying (something is needed)
 		postponed No    
S3‑193959 TR 33.836 – update of evaluation for the solution #2 InterDigital Communications pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		revised No S3‑194620  
S3‑193960 33.836 – update of evaluation for the Solution #1 InterDigital Communications pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		revised No S3‑194616  
S3‑193961 TR 33.836 – update of evaluation for the solution #4 InterDigital Communications pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No    
S3‑193962 TR 33.836 - proposed conclusion for KI#1 InterDigital Communications pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		merged No S3‑194618  
S3‑193963 TR 33.836 - Proposed conclusion for KI#2 InterDigital Communications pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		merged No S3‑194650  
S3‑193964 TR 33.813 - update for solution #11 InterDigital Communications pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No    
S3‑193965 Draft for ‘proposed structure for network slice security procedures’ InterDigital Communications draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		merged No S3‑194536  
S3‑193966 draft Reply LS_on_CHO key derivation Apple LS out Approval
6.13GPP Working Groups
 		Yes
YesEricsson, Qualcomm: remove the last sentence from the LS. This was taken offline.
 		revised No S3‑194447  
S3‑193967 Discussion on Consecutive CHO key derivation Apple discussion Endorsement
6.13GPP Working Groups
 		No
Yes
 		withdrawn Yes    
S3‑193968 33401-CR on CHO key derivation Apple CR Approval
7.19.1SAE/LTE Security
 		Yes
YesDepending on the discussion for 448.
 		revised No S3‑194602  
S3‑193969 33501-CR on CHO key derivation Apple CR Approval
6.13GPP Working Groups
 		Yes
YesNokia: add reference to RAN2 spec. Huawei supported this. Christine (Ericsson): wait for the reply, we don’t need to make the changes now. Qualcomm didn’t agree with having the second change as RAN2 was still working on this topic. Wait for their reply.
 		revised No S3‑194448  
S3‑193970 Discussion on PMF Protocol Security Apple discussion Endorsement
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑193971 draft reply LS on security consideration of PMF Apple LS out Approval
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑193972 UP IP-update for solution#9 Apple pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
YesQualcomm had some issues with this and it was left open.
 		revised No S3‑194698  
S3‑193973 AUTH_Enh-update for solution#9 Apple pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		No
Yes
 		withdrawn Yes    
S3‑193974 AUTH_Enh-Evaluation for solution#2.4 Apple pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesThales: this solution does not lead to another kind of attack.The last paragraph had to be reformulated.
 		revised No S3‑194677  
S3‑193975 5GFBS-conclusion of key issue#2 Apple pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesOverlapping with 062,108, 339. There was no consensus for a way forward for key issue 2. Orange commented that the solutions of these documents had numerous security issues. The Chair asked who supported and who objected every solution: 395: Apple,Ericsson, Samsung, Commscope Objection: Orange, Qualcomm 4062: CableLabs, Apple, Samsung,Intel,BT,Commscope,Ericsson Objections: Orange, Qualcomm 108: Huawei, Qualcomm Objection: Orange,CalbleLabs,Ericsson, Commscope, Apple 339: Qualcomm, Huawei,Nokia,Deutsche Telekom,Orange Objection: Apple, Ericsson, CableLabs
 		noted No    
S3‑193976 5GFBS-Update for solution#7 Apple pCR Approval
8.4Study on 5G security enhancement against false base stations
 		No
Yes
 		withdrawn Yes    
S3‑193977 SID on privacy enhancement of 3GPP access and non-3GPP access in EPS Apple SID new Approval
8.16New study item proposals
 		No
Yes
 		withdrawn Yes    
S3‑193978 Issue of re-authentication when AMF re-allocation via NAS reroute vivo, Apple discussion Endorsement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesNokia: against SA2 decision. There was no agreement as Nokia and Qualcomm were against it. There was no issue for them.
 		noted No    
S3‑193979 New WID on eV2X security LG Electronics Inc. WID new Approval
7.20New work item proposals
 		Yes
Yes
 		revised No S3‑194468  
S3‑193980 Conclusion for Key issue 10 LG Electronics Inc. pCR Agreement
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		merged No S3‑194657  
S3‑193981 Conclusion for Key issue 9 LG Electronics Inc. pCR Agreement
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesHuawei proposed to wait for RAN2 response to the LS before concluding on this key issue. Qualcomm disagreed and preferred to conclude this in the current meeting. It's been taken on by other groups already (e.g. SA2). MCC suggested to remove the second sentence which was mentioning other working groups; as confirmed by Qualcomm this was already considered in other working groups anyway. Nokia suggested to add text on this key issue being out of scope of SA3.
 		noted No    
S3‑193982 Skeleton for TS on eV2X LG Electronics Inc. discussion Agreement
7.20New work item proposals
 		Yes
YesHuawei: 5.2.2 gives the impression that the privacy requirements are the most important. They are part of the security requirements. Article19 objected to removing privacy from the tile of clause 5.2.2. Huawei didn’t agree with keeping it in the title.
 		revised No S3‑194526  
S3‑193983 Update to Key Issue #6 KPN, China Mobile pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		No
Yes
 		withdrawn Yes    
S3‑193984 Update to Key Issue #6 KPN, China Mobile pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
Yes
 		approved No    
S3‑193985 End-to-end security KPN, China Mobile pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesIt will come back in the next meeting since it depends on other discussions.
 		noted No    
S3‑193986 Authentication subscription data KPN, Nokia pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
YesEricsson: possible to merge with 292. Nokia: address 2G and 3G? China Mobile had issues with the AMF in the case of the subscriber using 3G or 4G as well. Orange disagreed with Note 2.The SUPI specific parameter is part of the authentication subsription data when it is derived. The note was removed.
 		revised No S3‑194660  
S3‑193987 Introduction of the Inter PLMN UP security function in the architecture Deutsche Telekom AG discussion Decision
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑193988 LTKUP: editorial corrections to solution 5 in TR 33.935 THALES pCR Approval
8.8Study on LTKUP Detailed solutions
 		Yes
Yes
 		approved No    
S3‑193989 Reply LS on UP gateway function on the N9 interface Juniper Networks LS out  
6.13GPP Working Groups
 		Yes
YesNokia: not mandatory for us to follow SA2 guidelines. They didn't agree with removing their descripton. Nokia supported a reply LS, but this needed some reshaping. Ericsson had a similar position; better not to go against SA2.
 		revised No S3‑194452  
S3‑193990 Draft LS on PC5 unicast and groupcast security protection InterDigital Communications LS out Decision
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesQualcomm agreed with the LS but they wanted to enhance the first bullet.
 		revised No S3‑194658  
S3‑193991 KI 14 Potential Security Requirement NIST, ATT, Sprint Corporation, CableLabs, Deutsche Telekom AG, Cisco pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesEricsson: data format is not security related. NIST: the key issue is on communication in the user plane and prevent any communication that falls outside that scope. Ericsson: we assumed that this key issue should be left without security requirements, and concluded since there is a lot more to be evaluated; the study has continued for way too long.
 		revised No S3‑194490  
S3‑193992 New Solution for KI #14 NIST, ATT, Sprint, CableLabs, Deutsche Telekom AG, Cisco pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesEricsson: several editor's notes are needed since this solution is not complete: how it fits into the 3GPP network, how it interacts with the 3GPP elements. Huawei: remove the evaluation part, as it should be evaluated in SA2. Ericsson was also sceptical about this solution as it would require a lot of work and the timeline would not allow to fully study this part. Qualcomm: SA2 study is in Release 17 and this is for Release 16.
 		revised No S3‑194492  
S3‑193993 [33.180] R14 - Fix bad reference Motorola Solutions UK Ltd. CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193994 [33.180] R15 Fix bad reference (mirror) Motorola Solutions UK Ltd. CR Agreement
7.19.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑193995 [33.180] R16 Fix bad reference (mirror) Motorola Solutions UK Ltd. CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑193996 [33.180] R16 - Consistent use of off-network Motorola Solutions UK Ltd. CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		revised No S3‑194499  
S3‑193997 [33.180] R16 KM client to KMS security Motorola Solutions UK Ltd. CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑193998 [33.180] R16 - TrK ID and InK ID Motorola Solutions UK Ltd. CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		revised No S3‑194500  
S3‑193999 [33.180] R16 - InterSD KM record Motorola Solutions UK Ltd. CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194000 [33.180] R16 ETSI Plugtest clarifications Motorola Solutions UK Ltd. CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194001 LS to CT1 on 3rd ETSI MCX Remote Plugtest Motorola Solutions UK Ltd. LS out Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		revised No S3‑194501  
S3‑194002 DTR 33848 KI1 – clause 5_2_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194568  
S3‑194003 DTR 33848 KI2 – clause 5_3_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194569  
S3‑194004 DTR 33848 KI3 – clause 5_4_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194570  
S3‑194005 DTR 33848 KI4 – clause 5_5_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194571  
S3‑194006 DTR 33848 KI5 – clause 5_6_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194572  
S3‑194007 DTR 33848 KI6 – clause 5_7_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194573  
S3‑194008 DTR 33848 KI7 – clause 5_8_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194574  
S3‑194009 DTR 33848 KI8 – clause 5_9_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194575  
S3‑194010 DTR 33848 KI9 – clause 5_10_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194576  
S3‑194011 DTR 33848 KI11 – clause 5_12_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194578  
S3‑194012 DTR 33848 KI12 – clause 5_13_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194579  
S3‑194013 DTR 33848 KI13 – clause 5_14_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194580  
S3‑194014 DTR 33848 KI14 – clause 5_15_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194581  
S3‑194015 DTR 33848 KI15 – clause 5_16_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194584  
S3‑194016 DTR 33848 KI16 – clause 5_17_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194585  
S3‑194017 DTR 33848 KI17 – clause 5_18_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		noted No    
S3‑194018 DTR 33848 KI18 – clause 5_19_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		noted No    
S3‑194019 DTR 33848 KI19 – clauses 5_20_2 and 3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		merged No S3‑194588  
S3‑194020 DTR 33848 KI20 – clause 5_21_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194589  
S3‑194021 DTR 33848 KI21 – clause 5_22_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194590  
S3‑194022 DTR 33848 KI22 – clause 5_23_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194591  
S3‑194023 DTR 33848 KI23 – clause 5_24_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194592  
S3‑194024 DTR 33848 KI24 – clause 5_25_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194593  
S3‑194025 Discussion on CHO key derivation Apple discussion Endorsement
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑194026 AUTH_Enh-update for solution#4.1 Apple pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		revised No S3‑194675  
S3‑194027 Horizontal derivation when AMF re-allocation Apple, vivo CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		merged No S3‑194691  
S3‑194028 5GFBS-Update for solution#11 Apple pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		revised No S3‑194685  
S3‑194029 SID on privacy enhancement of 3GPP access and non-3GPP access in EPS Apple, Google, AT&T, Verizon UK Ltd, Accuris Networks, Charter Communications, Cablelabs, ARTICLE19, Sprint, Broadcom, Comcast SID new Approval
8.16New study item proposals
 		Yes
YesChina Mobile objected to this Study Item. Apple clarified that this was a study and that there would be no impact on existing solutions. Qualcomm didn't support it either: The phase 1 study already concluded that there was no further work necessary. No need to reopen this. Qualcomm, Nokia, Huawei, ZTE and Futurewei objected to this study. Interdigital, Article19 also supported the study apart from the source companies. Apple didn't see the point of objecting to a study and declared that there was no concrete reason for this.
 		noted No    
S3‑194030 Removing ENs in annex X in the living document for 5WWC CableLabs, Charter Communications, Rogers Communications, Nokia, Nokia Shanghai Bell CR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194400  
S3‑194031 CR-R16-Horizontal derivation when AMF re-allocation Apple, vivo CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		merged No S3‑194692  
S3‑194032 Update solution 4 to clarify MIB/SIB Hash report Huawei, HiSilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesTaken offline to keep note 3 and try to reach an agreement with Qualcomm.
 		revised No S3‑194688  
S3‑194033 Reply LS to RAN2 on FBS detection Huawei, HiSilicon LS out Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesQualcomm: we don’t have the detailed answers for these questions. We need to estabilise the solutions before we can answer to RAN2. Futurewei: if we postpone this we don’t get any progress until the July meeting next year. Apple: work on this offline and we may agree on an answer fr this meeting.
 		revised No S3‑194687  
S3‑194034 Preventing UE from Connecting to FBSs Huawei, HiSilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesEricsson: this solution is not needed. This will introduce significant delay and cause the handover procedure to fail. Samsung supported this.
 		noted No    
S3‑194035 Preventing UE from reselecting to FBS Huawei, HiSilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesNot needed, as it doesn’t adress the key issue properly. Orange: if the message coming from the network to the UE is not delivered for any reason, the UE cannot know that the message was intended to be sent. The UE doesn’t expect this message. You just need as an attacker to prevent the delivery of this message to the UE.
 		noted No    
S3‑194036 Handover UE under MitM FBS attacks Huawei, HiSilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesEricsson: Why do you assume that the man in the middle is gone after the handover? This will not work.
 		noted No    
S3‑194037 Conclusion for Key Issue #3 Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		noted No    
S3‑194038 Conclusion for Key Issue #4 Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		noted No    
S3‑194039 Conclusion for Key Issue #8 Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No    
S3‑194040 Conclusion for Key Issue #9 Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		noted No    
S3‑194041 New Solution for secure identifier conversion in groupcast Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesLG: not aligned with SA2 architecture. Orange: add an editor's note to improve this alignment. Huawei clarified that this was part of the SA2 architecture and not something new. Interdigital: group setup and provisioning need coverage. That's a problem. An editor's note was added about this. Orange: remove the evaluation part, this is not complete.
 		revised No S3‑194653  
S3‑194042 New solution to KI#9 Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		revised No S3‑194697  
S3‑194043 Addition of security threats and security requirements to KI#9 Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		No
Yes
 		withdrawn Yes    
S3‑194044 Conclusions to KI #6 Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No    
S3‑194045 Add content to Clause X.X.2 of eNS Huawei, HiSilicon draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		revised No S3‑194536  
S3‑194046 Amendment to Clause X.X.3 of Slice specific authentication procedure Huawei, HiSilicon draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesDiscussed together with 212. Nokia: This is not aligned with SA2.how does roaming work? Unclear how Every AMF in the network gets to the AAA proxy. Huawei replied that this was an SA2 issue. Ericsson: this solution doesn’t work. Qualcomm: align the message names properly in all steps.
 		merged No S3‑194537  
S3‑194047 Note for the User ID privacy protection in Clause X.X.3 Huawei, HiSilicon draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesNokia disagreed with the note.Orange commented that it should be a recommendation and not mandatory. It was also discussed whether it had to be a note or not. MCC commented that notes were informative, and any normative language (recommendation or requirement) could not be used in them. It was agreed to make it plain text and have it as a recommendation.
 		revised No S3‑194538  
S3‑194048 Discussion on Authentication method negotiation Huawei, HiSilicon discussion Endorsement
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesNokia,Qualcomm: we don’t need this.Ericsson agreed ith them, that if this was needed, it would be related to the AAA server.
 		noted No    
S3‑194049 Authentication method negotiation Huawei, HiSilicon draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194050 Conclusion to KI#3 Huawei, HiSilicon pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesOrange objected to having normative work for this key issue.Ericsson agreed.
 		noted No    
S3‑194051 Solution 8 update Huawei, HiSilicon pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesEricsson: IDLE case: AMF relocation is to be avoided as an assumption, and this is implying that the relocation is needed. Capture this in the evaluation. Interdigital: signalling overheard is a concern here. Nokia disagreed with removing the editor's note. This didn't seem to be working.
 		revised No S3‑194542  
S3‑194052 Overal evaluation to solutions addressing KI#6 Huawei, HiSilicon pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesInterdigital: Idle mobility needs to be revisited as we have done in previous papers. It was agreed to add an editor's note. Qualcomm: the table is already out of date according to the progress today. Orange: no additional value of this table for the TR.
 		noted No    
S3‑194053 Conclusions to KI #6 Huawei, HiSilicon pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesDiscussed together with tdoc 211.
 		noted No    
S3‑194054 Discussion on LS from SA2 on AUSF role Huawei, HiSilicon discussion Agreement
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesNokia: proposal 2 is a big impact on the architecture. There is also a proxy in the SA2 call flow with the same functionality as the proposed new NF. Ericsson agreed with Nokia. HP agreed with Huawei's proposal. Nokia: security for the new slice specific authentication workflow is not broken from the security perspective. Huawei should go to SA2 to defend their proposal. This was taken offline.
 		noted No    
S3‑194055 Discussion paper on LS (R2-1911565) on AS key derivation for Conditional Handovertional Nokia, Nokia Shanghai Bell discussion Endorsement
6.13GPP Working Groups
 		Yes
YesNokia: it's aligned with SA3 work, no changes need to be made.The discussion was taken in the CR proposed by Apple.
 		noted No    
S3‑194056 Discussion on LS R3-194784 on Disaggregated CU-UPs in different security domains Nokia, Nokia Shanghai Bell discussion Endorsement
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑194057 Discussion paper on PMF protocol security S3-193680 Nokia, Nokia Shanghai Bell discussion Endorsement
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑194058 Proposed text for clause x.2 of living CR for eNS Nokia, Nokia Shanghai Bell other Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		merged No S3‑194536  
S3‑194059 Key Issue#7 on revocation of rejected NSSAI Nokia, Nokia Shnghai Bell, Lenovo, Motorola Mobility pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesOrange: this looks more like a stage 3 issue. No need to have it in the document. Lenovo commented that CT had been working in parallel to study how to do the revocation and it needed to be addressed in SA3 as well. Qualcomm commented that this was a CT1 issue, not appropriate for SA3. Huawei stressed the importance of this issue and that it should be worked on in SA3. Nokia: no new solution proposed here. This is aligned with CT1. Orange: note the document and see if CT1 asks something to be done in SA3. Orange asked to be minuted: "If needed this will be handled in the normative work."
 		noted No    
S3‑194060 Solution for KI#7 on revocation of rejected NSSAI Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		noted No    
S3‑194061 URLLC living CR: clarifications related to security policy Nokia, Nokia Shanghai Bell other Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194062 Way forward on key issue 2 in TR 33.809 CableLabs discussion Endorsement
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No    
S3‑194063 Top research papers published in 2019 on 4G and 5G security CableLabs discussion Information
6.9CVDs and Research
 		Yes
YesCableLabs encouraged delegates to inform on similar papers presented in other conferences. Vodafone: dangerous precedent here, especially if we show papers that haven't been properly reviewed. There is an established process in 3GPP CVD for this. We need a filter in advance to this.
 		noted No    
S3‑194064 LS on security consideration of performance measurement function protocol ZTE Corporation LS out Approval
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑194065 Considerations on security handling of registration with AMF re-allocation ZTE Corporation discussion Endorsement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		noted No    
S3‑194066 Security handling in registration with AMF re-allocation ZTE Corporation CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		merged No S3‑194692  
S3‑194067 Editorial correction in TS 33.519 ZTE Corporation CR Agreement
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		merged No S3‑194479  
S3‑194068 Update of solution #12 in TR 33.813 ZTE Corporation pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		revised No S3‑194547  
S3‑194069 Update of key issue #3.2 in TR 33.846 ZTE Corporation pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		noted No    
S3‑194070 Solution of mitigating the SUPI guessing attacks ZTE Corporation pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		noted No    
S3‑194071 Update of solution #2.1 in TR 33.846 ZTE Corporation pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesEricsson: no evaluation yet for this one. Vodafone commented that the tendency was to remove the evaluations from the solutions so a different party could write them.
 		approved No    
S3‑194072 Key issue on security attack caused by IAB-node with removable UICC card ZTE Corporation pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
YesOrange: this is a deployment decision, up to the network operator. Qualcomm: we don’t need this key issue. IDEMIA agreed.
 		noted No    
S3‑194073 Definition of IAB-MT ZTE Corporation pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
YesNot needed anymore.
 		noted No    
S3‑194074 Add a note to key issue #9 in TR 33.836 ZTE Corporation pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		noted No    
S3‑194075 Reply LS on Handling of UE radio network capabilities in 4G and 5G Intel Corporation (UK) Ltd LS out  
7.19.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesQualcomm and Huawei agreed with this reply. Qualcomm added that it should be mentioned that SA3 was still studying this issue. This had to be taken offline as Nokia had issues with the reply to question 1.
 		revised No S3‑194488  
S3‑194076 Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility Intel Corporation (UK) Ltd CR  
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		revised No S3‑194458  
S3‑194077 Conclusion for Key issue 15 Intel Corporation (UK) Ltd pCR  
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		noted No    
S3‑194078 New SID on the security of the system enablers for devices having multiple Universal Subscriber Identity Modules (USIM) Intel Corporation (UK) Ltd SID new  
8.16New study item proposals
 		Yes
Yes
 		revised No S3‑194471  
S3‑194079 Security solution for UE Capability Transfer for UE with no AS security. Intel Corporation (UK) Ltd pCR  
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesNokia: this changes the behaviour of the base station. Ericsson: this procedure between the RAN and the core network is totally new. Intel agreed to add an editor's note on this.
 		revised No S3‑194494  
S3‑194080 Updates to Key issue Protection of UE capability transfer for UEs without AS security Intel Corporation (UK) Ltd pCR  
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes080,087,238,324 overlap in this issue.
 		revised No S3‑194491  
S3‑194081 Updates to solution 9 Intel Corporation (UK) Ltd pCR  
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		revised No S3‑194619  
S3‑194082 Address the EN in Solution #17 Huawei, Hisilicon pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑194083 Conclusion on protection of time synchronization Huawei, Hisilicon pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑194084 Address the EN on the reference in key issue 4.1 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesOverlapping with tdoc 026.
 		merged No S3‑194675  
S3‑194085 Add solution details and evaluation to solutioin 4.1 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesQualcomm had issues with the figure and the evaluation. They suggested to send this evaluation to SAGE to confirm that this assumption was Ok. The ealuation was removed.
 		revised No S3‑194679  
S3‑194086 Address the EN on the NAS procedure impact in Solution#2.4 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesEricsson: it doesn’t really address the editor's note.This had to be taken offline. Huawei asked to be minuted: "Ericsson rejected the contribution without any explanation."
 		postponed No    
S3‑194087 Add the threat and requirement in KI#15 Huawei, Hisilicon pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		merged No S3‑194491  
S3‑194088 Protection of UE capability transfer for CP optimization only CIoT UE Huawei, Hisilicon pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesNokia: System impact, on the NAS protocol, UE capability exchange, etc..An editor's note was added about this. Qualcomm, Ericsson had issue with the evaluation part. This was taken offline.
 		revised No S3‑194493  
S3‑194089 Security attack caused by an unauthorized IAB device Huawei, Hisilicon pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
YesOrange: the note doesn’t make sense without the requirements. Nokia: it assumes that removing the UICC and putting into another IAB node it becomes another IAB node. This is not true.
 		noted No    
S3‑194090 resolving editor's note on the move of access point Huawei, Hisilicon draftCR Approval
7.8Security of the enhancement to the 5GC location services
 		Yes
YesEricsson: moving the access point is not relevant here.Huawei conceded to go for Ericsson's proposal for the resolution of the second editor's note. Qualcomm: All release 16 Ues don’t have to support this. Clarify that it is optional.
 		merged No S3‑194466  
S3‑194091 Discussion on security of 5MBS enhancement Huawei, Hisilicon discussion Discussion
8.16New study item proposals
 		Yes
Yes
 		noted No    
S3‑194092 5MBS_Sec_SID_SA3 Huawei, Hisilicon SID new Approval
8.16New study item proposals
 		Yes
YesQualcomm: we support this but it is too early. Bring it back in February. Juniper supported this.
 		noted No    
S3‑194093 DraftCR_TSC protection Huawei, Hisilicon draftCR Approval
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		merged No S3‑194553  
S3‑194094 Adding evaluation to solution #10 in TR 33.813 Huawei, Hisilicon pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesQualcomm: the previous document covers this already. We don’t agree.
 		noted No    
S3‑194095 Providing some updates to Solution #15 in TR 33.836 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No    
S3‑194096 Evaluation of Solution #15 in TR 33.836 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesInterdigital: no requirements for key issue 9. Then we cannot have an evaluation. Huawei replied that this was an optimization issue and not security specific.Interdigital asked what was being solved here. Huawei asked where this could be handled then. LG replied that possibly RAN2 and an LS could be sent to them.
 		noted No    
S3‑194097 Providing analysis to Solution #13 in TR 33.836 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesInterdigital: it's a solution adopted from SA2 but not an invention of SA3. It was added a reference to the SA2 spec where this was coming from.
 		revised No S3‑194654  
S3‑194098 Discussion on Security for truncation of 5G-S-TMSI Huawei, Hisilicon discussion Endorsement
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesQualcomm: not a DoS issue. We can modify whatever messages in the middle and cause this DoS. Ericsson: the RAN cannot recreate the full 5G S-TMSI. Qualcomm: this does not introduce a new security issue. It was agreed not to describe the DoS attack in the LS.
 		noted No    
S3‑194099 Security Procedure for RRCConnectionRe-establishment Procedure for Control Plane Optimization for 5GS CIoT Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesClarifications and additions needed to be discussed offline. Huawei argued that it was too early to add the false base station scenario as proposed by Ericsson.
 		merged No S3‑194484  
S3‑194100 Reply LS to SA2 on Security Issue on 5G-S-TMSI Truncation Procedure Huawei, Hisilicon LS out Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesEricsson agreed with this LS with minor changes. Qualcomm didn’t agree with the DoS issue. The attack is based on man in the middle but it doesn’t lead to DoS.
 		noted No    
S3‑194101 CIoT Title Modifications to draft CR Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194102 Skeleton for Security handling in User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194103 General for Security handling in User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesEricsson wanted to align with the progress in RAN groups through the addition of two editor's notes.
 		revised No S3‑194485  
S3‑194104 Security handling in Connection Suspend Procedure for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		revised No S3‑194486  
S3‑194105 Security handling in Connection Resume in CM-IDLE with Suspend to a new ng-eNB for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		revised No S3‑194487  
S3‑194106 Security handling in Connection Resume in CM-IDLE with Suspend to the same ng-eNB for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194107 Conclusion for RRC Resume Request Protection Huawei, Hisilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesOrange,Samsung, Qualcomm objected to this conclusion.
 		noted No    
S3‑194108 Conclusion for Key Issue #2 Huawei, Hisilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No    
S3‑194109 Evaluation for solution #7 Huawei, Hisilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No    
S3‑194110 Address EN in solution 6 and solution 18 Huawei, Hisilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesNokia; whatever you send it will be accepted by the base station because you are connected to it. Nokia disagreed with the change. Ericsson was of the similar opinion. The dumb repeater does nothing else than repeating, so why the overhead? Huawei replied that the repeater was not really dumb. This was taken offline.
 		revised No S3‑194689  
S3‑194111 Add Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesQualcomm: we have this supported in LTE, so why do we need to repeat it for 5G as well? This was taken offline.
 		agreed No    
S3‑194112 Mirror for Adding Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		agreed No    
S3‑194113 Editorial change for trusted non-3GPP access Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194532  
S3‑194114 Update content for trusted non-3GPP access Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
YesNokia: not comfortable with enabling cyphering in IpSec.
 		revised No S3‑194533  
S3‑194115 Corrections on N5CW connects 5GC via trusted non-3GPP access Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194116 Using ERP for intra-TNAN mobility Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
YesLenovo asked to postpone this in order to analize it with more detail.This topic will be brought back in the next meeting.
 		noted No    
S3‑194117 Move Requirement of 5G-RG to clause 5 Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194609  
S3‑194118 Delete an assumption sentence Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194119 Add a new clause for N5CW privacy Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194120 UE activates UP IP over eUTRA to EPC Huawei, Hisilicon pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
YesEricsson: remove the evaluation. Vodafone proposed to add an editor's note in order to have something that could be changed instead of starting from zero. Qualcomm agreed to remove the evaluation. This implied a major impact and a proper study was needed here.
 		revised No S3‑194671  
S3‑194121 Update conclusion clause Huawei, Hisilicon pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
Yes
 		approved No    
S3‑194122 Ensure the same setting for UP policy Huawei, Hisilicon draftCR Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
YesNokia agreed with removing the editor's note but wanted some rewording of the preceding text.
 		merged No S3‑194470  
S3‑194123 Clarification on UP security policy preconfiguration Huawei, Hisilicon draftCR Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
YesQualcomm didn’t see the need of the new text at all, for the "preferred" option and so on. Nokia wasn't sure about this either. Huawei added that this clarification was needed. This was taken offline.
 		approved No    
S3‑194124 Further clarification on UP activation status Huawei, Hisilicon draftCR Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
YesNokia found that there was a lot of text here. Qualcomm preferred to have an option with minimal text.
 		noted No    
S3‑194125 Clean up Huawei, Hisilicon draftCR Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
YesNokia and Qualcomm didn’t agree with the change in the general clause. This had to be taken offline.
 		revised No S3‑194469  
S3‑194126 Living doc for 5WWC Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194529  
S3‑194127 AKMA network functions Huawei, Hisilicon pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesOverlapping with tdoc 200. Qualcomm: we don’t need the AMF for RAN. Vodafone: why so many network functions interfacing here? It woud be an ideal point for an attack, creating a security hole. We should be cautious and connect what we absolutely need.
 		merged No S3‑194641  
S3‑194128 AKMA interface description Huawei, Hisilicon pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesEricsson: remove N1,N2. Qualcomm: Namf not needed for AKMA either.
 		revised No S3‑194642  
S3‑194129 AKMA security principles and requirements Huawei, Hisilicon pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesOrange: lifetime of the keys is operators' decision.The first sentence of the last requirement was removed. Qualcomm and Orange didn’t agree with these requirements. Only the last sentence went into the merge.
 		merged No S3‑194643  
S3‑194130 AKMA key management Huawei, Hisilicon pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesEricsson: explicit/implicit lifetime was clear in the context of the TR but not so clear here. An editor's note was added to explain these in the future.
 		revised No S3‑194644  
S3‑194131 Adding some evidence Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194132 Modify the message names Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194133 Fix the threat reference numbers for AMF Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesOverlap with 343. Tdoc number on the cover is wrong. Nokia asked to be minuted: Nokia asked to be minuted the following comment: "The threat referenced in sub-clause 4.2.2.3.1 is not applicable to the requirement to be tested, and needs to be replaced with a new threat to be captured in TR 33.926".
 		merged No S3‑194475  
S3‑194134 Amendment on 4.2.2.1.2 on AMF Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
No
Yes
 		withdrawn Yes    
S3‑194135 Fix the threat reference numbers for UPF Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		merged No S3‑194476  
S3‑194136 Corrections on clause 4.3 Huawei, Hisilicon pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		revised No S3‑194561  
S3‑194137 New SID: Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC China Unicom SID new  
8.16New study item proposals
 		Yes
YesHuawei: based on the SA6 study. Qualcomm: too early based on SA2's progress. ORANGE supported this. BT: SA is currently working on the Release 17 prioritization and it could impact on this topic significantly. AT&T supported approving this study item given the current work in SA6 as they could benefit from the work in here. Qualcomm preferred to discuss this in February next year given that this was Release 17 work.
 		noted No    
S3‑194138 Discussion on Security of Multi-CU-UP connectivity CATT discussion Decision
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑194139 LS reply to RAN WG3 LS on security for multi-CU-UP connectivity CATT LS out Approval
6.13GPP Working Groups
 		Yes
YesCATT: it's too late for Release 16 from our point of view. NTT-Docomo didn’t find the text in LS very clear. Qualcomm: the UE is not aware of where the user plane ends, it's handled by the RAN. SA3 needs to study this anyway, as the current architecture is not sufficient; and that's what we need to reply to them. Nokia: study item for this? It's a simple change. Qualcomm replied that this could have a significant impact on the RAN. NTT-Docomo: network side security domain could be affected as well, so this is not so simple. They proposed to take this offline to study the consequences. CATT added that RAN3 was planning to do a WID in Release 17 about this topic.
 		revised No S3‑194450  
S3‑194140 Discussion about a new study on 5G Prose security CATT discussion Decision
8.16New study item proposals
 		Yes
YesCATT added that SA2 had planned to finish in June and that SA3 should consider that.
 		noted No    
S3‑194141 Clarifying interfaces in clause 5.2.3.3.4 and clause 5.2.3.4.5 China Mobile pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		revised No S3‑194563  
S3‑194142 Discussion on the Xn-Handover message CATT discussion Decision
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesThis was kept open until RAN3 had discussed the issue during the week and confirm the scenario. CATT got feedback from RAN3: it was considered a rare case and the final decision was to be taken by SA3. It was finally noted but further action will be taken in the next meeting.
 		noted No    
S3‑194143 Conclusion for KI#7 Lenovo, Motorola Mobility pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		noted No    
S3‑194144 Update of Solution#15 Lenovo, Motorola Mobility pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		approved No    
S3‑194145 Adding security requirements for GVNP of type 1 China Mobile pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		revised No S3‑194564  
S3‑194146 Removal of Editor’s Note and update of the Figure 6.Y.4-1 Lenovo, Motorola Mobility draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194147 Adding security functional requirements deriving virtualisation and related test cases for GVNP of type 1 China Mobile pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		noted No    
S3‑194148 Update of solution#14 Lenovo, Motorola Mobility pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesHuawei: this is not addressing the availability part of the editor's note. Lenovo: the UE has an internal clock and we don’t depend on any time information from the outside.
 		approved No    
S3‑194149 Solution#14 Evaluation Lenovo, Motorola Mobility pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesEricsson: what happens if you are running out of battery? Lenovo: same as going out of coverage. For LG the evaluation needed to be completed with additional statements on UE out of coverage scenario.
 		revised No S3‑194651  
S3‑194150 Draft CR as a living baseline for 5GS LCS normative work CATT draftCR Approval
7.8Security of the enhancement to the 5GC location services
 		Yes
YesLiving document used as a baseline for the contributions in this meeting.
 		revised No S3‑194465  
S3‑194151 Revise the Evaluations for Solution 5 in TR 33.853 China Mobile pCR  
8.9Study on User Plane Integrity Protection
 		Yes
YesVodafone: it needs better English. Qualcomm didn’t agree with the document.
 		noted No    
S3‑194152 Discussion on the UP IP for 5G RAN connected 5GC China Mobile discussion Endorsement
8.9Study on User Plane Integrity Protection
 		Yes
Yes
 		noted No    
S3‑194153 Draft CR for eLCS on access point security CATT draftCR Approval
7.8Security of the enhancement to the 5GC location services
 		Yes
Yes
 		merged No S3‑194466  
S3‑194154 Add the conclusion on the UP IP for 5G RAN connected to 5GC China Mobile International Ltd pCR  
8.9Study on User Plane Integrity Protection
 		No
Yes
 		withdrawn Yes    
S3‑194155 Solution for destination L2 privacy Ericsson pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesHuawei disagreed with this solution.There were several issues that were not specified. Lenovo: How many IDs will you have to ensure your privacy? What will be the size of the set of the group IDs?
 		noted No    
S3‑194156 Add Abrreviations to TS 33.535 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194157 Miscellaneous Editorial clarifications in 33.916 Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesHuawei wanted to point out that there were unresolved editor's notes in the specification.
 		agreed No    
S3‑194158 Miscellaneous Editorial clarifications in 33.926 Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194159 Miscellaneous Editorial clarifications in 33.117 Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesHuawei commented that there were some issues that they couldn’t fix. E.g. references such as [ef]. Huawei asked to minute that there were references that were unresolved and that anyone was welcome to fix them.
 		agreed No    
S3‑194160 Update on AKMA reference model China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesQualcomm: it should be an editor's note. China Mobile commented that this would mean that SA3 would have to resolve it and that wasn't necessary.
 		approved No    
S3‑194161 Update of clause 4 Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesEricsson argued that having the text in the document was OK.Nokia supported Ericsson.
 		not pursued No    
S3‑194162 remove unspecified SDOs Huawei, Hisilicon pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		revised No S3‑194562  
S3‑194163 Adding conclusion on KI #6.2 Huawei, Hisilicon pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesEricsson preferred the Nokia alternative. Qualcomm: there is no security reason for NAS signalling, and in SA2 they are not sure whether this is needed. Huawei: not sending CAG ID would have security issues and would affect SA2 decisions. Samsung replied that conclusion in SA3 should be done when SA2 concluded their discussions. This was left open for discussion.
 		noted No    
S3‑194164 CAG ID privacy Huawei, Hisilicon draftCR Approval
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
YesOpen depending on the agreements on the CAG ID privacy.
 		noted No    
S3‑194165 New KI: Service access authorization for non-delegated subscribe-notify Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194510  
S3‑194166 eSBA: add conclusion on KI #5 Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194167 eSBA: conclusion update on KI #22 Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194168 eSBA: conclusion update on KI #29 Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194512  
S3‑194169 Conclusion on KI #4.1 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesNokia: don’t include internal GSMA internal papers in the zip file. Huawei's understanding was that the research paper had been made public, although a reference should have been added instead of adding the paper. Qualcomm didn’t agree with the solution and conclusions.
 		noted No    
S3‑194170 Editoral changes on solution for AKMA change Huawei, Hisilicon pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
YesEricsson: make sure to mention all ocurrences of security contexts here.
 		revised No S3‑194638  
S3‑194171 Resolving the editor’s notes in the solution of AKMA change Huawei, Hisilicon pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
YesQualcomm didn’t agree with this evaluation. No need for two PUSH solutions since SA3 had already a GBA Push work item ongoing. Vodafone supported this.
 		noted No    
S3‑194172 AKMA: add conclusion on KI #17 Huawei, Hisilicon pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
YesTaken offline whether it will have one or two Push solutions.
 		noted No    
S3‑194173 Resolving the EN and adding the evaluation of solution #17 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesInterdigital disagreed wtih the first paragraph. This was removed.
 		revised No S3‑194647  
S3‑194174 eV2X: Conclusion on KI#2 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		noted No    
S3‑194175 eV2X: Solution for the UP security activation policy handling in NR PC5 unicast Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesInterdigital: linked to the new requirement we added in a previous document on key issue 2.
 		revised No S3‑194648  
S3‑194176 eV2X: Conclusion on one requirement of KI#2 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		merged No S3‑194650  
S3‑194177 eV2X: conclusion on KI #10 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		revised No S3‑194657  
S3‑194178 eV2X: Conclusion on KI#2 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		withdrawn Yes    
S3‑194179 Clarification on aspects specific to the network product class UDM and AMF Huawei, Hisilicon CR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		revised No S3‑194419  
S3‑194180 New WID: Work Item on Security Assurance Specification for IMS Huawei, Hisilicon WID new Approval
7.20New work item proposals
 		Yes
YesORANGE: why excluding the IMS Access Gateway from the scope of the WID? Huawei commented that they were open to other network elements. It was agreed to generalize this. It was clarified that this affected Release 17 (wrong templated used for this WID). Nokia: SCAS for 5G or LTE? In SA2 they are working on IMS for 5G. ORANGE: this is SCAS for the previous Release, as we always do. This is SCAS for Release 15.
 		revised No S3‑194527  
S3‑194181 New SID: Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC Huawei, Hisilicon SID new Approval
8.16New study item proposals
 		Yes
YesHuawei: based on the SA2 study. AT&T: SA2 and SA6 have separate architectures so we want to support a split of study items. CableLabs supported initiating the work now. Telecom Italia: puzzled with having two studies with the same title. SA3 should have a single SID about this topic. Huawei wondered who supported having to split the study into two. The Chair commented that part of the reason was to have two rapporteurs,practice that had been deprecated in SA. This was a possible solution for that.
 		noted No    
S3‑194182 New solution for authorization in the non-delegated "Subscribe-Notify" interaction scenarios Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194511  
S3‑194183 Update on solution#15 in TR 33.855 Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194425  
S3‑194184 Conclusion on authorization in the non-delegated Subscribe-Notify interaction scenarios Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194185 Conclusion on authorization in the delegated Subscribe-Notify interaction scenarios Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194186 Conclusion on service access authorization of a NF Set Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194508  
S3‑194187 Service access authorization of a NF Set Huawei, Hisilicon draftCR Approval
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
YesContent is moved to the CR in 523.
 		noted No    
S3‑194188 Resolving the ENs of solution#2.5 in the TR 33.846 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesVodafone: describe how the MAC will impacted. The solution relies on the handset based SUCI mechanism. China Mobile: where is the key in step2? Add that the solution doesn't apply to legacy USIMs.
 		revised No S3‑194678  
S3‑194189 Resolving the ENs in KI#3.1 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesVodafone: don’t mention CT4, refer to their spec. Ericsson: keep the editor's notes. Vodafone: correct the English. Orange commented that this looked like the problem was coming from CT4, so it had to be fixed in there and not in SA3. Nokia: delete the key issue and send an LS. Orange: keep the key issue and delete the requirements. This was taken offline.
 		revised No S3‑194673  
S3‑194190 Resolving the ENs of solution#5 in the TR 33.809 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesInterdigital: refer to a generic satellite system, not specifically GPS. Revised to address this and other comments with editor's notes.
 		revised No S3‑194690  
S3‑194191 Conclusion on mitigation against the authentication relay attack Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesOrange disagreed with it.
 		noted No    
S3‑194192 Evaluation on service access authorization of a NF Set in non-roaming scenario Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194506  
S3‑194193 Evaluation on service access authorization of a NF Set in roaming scenario Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194507  
S3‑194194 Security requirement on Key Issue #24: service access authorization of a NF Set Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194505  
S3‑194195 Solving registration failure in registration procedure with AMF reallocation Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesQualcomm didn’t see any advantages in this proposal. Nokia wanted to wait for SA2's discussions. All agreed on having an issue for Release 16. The Chair asked if SA3 needed to wait for SA2's progress and Huawei strongly disagreed. This had to be taken offline. NTT-Docomo: Rel-15 UEs that end up in the wrong place? What do we do about them? Non-backward compatible changes are a cause for concern.
 		not pursued No    
S3‑194196 Clarification on AMF reallocation via direct NAS reroute for Rel-15 Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesQualcomm: we are adding new functionality in the UE and we don’t agree with that. ZTE: changes should go to Release 16 only.
 		not pursued No    
S3‑194197 Clarification on AMF reallocation via direct NAS reroute for Rel-16 Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		not pursued No    
S3‑194198 Clarification on primary authentication in direct NAS reroute for Rel-15 Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		revised No S3‑194691  
S3‑194199 Clarification on primary authentication in direct NAS reroute for Rel-16 Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		revised No S3‑194692  
S3‑194200 Add AAnF description into clause 4.2 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesQualcomm: requirements should go to the requirements clause, not here. Huawei: remove the editor's note.
 		revised No S3‑194641  
S3‑194201 Add content to clause 4.4 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		revised No S3‑194643  
S3‑194202 Updates to solution #7 - capability negotiation Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		revised No S3‑194667  
S3‑194203 Updates to solution #7 - network sharing Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No    
S3‑194204 Updates to solution #7 - signature schemes and length Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesOrange: the ETSI SAGE sentences should be removed.
 		revised No S3‑194683  
S3‑194205 [DRAFT] LS out to SA5 about SON poisoning Ericsson LS out Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesNokia: what do you want SA5 to do? Orange: better talk to your SA5 colleagues about this. It is not clear what SA5 needs to do about it. NTT-Docomo: clarify what they really need to do. This was taken offline.
 		noted No    
S3‑194206 [DRAFT] Reply LS on false base station detection Ericsson LS out Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		merged No S3‑194687  
S3‑194207 Way forward - KI#3 False RBS detection Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesQualcomm: perform the evaluation before concluding. Orange: this conclusion means that we should do nothing and it is left to implementation.They didn’t agree with this way forward.
 		noted No    
S3‑194208 Updates to solution #17 - resolving Ens Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesOrange: confused with the terminology ("newer network?), add an editor's note about that. Get rid of the shalls, the evaluation should be removed. The network negotiation to support the feature is FFS.
 		revised No S3‑194668  
S3‑194209 Conclusion on end to end security China Mobile, KPN pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
YesEricsson: you are proposing an informative annex for normative work. KPN: we want it normative and if this is not agreed it would become informative. Vodafone: this text is not an evaluation or a conclusion. Qualcomm: this is not part of AKMA. It's pat of the interface between UE and application function. This had to be taken offline.
 		revised No S3‑194636  
S3‑194210 Add abbreviations and editorial changes to TR 33.835 China Mobile pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
Yes
 		approved No    
S3‑194211 Conclusion on KI#6 Ericsson, Nokia, Nokia Shanghai Bell pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesInterdigital needed to see an additional analysys. The proposed solutions in the TR should be completed first before writing this evaluation. This was noted. The Chair recommended to keep working offline with this conclusion for the next meeting in order to finish the study.
 		noted No    
S3‑194212 DraftCR – Proposed call flow for Network Slice Specific Authentication and Authorization Ericsson draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesChina Mobile:NSSAI sent to the AAA server from network operator in step 7. NSSAI is a private part of the network's operator topology. Ericsson: this is needed in the AAA server for revocation procedures to work. Huawei disagreed, as there was alternative information that could be sent, some transformation of the information like done with the SUPI. Nokia was aligned with Ericsson. Nokia: no privacy sensitive information in the NSSAI today.
 		revised No S3‑194537  
S3‑194213 DraftCR - Proposed flow for Re-authentication and Re-authorization Ericsson draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesNokia: early to adopt this. Add an editor's note. Ericsson replied that SA3 needed to send these flows to SA2, so an editor's note may not be approriate. Huawei: reference to the SA2 document instead of copying the whole content from SA2. What if they update their part? Qualcomm agreed, no need to have a duplication in both groups since SA2 and SA3 could be updating the same text differently.The Chair agreed that this was a general problem and it needed to be discussed further. SA3 should make sure that work is not duplicated by communicating changes to SA2. This was taken offline.
 		revised No S3‑194539  
S3‑194214 DraftCR - Proposed flow for clarifying primary authentication steps Ericsson draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		merged No S3‑194536  
S3‑194215 DraftCR – Proposing a new AUSF service to support NSSAA flow Ericsson draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesThis depends on the outcome of the discussion on the AUSF involvement (LS in 535). Taken offline to address the
 		revised No S3‑194540  
S3‑194216 Cover sheet TR 33.835 China Mobile International Ltd TS or TR cover Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		No
Yes
 		withdrawn Yes    
S3‑194217 Cover sheet TR 33.835 for approval China Mobile TS or TR cover Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
YesVodafone objected sending this document for approval during the current meeting. The document was clashing with other existing specs and Vodafone needed more time to evaluate the TR. China Mobile commented that the completion was above 80% already. Vodafone added that the specification needed to go to EditHelp as well. Vodaone had a sustained objection. They were the only one. NTT-Docomo: there are numerous editor's notes and this should be mentioned in the outstanding issues. Orange: write cleanup in the outstanding issues. Mauro (TIM): if the group agrees on a needed cleanup what's the rush for sending this now instead of the next meeting? China Mobile: SA should know that we have done 80% of the work. BT found it better to delay and joined Vodafone. The Chair commented that the next meeting would focus especially on normative work and that the group would be under a lot of pressure to finish release 16.
 		revised No S3‑194695  
S3‑194218 Discussion on new SID for enhanced security to support new Non Public Network evolvement Ericsson discussion Endorsement
8.16New study item proposals
 		Yes
Yes
 		noted No    
S3‑194219 New SID: Study on enhanced security support for Non-Public Networks Ericsson SID new Agreement
8.16New study item proposals
 		Yes
YesORANGE: this is very early work in SA2. Everything is open and it is not time to start the work in SA3 yet. Ericsson: there are several agreements from which we can start the work. There is a risk that they will do some security work if we don’t start soon. ORANGE: this will lead to overlapping key issues being worked in both SA2 and SA3, and I want to avoid that. Nokia: it is too early to start the work. SA3 should continue the work in Vertical LAN and not compete with eNPN.
 		noted No    
S3‑194220 New solution to preserve CAG-ID privacy Ericsson pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesNokia disagreed, as this was against what SA2 was doing. Huawei supported Nokia. Ericsson: we could consider this as a solution. Nokia: come back with this if SA2 changes their mind.
 		noted No    
S3‑194221 New conclusion to preserve CAG-ID privacy Ericsson pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑194222 New conclusion for handling UP security policy in a 5GLAN group Ericsson pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesHuawei: no normative work is required for this key issue. Ericsson: Then how all Ues in the same group have the same policy then? It was agreed to add an editor's note. The text for this was taken offline.
 		revised No S3‑194555  
S3‑194223 Update test cases for gNB SCAS Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		revised No S3‑194474  
S3‑194224 Fix some reference numbers Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194225 Resolve EN about how to ensure the UP security policy to be the same Ericsson draftCR Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
Yes
 		revised No S3‑194470  
S3‑194226 Resolve EN about MN being preconfigured with SN capability to perform UP IP Ericsson draftCR Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194227 Necessity discussion for security study of eNA phase 2 China Mobile discussion Discussion
8.16New study item proposals
 		Yes
Yes
 		noted No    
S3‑194228 Clause 6.X – Deriving AKMA key during UE registration Nokia, Nokia Shanghai Bell, China Mobile pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesQualcomm proposed two editor's notes on the association with the UE is FFS.
 		revised No S3‑194645  
S3‑194229 Clause 6.Y – Deriving AF key for a specific Application function Nokia, Nokia Shanghai Bell, China Mobile pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194230 Add the conclusion on the UP IP for 5G RAN connected to 5GC China Mobile pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
YesVodafone didn’t see where this solution was coming from.
 		noted No    
S3‑194231 Add Definition of Execution Environment Interface in 33.818 Nokia, Nokia Shanghai Bell, China Mobile pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		merged No S3‑194563  
S3‑194232 [DRAFT] LS on SECAM Accreditation for Virtualised Network Products (VNPs) Nokia, Nokia Shanghai Bell, China Mobile LS out Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		revised No S3‑194567  
S3‑194233 Proposed conclusion to KI#3 Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No    
S3‑194234 Proposed revision of conclusion to KI#2 Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No    
S3‑194235 Proposed conclusion to KI#1 Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		revised No S3‑194498  
S3‑194236 [Draft CR] RRC Connection Re-Establishment for the control plane for NB-IoT radio access connected to 5GC Ericsson other Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		revised No S3‑194484  
S3‑194237 [Draft CR] RRC Connection Resume and Suspend procedures for the user plane for NB-IoT radio access connected to 5GC Ericsson other Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑194238 KI#15 - new requirement for handling UEs without AS security Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesQualcomm: requirement too vague.
 		merged No S3‑194491  
S3‑194239 KI#15 - new solution for handling UEs without AS security Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesQualcomm: this doesn't mitigate the threat. Intel agreed with Qualcomm. Qualcomm: UE capability never verified by the network.
 		approved No    
S3‑194240 Removal of three obsolete Editor’s Notes Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No    
S3‑194241 DRAFT Reply LS on Handling of UE radio network capabilities in 4G and 5G Ericsson LS out Approval
7.19.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑194242 DraftCR – Living document for supporting 5G CIoT security Ericsson other Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		revised No S3‑194483  
S3‑194243 Security of RRC UE capability transfer procedure in EPS Ericsson CR Approval
7.19.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesQualcomm: release 16 new feature, so we should wait for the results of the study to be completed. Ericsson: EPS is not part of the study, this is a different issue. Nokia: this is something new for legacy (LTE) Ues. Qualcomm: we want the same mechanism as 5G in here, but let's wait until the study is finished. Huawei agreed with this.
 		not pursued No    
S3‑194244 RRC Connection Resume and Suspend procedures Ericsson CR Approval
7.19.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesNokia wanted to add more text to make it clear. They agreed with the change. Ericsson didn’t find this necessary. Nokia promised to bring a CR next time to propose
 		agreed No    
S3‑194245 RRC Connection Resume and Suspend procedures Ericsson CR Approval
7.19.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		agreed No    
S3‑194246 Proposed conclusion to KI #14 Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesLeft open since it depended on the discussion about key issue 14.
 		revised No S3‑194604  
S3‑194247 Key issue on Protection of long-term key during storage in UDR KPN, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
YesVodafone: missing the threat on the user data being uncovered (decoding previously recorded previous communications) when the long term key is known by the attacker. Orange: who is the entity targeted in the first requirement? NTT-Docomo: another missing threat on someone stealing the service on behalf of someone else. A consumer paying for someone else using their service.Copying a protected key in a different subscription. Then the corresponding requirement. IDEMIA: remove the sentence on creating unauthorised USIMs.
 		revised No S3‑194661  
S3‑194248 pCR for eV2X TS Ericsson pCR Approval
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		Yes
Yes
 		merged No S3‑194613  
S3‑194249 Key issue on Protection of long-term key during transfer out of UDR KPN, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
YesOrange had problems with the requirements.Related to the previous document (661).
 		revised No S3‑194662  
S3‑194250 Editorials and corrections to Security requirements for SeCoP Ericsson draftCR Approval
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194517  
S3‑194251 Editorials and corrections to Protection of N9 interface Ericsson draftCR Approval
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
YesIt will go to tdoc 444.
 		approved No    
S3‑194252 Using Rel-15 token-based authorization in indirect communication scenarios Ericsson CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		not pursued No    
S3‑194253 Conclusion of Key Issue #28: Service access authorization in the delegated "Subscribe-Notify" scenarios Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194254 Conclusion for Key Issue #5 "NF-NF Authorization" Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194514  
S3‑194255 Update to conclusion on Key issue #23: NF to NF authentication and authorization in Indirect communication Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194256 Security for roaming interfaces in indirect communication Ericsson CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194519  
S3‑194257 Removal of Editor's Notes for Security of indirect communication in roaming scenarios Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194515  
S3‑194258 New Key issue on NF subtypes for authorization granularity Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194513  
S3‑194259 Update of Solution #32: OAuth 2.0 based resource level authorization of NF service consumers Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194260 Conclusion on NF subtypes for authorization granularity Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194261 Resource Level Authorization using Access Tokens Ericsson CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		not pursued No    
S3‑194262 Authorization using Access Tokens based on NF-Subtype Ericsson CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
YesNokia: the key issue is still open. This was left open depending on the outcome of the key issue.
 		not pursued No    
S3‑194263 Certificate and CRL profile update Ericsson CR Agreement
7.19.16Other work items
 		Yes
YesHuawei asked these group of CRs to be postponed for the next meeting. MCC commented that the notes were not appropriate as they were predicting the prohibition of features in future 3GPP releases.
 		not pursued No    
S3‑194264 TLS Recommended Cipher Suites Ericsson CR Agreement
7.19.16Other work items
 		Yes
Yes
 		not pursued No    
S3‑194265 Required TLS extenstions and algorithms Ericsson CR Agreement
7.19.16Other work items
 		Yes
Yes
 		not pursued No    
S3‑194266 IKEv2 profile update 33.210 Ericsson CR Agreement
7.19.16Other work items
 		Yes
Yes
 		not pursued No    
S3‑194267 IKEv2 profile update 33.310 Ericsson CR Agreement
7.19.16Other work items
 		Yes
Yes
 		not pursued No    
S3‑194268 Using EAP-TLS with TLS 1.3 Ericsson CR Agreement
7.19.16Other work items
 		Yes
YesOrange commented that Annex B was informative so the normative text could not be ntroduced here.
 		not pursued No    
S3‑194269 New WID on 3GPP profiles for cryptographic algorithms and IETF protocols Ericsson WID new Agreement
7.20New work item proposals
 		Yes
YesQualcomm: remove PFS objective and justification. NCSC: bullets look like key issues or solutions rather than objectives. Ericsson clarified that there were CRs for this meeting already, but with the WID TEI16 (to be changed to DUMMY).
 		revised No S3‑194528  
S3‑194270 Test cases referring to TS 33.117 Ericsson CR Agreement
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesHuawei and CATT objected to this CR.
 		not pursued No    
S3‑194271 Resolving ENs in Draft CR as a living baseline for 5GS LCS normative work Ericsson draftCR Approval
7.8Security of the enhancement to the 5GC location services
 		Yes
YesNokia supported this solution but didn’t see why changing "should" to "shall". Ericsson: what to do if the UE doesn’t receive this lst? In this case the UE would not be able to send its location for emergency purposes. Nokia didn’t agree with mandating this behaviour. This was taken offline.
 		revised No S3‑194466  
S3‑194272 Update of the key hierarchy Ericsson pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
YesOverlapping with 341.
 		noted No    
S3‑194273 Conclusions on Key Management Ericsson pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
YesChina Mobile: The case of the reauthentication being not successful is not clear to me. Ericsson replied that this wasn't a reauthentication but another authentication decided by the network, a subsequent authentication. Huawei didn’t agree with this. Taken offline.
 		revised No S3‑194637  
S3‑194274 [Draft CR] Security requirements for F1 interface Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194275 [Draft CR] Security requirements on the IAB node, IAB donor and 5GC supporting IAB architecture Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
YesQualcomm: IAB donor instead of parent IAB.
 		revised No S3‑194595  
S3‑194276 [Draft CR] Security mechanisms for the F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194277 [Draft CR] General introduction to IAB-node Integration Procedure Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		merged No S3‑194597  
S3‑194278 [Draft CR] Authentication of IAB nodes Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		merged No S3‑194598  
S3‑194279 [Draft CR] Authorization of IAB nodes Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		merged No S3‑194598  
S3‑194280 [Draft CR] Update of general introduction to IAB Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194281 Draft CR - Security for Integrated Access and Backhaul in EN-DC Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		merged No S3‑194599  
S3‑194282 AMF re-allocation Ericsson discussion Endorsement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesHuawei: SA2 is waiting for SA3's feedback, and SA3 is waiting for SA2's feedback. We are playing ping pong here.
 		noted No    
S3‑194283 TNAP mobility using ERP Ericsson discussion Endorsement
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
YesDiscussed together with tdoc 116.
 		noted No    
S3‑194284 Trusted access key hierarchy Ericsson draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
YesHuawei had some comments on the key names and this was left for offline discussion.
 		revised No S3‑194606  
S3‑194285 Trusted access key derivation Ericsson draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194607  
S3‑194286 Introducing missing definitions of untrusted and trusted non-3GPP accesses Ericsson draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
YesConcerns on the skeleton structure as stated by Huawei. ORANGE had concerns on whether this clause was necessary according to the content.
 		revised No S3‑194530  
S3‑194287 Determining trust relationship in the UE Ericsson draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194531  
S3‑194288 [DRAFT] Reply to: 256 bit radio interface algorithm performance Ericsson LS out Approval
6.3ETSI SAGE
 		Yes
YesCATT didn’t fully agree with the commodity hardware statement. Qualcomm: from UE perspective, this doesn’t preclude that SAGE can find other algorithms. Apple wanted to add this clarification. Vodafone: this is implied in all their work, we don’t need to add this clarification to every LS for them. NTT-Docomo: what is "commodity hardware" here? Replace it with something else. CATT agreed. CATT: don’t rule out hardware solutions. Apple wanted to add a sentence on the choosing of algorithms. Vodafone found obvious the process and there wans't any need of stating this. Vodafone explained that SA3 went to SAGE, who provides with algorithms that fulfil SA3's requirements. SA3 is the one choosing the algorithms, not SAGE.
 		revised No S3‑194456  
S3‑194289 UP-IP: Resolving editor's note in solution #7 Ericsson pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
YesQualcomm: this doesn’t address the RAN part.
 		approved No    
S3‑194290 Conclusion on Key Issue 6: UE connected to 5GC indicating support of UP IP over eUTRA Ericsson pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
YesCompeting with 338.
 		noted No    
S3‑194291 ARPF Deployment models Ericsson pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
YesVodafone asked why this had become an informative annex. Nokia commented that the clause was not completely related to the study but it was worth including it. Vodafone commented that as a TR all content was informative anyway.
 		approved No    
S3‑194292 Security Parameter Storage Ericsson pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
YesKPN: 4.1.2 and 4.1.3 overlap with our document and could go to clause 5. There is potential to merge. Orange: remove the e.g. in the first bullet point. Remove "identifier" in the second bullet. Ericsson replied that it was implementation specific, it would become more flexible. It was agreed to add proprietary algorithms. Vodafone: remove the last two sentences of 4.2.1.
 		revised No S3‑194664  
S3‑194293 Idle mode mobility from 5GS to EPS Ericsson CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesHuawei: not needed. The first change is a default rule that everybody knows. Ericsson: everybody in SA3 but not outside this group. Huawei: clause 8.6.1 already describes that, why repeat? Nokia supported that this change was not necessary. There was no support for this CR.
 		not pursued No    
S3‑194294 Idle mode mobility from 5GS to EPS Ericsson CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		not pursued No    
S3‑194295 Idle mode mobility from EPS to 5GS Ericsson CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesMCC: NOTE 2 contains normative language and that needs to be changed. Huawei had also some issues and this was taken offline.
 		revised No S3‑194460  
S3‑194296 Idle mode mobility from EPS to 5GS Ericsson CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		not pursued No    
S3‑194297 New KI: Existing authentication procedure lacking the PFS property Ericsson pCR  
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		No
Yes
 		revised No S3‑194346  
S3‑194298 Error handling against violation of the basic validation rules Nokia, Nokia Shanghai Bell CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesEricsson pointed out that this should go to Release 15. It was clarified that this was pointing to the Release 15 functionality of the SEPP. It was commented that the editor's note already appeared in the SCAS spec. This had to be taken offline.
 		not pursued No    
S3‑194299 33.216 Corrections for clean-up and alignment R15 Nokia, Nokia Shanghai Bell CR Approval
7.19.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesFuturewei disagreed with the removal of the test cases since those were being used. China Mobile: why removing 4.2.7? We care about the functional requirements. Futurewei preferred not to see editor's notes and it was asked to minute that the execution steps for Uu reference point in the test case in sub-clause 4.2.2.1.3 needed to be added.
 		revised No S3‑194480  
S3‑194300 33.216 Corrections for clean-up and alignment R16 Nokia, Nokia Shanghai Bell CR Approval
7.19.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesNokia asked to minute the following comment: "The execution steps for Uu reference point in the test case in sub-clause 4.2.2.1.3 need to be added."
 		revised No S3‑194481  
S3‑194301 33.117 Adding abbreviations and corrections for alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194302 Adding the provisioning of security policy to solution #16 Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		revised No S3‑194623  
S3‑194303 Resolving the Editor’s note on privacy in the evaluation of solution #8 Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No    
S3‑194304 Protection of IEs in Direct Communication Request message Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		revised No S3‑194649  
S3‑194305 Proposal of an evaluation of solution protecting IEs in Direct Communication Request message Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No    
S3‑194306 Proposal of an evaluation of solution #12 on protecting the traffic at the PDCP layer Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No    
S3‑194307 Proposal of an evaluation of solution #16 on the activation of user plane security in NR PC5 unicast Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesInterdigital: the solution is needed but we need a key issue for this. Qualcomm replied that it was part of key issue 2, protection of UP data. Revised to address this comment.
 		revised No S3‑194646  
S3‑194308 Proposal conclusion for key issue #2 on security for eV2X unicast messages over PC5 Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesCompeting conclusion with Huawei's proposals in the following contributions.
 		revised No S3‑194650  
S3‑194309 Proposed conclusion for Key Issue #1 on Unicast privacy Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesIt was asked to be minuted:The agreement is to use solution 1.
 		revised No S3‑194618  
S3‑194310 Proposed conclusion for Key Issue #4 on security of identifier conversion in groupcast communication Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesHuawei didn’t agree with this conclusion. LG supported Qualcomm.
 		noted No    
S3‑194311 Proposed conclusion for Key Issue #6 on Security of the UE service authorization and revocation Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesHuawei contribution had the same conclusion but Qualcomm was happy with going forward with tdoc 044.
 		noted No    
S3‑194312 Proposed text for the early clauses for V2X TS Qualcomm Incorporated, LG Electronics other Approval
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194313 Proposed text for security for V2X over Uu reference point clause Qualcomm Incorporated, LG Electronics other Approval
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		Yes
Yes
 		revised No S3‑194615  
S3‑194314 Proposed inclusion of groupcast and broadcast privacy solutions Qualcomm Incorporated, LG Electronics other Approval
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		Yes
Yes
 		revised No S3‑194613  
S3‑194315 Solving AMF re-allocations issues for via the RAN Qualcomm Incorporated discussion Endorsement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		noted No    
S3‑194316 Update to the evaluation of solution #4.1 on protecting SQN in AKA re-synchronisations Qualcomm Incorporated pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesApple: two editor's notes on more evalutation needed and how to deal with the legacy and new USIM.
 		revised No S3‑194681  
S3‑194317 Clarifications to solution #10 on protecting S-NSSAIs Qualcomm Incorporated pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesInterdigital: clarification of the Distribution of the Key ID is not here (Idle mode mobility). Add an editor's note about that. Qualcomm replied that this comment hadn't been done before when they were asked to bring a contribution with additional clarifications.
 		revised No S3‑194544  
S3‑194318 Update to the evaluation of solution #10 on protecting S-NSSAIs Qualcomm Incorporated pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesNokia commented that the impact of the idle mobility issue had to be considered. Ericsson: update this according to the editor's note added in the previous contribution. Nokia: retain the editor's note.
 		revised No S3‑194545  
S3‑194319 Removing editor's note on capturing all the details for alternative authentication methods Qualcomm Incorporated CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		revised No S3‑194549  
S3‑194320 Reply LS to SA2 on RRC Connection Reestablishment for CP for NB-IoT Qualcomm Incorporated LS out Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194321 CR on clarification of ARFCN in KgNB derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesHuawei: just put he reference. Qualcomm: better to give more information. The description would not be self-contained.
 		agreed No    
S3‑194322 CR on clarification of ARFCN in KgNB derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		agreed No    
S3‑194323 RRC UE capability transfer procedure for CP only CIoT UEs Qualcomm Incorporated CR Agreement
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesMCC argued that the CR was not introducing a correction but only adding an editor's note promising work. This was not adequate for a spec under change control and it would be better to bring the changes directly when the work in the study was mature. Qualcomm commented that without this editor's note 6.5.3 would It was proposed to add this to the living document and progress the work there; this was agreed. The CR was not pursued but the editor's note was added to the living document to continue the work there.
 		not pursued No    
S3‑194324 Security Requirement for KI #15 Qualcomm Incorporated pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		merged No S3‑194491  
S3‑194325 AMF verification of the UE radio capabilities for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesIntel: Hash seems to be sent in the initial request in an open message, add an editor's note. Qualcomm replied that it was mandatorily protected. Ericsson: step 3 might happen before step 2, not ensured that steps happen in this order. This was taken offline.
 		revised No S3‑194495 S3‑193391
S3‑194326 Hash based UE capability protection for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesIntel: in the Power ON scenario the initial registration request is sending the hash unprotected.. Ericsson: what happens if there is a mismatch? Huawei also had some issues, so these comments were taken offline.
 		revised No S3‑194497 S3‑193390
S3‑194327 Shared key based MIB/SIBs integrity information provided by gNB Qualcomm Incorporated pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		revised No S3‑194686 S3‑193361
S3‑194328 Evaluation on UE behavior on detection of false signature Qualcomm Incorporated pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No   S3‑193363
S3‑194329 Evaluation on signing key management Qualcomm Incorporated pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No   S3‑193364
S3‑194330 Solution #4 Evaluation (Enriched MR) Qualcomm Incorporated pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesHuawei didn’t agree with the text. This is talking only about the detection part. Ericsson didn’t agree either.
 		noted No   S3‑193365
S3‑194331 Evaluation on Solution #3.1 Qualcomm Incorporated, Ericsson pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
Yes
 		noted No   S3‑193358
S3‑194332 Evaluation on Solution #4.2 Qualcomm Incorporated, Ericsson pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
YesNokia: problematic to use the same F1. Samsung: it becomes more complex with wireless. There would be different procedures. Efficient in wireline would not be efficient with the wireless. The same wireline solution for the wireless would not be necessarily equally efficient. An additional sentence in the evaluation was to be discussed offline.
 		revised No S3‑194586  
S3‑194333 Conclusion on KI #4.1 Qualcomm Incorporated, Ericsson pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
Yes
 		noted No   S3‑193359
S3‑194334 Reply LS to SAGE on 256-bit algorithms Qualcomm Incorporated LS out Approval
6.3ETSI SAGE
 		Yes
Yes
 		merged No S3‑194456  
S3‑194335 Reply LS on SUCI computation from an NSI Qualcomm Incorporated LS out Approval
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
YesOrange commented that the derivation still needed to be standardised. Qualcomm replied that this was up to CT4. Thales: consider whether the identifiers are active or not. IMSI and NSI can be stored in SA6. NSI can be activated with a defined mechanism. It is possible to have two identifiers and having one activated in SA6. Thales: confirm that the NSI for AKA based authentication is always derived from the IMSI. Orange confirmed that.
 		revised No S3‑194548  
S3‑194336 Reply LS on PMF Qualcomm Incorporated LS out Approval
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑194337 Security aspects of RLOS Qualcomm Incorporated CR Agreement
7.18Provision of Access to Restricted Local Operator Services by Unauthenticated UEs – Security Aspects (Rel-16)
 		Yes
YesNokia: delete "manufactring time" from step 3. Vodafone: "where RLOS are supported"? Qualcomm replied that it referred to the regions where RLOS was supported. ORANGE commented on step 3 that the integrity of the white list was not ensured. It was agreed to bring back the manufacturing time and make it more strict. Orange: what is "valid USIM" in step 4? Qualcomm replied that if there is a USIM present with a ISIM that matches the MCC. It was agreed to remove "valid".
 		revised No S3‑194633  
S3‑194338 Proposed conclusion for KI#6 in TR 33.853 Qualcomm Incorporated pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
Yes
 		noted No    
S3‑194339 Proposed way forward for KI#2 in TR 33.809 Qualcomm Incorporated discussion Endorsement
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No    
S3‑194340 pCR: Adding UE – AF interface to the AKMA Reference Model Qualcomm Incorporated pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194341 pCR: pCR: Udpate of AKMA Key Hierarchy Qualcomm Incorporated pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194342 33.511 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesOverlapping with 223 and 270. The editor's notes were challenged and it was suggested to have an action point instead. Futurewei suggested to convert it into a note. Ericsson preferred to remove the editor's note and minute that the threat reference had to be replaced. Ericsson suggested: Some of the threat references are not aplicable to the requirements and they need to be replaced with new threat references that are applicable. Huawei: The whole test case needs to be revisited. The text to be minuted was taken offline. Futurewei: the removal of these test cases should not be brought back again. This has come several times already. Nokia asked to minute the following comment: "The threats referenced in sub-clauses 4.2.2.1.1, 4.2.2.1.2, 4.2.2.1.4, 4.2.2.1.5 4.2.2.1.6, 4.2.2.1.7, 4.2.2.1.8, and 4.2.2.1.9 are not applicable to the requirements to be tested, and need to be replaced with new threats to be captured in TR 33.926".
 		revised No S3‑194473  
S3‑194343 33.512 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		revised No S3‑194475  
S3‑194344 33.513 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesOverlap with 135.
 		revised No S3‑194476  
S3‑194345 33.514 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194346 New KI: Existing authentication procedure lacking the PFS property Ericsson,Apple, China Mobile, ZTE, Nokia pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesThales: it's been 4 times that this contribution has been brought here and last time there was a show of hands and it was rejected. We still object to the additional complexity that the addition of PFS mechanisms will bring. T-Mobile: it's a study, nothing normative and it is to be investigated. Thales replied that there was enough work already to bring in a new study item. Vodafone: no point of bringing this again if it was rejected before. Ericsson asked a show of hands. Who objected the key issue: Thales, IDEMIA, Qualcomm,Orange,Vodafone. Companies supporting the key issue: Apple Ericsson Nokia, ZTE,China Mobile, Huawei, ZTE, HP, T-Mobile
 		noted No   S3‑194297
S3‑194347 33.515 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		revised No S3‑194477  
S3‑194348 33.516 Corrections for alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194349 33.517 Adding abbreviations and corrections for alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		revised No S3‑194478  
S3‑194350 33.518 Adding abbreviations and corrections for alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194351 33.519 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		revised No S3‑194479  
S3‑194352 Security requirements for UP Gateway Function Nokia, Nokia Shanghai Bell, Juniper CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
YesThis CR will go together with the UP Gateway Function new WID that goes to the next SA plenary. That’s why it has the DUMMY WID code. The baseline was agreed and new changes would be merged into the revision.
 		revised No S3‑194443  
S3‑194353 TR 33.848 Solution – lock-down of infrastructure NCSC pCR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194582  
S3‑194354 TR 33.848 Solution – trust domains and separation NCSC pCR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194583  
S3‑194355 Protection of N9 interface Nokia, Nokia Shanghai Bell, Juniper Networks CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
YesThis CR will go together with the UP Gateway Function new WID that goes to the next SA plenary. That’s why it has the DUMMY WID code. The baseline was agreed and new changes would be merged into the revision.
 		revised No S3‑194444  
S3‑194356 New WID for User Plane Gateway Function for the Inter-PLMN Security Juniper Networks WID new Agreement
5.1Output of SA3#96-Ad hoc
Yes
YesVodafone asked if the date was realistic, but Juniper was not confident and the date was proposed to bechanged to March 2020. It was kept open for discussion whether to move it to this date.
 		revised No S3‑194445  
S3‑194357 Updates to Counter Check Procedure (Rel-15) Samsung CR Approval
6.13GPP Working Groups
 		Yes
YesEricsson didn’t agree with this change. Huawei: change from shall not to "should not". Samsung insisted on an existing misalignment with RAN2. There is no benefit with having the removed the sentence according to Samsung. Qualcomm supported Samsung. Alf (NTT-Docomo): just add a note with a clarification. MCC asked if this should be cat-F and Samsung replied that it could be and that a mirror was submitted to this meeting as well. Ericsson commented that this should not be changed in Release 16, so this was taken offline.
 		revised No S3‑194449  
S3‑194358 Updates to Counter Check Procedure (Rel-16) Samsung CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		revised No S3‑194601  
S3‑194359 Security requirements for SeCoP Nokia, Nokia Shanghai Bell CR Approval
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		revised No S3‑194446  
S3‑194360 Description of CAPIF reference point: 3e,4e,5e,7 and 7e Samsung CR Approval
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (Rel-16)
 		Yes
YesTim (Motorola Solutions): we are missing CAPIF-2e's definition here. Henrik (Ericsson): CAPIF-7e is similar to CAPIF-2e in the third paragraph. These were agreed and addressed in the revision.
 		revised No S3‑194464  
S3‑194361 Authentication and authorization between SeCoP and network functions Nokia, Nokia Shanghai Bell CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		agreed No    
S3‑194362 Algorithm negotiation procedure for MC Service Samsung CR Approval
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		revised No S3‑194652  
S3‑194363 Authentication and authorization between SeCoPs Nokia, Nokia Shanghai Bell CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		agreed No    
S3‑194364 Updates to Solution #2.1 on MT functionality Samsung, Qualcomm Incorporated, Ericsson, Nokia, Nokia Shanghai Bell pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
Yes
 		approved No    
S3‑194365 Resource Level Authorization using Access Tokens Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
YesCompeting contribution in 261. Huawei:The key issue in the TR (number 29) is not concluded yet. 365, 261 were taken offline since they depended on the outcome of the key issue.
 		merged No S3‑194659  
S3‑194366 Updates and evaluation of solution #3.1 Samsung pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
YesThales, Nokia supported this. Qulacomm: no requirement to have the additional authorization check. Why is this here? Samsung: RAN2 is working on the identification of co-location and verification of the authorization part. It was agreed to remove the sentence where this was mentioned. Qualcomm had numerous comments including the evaluation as well. Both Nokia and Qualcomm had competing evaluations.
 		revised No S3‑194577  
S3‑194367 TLS between NF and SEPP based on custom HTTP header Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		revised No S3‑194518  
S3‑194368 Requirements for Secure environment of the IAB node Samsung draftCR  
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
YesEricsson, Orange: reference this clause from the annex.
 		revised No S3‑194594  
S3‑194369 IAB-node integration procedure Samsung draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
YesNokia: phases are related to the deployment. Samsung replied that this was a security sequence and not related to the deployment phase. Orange agreed that this was confusing. Nokia added that additional text should be Samsung: this is not new, this is part of definitions given in RAN. MCC commented that the last paragraph didn’t seem appropriate for a general clause since it was introducing requirements. In addition to this, it looked like a requirement was given to the attackers as well.
 		revised No S3‑194597  
S3‑194370 Mutual authentication between Network Functions Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		not pursued No    
S3‑194371 IAB-UE part set-up procedure Samsung draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		revised No S3‑194598  
S3‑194372 NF consumer authentication by the producer in direct communication scenarios Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		not pursued No    
S3‑194373 F1 interface set-up procedure Samsung draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194374 TLS entity certificate profile for SBA Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
YesHuawei: this is too early. BT: TLS profiles defined in 33.210 already? MCC added that a draftCR would be more appropriate in order to introduce content with latercontributions, given that this CR was just introducing empty clauses. Nokia commented that there was only one meeting left before the freeze of Release 16.
 		not pursued No    
S3‑194375 Solution for IAB Architecture Samsung draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
YesORANGE: Requirements for subscription credential storage are not in TS 33.401 but in a CT spec. This was taken offline.
 		revised No S3‑194599  
S3‑194376 SBA Network Function TLS certificate profile Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		not pursued No    
S3‑194377 Solution #13 Evaluation and Conclusion Samsung, Intel pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesThales: impacts on the ME-UICC interface need to be stated in the evaluation. Huawei, Ericsson didn’t agree with the conclusion. This was removed.
 		revised No S3‑194558  
S3‑194378 Update to 5G_eSBA WID Nokia, Nokia Shanghai Bell WID revised Approval
5.1Output of SA3#96-Ad hoc
Yes
YesKept open in order to discuss the dates.
 		revised No S3‑194600  
S3‑194379 New Solution to Key Issue #6.2 Samsung pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesHuawei: impact on USIM? Samsung replied that there was none. Qualcomm had concerns on the SUCI calculation procedures.
 		revised No S3‑194557  
S3‑194380 Discussion paper on authorization for Model D Indirect communications Nokia, Nokia Shanghai Bell discussion Agreement
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194381 Udpate to Solution #3 Samsung pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesHuawei didn’t agree with the new sentence in the evaluation. This was left for offline discussion. After this discussion Huawei withdrew their comments and this was approved.
 		approved No    
S3‑194382 Update to conclusion on Key issue #22: Authorization of NF service access in indirect communication Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194383 Key Issue #6.1 conclusion Samsung pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesEricsson and Huawei didn’t agree with this conclusion. Ericsson added that the CAG ID was used to prevent access attempts, so it was unclear how this could happen.There were discussions in SA2 on whether the CAG ID should be sent at all. This was left open. After discussions there was no agreement and it was noted.
 		noted No    
S3‑194384 Conclusion for Key Issues #6.1 and #6.2 Samsung pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑194385 Updated TR33.845 - includes docs agreed at SA3#95 Adhoc Vodafone Espaρa SA draft TR Agreement
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
Yes
 		approved No    
S3‑194386 CAG cell access check Samsung draftCR Approval
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
YesNokia, Huawei, Ericsson objected to this.
 		noted No    
S3‑194387 Skeleton for SEAL TS 33.434 Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
YesMotorola proposed some changes in the structure of the TS.
 		revised No S3‑194627  
S3‑194388 Scope for SEAL TS 33.434 Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
YesTim (Motorola) suggested to add more wording to extend the scope.
 		revised No S3‑194628  
S3‑194389 Adding reference, term, abbreviation to the SEAL TS 33.434 Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		revised No S3‑194629  
S3‑194390 Security requirements for SEAL Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
YesOrange: differences between the different services written here? They seem to be three different services. The VAL service is not defined. Motorola provided a few more comments that had to be taken offline.
 		revised No S3‑194631  
S3‑194391 Security for SEAL interfaces Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
YesMotorola asked to add an editor's note on additional references needed to align with the SA6 specification.The terminology also needed to be aligned with the SA6 architecture.
 		revised No S3‑194632  
S3‑194392 VAL user authentication and authorization Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
YesHuawei commented that this was quite a large content and asked to have more time to review it properly. Motorola also had numerous comments. Samsung replied that they would bring back this and the following contributions for the next meeting (addressing the comments from the companies).
 		noted No    
S3‑194393 Security procedure for S-KMC and S-KMS Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194394 Annex X: OpenID Connect Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194395 Annex Y for TS 33.434 Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194396 Conclusion to Key Issue #5 Samsung pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
Yes
 		noted No    
S3‑194397 UPGF - Align with Inter PLMN UP Security Function (IPUPS) Nokia, Nokia Shanghai Bell draftCR Approval
7.17User Plane Gateway Function for Inter-PLMN Security (Rel-16)
 		Yes
YesHuawei, Juniper: bring back the first sentence. Docomo: don’t change the acronym. This was finally noted.
 		noted No    
S3‑194398 Requirements for KI#18 The Startup Paradox Ericsson pCR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194587  
S3‑194399 Source IP address range check for UPGF Nokia, Nokia Shanghai Bell draftCR Approval
7.17User Plane Gateway Function for Inter-PLMN Security (Rel-16)
 		Yes
YesJuniper networks: remove "that intercepts outgoing GTP-U traffic originated from a UPF". Ericsson added that in fact the whole paragraph was not needed. Docomo: which source address are you referring to? This was taken offline.
 		revised No S3‑194463  
S3‑194400 Removing ENs in annex X in the living document for 5WWC CableLabs, Charter Communications,Lenovo, Motorola Mobility, EricssonRogers Communications, Nokia, Nokia Shanghai Bell, CR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
YesOrange: hard to understand what's new and what's existent. CableLabs: red text is new. Blue text is existent.
 		not pursued No   S3‑194030
S3‑194401 NPN clarifications Nokia, Nokia Shanghai Bell,Qualcomm CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
YesVodafone: the change in I.2.1 makes it too broad. Other groups have misinterpreted our specification for this reason. The Chair commented that this was heavily discussed in the previous meeting. Nokia added that this referred to clauses I.2.2 and I.2.3. Qualcomm added that this was not normative but an introduction to other clauses. Vodafone withdrew their comment.
 		agreed No    
S3‑194402 Removal of ed.note on conformance tests Nokia, Nokia Shanghai Bell,Qualcomm CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		agreed No    
S3‑194403 CAG ID privacy conclusion Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesInterdigital: wait for SA2's conclusions. Sebastian (Qualcomm): no need to wait, SA3 can work on this and give their view on CAG ID privacy. Futurewei commented that it just has to be protected and that's the view. The Chair asked if SA3 could agree on their view on CAG ID privacy and send it to other groups. Interdigital: this is solution-specific. This was left for offline discussions in order to agree on a common view that could be sent to SA2. Samsung thought that it was too early and they needed to wait for SA2. Interdigital supported this. Qualcomm, Ericsson supported going for the study now.
 		revised No S3‑194693  
S3‑194404 CAG ID privacy Nokia, Nokia Shanghai Bell CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		not pursued No    
S3‑194405 Annex 5GLAN Nokia, Nokia Shanghai Bell CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		revised No S3‑194428  
S3‑194406 Annex TSC security intro Nokia, Nokia Shanghai Bell CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		agreed No    
S3‑194407 TSC gPTP message protection Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		revised No S3‑194423  
S3‑194408 TSC conclusion Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		revised No S3‑194422  
S3‑194409 Authentication of a TSC enabled UE Nokia, Nokia Shanghai Bell CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
YesQualcomm: "specified in this document". We refer to requirements that are all over the document. Orange: specify clause 6.1. This had to be taken offline. Editorial corrections. MCC commented: Just "UE" and not "5GS UE".
 		revised No S3‑194550  
S3‑194410 UP security in TSC Nokia, Nokia Shanghai Bell CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		revised No S3‑194424  
S3‑194411 UDR study - title correction Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
YesIt was clarified that the WID title was reworded before being sent to SA, although the spec title wasn’t aligned yet.
 		revised No S3‑194669  
S3‑194412 UDR study - intro Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
Yes
 		revised No S3‑194670  
S3‑194413 Privacy solution for groupcast Nokia, Nokia Shanghai Bell pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesHuawei didn’t agree with the solution, as this was against SA2's work on the creation and management of the group.
 		noted No    
S3‑194414 Evaluation to privacy solution for groupcast Nokia, Nokia Shanghai Bell pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		noted No    
S3‑194415 Discussion of New Study - eNPN Vertical_LAN_SEC Nokia, Nokia Shanghai Bell discussion Endorsement
8.16New study item proposals
 		Yes
YesNokia asked if Vertical LAN should continue as it is,with eNPN topics. Huawei preferred to split the topic as in SA2. Ericsson shared the same view. ORANGE commented that ojectives should not be key issues in SA2 so as not to have the same discussions as in SA2.
 		noted No    
S3‑194416 Enhanced NPN Security for Vertical and LAN Services.doc Nokia, Nokia Shanghai Bell SID new Agreement
8.16New study item proposals
 		Yes
Yes
 		noted No    
S3‑194417 [Draft CR]Solution for IAB Architecture (Baseline version) Samsung draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		revised No S3‑194596  
S3‑194418 Comment on S3-194061 Huawei, HiSilicon other  
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194419 Clarification on aspects specific to the network product class UDM and AMF Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194179
S3‑194420 Comments on S3-194315 HUAWEI TECHNOLOGIES Co. Ltd. discussion Discussion
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		noted No    
S3‑194421 living CR of URLLC Huawei, Hisilicon draftCR  
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
Yes
 		revised No S3‑194467  
S3‑194422 TSC conclusion Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesEricsson: lot of text that seems normative. SA3 should make a recommendation rather than specifying with "shalls". Sentences were reworded to remove the "shalls". Revised to address some Huawei's comments as well.
 		revised No S3‑194552 S3‑194408
S3‑194423 TSC gPTP message protection Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑194407
S3‑194424 UP security in TSC Nokia, Nokia Shanghai Bell CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		revised No S3‑194553 S3‑194410
S3‑194425 Update on solution#15 in TR 33.855 Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		revised No S3‑194509 S3‑194183
S3‑194426 Forwarding of Reply LS on GUTI allocation for 5G CIoT C1-198560 LS in  
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194427 Security for TSC service Nokia, Nokia Shanghai Bell discussion Information
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		noted No    
S3‑194428 Annex 5GLAN Nokia, Nokia Shanghai Bell CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		agreed No   S3‑194405
S3‑194429 Commenting on S3-194222 Nokia Germany pCR  
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		merged No S3‑194555  
S3‑194430 Commenting contribution on S3-194261 – Resource Level Authorization using Access Tokens Nokia, Nokia Shanghai Bell discussion Information
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194431 Nokia comments on S3-193970 PMF protocol security Nokia, Nokia Shanghai Bell discussion Discussion
6.13GPP Working Groups
 		Yes
YesApple: Nokia agrees on the attack and sees no standardization needed? We disagree. Lenovo supported the Apple contribution. Futurewei: application impacting on the UE is out of standardization scope as we concluded in the IoT work item. Qualcomm: no UP integrity protection in LTE. We don’t see the need for new security mechanisms, existing ones are sufficient. ZTE supported this. There was no consensus on the need for sending a reply LS.
 		noted No    
S3‑194432 Comments to S3-194019 DTR 33.848, Key Issue #19 Clauses 5.20.2 and 5.20.3 Ericsson pCR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		revised No S3‑194588  
S3‑194433 Reply LS on how the IWF obtains key material for interworking group and private communications S6-192194 LS in discussion
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		postponed No    
S3‑194434 LS on Application Architecture for enabling Edge Applications S6-192399 LS in discussion
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑194435 LS on native 5G NAS security context activation C1-199003 LS in discussion
6.13GPP Working Groups
 		Yes
YesQualcomm: leave it to the AMF to decide.Stick to the top highlighted text. Huawei: Our assumption is to use the native security context as much as possible. It was commented that CT1 was meeting after SA3's next meeting, so it was decided to postpone an answer.
 		postponed No    
S3‑194436 LS on GUTI allocation for MT-EDT in 5G CIoT C1-199005 LS in discussion
6.13GPP Working Groups
 		Yes
YesHuawei: we need to discuss this offline, as it implies that MT-EDT might not be needed at all. Qualcomm: how to allocate the GUTI is not in our scope. The utility of this feature is up to other working groups, not to us. Ericsson: we have studied this and we think that the re-allocation is not needed. This had to be taken offline.
 		noted No    
S3‑194437 LS on Use of 3gpp-Sbi-Target-apiRoot header in HTTP requests from NFs to SEPP C4-195375 LS in discussion
6.13GPP Working Groups
 		Yes
YesThis needed some offline discussion.
 		replied to No    
S3‑194438 Reply LS on GTP Recovery Counter & GSN node behaviour C4-195518 LS in discussion
6.13GPP Working Groups
 		Yes
YesNo action for SA3.
 		noted No    
S3‑194439 LS on ARPF in UDICOM C4-195553 LS in discussion
6.13GPP Working Groups
 		Yes
Yes
 		postponed No    
S3‑194440 LS on usage of IMSI during 3GPP based authentication C4-195574 LS in discussion
6.13GPP Working Groups
 		Yes
YesLenovo: we think that nothing needs to be done for this scenario. Qualcomm: Blackberry brought a CR for our previous meeting related to this. SUPI privacy can be compromised, but it's up to the implementers to decide if this can happen, and it should not be specified in our standards. Nokia: this is a mix of 4G and 5G. We should reply because CT4 has a CR pending.
 		replied to No    
S3‑194441 LS on user identity when 5G-AKA or EAP AKA’ is used for SNPN C6-190468 LS in discussion
6.13GPP Working Groups
 		Yes
Yes
 		replied to No    
S3‑194442 Agenda WG Chairman agenda -
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No   S3‑193900
S3‑194443 Security requirements for UP Gateway Function Nokia, Nokia Shanghai Bell, Juniper CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		agreed No   S3‑194352
S3‑194444 Protection of N9 interface Nokia, Nokia Shanghai Bell, Juniper Networks CR Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		agreed No   S3‑194355
S3‑194445 New WID for User Plane Gateway Function for the Inter-PLMN Security Juniper Networks WID new Agreement
5.1Output of SA3#96-Ad hoc
Yes
Yes
 		agreed No   S3‑194356
S3‑194446 Security requirements for SeCoP Nokia, Nokia Shanghai Bell CR Approval
5.1Output of SA3#96-Ad hoc
Yes
YesAgreed baseline but Ericsson proposed new changes for a revision.
 		agreed No   S3‑194359
S3‑194447 Reply LS_on_CHO key derivation Apple LS out Approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No   S3‑193966
S3‑194448 33501-CR on CHO key derivation Apple CR Approval
6.13GPP Working Groups
 		Yes
YesPostponed in order to add more details: Key derivation in CHO needs to be addressed in the specification.
 		not pursued No   S3‑193969
S3‑194449 Updates to Counter Check Procedure (Rel-15) Samsung CR Approval
6.13GPP Working Groups
 		Yes
YesMirror in 358.
 		agreed No   S3‑194357
S3‑194450 LS reply to RAN WG3 LS on security for multi-CU-UP connectivity CATT LS out Approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No   S3‑194139
S3‑194451 Reply to: LS on security consideration of performance measurement function protocol ZTE LS out approval
6.13GPP Working Groups
 		Yes
YesNo consensus. Apple asked to have in the minutes: "Apple strongly insists that the current security existing mechanism is NOT sufficient to address the security issue that 3rd part application could modify the PMF packet."
 		noted No    
S3‑194452 Reply LS on UP gateway function on the N9 interface Juniper Networks LS out -
6.13GPP Working Groups
 		Yes
Yes
 		approved No   S3‑193989
S3‑194453 Reply to: LS on Use of 3gpp-Sbi-Target-apiRoot header in HTTP requests from NFs to SEPP Nokia LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑194454 Reply to: LS on usage of IMSI during 3GPP based authentication Nokia LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑194455 Reply to: LS on user identity when 5G-AKA or EAP AKA’ is used for SNPN Samsung LS out approval
6.13GPP Working Groups
 		Yes
YesDisagreement on the statement that if NSI is being present in the USIM, the IMSI stored in the USIM can be used by the ME to derive the NSI.Samsung, IDEMIA in favour, Orange and Qualcomm against. Qualcomm: The disagreement lies in two SUPIs in the same USIM. SA2 has no use case for this.
 		approved No    
S3‑194456 Reply to: 256 bit radio interface algorithm performance Ericsson LS out Approval
6.3ETSI SAGE
 		Yes
Yes
 		approved No   S3‑194288
S3‑194457 Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility Intel CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		agreed No    
S3‑194458 Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility Intel Corporation (UK) Ltd CR -
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
YesQualcomm wanted to add in the cover sheet that it is not a change of behaviour of the ME but for alignment.
 		agreed No   S3‑194076
S3‑194459 Adding TSC abbreviation Nokia CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194460 Idle mode mobility from EPS to 5GS Ericsson CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		not pursued No   S3‑194295
S3‑194461 Idle mode mobility from EPS to 5GS Ericsson CR Agreement
7.1Security aspects of 5G System - Phase 1 (Rel-15)
No
Yes
 		withdrawn Yes    
S3‑194462 Add Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
No
Yes
 		withdrawn Yes    
S3‑194463 Source IP address range check for UPGF Nokia, Nokia Shanghai Bell draftCR Approval
7.17User Plane Gateway Function for Inter-PLMN Security (Rel-16)
 		No
Yes
 		merged No S3‑194443 S3‑194399
S3‑194464 Description of CAPIF reference point: 3e,4e,5e,7 and 7e Samsung CR Approval
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194360
S3‑194465 Draft CR as a living baseline for 5GS LCS normative work CATT draftCR Approval
7.8Security of the enhancement to the 5GC location services
 		Yes
Yes
 		approved No   S3‑194150
S3‑194466 Resolving ENs in Draft CR as a living baseline for 5GS LCS normative work Ericsson,Huawei,CATT draftCR Approval
7.8Security of the enhancement to the 5GC location services
 		Yes
Yes
 		approved No   S3‑194271
S3‑194467 living CR of URLLC Huawei, Hisilicon draftCR -
7.6Security of URLLC for 5GS (Rel-16)
 		No
Yes
 		left for email approval No   S3‑194421
S3‑194468 New WID on eV2X security LG Electronics Inc. WID new Approval
7.20New work item proposals
 		Yes
YesORANGE: the requirements in TR 33.836 are potential, don’t refer to this TR and stick to the TS as a base. Editorial comments from MCC.
 		agreed No   S3‑193979
S3‑194469 Clean up Huawei, Hisilicon draftCR Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
Yes
 		approved No   S3‑194125
S3‑194470 Resolve EN about how to ensure the UP security policy to be the same Ericsson,Huawei draftCR Approval
7.6Security of URLLC for 5GS (Rel-16)
 		Yes
Yes
 		approved No   S3‑194225
S3‑194471 New SID on the security of the system enablers for devices having multiple Universal Subscriber Identity Modules (USIM) Intel Corporation (UK) Ltd SID new -
8.16New study item proposals
 		Yes
YesORANGE: objectives are not clear. SA2 has just started and it's not clear either what SA3 has to do.Better to wait for SA2 to see if they have any specific security issues that we need to address with a study. Qualcomm supported this. Thales: SA2 SID has two USIMs (5GS and EPS) but the scope of the SID in SA3 is different.. Intel replied that this was aligned with the scenarios described in SA1. Ericsson: let us be careful as SA2 might advance some security work if we wait for too long. Alex (BT): SA plenary has prohibited the multi-operator scenario.
 		noted No   S3‑194078
S3‑194472 URLLC living CR: clarifications related to security policy Nokia, Nokia Shanghai Bell,Huawei,Ericsson other Approval
7.6Security of URLLC for 5GS (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑194473 33.511 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194342
S3‑194474 Update test cases for gNB SCAS Huawei, Hisilicon CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesRevised to address an editorial change: removal of automatic bullet lists.
 		agreed No   S3‑194223
S3‑194475 33.512 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell,Huawei CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194343
S3‑194476 33.513 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell,Huawei CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194344
S3‑194477 33.515 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell,Futurewei CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194347
S3‑194478 33.517 Adding abbreviations and corrections for alignment Nokia, Nokia Shanghai Bell CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
YesBringing back the removed editor's note.
 		agreed No   S3‑194349
S3‑194479 33.519 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell,ZTE CR Approval
7.2Security Assurance Specification for 5G (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194351
S3‑194480 33.216 Corrections for clean-up and alignment R15 Nokia, Nokia Shanghai Bell CR Approval
7.19.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑194299
S3‑194481 33.216 Corrections for clean-up and alignment R16 Nokia, Nokia Shanghai Bell CR Approval
7.19.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑194300
S3‑194482 Reply to: Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC Huawei LS out approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194483 DraftCR – Living document for supporting 5G CIoT security Ericsson draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		No
Yes
 		left for email approval No   S3‑194242
S3‑194484 [Draft CR] RRC Connection Re-Establishment for the control plane for NB-IoT radio access connected to 5GC Ericsson,Huawei other Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		approved No   S3‑194236
S3‑194485 General for Security handling in User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
Yes
 		approved No   S3‑194103
S3‑194486 Security handling in Connection Suspend Procedure for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesRevised to address Ericsson's comments.
 		approved No   S3‑194104
S3‑194487 Security handling in Connection Resume in CM-IDLE with Suspend to a new ng-eNB for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval
7.11Evolution of Cellular IoT security for the 5G System (Rel-16)
 		Yes
YesAddressing Ericsson's comments. Disagreement on linking this to the results of the false base station topic.Huawei didn’t want to do any link but Ericsson claimed that there was relation with the message parameters exposed here (fro "source C-NRTI..to the end of Note 1).
 		approved No   S3‑194105
S3‑194488 Reply LS on Handling of UE radio network capabilities in 4G and 5G Intel Corporation (UK) Ltd LS out -
7.19.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		approved No   S3‑194075
S3‑194489 draft TR 33.861 Ericsson draft TR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		No
YesThe Chair asked if this could be sent for approval. Ericsson replied that only one key issue was left and it would be ready for the next meeting.
 		left for email approval No    
S3‑194490 KI 14 Potential Security Requirement NIST, ATT, Sprint Corporation, CableLabs, Deutsche Telekom AG, Cisco pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesReivsed to re-formulate the security requirement.
 		approved No   S3‑193991
S3‑194491 Updates to Key issue Protection of UE capability transfer for UEs without AS security Intel Corporation (UK) Ltd,Qualcomm,Huawei,Ericsson pCR -
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No   S3‑194080
S3‑194492 New Solution for KI #14 NIST, ATT, Sprint, CableLabs, Deutsche Telekom AG, Cisco pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No   S3‑193992
S3‑194493 Protection of UE capability transfer for CP optimization only CIoT UE Huawei, Hisilicon pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No   S3‑194088
S3‑194494 Security solution for UE Capability Transfer for UE with no AS security. Intel Corporation (UK) Ltd pCR -
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
YesRemoving steps 1-3. Editor's note on the new call flow RAN- core network. Evaluation was removed as proposed by Qualcomm.
 		approved No   S3‑194079
S3‑194495 AMF verification of the UE radio capabilities for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No   S3‑194325
S3‑194496 KI#15 - new solution for handling UEs without AS security Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		No
Yes
 		withdrawn Yes    
S3‑194497 Hash based UE capability protection for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No   S3‑194326
S3‑194498 Proposed conclusion to KI#1 Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No   S3‑194235
S3‑194499 Consistent use of off-network Motorola Solutions UK Ltd. CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No   S3‑193996
S3‑194500 [33.180] R16 - TrK ID and InK ID Motorola Solutions UK Ltd. CR Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No   S3‑193998
S3‑194501 LS to CT1 on 3rd ETSI MCX Remote Plugtest Motorola Solutions UK Ltd. LS out Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		revised No S3‑194611 S3‑194001
S3‑194502 Minutes of the Mission Critical offline session Qualcomm report Information
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194503 Notes from the eSBA break out session NTT-Docomo report Information
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No    
S3‑194504 Update to conclusion on Key issue #23: NF to NF authentication and authorization in Indirect communication Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		No
Yes
 		withdrawn Yes    
S3‑194505 Security requirement on Key Issue #24: service access authorization of a NF Set Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		approved No   S3‑194194
S3‑194506 Evaluation on service access authorization of a NF Set in non-roaming scenario Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		approved No   S3‑194192
S3‑194507 Evaluation on service access authorization of a NF Set in roaming scenario Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		approved No   S3‑194193
S3‑194508 Conclusion on service access authorization of a NF Set Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		approved No   S3‑194186
S3‑194509 Update on solution#15 in TR 33.855 Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		approved No   S3‑194425
S3‑194510 New KI: Service access authorization for non-delegated subscribe-notify Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		approved No   S3‑194165
S3‑194511 New solution for authorization in the non-delegated "Subscribe-Notify" interaction scenarios Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		approved No   S3‑194182
S3‑194512 eSBA: conclusion update on KI #29 Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No   S3‑194168
S3‑194513 New Key issue on NF subtypes for authorization granularity Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No   S3‑194258
S3‑194514 Conclusion for Key Issue #5 "NF-NF Authorization" Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		noted No   S3‑194254
S3‑194515 Removal of Editor's Notes for Security of indirect communication in roaming scenarios Ericsson pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		Yes
Yes
 		approved No   S3‑194257
S3‑194516 Draft TR 33.855 Ericsson draft TR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture
 		No
Yes
 		left for email approval No    
S3‑194517 Editorials and corrections to Security requirements for SeCoP Ericsson draftCR Approval
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		approved No   S3‑194250
S3‑194518 TLS between NF and SEPP based on custom HTTP header Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194367
S3‑194519 Security for roaming interfaces in indirect communication Ericsson,Nokia CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194256
S3‑194520 Mutual authentication between Network Functions Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑194521 NF consumer authentication by the producer in direct communication scenarios Nokia, Nokia Shanghai Bell CR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑194522 Using Rel-15 token-based authorization in indirect communication scenarios Ericsson draftCR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		No
Yes
 		left for email approval No    
S3‑194523 Service access authorization of a NF Set Huawei, Hisilicon CR Approval
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑194524 SBA Network Function TLS certificate profile Nokia, Nokia Shanghai Bell draftCR Approval
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		Yes
YesThis draftCR will be used as a baseline for discussions and it will be brought back next meeting.
 		noted No    
S3‑194525 New WID on Security Aspects of PARLOS SPRINT Corporation WID new Agreement
7.20New work item proposals
 		Yes
Yes
 		agreed No   S3‑193913
S3‑194526 Skeleton for TS on eV2X LG Electronics Inc. other Approval
7.20New work item proposals
 		Yes
Yes
 		approved No   S3‑193982
S3‑194527 New WID: Work Item on Security Assurance Specification for IMS Huawei, Hisilicon WID new Approval
7.20New work item proposals
 		Yes
Yes
 		agreed No   S3‑194180
S3‑194528 New WID on 3GPP profiles for cryptographic algorithms and IETF protocols Ericsson WID new Agreement
7.20New work item proposals
 		Yes
Yes
 		agreed No   S3‑194269
S3‑194529 Living doc for 5WWC Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		No
Yes
 		left for email approval No   S3‑194126
S3‑194530 Introducing missing definitions of untrusted and trusted non-3GPP accesses Ericsson draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No   S3‑194286
S3‑194531 Determining trust relationship in the UE Ericsson draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No   S3‑194287
S3‑194532 Editorial change for trusted non-3GPP access Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No   S3‑194113
S3‑194533 Update content for trusted non-3GPP access Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No   S3‑194114
S3‑194534 256 bit algorithm candidates ETIS SAGE LS in discussion
6.3ETSI SAGE
 		Yes
Yes
 		postponed No    
S3‑194535 Reply to: Reply LS on AUSF role in slice specific authentication Ericsson LS out approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
YesNokia objected, as Telecom Italia, Orange. Ericsson, HP , Huawei, Interdigital supported this LS.
 		noted No    
S3‑194536 Add content to Clause X.X.2 of eNS Huawei, HiSilicon,Nokia,Ericsson, Interdigital draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		approved No   S3‑194045
S3‑194537 DraftCR – Proposed call flow for Network Slice Specific Authentication and Authorization Ericsson,Huawei draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		approved No   S3‑194212
S3‑194538 Note for the User ID privacy protection in Clause X.X.3 Huawei, HiSilicon draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		approved No   S3‑194047
S3‑194539 DraftCR - Proposed flow for Re-authentication and Re-authorization Ericsson draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		approved No   S3‑194213
S3‑194540 DraftCR – Proposing a new AUSF service to support NSSAA flow Ericsson draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		Yes
Yes
 		approved No   S3‑194215
S3‑194541 Living document on slice specific authentication procedures Nokia draftCR Approval
7.13Security aspects of Enhancement of Network Slicing (Rel-16)
 		No
Yes
 		left for email approval No    
S3‑194542 Solution 8 update Huawei, HiSilicon pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No   S3‑194051
S3‑194543 Draft TR 33.813 Nokia draft TR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		No
Yes
 		left for email approval No    
S3‑194544 Clarifications to solution #10 on protecting S-NSSAIs Qualcomm Incorporated pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesAdding the editor's note.
 		approved No   S3‑194317
S3‑194545 Update to the evaluation of solution #10 on protecting S-NSSAIs Qualcomm Incorporated pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesBringing back the editor's note.
 		approved No   S3‑194318
S3‑194546 TR 33.813 - update for the evaluation for solution #11 InterDigital Communications pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No   S3‑193911
S3‑194547 Update of solution #12 in TR 33.813 ZTE Corporation pCR Approval
8.5Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesIt brings back the last editor's note.
 		approved No   S3‑194068
S3‑194548 Reply LS on SUCI computation from an NSI Qualcomm Incorporated LS out Approval
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		approved No   S3‑194335
S3‑194549 Removing editor's note on capturing all the details for alternative authentication methods Qualcomm Incorporated CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194319
S3‑194550 Access security for a TSC-enabled UE Nokia, Nokia Shanghai Bell CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194409
S3‑194551 Draft TR 33.819 Nokia draft TR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		No
Yes
 		left for email approval No    
S3‑194552 TSC conclusion Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑194422
S3‑194553 UP security in TSC Nokia, Nokia Shanghai Bell,Huawei CR Agreement
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194424
S3‑194554 Reply LS on Sending CAG ID in NAS layer R3-197591 LS in discussion
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesNokia: we should add in the conclusion clause that for the broadcast part CAG ID privacy will not be considered given the complexity of the possible solutions. Ericsson commented that there was no need to send the CAG ID in the NAS layer as RAN3 had concluded.Qualcomm added that only if it went through the NAS it would be protected.
 		replied to No    
S3‑194555 New conclusion for handling UP security policy in a 5GLAN group Ericsson,Nokia pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑194222
S3‑194556 Udpate to Solution #3 Samsung pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		No
Yes
 		withdrawn Yes    
S3‑194557 New Solution to Key Issue #6.2 Samsung pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑194379
S3‑194558 Solution #13 Evaluation and Conclusion Samsung, Intel pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑194377
S3‑194559 Reply to: Reply LS on Sending CAG ID in NAS layer Qualcomm LS out approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No    
S3‑194560 Notes on the security impacts on the virtualization offline session NTT-Docomo report Information
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		noted No    
S3‑194561 Corrections on clause 4.3 Huawei, Hisilicon pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		approved No   S3‑194136
S3‑194562 remove unspecified SDOs Huawei, Hisilicon pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		approved No   S3‑194162
S3‑194563 Clarifying interfaces in clause 5.2.3.3.4 and clause 5.2.3.4.5 China Mobile,Nokia pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		approved No   S3‑194141
S3‑194564 Adding security requirements for GVNP of type 1 China Mobile pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		approved No   S3‑194145
S3‑194565 Adding security functional requirements deriving virtualisation and related test cases for GVNP of type 1 China Mobile pCR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		No
Yes
 		withdrawn Yes    
S3‑194566 Draft TR 33.824 Samsung draft TR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		No
Yes
 		left for email approval No    
S3‑194567 LS on SECAM Accreditation for Virtualised Network Products (VNPs) Nokia, Nokia Shanghai Bell, China Mobile LS out Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		Yes
Yes
 		approved No   S3‑194232
S3‑194568 DTR 33848 KI1 – clause 5_2_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194002
S3‑194569 DTR 33848 KI2 – clause 5_3_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
YesChina Mobile asked to be minuted :The requirement is not complete.
 		approved No   S3‑194003
S3‑194570 DTR 33848 KI3 – clause 5_4_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194004
S3‑194571 DTR 33848 KI4 – clause 5_5_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		noted No   S3‑194005
S3‑194572 DTR 33848 KI5 – clause 5_6_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194006
S3‑194573 DTR 33848 KI6 – clause 5_7_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194007
S3‑194574 DTR 33848 KI7 – clause 5_8_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194008
S3‑194575 DTR 33848 KI8 – clause 5_9_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194009
S3‑194576 DTR 33848 KI9 – clause 5_10_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194010
S3‑194577 Updates and evaluation of solution #3.1 Samsung pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
Yes
 		approved No   S3‑194366
S3‑194578 DTR 33848 KI11 – clause 5_12_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194011
S3‑194579 DTR 33848 KI12 – clause 5_13_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194012
S3‑194580 DTR 33848 KI13 – clause 5_14_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194013
S3‑194581 DTR 33848 KI14 – clause 5_15_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194014
S3‑194582 TR 33.848 Solution – lock-down of infrastructure NCSC pCR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
YesThales: do we need to point out what is in scope of ETSI NFV? MCC warned that this was an internal 3GPP specification and could not be shared with external to 3GPP groups. Alex (BT) argued that this was a public document and ETSI being an organizational partner wasn't an impediment to share the specification. MCC commented that this wasn’t enough and that the spec should be changed to a 900 series specification in order to be officially sent to ETSI NFV. This was to be discussed further offline.
 		approved No   S3‑194353
S3‑194583 TR 33.848 Solution – trust domains and separation NCSC pCR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194354
S3‑194584 DTR 33848 KI15 – clause 5_16_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194015
S3‑194585 DTR 33848 KI16 – clause 5_17_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194016
S3‑194586 Evaluation on Solution #4.2 Qualcomm Incorporated, Ericsson pCR Approval
8.12Study on Security for NR Integrated Access and Backhaul
 		Yes
Yes
 		approved No   S3‑194332
S3‑194587 Requirements for KI#18 The Startup Paradox Ericsson pCR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194398
S3‑194588 Comments to S3-194019 DTR 33.848, Key Issue #19 Clauses 5.20.2 and 5.20.3 Ericsson,T-Mobile pCR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194432
S3‑194589 DTR 33848 KI20 – clause 5_21_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194020
S3‑194590 DTR 33848 KI21 – clause 5_22_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194021
S3‑194591 DTR 33848 KI22 – clause 5_23_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194022
S3‑194592 DTR 33848 KI23 – clause 5_24_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194023
S3‑194593 DTR 33848 KI24 – clause 5_25_3 T-Mobile USA Inc. other Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No   S3‑194024
S3‑194594 Requirements for Secure environment of the IAB node Samsung draftCR -
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		approved No   S3‑194368
S3‑194595 [Draft CR] Security requirements on the IAB node, IAB donor and 5GC supporting IAB architecture Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		approved No   S3‑194275
S3‑194596 [Draft CR]Solution for IAB Architecture (Baseline version) Samsung draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		No
Yes
 		left for email approval No   S3‑194417
S3‑194597 IAB-node integration procedure Samsung,Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		approved No   S3‑194369
S3‑194598 IAB-UE part set-up procedure Samsung,Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		approved No   S3‑194371
S3‑194599 Solution for IAB Architecture Samsung .Ericsson draftCR Approval
7.14Security for NR Integrated Access and Backhaul (Rel-16)
 		Yes
Yes
 		approved No   S3‑194375
S3‑194600 Update to 5G_eSBA WID Nokia, Nokia Shanghai Bell WID revised Approval
5.1Output of SA3#96-Ad hoc
Yes
YesChanged to March 2020.
 		agreed No   S3‑194378
S3‑194601 Updates to Counter Check Procedure (Rel-16) Samsung CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		agreed No   S3‑194358
S3‑194602 33401-CR on CHO key derivation Apple CR Approval
7.19.1SAE/LTE Security
 		Yes
Yes
 		not pursued No   S3‑193968
S3‑194603 Reply to: LS on IANA assigned values for mission critical Motorola Solutions LS out approval
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194604 Proposed conclusion to KI #14 Ericsson pCR Approval
8.3Study on Evolution of Cellular IoT security for the 5G System
 		Yes
Yes
 		approved No   S3‑194246
S3‑194605 Notes on the V2X offline session NTT-Docomo report Information
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		Yes
Yes
 		noted No    
S3‑194606 Trusted access key hierarchy Ericsson draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No   S3‑194284
S3‑194607 Trusted access key derivation Ericsson draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No   S3‑194285
S3‑194608 Corrections on N5CW connects 5GC via trusted non-3GPP access Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑194609 Move Requirement of 5G-RG to clause 5 Huawei, Hisilicon draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
Yes
 		approved No   S3‑194117
S3‑194610 Removing ENs in annex X in the living document for 5WWC CableLabs, Charter Communications,Lenovo, Motorola Mobility, EricssonRogers Communications, Nokia, Nokia Shanghai Bell, draftCR Approval
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		Yes
YesRevised to show better the changes with the revision marks.
 		approved No    
S3‑194611 LS to CT1 on 3rd ETSI MCX Remote Plugtest Motorola Solutions UK Ltd. LS out Agreement
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		approved No   S3‑194501
S3‑194612 Draft TR 33.818 China Mobile draft TR Approval
8.6Study on SECAM and SCAS for 3GPP virtualized network products
 		No
Yes
 		left for email approval No    
S3‑194613 Proposed inclusion of groupcast and broadcast privacy solutions Qualcomm Incorporated, LG Electronics,Ericsson other Approval
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		Yes
Yes
 		approved No   S3‑194314
S3‑194614 Proposed text for the early clauses for V2X TS Qualcomm Incorporated, LG Electronics other Approval
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑194615 Proposed text for security for V2X over Uu reference point clause Qualcomm Incorporated, LG Electronics,Ericsson other Approval
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		Yes
Yes
 		approved No   S3‑194313
S3‑194616 33.836 – update of evaluation for the Solution #1 InterDigital Communications pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑193960
S3‑194617 TR 33.836 – update of evaluation for the solution #4 InterDigital Communications pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		No
Yes
 		withdrawn Yes    
S3‑194618 Proposed conclusion for Key Issue #1 on Unicast privacy Qualcomm Incorporated,Interdigital pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194309
S3‑194619 Updates to solution 9 Intel Corporation (UK) Ltd pCR -
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194081
S3‑194620 TR 33.836 – update of evaluation for the solution #2 InterDigital Communications pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑193959
S3‑194621 Resolving the Editor’s note on privacy in the evaluation of solution #8 Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		No
Yes
 		withdrawn Yes    
S3‑194622 Proposal of an evaluation of solution #12 on protecting the traffic at the PDCP layer Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		No
Yes
 		withdrawn Yes    
S3‑194623 Adding the provisioning of security policy to solution #16 Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194302
S3‑194624 Draft TR 33.848 BT draft TR Approval
8.10Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No    
S3‑194625 Draft TS 33.xyz on V2X Lge other Approval
7.16Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)
 		No
Yes
 		left for email approval No    
S3‑194626 Draft TR 33.836 Lge draft TR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		No
Yes
 		left for email approval No    
S3‑194627 Skeleton for SEAL TS 33.434 Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		approved No   S3‑194387
S3‑194628 Scope for SEAL TS 33.434 Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		approved No   S3‑194388
S3‑194629 Adding reference, term, abbreviation to the SEAL TS 33.434 Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		approved No   S3‑194389
S3‑194630 Draft TR 33.434 Samsung draft TS Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		approved No    
S3‑194631 Security requirements for SEAL Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		approved No   S3‑194390
S3‑194632 Security for SEAL interfaces Samsung pCR Approval
7.15Security aspects of SEAL (Rel-16)
 		Yes
Yes
 		approved No   S3‑194391
S3‑194633 Security aspects of RLOS Qualcomm Incorporated CR Agreement
7.18Provision of Access to Restricted Local Operator Services by Unauthenticated UEs – Security Aspects (Rel-16)
 		Yes
YesThe last sentence on the whitelist had to be discussed internally in MCC. If necessary, it would be modified in the next SA plenary directly.
 		agreed No   S3‑194337
S3‑194634 Draft TR 33.935 Vodafone draft TR Approval
8.8Study on LTKUP Detailed solutions
 		Yes
Yes
 		approved No    
S3‑194635 Draft TR 33.835 China Mobile draft TR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		No
Yes
 		left for email approval No    
S3‑194636 Conclusion on end to end security China Mobile, KPN pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
Yes
 		approved No   S3‑194209
S3‑194637 Conclusions on Key Management Ericsson pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
Yes
 		approved No   S3‑194273
S3‑194638 Editoral changes on solution for AKMA change Huawei, Hisilicon pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
Yes
 		approved No   S3‑194170
S3‑194639 AKMA: add conclusion on KI #17 Huawei, Hisilicon pCR Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		No
Yes
 		withdrawn Yes    
S3‑194640 Draft TS 33.535 China Mobile draft TS Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		No
Yes
 		left for email approval No    
S3‑194641 Add AAnF description into clause 4.2 China Mobile, Nokia, Nokia Shanghai Bel, Huaweil pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No   S3‑194200
S3‑194642 AKMA interface description Huawei, Hisilicon pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No   S3‑194128
S3‑194643 Add content to clause 4.4 China Mobile, Nokia, Nokia Shanghai Bell,Huawei pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No   S3‑194201
S3‑194644 AKMA key management Huawei, Hisilicon pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No   S3‑194130
S3‑194645 Clause 6.X – Deriving AKMA key during UE registration Nokia, Nokia Shanghai Bell, China Mobile pCR Approval
7.10Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)
 		Yes
Yes
 		approved No   S3‑194228
S3‑194646 Proposal of an evaluation of solution #16 on the activation of user plane security in NR PC5 unicast Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194307
S3‑194647 Resolving the EN and adding the evaluation of solution #17 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesAdded a statement on the solution being suitable for apps when the operators know the keys. Addressing Privacy issues with GUTI aspects. First paragraph removed and last paragraph reworded.
 		approved No   S3‑194173
S3‑194648 eV2X: Solution for the UP security activation policy handling in NR PC5 unicast Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194175
S3‑194649 Protection of IEs in Direct Communication Request message Qualcomm Incorporated pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194304
S3‑194650 Proposal conclusion for key issue #2 on security for eV2X unicast messages over PC5 Qualcomm Incorporated,Interdigital,Huawei pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194308
S3‑194651 Solution#14 Evaluation Lenovo, Motorola Mobility pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194149
S3‑194652 Algorithm negotiation procedure for MC Service Samsung,Motorola Solutions CR Approval
7.3eMCSec R16 security (Rel-16)
 		Yes
Yes
 		agreed No   S3‑194362
S3‑194653 New Solution for secure identifier conversion in groupcast Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194041
S3‑194654 Providing analysis to Solution #13 in TR 33.836 Huawei, Hisilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑194097
S3‑194655 LS on minimizing the impact of privacy protection mechanisms in the application layer Huawei LS out Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		noted No    
S3‑194656 Conclusion for Key issue 9 LG Electronics Inc. pCR Agreement
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		No
Yes
 		withdrawn Yes    
S3‑194657 eV2X: conclusion on KI #10 Huawei, Hisilicon,LG pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
YesRemoving "release 16" from the conclusion as MCC explained that this was a release 16 document anyway hence there was no need to mention it.
 		approved No   S3‑194177
S3‑194658 LS on PC5 unicast and groupcast security protection InterDigital Communications LS out Decision
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		approved No   S3‑193990
S3‑194659 Resource Level Authorization using Access Tokens Ericsson,Nokia draftCR Agreement
7.9Security Aspects of the 5G Service Based Architecture (Rel-16)
 		No
Yes
 		left for email approval No    
S3‑194660 Authentication subscription data KPN, Nokia pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
Yes
 		approved No   S3‑193986
S3‑194661 Key issue on Protection of long-term key during storage in UDR KPN, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
Yes
 		approved No   S3‑194247
S3‑194662 Key issue on Protection of long-term key during transfer out of UDR KPN, Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
Yes
 		approved No   S3‑194249
S3‑194663 Draft TR 33.845 Vodafone draft TR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		No
Yes
 		left for email approval No    
S3‑194664 Security Parameter Storage Ericsson pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
Yes
 		approved No   S3‑194292
S3‑194665 Notes from the offline session on false base stations NTT-Docomo report Information
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No    
S3‑194666 Reply to: LS on GUTI allocation for MT-EDT in 5G CIoT Ericsson LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑194667 Updates to solution #7 - capability negotiation Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		approved No   S3‑194202
S3‑194668 Updates to solution #17 - resolving Ens Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		approved No   S3‑194208
S3‑194669 UDR study - title correction Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
Yes
 		approved No   S3‑194411
S3‑194670 UDR study - intro Nokia, Nokia Shanghai Bell pCR Approval
8.14Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication
 		Yes
YesFirst paragraph and first sentence of last paragraph are gone as requested by Orange.
 		approved No   S3‑194412
S3‑194671 UE activates UP IP over eUTRA to EPC Huawei, Hisilicon pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
Yes
 		approved No   S3‑194120
S3‑194672 Draft TR 33.853 Vodafone draft TR Approval
8.9Study on User Plane Integrity Protection
 		No
Yes
 		left for email approval No    
S3‑194673 Resolving the ENs in KI#3.1 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑194189
S3‑194674 LS on deleting invalid autnentication results in UDM Huawei LS out Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No    
S3‑194675 AUTH_Enh-update for solution#4.1 Apple,Huawei pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑194026
S3‑194676 Draft TR 33.846 Ericsson draft TR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		No
Yes
 		left for email approval No    
S3‑194677 AUTH_Enh-Evaluation for solution#2.4 Apple pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑193974
S3‑194678 Resolving the ENs of solution#2.5 in the TR 33.846 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑194188
S3‑194679 Add solution details and evaluation to solutioin 4.1 Huawei, Hisilicon pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑194085
S3‑194680 LS on resynchronization Qualcomm LS out Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No    
S3‑194681 Update to the evaluation of solution #4.1 on protecting SQN in AKA re-synchronisations Qualcomm Incorporated pCR Approval
8.11Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑194316
S3‑194682 Updates to solution #7 - network sharing Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		No
Yes
 		withdrawn Yes    
S3‑194683 Updates to solution #7 - signature schemes and length Ericsson pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		approved No   S3‑194204
S3‑194684 Draft TR 33.809 Apple draft TR Approval
8.4Study on 5G security enhancement against false base stations
 		No
Yes
 		left for email approval No    
S3‑194685 5GFBS-Update for solution#11 Apple pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
YesRemoving the editor's note on legacy USIMs.
 		approved No   S3‑194028
S3‑194686 Shared key based MIB/SIBs integrity information provided by gNB Qualcomm Incorporated pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		approved No   S3‑194327
S3‑194687 Reply LS to RAN2 on FBS detection Huawei, HiSilicon LS out Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No   S3‑194033
S3‑194688 Update solution 4 to clarify MIB/SIB Hash report Huawei, HiSilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		approved No   S3‑194032
S3‑194689 Address EN in solution 6 and solution 18 Huawei, Hisilicon pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		noted No   S3‑194110
S3‑194690 Resolving the ENs of solution#5 in the TR 33.809 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval
8.4Study on 5G security enhancement against false base stations
 		Yes
Yes
 		approved No   S3‑194190
S3‑194691 Clarification on primary authentication in direct NAS reroute for Rel-15 Huawei, Hisilicon CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		agreed No   S3‑194198
S3‑194692 Clarification on primary authentication in direct NAS reroute for Rel-16 Huawei, Hisilicon,ZTE CR Approval
7.1Security aspects of 5G System - Phase 1 (Rel-15)
Yes
Yes
 		agreed No   S3‑194199
S3‑194693 CAG ID privacy conclusion Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No   S3‑194403
S3‑194694 5WWC Huawei CR Agreement
7.12Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑194695 Cover sheet TR 33.835 for approval China Mobile TS or TR cover Approval
8.2Study on Authentication and key management for applications based on 3GPP credential in 5G
 		Yes
YesNTT-Docomo commented that they preferred not to spend more time discussing this and send it for approval. Qualcomm: it is clearly more than 80% completed. Lenovo supported sending this for approval. Nokia: let's focus on the TS. ZTE supported sending it for approval. Sending the TR for approval, show of hands: Vodafone objected. Support sending it for approval: Ericsson Apple, ZTE, Huawei,KPN,Lenovo,Qualcomm, Nokia,China Mobile. The Chair decided to send it for approval anyway but warned the delgates that Vodafone could object in plenary and in that case it would be probably brought back to SA3.
 		approved No   S3‑194217
S3‑194696 Presentation of TR 33.819 to SA plenary Nokia TS or TR cover Approval
8.7Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No    
S3‑194697 New solution to KI#9 Huawei, HiSilicon pCR Approval
8.13Study on Security Aspects of 3GPP support for Advanced V2X Services
 		Yes
Yes
 		noted No   S3‑194042
S3‑194698 UP IP-update for solution#9 Apple pCR Approval
8.9Study on User Plane Integrity Protection
 		Yes
Yes
 		approved No   S3‑193972
S3‑194699 Work Plan input from Rapporteurs MCC other -
9.2Rapporteur input on status of WID or SID
 		Yes
Yes
 		noted No   S3‑193906