Tdoc List

2019-02-01 16:48

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑190000 Agenda WG Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No    
S3‑190001 Report from last SA3 meeting/s MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
Yes
 		approved No    
S3‑190002 SA3 Work Plan MCC Work Plan  
9.1Review of work plan
 		Yes
Yes
 		noted No    
S3‑190003 Report from last SA meeting WG Chairman report  
4.2Report from SA Plenary
 		Yes
Yes
 		noted No    
S3‑190004 SA3 meeting calendar MCC other  
10Future Meeting Dates and Venues
 		Yes
Yes
 		noted No    
S3‑190005 Work Plan input from Rapporteurs MCC other  
9.2Rapporteur input on status of WID or SID
 		Yes
Yes
 		revised No S3‑190563  
S3‑190006 Draft TR 33.xxx - Skeleton TR on User Plane Integrity Protection Vodafone Group other Agreement
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		revised No S3‑190014  
S3‑190007 pCR to TR 33.853 - addition of scope Vodafone GmbH pCR Agreement
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		revised No S3‑190015  
S3‑190008 draft skeleton document TR 33.935 - v001 - Detailed Long term key solutions Vodafone GmbH other Agreement
8.16Study on LTKUP Detailed solutions
 		Yes
Yes
 		not treated No    
S3‑190009 Discussion document on the changes required to BEST for the authentication available on the 5G options Vodafone GmbH discussion Discussion
7.5.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
YesDeutsche Telekom: we support option one. Nokia: we are having a similar issue in the AKMA work item. We prefer to analyze both before making a decision. NEC supported Nokia. Option 2 could be studied in the scope of AKMA and option one was fine too. BT: we are losing the focus on the battery efficiency and going for key sharing instead. Vodafone proposed to reword the option 2 and include in the scope of the AKMA study with contributions. Option one would be the way to go.
 		noted No    
S3‑190010 CR to 33.163 - Addition of HSE to NR core authentication interface Vodafone GmbH CR Endorsement
7.5.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑190011 draft WID for Addition of HSE to 5G core interface for authentication (if required) Vodafone GmbH WID new Endorsement
7.6New Work Item proposals
 		No
Yes
 		withdrawn Yes   S3‑183450
S3‑190012 CR to 33.834 - implementation of changes requested by edithelp Vodafone GmbH CR Endorsement
8.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)
 		No
Yes
 		left for email approval No    
S3‑190013 CR to 33.841 - implementation of requested by edithelp Vodafone GmbH CR Endorsement
8.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		No
Yes
 		left for email approval No    
S3‑190014 Draft TR 33.853 - Skeleton TR on User Plane Integrity Protection (updated after conf call) Vodafone Group draft TR Agreement
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		approved No   S3‑190006
S3‑190015 pCR to TR 33.853 - addition of scope (updated following conf call) Vodafone GmbH pCR Agreement
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		approved No   S3‑190007
S3‑190016 Correcting TLS crypto profiles Juniper Networks, Ericsson CR  
7.5.3Network Domain Security (NDS)
 		Yes
Yes
 		agreed No    
S3‑190017 LTKUP: addition of solution 5 in TR 33.935 Gemalto N.V. pCR Approval
8.16Study on LTKUP Detailed solutions
 		Yes
Yes
 		not treated No    
S3‑190018 Cooperation on Generic Slice Template definition GSMA LS in  
6.4GSMA
 		Yes
Yes
 		noted No    
S3‑190019 User Plane Security for 5GC Roaming GSMA LS in  
6.4GSMA
 		Yes
YesDeutsche Telekom: we have taken into acount in the FBA study already. BT commented that this should be taken care of in Rel-16. Vodafone: make a recommendation in Rel-15 to get around this issue and fix it in Rel-16. BT clarified that SA plenary would take care of a response to GSMA coordinating with SA3.
 		noted No    
S3‑190020 LS on new 5G-GUTI allocation C1-188921 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesAddressed in tdoc 106.
 		replied to No    
S3‑190021 LS on protection of initial NAS messages C1-188925 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑190022 Reply LS on Routing ID S2-1813178 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesNEC had a discussion document about this in tdoc 401.
 		noted No    
S3‑190023 Reply LS on Routing ID C1-188979 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑190024 LS on EAS-C&U support C3-186313 LS in  
7.5.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
YesVodafone rejected CT3's last comment on the protocol details. ORANGE: we have already an annex with these protocols and CT3 is going to talk about the same protocols with differences. We should avoid that. Vodafone: there is no requirement for the work they are doing. We need to point them out that.
 		replied to No    
S3‑190025 LS on OAuth authorization flows supported for Northbound APIs C3-187660 LS in  
7.5.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑190026 LS on Nudr Sensitive Data Protection C4-188524 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesVodafone commented that this shouldn’t be done at all. BT: this is trying to structure unenstrucutred data.
 		replied to No    
S3‑190027 Clarification request on NF authorization in UE Reachability Notification Request procedure C4-188603 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesVodafone pointed out that the second question was relevant for SA3. Docomo commented that this point was about reachability, not security related.
 		noted No    
S3‑190028 Response to 3GPP SA2 liaison S2-189038 on ‘general status of work’ BBF LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190029 Response to 3GPP SA2 liaison S2-1811575 on ‘general status of work’ BBF LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190030 Response to 3GPP SA2 liaison S2-1810989 on ‘Reply LS on devices behind 5G-RG accessing the 5GC’ BBF LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190031 Response to 3GPP SA2 liaison S2-1812643 BBF LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190032 Response to 3GPP SA2 on FN-RG authentication BBF LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		replied to No    
S3‑190033 LS to 3GPP TSG-SA WG6 on Use of ITS Dedicated Spectrum within V2X UE ETSI TC ITS LS in  
6.11Other Groups
 		Yes
Yes
 		noted No    
S3‑190034 LS on DRB Integrity Protection R2-1819080 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑190035 Reply LS on UP Integrity Protection for Small Data in Early Data Transfer R3-187230 LS in  
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		withdrawn Yes    
S3‑190036 Reply LS on inclusion of selected PLMN into the complete message R3-187235 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑190037 LS on Security Result Exchange Between NG-RAN and SMF in DC R3-187244 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesNokia: there is no security issue here. Ericsson: the SMF should be informed.This was taken offline.
 		replied to No    
S3‑190038 Enforcement of maximum supported data rate for integrity protection R3-187267 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesThis had to be taken offline since Docomo doubted about the necessity of doing this.
 		noted No    
S3‑190039 GTP Recovery Counter & GSN node behaviou GSMA LS in  
6.4GSMA
 		Yes
YesDirected to CT4.
 		noted No    
S3‑190040 LS on Authentication for UEs not Supporting NAS S2-1812600 LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesVodafone: non-5G-capable over WLAN UE has nothing to do with us. ORANGE didn't agree with the solutions shown here. Vodafone: why they talk about primary authentication if we have settled on having secondary authentication here? Lenovo: we have LTE over WLAN case when you could access the core network without USIM. In this case you are a subscriber of the core network, no roaming scenarios considered. We don’t see any issue if this is under control of the network operator. ORANGE: there is an LI issue. Who's liable? The owner of the UE or the WLAN owner? There is no point in asking for anything different from EAP' . Vodafone: You must have the USIM if you want to do the primary authentication. Gemalto supported Vodafone and ORANGE. The proposal by ORANGE was to tell SA2 to reuse the procedure in TS 33.501 for EAP' for primary authentication, and credential storage as detailed in the same spec. Samsung: ask SA2 about what kind of UE they are talking about.
 		replied to No    
S3‑190041 Reply LS on FN-RG authentication and related questions S2-1812601 LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		replied to No    
S3‑190042 LS on the security aspects of UE Capability ID S2-1812607 LS in  
6.13GPP Working Groups
 		Yes
Yes373,374 and 129 are docs related to this.
 		replied to No    
S3‑190043 Reply LS on FS_5WWC conclusion of study work S2-1812643 LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190044 LS on PC5 unicast and groupcast security protection S2-1812896 LS in  
8.21New study item proposals
 		Yes
YesORANGE: do we answer SA2 before or after the study? LG: we reply that we will investigate it with a study. ORANGE: study all possible solutions or those two proposed by SA2? LG commented that only the two from sA2.
 		replied to No    
S3‑190045 LS On Slice-Specific Secondary Authentication S2-1813359 LS in  
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesHuawei: not urgent to send it during this meeting. Timer is defined in CT1 and would rather wait for CT1's reply. Not sure that there are security issues. Ericsson: We don’t support the SA2 solution, let's wait and analize this. CableLabs: timer can be manipulated, let's discuss this and wait for CT1's reply. Interdigital: SA3 doesn’t see any security issues, we can reply with that. Nokia: ask CT1 if they can manage a flexible timer. It was decided to postpone it for the next meeting.
 		postponed No    
S3‑190046 LS response on API invoker onboarding S6-181848 LS in  
7.5.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑190047 Reply LS on Control Plane Solution for Steering of Roaming in 5GS SP-181244 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑190048 TCG Progress Report InterDigital, Inc. report Information
6.6TCG
 		Yes
Yes
 		noted No    
