Tdoc List

2018-08-27 15:16

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑182100 Agenda WG Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No    
S3‑182101 Report from last SA3 meeting/s MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
Yes
 		withdrawn Yes    
S3‑182102 SA3 Work Plan MCC Work Plan  
9.1Review of work plan
 		Yes
Yes
 		noted No    
S3‑182103 Report from last SA meeting WG Chairman report  
4.2Report from SA Plenary
 		Yes
Yes
 		noted No    
S3‑182104 SA3 meeting calendar MCC other  
10Future Meeting Dates and Venues
 		Yes
Yes
 		revised No S3‑182698  
S3‑182105 Work Plan input from Rapporteurs MCC other  
9.2Rapporteur input on status of WID or SID
 		Yes
Yes
 		revised No S3‑182699  
S3‑182106 TCG progress report InterDigital, Inc. report Information
6.6TCG
 		Yes
Yes1. TCG – Highlights • New/modified work working group CyRes – Cyber Resistance WG. This workgroup intends to develop new technologies, promote existing best-practices, and coordinate efforts in other groups inside and outside TCG, to improve the cyber-resiliency of future platforms. The CyRes WG will focus on: 1. Protection for code and configuration information that determine the platform capabilities. 2. Detection mechanisms for malware and deprecated or corrupted configuration data or code. 3. Recovery capabilities that can reliably patch both code and configuration in a selected device, and hence recover the device. • Publication of new or revised deliverables (incremental changes from the status reported at SA3#91) o TCG TMS Use Cases v2 – delayed due to GDPR compliance review, to be published September 2018 o TCG SNMP MIB for TPM-based Attestation – public review July 2018 o TCG PC Client Platform Firmware Profile – public review July 2018 o TCG Storage Interface Interactions (SIIS) – public review May 2018 o TCG SNMP MIB for TPM-based Attestation – public review May 2018 o TCG Device Identifier Composition Engine – published March 2018 2. Meetings TCG Members Meeting in Lisbon, PT – 15-18 October 2018 TCG Members Meeting in TBD location – February 2019 MPWG meets every Thursday at 10-11 ET TMS WG meets every Monday and Friday at 12-13 ET CyRes WG meets every Wednesday at 11-12:30 ET
 		noted No    
S3‑182107 [MCSec] 33180 R14. Examples of MC service ID shall be URI Airbus DS SLC CR  
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑182543  
S3‑182108 [MCSec] 33180 R15. Examples of MC service ID shall be URI Airbus DS SLC CR  
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑182544  
S3‑182109 New KI proposal for TR 33.861 on CIoT security InterDigital, Inc. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182110 [MCSec] 33180 R14. Clarification for MIKEY-SAKKE values Airbus DS SLC CR  
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
YesAlex (BT) commented that adding changes to editor's notes was not a valid procedure for a frozen spec, it was better to wait.
 		revised No S3‑182545  
S3‑182111 [MCSec] 33180 R15. Clarification for MIKEY-SAKKE values Airbus DS SLC CR  
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑182546  
S3‑182112 [MCSec] 33180 R15. Clarification for MIKEY-SAKKE values Airbus DS SLC CR  
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		No
Yes
 		withdrawn Yes    
S3‑182113 New KI proposal for TR 33.861 on CIoT security InterDigital, Inc. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182114 New KI proposal for TR 33.861 on CIoT security InterDigital, Inc. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182115 New KI proposal for TR 33.861 on CIoT security InterDigital, Inc. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182116 New KI proposal for TR 33.861 on CIoT security InterDigital, Inc. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182117 New KI proposal for TR 33.861 on CIoT security InterDigital, Inc. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182118 Use of SCEF anchored non-IP PDN Connections with BEST Convida Wireless, InterDigital, Inc. discussion Agreement
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑182119 Adding BEST Support for non-IP PDN Connections that Terminate at the SCEF Convida Wireless, InterDigital, Inc. CR Approval
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182626  
S3‑182120 [Draft] LS on Specification of the EAS-C/U interfaces for BEST Convida Wireless, InterDigital, Inc. LS out Agreement
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182674  
S3‑182121 Question on 5G network slices GSMA SIM LS in  
6.4GSMA
 		Yes
Yes
 		replied to No    
S3‑182122 Reply LS on GSMA question on 5G network slices S2-187599 LS in  
6.4GSMA
 		Yes
Yes
 		noted No    
S3‑182123 LS Out for 5G slices roaming S3i180376 LS in  
6.4GSMA
 		Yes
Yes
 		noted No    
S3‑182124 Statement on urgency of alignment of ETSI SSP with 3GPP release 15 GSMA LS in  
6.4GSMA
 		Yes
Yes
 		noted No    
S3‑182125 Reply LS on initial NAS message protection C1-183727 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesThis LS was already replied in the previous meeting.
 		withdrawn Yes    
S3‑182126 Reply LS on initial NAS message protection S2-187505 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182127 LS on [Temporary group call – user regroup] and [Temporary group – broadcast group call] C1-184907 LS in  
7.3eMCSec R16 security (MCXSec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑182128 Provision of ngKSI to UE at EAP-Request/AKA'-Challenge C1-184942 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182129 Reply LS on AUSF/UDM instance selection and SUCI parameters C4-184576 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑182130 Response to “Reply LS on AUSF/UDM instance selection and SUCI parameters” C6-180361 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑182131 Reply LS to “LS on AUSF/UDM instance selection and SUCI parameters” S2-186257 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑182132 LS OUT on TLS and inter PLMN routing C4-184612 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑182133 LS OUT on TLS and inter PLMN routing C4-185493 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182134 LS on Nausf_SoRProtection service C4-185319 LS in  
7.4.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑182135 Reply LS on avoiding race condition in 5G AKA C4-185320 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑182136 LS OUT on OAuth 2.0 C4-185505 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182137 Reply LS on SoR mechanism C6-180295 LS in  
7.4.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑182138 Reply-LS on new work item "X.5Gsec-q" ETSI TC CYBER LS in  
6.8TC-CYBER
 		Yes
YesColin (BT): if they mention 5G we shouldn't duplicate work that is being done in 3GPP as well.
 		replied to No    
S3‑182139 LSout to various organisations on usage of NFV Specifications ETSI ISG NFV LS in  
6.9ETSI NFV security
 		Yes
Yes
 		noted No    
S3‑182140 Reply LS to RAN2 on Bluetooth/WLAN measurement collection in MDT S5-183626 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑182141 Reply LS on Bluetooth/WLAN measurement collection in MDT R2-1808793 LS in  
6.13GPP Working Groups
 		Yes
YesChina Mobile had a contribution related to this: tdoc 450.
 		replied to No    
S3‑182142 Security related agreements on Early Data Transmission R2-1808869 LS in  
7.4.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑182143 Reply LS on Security aspects of supporting LTE connected to 5GC R2-1809162 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182144 LS on inactive security R2-1809177 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182145 LS on UE identity for PO calculation R2-1810941 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182146 LS on security requirements for RRC connection release R2-1810960 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182147 LS on connection re-establishment security R2-1810965 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182148 LS on EDT procedures and AS NAS interaction (R2-1712077) R3-183574 LS in  
7.4.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑182149 Reply LS on new BEST Service S2-187226 LS in  
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑182150 LS on security handling when deploying UDSF S2-187506 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		replied to No    
S3‑182151 Reply LS on clarification on Restricted Operator Services S2-181407 LS in  
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		postponed No    
S3‑182152 LS on devices behind 5G-RG accessing the 5GC S3i180377 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
 		postponed No    
S3‑182153 Reply LS on CAPIF4xMB S6-180727 LS in  
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑182154 Reply LS on CAPIF4xMB S6-180944 LS in  
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑182155 Reply LS to “5G for Industrial Communication” SP-180608 LS in  
6.10Other Groups
 		Yes
Yes
 		noted No    
S3‑182156 LS on Guidance on Way Forward for Steering of Roaming SP-180621 LS in  
7.4.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑182157 UE capability related to integrity protection of DRBs R2-1804056 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesThis LS was treated already in the previous meeting.
 		withdrawn Yes    
S3‑182158 New KI proposal for TR 33.807 on security of the Wireless and Wireline Convergence for the 5G system architecture InterDigital, Inc. 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
 		not treated No    
S3‑182159 LS/r on revised Recommendation ITU-T Q.850 (reply to 3GPP TSG SA3 - C3-183507) ITU-T SG11 LS in  
6.10Other Groups
 		Yes
YesThis LS was intended for CT3.
 		noted No    
S3‑182160 Reply LS on temporary group regroup procedures S6-181287 LS in  
7.3eMCSec R16 security (MCXSec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑182161 LS on use of ITS dedicated spectrum within V2X UE S6-181288 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑182162 Reply LS on CAPIF specification work in SA3 S6-181290 LS in  
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑182163 LS on application layer support for V2X services S6-181291 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑182164 Protection of the N4 Interface Juniper Networks, Deutsche Telecom AG CR  
7.1.12NDS
 		Yes
YesEricsson: Do we need to specify separately the security for every core network/RAN interface? We should do it in a more generic way. ORANGE: this is in line with what SA2 is doing. It was agreed to create a new CR to do such generalization.
 		not pursued No    
S3‑182165 Protection of the N9 Interface Juniper Networks, Deutsche Telecom AG CR  
7.1.12NDS
 		Yes
Yes
 		not pursued No    
S3‑182166 Discussion on the Scope and Future Use of the NDS IP and AF Specifications Juniper Networks discussion  
7.4.3Network Domain Security (NDS)
 		Yes
Yes
 		noted No    
S3‑182167 Update NDS/IP scope with application layer crypto profiles Juniper Networks CR  
7.4.3Network Domain Security (NDS)
 		Yes
Yes
 		revised No S3‑182606  
S3‑182168 Update NDS/IP scope with application layer crypto profiles Juniper Networks CR  
7.4.3Network Domain Security (NDS)
 		Yes
Yes
 		not pursued No    
S3‑182169 Clarify NDS/AF intro regarding crypto profiles Juniper Networks CR  
7.4.3Network Domain Security (NDS)
 		Yes
Yes
 		revised No S3‑182608  
S3‑182170 Clarify NDS/AF intro regarding crypto profiles Juniper Networks CR  
7.4.3Network Domain Security (NDS)
 		Yes
Yes
 		noted No    
S3‑182171 Clause 5.2.5 - Modification on subscriber privacy ZTE Corporation CR Approval
7.1.14Privacy
 		Yes
YesIDEMIA: we cannot mandate proprietary schemes to be stored in the USIM. Ericsson agreed. Gemalto: the routing information should be listed as well.
 		revised No S3‑182635  
S3‑182172 Clause 5.8.2 - Modification on requirement on UDM storing key pair identifier ZTE Corporation CR Approval
7.1.14Privacy
 		Yes
Yes
 		not pursued No    
S3‑182173 Clause 5.9.3.3 - Modification on integrity requirement on N32 ZTE Corporation CR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
YesDT didn’t agree with this change; it is not modified inline.NCSC agreed.
 		not pursued No    
S3‑182174 Clause 6.1.2 - Modification on figure of initiation of authentication ZTE Corporation CR Approval
7.1.8Primary authentication
 		Yes
YesEricsson didn’t see the need to have a split in the fgure.
 		not pursued No    
S3‑182175 Clause 6.3.1 - Modification on security context handling ZTE Corporation CR Approval
7.1.6Security context
 		Yes
Yes
 		merged No S3‑182540  
S3‑182176 Discussion on AMF sending NAS SMC over both access types ZTE Corporation discussion Endorsement
7.1.5NAS security
 		Yes
Yes
 		noted No    
S3‑182177 Clause 6.4.2.2 - Clarification on AMF sending NAS SMC over both access types ZTE Corporation CR Approval
7.1.5NAS security
 		Yes
Yes
 		not pursued No    
S3‑182178 Clause 6.4.5 - Editorial modification on NAS COUNT handling ZTE Corporation CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No    
S3‑182179 Clause 6.6.1 - Modification on UP security policy ZTE Corporation CR Approval
7.1.4AS security
 		Yes
Yes
 		merged No S3‑182644  
S3‑182180 Clause 6.6.2 - Modification on UP security activation mechanism ZTE Corporation CR Approval
7.1.4AS security
 		Yes
YesHuawei supported this change. Nokia had some reservations since they considered it a rare case.They dropped their objection since everybody else could live with the change.
 		revised No S3‑182645  
S3‑182181 Clause 6.7.3.2 - Modification on algorithm selection during N2 handover ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
Yes
 		revised No S3‑182584  
S3‑182182 Clause 6.7.3.5 - Correct reference for RNA update procedure ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
Yes
 		agreed No    
S3‑182183 Clause 6.8.2.1.3 - Modification on State transition from RRC-INACTIVE to RRC-CONNECTED ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
Yes
 		not pursued No    
S3‑182184 Clause 6.9.2 - Modification on security handling during handover ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
YesEricsson: Note1 in 6.2.9.3.3 is important to be kept here, not removed as proposed by ZTE. Docomo: if it's important it should be normative and not an informative note.
 		revised No S3‑182585  
S3‑182185 Clause 6.9.2.1.2, 6.9.2.2 - Editorial modification on NAS during handover ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
YesEricsson commented that removing 6.9.2.2 was not possible since it is a stand alone procedure.They didn’t agree with the other changes either, since they were removing details that were important.
 		not pursued No    
S3‑182186 Clause 6.9.3 - Editorial modification on mobile registration update – AMF handling ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
YesEricsson: leave out any aspect on Multi NAS until we have finished discussions.
 		merged No S3‑182636  
S3‑182187 Discussion on mobile registration update ZTE Corporation discussion Endorsement
7.1.3Mobility
 		Yes
YesNokia didn’t see a problem. The agreements in Belgrade were enough for them. Ericsson (tdoc 419) and Qualcomm (tdoc 482) agreed on the existence of an issue and they had contributions with possible solutions.
 		noted No    
S3‑182188 Clause 6.9.3 - Add multi-NAS connections consideration for mobile registration update – AMF handling ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
Yes
 		not pursued No    
S3‑182189 Clause 6.9.3, 6.3.2.2 - Modification on mobile registration update – UE handling ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
Yes
 		not pursued No    
S3‑182190 Discussion on key change indication on N14 (AMF-AMF) ZTE Corporation discussion Endorsement
7.1.3Mobility
 		Yes
YesEricsson: AKSI is the wrong terminology. They didn't agree with the proposals as it has fundamental errors.
 		noted No    
S3‑182191 Clause 6.9.2.3.3 - Correct indication on N14 during N2 HO ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
Yes
 		merged No S3‑182585  
S3‑182192 Clause 6.9.3 - Add description for mobile registration update when NAS SMC has been performed – AMF handling ZTE Corporation CR Approval
7.1.5NAS security
 		Yes
Yes
 		not pursued No    
S3‑182193 Clause 6.9.5.1 - Add rule for concurrent running of security procedures ZTE Corporation CR Approval
7.1.5NAS security
 		Yes
YesEricsson: rule three is not needed.It was agreed to be removed. There was an overlap with rule 6 with the contribution 478 from Qualcomm. It was agreed to integrate it here.
 		revised No S3‑182655  
S3‑182194 Clause 6.9.5.2 - Modify rule for concurrent running of security procedures ZTE Corporation CR Approval
7.1.5NAS security
 		Yes
YesOverlap with 410 and 479, that simply remove bullet 4.
 		revised No S3‑182656  
S3‑182195 Discussion on RRC Reestablishment security ZTE Corporation discussion Endorsement
7.1.4AS security
 		Yes
Yes
 		noted No    
S3‑182196 Report from last SA3 meeting/s MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
YesNCSC's action item stays open.
 		approved No    
S3‑182197 Removal of JWE/JWS profile from 33.501 Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
YesMCC warned about renaming clauses and moving content around. The clauses should be voided and the new content added to a new clause.
 		merged No S3‑182550  
S3‑182198 JWE and JWS profiles Ericsson CR Agreement
7.4.3Network Domain Security (NDS)
 		Yes
Yes
 		merged No S3‑182606  
S3‑182199 CR to clarify username in Annex C Nokia,Nokia Shanghai Bell CR Approval
7.1.2Key derivation
 		Yes
Yes
 		revised No S3‑182583  
S3‑182200 Deletion of Requester ID from ‘Nausf_UEAuthentication_authenticate’ Nokia,Nokia Shanghai Bell CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		agreed No    
S3‑182201 CR to Clause 6.9.3 Removal of KSEAF storage restriction Nokia, Verizon, TMO-USA,Nokia Shanghai Bell CR Approval
7.1.3Mobility
 		Yes
Yes
 		revised No S3‑182548  
S3‑182202 CR for Addition of security requirements for external storage Nokia, Nokia Shanghai bell, Verizon, TMO-USA CR  
7.1.3Mobility
 		Yes
YesDocomo: relying on an unespecified interface is a bit messy.Replace with a "shall" and reword to make the requirement clearer. This clause was controversial and Nokia preferred to withdraw it. Docomo wanted to at least approve a few sentences and work from there from the next meeting. Docomo proposed to postpone the decision to the next meeting, bringing the same CR for discussion. MCC clarified that if postponed, no revisions of the content would be possible.
 		revised No S3‑182549  
S3‑182203 Clause 6.9.3 typo corrections Nokia, Nokia shanghai Bell CR Approval
7.1.3Mobility
 		Yes
Yes
 		merged No S3‑182636  
S3‑182204 Make DTLS optional on F1, E1, N2, Xn interfaces Nokia, Nokia Shanghai Bell, Huawei, HiSilicon CR Approval
7.1.4AS security
 		Yes
YesBT: This is making IPSec optional as well in 9.8.3. Ericsson didn't agree with making it optional.Huawei supported Ericsson. ORANGE: we had long discussions to make this mandatory. No point to reverse this. Huawei: there are technical arguments behind this. Docomo: A "may" be supported complicates inter operability for operators. Ericsson: DTLS is for the protection of the applications that are using SCTP. This is what is stated in the RFC.
 		not pursued No    
S3‑182205 CR to delete ENs in clause 5.3 gNB Requirements Nokia, Nokia Shanghai Bell CR Approval
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182651  
S3‑182206 CR to align NAS Connection value and access type Nokia, Nokia Shanghai Bell CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No    
S3‑182207 Correct confidentiality key in confidentiality clause. Nokia, Nokia Shanghai Bell CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No    
S3‑182208 Delete EN in Annex D for parameters Nokia, Nokia Shanghai bell CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No    
S3‑182209 Define and clarify ABBA parameter Nokia, Nokia Shanghai Bell CR Approval
7.1.5NAS security
 		Yes
Yes
 		revised No S3‑182653  
S3‑182210 Key issue avoiding AS encryption for application security enabled UE Nokia, Nokia Shanghai Bell pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182211 Key issue providing temperory security for PARLOS PDU session Nokia, Nokia Shanghai bell pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182212 SID on Enhanced network Slicing Nokia, Nokia Shanghai Bell,NEC, Huawei, HiSilicon,Motorola Mobility, Lenovo SID new Approval
8.10New study item proposals
 		Yes
YesHuawei: less about network slicing than it is stated. ZTE: network slice security belongs to phase two. The Chair commented that this was coming from an agreement from last meeting. China Mobile: we need to clarify the authentication in the network slice context. We have a discussion paper about this in 449. From this document it was preffered to go for cat 3. ORANGE commented that SA2 had ths in their study. Ericsson: the last bullet is a bit out of scope of this SID, it should belong to another SID. Vodafone agreed. Qualcomm: inter-slice security isolation? Where is this defined?ORANGE and Gemalto wanted to keep this bullet. Huawei: add privacy issues. ORANGE: privacy is in our terms of reference. We always take it into account. Interidigital: all security issues are part of the ToR.
 		revised No S3‑182665  
S3‑182213 Delete EN in Clause 10.2.1 Authenticated IMS Emergency Sessions Nokia, Nokia Shanghai Bell CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No    
S3‑182214 Discussion paper on S3-182150 KSEAF storage in UDSF Nokia, Nokia Shanghai Bell discussion Endorsement
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑182215 draft_Reply LS to S3-182150 security handling when deploying UDSF Nokia,Nokia Shanghai Bell LS out  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		revised No S3‑182547  
S3‑182216 [CAPIF_Sec] 33122 R15 access token profile Motorola Solutions UK Ltd. CR Agreement
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182620  
S3‑182217 [CAPIF-Sec] 33122 R15 FC values for CAPIF Motorola Solutions UK Ltd. CR Agreement
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		withdrawn Yes    
S3‑182218 [CAPIF-Sec] 33122 correct note in clause 6.5.2.1 Motorola Solutions UK Ltd. CR Agreement
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182622  
S3‑182219 [CAPIF-Sec] 33220 R15 FC values for CAPIF Motorola Solutions UK Ltd. CR Agreement
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		withdrawn Yes    
S3‑182220 [MCPTT] 33179 R13 Fix XML schema Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182221 [MCSec] 33180 R14 Fix XML schema Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182222 [MCPTT] 33180 R15 Fix XML schema (mirror) Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑182601  
S3‑182223 [MCSec] 33180 R14 FC values for MCData Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182224 [MCSec] 33180 R15 FC values for MCData (mirror) Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182225 [MCSec] 33180 R15 registered media type Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182226 [MCSec] 33220 R14 FC values for MCData Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182227 [MCSec] 33220 R15 FC values for MCData (mirror) Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182228 Clause 6.12.2-Adding Routing Indicator in SUCI CATT, Ericsson , Vodafone, Huawei, NEC, China Mobile, Nokia, Nokia Shanghai Bell Labs, IDEMIA CR Agreement
7.1.14Privacy
 		Yes
Yes
 		revised No S3‑182513  
S3‑182229 Clarification on UP security policy verification CATT CR Agreement
7.1.4AS security
 		Yes
Yes
 		merged No S3‑182644  
S3‑182230 Clarifications on AS key update for non-3GPP access CATT CR Agreement
7.1.11non-3GPP access
 		Yes
YesQualcomm: we don’t want to do reauthentication in this scenario, no security reasons.
 		not pursued No    
S3‑182231 Clarifications on handover handling for Dual Connectivity CATT CR Agreement
7.1.4AS security
 		Yes
YesDefinition part will go into S3-182648.The rest goes to 649.
 		merged No S3‑182649  
S3‑182232 Clarifications on the key lifetime for non-3GPP access CATT CR Agreement
7.1.11non-3GPP access
 		Yes
YesNokia,Qualcomm: the new text is confusing.
 		not pursued No    
S3‑182233 Reference corrections in clause 6.10 CATT CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No    
S3‑182234 Resolving Editor’s Notes for requirements on the gNB CATT CR Agreement
7.1.4AS security
 		Yes
Yes
 		merged No S3‑182651  
S3‑182235 Key issue proposal for FS_CIoT_sec_5G NEC Corporation pCR Agreement
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182236 Removal of comment texts NEC Corporation CR Agreement
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		not pursued No    
S3‑182237 Algorithm Negotiation for Unauthenticated UEs in LSM Huawei, HiSilicon, China Mobile CR Approval
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182646  
S3‑182238 Update Key handling at RRC-INACTIVE state transitions Huawei, HiSilicon, Intel, China Mobile CR Approval
7.1.4AS security
 		Yes
Yes
 		merged No S3‑182639  
S3‑182239 Supporting DTLS on gNB internal and external SCTP Interfaces Huawei, Hisilicon, Nokia discussion Endorsement
7.1.12NDS
 		Yes
Yes
 		revised No S3‑182516  
S3‑182240 AS SMC Handling Update Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No    
S3‑182241 DRAFT Reply LS on RRC Re-establishment security Huawei, Hisilicon LS out Approval
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182541  
S3‑182242 Discussion on RRC Re-establishment Security Huawei, Hisilicon discussion Endorsement
7.1.4AS security
 		Yes
Yes
 		noted No    
S3‑182243 DRAFT Reply LS on security requirements for RRC connection release Huawei, Hisilicon, China Mobile LS out Approval
7.1.4AS security
 		Yes
YesEricsson didn’t want to remove this feature and leave it up to RAN2 whether they want t use it. Nokia: we have established in the LTE TS that all redirection shall be protected. We don’t need another network policy for this case. Docomo: how do we know if there's an impact on the service from the UE side?
 		revised No S3‑182542  
S3‑182244 Study of 5G System Security Phase-2 Huawei, Hisilicon, SID new Approval
8.10New study item proposals
 		Yes
Yes
 		revised No S3‑182625  
S3‑182245 DRAFT LS on SCTP Restrictions when supporting DTLS over SCTP Huawei, Hisilicon LS out Approval
7.1.12NDS
 		Yes
Yes
 		noted No    
S3‑182246 pCR to TR33.861: Authentication of a group of CIoT devices Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182247 pCR to TR33.861: Secure Communication for a group CIoT devices Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182248 Key Issue on gNB Protection from CIoT DoS attack Huawei, Hisilicon, China Mobile pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182249 Study on 5G security enhancement Apple Computer Trading Co. Ltd SID new Approval
8.10New study item proposals
 		Yes
YesORANGE: privacy was covered in 5G phase one already. Interdigital: during fake base station attack, identifiers can be leaked. NCSC: these studies seem to affect only the UE, are studying impact on the core? Apple replied that the core was covered. T-Mobile: overlap with the Huawei SID. The Chair commented that there had been a privacy study item in the past whose results were not satisfactory. ORANGE proposed some rewording regarding privacy. The objectives were also simplified. Ericsson: giving a handbook of threats to 5G is giving a bad image. Let's focus on solutions and not study the threats. Ericsson commented that there was agreement on having focused studies and that they could come back in the next meeting with the different studies. Discussing the content during the present meeting would be time consuming. Huawei agreed.
 		revised No S3‑182634  
S3‑182250 New WID on Security of the enhancement to the 5GC location services CATT SID new Agreement
8.10New study item proposals
 		Yes
YesORANGE: some statements are normative. Qualcomm: in SA2 they consider translating what we have in LTE in the 5G system. Security threats are not clear. We don’t think that this is SID is needed. A SID could be needed depending on RAN's work such as broadcast aspects. Ericsson: we should take a look at any work that SA2 is doing.We support this SID with a simplified objective.
 		revised No S3‑182678  
S3‑182251 Performance aspects for the new 256-bit algorithms CATT pCR Approval
8.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		revised No S3‑182537  
S3‑182252 Proposed Skeleton for TR SPRINT Corporation draft TR Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑182253 P-CR proposing Background clause text SPRINT Corporation pCR Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182254 P-CR proposing Introduction clause text SPRINT Corporation pCR Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182255 P-CR proposing Scope clause text SPRINT Corporation pCR Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182256 P-CR proposing Requirements, assumptions and constraint clause text SPRINT Corporation pCR Agreement
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182257 JOSE based protection of messages over N32-f Nokia, NCSC,Nokia Shanghai Bell other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182560  
S3‑182258 Remove EN in 13.2 – Application layer security Nokia,Nokia Shanghai Bell other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182673  
S3‑182259 Exchange of N32-f context id during Initial Handshake Nokia,Nokia Shanghai Bell other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182673  
S3‑182260 Other Security Procedures for Dual Connectivity Huawei, HiSilicon CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182649  
S3‑182261 Key issue on keys used in GBA Huawei, HiSilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑182262 Key issue for fitting GBA into 5G core network functions Huawei, HiSilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑182263 Key issue on DoS attack on the network for 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
 		not treated No    
S3‑182264 Key issue on security for small data transmission Huawei, HiSilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182265 The SID on security for 5G URLLC Huawei, HiSilicon SID new Approval
8.10New study item proposals
 		Yes
YesQualcomm: we have seen this before and rejected it. What's new? Huawei: SA2's progressed and they have security issues that need to be taken into account here. Vodafone: we would trigger this SID with an LS from SA2. Docomo: we should start working on our own and not wait for SA2 to start any kind of work. A discussion paper would have been helpful to explain to us what the issues are instead of "security issues were detected". Qualcomm supported this. ORANGE also wanted a discussion paper on what SA2 is doing and the security issues that are identified in their work. Interdigital: asking SA2 for the security issues? That's our job. Huawei clarified that SA2 would finish their study in September.
 		revised No S3‑182679  
S3‑182266 Discussion-slice-management-security Huawei, HiSilicon, China Mobile, China Unicom, CATR, CATT discussion Endorsement
7.5New Work Item proposals
 		Yes
YesORANGE didn’t see the need to have a WID on this topic.
 		noted No    
S3‑182267 WID slicing management security Huawei, HiSilicon, China Mobile, China Unicom, CATR, CATT WID new Approval
7.5New Work Item proposals
 		Yes
Yes
 		noted No    
S3‑182268 Draft LS to GSMA on slicing Huawei, HiSilicon LS out Approval
6.4GSMA
 		Yes
YesQualcomm: we don’t need to ask them whether we need a slice specific authentication. ORANGE: there's no link between the DN and the slice. The secondary authentication is not linked to the NSSAI. Ericsson: keep it simple by confirming SA2's reply.
 		revised No S3‑182530  
S3‑182269 Amendment to Re-authentication procedure in Secondary Authentication Huawei, HiSilicon CR Agreement
7.1.9Secondary authentication
 		Yes
YesORANGE: not consistent with what SA2 has in their specification. Huawei commented that was the reason why they were proposing an LS to SA2 where they should add this change.The procedure was broken according to them. ORANGE commented that SA3 was not the right place to discuss this but in SA2. Ericsson: let's ask SA2 with an LS if there is a problem.
 		not pursued No    
S3‑182270 Draft-LS-out-to-SA2-on secondary re-authentication Huawei, HiSilicon LS out Approval
7.1.9Secondary authentication
 		Yes
Yes
 		revised No S3‑182661  
S3‑182271 Presentation on N32 connections and N32-f context Nokia, Juniper,Nokia Shanghai Bell other Presentation
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑182272 CR to add N32 definitions Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182550  
S3‑182273 CR to add a missing step to discover an NF producer instance during Access Token Request Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
Yes
 		revised No S3‑182641  
S3‑182274 CR to add Access Token Request procedure for a specific NF service producer Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
Yes
 		revised No S3‑182642  
S3‑182275 Security requirements for API invoker onboarding and offboarding Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182618  
S3‑182276 Modifications on Security procedures for API invoker onboarding Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182610  
S3‑182277 Clarification on Security protections in CAPIF-1 and CAPIF-2 reference point Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
YesNEC ommented that it's up to the operator to appy security protection, in the first change. This was taken offline.
 		revised No S3‑182619  
S3‑182278 Clarification on access token verification Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182621  
S3‑182279 Editorial corrections to TS 33.501 Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
YesORANGE: do we need Note 9 in the definition? Vodafone disagreed with the note as well. NOTE 2 was brought back as the change was argued by NEC.
 		revised No S3‑182657  
S3‑182280 FC value in TS 33.220 Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182623  
S3‑182281 Adding FC value to TS 33.122 Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182624  
S3‑182282 Access token profile Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
YesMotorola commented that the whole access token was to be defined in the annex, so this was needed.It was agreed to reword it.
 		merged No S3‑182620  
S3‑182283 Key Issue on mutual authentication between UE and BSF Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑182284 Corrections on primary authentication Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
YesThe addition in bullet 5 wasn't fully understood.
 		revised No S3‑182658  
S3‑182285 Delay the transmission of kseaf after home network verifies the RES_star Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		agreed No    
S3‑182286 editorial modification on TR33.856 Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑182693  
S3‑182287 Dicussion on security handling when deploying UDSF Huawei, Hisilicon discussion Endorsement
7.1.6Security context
 		Yes
YesIntel:we should not be implementation specific. Docomo: Is it necessary to have KSEAF stored anywhere in Rel-15? It's not clear to me why they need to store it. Ericsson proposed to remove the requirement on the storage. It was confusing for SA2.
 		noted No    
S3‑182288 evaluation of solution 1.1 for KI#1 Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
YesORANGE: remove "basis of normative work".
 		revised No S3‑182687  
S3‑182289 a proposal for the key issue on protecting the SRVCC capability of TR33.856 Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
YesEricsson didn’t agree with this scenario. Huawei commented that this scenario was coming from SA2. Nokia agreed with Ericsson. They didn’t agree with this key issue. Qualcomm agreed with this key issue.
 		revised No S3‑182684  
S3‑182290 a proposal for protecting the SRVCC capability of TR33.856 Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑182686  
S3‑182291 conclusion for key issue on protecting the SRVCC capability in initial NAS message Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
YesHuawei: SA2 has concluded on this issue. ORANGE: has SA2 decided to go for normative work? Huawei replied that they have an existing WID.
 		revised No S3‑182691  
S3‑182292 Discussion on initial NAS message Protection Solution Huawei, Hisilicon discussion Discussion
7.1.5NAS security
 		Yes
Yes
 		noted No    
S3‑182293 Delete initial NAS message protection solution Huawei, Hisilicon CR Approval
7.1.5NAS security
 		Yes
YesQualcomm didn't agree wih the removal.
 		not pursued No    
S3‑182294 LS on INACTIVE Security Algorithms Negotiation Huawei, Hisilicon LS out Approval
7.1.4AS security
 		Yes
Yes
 		noted No    
S3‑182295 Security Algorithms Negotiation for INACTIVE related procedures Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
YesEricsson: this was brought earlier and it wasn’t agreed.
 		not pursued No    
S3‑182296 Involve Fresh Parameters to Input of InactiveMAC-I to Avoid Replay Attack Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		noted No    
S3‑182297 Discussion on input for InactiveMAC-I to avoid replay attack Huawei, Hisilicon discussion Discussion
7.1.4AS security
 		Yes
Yes
 		noted No    
S3‑182298 Alignment of terminology in RRCConnctionReestablsihment Procedure in R14 Huawei, Hisilicon CR Approval
7.4.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑182602  
S3‑182299 Alignment of terminology in RRCConnctionReestablsihment Procedure in R15 Huawei, Hisilicon CR Approval
7.4.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑182603  
S3‑182300 Key Issue on IoT Terminal Security Monitoring Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182301 Align AS SMC procedure with SA2 and RAN3 Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
YesQualcomm, Ericsson: content is OK but the location is not correct. It was agreed to change this in order to just show a reference to the relevant TS. Nokia didn’t agree with the last paragraph of the change.
 		revised No S3‑182650  
S3‑182302 Hanldling UP security policy in MRDC Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		not pursued No    
S3‑182303 skeleton of TS 33511 Huawei, Hisilicon draft TS Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No    
S3‑182304 scope of TS 33511 Huawei, Hisilicon pCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No    
S3‑182305 security requirements and corresponding test cases for gNB Huawei, Hisilicon pCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
YesNEC: some requirements are internal to the product and not possible to test. E.g. 4.2.2.1.Z. Huawei commented that this was following the same pattern as the SCAS for eNodeB. Nokia didn’t agree with this pCR.
 		noted No    
S3‑182306 skeleton of TS 33515 Huawei, Hisilicon draft TS Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		revised No S3‑182599  
S3‑182307 scope of TS 33515 Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No    
S3‑182308 EDCE5 security requirements and corresponding test cases for MeNB Huawei, Hisilicon CR Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesNEC: 4.2.2.1.E is too detailed. Nokia had also some issues that had to be taken offline.
 		not pursued No    
S3‑182309 skeleton of TR 33807 Huawei, Hisilicon 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‑182310 scope of TR33807 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
 		not treated No    
S3‑182311 new requirement of 5G RG 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
 		not treated No    
S3‑182312 new requirement of NAS security 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
 		not treated No    
S3‑182313 new requirement of multi NAS connection 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
 		not treated No    
S3‑182314 new requirement of UP security 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
 		not treated No    
S3‑182315 new requirement of truted access 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
 		not treated No    
S3‑182316 Clarifications in TS 33117 Huawei, Hisilicon CR Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesEricsson didn’t agree with the second change, since it was ambiguous. Leaving the door open NEC didn’t agree with the editor's note. Huawei agreed to remove it but they noted that the issue was still open. MCC commented that this CR would need to correct the issue in lower releases.
 		revised No S3‑182612  
S3‑182317 CR on mandatory ciphering of access tokens by NRF in inter-PLMN scenarios Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
YesEricsson commented that this was not needed (Cyphering with a token). NCSC: more work is needed in the reference to the document [45] that is about sing-in.
 		not pursued No    
S3‑182318 CR to remove Editor’s Note on additional claims in the access token Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
YesHuawei didn't agree with removing the scope. Nokia agreed with putting it back.
 		revised No S3‑182566  
S3‑182319 CR to remove Editor’s Note on additional parameters that may be required in step 1 of Figure 13.4.1.1-2 Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
Yes
 		revised No S3‑182567  
S3‑182320 CR to remove Editor’s Note on verification of claims in the access token Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
Yes
 		merged No S3‑182568  
S3‑182321 pCR to DraftCR - Protection Policies KPN N.V. other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
YesDocomo: "Which IPX providers are authorized to perform modifications" not required if we don’t have a next hop. Delete this line.If we have a next hop identifier this is not required. It was commented that KPN was not present in the meeting to agree on the changes. DT proposed to take this over.
 		revised No S3‑182555  
S3‑182322 For Information: Discussion document on dealing with maliciously behaving devices KPN N.V. discussion Information
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182323 For Information: Potential new key issue KPN N.V. other Information
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182324 For Information: A potential new solution for dealing with maliciously behaving devices KPN N.V. other Information
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182325 Session Key Derivation for N32-f Application Layer Security NCSC other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182553  
S3‑182326 Agenda and notes of SA3 conference call on remaining Rel-15 SBA work Deutsche Telekom AG discussion Information
7.1.13.2Other
 		Yes
Yes
 		noted No    
S3‑182327 Agenda and notes of CT4/SA3 conference call on N32 Deutsche Telekom AG discussion Information
7.1.13.2Other
 		Yes
Yes
 		noted No    
S3‑182328 Agenda and notes of SA3 conference call on N32 Deutsche Telekom AG discussion Information
7.1.13.2Other
 		Yes
Yes
 		noted No    
S3‑182329 CR-slice-management-security Huawei, HiSilicon, China Mobile, China Unicom, CATR, CATT CR  
7.1.16Others
 		Yes
YesColin (BT) asked whether it was about management of network slices as signalling. MCC queried whether network slicing management security was part of the objectives of the 5G phase one security WID. ORANGE commented that it was part of the objectives of this WID to work on 5G security issues that were being done in other working groups (SA5 in this case). MCC commented that it may be argued that a revised WID for 5G Phase one would be needed to add this or a new WID to add this new security feature. The CR was finally agreed.
 		agreed No    
S3‑182330 SBA Security in the Context of 5G SCAS Work Deutsche Telekom AG, Nokia discussion Endorsement
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		endorsed No    
S3‑182331 Document Skeleton for TS 33.512, based on TS 33.116 Deutsche Telekom AG draft TS Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑182594  
S3‑182332 Update to WID 5G SCAS Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, China Unicom, CATT, Deutsche Telekom, ZTE, Samsung, KPN, NEC, British Telecom, China Mobile WID revised Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		revised No S3‑182525  
S3‑182333 Discussion on Security Assurance for 3GPP Virtualized Network Products Nokia, Nokia Shanghai Bell, China Mobile discussion Endorsement
8.10New study item proposals
 		Yes
Yes
 		noted No    
S3‑182334 New WID on security aspects of single radio voice continuity from 5G to 3G China Unicom, Huawei, HiSilicon, ZTE, CATT, OPPO WID new  
7.5New Work Item proposals
 		Yes
YesAlex(BT): in 5G we rely on VoLTE. Scenarios 2 and 3 are unclear since I don’t know what we are standardising. ORANGE commented that the current percentage of completion of the study (50%) may not justify this work item. Ericsson asked about the status of the study in SA2. It was commented that SA2 hadn’t completed the study yet.
 		revised No S3‑182671  
S3‑182335 On the alignment of N32 terminology Deutsche Telekom AG, Juniper Networks Inc. discussion Endorsement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑182336 Evaluation for solution #1.1 China Unicom pCR  
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
YesEricsson: the parameter is not new.
 		revised No S3‑182688  
S3‑182337 Closing the open Action Item for implementing one NESAS Pilot Finding in SCAS specification Nokia, Nokia Shanghai Bell discussion Endorsement
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		noted No    
S3‑182338 Evaluation for solution #1.2 China Unicom pCR  
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
YesEricsson: keep the evaluation but the last sentence seems not to be aligned with SA2.
 		revised No S3‑182689  
S3‑182339 A scenario on secure communication for shared bikes Alibaba (China) Group., Ltd. pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		revised No S3‑182518  
S3‑182340 References to encrypted IEs in the rewritten HTTP message Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑182341 N32-f context Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182552  
S3‑182342 Message flows including SEPP Ericsson CR Agreement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		not pursued No    
S3‑182343 Authentication for token-based authorization Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No    
S3‑182344 Clarifications and editorials to clause 13.1 (Transport security for service based interfaces) Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		withdrawn Yes    
S3‑182345 Clarifications and editorials to clause 13.3 (authentication and static authorization between network functions) Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		merged No S3‑182569  
S3‑182346 Update to LS on Implementation of NESAS Pilot Findings in SCAS specifications Nokia, Nokia Shanghai Bell LS out Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesHuawei didn't agree with the second paragraph.
 		revised No S3‑182701  
S3‑182347 Evaluation for solution #1.3 China Unicom pCR  
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑182690  
S3‑182348 EDCE5 – Fixing contradicting and insecure scg/sk counter handling in 33.401 from 36.331 Ericsson CR Agreement
7.4.11EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)
 		Yes
YesNokia didn't agree with this. Stick to one counter; RAN2 is wrong, so we need to tell them with an LS (S3-182616).
 		not pursued No    
S3‑182349 LTE EDT - Updates in suspend/resume Ericsson CR Agreement
7.4.1SAE/LTE Security
 		Yes
YesHuawei: RAN2 has gone already gone for 16 bits so let's move on. Ericsson: this is a new feature; I don’t understand why this is not integrity protected. This document was taken offline.It was decided to send an LS to RAN2 as well (S3-182605).
 		revised No S3‑182604  
S3‑182350 DC - definition corrections Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182648  
S3‑182351 Handling of maximum supported data rate per UE for integrity protection of DRBs Ericsson CR Agreement
7.1.4AS security
 		Yes
YesHuawei: policing the rate is causing an unnecessary burden on the gNB.(on the sentence "if the UE indicates 64 kbps as its maximum data rate, then the network turns on the integrity protection for user plane data only for total data rates equal to or lower than 64 kbps. "). Nokia: nothing new here, SA2 has captured it already. It was decided to drop this given that it was captured already in SA2.
 		not pursued No    
S3‑182352 DC - integrity protection of traffic between UE and SN Ericsson CR Agreement
7.1.4AS security
 		Yes
YesHuawei and Qualcomm didn’t agree with this change. Ericsson: Removing this assumes that the ng-eNB is not supporting integrity protection. Vodafone supported this change. Docomo: all dual connectivity types have no integrity protection supported? It was answered yes. It was also clarified that in pure 5G gNB-gNB there is integrity protection. DT also supported the notion of this change, but they commented that thing should be normative and not go into a note. Qualcomm: dual connectivity where one RAN is LTE and the other is NR, we don’t support integrity protection. This was the agreement during the last meeting. Ericsson eventually dropped this proposal and commented that they would come back with a modified proposal based on this.
 		not pursued No    
S3‑182353 DC - adding missing details Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		merged No S3‑182649  
S3‑182354 Reply LS on inactive security Ericsson LS out Approval
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182640  
S3‑182355 Reply LS on connection re-establishment security Ericsson LS out Approval
7.1.4AS security
 		Yes
YesSamsung: if we go for the LTE solution the message is not encrypted. Huawei: RAN2 is fine with the first message not being encrypted. Nokia: introducing this new complexity does not bring a noticeable benefit. The Chair noted that there was a big support for keeping the LTE mechanism. Huawei advocated for the existing solution in TS 33.501 and communicate it to RAN2.
 		merged No S3‑182541  
S3‑182356 DC - Handling of UP security policy in SN Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		not pursued No    
S3‑182357 DC - Selection of SN Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		not pursued No    
S3‑182358 Reply LS on BL/WLAN measurement collection in MDT Ericsson LS out Approval
7.1.4AS security
 		Yes
YesInterdigital: spoofing of the SSID should be addressed as well.
 		revised No S3‑182529  
S3‑182359 Reply LS on UE identity for PO calculation Ericsson LS out Approval
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182539  
S3‑182360 Reply LS on security requirements for RRC connection release Ericsson LS out Approval
7.1.4AS security
 		Yes
Yes
 		merged No S3‑182542  
S3‑182361 Reply LS on Security aspects of supporting LTE connected to 5GC Ericsson LS out Approval
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182538  
S3‑182362 DC – correcting reference Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No    
S3‑182363 Mobility – Clarification in intra-gNB-CU handover Ericsson CR Agreement
7.1.3Mobility
 		Yes
YesHuawei: Meaning of intra gNB handover is not to be explained by SA3. It had to be check offline whether the Intra gNB CU Handover existed in other groups specifications. Ericsson: we don’t need to distinguish between intra gNB and CU handover. We need to generalise it for just Intra gNB.
 		revised No S3‑182666  
S3‑182364 Mobility – Correcting AS re-keying and NAS re-keying in N2-handover Ericsson CR Agreement
7.1.3Mobility
 		Yes
YesZTE: this will make CT4 to change terminology. Ericsson: we are not introducing a new flag, this was existing already.
 		merged No S3‑182585  
S3‑182365 Mobility – Correcting to UE handling clause Ericsson CR Agreement
7.1.3Mobility
 		Yes
YesDiscussed together with 483.
 		merged No S3‑182590  
S3‑182366 Mobility – Resolving EN and corrections in AS re-keying Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		revised No S3‑182591  
S3‑182367 Mobility – Corrections for usage of local policy at AMF Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		revised No S3‑182636  
S3‑182368 Mobility – Rectification of NAS MAC calculation for NAS Container Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		revised No S3‑182586  
S3‑182369 Mobility – Rectification of how DL NAS COUNT is transferred in NAS Container Ericsson CR Agreement
7.1.3Mobility
 		Yes
YesQualcomm: CT1 has chosen 8 LSB already. Ericsson: this just brings clarification. This had to be checked offline. Since an LS to CT1 was agreed to be sent, Ericsson decided to drop this revision.
 		not pursued No    
S3‑182370 Mobility – Correction of NAS COUNTs in N2-handover Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No    
S3‑182371 Mobility – Removing an EN in Xn-handover Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No    
S3‑182372 Mobility – Rectification of UE security capabilities in NAS Container Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No    
S3‑182373 Mobility – Rectification of how UL NAS COUNT is transferred in NAS SMC Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		merged No S3‑182638  
S3‑182374 Privacy – adding missing detials in SUCI content and format Ericsson CR Agreement
7.1.14Privacy
 		Yes
YesQualcomm agreed with using 4 bits instead of 8 as proposed by Huawei in tdoc 514. Qualcomm: using the routing identifier bits is optional. It was agreed to have a field for the routing id. ORANGE: define a default value that means "not used". Huawei: not SA3's work, but CT4's.
 		revised No S3‑182535  
S3‑182375 Privacy - addressing ENs Ericsson CR Agreement
7.1.14Privacy
 		Yes
Yes
 		revised No S3‑182571  
S3‑182376 Update of definition of 5G AS security context for 3GPP access Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182652  
S3‑182377 Use the old KRRCint for calculation of the security token in MSG3 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182639  
S3‑182378 Security enhancements in LTE Ericsson discussion Endorsement
8.10New study item proposals
 		Yes
Yes
 		noted No    
S3‑182379 Security enhancements in 5G Ericsson discussion Endorsement
8.10New study item proposals
 		Yes
YesQualcomm: we cannot limit to these two points.
 		noted No    
S3‑182380 N32 session key derivation and key hierarchy Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182553  
S3‑182381 Removal of MAC based OAuth2.0 token verification Ericsson CR Agreement
7.1.13.2Other
 		Yes
YesChina Mobile and Huawei didn’t agree with the change. Vodafone: we may have different security levels considering that we have concepts like Edge Computing.
 		not pursued No    
S3‑182382 OAuth Client Registration up to implementation Ericsson CR Agreement
7.1.13.2Other
 		Yes
YesORANGE didn’t like to remove the reference to the SA2 document. No reason to make it implementation specific.DT supported this.
 		not pursued No    
S3‑182383 Removal of token validation by NRF Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		revised No S3‑182568  
S3‑182384 NRF Access Token Service Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		merged No S3‑182641  
S3‑182385 Clarifications on OAuth access token scope Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		merged No S3‑182641  
S3‑182386 TLS export Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182554  
S3‑182387 N32 terminology and restructuring Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182551  
S3‑182388 HTTP basic authentication to NRF Ericsson CR Agreement
7.1.13.2Other
 		Yes
YesDT: if we use dummy values why do we authenticate at all? We need to consult CT4 about it. Huawei didn't agree with this either.
 		not pursued No    
S3‑182389 NF Instance ID in HTTP basic authentication username in Rel-15 Ericsson discussion Discussion
7.1.13.2Other
 		Yes
Yes
 		noted No    
S3‑182390 Message Routing in N32 Ericsson discussion Discussion
7.1.13.1Interconnect (SEPP related)
 		Yes
YesHuawei didn’t agree with these proposals. It was agreed to send an LS to CT4.
 		noted No    
S3‑182391 Propose the content of conclusions China Unicom pCR  
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
YesAlex (BT): if this is the conclusion the TR misses the condition from SA plenary that moving down to UMTS would not cause any impact on 5G. Huawei: this is the conclusion of the key issues only. It was agreed to add an editor's note on this: "Confirmation that solutions do not weaken 5G security (including privacy) for operators not using 5G to UMTS SRVCC needs to be confirmed, as required by SA plenary study agreement."
 		revised No S3‑182692  
S3‑182392 Clarification of ngKSI and ABBA parameter in 5G-AKA Intel Corporation (UK) Ltd CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		revised No S3‑182533  
S3‑182393 Clarification for ngksi and ABBA parameter for EAP-AKA’ Intel Corporation (UK) Ltd CR  
7.1.8Primary authentication
 		Yes
Yes
 		revised No S3‑182534  
S3‑182394 Discussion on ngKSI Intel Corporation (UK) Ltd discussion  
7.1.8Primary authentication
 		Yes
Yes
 		noted No    
S3‑182395 AKMA Architecture for Non-3GPP Credential Download Alibaba (China) Group., Ltd. pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		revised No S3‑182520  
S3‑182396 Reply LS on Initial NAS Message Protection Intel Corporation (UK) Ltd LS out  
7.1.5NAS security
 		Yes
Yes
 		noted No    
S3‑182397 Steering of Information using Secure Packet Intel Corporation (UK) Ltd CR  
7.4.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
Yes
 		withdrawn Yes    
S3‑182398 Missing procedure for AS algorithm negotiation for unauthenticated emergency sessions Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		merged No S3‑182646  
S3‑182399 Corrections and clarifications to interworking clauses Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		revised No S3‑182581  
S3‑182400 Removal of editor’s note on harmonization between inter and intra system handovers Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		revised No S3‑182576  
S3‑182401 Clarifications related to the NAS Container calculation during inter system handover Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		revised No S3‑182575  
S3‑182402 Addition of missing reference to RFC on DTLS over SCTP Ericsson CR Agreement
7.1.12NDS
 		Yes
YesHuawei: add a note on the limitation during implementation. ORANGE: this is implementing the agreement from last meeting. Ericsson: we only minuted last meeting that we needed to fix the reference.
 		agreed No    
S3‑182403 Correction of Note on physical protection for NDS/IP use Ericsson CR Agreement
7.1.12NDS
 		Yes
YesDT: say "if" and not "In case". BT: the specs are control plane only, why remove these words? It was agreed to remove the note.
 		revised No S3‑182662  
S3‑182404 New key issue for security key refreshing Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182405 New key issue for security key storage Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182406 New key issue for security key and authentication tag size Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182407 New key issue for integrity protection of small data Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182408 New key issue for encryption of small data Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182409 Multiple NAS connections: mobility with horizontal KAMF derivation Ericsson CR Agreement
7.1.5NAS security
 		Yes
YesNEC: we don’t reestablish IPSec as described in step 3. Ericsson: we have to keep this if it is not described somewhere else. Qualcomm: handover over 4G, and other cases should also be described here. It was agreed to send an LS to CT1 to know their opinion on the results of the agreements in SA3.
 		not pursued No    
S3‑182410 Correction to clause 6.9.5.2 Ericsson CR Agreement
7.1.5NAS security
 		Yes
Yes
 		merged No S3‑182656  
S3‑182411 Multiple NAS connections: taking a new security context into use on non-3GPP access Ericsson CR Agreement
7.1.5NAS security
 		Yes
YesNokia: the existing IPSec would have to be deleted and then created again. Revised to add this clarification.
 		revised No S3‑182654  
S3‑182412 Support for Unauthenticated UEs access to RLOS using EPC Intel Corporation (UK) Ltd pCR  
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182413 On the need for error signalling in inter-PLMN communication Deutsche Telekom AG discussion Endorsement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182561  
S3‑182414 Editorial correction to figure 6.2.1-1 Key hierarchy generation in 5GS NEC Corporation CR Approval
7.1.1Key hierarchy
 		Yes
Yes
 		merged No S3‑182573  
S3‑182415 Correction to Clause 5.11.2 Requirements for algorithm selection NEC Corporation CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No    
S3‑182416 EPC solution for RLOS access Intel Corporation (UK) Ltd pCR  
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑182417 Removal of Note 2a on Kausf use case restriction NEC Corporation CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		revised No S3‑182659  
S3‑182418 Clarification on Storage of SUPI at SEAF NEC Corporation CR Approval
7.1.8Primary authentication
 		Yes
YesVodafone: store "securely". This was agreed. ORANGE, DT, BT: don’t delete the SUPI, just store it.
 		not pursued No    
S3‑182419 Editorial correction to TS 33.501 NEC Corporation CR Approval
7.1.16Others
 		Yes
Yes
 		agreed No    
S3‑182420 Skeleton for TS 33.514 SCAS UDM NEC Corporation pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
YesChina Mobile: why do we have a general security requirements clause and a specific requirements clause? Samsung: the general requirements are for all the network entities.
 		revised No S3‑182598  
S3‑182421 Scope proposal for TS 33.514 SCAS UDM NEC Corporation pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No    
S3‑182422 Mitigation against fraudulent registration attack between SEPPs Huawei, Hisilicon CR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
YesNCSC: this is not needed. There was no support for this document so it was not pursued.
 		not pursued No    
S3‑182423 Discussing about the necessity of SCAS for 3GPP virtualized network products China Mobile discussion Discussion
8.10New study item proposals
 		Yes
Yes
 		noted No    
S3‑182424 Discussing about ToE of SCAS for 3GPP virtualized network products China Mobile discussion Decision
8.10New study item proposals
 		Yes
Yes
 		noted No    
S3‑182425 Discussing about the SECAM and SCAS for 3GPP virtualized network products China Mobile discussion Decision
8.10New study item proposals
 		Yes
Yes
 		noted No    
S3‑182426 Implications of Network Function Virtualisation BT plc discussion Discussion
8.10New study item proposals
 		Yes
Yes
 		noted No    
S3‑182427 New SID on SECAM and SCAS for 3GPP virtualized network products China Mobile, Nokia, Nokia Shanghai Bell, China Unicom, CAICT, CATT, ZTE SID new  
8.10New study item proposals
 		Yes
YesAlex (BT): it misses whether we have to make changes in the architecture in order to virtualize it. Ericsson: this assumes impact on our architecture and we want to avoid that. Enhancement on the existing architecture is not what SCAS is about. NCSC: let's extend it beyond SCAS. The Chair commented that this could duplicate work done in other groups like ETSI ISG NFV. Better to separate SCAS activities from architecture enhancements. Colin (BT): deployment issues are in scope of GSMA. Ericsson: we will not be doing security assurance for platforms (e.g. proposed by ETSI NFV). Nokia: this is a study, there is no normative output here. Ericsson conceded given that this was a study.
 		revised No S3‑182681  
S3‑182428 A scenario on UAV Nav in AKMA China Mobile pCR  
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesORANGE: we don’t need new scenarios here unless they bring any substantial change in the architecture. Interdigital supported this. Companies had many issues with the scenario described here. 429 and 577 were opened to show new scenarios and try to figure out whether these scenarios brough key issues and architecture changes. Huawei: scenarios belong to SA1. We normally have key issues instead of scenarios in our TRs. ORANGE clarified that the scenarios could be brought as justification for the key issue in a discussion paper. ORANGE reminded that this was an internal TR, not intended for sharing externally. This had to be taken offline.
 		noted No    
S3‑182429 A scenario on V2X communication in 5G China Mobile pCR  
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑182430 Discussion and pCR for secure tranferring between network and 3rd party in AKMA China Mobile, DT, KPN, LG electronics, Alibaba (China) Group., Ltd. pCR  
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑182431 Discussion and pCR for identity key issue of AKMA China Mobile, DT, KPN, Alibaba (China) Group., Ltd. pCR  
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‑182526  
S3‑182432 Discussion and pCR for decoupling secure procedure with specific protocol in AKMA China Mobile, KPN, LG electronics, Alibaba (China) Group., Ltd. pCR  
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑182433 Revision of the modification policy in draft CR S3-181937 China Mobile other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182558  
S3‑182434 Discussion on provision of ngKSI to UE in EAP-Request/AKA'-Challenge message Huawei, Hisilicon discussion Endorsement
7.1.8Primary authentication
 		Yes
Yes
 		noted No    
S3‑182435 Discussion of error handling for SBA China Mobile discussion Discussion
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑182436 Generic description of security elements Nokia, Nokia Shanghai Bell CR  
7.1.16Others
 		Yes
Yes
 		revised No S3‑182613 S3‑181892
S3‑182437 Clarification to key hierarchy Nokia, Nokia Shanghai Bell CR  
7.1.1Key hierarchy
 		Yes
YesIt was unclear the term "shall be prepared to support 256-bit keys". Ericsson commented that all interfaces support already 256 bits. This sentence was reworded in the revision.
 		revised No S3‑182573  
S3‑182438 Editorial changes to clause 9 Nokia, Nokia Shanghai Bell CR  
7.1.16Others
 		Yes
YesEricsson: these services are described in our specification. MCC: not possible to "un-void" clauses. It should have been rev 2. Ericsson: clause 9.5.1 is referring to the very same spec. Not necessary.
 		revised No S3‑182664 S3‑181895
S3‑182439 Collection of editorial changes Nokia, Nokia Shanghai Bell CR  
7.1.16Others
 		Yes
Yes
 		revised No S3‑182528  
S3‑182440 Update on SEAF requirements Nokia, Nokia Shanghai Bell CR  
7.1.8Primary authentication
 		Yes
Yes
 		revised No S3‑182589 S3‑181894
S3‑182441 Addition of definitions and corrections to references Nokia, Nokia Shanghai Bell CR  
7.1.16Others
 		Yes
Yes
 		revised No S3‑182582  
S3‑182442 Corrections to references related to handling of security contexts in mobility procedures Nokia, Nokia Shanghai Bell CR  
7.1.10Interworking
 		Yes
Yes
 		revised No S3‑182540  
S3‑182443 Clarification to support of authentication methods Nokia, Nokia Shanghai Bell CR  
7.1.8Primary authentication
 		Yes
Yes
 		revised No S3‑182680  
S3‑182444 Intro to FS_VERTICAL_LAN_SEC Nokia, Nokia Shanghai Bell discussion  
8.10New study item proposals
 		Yes
Yes
 		noted No    
S3‑182445 SID_FS_VERTICAL_LAN_SEC Nokia, Nokia Shanghai Bell SID new  
8.10New study item proposals
 		Yes
Yes
 		revised No S3‑182682  
S3‑182446 Provision of ngKSI to UE at EAP-Request/ AKA'-Challenge Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		merged No S3‑182534  
S3‑182447 Error handling for SBA authentication and authorization in service layer China Mobile CR  
7.1.13.1Interconnect (SEPP related)
 		Yes
YesDT: what's the benefit of silently discarding here? Also, there is normative text in the notes. China Mobile: we need a procedure to deal with this error handling. DT proposed to include these changes in the error messages that they had brought in the discussion paper. In any case the error messages were to be worked on in CT4 so an LS would be sent to them. This was agreed. BT: "silently discard" wording is used when there is an overload.
 		revised No S3‑182563  
S3‑182448 [DRAFT] Reply LS to LS on provision of ngKSI to UE at EAP-Request/AKA'-Challenge Huawei, Hisilicon LS out Approval
7.1.8Primary authentication
 		Yes
Yes
 		revised No S3‑182532  
S3‑182449 Discussion on clarification of concept of slice authentication China Mobile discussion Endorsement
8.9Other study areas
 		Yes
YesORANGE: cat 1 and cat 2 can be discarded. I can agree with cat 3, this slice authentication comes after a succesful primary authentication. I agree with the conclusion. Colin (BT) agreed with cat 3 as well. China Mobile asked to be minuted that the SA3 preference was on cat 3. ORANGE added that this would be with some modification on the objectives of the Study Item in 2212.
 		noted No    
S3‑182450 Clarification on motivation and privacy concerns for BT and WLAN measurement collection in MDT China Mobile discussion  
7.4.16Other work items
 		Yes
YesBT: there's an integrity issue, you can set the SSID to anything you like (spoofing).The initial connection cannot be trusted. Vodafone: we are concerned about the provisioning aspects of the SSID as well. Nokia: How does the bluetooth improve the privacy? There is no use for Bluetooth in this case. China Mobile replied that the operator must have the user consent at first. The user knows that the operator will collect something. Alec (Interdigital) commented that the user consent was not enough to ensure privacy. The identity should not be given. Giving away the location would not help either if they capture the user's Bluetooth beacon. Ericsson: it's not up to us to discuss the usefulness of this.Integrity and confidentiality protection would secure this case enough. Docomo: the operator wants to collect their own Bluetooth beacon, not the user's.They only measure WLAN APs with a certain name as well. A major issue is the use of fake base stations. How to do self-configuration in a secure way would be useful to work on a future work item. Vodafone: roamers have an issue.
 		noted No    
S3‑182451 Discussion on charging fraud attack Huawei, Hisilicon discussion Endorsement
7.1.16Others
 		Yes
YesVodafone commented that a SID would be useful to study the different fraud possibilites but Tim wasn't convinced that a solution or an implemented fix would be enough. Docomo and ORANGE agreed. A SID could be useful. Qualcomm commented that the visited network had to be trusted. They weren't sure of what could be done here. Qualcomm asked Huawei to bring more details in order to consider a Study Item. It was agreed that Huawei would bring more details in the next meeting.
 		noted No    
S3‑182452 Clarification on authentication and authorization in SBA Huawei, Hisilicon CR Approval
7.1.13.2Other
 		Yes
Yes
 		revised No S3‑182569  
S3‑182453 Adding OAuth related authorization services for SBA security Huawei, Hisilicon CR Approval
7.1.13.2Other
 		Yes
Yes
 		revised No S3‑182670  
S3‑182454 TS 33.834 - editorial updates Vodafone Espańa SA pCR Approval
8.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑182455 Draft LS to ETSI SCP regarding the integration of LTKUP solution 4B into the OTA specifications. Vodafone Espańa SA LS out Agreement
8.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑182456 CR to TS 33.163 (BEST) - correction of Tag values Vodafone Espańa SA CR Agreement
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑182627  
S3‑182457 CR to TS33.163 (BEST) - clarification of error conditions Vodafone Espańa SA CR Agreement
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑182458 CR to 33.163 - Clarification as to when the Serving Network TLV is required Vodafone Espańa SA CR Agreement
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑182459 References to encrypted IEs in the rewritten HTTP message Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		No
Yes
 		withdrawn Yes    
S3‑182460 N32-f context Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		No
Yes
 		withdrawn Yes    
S3‑182461 Message flows including SEPP Ericsson CR Agreement
7.1.13.1Interconnect (SEPP related)
 		No
Yes
 		withdrawn Yes    
S3‑182462 Authentication for token-based authorization Ericsson CR Agreement
7.1.13.2Other
 		No
Yes
 		withdrawn Yes    
S3‑182463 Clarifications and editorials to clause 13.1 (Transport security for service based interfaces) Ericsson CR Agreement
7.1.13.2Other
 		No
Yes
 		withdrawn Yes    
S3‑182464 Clarifications and editorials to clause 13.3 (authentication and static authorization between network functions) Ericsson CR Agreement
7.1.13.2Other
 		No
Yes
 		withdrawn Yes    
S3‑182465 Clarifications and editorials to clause 13.1 (Transport security for service based interfaces) Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		revised No S3‑182570  
S3‑182466 LTKUP: solution#5 evaluation Gemalto N.V. pCR Approval
8.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)
 		Yes
YesVodafone: this may misinterpret key issue 5. Vodafone commented that there were issues left and that they wanted to continue the study.
 		revised No S3‑182696  
S3‑182467 Key Issue on Authentication Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑182468 Support of 256-bit algorithms: references Gemalto N.V. pCR Approval
8.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
YesNCSC: 64 bits is only legacy, it should be 96bits and longer. Vodafone wanted the first change removed.
 		revised No S3‑182675  
S3‑182469 Support of 256-bit algorithms: changes Gemalto N.V. pCR Approval
8.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
YesNCSC objected to the first change. There were many other concerns on this document so it was finally noted.
 		noted No    
S3‑182470 Updates on Security Mechanism for Steering of Roaming Samsung, Qualcomm Incorporated, T-Mobile USA CR  
7.4.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑182471 Mending MCC EditHelp Comments Deutsche Telekom AG pCR Agreement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑182472 Assignment of FC values to AEFPSK derivation Samsung CR  
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑182624  
S3‑182473 Clarifications on the calculation of NAS-MAC for RRCConnection re-establishmentwith Control Plane CIoT optimisations (Rel-14) Qualcomm Incorporated CR Agreement
7.4.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		revised No S3‑182614  
S3‑182474 Clarifications on the calculation of NAS-MAC for RRCConnection re-establishmentwith Control Plane CIoT optimisations (Rel-15) Qualcomm Incorporated CR Agreement
7.4.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		revised No S3‑182615  
S3‑182475 Initial NAS security discussion Qualcomm Incorporated, DT, Vodafone, KPN discussion Endorsement
7.1.5NAS security
 		Yes
YesDT: this is not only protecting the message in its current form but also it is safe for the future. Nokia: too late to change the cal flow, impact on current implementations.I don’t see the threat of the UE being traceable, nothing to protect here. Vodafone supported Qualcomm's assesment on reverse engineering. Interidigital: GUTI carries AMF identifier and it is enough to identify a number of UEs that work with an AMF. Intel: ProSe is not supported in Rel-15, there is no clear threat analysis done and we propose to postpone this for Rel-16. Ericsson agreed with Intel: it is too late and we are concerned with the impact on stage 2. Postpone to Rel-16. Vodafone: we had agreed on a change on this. We would need a CR to revert this and it's not postponing: it's taking an action. Qualcomm agreed with Vodafone. SA3 has rejected this CR twice already. AT&T: if we don't do it now, we may not do it at all. Docomo agreed. Nokia: is this an essential feature? Ericsson: it's fine to introduce this in later Releases. Docomo: Why is CT1 worried about the delay? Partial cyphering was present in LTE already. The Chair requested a show of hands on 292 and 475. Tdoc 292: Nokia, LG,Intel,Huawei,Ericsson, ZTE. Tdoc 475: Vodafone, Qualcomm, IDEMIA,Docomo, DT,ORANGE,Interdigital,BT,NIST,China Mobile,AT&T,Vodafone, Airbus,Gemalto.
 		noted No    
S3‑182476 Reply LS on initial NAS message protection Qualcomm Incorporated LS out Approval
7.1.5NAS security
 		Yes
YesEricsson: it is important to analyze impacts on stage 2. DT: security by default should be the solution we should aim for. The Chair suggested that in SA3 a trade-off would be needed in this case if SA3 couldn’t get to the full security solution and let another group decide. Huawei commented that there seemed to be two sides on this issue: vendors (who saw a huge impact with little gain) and the operators/ handset manufacturers. Ericsson: we never justified why we needed to protect all the parameters. Qualcomm: you can link all this to the IMSI. Docomo agreed with Qualcomm. Alf also wondered where the impact was happening exactly. Ericsson replied that SA2 needed to revise the flow and it was too late to do this stage 2 change now. Docomo: the impact or cost is in standard development then. The Chair commented that not sending LS would mean that what is in the TS would remain.He suggested to send an LS stating the disagreement in SA3 on the justification. Huawei agreed to send such LS and suggested to let SA plenary decide. It was agreed to create an LS to express the lack of consensus (S3-182632). Alex (BT) warned about the danger of the operators not being GDPR compliant. He also added that we are required by the regulators to support LI but as operators we cannot justify creating more "holes" than the ones that LI requires.LI "holes" are protected, but here we would have "holes" open to the public.
 		noted No    
S3‑182477 Moving the HASHAMF behaviour from subclause 6.7.2 to subclause 6.4.6 Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
Yes
 		not pursued No    
S3‑182478 Concurrency issues with N2 and 5G to EPS handovers Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
Yes
 		merged No S3‑182655  
S3‑182479 Correction to the concurrency rules for parallel NAS connections Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
Yes
 		merged No S3‑182656  
S3‑182480 Adding to note about ABBA to Annex A.7 that was missed in implementation of CR 0155r2 Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
Yes
 		not pursued No    
S3‑182481 Discussion on the response to the CT1 LS on provision of ngKSI to UE at EAP-Request/AKA'-Challenge Qualcomm Incorporated discussion Endorsement
7.1.8Primary authentication
 		Yes
Yes
 		noted No    
S3‑182482 Discussion on security context handling issues when the UE is multiple registered in the same PLMN Qualcomm Incorporated discussion Endorsement
7.1.5NAS security
 		Yes
YesThe LS to cT1 in tdoc 637 is based on this document.
 		noted No    
S3‑182483 Simplification of the UE handling of keys at handover Qualcomm Incorporated CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182590  
S3‑182484 discussion on RRC Inactive security Qualcomm Incorporated discussion Endorsement
7.1.4AS security
 		Yes
Yes
 		noted No    
S3‑182485 CR on RRC Inactive Qualcomm Incorporated CR Agreement
7.1.4AS security
 		Yes
YesHuawei: we cannot revert decisions and come back to something that RAN2 has decided. Adapt option A and forget about option B.
 		not pursued No    
S3‑182486 CR on reigstration procedure for mobility from 4G to 5G Qualcomm Incorporated CR Agreement
7.1.10Interworking
 		Yes
Yes
 		revised No S3‑182574  
S3‑182487 K_AMF change indication in NAS SMC Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
YesNokia and Huawei agreed with Qualcomm.
 		revised No S3‑182638  
S3‑182488 UP policy check Qualcomm Incorporated CR Agreement
7.1.4AS security
 		Yes
Yes
 		revised No S3‑182644  
S3‑182489 CR on N2 based HO Qualcomm Incorporated CR Agreement
7.1.3Mobility
 		Yes
Yes
 		revised No S3‑182588  
S3‑182490 LS reply on security for E-UTRA connected to 5GC Qualcomm Incorporated LS out Approval
7.1.4AS security
 		Yes
Yes
 		merged No S3‑182538  
S3‑182491 CR on corrections on the 5GS to EPS handover procedure Qualcomm Incorporated CR Agreement
7.1.10Interworking
 		Yes
YesNTT-Docomo: is there any reason to specify 4 or 8 bytes? It's irrelevant from the security point of view. Ericsson: CT1 usually asks us about the size.
 		revised No S3‑182579  
S3‑182492 LS on NAS parameter for 5GS to EPS HO Qualcomm Incorporated LS out Approval
7.1.10Interworking
 		Yes
Yes
 		revised No S3‑182580  
S3‑182493 Handling of initial value of CounterSoR Qualcomm Incorporated CR Agreement
7.4.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑182494 Agenda and notes of 27th June conference call on remaining Rel-15 SBA work Qualcomm Incorporated report Information
7.1.13.2Other
 		Yes
Yes
 		noted No    
S3‑182495 Assigning FC value to TS 33.122 Samsung CR  
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑182623  
S3‑182496 Key Issue on PARLOS Security Motorola Mobility, Lenovo pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182497 Key Issue on Registration and NAS transport for trusted non-3GPP access 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
Yes
 		not treated No    
S3‑182498 Key Issue on Access to 5GC from 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
Yes
 		not treated No    
S3‑182499 [Draft] Reply LS on connection re-establishment security Samsung LS out  
7.1.4AS security
 		Yes
YesZTE: RAN2's proposal will cause an signalling overload. LTE's mechanisms could be reused here.
 		noted No    
S3‑182500 Update on InactiveMAC-I calculation Samsung CR  
7.1.4AS security
 		Yes
YesEricsson: this has been here since LTE, so if we want to remove we need to prove that there is a problem. We need a proper justification. Huawei wanted this change enhanced. Nokia: we can address the scenarios in the next meeting. Huawei proposed to bring a discussion paper about this. Ericsson asked to be minuted: calculation of soft resume MAC-I and resume constant input needs to be revisited. It was agreed to send an LS in 667 to CT1 as well.
 		agreed No    
S3‑182501 Mechanism to mitigate replay attack in RRC-Inactive state Samsung CR  
7.1.4AS security
 		Yes
YesIt was pointed out that the Issue was identified. Ericsson thought that this issue should be addressed but they didn’t agree with the solutions from Samsung and Huawei. They commented that they would bring a contribution for the next meeting. Huawei would also come back with their solution.
 		noted No    
S3‑182502 Discussion on Key Issues of FS_SBA_Sec Deutsche Telekom AG discussion Endorsement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑182503 Introducing a new set of key issues to TR 33.855 Deutsche Telekom AG pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesEricsson: this is not in scope of the study. Deutsche Telekom commented that the former living document had not enough content. ORANGE: is the intention to stop the Study now or we continue to add content in the next release? DT commented that they didn’t see realistic to finish the study in this meeting. MCC commented that if SA3 was going beyond the initial scope and objectives of the Study, they had to revise the Study. Ericsson: routing issues should be added. Vodafone didn’t want to see this closed; there were open issues and the study was still useful for Rel-16. The Rel-15 version of SBA was not robust enough to be implemented. ORANGE supported Vodafone. Ericsson queried whether the study was going to be with a Rel-15 scope or including enhancements for Rel-16. Nokia: there are a couple of open issues not closed in Rel-15. We don’t want to close it now. Vodafone: don’t send it for approval for the next Plenary. BT: what is more interesting is what goes to 33.501. No need to carry on with this TR, close it. Huawei: close the TR. ORANGE: approving this document will leave the study incomplete. Ericsson: the original commitment was to copy the living document into a TR, and save time, This is taking more time than planned. We should close now and open a new Study Item. Vodafone objected to closing the Study.DT preferred to keep it open too. ORANGE would also object to closing the study.
 		approved No    
S3‑182504 Skeleton for TS 33.513 Samsung draft TS  
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
Yes
 		revised No S3‑182595  
S3‑182505 Scope for TS 33.513 SCAS UPF Samsung pCR  
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
Yes
 		approved No    
S3‑182506 Clarification to the protection of attributes by the SEPP Deutsche Telekom AG CR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182565  
S3‑182507 Clarifications to protection policies Deutsche Telekom AG CR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182559  
S3‑182508 New key issue on Privacy of subscriber and application user LG Electronics 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‑182509 New key issue on provisioning of CIoT devices LG Electronics pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑182510 New key issue on flexible security of CIoT devices LG Electronics 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‑182511 CR for 33.501 - Editorial correction of 6.9.3 LG Electronics CR Agreement
7.1.16Others
 		Yes
Yes
 		merged No S3‑182528  
S3‑182512 CR for 33.501 - Editorial correction of 6.7.2 LG Electronics CR Agreement
7.1.16Others
 		Yes
Yes
 		agreed No    
S3‑182513 Clause 6.12.2-Adding Routing Indicator in SUCI CATT, Ericsson , Vodafone, Huawei, NEC, China Mobile, Nokia, Nokia Shanghai Bell Labs, IDEMIA CR Agreement
7.1.14Privacy
 		Yes
Yes
 		merged No S3‑182535 S3‑182228
S3‑182514 Disucssion and clarification on SUCI parameters Huawei, Hisilicon discussion Agreement
7.1.14Privacy
 		Yes
Yes
 		noted No    
S3‑182515 LS on SUCI parameters clarification Huawei, Hisilicon LS out Approval
7.1.14Privacy
 		Yes
Yes
 		revised No S3‑182536  
S3‑182516 Supporting DTLS on gNB internal and external SCTP Interfaces Huawei, Hisilicon, Nokia discussion Endorsement
7.1.4AS security
 		Yes
Yes
 		not pursued No   S3‑182239
S3‑182517 Security requirements on the CAPIF-3e/4e/5e reference points China Telecommunications CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑182518 A scenario on secure communication for shared bikes Alibaba (China) Group., Ltd., China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		noted No   S3‑182339
S3‑182519 Response to 3GPP SA2 liaison S2-183036 on ‘general status of work’ BBF LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑182520 AKMA Architecture for Non-3GPP Credential Download Alibaba (China) Group., Ltd., China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		noted No   S3‑182395
S3‑182521 Commenting contribution on JOSE based protection of HTTP messages over N32-f (S3-182257) Deutsche Telekom AG other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑182522 Error handling for N32 Application Layer Security Nokia other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
YesVodafone proposed to have the error handling optional. Ericsson: error handling being optional is stepping on CT4's (stage 3) territory.
 		revised No S3‑182564  
S3‑182523 Comments on S3-182209 Qualcomm Incorporated discussion  
7.1.5NAS security
 		Yes
Yes
 		noted No    
S3‑182524 WI Summary for 5G_Ph1-sec NTT DOCOMO INC. WI summary Endorsement
7.1.16Others
 		Yes
Yes
 		revised No S3‑182633  
S3‑182525 Update to WID 5G SCAS Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, China Unicom, CATT, Deutsche Telekom, ZTE, Samsung, KPN, NEC, British Telecom, China Mobile, Ericsson WID revised Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
YesEricsson was concerned about the amount of resources spent on this work and whether this was used in GSMA and so on. The progress was slow on SCAS.
 		revised No S3‑182593 S3‑182332
S3‑182526 Discussion and pCR for identity key issue of AKMA China Mobile, DT, KPN, Alibaba (China) Group., Ltd. pCR  
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‑182431
S3‑182527 Comment on: JOSE based protection of HTTP messages over N32-f (S3-182257) Ericsson-LG Co., LTD discussion Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑182528 Collection of editorial changes Nokia, Nokia Shanghai Bell,LG CR -
7.1.16Others
 		Yes
Yes
 		agreed No   S3‑182439
S3‑182529 Reply LS on BL/WLAN measurement collection in MDT Ericsson LS out Approval
7.1.4AS security
 		Yes
Yes
 		approved No   S3‑182358
S3‑182530 LS to GSMA on slicing Huawei, HiSilicon LS out Approval
6.4GSMA
 		Yes
Yes
 		approved No   S3‑182268
S3‑182531 Reply to:LS on new work item "X.5Gsec-q" Vodafone LS out approval
6.8TC-CYBER
 		Yes
Yes
 		approved No    
S3‑182532 Reply LS to LS on provision of ngKSI to UE at EAP-Request/AKA'-Challenge Huawei, Hisilicon LS out Approval
7.1.8Primary authentication
 		Yes
Yes
 		approved No   S3‑182448
S3‑182533 Clarification of ngKSI and ABBA parameter in 5G-AKA Intel Corporation (UK) Ltd CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑182392
S3‑182534 Clarification for ngksi and ABBA parameter for EAP-AKA’ Intel Corporation (UK) Ltd,Huawei,Nokia, Nokia Shanghai Bell CR -
7.1.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑182393
S3‑182535 Privacy – adding missing detials in SUCI content and format CATT, Ericsson , Vodafone, Huawei, NEC, China Mobile, Nokia, Nokia Shanghai Bell Labs, IDEMIA CR Agreement
7.1.14Privacy
 		Yes
Yes
 		agreed No   S3‑182374
S3‑182536 LS on SUCI parameters clarification Huawei, Hisilicon LS out Approval
7.1.14Privacy
 		Yes
Yes
 		approved No   S3‑182515
S3‑182537 Performance aspects for the new 256-bit algorithms CATT pCR Approval
8.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
YesThere were many concerns on this document so it had to be noted. Vodafone proposed a conference call for the following week to have documents like this as an input.
 		noted No   S3‑182251
S3‑182538 Reply LS on Security aspects of supporting LTE connected to 5GC Ericsson LS out Approval
7.1.4AS security
 		Yes
Yes
 		approved No   S3‑182361
S3‑182539 Reply LS on UE identity for PO calculation Ericsson LS out Approval
7.1.4AS security
 		Yes
Yes
 		approved No   S3‑182359
S3‑182540 Corrections to references related to handling of security contexts in mobility procedures Nokia, Nokia Shanghai Bell,ZTE CR -
7.1.6Security context
 		Yes
Yes
 		agreed No   S3‑182442
S3‑182541 Reply LS on RRC Re-establishment security Huawei, Hisilicon LS out Approval
7.1.4AS security
 		Yes
Yes
 		approved No   S3‑182241
S3‑182542 Reply LS on security requirements for RRC connection release Huawei, Hisilicon, China Mobile LS out Approval
7.1.4AS security
 		Yes
Yes
 		approved No   S3‑182243
S3‑182543 [MCSec] 33180 R14. Examples of MC service ID shall be URI Airbus DS SLC CR -
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑182107
S3‑182544 [MCSec] 33180 R15. Examples of MC service ID shall be URI Airbus DS SLC CR -
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑182108
S3‑182545 [MCPTT 33180 R14. Clarification for MIKEY-SAKKE values Airbus DS SLC CR -
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑182110
S3‑182546 [MCSec] 33180 R15. Clarification for MIKEY-SAKKE values Airbus DS SLC CR -
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑182111
S3‑182547 Reply LS to S3-182150 security handling when deploying UDSF Nokia,Nokia Shanghai Bell LS out -
7.1.15Incoming and outgoing Lses
 		Yes
YesThere was no consensus on this LS, and given that SA2 would not meet before the next SA3 meetng, this was noted.
 		noted No   S3‑182215
S3‑182548 CR to Clause 6.9.3 Removal of KSEAF storage restriction Nokia, Verizon, TMO-USA,Nokia Shanghai Bell CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑182201
S3‑182549 CR for Addition of security requirements for external storage Nokia, Nokia Shanghai bell, Verizon, TMO-USA CR -
7.1.3Mobility
 		Yes
Yes
 		postponed No   S3‑182202
S3‑182550 N32 solution details Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		agreed No   S3‑182272
S3‑182551 N32 terminology and restructuring Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182673 S3‑182387
S3‑182552 N32-f context Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182673 S3‑182341
S3‑182553 N32 session key derivation and key hierarchy Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182550 S3‑182380
S3‑182554 TLS export Ericsson other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182673 S3‑182386
S3‑182555 pCR to DraftCR - Protection Policies Deutsche Telekom other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182552 S3‑182321
S3‑182556 [MCPTT] 33179 R13. Examples of MC service ID shall be URI Airbus DS SLC CR -
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182557 [MCPTT] 331179 R13. Clarification for MIKEY-SAKKE values Airbus DS SLC CR -
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑182558 Revision of the modification policy in draft CR S3-181937 China Mobile other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182673 S3‑182433
S3‑182559 Clarifications to protection policies Deutsche Telekom AG CR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182673 S3‑182507
S3‑182560 JOSE based protection of messages over N32-f Nokia, NCSC,Nokia Shanghai Bell other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182673 S3‑182257
S3‑182561 On the need for error signalling in inter-PLMN communication Deutsche Telekom AG discussion Endorsement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		endorsed No   S3‑182413
S3‑182562 LS on N32 error signalling Deutsche Telekom LS out Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No    
S3‑182563 Error handling for SBA authentication and authorization in service layer China Mobile CR -
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		agreed No   S3‑182447
S3‑182564 Error handling for N32 Application Layer Security Nokia other Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		merged No S3‑182550 S3‑182522
S3‑182565 Clarification to the protection of attributes by the SEPP Deutsche Telekom AG CR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		agreed No   S3‑182506
S3‑182566 CR to remove Editor’s Note on additional claims in the access token Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑182318
S3‑182567 CR to remove Editor’s Note on additional parameters that may be required in step 1 of Figure 13.4.1.1-2 Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑182319
S3‑182568 Removal of token validation by NRF Ericsson,Nokia CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑182383
S3‑182569 Clarification on authentication and authorization in SBA Huawei, Hisilicon,Ericsson, Nokia CR Approval
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑182452
S3‑182570 Clarifications and editorials to clause 13.1 (Transport security for service based interfaces) Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑182465
S3‑182571 Privacy - addressing ENs Ericsson CR Agreement
7.1.14Privacy
 		Yes
Yes
 		agreed No   S3‑182375
S3‑182572 LS Reply on Control Plane Solution for Steering of Roaming in 5GS GSMA LS in discussion
7.4.14PLMN RAT selection (Steering of Roaming) (Rel-15)
 		Yes
YesPostponed until receiving some guidance from plenary.
 		postponed No    
S3‑182573 Clarification to key hierarchy Nokia, Nokia Shanghai Bell CR -
7.1.1Key hierarchy
 		Yes
Yes
 		agreed No   S3‑182437
S3‑182574 CR on reigstration procedure for mobility from 4G to 5G Qualcomm Incorporated CR Agreement
7.1.10Interworking
 		Yes
Yes
 		agreed No   S3‑182486
S3‑182575 Clarifications related to the NAS Container calculation during inter system handover Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		agreed No   S3‑182401
S3‑182576 Removal of editor’s note on harmonization between inter and intra system handovers Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		agreed No   S3‑182400
S3‑182577 A scenario on secure communication for shared bikes Alibaba (China) Group., Ltd., China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		withdrawn Yes    
S3‑182578 AKMA Architecture for Non-3GPP Credential Download Alibaba (China) Group., Ltd., China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		withdrawn Yes    
S3‑182579 CR on corrections on the 5GS to EPS handover procedure Qualcomm Incorporated CR Agreement
7.1.10Interworking
 		Yes
Yes
 		agreed No   S3‑182491
S3‑182580 LS on NAS parameter for 5GS to EPS HO Qualcomm Incorporated LS out Approval
7.1.10Interworking
 		Yes
Yes
 		approved No   S3‑182492
S3‑182581 Corrections and clarifications to interworking clauses Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		agreed No   S3‑182399
S3‑182582 Addition of definitions and corrections to references Nokia, Nokia Shanghai Bell CR -
7.1.16Others
 		Yes
YesNokia pointed out that the corrected definition on “authentication data” in this CR points to a related topic that needs to be addressed. CT4 29.505 and SA3 33.501 have a different meaning of “authentication data” related to UDM/UDR. Also Nudr service details related to security are missing. It was asked how to solve this and which group is responsible? Nokia encouraged to discuss the details offline and offered to take the lead. Nokia aso stated that the background was available in an email sent to the SA3 reflector.
 		agreed No   S3‑182441
S3‑182583 CR to clarify username in Annex C Nokia,Nokia Shanghai Bell CR Approval
7.1.2Key derivation
 		Yes
Yes
 		agreed No   S3‑182199
S3‑182584 Clause 6.7.3.2 - Modification on algorithm selection during N2 handover ZTE Corporation CR Approval
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑182181
S3‑182585 Clause 6.9.2 - Modification on security handling during handover ZTE Corporation,Ericsson CR Approval
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑182184
S3‑182586 Mobility – Rectification of NAS MAC calculation for NAS Container Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑182368
S3‑182587 Mobility – Rectification of how DL NAS COUNT is transferred in NAS Container Ericsson CR Agreement
7.1.3Mobility
 		No
Yes
 		withdrawn Yes    
S3‑182588 CR on N2 based HO Qualcomm Incorporated CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑182489
S3‑182589 Update on SEAF requirements Nokia, Nokia Shanghai Bell CR -
7.1.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑182440
S3‑182590 Simplification of the UE handling of keys at handover Qualcomm Incorporated CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182483
S3‑182591 Mobility – Resolving EN and corrections in AS re-keying Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑182366
S3‑182592 Draft TS 33.511 Huawei draft TS Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No    
S3‑182593 Update to WID 5G SCAS Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, China Unicom, CATT, Deutsche Telekom, ZTE, Samsung, KPN, NEC, British Telecom, China Mobile, Ericsson WID revised Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		agreed No   S3‑182525
S3‑182594 Document Skeleton for TS 33.512, based on TS 33.116 Deutsche Telekom AG draft TS Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		approved No   S3‑182331
S3‑182595 Skeleton for TS 33.513 Samsung draft TS -
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
Yes
 		approved No   S3‑182504
S3‑182596 Draft TS 33.513 Samsung draft TS Approval
7.2.3User Plane Function (UPF) (TS 33.513)
 		Yes
Yes
 		approved No    
S3‑182597 Draft TS 33.514 NEC draft TS Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
Yes
 		approved No    
S3‑182598 Skeleton for TS 33.514 SCAS UDM NEC Corporation pCR Approval
7.2.4Unified Data Management (UDM) (TS 33.514)
 		Yes
YesClause 4 is gone.
 		approved No   S3‑182420
S3‑182599 skeleton of TS 33515 Huawei, Hisilicon draft TS Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No   S3‑182306
S3‑182600 Draft TS 33.515 Huawei draft TS Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No    
S3‑182601 [MCPTT] 33180 R15 Fix XML schema Motorola Solutions UK Ltd. CR Agreement
7.4.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑182222
S3‑182602 Alignment of terminology in RRCConnctionReestablsihment Procedure in R14 Huawei, Hisilicon CR Approval
7.4.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑182298
S3‑182603 Alignment of terminology in RRCConnctionReestablsihment Procedure in R15 Huawei, Hisilicon CR Approval
7.4.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑182299
S3‑182604 LTE EDT - Updates in suspend/resume Ericsson CR Agreement
7.4.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑182349
S3‑182605 LS on security aspects of EDT Ericsson LS out Approval
7.4.1SAE/LTE Security
 		Yes
Yes
 		approved No    
S3‑182606 Update NDS/IP scope with application layer crypto profiles Juniper Networks CR -
7.4.3Network Domain Security (NDS)
 		Yes
Yes
 		agreed No   S3‑182167
S3‑182607 Update NDS/IP scope with application layer crypto profiles Juniper Networks CR -
7.4.3Network Domain Security (NDS)
 		No
Yes
 		withdrawn Yes    
S3‑182608 Clarify NDS/AF intro regarding crypto profiles Juniper Networks CR -
7.4.3Network Domain Security (NDS)
 		Yes
Yes
 		agreed No   S3‑182169
S3‑182609 Clarify NDS/AF intro regarding crypto profiles Juniper Networks CR -
7.4.3Network Domain Security (NDS)
 		No
Yes
 		withdrawn Yes    
S3‑182610 Modifications on Security procedures for API invoker onboarding Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182276
S3‑182611 EDCE5 security requirements and corresponding test cases for MeNB Huawei, Hisilicon CR Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		No
Yes
 		withdrawn Yes    
S3‑182612 Clarifications in TS 33117 Huawei, Hisilicon CR Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑182316
S3‑182613 Generic description of security elements Nokia, Nokia Shanghai Bell CR -
7.1.16Others
 		Yes
Yes
 		agreed No   S3‑182436
S3‑182614 Clarifications on the calculation of NAS-MAC for RRCConnection re-establishmentwith Control Plane CIoT optimisations (Rel-14) Qualcomm Incorporated CR Agreement
7.4.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		agreed No   S3‑182473
S3‑182615 Clarifications on the calculation of NAS-MAC for RRCConnection re-establishmentwith Control Plane CIoT optimisations (Rel-15) Qualcomm Incorporated CR Agreement
7.4.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		agreed No   S3‑182474
S3‑182616 LS on using same counters in EDCE5 Ericsson LS out Approval
7.4.11EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)
 		Yes
Yes
 		approved No    
S3‑182617 Reply to: LS on CAPIF4xMB Samsung LS out approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
YesAnswering the question on authentication and authorization.
 		approved No    
S3‑182618 Security requirements for API invoker onboarding and offboarding Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182275
S3‑182619 Clarification on Security protections in CAPIF-1 and CAPIF-2 reference point Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182277
S3‑182620 [CAPIF_Sec] 33122 R15 access token profile Motorola Solutions UK Ltd. CR Agreement
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182216
S3‑182621 Clarification on access token verification Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182278
S3‑182622 [CAPIF-Sec] 33122 correct note in clause 6.5.2.1 Motorola Solutions UK Ltd. CR Agreement
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182218
S3‑182623 FC value in TS 33.220 Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182280
S3‑182624 Adding FC value to TS 33.122 Huawei, Hisilicon CR Approval
7.4.13Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182281
S3‑182625 Study of KDF negotiation for 5G System Security Huawei, Hisilicon, SID new Approval
8.10New study item proposals
 		Yes
YesORANGE: overlapping with our study in LTE-CUP. AT&T supported this SID. Qualcomm: RAN related stuff should go to a different SID. A single SID with a long list of objectives woud be too much and this is the way other 3GPP WGs are working this way. ORANGE supported this.
 		agreed No   S3‑182244
S3‑182626 Adding BEST Support for non-IP PDN Connections that Terminate at the SCEF Convida Wireless, InterDigital, Inc. CR Approval
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182119
S3‑182627 CR to TS 33.163 (BEST) - correction of Tag values Vodafone Espańa SA CR Agreement
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑182456
S3‑182628 Discussion and pCR for identity key issue of AKMA China Mobile, DT, KPN, Alibaba (China) Group., Ltd. pCR -
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		withdrawn Yes    
S3‑182629 Reply to: LS OUT on OAuth 2.0 Ericsson LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		approved No    
S3‑182630 Reply to: LS OUT on TLS and inter PLMN routing NTT-Docomo LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		approved No    
S3‑182631 EPC solution for RLOS access Intel Corporation (UK) Ltd pCR -
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑182632 Reply to: LS on initial NAS message protection NTT-Docomo LS out approval
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		approved No    
S3‑182633 WI Summary for 5G_Ph1-sec NTT DOCOMO INC. WI summary Endorsement
7.1.16Others
 		Yes
Yes
 		endorsed No   S3‑182524
S3‑182634 Study on 5G security enhancement against false base stations Apple Computer Trading Co. Ltd SID new Approval
8.10New study item proposals
 		Yes
Yes
 		revised No S3‑182704 S3‑182249
S3‑182635 Clause 5.2.5 - Modification on subscriber privacy ZTE Corporation CR Approval
7.1.14Privacy
 		Yes
Yes
 		agreed No   S3‑182171
S3‑182636 Mobility – Corrections for usage of local policy at AMF Ericsson,ZTE,Nokia CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑182367
S3‑182637 LS on security issues on Multi NAS scenarios Qualcomm LS out Approval
7.1.5NAS security
 		Yes
Yes
 		approved No    
S3‑182638 K_AMF change indication in NAS SMC Qualcomm Incorporated,Ericsson CR Agreement
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑182487
S3‑182639 Use the old KRRCint for calculation of the security token in MSG3 Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182377
S3‑182640 Reply LS on inactive security Ericsson LS out Approval
7.1.4AS security
 		Yes
Yes
 		approved No   S3‑182354
S3‑182641 CR to add a missing step to discover an NF producer instance during Access Token Request Nokia,Nokia Shanghai Bell,Ericsson,Huawei CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑182273
S3‑182642 CR to add Access Token Request procedure for a specific NF service producer Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑182274
S3‑182643 CR on mandatory ciphering of access tokens by NRF in inter-PLMN scenarios Nokia,Nokia Shanghai Bell CR Agreement
7.1.13.2Other
 		No
Yes
 		withdrawn Yes    
S3‑182644 UP policy check Qualcomm Incorporated,ZTE,CATT CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182488
S3‑182645 Clause 6.6.2 - Modification on UP security activation mechanism ZTE Corporation CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182180
S3‑182646 Algorithm Negotiation for Unauthenticated UEs in LSM Huawei, HiSilicon, China Mobile.Ericsson CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182237
S3‑182647 Clarifications in TS 33117 Huawei, Hisilicon CR Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No    
S3‑182648 DC - definition corrections Ericsson,CATT CR Agreement
7.1.4AS security
 		Yes
YesIncludes the definition part of tdoc 2231.
 		agreed No   S3‑182350
S3‑182649 Other Security Procedures for Dual Connectivity Huawei, HiSilicon,Ericsson,CATT CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182260
S3‑182650 Align AS SMC procedure with SA2 and RAN3 Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182301
S3‑182651 CR to delete ENs in clause 5.3 gNB Requirements Nokia, Nokia Shanghai Bell CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182205
S3‑182652 Update of definition of 5G AS security context for 3GPP access Ericsson CR Agreement
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑182376
S3‑182653 Define and clarify ABBA parameter Nokia, Nokia Shanghai Bell CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑182209
S3‑182654 Multiple NAS connections: taking a new security context into use on non-3GPP access Ericsson CR Agreement
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑182411
S3‑182655 Clause 6.9.5.1 - Add rule for concurrent running of security procedures ZTE Corporation,Qualcomm CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑182193
S3‑182656 Clause 6.9.5.2 - Modify rule for concurrent running of security procedures ZTE Corporation,Ericsson,Qualcomm CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑182194
S3‑182657 Editorial corrections to TS 33.501 Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑182279
S3‑182658 Corrections on primary authentication Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑182284
S3‑182659 Removal of Note 2a on Kausf use case restriction NEC Corporation CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑182417
S3‑182660 Clarification on Storage of SUPI at SEAF NEC Corporation CR Approval
7.1.8Primary authentication
 		No
Yes
 		withdrawn Yes    
S3‑182661 LS-out-to-SA2-on secondary re-authentication Huawei, HiSilicon LS out Approval
7.1.9Secondary authentication
 		Yes
Yes
 		approved No   S3‑182270
S3‑182662 Correction of Note on physical protection for NDS/IP use Ericsson CR Agreement
7.1.12NDS
 		Yes
Yes
 		agreed No   S3‑182403
S3‑182663 Protection of non SBA interfaces internal to 5G core. Deutsche Telecom AG CR -
7.1.12NDS
 		Yes
Yes
 		agreed No    
S3‑182664 Editorial changes to clause 9 Nokia, Nokia Shanghai Bell CR -
7.1.16Others
 		Yes
Yes
 		agreed No   S3‑182438
S3‑182665 SID on Enhanced network Slicing Nokia, Nokia Shanghai Bell,NEC, Huawei, HiSilicon,Motorola Mobility, Lenovo SID new Approval
8.10New study item proposals
 		Yes
Yes
 		agreed No   S3‑182212
S3‑182666 Mobility – Clarification in intra-gNB-CU handover Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑182363
S3‑182667 LS on calculation of inactive MAC-I token Samsung LS out Approval
7.1.4AS security
 		Yes
Yes
 		approved No    
S3‑182668 LS on inidication for keys syncronization ZTE LS out Approval
7.1.3Mobility
 		Yes
Yes
 		approved No    
S3‑182669 revised WID 5G Phase one security NTT-Docomo WID revised Agreement
7.1.16Others
 		Yes
Yes
 		agreed No    
S3‑182670 Adding OAuth related authorization services for SBA security Huawei, Hisilicon CR Approval
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑182453
S3‑182671 New WID on security aspects of single radio voice continuity from 5G to 3G China Unicom, Huawei, HiSilicon, ZTE, CATT, OPPO WID new -
7.5New Work Item proposals
 		Yes
YesORANGE asked if the study was considered as finsihed and the TR sent for approval. BT proposed to send it for information, given that the spec was still missing the SA requirement. Huawei commented that the SA2 WID was to be finished in December. The Chair commented that SA3 usually finished a cycle later than SA2 and that there was no rush. This was a Rel-16 Work Item. Docomo: impact on 5G security needs to be clarified before we go for a WID. The Chair noted the WID and asked China Unicom to bring the WID back for the next meeting. The TR 33.856 was to be sent for information to SA.
 		noted No   S3‑182334
S3‑182672 Draft CR on Application layer security on the N32 interface Nokia draftCR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑182673  
S3‑182673 Draft CR on Application layer security on the N32 interface Nokia draftCR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
YesIt merges all content for the draft CR.
 		approved No   S3‑182672
S3‑182674 LS on Specification of the EAS-C/U interfaces for BEST InterDigital, Inc. LS out Agreement
7.4.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑182120
S3‑182675 Support of 256-bit algorithms: references Gemalto N.V. pCR Approval
8.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182468
S3‑182676 Draft TR 33.841 Vodafone draft TR Approval
8.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑182677 Study on the supporting of perfect forward secrecy for 5G Authentication and Key Agreement Protocols Huawei SID new Agreement
8.10New study item proposals
 		No
Yes
 		withdrawn Yes    
S3‑182678 New SID on Security of the enhancement to the 5GC location services CATT SID new Agreement
8.10New study item proposals
 		Yes
Yes
 		agreed No   S3‑182250
S3‑182679 The SID on security for 5G URLLC Huawei, HiSilicon SID new Approval
8.10New study item proposals
 		Yes
Yes
 		agreed No   S3‑182265
S3‑182680 Clarification to support of authentication methods Nokia, Nokia Shanghai Bell CR -
7.1.8Primary authentication
 		Yes
YesORANGE didn’t support the added note. It's confusing and it's not adding anything. Nokia commented that they got questions from operators on how they had to choose. IDEMIA didn’t see the need for this note. Ericsson commented that this was just a note, no wrong technical issue here. Qualcomm: if we are having this confusion here, this needs to be clarified to the outside world.
 		not pursued No   S3‑182443
S3‑182681 New SID on SECAM and SCAS for 3GPP virtualized network products China Mobile, Nokia, Nokia Shanghai Bell, China Unicom, CAICT, CATT, ZTE SID new -
8.10New study item proposals
 		Yes
Yes
 		agreed No   S3‑182427
S3‑182682 Study on Security for 5GS Enhanced support of Vertical and LAN Services Nokia, Nokia Shanghai Bell SID new -
8.10New study item proposals
 		Yes
Yes
 		agreed No   S3‑182445
S3‑182683 TR 33.855 Deutsche Telekom draft TR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑182684 a proposal for the key issue on protecting the SRVCC capability of TR33.856 Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182289
S3‑182685 Draft TR 33.856 China Unicom draft TR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑182686 a proposal for protecting the SRVCC capability of TR33.856 Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182290
S3‑182687 evaluation of solution 1.1 for KI#1 Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182288
S3‑182688 Evaluation for solution #1.1 China Unicom pCR -
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182336
S3‑182689 Evaluation for solution #1.2 China Unicom pCR -
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182338
S3‑182690 Evaluation for solution #1.3 China Unicom pCR -
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182347
S3‑182691 conclusion for key issue on protecting the SRVCC capability in initial NAS message Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182291
S3‑182692 Propose the content of conclusions China Unicom pCR -
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182391
S3‑182693 editorial modification on TR33.856 Huawei, Hisilicon pCR Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182286
S3‑182694 Key Issue on Authentication Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑182695 Key Issue on secure communication between UE and 3rd party application server China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
YesClause 3.1 (offline discussion bullets) was endorsed. ORANGE considered that submitting a new key issue this late was not appropriate and the he needed more time to study it.
 		noted No    
S3‑182696 LTKUP: solution#5 evaluation Gemalto N.V. pCR Approval
8.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)
 		Yes
Yes
 		approved No   S3‑182466
S3‑182697 Clarifications in clause 13.5 Ericsson CR Agreement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		agreed No    
S3‑182698 SA3 meeting calendar MCC other -
10Future Meeting Dates and Venues
 		Yes
Yes
 		noted No   S3‑182104
S3‑182699 Work Plan input from Rapporteurs MCC other -
9.2Rapporteur input on status of WID or SID
 		No
Yes
 		noted No   S3‑182105
S3‑182700 Application layer security on the N32 interface Nokia CR Agreement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		agreed No    
S3‑182701 Update to LS on Implementation of NESAS Pilot Findings in SCAS specifications Nokia, Nokia Shanghai Bell LS out Approval
7.4.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		approved No   S3‑182346
S3‑182702 Draft TR 33.834 Vodafone draft TR Approval
8.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑182703 Cover sheet for TR 33.856 China Unicom TS or TR cover Approval
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
YesTR 33.856 is sent for information.
 		approved No    
S3‑182704 Study on 5G security enhancement against false base stations Apple Computer Trading Co. Ltd SID new Approval
8.10New study item proposals
 		Yes
Yes
 		agreed No   S3‑182634