S3‑190049 [33.179] R13 Annex D.3.4.2 XSD correction Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑190050 [33.180] R14 Annex D.3.5.2 XSD correction (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑190444  
S3‑190051 [33.180] R15 Annex D.3.5.2 XSD correction (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑190445  
S3‑190052 [33.179] R13 IdMS interface security Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑190053 [33.180] R14 IdMS interface security (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
YesCableLAbs
 		revised No S3‑190446  
S3‑190054 [33.180] R15 IdMS interface security (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
YesJuniper: the TLS profile has been moved to 33.210. It was commented that there was a note in 33.310 pointing to 33.210 anyway and this could be fixed later.
 		revised No S3‑190447  
S3‑190055 [33.179] R13 user service authorisation Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
YesSamsung: we cannot delete a feature from Release 13 for this reason. We can wait for stage 3 before deleting this. Tim (Motorola): leave it in Rel-13? It's ok, but even beyond stage 3 problems there is an interoperability problem. We should remove it from Rel-15, Rel-16. Nokia: plugtest results should be evaluated by Samsung and bring a paper with their conclusions. Samsung agreed to do that.
 		not pursued No    
S3‑190056 [33.180] R14 user service authorisation (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		not pursued No    
S3‑190057 [33.180] R15 user service authorisation (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		not pursued No    
S3‑190058 [33.180] R14 InK clarifications Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑190448  
S3‑190059 [33.180] R15 InK clarifications (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑190449  
S3‑190060 [33.180] R14 MCX identity clarifications Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑190450  
S3‑190061 [33.180] R15 MCX identity clarifications (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑190451  
S3‑190062 Adding Security Protection Requirement of Unicast RRC Messges HUAWEI TECH. GmbH pCR Approval
8.9Study on 5G security enhancement against false base stations
No
Yes
 		withdrawn Yes    
S3‑190063 Security Solution for RRC UE capability transfer HUAWEI TECH. GmbH pCR  
8.9Study on 5G security enhancement against false base stations
No
Yes
 		withdrawn Yes    
S3‑190064 Details of protecting gNB from RRC DoS attack HUAWEI TECH. GmbH pCR  
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑190065 Corrections of messages names etc HUAWEI TECH. GmbH CR  
7.1.4AS security
 		No
Yes
 		withdrawn Yes    
S3‑190066 LS to RAN2/3 on EDT data integrity protection HUAWEI TECH. GmbH LS out  
7.5.1SAE/LTE Security
 		No
Yes
 		withdrawn Yes    
S3‑190067 Adding Security Protection Requirement of Unicast RRC Messges Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesCompared with 275.
 		noted No    
S3‑190068 Security Solution for RRC UE capability transfer Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No    
S3‑190069 Security Requirement for Paging Messges Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesApple: requirement should be more general. Ericsson: protection of paging in a separate key issue should be in a separate key issue.
 		noted No    
S3‑190070 Protection for Incoming Paging Message Based on Stored Security Context Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑190071 Avoiding UE connecting to fake base station during HO Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190072 Corrections of messages names etc Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		merged No S3‑190423  
S3‑190073 EDT UP IP handling of multiple PDCP PDUs Huawei, Hisilicon CR Approval
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesIntel: RAN2 hasn’t discussed the LS that we sent to them, so we don’t need to pursue this CR during this meeting. Besides this solution doesn’t cover a particular scenario and we don’t agree with this solution. This was left open.
 		not pursued No    
S3‑190074 Details of protecting gNB from RRC DoS attack Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: no drawbacks at all in the evaluation, impacts and no sales pitch. Not clear which key issue is being evaluated.
 		revised No S3‑190482  
S3‑190075 Resolving Editor’s Note for solution #7 (clause 6.7) Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190076 LS to RAN2/3 on EDT data integrity protection Huawei, Hisilicon LS out Approval
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		revised No S3‑190454  
S3‑190077 Update Solution #4 to use HASHUE-data as in TS33.401 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190078 Clarification and correct clause reference for RNAU w/o context relocation Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No    
S3‑190079 New key issue: Protection of Line ID Ericsson pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesThreats and requirements go out, key issues are merged.
 		merged No    
S3‑190080 New key issue: TNAP mobility for trusted non-3GPP access Ericsson pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE: less key issues and more solutions.
 		noted No    
S3‑190081 Reply-LS on FN-RG authentication and related questions Ericsson LS out Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑190518  
S3‑190082 Reply-LS on FN-RG authentication and related questions Ericsson LS out Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE: SA2 should not assume solutions before consulting SA3 on the security feasibility of these solutions. Huawei: we agree on roaming scenarios but we don’t have solutions yet. Ericsson: progress is easier by answering LS.
 		merged No S3‑190518  
S3‑190083 Alignment with TS 23.502: Optimization of UDM selection in AUSF Ericsson CR Agreement
7.1.8Primary authentication
 		Yes
YesVodafone: Compatibility issue with the networks that are rolled out today. It's too late to change this. Ericsson replied that this was alignment with SA2. Huawei disagreed. This had to be taken offline.
 		not pursued No    
S3‑190084 Correction to authentication step Ericsson CR Agreement
7.1.8Primary authentication
 		Yes
YesCableLabs: good requirement. Does the AUSF do the same validation? ZTE: this depends on the discussion about the SUPI type and the AMF. Nokia: the MNC is part of the SUPI value. Why does it depend on the SUPI type? The current procedure already addresses this. What kind of attack are we facing here? Huawei agreed with Nokia. Ericsson: there is no attack, there is a weakness. Lenovo didn’t understand how this could ever happen.
 		not pursued No    
S3‑190085 Reply LS on Nudr Sensitive Data Protection Ericsson LS out Approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		revised No S3‑190411  
S3‑190086 New solution: WLAN measurements from UEs Ericsson pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190087 New solution: Bluetooth measurements from UEs Ericsson pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190088 Resubmission of S3-183526 “WLAN positioning - new KI for the upcoming TR on FS_eLCS_Sec” Ericsson pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		approved No    
S3‑190089 Editorials and minor clarifications for clause 13.1 Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No    
S3‑190090 Editorials and minor clarifications for clause 13.2 Ericsson CR Agreement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑190439  
S3‑190091 Minimized kernel functions Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesIf agreed, this should become a mirror and we would need a new CR for Rel-14.
 		not pursued No    
S3‑190092 Minimized kernel functions Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		not pursued No    
S3‑190093 Protection from buffer overflows Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesMCC commented that the error should be corrected in the earliest release of this spec,Rel-14. Huawei: the test case is not impacted, only the examples. NTT-Docomo agreed with removing the examples to keep the spec more aligned with the reality.
 		revised No S3‑190456  
S3‑190094 Protection from buffer overflows Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No    
S3‑190095 Uunused software Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesDeutsche Telekom didn't agree with this change. The test was important to maintain. Ericsson wasn't clear on how to test this. NEC supported Deutsche Telekom, BT as well.
 		not pursued No    
S3‑190096 Uunused software Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		not pursued No    
S3‑190097 No unsupported components Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesDeutsche Telekom didn't agree with removing this test case. NEC and BT supported this.
 		not pursued No    
S3‑190098 No unsupported components Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		not pursued No    
S3‑190099 Analysis of requirements on the AUSF in TS 33.501 Ericsson discussion Endorsement
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
YesHuawei: the failure should be also tested and that does not belong to any category. Alf (Vice chair) commented that the confusion focused on whether interoperability and failure authentication were in or out of scope of SCAS. Huawei: very few requirements deal with failure test cases: what happens if a particular test fails. The Vice Chair asked the delegates if the requirements in the table were considered category one. NEC replied that number 3 wasn’t category one. Ericsson: check these requirements and see what could go wrong and come back next meeting with the test cases? Huawei: refer to CT group standard as well. Deutsche Telekom: agree with Ericsson that these test cases are out of scope of SCAS. The way forward would be to agree on this. NEC: at least 1,2 and 4 are category one and this is agreed by the group. Huawei: failure test case included in the category one or not?
 		noted No    
S3‑190100 Name correction of the Nudm_SDM_Notification service operation Ericsson CR Agreement
7.5.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑190101 New Key Issue: UP integrity activation in EPS Ericsson pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		approved No    
S3‑190102 Update to Study Item Description FS_SBA_Sec: Security for inter-PLMN user plane traffic (N9 reference point) Ericsson SID revised Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑190103 Reply LS on Interim conclusions for SA2 study on Radio Capabilities Signalling Optimisations (FS_RACS) R2-1819206 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑190104 Update to KI#2.1 in TR 33.819 InterDigital Europe. Ltd. pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑190105 Update to Study Item Description FS_SBA_Sec: Security for inter-PLMN user plane traffic (N9 reference point) Ericsson, Juniper Networks, Deutsche Telekom AG SID revised  
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑190464  
S3‑190106 Reply LS on new 5G-GUTI allocation Ericsson LS out Approval
7.1.15Incoming and outgoing Lses
 		Yes
YesQualcomm agreed with this except in the case of non-3GPP networks.
 		revised No S3‑190410  
S3‑190107 Expectations and requirements for 256 bit algorithms ETSI SAGE LS in  
6.3ETSI SAGE
 		Yes
Yes
 		withdrawn Yes    
S3‑190108 TR33848 Study on Virtualisation Skeleton BT plc draft TR Agreement
8.18Study on Security Impacts of Virtualisation
 		Yes
Yes
 		approved No    
S3‑190109 TR33848 Introduction and Scope BT plc other Agreement
8.18Study on Security Impacts of Virtualisation
 		No
Yes
 		withdrawn Yes    
S3‑190110 TR33848 Section 4 Background BT plc other Agreement
8.18Study on Security Impacts of Virtualisation
 		No
Yes
 		withdrawn Yes    
S3‑190111 Evaluation text for solution #2 NEC Corporation pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		withdrawn Yes    
S3‑190112 New key issue on user plane integrity protection in MR-DC scenarios NEC Corporation pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		withdrawn Yes    
S3‑190113 New key issue on data rate limitation of integrity protection in UP DRB NEC Corporation pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		withdrawn Yes    
S3‑190114 New Key Issue: Basic security requirements on SFSF message transport Telekom Deutschland GmbH pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑190115 New Key Issue: Protection of SFSF interfaces Telekom Deutschland GmbH pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑190116 Subscriber privacy: test data for SUCI computation Gemalto N.V. CR Approval
7.1.14Privacy
 		Yes
YesIDEMIA: some coding is wrong, nt compliying with CT4's decisions. Qualcomm: good idea to have testers' data, but there are things missing here. We can come back next meeting with a better look at this.
 		not pursued No    
S3‑190117 Update to Study Item Description FS_SBA_Sec: Enhanced-SBA aspects Telekom Deutschland GmbH SID revised Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesMCC commented that taking the Rel-15 study and expanding it for a study in Rel-16 looked a bit unusual. It was agreed to do it like this since the TR hadn’t been approved. MCC added that the document should take the original SID and add revision marks for the changes. Any discussion should be part of a different document.
 		revised No S3‑190464  
S3‑190118 On the handling of invalid JSON patches in N32-f messages Telekom Deutschland GmbH discussion Discussion
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑190119 Inter-PLMN N9 Security Telekom Deutschland GmbH discussion Endorsement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesBT: it's up to the study to decide whether this is to be performed by a "box". Ericsson: let's study this as a key issue. TIM: SBA architecture is for control plane interfaces. N9 is a user plane interface. How is N9 security related to SBA architecture and why is it treated inside this SID? NTT-Docomo replied that SBA architecture should be in one study and the N9 part in a new study,
 		noted No    
S3‑190120 New Test Case: Separation of cryptographic storage within the SEPP Telekom Deutschland GmbH pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑190511  
S3‑190121 New Test Case: Connection-specific scope of cryptographic material by IPX-providers Telekom Deutschland GmbH pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		noted No    
S3‑190122 New Test Case: Precendence of preconfigured protection policies Telekom Deutschland GmbH pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		noted No    
S3‑190123 New Test Case: Validating the common message formatting Telekom Deutschland GmbH pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		noted No    
S3‑190124 CR Add UE trace to UE Authentication Get Service Nokia, Nokia Shanghai Bell CR Approval
7.1.8Primary authentication
 		Yes
YesVodafone: what data is Trace Data? NEC agreed, there was no security reasoning behind this. Nokia: This is described in SA2 and CT4. Huawei: limit to authentication related parameters. Nokia: it doesn't impact the security directly. This particular definition does only exist in 33.401, that’s why it's here. Ericsson: we need to know what is done in SA2 but at the moment there is no mentioning of this, the clause is empty. Nokia commented that this was aligned with results from the SA2 meeting held the previous week, not available at that time. Vodafone: we might be giving away data that is covered by the GDPR. It was agreed to send an LS to SA2 and attach this CR. The agreement on this CR would depend on the response from SA2. After discussions on the LS, it was decided to note the LS.
 		not pursued No    
S3‑190125 Discussion on providing AS security during RRC connection establishment to protect NSSAI NEC Europe Ltd discussion Agreement
7.6New Work Item proposals
 		Yes
Yes
 		withdrawn Yes    
S3‑190126 Discussion on C1-188921 LS on GUTI Re-assignment Nokia, Nokia Shangahi Bell discussion Endorsement
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑190127 Key Issue for Fake Base Station Intel Deutschland GmbH pCR  
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190128 New WID on providing the encryption of slice identity at the AS layer during RRC connection establishment procedure NEC Europe Ltd WID new Approval
7.6New Work Item proposals
 		Yes
YesNokia: SA3 and SA2 have agreed on a solution already. If a new solution is needed, it should be triggered in SA2 and not here. Ericsson agreed with this. NEC clarified that this was presented in SA2 and that they directed the discussions to SA3. Deustche Telekom supported this study. Vodafone: this is a study item, not a Work Item. NEC: it's a TR and CRs for the TS. Vodafone replied that wasn't the way of working. Supporting the study in Rel-16: NEC, Huawei,NIST,BT,KPN,Docomo,Intel,ARICC,T-Mobile. Not in Rel-16: Nokia. Qualcomm: key issue in the key authentication study that we already have. Huawei agreed with this. NTT-Docomo preferred to have a separate study. The Chair recommended to decrease the number of study items, for the sake of progress.
 		noted No    
S3‑190129 Discussion on Radio Capability indication LS S2-1812607 Nokia, Nokia Shanghai Bell discussion Endorsement
7.1.15Incoming and outgoing Lses
 		Yes
YesVodafone was in line with Nokia's comments: It could be a problem given that it wouldn't be sent after authentication. Ericsson also agreed with sending the capbilities encrypted.
 		noted No    
S3‑190130 Security Requirement for Key issue 2 Intel Deutschland GmbH pCR  
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesBT: EPC instead of EPS. Ericsson: impact on ME is considerable. Qualcomm: this is driving to a solution.
 		noted No    
S3‑190131 EPC solution for RLOS access Intel Deutschland GmbH pCR  
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesVodafone: does PARLOS work for roaming customers? Sprint replied that it was an accepted option. Nobody seemed to agree on this contribution so it was noted.
 		noted No    
S3‑190132 Discussion on SA2 LS on Slice Specific Authentication S2-1813359 Nokia, Nokia Shanghai-Bell discussion Endorsement
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		noted No    
S3‑190133 Solution for Slice Specific secondary authentication Nokia, Nokia Shangahi Bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesORANGE wanted to question the SA2 solution (dependency of primary and secondary authentication) from SA3 perspective, by adding an editor's note. TIM commented that secondary authentication was not related to the slice concept. The slice is inside the core network and does have nothing to do with the secondary authentication as SA3 had agreed. We need to agree on the correct terminology. Slice secondary authentication would be the terminology to follow instead of secondary authentication. Interdigital: nested authentication is an open issue between SA2 and CT1. Add an editor's note about this. ORANGE: remove the evaluation, too early.
 		revised No S3‑190533  
S3‑190134 Clarification on Establishment of a mapped security context during intersystem handover(N1 to S1) Intel Deutschland GmbH CR  
7.1.10Interworking
 		Yes
YesQualcomm and Ericsson didn’t agree with this.
 		not pursued No    
S3‑190135 Clarification to the 5G-GUTI change during the NAS procedure. NEC Europe Ltd CR Approval
7.1.3Mobility
 		Yes
Yes
 		not pursued No    
S3‑190136 Clarification to the 5G-GUTI allocation during the Notification procedure. NEC Europe Ltd CR Approval
7.1.5NAS security
 		Yes
Yes
 		not pursued No    
S3‑190137 Clarification on Establishment of a mapped security context during intersystem handover(S1 to N1) Intel Deutschland GmbH CR  
7.1.10Interworking
 		Yes
YesZTE didn’t agree with the scenarios. Ericsson: the clause is misplaced.
 		not pursued No    
S3‑190138 Handling of SUCI de-concealment during registration retry procedure NEC Europe Ltd CR Approval
7.1.3Mobility
 		Yes
YesEricsson: this is done in TS 34.501 already. It's in scope of CT1. Huawei: it doesn’t belong here. Nokia agreed with this. There was a strong support on this being in CT1's scope.
 		not pursued No    
S3‑190139 requirement of protection of broadcast messages Apple (UK) Limited pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑190140 Clarification on Handover message in Interworking Intel Deutschland GmbH CR  
7.1.10Interworking
 		Yes
YesQualcomm disagreed with this.
 		not pursued No    
S3‑190141 requirement of protection of unicast messages Apple (UK) Limited pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑190142 Discussion about a new study on eV2X security LG Electronics discussion Discussion
8.21New study item proposals
 		Yes
Yes
 		noted No    
S3‑190143 New SID on Security Aspects of 3GPP support for Advanced V2X Services LG Electronics SID new Approval
8.21New study item proposals
 		Yes
YesORANGE: conclusions should be based on the TR conclusions from sA2. LG clarified that the solutions will go for the normative work that is being carried out in SA2.
 		revised No S3‑190462  
S3‑190144 Reply LS on PC5 unicast and groupcast security protection LG Electronics LS out Approval
8.21New study item proposals
 		Yes
Yes
 		revised No S3‑190463  
S3‑190145 Editorial pCR for PARLOS TR 33.815 LG Electronics pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑190466  
S3‑190146 ID-based solution in 5GFBS Apple (UK) Limited pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑190147 Credential-based solution in 5GFBS Apple (UK) Limited pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesORANGE was against these solutions. Qualcomm: we studied those kind of solutions in PWS. Ericsson: it's important to capture this and the scalability issues. ORANGE: don’t repeat the same evaluations from other TRs. Apple: why are we doing a study if we are killing all solutions?
 		noted No    
S3‑190148 Key issue of network credential revocation consideration Apple (UK) Limited pCR Approval
8.9Study on 5G security enhancement against false base stations
No
Yes
 		withdrawn Yes    
S3‑190149 Key issue of UP IP performance Apple (UK) Limited pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
YesHuawei: performance is not a security issue. ORANGE: consider bidding down attack.
 		noted No    
S3‑190150 Solution of improving efficiency of UP IP Apple (UK) Limited pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		noted No    
S3‑190151 Align NAS connection identifier values ZTE Corporation CR Agreement
7.1.3Mobility
 		Yes
YesDiscussed with overlapping documents 365, 378 and 222. Nokia: Huawei's document is proposing to re-use the concept in LTE. Ericsson: in LTE we didn’t have the concept of NAS connection identifier. It was finally decided to go for Qualcomm's point in 378. The last two changes of this document were merged in 422.
 		merged No S3‑190422  
S3‑190152 Clarification on Registration procedure for mobility from EPS to 5GS over N26 ZTE Corporation CR Agreement
7.1.10Interworking
 		Yes
YesEricsson: we don’t need this clarification, nothing new here. Vodafone: this is not an essential correction, cat-F.Nokia supported Vodafone.
 		not pursued No    
S3‑190153 Handling of AMF redirection ZTE Corporation CR Agreement
7.1.5NAS security
 		Yes
YesEricsson: Why restrict the AMF from performing re-authentication procedure?It is not clear why this is needed. Nokia agreed with Ericsson. Proposal 2 and 3 were related to one.
 		not pursued No    
S3‑190154 Authorization on northbound APIs ZTE Corporation pCR Approval
7.2.9Network Exposure Function (NEF) (TS 33.519)
 		Yes
Yes
 		revised No S3‑190514  
S3‑190155 Anti fake base station based on symmetric algorithm ZTE Corporation pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190156 Solution on registration for mutual exclusive slices ZTE Corporation pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesORANGE, TIM didn’t understand the contrbution. BT didn’t see the requirement forthis. For this reason the document was noted.
 		noted No    
S3‑190157 Key issue for acceleration of AKA procedure for low latency ZTE Corporation pCR Approval
8.13Study on security for 5G URLLC
Yes
YesVodafone: this is more a solution. ORANGE didn’t agree with the requirement. New editor's note added.
 		revised No S3‑190541  
S3‑190158 Solution on enhancement of handover with direct Xn tunnel for single user plan path ZTE Corporation pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		noted No    
S3‑190159 Key issue for SUPI concealment ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190160 Key issue for linkability when AUTN verification fails ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190161 Solution on mitigation of large SUCI attack ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190162 Solution for linkability issue ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190163 New SID on 5G forward security ZTE Corporation SID new Approval
8.21New study item proposals
 		Yes
YesNokia: there is a forward secrecy study item. Ericsson: this is not very urgent for Rel-16. There is no clear threat, it's more of an enhancement. ORANGE preferred to have a security paper for the next meeting describing the security issue. This was also recommended by the Chair.
 		noted No    
S3‑190164 New SID on IPsec enhancement to meet 5G data rate requirements ZTE Corporation SID new Approval
8.21New study item proposals
 		Yes
Yes
 		noted No    
S3‑190165 Discussion on improving the efficiency of IPsec to meet 5G data rate requirements ZTE Corporation discussion Discussion
8.21New study item proposals
 		Yes
YesZTE clarified that the results were coming from testing. BT: 20Gbps? What was the experimental setup? 3GPP deployment? ZTE answered that a 3GPP deployment. IPSec is an IETF standard, and the issue should be considered there. NEC: this is about performance and implementation, not a standard issue.
 		noted No    
S3‑190166 Solution on privacy protection of SUPI ZTE Corporation pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesVodafone: This assumes that we are only using GPM whereas AKMA's scope will be wider. BT: no distribution of private key here. Qualcomm: this solution adds nothing, it should be noted. Vodafone: the solution doesn’t meet the criteria.
 		noted No    
S3‑190167 a skeleton of security aspects of 5G SRVCC to UTRAN Huawei, Hisilicon, China Unicom draftCR Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		revised No S3‑190443  
S3‑190168 Resovle Editor's note in Solution for bootstrapping authentication of AKMA Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No    
S3‑190169 Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesVodafone, ORANGE: the document is badly structured.You have a solution in mind, write the key issues properly. There was no support for this document.
 		noted No    
S3‑190170 New Conclusion for Small Data Transfer via NAS Signaling Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: too premature for having conclusions. We still have lot of new key issues. Nokia supported Huawei in order to make progress and not delay anything. Ericsson: we should have a conclusion for each key issue as SA2 is doing.
 		revised No S3‑190489  
S3‑190171 New Solution Security-Property-Group-based Mitigation for DDoS Attack Triggered by Malicious Applications on the UE Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesJuniper: this is an operational issue for operators. It should be treated outside security.Qualcomm agreed with Juniper; it's application level. Alf (NTT-Docomo): not advisable to have standardised these kind of mechanisms since it would be too exposed to the public. It was agreed to add two editor's notes. Qualcomm suggested the need for discussion papers justifying why these kind of solutions should be justified. ORANGE: editor's note on investigating whether this solutions brings new DoS attacks.
 		revised No S3‑190485  
S3‑190172 Address EN in Key Issue 4 of Definition of Misbehaving UE Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesNEC: the clause 8.8.1 in 23.791 does have nothing to do with the misbehaving UE. Vodafone preffered to have this moved to the Definitions clause. Qualcomm: we need to understand the definition of misbehaving UE in the context of CIoT. Huawei: we don’t want to define anything, just to use an existing definition.
 		revised No S3‑190474  
S3‑190173 New Key Issue for NAS based Redirection between Core Networks Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: the key issue is the bidding attack. The anti-bidding down is the solution. NEC: this problem is not specific for IoT. NEC supported this. CableLabs supported having this threat. NTT-Docomo: What happens if there is no key negotiated, key wrong, etc? What’s there it is a solution specific requirement. Vodafone: there is nothing that says here what protection we have in the current system. Then explain why it could be unprotected.
 		revised No S3‑190475  
S3‑190174 Clarification for section 6.10.2.1 Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		revised No S3‑190433  
S3‑190175 Clarification for UP security in option4&7 Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
YesNokia: delete the "rather than".
 		revised No S3‑190434  
S3‑190176 claification on interworking case Huawei, Hisilicon CR Approval
7.1.10Interworking
 		Yes
YesVodafone: not happy with the use of "done" in these sentences. Qualcomm: changes are not needed, they are obvious. MCC: replace 4G with LTE.
 		revised No S3‑190437  
S3‑190177 key update in multi-NAS scenario Huawei, Hisilicon CR Approval
7.1.5NAS security
 		Yes
YesNokia: why are we bringing these changes based on access type? Overlapping with tdoc 282 and 372.
 		revised No S3‑190556  
S3‑190178 Clarification on the UE selecting the 4G or 5G security protection method Huawei, Hisilicon CR Approval
7.1.16Others
 		Yes
YesQualcomm: already specified in CT1, not needed here. Huawei: this is not done in CT1. Ericsson: why is NAS not mentioned here and only AS SMC procedure? Is the AS SMC part an example? This had to be taken offline.
 		revised No S3‑190478  
S3‑190179 Add requirement to KI#2 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190180 A new KI on the trust of W-5GAN Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesEricsson, ORANGE: this is not needed.
 		noted No    
S3‑190181 Add evaulation to sloutlion 3 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190182 add conclusion clauses Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesEricsson: we don’t have conclusions yet. Huawei: but we will. ORANGE: just keep the Key Issue X.
 		approved No    
S3‑190183 Add conclusion to KI#1 Huawei,Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190184 Key Issue for encryption and integrity protection of assistance data Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190185 Key Issue for encryption and integrity protection of location data Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190186 Key Issue for integrity protection of privacy setting between UE and home network Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190187 Solution for DDoS attack mitigation in CIoT Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEricsson: editor's note on how this filter is determined. This was agreed.
 		revised No S3‑190486  
S3‑190188 Solution for integrity protection of privacy setting between UE and UDM Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190189 Key Issue for protection against DDoS attack Huawei, Hisilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesVodafone: why mandate the NPN to support anything? The first requirement needs rewording anyway. Nokia: does the Denial of Service a key issue need to be addressed at all? Qualcomm: this key issue is not needed.
 		noted No    
S3‑190190 Security Solution for DDoS attack mitigation in the roaming scenarios between NPN and PLMN Huawei, Hisilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑190191 Editorial corrections in TS 33.117 R15 Nokia, Nokia Shanghai Bell CR Approval
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesIt was agreed in order to see if Rel-14 had the same issue to be corrected.
 		revised No S3‑190458  
S3‑190192 Corrections on ng-ran keys Huawei, HiSilicon CR Agreement
7.1.4AS security
 		Yes
YesNokia didn’t agree with using multiple names for the same keys. KNG-RAN should not be used as this is causing confusion.
 		revised No S3‑190426  
S3‑190193 New clause for intra ng-enb handover Huawei, HiSilicon CR Agreement
7.1.4AS security
 		Yes
YesNokia: not sure if we need this new clause. Ericsson agreed.
 		not pursued No    
S3‑190194 Clarifications CIOT security assumptions Huawei, HiSilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: it's clearer to have the introducion of 268 instead of having it in here. ORANGE: why comparing it with EPS? Staet that the Ues shall follow 5G requirements. Huawei: we may miss solutions for IoT Ues that have EPS solutions (e.g. if they are redirected to EPS). ORANGE: if they are connected to 5G the Ues shall have security as strong as 5G.
 		revised No S3‑190473  
S3‑190195 CIOT solution 6 improvement Huawei, HiSilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190196 Roaming key issue for AKMA Huawei, HiSilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: why is the proxy needed? Huawei: it’s for the roaming. Qualcomm, Gemalto didn’t see the point for having a proxy either. Qualcomm: roaming needs to be supported, but we only need a description of the key issue to start with. Remove everything else and come back for the next meeting with the rest.
 		noted No    
S3‑190197 architecture solution for AKMA with non-standalone function Huawei, HiSilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: why mandating a specific authentication for the network in AKMA? Huawei: we want to reuse primary authentication.It's a general authentication procedure. ORANGE: this authentication is not needed. Vodafone: missing how the enterprise interacts with the system. Qualcomm: if you don’t want to use primary authentication describe it somewhere else. This is mixing primary authentication with Kusf authenticaiton. Vodafone: this is two different solutions mixed.
 		noted No    
S3‑190198 URLLC solution for N3 tunnel redundancy Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC
Yes
YesEricsson: Redundace of N9 tunnel needs more clarification. Ericsson: there is no key issue for the backhaul interface, which is being addressed here in the N3 interface.
 		revised No S3‑190549  
S3‑190199 URLLC solution for Key Issue 1 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC
Yes
YesOption 2 is merged into 545.
 		merged No S3‑190545  
S3‑190200 URLLC solution for Key Issue 3 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC
Yes
YesVodafone: how do they satisfy LI requirements? Ericsson: there are no LI issues.
 		revised No S3‑190546  
S3‑190201 A key issue on the long-term key and its related anchor key leakage Huawei, HiSilicon pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190202 A solution to slice authentication Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesORANGE: step 5 is slice registration complete. Add step 6.An editor's note was agreed, step one revised as well. Interdigital: this is still a nested approach and it needs waiting for SA2 and CT1's discussions.
 		revised No S3‑190534  
S3‑190203 A new KI on NSSAI protection Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		revised No S3‑190477  
S3‑190204 Solutions to AMF key separation Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesOrange: second solution is not related to this study item. NCSC didn't support this either as it was introducing a new solution that should be assesed agains quantum computing. Nokia didn't support it either.
 		noted No    
S3‑190205 A solution to security features for NSaaS Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesORANGE: why defining these security features at all here? I don’t want his table. BT, CableLabs: network slices hould have their own invocable security features according to policy. ORANGE: we only introduce secondary authentication in TS33.501, there is no other security feature added for them. TIM: how is the secondary authentication intended here? ORANGE clarified that it referred to the slice authentication.
 		revised No S3‑190537  
S3‑190206 Security threats and requirement for KI #4 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesDeutsche Telekom: privacy doesn’t leak, but user sensitive information. NTT-Docomo, NEC: against whom are we protecting? Editor's note was added to that effect.
 		revised No S3‑190535  
S3‑190207 Considerations on network product class when using NFV technology China Mobile, ZTE Corporation, Nokia, Nokia Shanghai Bell pCR  
8.14Study on SECAM and SCAS for 3GPP virtualized network products
Yes
Yes
 		not treated No    
S3‑190208 Evaluation text for solution #2 NEC Corporation pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: we are still adding key issues. Will you update this when new key issues will be added? NEC: this is the evaluation for a specific solution from last meeting. KPN: this looks like an evaluation for all key issues, this is very generic. Vodafone: editor's note on adding an evaluation for future key issues.
 		revised No S3‑190479  
S3‑190209 New key issue on user plane integrity protection in MR-DC scenarios NEC Corporation pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		noted No    
S3‑190210 New key issue on data rate limitation of integrity protection in UP DRB NEC Corporation pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
YesQualcomm: max data rate is full data rate, minimum is 64Kbps. The key issue is wrong. There was a different understanding on this and had to be discussed offline.
 		noted No    
S3‑190211 Discussion on Requirement for KDF Negotiation NEC Corporation, Huawei, Hisilicon discussion Discussion
8.10Study of KDF negotiation for 5G System Security
 		Yes
YesORANGE: premature to have this proposal. It was noted that the document was sent for discussion and not for endorsement.
 		noted No    
S3‑190212 Update to clause 4 to add KDF negotiation rationale NEC Corporation, Huawei, Hisilicon pCR Approval
8.10Study of KDF negotiation for 5G System Security
 		Yes
YesEricsson: geopolitics and cost issues are not true.They didn’t agree with the preferences of UE vendors either. Qualcomm: we cannot agree with this document. Too premature. KDF negotiation is needed in 5G. That's the only point we need now. ORANGE supported Ericsson and Qualcomm. ORANGE didn’t agree with anything in this contribution. NEC: this is just a rational clause for the study item, not a key issue. Colin (BT): Where are the KDFs and what's the impact on the operators? Vodafone: can only accept he paragraph on the future proofness. It looked like companies preferred a much shorter rational. This was taken offline.
 		revised No S3‑190517  
S3‑190213 New Key Issue on use of established keys for AKMA NEC Corporation pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		noted No    
S3‑190214 Solution for using established keys for AKMA NEC Corporation pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		revised No S3‑190558  
S3‑190215 Considerations on SECAM of the virtualized network products China Mobile, ZTE Corporation, Nokia, Nokia Shanghai Bell pCR  
8.14Study on SECAM and SCAS for 3GPP virtualized network products
Yes
Yes
 		not treated No    
S3‑190216 CR to TR 33.841 regarding key derivation function China Mobile CR  
8.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
YesEricsson: the note is not clear. NCSC commented that this wasn’t necessary for the study, which is finished.
 		not pursued No    
S3‑190217 Key issue regarding minimal computational cost when generating session anchor keys China Mobile pCR  
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190218 Key issue to ensure the correct routing of the data packets in the user plane China Mobile pCR  
8.17Study on User Plane Integrity Protection
 		Yes
YesDeutsche Telekom: same key issue as the NEC contribution.
 		noted No    
S3‑190219 Clarification on UE Parameters Update Data used for MAC computation Huawei, HiSilicon CR Agreement
7.1.16Others
 		Yes
YesQualcomm: it is already clear, no need to clarify. IDEMIA and Gemalto didn't support this either.
 		not pursued No    
S3‑190220 Test Case: Mutual Authentication between Network Functions Nokia, Nokia Shanghai Bell draftCR Approval
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		noted No    
S3‑190221 Key issue to ensure the security of session anchor keys China Mobile pCR  
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190222 Modificaiton on the NAS connection identifier for backward compatibility with LTE Huawei, Hisilicon CR  
7.1.5NAS security
 		Yes
Yes
 		not pursued No    
S3‑190223 Key issue to mitigate the DDoS attacks on the UDM China Mobile pCR  
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190224 NAS counter clarification on interworking Huawei, Hisilicon CR Agreement
7.1.10Interworking
 		Yes
YesEricsson: first set of changes are legacy behaviour. Not needed. Qualcomm didn’t agree with this contribution at all.
 		revised No S3‑190438  
S3‑190225 Test Case: Authorization of NF Serive Access Nokia, Nokia Shanghai Bell draftCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		noted No    
S3‑190226 Key issue to resist the linkability attacks China Mobile pCR  
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190227 Update on the token verification Huawei, Hisilicon,Nokia CR Agreement
7.1.13.2Other
 		Yes
YesNokia: not OK with removing the verification part, agree to remove where the verification is done. This was taken offline and then agreed.
 		agreed No    
S3‑190228 Proposed revision of solution 6 China Mobile,ZTE Corporation pCR  
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: this is mixing two authentication procedures. ZTE agreed to separate them. ORANGE then commented that the authentication procedure looked strange. ORANGE didn’t see it clear that there were two procedures after all and couldn’t agree with the contribution. ZTE wanted to add an editor's note on the need for separating both procedures but this was rejected by ORANGE. It had to be taken offline.
 		noted No    
S3‑190229 Clarification on service authorization and token verification Huawei, Hisilicon CR Agreement
7.1.13.2Other
 		Yes
Yes
 		revised No S3‑190440  
S3‑190230 A key issue: Slice-specific Security in roaming China Mobile pCR  
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesBT: What is the difference with the non-slicing scenario? This is not slice specific. ORANGE: have this as a key issue in the SBA study.
 		noted No    
S3‑190231 Clarification on securing the procedure of idle mode mobility from 5GS to EPS over N26 interface Huawei, Hisilicon CR Agreement
7.1.10Interworking
 		Yes
YesWe don’t need this change. Initial attach procedure is done where there is no N26. Ericsson commented that it didn't matter whether there was N26 or not.
 		not pursued No    
S3‑190232 Clarification on the Use of the SUPI in the Kamf Derivation Huawei, Hisilicon,Nokia,Nokia Shanghai Bell CR Agreement
7.1.2Key derivation
 		Yes
YesEricsson didn’t agree since this would affect Legal Interception requirements. The question is whether to remove the SUPI type part. ZTE didn’t agree with this change. Vodafone: the wording is confusing.
 		revised No S3‑190416  
S3‑190233 SCAS SEPP: Introduction and general approach Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑190512  
S3‑190234 Clarification on the allocation of 5G-GUTI Huawei, Hisilicon CR Agreement
7.1.14Privacy
 		Yes
Yes
 		revised No S3‑190397  
S3‑190235 SCAS NRF: Introduction and general approach Nokia, Nokia Shanghai Bell pCR Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		approved No    
S3‑190236 pCR to TR33.814 - Key issue for end-to-end LCS data security CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190237 New KI: SUPI privacy protection across different security domains Huawei, Hisilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesORANGE: why sending the SUPI to the slice? Huawei: according to SA2 several network functions can be deployed in the slice, so it is necessary in some cases to send the SUPI. Nokia: additional protection for SUPI? They are already protected. DT: we need a new mechanism to send the SUPI to third parties. ORANGE wasn't sure that SA2 could see the SUPI, and if that was the case SA3 should tell them not to do that. Alf (NTT-Docomo: SUPI shall not be available outside the operator's network. BT: struggling to see this slice specific.
 		noted No    
S3‑190238 Dynamic UP security policy control solution for URLLC Huawei, HiSilicon pCR  
8.13Study on security for 5G URLLC
Yes
YesVodafone: solution details need rewriting. Ericsson: PCF issue is not clear here.
 		noted No    
S3‑190239 New KI: Access token handling between network slices Huawei Technologies Sweden AB pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		revised No S3‑190318  
S3‑190240 Test Case: Mutual Authentication Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		noted No    
S3‑190241 Solution for NPN network access via PLMN Huawei, Hisilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesEricsson: why not use SA2's conclusion on this? There is no security problem here.
 		revised No S3‑190493  
S3‑190242 pCR to TR33.814 - Key issue for broadcast assistance data security CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190243 New KI: Isolation of multiple NAS connections Huawei, Hisilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesORANGE objected to this document.
 		noted No    
S3‑190244 Test Case: NF Discovery Service Authorization Nokia, Nokia Shanghai Bell pCR Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		noted No    
S3‑190245 New requirment for Authentication relay attack Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190246 pCR to TR33.814 - Solution of provisioning keys for broadcast assistant data protection CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190247 pCR to TR33.814 - Solution of ciphering algorithms CATT pCR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		not treated No    
S3‑190248 New key issue: Key revocation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesVodafone: more requirements and definitions are needed.For example, who rebokes the application keys. ORANGE repplied that it was the network who revoked the keys. Qualcomm proposed to add an editor's note to procceed with the work during the next meeting.
 		revised No S3‑190528  
S3‑190249 Protocol clarifications to solution 2 Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesVodafone: the third party application doesn’t seem represented. Ericsson: this is about the authentication procedure, bootstrapping, not about how the keys are used. Ericsson: this is purely used plane based. A copy of GBA making sure that it works in 5G. ORANGE: revocation of the keys in the UE needs to be clarified. It was agreed to add an editor's note stating the above.
 		revised No S3‑190529  
S3‑190250 Evaluation of solution 2 Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: key issues are still coming, having the evaluation is a bit premature. Qualcomm agreed.
 		noted No    
S3‑190251 New solution:Key revocation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: remove the evaluation. Vodafone: consequences are not described in detail.
 		revised No S3‑190530  
S3‑190252 New solution: Implicit Bootstrapping Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesNEC proposed to alter the order of some clauses. Ericsson: too early to decide the solution since there are still revocation aspects that need to be considered.
 		revised No S3‑190531  
S3‑190253 New solution: AKMA authentication via the control plane Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No    
S3‑190254 Corrections to RRC Inactive procedure.and RAN-based notification area update procedure. Ericsson CR Agreement
7.1.4AS security
 		Yes
YesHuawei didn’t agree with the new requirement, since this was implementation specific and not needed. NEC supported the Ericsson's view. Nokia: there is an impact on implementation, it has performance implications. They needed to check if this was fine with them.
 		revised No S3‑190429  
S3‑190255 EUTRA connected to 5GC: clause 6.6.2 Ericsson CR Agreement
7.1.4AS security
 		Yes
YesVodafone didn't see the purpose of the note.Just refer to 33.401. Nokia: ng-eNodeB specific topics are specified in 33.501, not 33.401. Vodafone admitted the above but preferred to have the note as a requirement. Ericsson replied that the requirement existed somewhere else. This was taken offline.
 		revised No S3‑190501  
S3‑190256 EUTRA connected to 5GC: clause 6.7.3 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑190427  
S3‑190257 EUTRA connected to 5GC: clause 6.7.4 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑190428  
S3‑190258 EUTRA connected to 5GC: clause 6.8.1 Ericsson CR Agreement
7.1.4AS security
 		Yes
YesNokia: There is no consistency with the key names. Don’t use KngRAN.
 		revised No S3‑190424  
S3‑190259 EUTRA connected to 5GC: clause 6.8.2 Ericsson CR Agreement
7.1.4AS security
 		Yes
YesThe NOTE was removed since it was adressed in other conitrbutions.Also other changes related with message names. Overlaps with 192.
 		revised No S3‑190425  
S3‑190260 EUTRA connected to 5GC: clause 6.9.2.1 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑190430  
S3‑190261 EUTRA connected to 5GC: clauses 6.9.2.3.1 and 6.9.2.3.2 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		merged No S3‑190426  
S3‑190262 EUTRA connected to 5GC: clauses 6.9.3 and 6.9.4 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑190431  
S3‑190263 EUTRA connected to 5GC: clause 6.9.5 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑190432  
S3‑190264 EUTRA connected to 5GC: clause 6.11 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No    
S3‑190265 Updates to Solution #3: Security solution for MO SMS at AMF re-allocation Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei: add an editor's note on why this assumption is made in the solution. Qualcomm supported this. Ericsson: this is an editor's note on existing text. Bring it with a contribution. Huawei commented that it was impacted by the new text.
 		revised No S3‑190480  
S3‑190266 Updates to Solution #5: Security solution for small data included in initial NAS signalling at mobility Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑190481  
S3‑190267 Potential new security impact in Rel-16 for the selected CIoT solutions in SA2 TR 23.724 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei didn’t see the need for having this in the TR. ORANGE agreed with Huawei.
 		noted No    
S3‑190268 Proposal for content to introduction clause Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei: refer to SA2 with regards to architecture. References are wrong.Clash with 194. Vodafone: no clash with 194, really. Vodafone and TIM agreed to have this in the introduction.
 		revised No S3‑190470  
S3‑190269 Proposal for content to clause 4 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei: reference SA2; it is also referring to things that SA2 hasn’t decided yet. Ericsson: SA2 concluded.
 		revised No S3‑190472  
S3‑190270 A new key issue for privacy protection of new parameters for CIoT included in NAS messages Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei: wait for SA2 to have the parameters that need to be privacy protected. ORANGE: remove requirements, keep the key issue, analyze parameters as they come.
 		revised No S3‑190476  
S3‑190271 Solution for privacy protection of new parameters for CIoT included in NAS messages Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190272 Solution for key separation based on slice authentication keys Ericsson pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesOverlapping with 204.
 		noted No    
S3‑190273 KI#2 in TR 33.809 – new requirement and solution for non-public networks Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesQualcomm was against this contribution. No other support was found.
 		noted No    
S3‑190274 KI#1 in TR 33.809 – a new NOTE for requirements Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No    
S3‑190275 KI#1 in TR 33.809 – new requirement and solution for UECapabilityInformation RRC message Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesThe requirement was agreed.The solution had to be discussed separately.
 		revised No S3‑190554  
S3‑190276 KI#1 in TR 33.809 – new requirement and solution for RRC Reject message Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesDocomo preferred 359. The requirement was removed.
 		noted No    
S3‑190277 KI#3 in TR 33.809 – updates to requriements and editorials Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190278 KI#3 in TR 33.809 – new solution for enriched measurement reports Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190279 KI#3 in TR 33.809 – conclusion on second requirement (reactive action) Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190280 EUTRA connected to 5GC: clause 8 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑190435  
S3‑190281 Clarification to AKA parameter derivation Ericsson CR Approval
7.1.5NAS security
 		Yes
YesNokia missed some text covering RES* and XRES*.It was proposed to add this during the next meeting.
 		agreed No    
S3‑190282 Multiple NAS connecions: mobility with horizontal KAMF derivation Ericsson CR Approval
7.1.5NAS security
 		Yes
Yes
 		merged No S3‑190556  
S3‑190283 Multiple active NAS connections in the same PLMN's serving network: common algorithm identifiers Ericsson CR Approval
7.1.5NAS security
 		Yes
YesQualcomm: how do you achieve this requirement? They didn't agree with the wording. It was revised to reword the sentence.
 		revised No S3‑190436  
S3‑190284 Clarification to the implementation requirement for the protectaion of the backhaul and sidehaul interfaces Ericsson CR Agreement
7.1.12NDS
 		Yes
Yes
 		agreed No    
S3‑190285 New key issue on the secure negotiation of the user plane integrity protection feature Ericsson pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		revised No S3‑190551  
S3‑190286 Update to KI#3 or KI#4 taking Dual Connectivity into considerations Ericsson pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		revised No S3‑190543  
S3‑190287 Evaluation to solution #1 and conclusion to key issue #3 Ericsson pCR Approval
8.13Study on security for 5G URLLC
Yes
YesHuawei: remove the conclusion.This was agreed.
 		revised No S3‑190547  
S3‑190288 Evaluation on solution #2 and conclusion to key issue #3 Ericsson pCR Approval
8.13Study on security for 5G URLLC
Yes
YesSame as the one above.
 		revised No S3‑190548  
S3‑190289 New key issue on UP security policy for the 5GLAN Group Ericsson pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesHuawei didn't agree with the example. The requirement was reworded to state "a" 5GLAN group instead of "the".
 		revised No S3‑190498  
S3‑190290 New security solution for handling UP security policy for a 5GLAN Group Ericsson pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		revised No S3‑190499  
S3‑190291 TR 33.819: new key issue on security and privacy aspects of service continuity and session continuity Ericsson pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesNokia: session and service continuity are requirements in SA2. This is a very vague requirement. Key issue is valid. NTT-Docomo: security threats need to be more concrete.
 		revised No S3‑190494  
S3‑190292 Skeleton for TR 33.846 on authentication enhancements Ericsson pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190293 Scope for the study on authentication enhancements (FS_AUTH_ENH) Ericsson pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190294 New KI: Leakage of long-term key Ericsson pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190295 New solution: EAP-AKA´ PFS Ericsson pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190296 Update on EAP-AKA´ PFS Ericsson pCR Information
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190297 Clarification to idle mode mobility from EPS to 5GS Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No    
S3‑190298 EDT correction – input "S" to calculation of HASHUE-data and HASHeNB-data Ericsson CR Agreement
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesEricsson considered that RAN2 had the responsibility for a solution and not SA3. Huawei disagreed. Ericsson: we don’t need to take a stand on how RAN will solve the issue. We can wait for them. Huawei replied that SA3 knew what RAN solution would be about, but it didn’t work when having multiple PDCP PDUs. Nokia: calculation at the MAC layer feasibility should be pondered by RAN2, not SA3. Let's ask them about this in an LS. Qualcomm supported involving RAN2. Docomo commented that SA3 may reconsider the requirement for having it at the MAC layer and make it application dependent. It was agreed to send an LS to RAN2 with several questions involving potential solutions to the multiple PDU issue.
 		not pursued No    
S3‑190299 EDT correction – length of HASHUE-data and HASHeNB-data Ericsson CR Agreement
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesQualcomm: solution dependent? We may have to revisit this based on the solution we settle down on. Ericsson clarified that this was sent through the RAN nodes, not transferred over the air. The sentence needed rewording so it was taken offline.
 		revised No S3‑190455  
S3‑190300 EDT correction – input to calculation of shortResumeMAC-I Ericsson CR Agreement
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		agreed No    
S3‑190301 EDT correction – clarification of NOTE about no-integrity protection for non-EDT data Ericsson CR Agreement
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesHuawei didn’t agree with the CR.Ericsson could come back once the solution was defined.
 		not pursued No    
S3‑190302 LS on EDT security Ericsson LS out Approval
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑190303 Key issue on linkability attack Huawei, Hisilicon pCR Approval
8.19Study on authentication enhancements in 5GS
 		Yes
Yes
 		not treated No    
S3‑190304 Update on Key issue #2.1 Huawei, Hisilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesORANGE: is this the right conclusion in sA2? This was confirmed.
 		approved No    
S3‑190305 Response LS on Authentication for UEs not Supporting NAS Lenovo (Beijing) Ltd LS out  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑190519  
S3‑190306 Solution for 5GC access from WLAN UEs that do not support NAS Motorola Mobility, Lenovo pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesDeutsche Telekom: we need to modify this according to our LS reply to SA2. ORANGE: SUCI is enough for 3GPP credentials.
 		merged No S3‑190507  
S3‑190307 Security Assurance Requirement and Test for authorization handling in the NF Huawei, HiSilicon draftCR Agreement
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		revised No S3‑190540  
S3‑190308 Solution for Key Issue #7: Key refreshing for protection of small data Lenovo, Motorla Mobility pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑190488  
S3‑190309 Solution for partial UP IP considering UE limitations Motorola Mobility, Lenovo pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
YesDeutsche Telekom: This is not the solution SA3 should go for.
 		noted No    
S3‑190310 SCAS: UDM-specific adaptations of security functional requirements and related test cases Huawei, Hisilicon pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		revised No S3‑190508  
S3‑190311 SCAS: AMF-specific adaptations of security functional requirements and related test cases Huawei, Hisilicon pCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
YesEricsson: interoperability testing is out of scope of SCAS. NEC pointed out that tdoc 099 was related to this discussion. 099 was discussed and then this document gone through. Test case one was scrapped out, related to interoperability. Test case two: the vice Chair commented that failure of integrity protection would fit in here. There didn’t seem to be a discussion so the vice chair proposed to take this document offline.
 		noted No    
S3‑190312 Security Assurance Requirements and Tests for the Security Functionalities Provided by UPF Huawei, Hisilicon pCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		noted No    
S3‑190313 Security Assurance Requirement and Test for NRF Huawei, Hisilicon pCR Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		noted No    
S3‑190314 New Key Issue: Subscription identifier exposure outside 3GPP network Ericsson India Private Limited pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesZTE: the requirement is not clear, it's also a generic one not related to cIoT. There is a requirement in 33.501 for the AMF already. Vodafone supported this. Ericsson: there is no requirement with the NIDD API involved.
 		noted No    
S3‑190315 Removing the test case on Kseaf handling Huawei, Hisilicon pCR Approval
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes
 		approved No    
S3‑190316 New solution - Battery efficient AKMA KPN pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑190317 Requirement and test cases for SMF Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		noted No    
S3‑190318 New KI: Access token handling between network slices Huawei, Hisilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		revised No S3‑190538 S3‑190239
S3‑190319 Key Issue on access to 5GC from a non-3GPP device over Wireline 5G Cable Access Network Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190320 Key Issue on NAS termination in TWIF Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesEricsson: no need to use NAS security here, you can rely on transport security. Add it to existing key issue 6. Nokia: we can just remove the requirements. This was agreed. ORANGE: generalise this since it refers to a key issue from the SA2 TR.
 		revised No S3‑190520  
S3‑190321 Editorial corrections in CAPIF TS Ericsson CR Approval
7.5.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑190322 Key Issue on SUCI format for legacy FN-RG devices that access 5G over wireline network Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑190522  
S3‑190323 Key Issue on Authorization of IPTV subsystem Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesEricsson: this is already addressed in 33.501 in clause 12. There is no normative work needed for this, note it.
 		noted No    
S3‑190324 Key Issue on security of TNGF mobility using EAP Reauthentication Protocol (ERP) Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190325 Key Issue on NAS termination for registered FN-RGs Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesHuawei: solution specific requirement.ORANGE proposed to keep it solution specific since it was the base for normative work.
 		revised No S3‑190523  
S3‑190326 New KI: Interworking between AKMA and GBA Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑190327 Allocating new 5G-GUTI during the MO service request procedure NEC Europe Ltd CR Approval
7.1.3Mobility
 		Yes
YesHuawei: check with CT1. Qualcomm: we should not mandate it, it's up to the network. Nokia agreed. Ericsson: we discussed this before and decided not to mandate it. Docomo proposed to change NOTE1 to clarify the "more frequently" bit.
 		revised No S3‑190420  
S3‑190328 Key Issue on security of the Tn interface between TNGFs Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesNokia: the scope of thi study is the Tn interface. ORANGE: generalise this since it refers to a SA2 key issue. SA2 conclusions needed to be checked offline.
 		noted No    
S3‑190329 Key Issue on access to 5GC from non-3GPP device over Trusted WLAN Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE: this has been considered in our LS to SA2. Huawei: non-3GPP device and non 5G capable device; What's the difference? We need to be consistent with the terminology in the future.
 		noted No    
S3‑190330 Conclusion for Key Issue #9 Ericsson pCR  
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: we changed some of the aspects related to this. We should finish the key issues before concluding the study. Huawei: SA2 also concluded this topic.
 		revised No S3‑190490  
S3‑190331 pCR to Solution #1 to include child SA creation for user plane data protection Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190332 FN-RG registration to 5GC Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑190506  
S3‑190333 Access to 5GC via Trusted WLAN for UEs w/o NAS support Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesTIM: this is pointing wrongly to annex B of 33.501. This type of networks are not mentioned in there. It was agreed to remove the reference to annex B.
 		revised No S3‑190507  
S3‑190334 5G-RG connecting to 5GC via Wireline Access (W-5GAN) Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑190524  
S3‑190335 5G-RG connecting to 5GC via NG-RAN Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑190525  
S3‑190336 Vertical - Key Issue on Authentication of a UE for Non-public network Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, CableLabs pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesORANGE: how is this different from Rel-15? There is no issue here. IDEMIA: How to protect non-3GPP credentials is not available for us. Huawei: there is no SA1 requirement for non-public networks having to use UICC. IDEMIA: it's up to us to decide. Vodafone: UICC are irrelevant, we talk about USIM in our specs. ORANGE: NPN are 5G networks, hence the UICC is needed. NEC was fine with this contribution. DT,ORANGE, TIM and Vodafone didn’t support this contribution. Qualcomm: NPN operators may or may not USIMs. ORANGE replied that this wasn’t part of the contribution and should be brought separately. Vodafone: with no USIM we will have problems to connect to the network. Nokia: we have a SA1 requirement that cannot be fulfilled by 33.501.
 		noted No    
S3‑190337 Vertical - Key Issue on credential storage for Non-public network Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑190338 Vertical - Requirements to Key Issue on Authentication of a UE for Non-public network Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, CableLabs pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesORANGE: no need to have these definitions in the potential security requirements clause. Gemalto also disagreed with this contributions. Vodafone wanted to remove note 1. Gemalto also disagreed since it implied that the the credentials were stored in the device. The Chair saw very strong support towards removing note one and very little possibility of having a compromise for this note. DT: closed access groups should strongly and properly authenticated, not as it appears in note 2. Nokia argued that the disagreement of this contribution endangered the future normative work, but ORANGE replied that the study didn’t depend entirely on this issue.
 		noted No    
S3‑190339 Vertical - solution on EAP authentication framework Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesORANGE didn’t agree with this contribution. Gemalto,TIM and IDEMIA supported ORANGE. It’s already covered in TS 33.501 in an informative annex. Nokia: then we should reword it in TS 33.501. Contribution supported by Samsung. Vodafone: the solution is not described well.
 		noted No    
S3‑190340 Vertical - solution on EAP-TLS Nokia, Nokia Shanghai Bell, CableLabs pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesVodafone: solution is not described well enough. ORANGE: this is more a requirement, not a solution. Why are we mandating TLS? No other options?
 		noted No    
S3‑190341 Vertical - solution on EAP-TTLS Nokia, Nokia Shanghai Bell, CableLabs pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesThe Chair argued that this study needed more offline discussions, probably conference calls. ORANGE replied that the study was not based on authentication only. Vodafone: we don’t need to specify the methods used.
 		noted No    
S3‑190342 Vertical - Conclusion on authentication Nokia, Nokia Shanghai Bell, CableLabs pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑190343 Vertical - Discussion of WID for 5GS Vertical_LAN_SEC Nokia, Nokia Shanghai Bell discussion Endorsement
7.6New Work Item proposals
 		Yes
YesNokia clarified that the document referred to Rel-16. Ericsson pointed out that if this was going for Rel-16 there was no such rush. Huawei, ORANGE commented that there was still time and the rush was not justified. Vodafone commented that the WID proposed was too general.
 		noted No    
S3‑190344 WID proposal for 5GS Vertical_LAN_SEC Nokia, Nokia Shanghai Bell WID new Agreement
7.6New Work Item proposals
 		Yes
Yes
 		noted No    
S3‑190345 Correction to clause 14.2.1 NEC Corporation CR Approval
7.1.16Others
 		Yes
Yes
 		agreed No    
S3‑190346 New KI on Privacy aspects for NPN NEC Corporation pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesORANGE: last requirement not in the scope of SA3. First requirement covered by the previous contribution. Nokia: second requirement is too strong formulated. The operator can decide whether they can apply privacy or not (e.g. depending on regulator rules). It was also commented that the second requirement was already covered in 33.501. The general agreement was that all requirements covered in TS 33.501 will not be covered here as well. No repetition of work.
 		noted No    
S3‑190347 New Solution on Privacy aspects for NPN NEC Corporation pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑190348 New Solution for Redundant data protection NEC Corporation pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		revised No S3‑190545  
S3‑190349 New KI on Supporting low latency during Re-attach procedure NEC Corporation pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		revised No S3‑190542  
S3‑190350 Solution to KI#9 Key separation for AKMA AFs NEC Corporation pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑190351 Updating key issue#3 for network detection of nearby fake base station NEC Corporation pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑190532  
S3‑190352 New solution for preventing UE from attaching to a false base station NEC Corporation pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190353 New solution for protecting the System Information Block NEC Corporation pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190354 Updating Access Token Response to include token expiration time and scope Nokia, Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
Yes
 		merged No S3‑190440  
S3‑190355 SN Id and SNN clarification Ericsson India Private Limited discussion Discussion
7.1.16Others
 		Yes
YesIt was agreed to do a CR for this (tdoc 441).
 		noted No    
S3‑190356 New WID on Security for NR Integrated Access and Backhaul Samsung WID new Approval
7.6New Work Item proposals
 		Yes
Yes
 		revised No S3‑190442  
S3‑190357 Security framework for the NR integrated access backhaul Samsung discussion Decision
7.6New Work Item proposals
 		Yes
YesSamsung clarified that the work in RAN was in normative phase. The purpose was to create a draftCR that would eventually become a CR to 33.501. Vodafone didn’t agree with this style of work and preferred to have a Study Item. Samsung commented that the time scales were too limited to have both SID and WID. The Chair proposed to have a Study that could last for two meetings and then a Work Item to be sent for approval to SA together with the necessary CRs in one go. This was accepted.
 		noted No    
S3‑190358 Correction on RRC states terminology usage Samsung CR  
7.1.4AS security
 		Yes
YesOverlapping with 0072, 258,259.
 		revised No S3‑190423  
S3‑190359 Requirement on security of unprotected unicast messages Samsung pCR  
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑190553  
S3‑190360 Solution on security of RRC Reject messages Samsung pCR  
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑190555  
S3‑190361 Requirement on security of unprotected unicast messages Samsung pCR  
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No    
S3‑190362 Solution for AS security during RRC Idle mode Samsung pCR  
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑190363 New WID on Enhancements for Security aspects of Common API Framework Samsung, China Telecom, China Unicom, Nokia WID new  
7.6New Work Item proposals
 		Yes
YesSamsung clarified that SA6 had finished their work and that this WID would only need a single CR to be brought in the next meeting. Vodafone: there is a clear single solution for this? No other solutions to be studied? NTT-Docomo: we don’t need studies for all the CRs we make.
 		revised No S3‑190461  
S3‑190364 P-CR for PARLOS evaluation clause SPRINT Corporation pCR Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑190365 Non-3GPP Access: Correcting Connection Identifier Samsung CR  
7.1.3Mobility
 		Yes
Yes
 		revised No S3‑190422  
S3‑190366 Key issue on Multiple and Separate credentials for PLMN and NPN network Samsung pCR  
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		revised No S3‑190495  
S3‑190367 Discussion paper on N9 firewall for inter-PLMN GTP-U filtering Nokia, Nokia Shanghai Bell discussion Endorsement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑190368 Protecting small data at idle mobility using the Registration Complete message Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEricsson: not aligned with SA2 procedure on data delivery. Qualcomm: SA2 is consulting CT1 on this issue. NEC: this issue needs to be discussed in SA2. Vodafone: this is a study. No point to discuss with SA2 until it is selected. The comment should be part of the evaluation of the solution. Huawei agreed, since this was part of the usual process performed in SA3. It was agreed to add an editor's note.
 		revised No S3‑190484  
S3‑190369 Proposed key issue on binding key to network identity for standalone non-public networks Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
YesORANGE: the security threat is not clear enough. Remove it with the requirements.
 		revised No S3‑190497  
S3‑190370 Proposed key issue on key hierarchy for non-public networks Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		revised No S3‑190496  
S3‑190371 Proposed solution on binding key to network identity for standalone non-public networks Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		noted No    
S3‑190372 Handling the non-3GPP security context at mobility on the 3GPP access Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
YesEricsson was fine with this proposal.
 		merged No S3‑190556  
S3‑190373 Discussion on the incoming SA2 on security aspects of UE Capability ID Qualcomm Incorporated discussion Discussion
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑190374 Draft response LS on the security aspects of UE Capability ID Qualcomm Incorporated LS out Approval
6.13GPP Working Groups
 		Yes
YesHuawei: The capbility to be ssent after AES.
 		revised No    
S3‑190375 Modifying AKA to provide freshness for the protection of SQN in the case of re-synchronisations Qualcomm Incorporated discussion Discussion
7.1.16Others
 		Yes
Yes
 		noted No    
S3‑190376 Adding MACS as an input parameter to the calculation of AK* to provide freshness Qualcomm Incorporated CR Agreement
7.1.16Others
 		Yes
YesAT&T supported this change. Apple:we should first investigate whether it is feasible in 5G, and then evaluate the effect and make corresponding enhancement. It was left open to verify what GSMA was doing on this topic.
 		not pursued No    
S3‑190377 Solution for PARLOS based on emergency call procedures Qualcomm Incorporated pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑190468  
S3‑190378 CR on NAS connection id for NAS MAC calculation Qualcomm Incorporated CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No    
S3‑190379 CR on clarification on N2 handover Qualcomm Incorporated CR Agreement
7.1.3Mobility
 		Yes
YesEricsson wasn't fully in line with this.It was taken offline.
 		revised No S3‑190421  
S3‑190380 CR - clarification on key handling in handover Qualcomm Incorporated CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No    
S3‑190381 Key Issue MITM attacks Qualcomm Incorporated pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑190382 Solution for small data at idle mode mobility Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: solution details are not really detailed. It was agreed to add an editor's note to add more details in the future.
 		revised No S3‑190483  
S3‑190383 SUPI Type clarification Qualcomm Incorporated CR Approval
7.1.14Privacy
 		Yes
YesGemalto: what happens if there are two files in the UICC? Which one do you compute? Qualcomm: question for CT1. I don’t know if there is a scenario with two files. We may have more types of SUPI. CT hasn’t decided to remove this yet. There was no agreement with this contribution.
 		not pursued No    
S3‑190384 Input encoding for ECIES protection schemes Qualcomm Incorporated CR Approval
7.1.14Privacy
 		Yes
YesVodafone: does this protect types? Qualcomm: no, just the subscription identifier part. IDEMIA: why isnt the CT4 referenced here? Qualcomm: it doesn’t apply to transport. This was taken offline. IDEMIA objected since this meant additional processing in the UICC.
 		revised No S3‑190557  
S3‑190385 pCR: Reusing KAUSF for AKMA Qualcomm Incorporated pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑190386 pCR: New KI: Efficient handling of PDCP discardTimer expiry on the UE Uplink Qualcomm Incorporated pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
YesHuawei: not security related. Apple agreed.
 		noted No    
S3‑190387 pCR: New KI: Ability to prioritize certain PDCP packets on the UE uplink Qualcomm Incorporated pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
YesHuawei: not related to security, this should go to RAN2. NTT-Docomo disagreed, this could lead to DoS attacks. Ericsson, Apple: more solution than key issue.
 		noted No    
S3‑190388 pCR: New KI: Integrity Algorithm independence Qualcomm Incorporated pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
YesApple: evaluation of solutions that we don’t have. Vodafone: this is putting the framework of the solution into plan. NEC: this is not a key issue. NCSC agreed with NEC and Apple. Vodafone proposed to have conference calls in order to discuss how to progress with the key issues.
 		noted No    
S3‑190389 P-CR for editors note in PARLOS manual roaming clause SPRINT Corporation pCR Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190390 PARLOS TR cover sheet for plenary presentation SPRINT Corporation TS or TR cover Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesVodafone: it seems to be really early-on for sending it for information. There are missing key issues. ORANGE: no evaluations, key issues without requirements,..this not ready for presentation for information. Sprint: we can mention these open key issues as outstanding issues. ORANGE: this is not 60% ready. BT: one region's regulatory issue should not affect all the handsets in the rest of the countries. I would like to see that in the evaluation.
 		noted No    
S3‑190391 Removal of editor’s note in solution #1 Lenovo, Motorola Mobility pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesEricsson didn't agree with the changes.No one agreed with the change so the document was noted.
 		noted No    
S3‑190392 draft SID for User Identities and Authentication Vodafone GmbH SID new Agreement
8.21New study item proposals
 		No
Yes
 		withdrawn Yes    
S3‑190393 New proposal on the length of password and other clarifications Huawei, Hisilicon CR Approval
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesDT didn’t agree with the last note (third change). NEC supported this change. NTT-Docomo: Anti-spoofing in internal networks is necessary.Huawei commented that SA3 didn’t do this for every network element. CableLabs didn't agree with the first change. NCSC suggested having longer simpler passwords was a better solution. BT wasn’t in favour of this change either. It was decided to drop the first change. BT: there are use cases in certain interfaces where we may want to allow this, for the note in the third change. BT was in favour of maintaing this. DT didn’t agree with the second change either.There were arguments on the 100 accounts so this was taken offline. BT wasn’t comfortable with having SA3 imposing limitations on the products.
 		revised No S3‑190503  
S3‑190394 LS on the need to update home network public key and key ID during Routing indicator update C1-190377 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesQualcomm had tdoc 400 related to this.
 		replied to No    
S3‑190395 LS on mandating 5G-GUTI allocation after network triggered service request C1-190380 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesHuawei proposed a CR in 397. Qualcomm proposed to respond afirmatively to this LS but didn't agree with the CR. Nokia: on the GUTI realocation we should be flexible.
 		replied to No    
S3‑190396 LS on securing warning messages in ePWS C1-190393 LS in  
6.13GPP Working Groups
 		Yes
YesVodafone considered a serious problem to have a possible mechanism that can shut down IoT devices. Sprint: the focus should be on the broadcast service and not on PWS. Nokia: we did PWS security before and didn’t reach a conclusion given the different regulations in different parts of the World. This kind of mechanism is application specific and I'm not sure what security capbility we can enforce here. NEC: IoT devices need an intelligence to distinguish the PWS message to shut down. What is the use case here? BT: Don’t mix PWS with IoT, shutdown commands would be dangerous. Ericsson: SA3's study had a different scope. We had a user behind the device and in here we have a new use case. Sprint: this use case is not defined as a service. This should come as a SA1 requirement. NTT-Docomo and NCSC agreed with this. Qualcomm: this seems to be more application layer specific. NTT-Docomo: make it very clear that using existing PWS mechanisms without application layer security would not be acceptable.
 		replied to No    
S3‑190397 Clarification on the allocation of 5G-GUTI Huawei, Hisilicon CR Agreement
7.1.14Privacy
 		Yes
YesQualcomm didn’t agree with this CR.A rewording was then proposed and for that reason the CR was revised. NEC: remove the last line and let CT1, CT4 decide.
 		revised No S3‑190415 S3‑190234
S3‑190398 Comment on S3-190116 Huawei, Hisilicon discussion Discussion
7.1.14Privacy
 		Yes
Yes
 		noted No    
S3‑190399 Discussion on providing AS security during RRC connection establishment to protect slice identity NEC Corporation discussion Agreement
7.6New Work Item proposals
 		Yes
Yes
 		noted No    
S3‑190400 Discussion on incoming CT1 LS on update of Routing Indicator (S3-190394) Qualcomm Incorporated discussion Endorsement
7.1.15Incoming and outgoing Lses
 		Yes
YesVodafone: the mechanism of the public key update is out of standardization scope and it should be kept this way.BT, IDEMIA, CableLabs and ORANGE supported this.
 		noted No    
S3‑190401 [Late contribution] Discussion on dealing with Routing ID update Lses NEC Corporation discussion discussion
7.1.15Incoming and outgoing Lses
 		Yes
YesQualcomm and Gemalto commented that there was an existing mechanism for what SA2 was proposing. NEC replied that they were not arguing that but wanted to put it down in words and send it to them. IDEMIA: the proof of receipt needs to go through the UDM but I'm not sure that this is the case in our spec. Vodafone: OTA is transport independent protocol. In steering of roaming, OTA was one of the possible protocols to be used there. Ericsson: we don’t need to send an LS saying that OTA is fine from the security point of view. At&T considered that the LS wasn’t necessary since they wouldn't do anything with it. Vodafone: the attached CR contains OTA as a path to and from.
 		noted No    
S3‑190402 128-EIA3 maximum message size ETSI SAGE LS in discussion
6.3ETSI SAGE
 		Yes
Yes
 		noted No    
S3‑190403 Expectations and requirements for 256 bit algorithms ETSI SAGE LS in discussion
6.3ETSI SAGE
 		Yes
Yes
 		replied to No    
S3‑190404 Interception of voice services over new radio in a 5GS environment S3i190057 LS in discussion
7.1.15Incoming and outgoing Lses
 		Yes
YesVodafone asked if a study could cover this work. BT replied that a study could be done. The Chair commented that a study would be easier to manage. Vodafone, AT&T, Deutsche Telekom and others supported having a study item, so BT would bring it for the next meeting in May.
 		postponed No    
S3‑190405 Reply to: LS on the security aspects of UE Capability ID Qualcomm LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑190406 Reply to: LS on securing warning messages in ePWS Ericsson LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑190407 Reply to: Expectations and requirements for 256 bit algorithms Vodafone LS out approval
6.3ETSI SAGE
 		Yes
Yes
 		approved No    
S3‑190408 User Plane Security for 5GC Roaming Vodafone CR Agreement
6.4GSMA
 		Yes
Yes
 		agreed No    
S3‑190409 LS on User Plane Security for 5GC Roaming BT LS out Agreement
6.4GSMA
 		Yes
Yes
 		approved No    
S3‑190410 Reply to: LS on new 5G-GUTI allocation Ericsson LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		approved No    
S3‑190411 Reply to: LS on Nudr Sensitive Data Protection Ericsson LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		approved No    
S3‑190412 Reply to: LS on Security Result Exchange Between NG-RAN and SMF in DC Nokia LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		approved No    
S3‑190413 Reply to: LS on the need to update home network public key and key ID during Routing indicator update Vodafone LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		approved No    
S3‑190414 Reply to: LS on mandating 5G-GUTI allocation after network triggered service request Huawei LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		approved No    
S3‑190415 Clarification on the allocation of 5G-GUTI Huawei, Hisilicon,Nokia,Interdigital CR Agreement
7.1.14Privacy
 		Yes
Yes
 		agreed No   S3‑190397
S3‑190416 Clarification on the Use of the SUPI in the Kamf Derivation Huawei, Hisilicon,Nokia,Nokia Shanghai Bell,Qualcomm,Vodafone CR Agreement
7.1.2Key derivation
 		Yes
Yes
 		agreed No   S3‑190232
S3‑190417 LS Response on Enforcement of maximum supported data rate for integrity protection S2-1812600 LS in discussion
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑190418 Reply LS on Interim conclusions for SA2 study on Radio Capabilities Signalling Optimisations (FS_RACS) S2-1901303 LS in discussion
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑190419 LS Response on Security Result Exchange Between NG-RAN and SMF in DC S2-1901386 LS in discussion
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑190420 Allocating new 5G-GUTI during the MO service request procedure NEC Europe Ltd CR Approval
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑190327
S3‑190421 CR on clarification on N2 handover Qualcomm Incorporated CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑190379
S3‑190422 Non-3GPP Access: Correcting Connection Identifier Samsung,ZTE CR -
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑190365
S3‑190423 Correction on RRC states terminology usage Samsung,Huawei CR -
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190358
S3‑190424 EUTRA connected to 5GC: clause 6.8.1 Ericsson CR Agreement
7.1.4AS security
 		Yes
YesRevised to include all clauses affected in the cover page.
 		agreed No   S3‑190258
S3‑190425 EUTRA connected to 5GC: clause 6.8.2 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190259
S3‑190426 Corrections on ng-ran keys Huawei, HiSilicon,Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190192
S3‑190427 EUTRA connected to 5GC: clause 6.7.3 Ericsson CR Agreement
7.1.4AS security
 		Yes
YesRevised to address issues on the cover.
 		agreed No   S3‑190256
S3‑190428 EUTRA connected to 5GC: clause 6.7.4 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190257
S3‑190429 Corrections to RRC Inactive procedure.and RAN-based notification area update procedure. Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190254
S3‑190430 EUTRA connected to 5GC: clause 6.9.2.1 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190260
S3‑190431 EUTRA connected to 5GC: clauses 6.9.3 and 6.9.4 Ericsson CR Agreement
7.1.4AS security
 		Yes
YesRevised to fix mistakes on the cover page.
 		agreed No   S3‑190262
S3‑190432 EUTRA connected to 5GC: clause 6.9.5 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190263
S3‑190433 Clarification for section 6.10.2.1 Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
YesIncorporating changes suggested by Ericsson.
 		agreed No   S3‑190174
S3‑190434 Clarification for UP security in option4&7 Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190175
S3‑190435 EUTRA connected to 5GC: clause 8 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190280
S3‑190436 Multiple active NAS connections in the same PLMN's serving network: common algorithm identifiers Ericsson CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑190283
S3‑190437 claification on interworking case Huawei, Hisilicon CR Approval
7.1.10Interworking
 		Yes
Yes
 		agreed No   S3‑190176
S3‑190438 NAS counter clarification on interworking Huawei, Hisilicon CR Agreement
7.1.10Interworking
 		Yes
YesFirst change is gone.
 		agreed No   S3‑190224
S3‑190439 Editorials and minor clarifications for clause 13.2 Ericsson CR Agreement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		agreed No   S3‑190090
S3‑190440 Clarification on service authorization and token verification Huawei, Hisilicon, Nokia CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑190229
S3‑190441 SN Id and SNN clarification Ericsson CR discussion
7.1.16Others
 		Yes
Yes
 		agreed No    
S3‑190442 New WID on Security for NR Integrated Access and Backhaul Samsung WID new Agreement
7.6New Work Item proposals
 		Yes
YesIt was agreed to reformulate this as a SID.
 		revised No S3‑190460 S3‑190356
S3‑190443 a skeleton of security aspects of 5G SRVCC to UTRAN Huawei, Hisilicon, China Unicom draftCR Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesThe annex was retitled.
 		approved No   S3‑190167
S3‑190444 [33.180] R14 Annex D.3.5.2 XSD correction (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
YesFixng issues on the cover page.
 		agreed No   S3‑190050
S3‑190445 [33.180] R15 Annex D.3.5.2 XSD correction (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑190051
S3‑190446 [33.180] R14 IdMS interface security (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑190053
S3‑190447 [33.180] R15 IdMS interface security (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑190054
S3‑190448 [33.180] R14 InK clarifications Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
YesRevised to address issues on the cover page.
 		agreed No   S3‑190058
S3‑190449 [33.180] R15 InK clarifications (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
YesIssues on the cover page.
 		agreed No   S3‑190059
S3‑190450 [33.180] R14 MCX identity clarifications Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑190060
S3‑190451 [33.180] R15 MCX identity clarifications (mirror) Motorola Solutions Germany CR Agreement
7.5.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑190061
S3‑190452 Reply to: LS on OAuth authorization flows supported for Northbound APIs Nokia LS out approval
7.5.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑190453 Reply to: LS on EAS-C&U support Vodafone LS out approval
7.5.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑190454 LS to RAN2/3 on EDT data integrity protection Huawei, Hisilicon LS out Approval
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		approved No   S3‑190076
S3‑190455 EDT correction – length of HASHUE-data and HASHeNB-data Ericsson CR Agreement
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		agreed No   S3‑190299
S3‑190456 Protection from buffer overflows Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑190093
S3‑190457 Protection from buffer overflows Ericsson CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No    
S3‑190458 Editorial corrections in TS 33.117 R15 Nokia, Nokia Shanghai Bell CR Approval
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑190191
S3‑190459 Editorial corrections Nokia CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No    
S3‑190460 New SID on Security for NR Integrated Access and Backhaul Samsung SID new Agreement
7.6New Work Item proposals
 		Yes
YesQualcomm proposed to start working on pCRs in the ad-hoc before the study was approved in SA.
 		agreed No   S3‑190442
S3‑190461 New WID on Enhancements for Security aspects of Common API Framework Samsung, China Telecom, China Unicom, Nokia WID new -
7.6New Work Item proposals
 		Yes
Yes
 		agreed No   S3‑190363
S3‑190462 New SID on Security Aspects of 3GPP support for Advanced V2X Services LG Electronics SID new Agreement
8.21New study item proposals
 		Yes
Yes
 		agreed No   S3‑190143
S3‑190463 Reply LS on PC5 unicast and groupcast security protection LG Electronics LS out Approval
8.21New study item proposals
 		Yes
Yes
 		approved No   S3‑190144
S3‑190464 Update to Study Item Description FS_SBA_Sec: Enhanced-SBA aspects Telekom Deutschland GmbH SID revised Agreement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑190117
S3‑190465 EDT UP IP handling of multiple PDCP PDUs Huawei, Hisilicon CR Approval
7.5.10Security Aspects of Narrowband IOT (CIoT)
 		No
Yes
 		withdrawn Yes    
S3‑190466 Editorial pCR for PARLOS TR 33.815 LG Electronics pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190145
S3‑190467 Draft TR 33.815 Sprint draft TR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190468 Solution for PARLOS based on emergency call procedures Qualcomm Incorporated pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190377
S3‑190469 P-CR for PARLOS evaluation clause SPRINT Corporation pCR Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑190470 Proposal for content to introduction clause Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190268
S3‑190471 Draft TR 33.861 Ericsson draft TR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190472 Proposal for content to clause 4 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190269
S3‑190473 Clarifications CIOT security assumptions Huawei, HiSilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190194
S3‑190474 Address EN in Key Issue 4 of Definition of Misbehaving UE Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190172
S3‑190475 New Key Issue for NAS based Redirection between Core Networks Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190173
S3‑190476 A new key issue for privacy protection of new parameters for CIoT included in NAS messages Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190270
S3‑190477 A new KI on NSSAI protection Huawei, HiSilicon,NEC,Interdigital pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
YesNokia: there are implications on the study item if we procceed with this. ORANGE clarified that NEC had a study item on this (tdoc 128) and we had agreed on adding the objectives into a key issue here. ORANGE wasn't fine with the requirements since they were out of scope of the study item. MCC commented that it seemed a bit strange to enumerate objectives and open issues for Rel-16 in the key issue details.The format of these key issue details was to be revised. Qualcomm: last requirement doesn't make sense. It was agreed to remove it.
 		revised No S3‑190536 S3‑190203
S3‑190478 Clarification on the UE selecting the 4G or 5G security protection method Huawei, Hisilicon CR Approval
7.1.16Others
 		Yes
Yes
 		agreed No   S3‑190178
S3‑190479 Evaluation text for solution #2 NEC Corporation pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190208
S3‑190480 Updates to Solution #3: Security solution for MO SMS at AMF re-allocation Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190265
S3‑190481 Updates to Solution #5: Security solution for small data included in initial NAS signalling at mobility Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190266
S3‑190482 Details of protecting gNB from RRC DoS attack Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190074
S3‑190483 Solution for small data at idle mode mobility Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190382
S3‑190484 Protecting small data at idle mobility using the Registration Complete message Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190368
S3‑190485 New Solution Security-Property-Group-based Mitigation for DDoS Attack Triggered by Malicious Applications on the UE Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190171
S3‑190486 Solution for DDoS attack mitigation in CIoT Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190187
S3‑190487 Output of SCAS offline session Deutsche Telekom report Information
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		noted No    
S3‑190488 Solution for Key Issue #7: Key refreshing for protection of small data Lenovo, Motorla Mobility pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190308
S3‑190489 New Conclusion for Small Data Transfer via NAS Signaling Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190170
S3‑190490 Conclusion for Key Issue #9 Ericsson pCR -
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190330
S3‑190491 Cover sheet TR 33.861 Ericsson TS or TR cover Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesThe TR will be sent for information.
 		approved No    
S3‑190492 Draft TR 33.819 Nokia draft TR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No    
S3‑190493 Solution for NPN network access via PLMN Huawei, Hisilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑190241
S3‑190494 TR 33.819: new key issue on security and privacy aspects of service continuity and session continuity Ericsson pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑190291
S3‑190495 Key issue on Multiple and Separate credentials for PLMN and NPN network Samsung pCR -
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑190366
S3‑190496 Proposed key issue on key hierarchy for non-public networks Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑190370
S3‑190497 Proposed key issue on binding key to network identity for standalone non-public networks Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑190369
S3‑190498 New key issue on UP security policy for the 5GLAN Group Ericsson pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑190289
S3‑190499 New security solution for handling UP security policy for a 5GLAN Group Ericsson pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services
 		Yes
Yes
 		approved No   S3‑190290
S3‑190500 LS on naming issues with SUPI Vodafone LS out Approval
7.1.2Key derivation
 		No
Yes
 		withdrawn Yes    
S3‑190501 EUTRA connected to 5GC: clause 6.6.2 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑190255
S3‑190502 LS on clarification on UE trace definition Nokia LS out Approval
7.1.8Primary authentication
 		Yes
Yes
 		approved No    
S3‑190503 New proposal on the length of password and other clarifications Huawei, Hisilicon CR Approval
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑190393
S3‑190504 New proposal on the length of password and other clarification Huawei CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No    
S3‑190505 New proposal on the length of password and other clarification Huawei CR Agreement
7.5.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No    
S3‑190506 FN-RG registration to 5GC Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesAdding an editor's note.
 		approved No   S3‑190332
S3‑190507 Solution for 5GC access from WLAN UEs that do not support NAS Nokia, Lenovo pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190333
S3‑190508 SCAS: UDM-specific adaptations of security functional requirements and related test cases Huawei, Hisilicon pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No   S3‑190310
S3‑190509 Draft TS 33.514 NEC draft TS Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No    
S3‑190510 Draft TS 33.512 Deutsche Telekom draft TS Approval
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
Yes
 		approved No    
S3‑190511 New Test Case: Separation of cryptographic storage within the SEPP Telekom Deutschland GmbH pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑190120
S3‑190512 SCAS SEPP: Introduction and general approach Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑190233
S3‑190513 Draft TS 33.518 Nokia draft TS Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		approved No    
S3‑190514 Authorization on northbound APIs ZTE Corporation pCR Approval
7.2.9Network Exposure Function (NEF) (TS 33.519)
 		Yes
Yes
 		approved No   S3‑190154
S3‑190515 Draft 33.517 Nokia draft TS Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No    
S3‑190516 Draft TS 33.519 ZTE draft TS Approval
7.2.9Network Exposure Function (NEF) (TS 33.519)
 		Yes
Yes
 		approved No    
S3‑190517 Update to clause 4 to add KDF negotiation rationale NEC Corporation, Huawei, Hisilicon pCR Approval
8.10Study of KDF negotiation for 5G System Security
 		Yes
YesThe purpose of the study was argued. The Chair proposed to have conference calls before the next meeting given the disagreement between the companies. Huawei proposed to close the study and move forward. NTT-Docomo commented that this was an old topic and to avoid having it coming back at least a rational should be written.
 		noted No   S3‑190212
S3‑190518 Reply-LS on FN-RG authentication and related questions Ericsson LS out Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190081
S3‑190519 Response LS on Authentication for UEs not Supporting NAS Lenovo (Beijing) Ltd LS out -
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190305
S3‑190520 Key Issue on NAS termination in TWIF Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190320
S3‑190521 Draft TR 33.807 Huawei draft TR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑190522 Key Issue on SUCI format for legacy FN-RG devices that access 5G over wireline network Nokia, Ericsson pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190322
S3‑190523 Key Issue on NAS termination for registered FN-RGs Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190325
S3‑190524 5G-RG connecting to 5GC via Wireline Access (W-5GAN) Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190334
S3‑190525 5G-RG connecting to 5GC via NG-RAN Nokia, Nokia Shanghai Bell pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑190335
S3‑190526 Draft TR 33.835 China Mobile draft TR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No    
S3‑190527 Roaming key issue for AKMA Huawei, HiSilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
No
Yes
 		withdrawn Yes    
S3‑190528 New key issue: Key revocation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑190248
S3‑190529 Protocol clarifications to solution 2 Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑190249
S3‑190530 New solution:Key revocation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑190251
S3‑190531 New solution: Implicit Bootstrapping Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑190252
S3‑190532 Updating key issue#3 for network detection of nearby fake base station NEC Corporation pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No   S3‑190351
S3‑190533 Solution for Slice Specific secondary authentication Nokia, Nokia Shangahi Bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No   S3‑190133
S3‑190534 A solution to slice authentication Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No   S3‑190202
S3‑190535 Security threats and requirement for KI #4 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No   S3‑190206
S3‑190536 A new KI on NSSAI protection Huawei, HiSilicon,NEC,Interdigital pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No   S3‑190477
S3‑190537 A solution to security features for NSaaS Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No   S3‑190205
S3‑190538 New KI: Access token handling between network slices Huawei, Hisilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No   S3‑190318
S3‑190539 Draft TR 33.813 Nokia draft TR Approval
8.11Study on Security aspects of Enhancement of Network Slicing
 		Yes
Yes
 		approved No    
S3‑190540 Security Assurance Requirement and Test for authorization handling in the NF Huawei, HiSilicon draftCR Agreement
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No   S3‑190307
S3‑190541 Key issue for acceleration of AKA procedure for low latency ZTE Corporation pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		approved No   S3‑190157
S3‑190542 New KI on Supporting low latency during Re-attach procedure NEC Corporation pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		approved No   S3‑190349
S3‑190543 Update to KI#3 or KI#4 taking Dual Connectivity into considerations Ericsson pCR Approval
8.13Study on security for 5G URLLC
Yes
YesLast paragraph removed as proposed by Huawei.
 		approved No   S3‑190286
S3‑190544 Draft TR 33.825 Huawei draft TR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		approved No    
S3‑190545 New Solution for Redundant data protection NEC Corporation,Huawei pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		approved No   S3‑190348
S3‑190546 URLLC solution for Key Issue 3 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC
Yes
YesAdding two editor's notes.
 		approved No   S3‑190200
S3‑190547 Evaluation to solution #1 and conclusion to key issue #3 Ericsson pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		approved No   S3‑190287
S3‑190548 Evaluation on solution #2 and conclusion to key issue #3 Ericsson pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		approved No   S3‑190288
S3‑190549 URLLC solution for N3 tunnel redundancy Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC
Yes
Yes
 		approved No   S3‑190198
S3‑190550 draft TR 33.853 Vodafone draft TR Approval
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		approved No    
S3‑190551 New key issue on the secure negotiation of the user plane integrity protection feature Ericsson pCR Approval
8.17Study on User Plane Integrity Protection
 		Yes
Yes
 		approved No   S3‑190285
S3‑190552 Draft TR 33.809 Apple draft TR Agreement
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No    
S3‑190553 Requirement on security of unprotected unicast messages Samsung pCR -
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No   S3‑190359
S3‑190554 KI#1 in TR 33.809 – new requirement and solution for UECapabilityInformation RRC message Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No   S3‑190275
S3‑190555 Solution on security of RRC Reject messages Samsung pCR -
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No   S3‑190360
S3‑190556 key update in multi-NAS scenario Huawei, Hisilicon,Qualcomm,Ericsson CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑190177
S3‑190557 Input encoding for ECIES protection schemes Qualcomm Incorporated,IDEMIA,Gemalto CR Approval
7.1.14Privacy
 		Yes
Yes
 		agreed No   S3‑190384
S3‑190558 Solution for using established keys for AKMA NEC Corporation pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		approved No   S3‑190214
S3‑190559 LS on PLMN-ID verification Deutsche Telekom LS out Approval
7.1.13.1Interconnect (SEPP related)
 		No
YesA conference call was setup to discuss the LS. This was sent for email approval: Friday 8th available,Tuesday 12th ,Wednesday 13th final version available.
 		left for email approval No    
S3‑190560 Draft agenda SA3_94 AdHoc WG Vice Chair (Qualcomm) discussion Endorsement
11Any Other Business
 		Yes
Yes
 		endorsed No    
S3‑190561 draftCR General aspects in TS 33.117 Nokia draftCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No    
S3‑190562 Draft TR 33.814 CATT draft TR Approval
8.12Study on Security of the enhancement to the 5GC location services
 		Yes
Yes
 		approved No    
S3‑190563 Work Plan input from Rapporteurs MCC other -
9.2Rapporteur input on status of WID or SID
 		Yes
Yes
 		noted No   S3‑190005