Tdoc List

2019-05-10 15:43

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑191100 Agenda WG Vice Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No    
S3‑191101 Report from SA4#94AH MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
Yes
 		approved No    
S3‑191102 SA3 Work Plan MCC Work Plan  
9.1Review of work plan
 		Yes
Yes
 		noted No    
S3‑191103 Report from last SA meeting WG Vice Chairman (Qualcomm) report  
4.2Report from SA Plenary
 		Yes
Yes
 		noted No    
S3‑191104 SA3 meeting calendar MCC other  
10Future Meeting Dates and Venues
 		Yes
Yes
 		revised No S3‑191793  
S3‑191105 Work Plan input from Rapporteurs MCC other  
9.2Rapporteur input on status of WID or SID
 		Yes
Yes
 		revised No S3‑191792  
S3‑191106 Discussion on possible privacy/confidentiality attacks in PLMN integrated NPN InterDigital discussion Endorsement
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191107 New KI for PLMN integrated NPN InterDigital pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191596  
S3‑191108 TCG progress report InterDigital other Information
6.6TCG
 		Yes
Yes• Publication of new or revised deliverables (incremental changes from the status reported at SA3#94): o TCG TSS 2.0 TAB and Resource Manager – published April 2019 o TCG TSS 2.0 TPM Command Transmission Interface (TCTI) – published April 2019 o TCG TSS 2.0 System Level API (SAPI) – public review April 2019 o TCG TSS 2.0 Enhanced System Level API (ESAPI) – public review April 2019 o TCG PC Client Device Driver Design Principles for TPM 2.0 – public review February 2019 o TCG Platform Certificate Profile – public review February 2019 o TCG Trusted Platform Module 2.0 r1.50 – public review January 2019 o TCG TSS 2.0 Response Code API – public review January 2019 o TCG Trusted Attestation Protocol (TAP) Information Model – public review January 2019 2. Meetings • TCG Members Meeting in Warsaw, Poland – 10-13 June 2019 • TCG Annual Members Meeting in Toronto, Canada - 15-17 October 2019 • MPWG meets every Thursday at 10-11 ET • TMS WG meets every Monday and Friday at 12-13 ET • CyRes WG meets every Wednesday at 11-12:30 ET
 		noted No    
S3‑191109 New Key Issue for TR 33.836 - privacy protection for unicast messages over PC5 InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesBT: split between short term and long term linkabilities. These are two different scenarios. We have to avoid tracking vehicles in the long term, for example. An editor's note was added to that effect.
 		revised No S3‑191746  
S3‑191110 New Key Issue for TR 33.836 - privacy protection for multicast messages over PC5 InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		revised No S3‑191670  
S3‑191111 New Key Issue for TR 33.836 - security for eV2X unicast messages over PC5 InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesLG and Qualcomm had their doubts on the last wo requirements. MCC had doubts on the "shall be used and protected" or "shall be supported and may be used" wordings. Qualcomm: further requirements are FFS. MCC: "shall be supupported and may be used", the "may be used" is already in the meaning of "supported". Qualcomm: add reference to the PROSE spec for the NOTE.
 		revised No S3‑191747  
S3‑191112 New Key Issue for TR 33.836 - Security of the UE service authorization and revocation InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesGemalto: "shall provide means" is too vague. Qualcomm: is this key issue going to the normative phase in SA2? Is the revocation in scope? An editor's note was added to check this in the future.
 		revised No S3‑191749  
S3‑191113 [MCPTT] 33179 R13. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
YesMotorola: it should be 40 bits. Airbus: the way it is written it refers to 32 bits. Motorola: standards says 32 bits, errata says 40 bits. We need to use 40 bits.
 		revised No S3‑191641  
S3‑191114 [MCSec] 33180 R14. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑191642  
S3‑191115 [MCSec] 33180 R15. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑191643  
S3‑191116 New Key Issue for TR 33.836 - Security of the UE service provisioning InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑191117 References InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQualcomm, MCC: add the references in the contributions where they are mentioned.
 		approved No    
S3‑191118 Update to solution #4 InterDigital Belgium. LLC pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: clarify the dependency between the RAT and access type.The document was revised to address this.
 		revised No S3‑191734  
S3‑191119 Reply LS on securing warning messages in ePWS C1-191522 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑191120 Reply LS on securing warning messages in ePWS S1-190503 LS in  
6.13GPP Working Groups
 		Yes
YesBT: PWS has regulatory requirements identified,but SA1 says that this is not the case. Vice Chair: maybe this refers to ePWS, not PWS. Nokia: no specific requirements for IoT devices as opposed to humans. Vodafone: what does an IoT unit do with this message? Ericsson: CT1 decides the specific requirements and they said in the other LS that they haven't concluded this. Vodafone: if the early warning message is a piece of text we would have concerns about this. Vodafone was to ask their SA1 delegates about this for more clarification and maybe respond to SA1. This was taken offline. Nokia: IoT devices can be very different.
 		noted No    
S3‑191121 LS on Use of SUCI in NAS signalling C1-191685 LS in  
7.1.14Privacy
 		Yes
Yes
 		replied to No    
S3‑191122 LS on handling of non-zero ABBA value in Release 15 C1-191686 LS in  
7.1.5NAS security
 		Yes
Yes
 		replied to No    
S3‑191123 LS on SUPI formats for 5WWC C1-192776 LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191124 LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode C1-192804 LS in  
7.1.5NAS security
 		Yes
YesTdocs 452, 501, 502,503 are related documents. Tentative response from Qualcomm in 505.
 		replied to No    
S3‑191125 Reply LS on EAS-C&U support C3-191167 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑191126 LS on usage of EPLMNs S2-1904825 LS in  
6.13GPP Working Groups
 		Yes
YesRelated discussion paper in 462.
 		replied to No    
S3‑191127 Reply LS on Interim conclusions for SA2 study on Radio Capabilities Signalling Optimisations (FS_RACS) C4-190346 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑191128 Reply LS on Verification of PLMN-ID in the SEPP C4-190348 LS in  
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		replied to No    
S3‑191129 Reply LS on GTP Recovery Counter & GSN node behaviour C4-190485 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑191130 Reply LS on Nudr Sensitive Data Protection C4-190534 LS in  
7.1.16Others
 		Yes
Yes
 		replied to No    
S3‑191131 LS on Maximum HTTP payload size C4-190609 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191132 LS on Protected LI Parameters in N4 S3i190254 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
YesBT: LTE solution has security weaknesses to be hardened in 5G.
 		noted No    
S3‑191133 Reply LS on Protected LI Parameters in N4 C4-191529 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191134 Reply on LS on Protected LI Parameters in N4 S3i190283 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191135 LS on Handling of non-essential corrections (non-FASMO) CRs and non-backwards compatible CRs CP-190218 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑191136 LS on the availability of and requesting feedback on the stable draft TR 103 582 from ETSI STF555 - "Study of use cases and communications involving IoT devices in emergency situations" ETSI SC EMTEL LS in  
6.11Other Groups
 		Yes
YesVodafone: we already missed the deadline given in here, so I propose to postpone this for the next meeting.
 		postponed No    
S3‑191137 GSMA DESS - Diameter IPX Network End-to-End Security Solution GSMA LS in  
6.4GSMA
 		Yes
YesSpecific action for SA3, so this LS was postponed for the next meeting.
 		postponed No    
S3‑191138 Reply LS on Authentication for UEs not Supporting NAS S2-1904829 LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		replied to No    
S3‑191139 Response to 3GPP SA2 liaison S2-1902902 on ‘LS on updating the status of 5WWC normative work’ BBF LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191140 Reply LS on EDT integrity protection R2-1902439 LS in  
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		replied to No    
S3‑191141 LS on RAN2 conclusion for NR positioning SI R2-1902479 LS in  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		replied to No    
S3‑191142 LS on RAN2 conclusion for NR positioning SI R3-191141 LS in  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191143 Reply LS on Dual Connectivity R2-1902677 LS in  
7.1.4AS security
 		Yes
Yes450 related to this LS.
 		noted No    
S3‑191144 Reply LS on Enforcement of maximum supported data rate for integrity protection R2-1902700 LS in  
7.1.4AS security
 		Yes
Yes
 		noted No    
S3‑191145 LS on protection of PC5-RRC messages for sidelink unicast communication R2-1905332 LS in  
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		replied to No    
S3‑191146 Response LS on full data rate support for UP IP R2-1905455 LS in  
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesLenovo: what are the implications of this in our study? Qualcomm replied that SA3 should focus on the LTE part, and for the NR it is fine to meet the requirement. Huawei: it seems that they didn’t get our requirement.
 		noted No    
S3‑191147 LS on Security failure of NAS container in HO command R2-1905460 LS in  
7.1.5NAS security
 		Yes
Yes419,449 and 512 handle this issue.
 		replied to No    
S3‑191148 LS on broadcast assistance data delivery R2-1905462 LS in  
6.13GPP Working Groups
 		Yes
YesQualcomm had a discussion paper in tdoc 520 proposing a reply.CATT also proposed a reply in 350.
 		replied to No    
S3‑191149 LS to SA2 and SA5 on IAB impact to CN R2-1905475 LS in  
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑191150 Response LS on reporting all cell IDs in 5G R3-191111 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191151 Response LS on reporting all cell IDs in 5G S2-1904819 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191152 Response LS on reporting all Cell IDs in 5G S3i190265 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191153 Reply LS on UP Integrity Protection for Small Data in Early Data Transfer R3-191116 LS in  
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesRAN3 will be included in the response for RAN2 LS.
 		noted No    
S3‑191154 Reply LS on authentication of group of IoT devices S1-190501 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		replied to No    
S3‑191155 Reply LS on Interception of voice services over new radio in a 5GS environment S2-1902799 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191156 Reply LS on Clarification of UE Trace support S2-1902901 LS in  
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		noted No    
S3‑191157 LS on LI Impacts for LMR-LTE Interworking study S3i190281 LS in  
7.3eMCSec R16 security (MCXSec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191158 Approval of Smart Secure Platform requirement specification ETSI TC SCP LS in  
6.11Other Groups
 		Yes
Yes
 		noted No    
S3‑191159 LS/r on SG17 work item X.5Gsec-q: Security guidelines for applying quantum-safe algorithms in 5G systems ITU-T SG17 LS in  
6.11Other Groups
 		Yes
Yes
 		noted No    
S3‑191160 LS on SG17 new work item X.5Gsec-ecs: Security Framework for 5G Edge Computing Services ITU-T SG17 LS in  
6.11Other Groups
 		Yes
YesChina Unicom presented the document and commented that they were also participating.
 		noted No    
S3‑191161 LS to request inputs on the Vehicular Multimedia technical report and to invite participation from relevant stakeholders ITU-T Focus Group on Vehicular Multimedia (FG-VM) LS in  
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑191162 Reply LS on User Plane Security for 5GC Roaming SP-190252 LS in  
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑191163 Clarification of MSIN coding for the ECIES protection shemes IDEMIA,Gemalto, Qualcomm,Ericsson,Huawei,HiSilicon CR Approval
7.1.14Privacy
 		Yes
YesDiscussed with 261.
 		revised No S3‑191624  
S3‑191164 New KI for Public network integrated NPN InterDigital Germany GmbH pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191597  
S3‑191165 [33.179] R13 XSD Corrections Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑191166 [33.180] R14 XSD Corrections Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑191167 [33.180] R15 XSD Corrections (mirror) Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No    
S3‑191168 {33.179] R13 Remove IANA editor's notes Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑191644  
S3‑191169 [33.180] R14 Remove IANA editor’s notes Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑191645  
S3‑191170 [33.180] R15 Remove IANA editor’s notes (mirror) Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		revised No S3‑191646  
S3‑191171 [33.180] R16 Pre-established PCK Motorola Solutions UK CR Agreement
7.3eMCSec R16 security (MCXSec) (Rel-16)
 		Yes
Yes
 		revised No S3‑191647  
S3‑191172 Interface and protocol stack clarifications and corrections to TS 33.163 Juniper Networks CR Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
YesVodafone: it is not 4 scenarios but three in here. Juniper: four scenarios in Rel-16.
 		revised No S3‑191635  
S3‑191173 Interface and protocol stack clarifications and corrections to TS 33.163 Juniper Networks CR Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑191636  
S3‑191174 Making UE initiated key refresh optional in TS33.163 Juniper Networks CR  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
YesIt was queried whether there was work planned for Rel-16. Vodafone commented that a WID was planned for Rel-17. MCC reminded about the SA's statement on the use of TEI16 WID code and eventually the WID code for Rel-15 was also added in the cover page.
 		revised No S3‑191637  
S3‑191175 Corrections for Key Issue #27 Support of a UP gateway function on the N9 interface Juniper Networks pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑191176 Solution to KI #26: NDS/IP on the inter-PLMN N9 interface Juniper Networks pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		withdrawn Yes    
S3‑191177 Discussion document on roaming UP gateway Juniper Networks discussion Endorsement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesEricsson: we should study this properly with direct contributions to the TR, instead of discussion papers. Hans (DT) commented that available solutions needed to be discussed and this is what was done in this paper. Ericsson: postpone this for the next meeting with conclusions and evaluations. There was support to endorse this paper so a revision number was given to reformulate the proposal.
 		revised No S3‑191666  
S3‑191178 Solution for KI #27: Roaming UP gateway Juniper Networks pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑191661  
S3‑191179 Update of solution #17 – Efficient key derivation for e2e security KPN pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191180 Update of Solution #6 – Use of UE Configuration Update KPN pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEditor's note on maximum amount of minutes as proposed by Vodafone. Vodafone: more likely that it's an malicious application. Evaluation part was removed.
 		revised No S3‑191680  
S3‑191181 Addition of Network Product Class Description for AMF Deutsche Telekom AG CR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
YesMCC was hesitant about referring to Release 16 version of TS 23.501. The reference pointed to Rel-16 by default. Ericsson commented that in fact the reference should be for the Release 15 version of TS 23.501. It was decided to work with draftCRs so this was converted into a new document in 653.
 		not pursued No    
S3‑191182 Addition of AMF-related Security Problem Descriptions Deutsche Telekom AG CR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
YesHuawei: add the threat rational.
 		revised No S3‑191654  
S3‑191183 On configurational error handling on N32 by the receiving SEPP Deutsche Telekom AG discussion Endorsement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑191184 Addition of SEPP requirement on configurational error handling Deutsche Telekom AG draftCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		withdrawn Yes    
S3‑191185 Addition of missing SEPP requirement on JOSE-patch validation Deutsche Telekom AG CR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
YesNokia: modify the following sentence instead of adding the new sentence.
 		revised No S3‑191616  
S3‑191186 Testcase: Replacing confidential IEs with NULL in original N32-f message Deutsche Telekom AG pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		revised No S3‑191657  
S3‑191187 AKMA solution set analysis KPN discussion Discussion
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191188 Proposal for editor's notes in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: this needs rewriting. Qualcomm suggested an editor's note. Vodafone wanted a statement in the evaluation on injected first messages. MCC added that the use of "must" was not allowed in 3GPP and it needed rewording.
 		revised No S3‑191687  
S3‑191189 Proposal for improvement FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑191686  
S3‑191190 New solution to key issue 5 in TR 33.814 (FS_eLCS_Sec): UE faking/altering location measurements Philips International B.V. pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesORANGE: there are no requirements.
 		noted No    
S3‑191191 Proposal for FS_UP_IP_Sec Key Issue #3 and 5: Zero-overhead user plane integrity protection on the link layer Philips International B.V. pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑191691  
S3‑191192 New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC CableLabs pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191193  
S3‑191193 New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC CableLabs pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191702 S3‑191192
S3‑191194 IAM Security AT&T,Interdigital discussion  
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesEricsson: we are aligned with AT&T's view.Qualcomm also shared their opinion and they had related contributions. Huawei commented that they had contributions addressing this as well. Alex(BT): make sure that this will scale out in software.
 		noted No    
S3‑191195 Using symmetric algorithm with assistance of USIM and home network ZTE Corporation pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No    
S3‑191196 way forward against attack using authentication ZTE Corporation discussion Endorsement
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
YesZTE: this involves both Rel-15 and Rel-16. Gemalto: how and where to address this topic? Rel-15 or Rel-16? Ericsson: all contributions changing the core of SA3 cannot be handled in Rel-15 at this stage. Nokia: we are touching the core of authentication mechanism so this needs to be analysed carefully. It was commented that this content was related to the study in 8.19. The CRs in that case would not be considered as such in the study, but as pseudo CRs.
 		noted No    
S3‑191197 Structure RAND for authentication – HE part ZTE Corporation CR Agreement
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191198 Structure RAND for authentication – ME part ZTE Corporation CR Agreement
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191199 Structure RAND for authentication – ME part ZTE Corporation CR Agreement
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191200 Handling of Sync failure for 5G AKA ZTE Corporation CR Agreement
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191201 Modification on linkability issue1 ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191202 Conclusion on linkability issue ZTE Corporation pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191203 KAUSF desynchronization problem and solutions NEC Europe Ltd discussion Information
7.1.2Key derivation
 		Yes
YesSuperseeded by tdoc 204.
 		noted No    
S3‑191204 KAUSF desynchronization problem and solutions – updated version after conf call on 25 Apr. NEC Europe Ltd discussion Endorsement
7.1.2Key derivation
 		Yes
YesQualcomm: we don’t agree with bullets 3,4 and 5. More analysis is needed and it should be considered for Rel-16, not Rel-15. Ericsson agreed with Qualcomm. NEC was fine with having the work in Rel-16 instead of Rel-15, for bullets 3-5. Qualcomm didn’t see a need for bullets 3-5, independently from the release. Huawei only supported bullet 2. Samsung didn't agree with 3-5 either. Nokia needed to look at proposal 2, not agreeing on the rest.
 		noted No    
S3‑191205 Aligning the storage timing of KAUSF in 5G AKA with EAP-AKA' NEC Europe Ltd CR Agreement
7.1.2Key derivation
 		Yes
YesNokia didn’t agree with the changes. It seemed that companies were OK with the idea, but the wording was not correct. Qualcomm: no impact on the ME.
 		revised No S3‑191603  
S3‑191206 Synchronization of KAUSF between AUSF and UE NEC Europe Ltd draftCR Discussion
7.1.2Key derivation
 		Yes
Yes
 		not pursued No    
S3‑191207 Using Key Identifiers between AUSF and UE for UPU and SoR NEC Europe Ltd draftCR Discussion
7.1.2Key derivation
 		Yes
Yes
 		noted No    
S3‑191208 UDM triggered authentication NEC Europe Ltd draftCR Discussion
7.1.2Key derivation
 		Yes
YesMore analysis was needed on this proposal. Ericsson: if this is for Rel-16 we need a new Work Item and it is too early for that.
 		noted No    
S3‑191209 KAUSF key setting in EAP AKA’ NEC Europe Ltd draftCR Discussion
7.1.2Key derivation
 		Yes
Yes
 		not pursued No    
S3‑191210 Discussion on AKMA overall conclusions NEC Europe Ltd discussion Endorsement
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191211 Resolving Editor’s Notes and adding conclusion to solution #18 (Key Separation for AKMA AFs using counters) NEC Europe Ltd pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191212 Resolving Editor’s Notes and adding conclusion to solution #20 (Key Identification when Implicit bootstrapping is used) NEC Europe Ltd pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191213 Restoring lost figures in the latest draft update of AKMA TR at SA3 #94ah NEC Europe Ltd pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191214 New Test Case: Error handling of malformed JSON object between two network products NEC Europe Ltd draftCR Agreement
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		revised No S3‑191487  
S3‑191215 Evaluation and text for resolving editor’s note for solution #5 in TR 33.825 NEC Europe Ltd pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191723  
S3‑191216 Initial Key Issues for TR 33.848 BT plc pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191721  
S3‑191217 Scope for TR 33 848 BT plc pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191714  
S3‑191218 Discussion on N9 security Deutsche Telekom AG, NTT Docomo discussion Endorsement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesEricsson: why is this a discussion and not a key issue? We have an ongoing study.
 		noted No    
S3‑191219 Solution to KI #26: NDS/IP on the inter-PLMN N9 interface Juniper Networks, Nokia pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesBT: add an editor's note on how the control plane enforces policy NDS/IP and N9 security. NTT-Docomo: not the control plane but the SMF who enforces the policy.
 		revised No S3‑191668  
S3‑191220 subscriber privacy: ECIES test data Gemalto, IDEMIA, Huawei, Hisilicon CR Approval
7.1.14Privacy
 		Yes
Yes
 		revised No S3‑191626  
S3‑191221 Discussion on proposed response to incoming LS (S3-191138) on authentication of UEs not supporting NAS Charter Communications, CableLabs discussion Discussion
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesOn question one: ORANGE: stick to what is written in TS 33.501. There are statements here that don’t adhere to what is in the spec. Ericsson: it is not sufficient because it is a Rel-15 spec and this is new material for Rel-16. BT didn’t agree, it's the storage what matters. Telecom Italia: SA2's interest lies in TS 33.501 annex B only. Cablelabs replied that there was a key issue on 5WWC. Charter communications: consider the Rel-16 context only, not Rel-15. AT&T: use the EAP framework if you want to use the 3GPP network. Charter Communications: this is cable access, not 3GPP access. ORANGE: if the use case is similar for non-public networks it is perfectly fine to use annex B of TS 33.501. In 5WWC the case is different. Nokia: is it possible for 3GPP to support this in Rel-16? Vodafone: Non private networks should not be in the scope of this TR, otherwise we will have a whole range of new use cases that will blur the security. Charter: Non public networks is another WID that doesn’t cover fixed access. Telecom Italia: 5WWC should not just use annex B, they need to stick to the TR. This had to be taken offline.
 		revised No S3‑191703  
S3‑191222 Virtualisation Background and Concepts NCSC pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191715  
S3‑191223 Discussion on structure of TR 33.848: Study on Security Impacts of Virtualisation NCSC discussion Discussion
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191224 Key Issue: Establishment of trust domains for Network Functions NCSC pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191716  
S3‑191225 Key Issue: Confidentiality of Sensitive Data NCSC pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191717  
S3‑191226 Key Issue: Availability of Network Functions NCSC pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191718  
S3‑191227 eNS Update to solution 1 Slice specific secondary authentication Nokia, Nokia Shanghai Bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesHuawei: some issues that were agreed not to have here are coming back: secondary authentication in step 11 for example. We should use the term "slice specific authentication". Huawei: this doesn’t address key issue 4 (privacy), remove it from the evaluation. Nokia: NAS messages are protected already, no parameter is exposed. ORANGE and Qualcomm agreed: adding a sentence clarifying this would be sufficient. Gemalto: the requirement doesn't show explicit end points, only addresses the privacy of the user.
 		revised No S3‑191730  
S3‑191228 Preliminary comparison of solutions Nokia, Nokia Shanghai Bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia clarified that this reflected results before the current meeting. The Chair asked if conclusions should be postponed to the next meeting. Telecom Italia: "not applicable" means no solution? Nokia confirmed this. The table was revised to address the results from the current meeting. Qualcomm: it shouldn't be a conclusion but in an annex. Nokia: the conclusion text should follow this. An overall evaluation clause was added to the conclusion in order to accommodate this table.
 		revised No S3‑191739  
S3‑191229 New KI: Separation of CP and UP in NAS CP Optimization 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
YesNokia admitted that this issue could be late for this Release and asked if it was to be pushed for the next release. Vodafone: this doesn’t seem to be a security issue. Qualcomm had the same concern. If CT groups had a problem with this they should contact SA3. CableLabs: this can cause denial of service. I agree with this key issue. Vodafone understood the idea but didn’t agree with the writing. Qualcomm: SA2 decided not to procceed with this one. ORANGE didn’t agree with this key issue. This was taken offline.
 		noted No    
S3‑191230 Discussion paper on Re-authentication and UE context handling Nokia, Nokia Shanghai Bell discussion Endorsement
7.1.8Primary authentication
 		Yes
YesEricsson: number 6 not to be handled in Rel-16. They didn't agree with the rest of the points. Qualcomm: this could create more issues than actually solving anything. Samsung supported point 6 (for Rel-16) but agreed with Qualcomm for the rest, on being careful with how to handle the issue. BT didn't agree with point 6 on the wording "in any scenario". This was taken offline
 		noted No    
S3‑191231 New KI: Updating UDM with UE deregistration status Nokia, Nokia Shanghai Bell pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191232 Nokia comments on LS R2-1905332 PC5-RRC message protection Nokia, Nokia Shnghai Bell discussion Endorsement
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑191233 Non-AKA based EAP methods with credentials stored and processed in UDM/ARPF CableLabs pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE didn’t agree with the key issue. The key hierarchy key issue is already covered somewhere else. Qualcomm argued that the use case was supported by the Rel-15 frameork
 		noted No    
S3‑191234 conclusion on KI#5 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesIt was queried whether anyone was going to bring another solution. Ericsson preferred to postpone this for the next meeting.
 		noted No    
S3‑191235 Resolve EN "signaling details of how the UE hands over to false base station Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191236 Solution #6: Resolve EN Handover Attemp Failure Counter Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191237 Solution#4: resolving EN network verification of the hashes of MIB/SIBs Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191238 Solution#4: Resolving EN Impact on UE power consumption Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191239 Solution #4: Details on the hash algorithm used for MIB/SIB hashes. Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191240 Secuirty threat for RRCResumeRequest tampering. Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No    
S3‑191241 Solution for protecting RRCResumeRequest against tampering Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No    
S3‑191242 Address EN in solution #1 “The above text needs to be updated ….” Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191243 Draft LS to RAN2 on UECapabilitiesEnquire after AS SMC Huawei, Hisilicon LS out Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191244 Discussion paper Security of Bulk IoT operations Huawei, Hisilicon discussion Endorsement
6.13GPP Working Groups
 		Yes
YesVodafone: it misses the point abut auth based on key sharing. ORANGE: SA2 and RAN groups should take care of this as well, not standalone SA3 work. Vodafone: IoT should be more secure, not less secure in our view. Huawei: SA1 is asking us about the authentication procedure. ORANGE: this is part of the registration procedure handled by SA2. IDEMIA agreed that his was to be treated firstly by SA2. BT: use case is about enabling/disabling large number of devices, so you should make it more secure. The term "operations" is more general. Huawei didn’t understand why this was necessarily less secure as stated by some companies. ORANGE: send an LS to SA1. Sony added that SA2 should be added to the recipients as well. The study item in 245 was postponed given that a response from SA1 was needed.
 		noted No    
S3‑191245 Study Item: Security of Bulk IoT operations Huawei, Hisilicon SID new Approval
8.23New study item proposals
 		Yes
Yes
 		postponed No    
S3‑191246 draft reply LS to RAN2/RAN3 on EDT UP IP Huawei, Hisilicon LS out Approval
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		revised No S3‑191634  
S3‑191247 CR for removing EDT UP IP solution using PDCP PDU hashes. Huawei, Hisilicon CR Approval
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		merged No S3‑191633  
S3‑191248 EDT UP IP for multiple PDCP PDUs Huawei, Hisilicon discussion Endorsement
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191249 update solution#4 with UP IP during EDT for multiple PDCP PDUs. Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesEricsson: split into two separate solutions. Overlapping with 437. Huawei: we are not bringing another solution, just details for an existing solution.
 		revised No S3‑191678  
S3‑191250 F1-U security analysis for IAB architecture Huawei, Hisilicon discussion Endorsement
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesORANGE: this challenges the TS 33.501 5G architecture. This is misplaced. Juniper, AT&T, Vodafone,BT objected to the document. ORANGE: f1 security activation is optional for the operator, this was agreed. Huawei: we didn’t analyse the security threats for f1. If there are no threats we don’t need the security requirement. Vodafone: we cannot be reactive, do something when we have a security threat. Not having identified the threat doesn't mean that there is no threat. NTT-Docomo didn’t agree with the way the document was written. There wasn't any support for this document, hence it was noted.
 		noted No    
S3‑191251 Enabling UE to detect FBS Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		noted No    
S3‑191252 Updating solution#7 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: this needs rewording. Ericsson: other Ues can take turns when attacking. Huawei: it's an engineering issue. Vodafone: there is no way of permanently block a misbehaving UE. Huawei: the gNodeB informs the core network to do something about it and we don’t specify more than that.
 		revised No S3‑191681  
S3‑191253 Clarification for F1-U protection Huawei, Hisilicon CR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesNTT-Docomo,ORANGE, AT&T: the change is not needed. Huawei: capture it in a note since this is confusing for external readers. Juniper didn’t agree with this CR either. Samsung supported the contribution since it was adding some clarification. Huawei: no security reason against this. In the end there was no agreement and the document was not pursued.
 		not pursued No    
S3‑191254 Key Issues on F1-U security for IAB architecture Huawei, Hisilicon pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑191255 F1-U security when UE UP is e2e PDCP protected Huawei, Hisilicon discussion Endorsement
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑191256 Protecting IOT Devices Against False Base Station Attacks Qihoo 360 discussion Discussion
8.9Study on 5G security enhancement against false base stations
Yes
YesDeutsche Telekom: what's the proposal to endorse? Qihoo: just for discussion. Apple: we can have key issues for these kind of devices. Huawei: we don’t know if this has any impact on our study. CableLabs: capture this content somewhere, it's a good input. The Chair suggested Qihoo360 to bring a pCR for the next meeting or some endorsement proposal. Huawei proposed a key issue for the CIoT study.
 		noted No    
S3‑191257 draft LS response to LS on Use of SUCI in NAS signalling Intel Corporation (UK) Ltd response  
7.1.14Privacy
 		Yes
Yes
 		noted No    
S3‑191258 Clarification on Subscription Identifier mechanism for De-registration. Intel Corporation (UK) Ltd CR  
7.1.14Privacy
 		Yes
YesNokia: the use of SUCI here opens a DoS attack scenario. Qualcomm: Deregistration with the SUCI would happen as part of the registration procedure. IDEMIA: in which case the 5G GUTI is not valid? This is what we need to identify. NTT-Docomo was concerned like Nokia as this could be misused. CableLabs didn’t agree with the attack scenario. Anja (Nokia): SUCI is a one time identifier by design. Qualcomm commented that there is a requirement where the UE will keep sending the same SUCI in a specific situation. Qualcomm: if you read the CT1 specification, it is up to AMF how to handle this. Nokia: CT1 inherited this case from LTE. It was allowed in LTE, but changes adopted for SUCI require a correction in CT1. This had to be taken offline.
 		revised No S3‑191751  
S3‑191259 Solution for integrity protection of UL EDT data Intel Corporation (UK) Ltd discussion Decision
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑191260 key issue for IAB Handover Intel Corporation (UK) Ltd pCR  
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesInterdigital: no connection between threats and requirements. Intel agreed to remove the requirements. Qualcomm didn’t understand the threats. IAB node communication security was to be covered in 698 and the UE handovers being transparent aspects in 696.
 		merged No S3‑191696  
S3‑191261 Input encoding for ECIES protection schemes Intel Corporation (UK) Ltd CR  
7.1.14Privacy
 		Yes
YesIDEMIA: we don’t need to add anything else to the CT1 work.The new figure was removed.
 		merged No S3‑191624  
S3‑191262 Addition of AMF/SMF requirement on security logging Deutsche Telekom AG, NTT Docomo CR Approval
7.1.16Others
 		Yes
Yes
 		revised No S3‑191562  
S3‑191263 Modification to key issue#1 Apple Computer Trading Co. Ltd pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191264 Modification to Key issue#4 Apple Computer Trading Co. Ltd pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191265 Integrity protection between SgNB and UE in NGEN-DC Apple Computer Trading Co. Ltd pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesHuawei, NEC: this is already covered in TS 33.501. Vodafone: key issue 4 still exists, so this is valid as a solution. Huawei: just refer to TS 33.501. Vodafone: we need a contribution evaluating this. MCC: reword last sentence to say that this is covered by TS 33.501. Huawei: add an editor's note indicating that if TS 33.501 is changed, the solution needs to be aligned. The solution details were removed.
 		revised No S3‑191776  
S3‑191266 Solution for Key issue #5 Apple Computer Trading Co. Ltd pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesQualcomm: not in the scope of the study item based on the RAN2 LS. NCSC: remove the IV generation part. Ericsson: we don’t need this. Qualcomm: we need to revisit the key issues based on RAN2's answer. Lenovo agreed.
 		noted No    
S3‑191267 Certificate based solution for 5GFBS Apple Computer Trading Co. Ltd pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑191781  
S3‑191268 ID based solution for 5GFBS Apple Computer Trading Co. Ltd pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesORANGE: Threats are not mitigated with signed messages,roaming scenarios are FFS. Qualcomm: PKG deployment is FFS. MCC: add references to IEEE, RFC, ISO SC27 and other mentioned bodies.
 		revised No S3‑191782  
S3‑191269 Modification for AnnexA Apple Computer Trading Co. Ltd pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191270 Conclusion for key issue 1 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
YesEricsson: remove solution 5.
 		revised No S3‑191764  
S3‑191271 Conclusion for key issue 2 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191272 Conclusion for key issue 3 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191273 Conclusion for key issue 4 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
YesBT: we need to check the relation with the SA2 specification. Add an editor's note. Ericsson: we don’t agree with solution 3 part. This was removed.
 		revised No S3‑191765  
S3‑191274 Evaluation for solution 5 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑191723  
S3‑191275 Evaluation for solution 3 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191276 Security solutions summary Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
YesEricsson: where to put this table?
 		revised No S3‑191763  
S3‑191277 Deleting the EN of solution 3 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191759  
S3‑191278 Adding more clarification text of solution 7 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191760  
S3‑191279 Deleting EN of solution 4 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
YesMCC commented that the introduction could not have normative requirements and proposed to reformulate the paragraph in present tense removing the shall and "it is required".
 		revised No S3‑191757  
S3‑191280 Evaluation for solution 4 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191758  
S3‑191281 Reference part Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191282 Way forward of FS_5G_URLLC security study Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		withdrawn Yes    
S3‑191283 Adding the key issue details and threats for KI #1 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191284 Delete the EN of Introduction Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191285 Abbreviations Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191286 Delete the EN of solution 5 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191724  
S3‑191287 Evaluation for solution 6 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
YesEricsson: solution 6 is out of scope. Delete the evaluation.
 		revised No S3‑191761  
S3‑191288 WID on security of URLLC Huawei, HiSilicon WID new Endorsement
7.7New Work Item proposals
 		Yes
Yes
 		revised No S3‑191725  
S3‑191289 Discussion on security of 5G eMBMS enhancement Huawei, HiSilicon discussion Endorsement
8.23New study item proposals
 		Yes
YesVodafone: it doesn’t provide a really good reason apart from saying that SA2 is working on 5G MBMS. Huawei: just a warning on that we will have to work on this in the near future. We don’t intend to start working on this now. It was commented that this could be part of Rel-17 work. Qualcomm agreed with this and added that it was a bit too early to start any activity on this issue.
 		noted No    
S3‑191290 Evaluation for solution 4 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‑191291 Security aspects on enhancement of support for Edge Computing in 5GC China Unicom, CAICT, China Telecom discussion  
8.23New study item proposals
 		Yes
YesVodafone: work on URLCC hasn’t finished yet. Wy having a rel-17 SID when we haven’t finished work on URLCC Rel-16? Huawei: this is a different topic, it's on edge computing. ORANGE: too many studies in SA3 at this moment. Let's postpone and wait for progress from SA2.
 		noted No    
S3‑191292 New SID: Study on security aspects of enhancement of support for Edge Computing in 5GC China Unicom, CAICT, China Telecom, ZTE SID new  
8.23New study item proposals
 		Yes
Yes
 		revised No S3‑191639  
S3‑191293 Key derivation during SRVCC from 5G to UTRAN CS China Unicom,CATT CR  
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesX.1.2 will be removed and the content merged with Huawei's contribution.
 		not pursued No    
S3‑191294 Emergency call in SRVCC from NR to UTRAN China Unicom, CATT CR  
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesORANGE: the second paragraph doesn't make any sense.What keys are derived in here? It was clarified that the handing over to 3G should be similar as the procedure in 4G, so the wording should explain this better. Content will merge into 649.
 		not pursued No    
S3‑191295 Overview of TR33.856 China Unicom CR  
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191788  
S3‑191296 Content of clause 3 for TR33.856 China Unicom, CATT CR  
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑191297 Key issue for encryption of broadcast assistance data in eLCS CAICT, China Unicom pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑191298 Key issue for encryption of broadcast assistance data in eLCS CAICT, China Unicom pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191299 Addition of SEPP requirement on N32 error handling Deutsche Telekom AG, NTT Docomo draftCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesIt was clarified that a WID was needed in order to have this eventually as a draftCR converted into a CR. Deutsche Telekom agreed to create a pCR with the key ssue and capture this in TR 33.855 (tdoc 669).
 		noted No    
S3‑191300 Discussion about RAN2 LS on protection of PC5-RRC messages for sidelink unicast communication LG Electronics discussion Discussion
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑191301 Reply LS on protection of PC5-RRC messages for sidelink unicast communication LG Electronics LS out Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑191302 Clause 4 Security Aspects of Advanced V2X services LG Electronics pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesNEC: references are not included in here.
 		revised No S3‑191744  
S3‑191303 New key issue on AS layer signalling protection for unicast mode over PC5 LG Electronics pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesLG asked to have it noted and commented that they would come back with further details in the next meeting.
 		noted No    
S3‑191304 New key issue on security and privacy of groupcast over PC5 for V2X communication LG Electronics pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		merged No S3‑191670  
S3‑191305 Discussion on LS on Use of SUCI in NAS signalling ZTE Corporation discussion Endorsement
7.1.14Privacy
 		Yes
Yes
 		noted No    
S3‑191306 Modification on Use of SUCI in NAS signalling ZTE Corporation CR Agreement
7.1.14Privacy
 		Yes
YesQualcomm: it correctly reflects what's happening in CT1. It needs to be verified if this is acceptable from security point of view. This was taken offline.
 		revised No S3‑191704  
S3‑191307 LS on Use of SUCI in NAS signalling ZTE Corporation LS out Approval
7.1.14Privacy
 		Yes
Yes
 		noted No    
S3‑191308 Deprecation of TLS 1.1 Ericsson CR Agreement
7.6.16Other work items
 		Yes
YesORANGE: why removing reference to RFC4366? Vodafone: add reference in TLS 1.2 in clause 6.2.3. Cover page needed to be fixed as well.
 		revised No S3‑191638  
S3‑191309 Using EAP-TLS with TLS 1.3 Ericsson discussion Discussion
7.6.16Other work items
 		Yes
YesApple: editor's note to consider current discussions in IETF. Ericsson commented that this was a discussion paper and that the CR would come back in the next meeting. Huwaei received confirmation that this would be only for rel-16.
 		noted No    
S3‑191310 References to several obsoleted RFCs Ericsson CR Agreement
7.6.16Other work items
 		Yes
Yes
 		agreed No    
S3‑191311 TLS OCSP stapling Ericsson CR Agreement
7.6.16Other work items
 		Yes
YesORANGE: this is a new feature, not a correction. Ericsson clarified that OSCP stapling referred to certificate signing in a way that the certificate authority didn’t need to be online. It was commented that Ericsson would come back with the same CR and an accompanying WID for the next meeting.
 		not pursued No    
S3‑191312 References to several obsoleted RFCs Ericsson CR Agreement
7.6.16Other work items
 		Yes
YesRelying on 1310 discussions.
 		agreed No    
S3‑191313 Various corrections to security protocols and cryptography Ericsson CR Agreement
7.1.16Others
 		Yes
Yes
 		agreed No    
S3‑191314 Token-based authorization for NRF's management and discovery services Ericsson CR Agreement
7.1.13.2Other
 		Yes
YesEricsson: this is alignment with CT4. Huawei preferred to keep the note. BT: the cover sheet does not correspond to the clause that is being changed. It is not the right place to make the change. Ericsson commented that if this wasn't accepted, CT4 would have to revert their decision.
 		revised No S3‑191619  
S3‑191315 Slice information for token-based authorization Ericsson CR Agreement
7.1.13.2Other
 		Yes
YesDeutsche Telekom: isn’t this a Rel-16 issue? We have a key issue in Rel-16 about this. Ericsson: we do it for Rel-15 then enhancements in Rel-16.
 		revised No S3‑191621  
S3‑191316 Name for N32 application layer security Ericsson discussion Endorsement
7.1.13.1Interconnect (SEPP related)
 		Yes
YesVodafone: what happens if other people are using the acronym in their specs? SA has asked for essential corrections in Rel-15. NTT-Docomo: the current acronym is heavily overloaded. NCSC: change the acronym, it's unlikely that many specs are using it. Ericsson:: we would tell CT4 mainly.
 		noted No    
S3‑191317 New Solution: Transport security for the interfaces between W-5GAN and 5GC Ericsson pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesHuawei: simplify the content, no need to list every interface.
 		approved No    
S3‑191318 New Key Issue: SUCI-to-SUPI mapping for the FN-RG Ericsson pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE: replace visited network by serving network since are not covering roaming now. Telecom Italia: How is the SUCI computed in the Home gateway if it doesn’t have an UICC? Ericsson replied that it wasn't computed by the home gateway but somewhere else in the network. Telecom Italia: potential architecture requirement instead of a security requirement? Ericsson SUCI to SUPI mapping is in our scope and we need to tell SA2 about this. Telecom Italia suggested that this had to be described as a security requirement, with a threat and so on. Vodafone agreed. Vodafone: the key issue is the mapping of SUCI to SUPI. The security threat was not related and scrapped from here.
 		revised No S3‑191690  
S3‑191319 New Solution: SUCI-to-SUPI mapping for the FN-RG Ericsson pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesNokia: the mapping is not explained. Huawei: a similar figure is available in the TR (solution #4) and there is a bunch of editor's notes in there as well. This solution exists already.Bring this back in the next meeting detailing the mapping. Nokia supported this.
 		noted No    
S3‑191320 Using STRIDE methodology for NPCD, SPD, assets and threats Ericsson discussion Endorsement
7.2.6Authentication Server Function (AUSF) (TS 33.516)
 		Yes
YesHuawei wasn’t sure about adding anything else to the process that was being performed in LTE and now in 5G.
 		noted No    
S3‑191321 Corrections on IP packet forwarding Ericsson CR Agreement
7.6.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesMCC commented that Rel-14 and Rel-15 should be changed as well making this CR a mirror. Huawei warned about implications in GSMA's work (NISAs), given that they were using 33.117 and that could affect them. Huawei wanted more time in order to make sure that the Rel-14,Rel-15 didn’t have immediate impacts on the pilot testing.
 		revised No S3‑191632  
S3‑191322 Update to solution #3 on NSaaS security features Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: the new text is not clear. ORANGE: secondary authentication is ortogonal to the slices, why is this here?When you configure the secondary authentication you don’t know to which external network you are connecting to. Qualcomm agreed with ORANGE. Secondary authentication is a different issue from slice specific authentication.
 		noted No    
S3‑191323 Conclusion to KI #3 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesORANGE: it's too early to conclude, some other companies might come back with other solutions.
 		noted No    
S3‑191324 A solution to NSSAI protection at AS transmission Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesORANGE: How the authorised NSSAI for the UE is configured in the serving network needs more details. This was added in an editor's note.
 		revised No S3‑191736  
S3‑191325 Discussion paper on KI#6 on NSSAI in RRC Huawei, HiSilicon discussion Discussion
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191326 Solution to KI #4 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: What is this solution about and what is being protected? This is not a new solution. Qualcomm:this doesn’t add any value. There is no requirement to protect the user id between the UE and the AAA; we would need to revisit the key issue. Qualcomm proposed to add an editor's note on the above. This was agreed. The evaluation was removed as well.
 		revised No S3‑191735  
S3‑191327 Conclusion to KI #4 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191328 Removing ENs for solution #2 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191732  
S3‑191329 Add Evaluation to Solution #2 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191733  
S3‑191330 Conclusion to KI #1 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: the conclusion needs to be expanded.
 		noted No    
S3‑191331 Discussions on Key Issue AMF key separation Huawei, HiSilicon discussion Agreement
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia disagreed witht the key issue. The Chair commented that this was discussed in the previous meeting and it had been seen that SA2 pushed this issue to Rel-17. ORANGE: this issue was out of scope in SA2 and they didn’t agree with any solution. Huawei is making an invalid interpretation. Nokia: the UE cannot connect to two AMF at the same time. The figure is wrong. Huawei proposed an LS to SA2 if there was no agreement with this paper. ORANGE agreed to ask SA2 if this had been pushed to Rel-17. Qualcomm replied that they had checked the SA2 report and this had been pushed to Rel-17. Huawei disagreed and commented that they had a different interpretation. There wasn't support for the LS. This discussion was noted and all the related documents.
 		noted No    
S3‑191332 Overview on solutions to AMF key separation Huawei, HiSilicon discussion Agreement
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191333 pCR on AMF key separation solutions solution 1 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191334 pCR on AMF key separation solutions solution 2 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191335 pCR on AMF key separation solutions solution 3 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191336 A key issue on forward secracy Huawei, HiSilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191337 A solution to forward secracy Huawei, HiSilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191338 Solution for efficient authentication for access between NPN and PLMN Huawei, HiSilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191339 Discussion on Architecture of PLMN integrated NPN Huawei, HiSilicon discussion Agreement
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191340 New Key Issue-Security of identifiers in group communication Huawei, HiSilicon pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		revised No S3‑191740  
S3‑191341 New Key Issue-cross-RAT PC5 control authorization indication Huawei, HiSilicon pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑191342 New Key Issue-Security visibility including human factors Huawei, HiSilicon pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesORANGE: what is expected from 3GPP here? This is an application layer issue, out of scope. BT, Gemalto agreed.
 		noted No    
S3‑191343 New Key Issue-Driving information privacy protection Huawei, HiSilicon pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesBT, ORANGE: this is application layer as well, especially speed, brake and acceleration. Interdigital: two positions in time gives us the speed. Qualcomm: is SA2 proposing to have specific location information in their V2X work? This belongs to the location work item. LG didn’t support this.
 		noted No    
S3‑191344 Identity based Signature against false base station on Key Issue #2 Huawei, HiSilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
No
Yes
 		withdrawn Yes    
S3‑191345 Protection of unicast message Apple Computer Trading Co. Ltd pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑191620  
S3‑191346 CR to TS33.501 - NAS SMC figure correction CATT CR  
7.1.5NAS security
 		Yes
Yes
 		agreed No    
S3‑191347 Way forward for evaluation for every solution Apple Computer Trading Co. Ltd pCR Agreement
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191348 Amendment to Key Issue# 2.1 Huawei, HiSilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE: SA2 already created an architecture that doesn't imply changes in the security architecture. No work for us in this key issue. Huawei: you mention the standalone case, this is for the integrated case.
 		noted No    
S3‑191349 pCR to TR33.814 - Key issue for security aspect of eLCS architecture enhancement CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesEricsson commented that it was better to bring this back in a later stage.
 		noted No    
S3‑191350 LS reply to RAN WG2 LS on broadcast assistance data delivery CATT LS out  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191351 pCR to TR33.814 - Key issue for confidentiality protection of broadcast assistance data CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesQualcomm: we already agreed in the LS in tdoc 600 for a solution for this.
 		noted No    
S3‑191352 pCR to TR33.814 - Key issue for distribution of assistance data ciphering key CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesQualcomm: SA2 has decided to do the same for the 5G system in Rel-16. This is not needed.
 		noted No    
S3‑191353 pCR to TR33.814 - Key issue for integrity protection of broadcast assistance data CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑191602  
S3‑191354 pCR to TR33.814 - Key issue for the security architecture of eLCS CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191355 pCR to TR33.814 - Solution of ciphering algorithms CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191356 pCR to TR33.814 - Solution of provisioning keys for broadcast assistance data protection CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191357 Subscriber privacy: ECIES test data for Profile A Gemalto N.V. discussion Discussion
7.1.14Privacy
 		Yes
Yes
 		noted No    
S3‑191358 pCR to TR33.814 - The solution for the distribution of broadcast assistance data deciphering key CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191359 pCR to TR33.814 - The analysis of security architecture of eLCS CATT pCR  
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesCATT proposed to move the content to clause 4. Qualcomm and Ericsson commented on the figure and CATT agreed to bring this back in the next meeting.
 		noted No    
S3‑191360 pCR to TR33.813 - Key issue for deeper UP protection termination CATT pCR  
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesNokia: this is not relevant to Rel-16, maybe for Rel-17. CATT: this is required by the market. Telecom Italia: SA1 addresses this kind of use cases, not here. ORANGE: SA1 should not go into security requirements. ORANGE: we need to control the UPF due to lawful interception requirements. This is material for a new study item. CATT: we wanted to know if this was feasible work for the future.
 		noted No    
S3‑191361 pCR to TR33.813 - Key issue for UP key separation CATT pCR  
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesTelecom Italia: this input should start from an SA1 requirement. ORANGE: we need a discussion paper with more details.
 		noted No    
S3‑191362 pCR to TR33.813 - Solution for UP key separation CATT pCR  
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191363 Address EN in key issue 4 Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesNokia didn't know what the role of the AMF was in the enforcement of the privacy. ORANGE didn’t understand the meaning of privacy control here, but since it was part of existing text of the specification they withdrew their comment. Qualcomm didn’t agree with the AMF/UE enforcing the privacy control.
 		noted No    
S3‑191364 Reply LS on RAN2 conclusion for NR positioning Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesIntel supported this response. CATT wasn't convinced with the physical risk.Qualcomm agreed with this, they preferred to wait for RAN's progress. Huawei: we do have requirements for a secure environment and we should tell them about them. It was agreed that SA3 needed to wait for RAN's progress in this work. CATT: RAN will finish this work in December, our work item will be really delayed.
 		noted No    
S3‑191365 Delete EN in solution12 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: time limit to the filters?An editor's note was added for this. Reference to the relevant spec in SA2 in step 4 was added.
 		revised No S3‑191684  
S3‑191366 Add evalution in solution12 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: reformulate the last two sentences. Ericsson: If PDU sessions are not terminated the network will keep the PDU sessions open and this would be a waste or resources. In the end Ericsson conceded and the revision only took care of the rewording.
 		revised No S3‑191685  
S3‑191367 Corrections on the s-Kgnb derivation Huawei, Hisilicon CR Approval
7.1.2Key derivation
 		Yes
YesEricsson: Wrong key name and second change does not need to be there.
 		revised No S3‑191605  
S3‑191368 Address EN and update in key issue 5 Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesNokia and Ericsson had concerns on the requirements so the editor's note came back.
 		revised No S3‑191754  
S3‑191369 A solution to prevent from providing faked/altered location estimate Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191370 update in solution 4 Huawei, Hisilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191772  
S3‑191371 Add introduction part Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesORANGE: the introduction is not needed. MCC: the first two sentences are in fact the scope of the document. Only the reference part stays.
 		revised No S3‑191706  
S3‑191372 Add content to clause 4 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesEricsson: refer to relevant SA2 specs. Nokia: refer to all possible scenarios.
 		revised No S3‑191707  
S3‑191373 Delete Editor's Note in KI#4 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191708  
S3‑191374 Add requirement and delete EN for KI#13 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191709  
S3‑191375 Delete one Editor’s Note in solution3 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191376 Delete EN for solution 5 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191377 Add conclusion on KI#3 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesTelecom Italia: getting to a solution without an evaluation?
 		revised No S3‑191711  
S3‑191378 Add Conclusion on KI#4 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191379 Add detials on handling UP security in RRC inactive scenario Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
YesQualcomm needed to take this offline.
 		revised No S3‑191609  
S3‑191380 Completing TS 33.511 Huawei, Hisilicon pCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
YesEricsson queried about the conclusion on gNB-specific additions to 33.117. Huawei replied that they didn’t find new test cases.
 		revised No S3‑191741  
S3‑191381 Adding gNB critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
YesEricsson commented that a similar work should be done for the other network product classes. Ericsson: Confidentiality and inegrity protection are missing in X.2.1. The contribution was well received but it needed further discussions.
 		revised No S3‑191630  
S3‑191382 security procedures of 5G SRVCC to UTRAN Huawei, Hisilicon CR Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesContent will be merged with China Unicom's agreed content in 649.
 		not pursued No    
S3‑191383 mitigate the linkability attack Huawei, Hisilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191384 a skeleton of security aspects of 5G SRVCC to UTRAN Huawei, Hisilicon CR Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesORANGE: plenary decision is against X.3 (return from UTRAN to E-UTRAN or NR). We don’t need it. Huawei clarified that this wasn't a CR but a draftCR. Qualcomm commented that this was a baseline, with agreed changes from the Kochi meeting; removing X.3 would need another contribution. It was agreed to remove X.3. The living document/draft CR will be in 648 and will capture the agreements of this meeting.
 		not pursued No    
S3‑191385 KI_security for setting up multicast Huawei, Hisilicon pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQualcomm: better reword the requirements to include the support. LG: too early for this key issue, but I can live with it. The requirement was removed and an editor's note was added.
 		revised No S3‑191748  
S3‑191386 Resovle Editor's notes in Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191387 Clarification for Initial NAS Message Protection Huawei, Hisilicon CR Approval
7.1.5NAS security
 		Yes
YesEricsson: valid scenario but the additional changes are already described somewhere else. This had to be taken offline.
 		revised No S3‑191611  
S3‑191388 Resolve ENs on Solution to Mitigate DDoS Attack based on RAN Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone didn’t agree with the term "massive misbehaving infrequent CIOT Ues". Huawei replied that this was coming from SA2. Vodafone: how do you get out of the blacklist? Huawei: there is a timer. Vodafone: this timer doesn’t appear in here. The blacklist applies to a collection of Ues and not a single UE. The timer applies to which UE? The first one? An editor's note was added to address this.
 		revised No S3‑191688  
S3‑191389 Solution to Mitigate DDoS Attack based on RAN Caused by Massive Misbehaving Frequent CIoT Ues Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: now the CIoT Ues are frequent, whereas in other contributions they were infrequent.Huawei replied that this was to be reworded like in the previous contribution and that the term "frequent" was coming from SA2.
 		merged No S3‑191688  
S3‑191390 Solution to Mitigate DDoS Attack on AMF caused by Massive Misbehaving Infrequent CIoT Ues Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑191689  
S3‑191391 Solution for Protection of RRCReject Message Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191392 Solution for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191393 Add New Security Threat and Requirement for Key Issue #1 for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑191789  
S3‑191394 CR to TS33501-RRC Reestablishment security handling when N2 Handover fails Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
YesQualcomm: this is not needed in Rel-15 and it should be discussed separately in Rel-16. Ericsson agreed: RAN groups consider this as a rare case and they don’t want to optimize for this. Huawei: let's ask RAN2 about their opinion on this.It is not a radio link failure. Ericsson: this is to be handled by RAN2, no LS needed. Qualcomm agreed. Huawei considered it to be a valid security issue. There was no agreement to have this for Rel-15, and more offline discussion was needed for Rel-16.
 		not pursued No    
S3‑191395 Discussion on Key handling on UE for Reestablishment Procedure in case of N2 handover failure Huawei, Hisilicon discussion Endorsement
7.1.4AS security
 		Yes
Yes
 		noted No    
S3‑191396 Security Assurance Requirements and Test Case on TEID Uniqueness for SMF Huawei, Hisilicon pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		revised No S3‑191655  
S3‑191397 Discussion on the security test of NRF authorization Huawei, Hisilicon discussion Discussion
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
YesEricsson: 33.926 should contain the threat part. Huawei: we just want to show that the threat exists and we can ome back later with a contribution for 33.926.
 		noted No    
S3‑191398 Way forward on the security test of NRF authorization Huawei, Hisilicon discussion Endorsement
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
YesEricsson: not clear what we are endorsing. It was generally agreed and the wording was worked out offline.
 		revised No S3‑191662  
S3‑191399 Security Assurance Requirement and Test for NRF authorization on the NF discovery Huawei, Hisilicon pCR Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
YesNokia preferred to have another name for the test. They had other comments that had to be taken offline.
 		revised No S3‑191663  
S3‑191400 Removing the EN on AMF log Huawei, Hisilicon pCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		merged No S3‑191651  
S3‑191401 Test case on UE security capability invalid or unacceptable Huawei, Hisilicon pCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
YesDeutsche Telekom: expected result should be reworded. Nokia had some comments that needed to be taken offlien. Ericsson: there is no threat, not clearly motivated. The test is very unspecific, not clear what the test should do. Huawei: CT1 has specified what's invalid or unacceptable.We can focus on the clear scenarios if needed. Nokia: we need to do firstly a threat analysis and afterwards the test case. Huawei: it's in the rational. Nokia: it should be documented in the TR 33.926.
 		revised No S3‑191650  
S3‑191402 New solution for linkability attack Huawei, Hisilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191403 Key issue on authorization for delegated "Subscribe-Notify" interaction scenarios Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesVodafone: this is not written as a key issue. A key issue is not a study.
 		revised No S3‑191673  
S3‑191404 New solution for delegated "Subscribe-Notify" interaction authorization Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑191405 Discussions on security of mobile edge computing Huawei, Hisilicon discussion Discussion
8.23New study item proposals
 		Yes
Yes
 		noted No    
S3‑191406 New SID: Study on Security Aspects of enhancement of support for Edge Computing in 5GC Huawei, Hisilicon SID new Approval
8.23New study item proposals
 		Yes
Yes
 		merged No S3‑191639  
S3‑191407 Clarification on securing the procedure of idle mobility from 5GS to EPS over N26 interface Huawei, Hisilicon CR Approval
7.1.3Mobility
 		Yes
YesNokia: add explanation on this in 8.5.1. Ericsson: why a separate clause? Just add a note. Vodafone: is this essential? Add the word in the title. Ericsson: all CRs cat-F are supposed to be essential anyway. No need for this.
 		revised No S3‑191606  
S3‑191408 New KI: AKMA push Huawei, Hisilicon pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191409 Subscriber privacy: test data for Profile A of SUCI computation Huawei, Hisilicon CR Approval
7.1.14Privacy
 		Yes
Yes
 		merged No S3‑191626  
S3‑191410 New KI: KAUSF storing at UE side Huawei, Hisilicon pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191411 Registration failure in registration procedure with AMF reallocation caused by slicing Huawei, Hisilicon discussion Discussion
7.1.3Mobility
 		Yes
YesVodafone: this is lack of efficiency, not a security hole. Huawei: you will never be registered successfully, it's a denial of service. Ericsson: step 7 discarded by UE according to Huawei, but we don’t agree. The Vice Chair (NTT-Docomo) commented that confusion with the CT1 specification seemed to be the source of the discussion. An LS could be sent to them. Qualcomm agreed with sending an LS to CT1 ccSA2. It was a CT1 decision according to them. The vice chair asked if this was a Rel-15 issue, and Qualcomm replied that Rel-15 shouldn't be ruled out. This was taken offline.
 		noted No    
S3‑191412 Solving registration failure in initial registration procedure with AMF reallocation Huawei, Hisilicon CR Approval
7.1.3Mobility
 		Yes
YesThere was an agreement that this was a problem to be fixed, but Qualcomm preferred to contact SA2 and CT1 as well with an LS before agreeing with this CR. It was agreed the existence of an issue that needed to be solved; it was asked to be minuted "the issues in tdoc 411 need further investigation." The Chair declared the CRs as not pursued but pointed out that Huawei could bring back revisions of them to continue discussions in the next meeting.
 		not pursued No    
S3‑191413 Solving registration failure in initial registration procedure with AMF reallocation Huawei, Hisilicon CR Approval
7.1.3Mobility
 		Yes
Yes
 		not pursued No    
S3‑191414 Clarification on the SUCI compuation Huawei, Hisilicon, Gemalto, IDEMIA CR Approval
7.1.14Privacy
 		Yes
YesVodafone: it needs rewording.
 		revised No S3‑191625  
S3‑191415 New KI: Access token sharing between NFs Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesVodafone didn't agree with the solution. Deutsche Telekom: the potential requirement is too weak.
 		noted No    
S3‑191416 New solution for service access authorization within a NF Set Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesVodafone: the text of the potential requirement does not have any relation to security.Deutsche Telekom and Nokia didn’t agree with this change either. The change was removed.
 		revised No S3‑191674  
S3‑191417 Discussion on removing the authentication result in the UDM Huawei, Hisilicon discussion Discussion
7.1.8Primary authentication
 		Yes
Yes
 		revised No S3‑191589  
S3‑191418 Removing the authentication result in the UDM Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		revised No S3‑191492  
S3‑191419 NAS recovery with the soure AMF in handover failure Huawei, Hisilicon CR Approval
7.1.3Mobility
 		Yes
YesRelated to the LS in 147. Vodafone: this needs rewording.
 		merged No S3‑191607  
S3‑191420 Missing UDR description in alignment with 29.505 Nokia, Nokia Shanghai Bell CR Agreement
7.1.16Others
 		Yes
YesVodafone: no point in standardising this now. Telecom Italia pointed out that this was cat-B for Rel-15 and too late to be introduced. It was commented that this was aligning with CT4 changes. BT: unless the vendors update security in UDM/UDR we will have security breaches. This introduces an operational problem. Vodafone agreed. Christine (Ericsson) wanted to take it offline to clarify the concerns on the deployment of this. NTT-Docomo commented: can UDM be virtualised? If so, security is not possible; it would be a red flag. Hpe: we thought that ARPF would be a separate module, have hardware for that one. ORANGE: how do we handle having the right keys in the right hardware when having multiple UDMs? This had to be taken offline.
 		not pursued No    
S3‑191421 Adding Nudr service Nokia, Nokia Shanghai Bell CR Agreement
7.1.16Others
 		Yes
Yes
 		not pursued No    
S3‑191422 Unified EAP authentication framework Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE: not needed. There is no key issue or requirements. Nokia replied that this was coming from an endorsed document from the last meeting. ORANGE commented that the agreement was about going directly to CRs in the normative phase instead of introducing content in the TR. ORANGE added that the usual procedure from SA3 was based on key issues and there was no point in changing this working methodology.
 		noted No    
S3‑191423 Conclusion on EAP authentication framework Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191424 Solutions and conclusion for SNPN service access via PLMN and vice versa Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE: everything is captured in the SA2 specification.The solution is in their document already. This will not prodce eventually CRs into 33.501. Gemalto: we need a conclusion on this key issue, otherwise this will come back. The Chair commented that existing solutions can apply. ORANGE didn’t agree since this didn’t have any impact on our specifications. ORANGE: just say that no normative work is required. Everything was gone except the conclusion, which was reworded.
 		revised No S3‑191771  
S3‑191425 Solution and Conclusion on 5GLAN authentication Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesMCC reminded to add the references of the named specifications (e.g. 33.501) in clause 2 of the next draft TR.
 		approved No    
S3‑191426 Solution on SMF handling the UP security policy for a 5GLAN Group Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191427 Solution and conclusion for TSC Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesTaken offline to express that the authentication procedure in 33.501 is to be followed.
 		revised No S3‑191767  
S3‑191428 Key issue on PNiNPN authentication Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesEricsson didn’t see the threat clearly. ORANGE: the security requirements don’t match because you can access the NPN networks without authenticating, you cannot mandate authentication. Qualcomm: we should close the TR without adding more key issues. Nokia: we want to close on this key issue. Telecom Italia: the solution should not exist. No support for this document, hence it was noted.
 		noted No    
S3‑191429 Solution and evaluation for PNiNPN authentication Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesORANGE: not needed. We should not put material from our specifications in the TRs. This is exisitng already.
 		noted No    
S3‑191430 Summary of security aspects covered in this study Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191774  
S3‑191431 Security for non-public networks Nokia, Nokia Shanghai Bell draftCR Agreement
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesMCC commented that this could not be input for the study, since CRs are part of normative work. Qualcomm and Nokia replied that thhey wanted to collect comments and agree on a way forward for the future. MCC added that in order to procceed with these CRs a normative WID would be needed.
 		noted No    
S3‑191432 NPN references in existing text Nokia, Nokia Shanghai Bell draftCR Agreement
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesGemalto: the USIM always resides in the UICC, not only for PLMNs.
 		noted No    
S3‑191433 Discussion WID 5GS Vertical_LAN_SEC Nokia, Nokia Shanghai Bell discussion Discussion
7.7New Work Item proposals
 		Yes
Yes
 		noted No    
S3‑191434 WID proposal for 5GS Vertical_LAN_SEC Nokia, Nokia Shanghai Bell WID new Agreement
7.7New Work Item proposals
 		Yes
Yes
 		revised No S3‑191726  
S3‑191435 CIoT: Definitions and Abbreviations Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: Some of these are already in 21.905. NTT-Docomo: there may be other acronyms that can be added here.
 		revised No S3‑191676  
S3‑191436 CIoT: Evaluation to Solution #4 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191437 CIoT: Update to Solution #4 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑191679  
S3‑191438 CIoT: Conclusion to KI#2 and KI#3 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191439 Solution to protect user ID over the air interface Ericsson pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesEditor's note added on protection is needed between serving network to AAA server. Secondary authentication was changed to slice specific authentication. Lenovo proposed to remove the evaluation part. This was agreed.
 		revised No S3‑191738  
S3‑191440 Correction of ShortResumeMAC-I calculation for EDT Ericsson CR Agreement
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		revised No S3‑191633  
S3‑191441 LS on integrity protection for EDT Ericsson LS out Approval
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑191442 Discussion on RAN2 conclusion for NR positioning SI Ericsson discussion Endorsement
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191443 LS on security and privacy aspects of NR positioning Ericsson LS out Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑191750  
S3‑191444 Discussion on missing AMF/SEAF behaviour Ericsson, CableLabs discussion Endorsement
7.1.8Primary authentication
 		Yes
YesHuawei: maybe we don’t need to cope with this until someone comes with a security threat and attack related to this. If not, it would be a protocol error left for stage 3. ORANGE: this is an error case, agree with Huawei. Nokia didn't agree either. Ericsson asked what the right behaviour was. Qualcomm answered that this case scenario would not work, it doesn't matter asking about the behaviour.
 		noted No    
S3‑191445 Missing AMF/SEAF behaviour Ericsson, CableLabs CR Agreement
7.1.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑191446 Rectifying incorrect limitation for horiz/vert key derivation Ericsson CR Agreement
7.1.2Key derivation
 		Yes
Yes
 		revised No S3‑191604  
S3‑191447 UP policy handling in case of unauthenticated emergency calls Ericsson CR Agreement
7.1.5NAS security
 		Yes
YesCableLabs agreed with the change, it clarifed an ambiguity. Alex (BT): this wording infers that the AMF may not accept unauthentication in emergency calls and this is a requirement for the network. The problem is in "in the case" words. This change was removed. Qualcomm: ME is not affected.
 		revised No S3‑191612  
S3‑191448 Remove EN in clause 10.2.2.2 Ericsson CR Agreement
7.1.5NAS security
 		Yes
YesHuawei: specification of the messages is a CT1 issue. There were different concerns about this and Ericsson decided to bring it back during the next meeting.
 		not pursued No    
S3‑191449 Verification failure of NAS container Ericsson CR Agreement
7.1.3Mobility
 		Yes
YesIntel didn’t see the need of this. How does the AMF will know to do the same?
 		merged No S3‑191607  
S3‑191450 Security algorithm change by SN Ericsson CR Agreement
7.1.4AS security
 		Yes
YesHuawei: this change is not needed.
 		not pursued No    
S3‑191451 Verification failure of NAS MAC in NAS container at 4G to 5G HO Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		merged No S3‑191614  
S3‑191452 Handling of 5G security contexts with multiple NAS connections at 4G to 5G HO Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		merged No S3‑191783  
S3‑191453 Missing privacy parameters Ericsson CR Agreement
7.1.14Privacy
 		Yes
YesGemalto added a clarification on NOTE2: "by OTA". IDEMIA: we don’t need to indicate how it is updated, it is up to the operator. Nokia, Qualcomm: all these details are in CT specs; we don’t need this CR. Gemalto supported Ericsson's CR. Qualcomm: it is not an essential correction. Huawei agreed. IDEMIA: not a contentious issue, we can go forward with this change. Ericsson: in which stage 3 document is this covered? ORANGE preferred not to refer to a CT6 specification. ORANGE: Keep 5.2.5 make a new contribution for 5.8.2. Vodafone: no need to standardize what appears in 5.8.2.
 		revised No S3‑191627  
S3‑191454 New solution (SERSI - SERving network controlled SI signatures) - builds on Solution#7 Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesApple: to be merged to solution 7. Add an editor's note on the assesment of this. Qualcomm, ORANGE: we need to reformat the existing solution. Samsung,Intel supported the editor's note in order to move forward. ORANGE wanted to restructure the contribution firstly. AT&T supported having this in. Ericsson: merge with solution 7, there are 10 companies supporting this. AT&T: reformatting is editorial, there is no technical justification against this. CableLabs supported AT&T. Telecom Italia was against having this in. The vice chair (Docomo) proposed to minute: This type of solution should go in but it needs to come back with the proper formatting according to Annex A. There was opposition to the formatting but a general agreement to the solution. The vice chair encouraged to discuss offline on this document and noted it.
 		noted No    
S3‑191455 Conclusion on KI#3'S second requirement (reactive action) Ericsson pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesHuawei: too early.
 		noted No    
S3‑191456 IAB - terminology Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesHuawei: this is not related to SA3, let's reference the RAN specs because the definitions can change. Qualcomm suggested to keep them as they were useful with an editor's note explaining that they may be temporary.
 		revised No S3‑191692  
S3‑191457 IAB - security architecture diagram key issue Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑191458 A new KI for the authentication framework for the UE Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesHuawei: we don’t need to mention framework here. Ericsson: we want to capture that the UE is transparent to this authentication. ORANGE: we don’t need this key issue. The UE is authenticated to the network according to TS 33.501. Qualcomm: this TR analyses changes to what's in TS 33.501 already. We don’t want to re-open key issues. ORANGE: be more precise, not just "transparent". The Chair proposed to add a statement addressing this somewhere like in clause 4.
 		revised No S3‑191696  
S3‑191459 A new KI for the authentication framework for an IAB node acting as a MT Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		revised No S3‑191697  
S3‑191460 A new KI for activating communication security in IAB node Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		revised No S3‑191698  
S3‑191461 A solution for mutual authentication between a UE and a 3GPP network supporting the IAB architecture Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		merged No S3‑191696  
S3‑191462 Discussion on security aspects of EPLMN in LS from S2 (S3-191126) Vodafone GmbH discussion Discussion
6.13GPP Working Groups
 		Yes
YesEricsson wasn't sure about proposal C, although they supported a and b. This was taken offline. Qualcomm was fine with informing SA2, but not sure about sending an LS to CT1. It's up to SA3 to work on the security, CT1 is not involved in that.
 		noted No    
S3‑191463 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		revised No S3‑191631  
S3‑191464 Resolving the ENs in solution #5 Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191465 SMF Test Case: TEID Uniqueness Nokia, Nokia Shanghai Bell pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
YesEricsson: it needs more work on the threats, it seems to be incomplete. Docomo had some issues that were taken offline.
 		merged No S3‑191655  
S3‑191466 New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
YesHuawei: In x.2.3.1 the effect would be a worse problem than a waste of system resources. This was taken offline.
 		revised No S3‑191659  
S3‑191467 Updates to SEPP Test Cases Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
YesEricsson: remove editor's note on requirement to be added in 33.501. Huawei didn't agree with the last change, it was not needed according to them. Related to contribution 469 according to Nokia, but it was clarified that the SCAS work didn’t depend on study work, so the last change was removed.
 		revised No S3‑191660  
S3‑191468 New Annex for the NRF in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		revised No S3‑191664  
S3‑191469 Error handling for PLMN ID mismatch at SEPP Nokia, Nokia Shanghai Bell draftCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesHuawei: we don’t include it in SCAS because it's purely for Rel-16. The SCAS WID is based on Rel-15 specifications. Vodafone: on the sentence about the receiving SEPP, this cannot be a "shall". NTT-Docomo: better say "shall support". Huawei: check CT4 specs for the error messages. Vodafone: we are not sending an error message to an attacker. It was questioned whether this was a draftCR since it was part of the study item. This had to be shaped to be inserted into the TR instead. It was decided finally to note the document.
 		noted No    
S3‑191470 Update to Solution#4 Enhance privacy control in LCS Nokia, Nokia Shanghai Bell pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191471 Solution 2 Evaluation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191472 Solution 3 Evaluation Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191473 Co-existence of LTKUP and PFS Ericsson discussion Discussion
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191474 URLLC: Resolving EN in solution #8 Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191742  
S3‑191475 URLLC: Evaluation to solution #8 Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191762  
S3‑191476 URLLC: Recommendation for KI#3 Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191477 Solution #7 evaluation Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191478 Conclusion to KI#1 and KI#2 Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191479 Restore figures in Solution 3 Ericsson pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191480 New KI: Leakage of long-term key Ericsson pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191481 New solution: EAP-AKA΄ PFS Ericsson pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191482 pCR to TR33.935 - Addition of Diffie - Helman Key agreements section Vodafone GmbH pCR Approval
8.16Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)
 		Yes
Yes
 		withdrawn Yes    
S3‑191483 CR to 33.501 6.6.4 UP integrity mechanisms - UE to gNB ntegrity protection check failure reporting BT plc CR Approval
7.1.4AS security
 		Yes
YesIt was commented that TEIx for Rel-16 category-B and C was not recommended anymore by SA. The WI code would have to be taken into account. Deutsche Telekom: do we want to make this mandatory? Qualcomm: RAN2 asked SA3 last year about this being necessary and now we are reopening the issue changing our mind. Nokia: network and UE can verify that the integrity is failing already. We don’t agree with this change either. Samsung: When the PDCP error happens, it is reported to the RRC layer. RRC layer knows the reason why the packet is dropped. RAN2 implements the behaviour on how to act in case there is such failure. Qualcomm: this is a RAN level discussion. They discussed this in Rel-15 and there was no agreement. Lenovo didn’t agree with this either. This was taken offline.
 		not pursued No    
S3‑191484 Discussion paper on Service access authorization for Indirect communication with delegated discovery (Model D) Nokia, Nokia Shanghai Bell discussion Discussion
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑191485 eSBA: Solution to KI #22 - Service access authorization for Indirect Communication with delegated discovery (Model D) Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesEricsson: different deployment scenarios should be considered. An editor's note was added about this.
 		revised No S3‑191671  
S3‑191486 Evaluation of Solution #1 Lenovo, Motorola Mobility pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191712  
S3‑191487 New Test Case: Error handling of malformed JSON object between two network products NEC Europe Ltd draftCR Agreement
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
YesHuawei: what is a malformed JSON object? NEC: NOTE 1 explains it. Huawei: the test case needs more work. Ericsson supported this. Ericsson added that this could mean having malformed JSON objects everywhere.
 		revised No S3‑191701 S3‑191214
S3‑191488 Mitigation against the authentication relay attack with different PLMNs Lenovo, Motorola Mobility pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesEricsson: indications in the victim (UE) may or may not be standardised. An editor's note was added for this. Qualcomm: general error handling on the UE may be affected. Editor's note added on this.
 		revised No S3‑191790  
S3‑191489 Removal of Editor’s Notes of Solution #5 Lenovo, Motorola Mobility pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		not treated No    
S3‑191490 eSBA: Solution to KI#22 - Service access authorization for Indirect Communication without delegated discovery (Model C) Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑191491 IAB - security architecture diagram solution Ericsson-LG Co., LTD pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		revised No S3‑191695  
S3‑191492 Removing the authentication result in the UDM Huawei, Hisilicon CR Approval
7.1.8Primary authentication
 		Yes
Yes
 		not pursued No   S3‑191418
S3‑191493 Proposed evaluation details for solution #5 in TR 33.819 Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191494 Proposed conclusion details for key issue #5.1 in TR 33.819 Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191495 Proposed evaluation details for solution #4 in TR 33.819 Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191496 Proposed conclusion details for key issue #1.1 in TR 33.819 Qualcomm Incorporated pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesEricsson: too early.
 		noted No    
S3‑191497 Motivation and comments on a draft CR for non-public networks Qualcomm Incorporated discussion Discussion
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191498 Security for non-public networks Qualcomm Incorporated discussion Endorsement
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191499 Proposed solution for protecting the S-NSSAI for transmission at the AS layer Qualcomm Incorporated pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
YesIt was agreed to include the same editor's note as 736.
 		revised No S3‑191737 S3‑190791
S3‑191500 Key derivation for SRVCC from 5G to UTRAN CS Qualcomm Incorporated discussion Endorsement
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		endorsed No    
S3‑191501 Correction to the handling of security context in the multi-NAS scenario Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
Yes
 		revised No S3‑191783  
S3‑191502 Description of issue of clashing ngKSIs with multi-NAS security Qualcomm Incorporated discussion Discussion
7.1.5NAS security
 		Yes
YesHuawei considered this as a very rare case. Ericsson:
 		noted No    
S3‑191503 Clashing ngKSI for different security contexts in multi-NAS scenarios Qualcomm Incorporated CR Agreement
7.1.5NAS security
 		Yes
YesQualcomm will bring a revised version for the next meeting.
 		not pursued No    
S3‑191504 Response LS on handling of non-zero ABBA value in Release 15 Qualcomm Incorporated LS out Approval
7.1.5NAS security
 		Yes
Yes
 		revised No S3‑191613  
S3‑191505 Response LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode Qualcomm Incorporated LS out Approval
7.1.5NAS security
 		Yes
Yes
 		revised No S3‑191610  
S3‑191506 Missing implementation of S3-190797: Conclusion on KI #8 for Study on the security for URLLC Qualcomm Incorporated pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191507 Evaluation of solution #5: Security for redundant data transmission Qualcomm Incorporated pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191508 Shared key based MIB/SIB protection Qualcomm Incorporated pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		revised No S3‑191780  
S3‑191509 Security requirement for KI #7 Qualcomm Incorporated pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesEricsson,Huawei: this is not a requirement, but an evaluation.
 		noted No    
S3‑191510 Resolving EN in Solution 9 Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesVodafone: very confusing. Not an outstanding issue since it will be treated in Rel-16 as written here. Huawei: this CIoT activity depends on SA2's agreements and here it seems that we deviating from that. This needed reformulating and Huawei wanted to include a reference to the work in SA2.
 		revised No S3‑191682  
S3‑191511 Resolving EN in Solution 10 Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		revised No S3‑191683  
S3‑191512 Clarification for the NAS MAC failure case in N2 HO Qualcomm Incorporated CR Agreement
7.1.3Mobility
 		Yes
YesVodafone: wording issues. Huawei: we are not addressing how often this happens. It's a new feature and if this happens often the RAN2 LS is a good place to start, but we need to agree on how often this happens. Ericsson commented that this was out of scope of SA3.
 		revised No S3‑191607  
S3‑191513 Clarification for the NAS MAC failure case in interworking Qualcomm Incorporated CR Agreement
7.1.10Interworking
 		Yes
Yes
 		revised No S3‑191614  
S3‑191514 Draft CR to 38300 for IAB Qualcomm Incorporated discussion Information
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesCompany of the previous contribution for information.
 		noted No    
S3‑191515 Draft CR to 38401 for IAB Qualcomm Incorporated discussion Information
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesCompany of the previous contribution for information.
 		noted No    
S3‑191516 Status on RAN WI NR_IAB Qualcomm Incorporated discussion Information
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesHuawei: RAN3 can inform us by LS about their progress.
 		noted No    
S3‑191517 F1 interface security for IAB Qualcomm Incorporated pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesHuawei only supported the f1 control, but objected to the requirements and threats. Ericsson,ORANGE, NTT-Docomo, Vodafone, Juniper,BT, AT&T supported these requirements.. BT: the requirement should distinguish between wireless and wireline. Huawei: no additional requirements to end-to-end PDCP security protection. There are no attacks for this. NTT-Docomo: clarify the end-to-end between the terminating points. The security requirements were reworded to say "shall support" instead.
 		revised No S3‑191700  
S3‑191518 Commonalities between IAB and Wireline Fronthaul for CU/DU Qualcomm Incorporated discussion Discussion
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑191519 Solution for F1 interface security for IAB Qualcomm Incorporated pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No    
S3‑191520 Broadcast of Location Assistance Data for NR Qualcomm Incorporated discussion Decision
6.13GPP Working Groups
 		Yes
YesEricsson commented that integrity protection should be included here. Qualcomm, Intel: no need to reopen this discussion. This was taken offline.
 		noted No    
S3‑191521 eSBA: Solution to KI #21: Protection of SeCoP interfaces Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑191522 Discussion of SBA authorization selection China Mobile discussion Endorsement
7.1.13.2Other
 		Yes
YesDeutsche Telekom: we should involve CT4 as well and have a discussion on whether we want to do it this way. Nokia didn’t agree with the proposal: Authentication during discovery and authentication during service access are not mutually exclusive as the paper claims.
 		noted No    
S3‑191523 eSBA: Solution to KI #23: NF to NF authentication and authorization in Indirect communications model Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑191672  
S3‑191524 Proposal of SBA authorization revision China Mobile CR Approval
7.1.13.2Other
 		Yes
Yes
 		not pursued No    
S3‑191525 eSBA: Solution to KI #27 - UP Gateway function for protection of inter-PLMN N9 interface Nokia, Nokia Shanghai Bell,Juniper pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑191661  
S3‑191526 Scope of a SECAM SCAS for 3GPP virtualized network products China Mobile, CAICT pCR  
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191527 Providing some evaluation for solution #2 in TR 33.815 Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑191593  
S3‑191528 Proposed conclusion for establishing the RLOS call Qualcomm Incorporated pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑191594  
S3‑191529 Adding MACS as an input parameter to the calculation of AK* to provide freshness Qualcomm Incorporated CR Agreement
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No   S3‑190376
S3‑191530 Scope of SECAM evaluation for 3GPP virtualized network products China Mobile, CAICT pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191531 Scope of SECAM Accreditation for 3GPP virtualized network products China Mobile, CAICT pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191532 eSBA: NF Consumer authentication for based on signed API Request Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑191533 Adding roles in SECAM for 3GPP virtualized network products into clause 4.6 China Mobile, CAICT pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191534 AKMA: Implicit bootstrapping using NEF as the AKMA Anchor Function Nokia, Nokia Shanghai Bell 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‑191535 Adding contents into clause 4 China Mobile, CAICT pCR Approval
8.14Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191536 IAB Architecture Samsung pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		revised No S3‑191694  
S3‑191537 Work Plan for moving forward AKMA China Mobile discussion Endorsement
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‑191538 Key Issue on IAB Node authentication and authorization Samsung R&D Institute India pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesContent related to authentication was merged with the revision of 459.
 		merged No S3‑191697  
S3‑191539 Solution for IAB Node authentication and authorization Samsung pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesHuawei: this is mixing LTE and 5G details, so it's confusing. Added an editor's note on the need to separate both authentication details. ORANGE: remove the evaluation, add an editor's note on the difference between MT and UE (which will be decided in RAN groups). It was decided to add a statement on the IP node acting as an UE instead of the editor's note.
 		revised No S3‑191699  
S3‑191540 Discussion on AKMA overall evaluation methodology China Mobile, ZTE Corporation discussion Endorsement
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191541 pCR to 33.815 on authentication of network NTT DOCOMO pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesQualcomm: this assumes that the user has an active USIM, but this is not what's happening in SA1.SA2. They didn’t agree with the key issue. Sony supported Qualcomm. ORANGE supported the requirement. Vodafone: how do you identify that you are an US person without credentials?Only US customers would expect this service. Vodafone supported this key issue. Deutsche Telekom wanted to have this key issue as well. There was a big risk of weakening the security to satisfy a specific issue for US customers. Ericsson: this key issue is against the PARLOS concept. IDEMIA supported the key issue. Nokia: this is written with the assumption that this will be an universal feature, and this is not the way it should be addresses. I don’t agree with the key issue. Samsung supported this. NTT-Docomo: International (non-US) customers would have to deal with the fact that they will possess an UE vulnerable to man-in-the-middle attacks. BT supported Docomo. There was no agreement with this document.
 		noted No    
S3‑191542 Discussion on Action Item 94/1 Samsung discussion Endorsement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		noted No    
S3‑191543 Solution for integrity protection of UP signalling messages Samsung pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191544 pCR of clause 7- evaluation and conclusion China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
No
Yes
 		withdrawn Yes    
S3‑191545 pCR of clause 7- evaluation and conclusion China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191546 pCR of clause 7- evaluation and conclusion China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
No
Yes
 		withdrawn Yes    
S3‑191547 Security Requirements for CAPIF-3e/4e/5e reference points Samsung CR Approval
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16)
 		Yes
Yes
 		agreed No    
S3‑191548 Individual Evaluations of solution #7- #12 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‑191549 Clarification to Initial NAS message protection Samsung CR Approval
7.1.5NAS security
 		Yes
YesThis had to be discussed offline and Samsung will bring a modified version for the next meeting.
 		not pursued No    
S3‑191550 Clarification to Solution#1 of PARLOS Samsung pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesVodafone: any authentication in the PARLOS network here? Samsung: it's just an update on an existing procedure. Vodafone wasn't sure that this would work technically. ORANGE: evaluation needs to be updated, add it here. Maybe add a note on the technical feasbility of this solution.
 		noted No    
S3‑191551 Alignment of the term Non-Standalone NPN Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191552 Editor’s note for KI #1.1 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191553 Resolution of Editor’s note on privacy impact in Solution #3 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191768  
S3‑191554 Editorial Changes to TR 33.835 v0.4.0 China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191555 Resolution of Editor’s note on entities protected in Solution #3 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191556 Evaluation to Solution #3 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesEricsson: how do you know that the UE is present without authentication and not a reply attack? Samsung: this is always possible but it is not addressed in this key issue. Editor's note added: change of CAGid by the network, provisioning of the updated id to the UE is out of scope of this solution.
 		revised No S3‑191773  
S3‑191557 Individual Evaluation of solution #6 China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
No
Yes
 		withdrawn Yes    
S3‑191558 Individual Evaluation of solution #6 China Mobile pCR Approval
8.5Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
Yes
Yes
 		not treated No    
S3‑191559 Mitigation against linkability attack Gemalto N.V. pCR Approval
8.19Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191560 Removing the EN on AMF log NTT DOCOMO, Deutsche Telekom pCR  
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		revised No S3‑191651  
S3‑191561 Meeting minutes of AKMA conference calls China Mobile discussion Information
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‑191562 Addition of AMF/SMF requirement on security logging Deutsche Telekom AG, NTT Docomo CR Approval
7.1.16Others
 		Yes
Yes
 		agreed No   S3‑191262
S3‑191563 Virtualisation Study Key Issue 1 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191719  
S3‑191564 Virtualisation Study Key Issue 2 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191720  
S3‑191565 Virtualisation Study Key Issue 3 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191566 Virtualisation Study Key Issue 4 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191567 Virtualisation Study Key Issue 5 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
YesHuawei: what's the requirement for 3GPP here? BT: good question, not trivial. It was commented that most probably there would be no requirements, but it was good to document it. This was asked to be captured in the minutes.
 		revised No S3‑191778  
S3‑191568 Virtualisation Study Key Issue 6 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191569 Virtualisation Study Key Issue 7 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191570 Virtualisation Study Key Issue 8 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191571 Virtualisation Study Key Issue 9 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191572 Virtualisation Study Key Issue 10 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191573 Virtualisation Study Key Issue 11 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191574 Virtualisation Study Key Issue 12 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191575 Virtualisation Study Key Issue 13 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191576 Virtualisation Study Key Issue 14 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191577 Virtualisation Study Key Issue 15 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191578 Virtualisation Study Key Issue 16 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191579 Virtualisation Study Key Issue 17 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191580 Virtualisation Study Key Issue 18 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191581 Virtualisation Study Key Issue 19 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191582 Virtualisation Study Key Issue 20 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191583 Virtualisation Study Key Issue 21 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191584 Virtualisation Study Key Issue 22 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191585 Virtualisation Study Key Issue 23 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191586 Residential use case for 5G Core with fixed broadband access CableLabs LS in  
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191587 Virtualisation Study Key Issue 24 BT plc pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		not treated No    
S3‑191588 User Plane Security for 5GC Roaming (re: S3-191016) GSMA LS in  
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑191589 Discussion on removing the authentication result in the UDM Huawei, Hisilicon discussion Discussion
7.1.8Primary authentication
 		Yes
YesEricsson: the attack is valid in a very rare case. There wasn't much support for this and the accompanying CR was not pursued.
 		noted No   S3‑191417
S3‑191590 Secure LI Data Access Living Document BT plc other Agreement
7.6.2IP Multimedia Subsystem (IMS) Security
 		No
Yes
 		withdrawn Yes    
S3‑191591 Comments on S3-191301, Draft Reply LS on protection of PC5-RRC messages for sidelink unicast communication InterDigital Germany GmbH LS out Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesCATT commented that there was no intervention of the operator through PC5, car-to-car communication/unicast security is established in a different scenario from the operator's network. LG: there is still information exchange with gNodeB. Nokia: we need more information on the PC5 protocol layer to answer question 2.
 		revised No S3‑191622  
S3‑191592 Comment on contribution S3-191553 InterDigital Belgium. LLC discussion Discussion
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑191593 Providing some evaluation for solution #2 in TR 33.815 Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
YesBT: no need for man in the middle. The attacker can just call asking the user to make a call to to PARLOS. Qualcomm: it doesn’t need to be an RLOS number, it can be a premium number or whatever. Vodafone:add an editor's note on the hability of the user to identify the trust of the PARLOS network needing to be provided. NTT-Docomo: paragraph three needs to go away.
 		revised No S3‑191728 S3‑191527
S3‑191594 Proposed conclusion for establishing the RLOS call Qualcomm Incorporated, Ericsson, Verizon UK Ltd pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		revised No S3‑191595 S3‑191528
S3‑191595 Proposed conclusion for establishing the RLOS call Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		noted No   S3‑191594
S3‑191596 New KI for PLMN integrated NPN InterDigital Germany GmbH pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesThere was no agreement with the security threats and requirements.
 		revised No S3‑191769 S3‑191107
S3‑191597 New KI for Public network integrated NPN InterDigital Germany GmbH pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑191770 S3‑191164
S3‑191598 Report from SA3#94 MCC report Approval
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
Yes
 		approved No    
S3‑191599 Reply to: LS on usage of EPLMNs Vodafone LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑191600 Reply to: LS on broadcast assistance data delivery Intel LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑191601 Reply to: Reply LS on authentication of group of IoT devices Huawei LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑191602 pCR to TR33.814 - Key issue for integrity protection of broadcast assistance data CATT pCR -
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
YesSame as tdoc 351. This was already addressed in tdoc 600.
 		noted No   S3‑191353
S3‑191603 Aligning the storage timing of KAUSF in 5G AKA with EAP-AKA' NEC Europe Ltd CR Agreement
7.1.2Key derivation
 		Yes
Yes
 		agreed No   S3‑191205
S3‑191604 Rectifying incorrect limitation for horiz/vert key derivation Ericsson CR Agreement
7.1.2Key derivation
 		Yes
Yes
 		agreed No   S3‑191446
S3‑191605 Corrections on the s-Kgnb derivation Huawei, Hisilicon CR Approval
7.1.2Key derivation
 		Yes
Yes
 		agreed No   S3‑191367
S3‑191606 Clarification on securing the procedure of idle mobility from 5GS to EPS over N26 interface Huawei, Hisilicon CR Approval
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑191407
S3‑191607 Clarification for the NAS MAC failure case in N2 HO Qualcomm Incorporated,Huawei,Ericsson CR Agreement
7.1.3Mobility
 		Yes
Yes
 		agreed No   S3‑191512
S3‑191608 Reply to: LS on Security failure of NAS container in HO command Ericsson LS out approval
7.1.5NAS security
 		Yes
Yes
 		approved No    
S3‑191609 Add detials on handling UP security in RRC inactive scenario Huawei, Hisilicon CR Approval
7.1.4AS security
 		Yes
Yes
 		agreed No   S3‑191379
S3‑191610 Response LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode Qualcomm Incorporated LS out Approval
7.1.5NAS security
 		Yes
Yes
 		approved No   S3‑191505
S3‑191611 Clarification for Initial NAS Message Protection Huawei, Hisilicon CR Approval
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑191387
S3‑191612 UP policy handling in case of unauthenticated emergency calls Ericsson CR Agreement
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑191447
S3‑191613 Response LS on handling of non-zero ABBA value in Release 15 Qualcomm Incorporated LS out Approval
7.1.5NAS security
 		Yes
Yes
 		approved No   S3‑191504
S3‑191614 Clarification for the NAS MAC failure case in interworking Qualcomm Incorporated,Ericsson CR Agreement
7.1.10Interworking
 		Yes
Yes
 		agreed No   S3‑191513
S3‑191615 Reply to: Reply LS on Verification of PLMN-ID in the SEPP Deutsche Telekom LS out approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No    
S3‑191616 Addition of missing SEPP requirement on JOSE-patch validation Deutsche Telekom AG CR Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		agreed No   S3‑191185
S3‑191617 Name clarification for N32 security Ericsson,NCSC CR Agreement
7.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		agreed No    
S3‑191618 LS on clarification for N32 security Ericsson LS out Approval
7.1.13.1Interconnect (SEPP related)
 		Yes
YesThe LS will attach the CR in 617 and sent to SA and CT so the Plenary can decide whether to accept it or not.
 		approved No    
S3‑191619 Token-based authorization for NRF's management and discovery services Ericsson CR Agreement
7.1.13.2Other
 		Yes
YesHuawei didn’t agree with the changes.
 		not pursued No   S3‑191314
S3‑191620 Protection of unicast message Apple Computer Trading Co. Ltd pCR Approval
8.9Study on 5G security enhancement against false base stations
No
YesQualcomm added three editor's notes related to the key provisioning from 781 and one on camping. ORANGE also added some editor's notes and corrections.
 		approved No   S3‑191345
S3‑191621 Slice information for token-based authorization Ericsson CR Agreement
7.1.13.2Other
 		Yes
Yes
 		agreed No   S3‑191315
S3‑191622 Reply LS on protection of PC5-RRC messages for sidelink unicast communication InterDigital Germany GmbH,LG LS out Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191591
S3‑191623 Way forward in CVD and research CableLabs discussion discussion
6.10CVDs and Research
 		Yes
YesQualcomm: published papers can be discussed publicly in the SA3 mail list. Vodafone: uncomfortable to discuss these papers in an open meeting. It was decided to continue the discussions in the next meeting on how to address the academic papers. Qualcomm warned about legal issues if a private discussion group for SA3 was created, so they wanted to check back at home the implications of this. MCC reminded that there existed a closed group for VCD where papers could be discussed before their publication and a first response could be given before discussions in SA3.
 		noted No    
S3‑191624 Essential clarification of MSIN coding for the ECIES protection shemes IDEMIA,Gemalto, Qualcomm,Ericsson,Huawei,HiSilicon,Intel CR Approval
7.1.14Privacy
 		Yes
Yes
 		agreed No   S3‑191163
S3‑191625 Clarification on the SUCI compuation Huawei, Hisilicon, Gemalto, IDEMIA CR Approval
7.1.14Privacy
 		Yes
YesAdded a reference as proposed by Ericsson.
 		agreed No   S3‑191414
S3‑191626 subscriber privacy: ECIES test data Gemalto, IDEMIA, Huawei, Hisilicon CR Approval
7.1.14Privacy
 		Yes
Yes
 		agreed No   S3‑191220
S3‑191627 Missing privacy parameters Ericsson,Gemalto,IDEMIA CR Agreement
7.1.14Privacy
 		Yes
Yes5.8.2 was removed and NOTE 2 modified.
 		agreed No   S3‑191453
S3‑191628 LS on support of non-3GPP only UE and support for PEI in IMEI format S2-1904836 LS in discussion
7.1.15Incoming and outgoing Lses
 		Yes
Yes
 		postponed No    
S3‑191629 Reply to: Reply LS on Nudr Sensitive Data Protection Hewlett Packard Enterprise LS out approval
7.1.16Others
 		Yes
YesNokia had a proposal to make a change in TS 33.501 with a new requirement. It was said that she could bring it back in the next meeting as Ericsson requested more time to check it.
 		approved No    
S3‑191630 Adding gNB critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		agreed No   S3‑191381
S3‑191631 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No   S3‑191463
S3‑191632 Corrections on IP packet forwarding Ericsson CR Agreement
7.6.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesThe changes of this CR were agreed and Ericsson will bring this CR again in the next meeting; also CRs for Rel-14 and Rel-15 in order to send them to SA as a pack provided that there were no impacts as requested by Huawei.
 		not pursued No   S3‑191321
S3‑191633 Correction of ShortResumeMAC-I calculation for EDT Ericsson,Huawei CR Agreement
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		agreed No   S3‑191440
S3‑191634 Reply LS to RAN2/RAN3 on EDT UP IP Huawei, Hisilicon LS out Approval
7.6.10Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		approved No   S3‑191246
S3‑191635 Interface and protocol stack clarifications and corrections to TS 33.163 Juniper Networks CR Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑191172
S3‑191636 Interface and protocol stack clarifications and corrections to TS 33.163 Juniper Networks CR Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑191173
S3‑191637 Making UE initiated key refresh optional in TS33.163 Juniper Networks CR -
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑191174
S3‑191638 Deprecation of TLS 1.1 Ericsson CR Agreement
7.6.16Other work items
 		Yes
Yes
 		agreed No   S3‑191308
S3‑191639 New SID: Study on security aspects of enhancement of support for Edge Computing in 5GC China Unicom, CAICT, China Telecom, ZTE,Huawei SID new -
8.23New study item proposals
 		Yes
YesORANGE: very little work done in SA2 since their study item was approved in the last plenary. Qualcomm agreed. The Chair asked if it was ok to wait for SA2's progress. China Unicom asked when it was good time to bring back this. Qualcomm replied that it would be a good timing when SA2 had drafted some conclusions in their study. This was agreed, China Unicom asked for offline feedback for their study paper.
 		noted No   S3‑191292
S3‑191640 Adapting maximum HTTP payload size to CT4 specification Deutsche Telekom pCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No    
S3‑191641 [MCPTT] 33179 R13. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑191113
S3‑191642 [MCSec] 33180 R14. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑191114
S3‑191643 [MCSec] 33180 R15. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑191115
S3‑191644 {33.179] R13 Remove IANA editor's notes Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑191168
S3‑191645 [33.180] R14 Remove IANA editor’s notes Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑191169
S3‑191646 [33.180] R15 Remove IANA editor’s notes (mirror) Motorola Solutions UK CR Agreement
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		agreed No   S3‑191170
S3‑191647 [33.180] R16 Establishment of PCK for MCData Samsung CR Agreement
7.3eMCSec R16 security (MCXSec) (Rel-16)
 		Yes
Yes
 		agreed No   S3‑191171
S3‑191648 skeleton of security aspects of 5G SRVCC to UTRAN China Unicom draftCR Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
YesNew version of the living document.
 		approved No    
S3‑191649 Security procedures of 5G SRVCC to UTRAN Huawei,China Unicom,CATT other Approval
7.4Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191650 Test case on UE security capability invalid or unacceptable Huawei, Hisilicon pCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		approved No   S3‑191401
S3‑191651 Removing the EN on AMF log NTT DOCOMO, Deutsche Telekom,Huawei pCR -
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		approved No   S3‑191560
S3‑191652 Draft TS 33.512 Deutsche Telekom draft TS Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		approved No    
S3‑191653 Addition of Network Product Class Description for AMF Deutsche Telekom AG draftCR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		approved No    
S3‑191654 Addition of AMF-related Security Problem Descriptions Deutsche Telekom AG CR Approval
7.2.2Access and Mobility Management Function (TS 33.512)
 		Yes
Yes
 		agreed No   S3‑191182
S3‑191655 Security Assurance Requirements and Test Case on TEID Uniqueness for SMF Huawei, Hisilicon,Nokia pCR Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No   S3‑191396
S3‑191656 Draft TS 33.515 Huawei draft TS Approval
7.2.5Session Management Function (SMF) (TS 33.515)
 		Yes
Yes
 		approved No    
S3‑191657 Testcase: Replacing confidential IEs with NULL in original N32-f message Deutsche Telekom AG pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑191186
S3‑191658 Draft TS 33.517 Nokia draft TS Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No    
S3‑191659 New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑191466
S3‑191660 Updates to SEPP Test Cases Nokia, Nokia Shanghai Bell pCR Approval
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
 		Yes
Yes
 		approved No   S3‑191467
S3‑191661 eSBA: Solution to KI #27 - UP Gateway function for protection of inter-PLMN N9 interface Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑191525
S3‑191662 Way forward on the security test of NRF authorization Huawei, Hisilicon discussion Endorsement
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		endorsed No   S3‑191398
S3‑191663 Security Assurance Requirement and Test for NRF authorization on the NF discovery Huawei, Hisilicon pCR Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		approved No   S3‑191399
S3‑191664 New Annex for the NRF in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		approved No   S3‑191468
S3‑191665 Draft TS 33.518 Nokia draft TS Approval
7.2.8Network Resource Function (NRF) (TS 33.518)
 		Yes
Yes
 		approved No    
S3‑191666 Discussion document on roaming UP gateway Juniper Networks discussion Endorsement
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		endorsed No   S3‑191177
S3‑191667 Draft 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‑191668 Solution to KI #26: NDS/IP on the inter-PLMN N9 interface Juniper Networks, Nokia pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑191219
S3‑191669 Key issue of signalling between SEPP and IPX provider Deutsche telekom pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑191670 New Key Issue for TR 33.836 - privacy protection for multicast messages over PC5 InterDigital Germany GmbH,LG pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191110
S3‑191671 eSBA: Solution to KI #22 - Service access authorization for Indirect Communication with delegated discovery (Model D) Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑191485
S3‑191672 eSBA: Solution to KI #23: NF to NF authentication and authorization in Indirect communications model Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
YesAdding editor's note on the different deployment scenarios. Added statement on key issue addressed.
 		approved No   S3‑191523
S3‑191673 Key issue on authorization for delegated "Subscribe-Notify" interaction scenarios Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑191403
S3‑191674 New solution for service access authorization within a NF Set Huawei, Hisilicon pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑191416
S3‑191675 eSBA: NF Consumer authentication for based on signed API Request Nokia, Nokia Shanghai Bell pCR Approval
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑191676 CIoT: Definitions and Abbreviations Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191435
S3‑191677 Draft TR 33.861 Ericsson draft TR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		No
Yes
 		left for email approval No    
S3‑191678 update solution#4 with UP IP during EDT for multiple PDCP PDUs. Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesIt was agreed to fix a typo and replace gNodeB.
 		approved No   S3‑191249
S3‑191679 CIoT: Update to Solution #4 Ericsson pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesRevised as a completely new solution. Editors note from Qualcomm. Reformulation from Vodafone.
 		approved No   S3‑191437
S3‑191680 Update of Solution #6 – Use of UE Configuration Update KPN pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191180
S3‑191681 Updating solution#7 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191252
S3‑191682 Resolving EN in Solution 9 Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesHuawei commented and asked to be minuted: "All solutions which include short UP packets in NAS messages, e.g., Registration Request, Registration Complete, etc. depend on SA2 decision"
 		approved No   S3‑191510
S3‑191683 Resolving EN in Solution 10 Qualcomm Incorporated pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191511
S3‑191684 Delete EN in solution12 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191365
S3‑191685 Add evalution in solution12 Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191366
S3‑191686 Proposal for improvement FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191189
S3‑191687 Proposal for editor's notes in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191188
S3‑191688 Resolve ENs on Solution to Mitigate DDoS Attack based on RAN Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191388
S3‑191689 Solution to Mitigate DDoS Attack on AMF caused by Massive Misbehaving Infrequent CIoT Ues Huawei, Hisilicon pCR Approval
8.6Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
 		Yes
YesWording changes as proposed by Vodafone.
 		approved No   S3‑191390
S3‑191690 New Key Issue: SUCI-to-SUPI mapping for the FN-RG Ericsson pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191318
S3‑191691 Proposal for FS_UP_IP_Sec Key Issue #3 and 5: Zero-overhead user plane integrity protection on the link layer Philips International B.V. pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
YesLenovo: for NR or LTE? Philips: for both. Huawei: for LTE it is impossible. Vodafone: this is not a TS, we don’t need approval from RAN2 to introduce a solution in the TR, it is not a conclusion. Lenovo,Ericsson, Nokia: let's not advance with this given the answer from RAN2 in their LS.
 		noted No   S3‑191191
S3‑191692 IAB - terminology Ericsson pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑191456
S3‑191693 Draft TR 33.824 Samsung draft TR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No    
S3‑191694 IAB Architecture Samsung pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
YesAdding an editor's note on alignment with RAN specs.
 		approved No   S3‑191536
S3‑191695 IAB - security architecture diagram solution Ericsson-LG Co., LTD pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑191491
S3‑191696 A new KI for the authentication framework for the UE Ericsson,Intel pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑191458
S3‑191697 A new KI for the authentication framework for an IAB node acting as a MT Ericsson,Samsung pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑191459
S3‑191698 A new KI for activating communication security in IAB node Ericsson,Intel pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑191460
S3‑191699 Solution for IAB Node authentication and authorization Samsung pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑191539
S3‑191700 F1 interface security for IAB Qualcomm Incorporated pCR Approval
8.20Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No   S3‑191517
S3‑191701 New Test Case: Error handling of malformed JSON object between two network products NEC Europe Ltd draftCR Agreement
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		noted No   S3‑191487
S3‑191702 New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC CableLabs pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		noted No   S3‑191193
S3‑191703 Discussion on proposed response to incoming LS (S3-191138) on authentication of UEs not supporting NAS Charter Communications, CableLabs discussion Discussion
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		No
Yes
 		noted No   S3‑191221
S3‑191704 Modification on Use of SUCI in NAS signalling ZTE Corporation,Intel CR Agreement
7.1.14Privacy
 		Yes
Yes
 		agreed No   S3‑191306
S3‑191705 Security of RRC Reestablishment during N2 HO Huawei LS out Approval
7.1.4AS security
 		Yes
YesQualcomm and Ericsson were against sending this LS. Huawei pointed out that most companies were OK with this.
 		noted No    
S3‑191706 Add references Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191371
S3‑191707 Add content to clause 4 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191372
S3‑191708 Delete Editor's Note in KI#4 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesThe requirement was removed since the security of the nterface was not in the scope of the document.
 		approved No   S3‑191373
S3‑191709 Add requirement and delete EN for KI#13 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
YesRemoving the e.g. as proposed by Ericsson.
 		approved No   S3‑191374
S3‑191710 Draft TR 33.807 Huawei draft TR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191711 Add conclusion on KI#3 Huawei, Hisilicon pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
YesFirst paragraph: reference to the solution. Second paragraph is gone as proposed by Nokia.
 		approved No   S3‑191377
S3‑191712 Evaluation of Solution #1 Lenovo, Motorola Mobility pCR Approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191486
S3‑191713 Reply LS on Authentication for UEs not Supporting NAS Nokia LS out approval
8.7Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191714 Scope for TR 33 848 BT plc pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191217
S3‑191715 Virtualisation Background and Concepts NCSC pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191222
S3‑191716 Key Issue: Establishment of trust domains for Network Functions NCSC pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191224
S3‑191717 Key Issue: Confidentiality of Sensitive Data NCSC pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191225
S3‑191718 Key Issue: Availability of Network Functions NCSC pCR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191226
S3‑191719 Virtualisation Study Key Issue 1 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191563
S3‑191720 Virtualisation Study Key Issue 2 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
YesLast sentence was removed as challenged by Gemalto. MCC: remove the "must". We don't have to refer to ETSI ISG NFV phase one as a whole, better refer to specific documents.
 		approved No   S3‑191564
S3‑191721 Initial Key Issues for TR 33.848 BT plc pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191216
S3‑191722 Draft TR 33.848 BT draft TR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		revised No S3‑191777  
S3‑191723 Evaluation and text for resolving editor’s note for solution #5 in TR 33.825 NEC Europe Ltd,Huawei pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		No
Yes
 		noted No   S3‑191215
S3‑191724 Delete the EN of solution 5 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191286
S3‑191725 WID on security of URLLC Huawei, HiSilicon WID new Endorsement
7.7New Work Item proposals
 		Yes
Yes
 		agreed No   S3‑191288
S3‑191726 WID proposal for 5GS Vertical_LAN_SEC Nokia, Nokia Shanghai Bell WID new Agreement
7.7New Work Item proposals
 		No
Yes
 		agreed No   S3‑191434
S3‑191727 Clarification to Solution#1 of PARLOS Samsung pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑191728 Providing some evaluation for solution #2 in TR 33.815 Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd pCR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191593
S3‑191729 Draft TR 33.815 Qualcomm draft TR Approval
8.8Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191730 eNS Update to solution 1 Slice specific secondary authentication Nokia, Nokia Shanghai Bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191227
S3‑191731 Draft TR 33.813 Nokia draft TR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191732 Removing ENs for solution #2 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191328
S3‑191733 Add Evaluation to Solution #2 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191329
S3‑191734 Update to solution #4 InterDigital Belgium. LLC pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191118
S3‑191735 Solution to KI #4 Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191326
S3‑191736 A solution to NSSAI protection at AS transmission Huawei, HiSilicon pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191324
S3‑191737 Proposed solution for protecting the S-NSSAI for transmission at the AS layer Qualcomm Incorporated pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191499
S3‑191738 Solution to protect user ID over the air interface Ericsson pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191439
S3‑191739 Preliminary comparison of solutions Nokia, Nokia Shanghai Bell pCR Approval
8.11Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191228
S3‑191740 New Key Issue-Security of identifiers in group communication Huawei, HiSilicon pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191340
S3‑191741 Completing TS 33.511 Huawei, Hisilicon pCR Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No   S3‑191380
S3‑191742 URLLC: Resolving EN in solution #8 Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191474
S3‑191743 Handling of UE radio network capabilities in 4G and 5G GSMA LS in discussion
6.10CVDs and Research
 		Yes
YesVodafone: RAN2 should do something first, and they are meeting next week. Our next meeting is after SA, so we would have to have a conference call to address this to meet the deadline. Qualcomm: the issue is in RAN. It's a gNodeB configuration. It's a "should" requirement from the network side to first activate security. NTT-Docomo: we could have a conference call to address this. Qualcomm: RAN is meeting next week and then in August. It was decided to postpone and come up with a conference call between June and August if necessary.
 		postponed No    
S3‑191744 Clause 4 Security Aspects of Advanced V2X services LG Electronics pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191302
S3‑191745 Draft TR 33.836 LG draft TR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑191746 New Key Issue for TR 33.836 - privacy protection for unicast messages over PC5 InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191109
S3‑191747 New Key Issue for TR 33.836 - security for eV2X unicast messages over PC5 InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191111
S3‑191748 KI_security for setting up multicast Huawei, Hisilicon pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191385
S3‑191749 New Key Issue for TR 33.836 - Security of the UE service authorization and revocation InterDigital Germany GmbH pCR Approval
8.21Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑191112
S3‑191750 LS on security and privacy aspects of NR positioning Ericsson LS out Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191443
S3‑191751 Clarification on Subscription Identifier mechanism for De-registration. Intel Corporation (UK) Ltd CR -
7.1.14Privacy
 		Yes
YesNokia: this opens up a DoS attack scenario but it's too late to change this in Rel-15. Qualcomm agreed.
 		agreed No   S3‑191258
S3‑191752 Reply to: LS on Use of SUCI in NAS signalling Intel LS out approval
7.1.14Privacy
 		Yes
Yes
 		approved No    
S3‑191753 IANA assigned values for mission critical Motorola LS out Approval
7.6.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
 		Yes
Yes
 		approved No    
S3‑191754 Address EN and update in key issue 5 Huawei, Hisilicon pCR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191368
S3‑191755 Draft TR 33.814 CATT draft TR Approval
8.12Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191756 Draft TR 33.825 Huawei draft TR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191757 Deleting EN of solution 4 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191279
S3‑191758 Evaluation for solution 4 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191280
S3‑191759 Deleting the EN of solution 3 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191277
S3‑191760 Adding more clarification text of solution 7 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191278
S3‑191761 Evaluation for solution 6 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191287
S3‑191762 URLLC: Evaluation to solution #8 Ericsson pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191475
S3‑191763 Security solutions summary Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191276
S3‑191764 Conclusion for key issue 1 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191270
S3‑191765 Conclusion for key issue 4 Huawei, HiSilicon pCR Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191273
S3‑191766 Draft TR 33.819 Nokia draft TR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191767 Solution and conclusion for TSC Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191427
S3‑191768 Resolution of Editor’s note on privacy impact in Solution #3 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesEditor's note was finally kept.
 		approved No   S3‑191553
S3‑191769 New KI for PLMN integrated NPN InterDigital Germany GmbH pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191596
S3‑191770 New KI for Public network integrated NPN InterDigital Germany GmbH pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191597
S3‑191771 Solutions and conclusion for SNPN service access via PLMN and vice versa Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191424
S3‑191772 update in solution 3 Huawei, Hisilicon pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191370
S3‑191773 Evaluation to Solution #3 Samsung pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191556
S3‑191774 Summary of security aspects covered in this study Nokia, Nokia Shanghai Bell pCR Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
YesLast part from "the key issues are grouped.." removed as proposed by Qualcomm.
 		approved No   S3‑191430
S3‑191775 Draft TR 33.853 Vodafone draft TR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191776 Integrity protection between SgNB and UE in NGEN-DC Apple Computer Trading Co. Ltd pCR Approval
8.17Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191265
S3‑191777 Draft TR 33.848 BT draft TR Approval
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191722
S3‑191778 Virtualisation Study Key Issue 5 BT Group pCR Agreement
8.18Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
 		Yes
Yes
 		approved No   S3‑191567
S3‑191779 Draft TR 33.809 Apple draft TR Approval
8.9Study on 5G security enhancement against false base stations
No
Yes
 		left for email approval No    
S3‑191780 Shared key based MIB/SIB protection Qualcomm Incorporated pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesAdding an editor's note as proposed by Huawei.
 		approved No   S3‑191508
S3‑191781 Certificate based solution for 5GFBS Apple Computer Trading Co. Ltd pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesIntroducing editor's notes as proposed by ORANGE: roaming aspects, MNO controlling the revocation of CA, other signature algorithms are FFS. Qualcomm: issue of camping needs to be clarified.Editor's note on this was added. Also editor's notes on the manufacturing time, interworking with UE USIM and gNodeB.
 		approved No   S3‑191267
S3‑191782 ID based solution for 5GFBS Apple Computer Trading Co. Ltd pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No   S3‑191268
S3‑191783 Correction to the handling of security context in the multi-NAS scenario Qualcomm Incorporated,Ericsson,Huawei CR Agreement
7.1.5NAS security
 		Yes
Yes
 		agreed No   S3‑191501
S3‑191784 Draft agenda SA3_95-BIS WG Chair discussion Discussion
11Any Other Business
 		No
YesOrder of study items will be reverse of what was treated during this meeting. The Chair recommended to have conference calls in order to save meeting time and progress in the work, and avoid non treated documents.
 		noted No    
S3‑191785 Draft TS 33.511 Huawei draft TS Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No    
S3‑191786 Cover sheet TS 33.511 Huawei TS or TR cover Approval
7.2.1NR Node B (gNB) (TS 33.511)
 		Yes
Yes
 		approved No    
S3‑191787 Cover sheet TR 33.825 Huawei TS or TR cover Approval
8.13Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191788 Overview of TR33.856 China Unicom CR -
8.4Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		agreed No   S3‑191295
S3‑191789 Add New Security Threat and Requirement for Key Issue #1 for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
YesEricsson didn’t agree with the requirement, so an editor's note was added as suggested bu NTT-Docomo.
 		approved No   S3‑191393
S3‑191790 Mitigation against the authentication relay attack with different PLMNs Lenovo, Motorola Mobility pCR Approval
8.9Study on 5G security enhancement against false base stations
Yes
Yes
 		approved No   S3‑191488
S3‑191791 Cover sheet TR 33.819 Nokia TS or TR cover Approval
8.15Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑191792 Work Plan input from Rapporteurs MCC other -
9.2Rapporteur input on status of WID or SID
 		No
Yes
 		noted No   S3‑191105
S3‑191793 SA3 meeting calendar MCC other -
10Future Meeting Dates and Venues
 		No
YesPossibility of one or two adhocs in 2020, for further consideration. November 2020, it could be NAF or Huawei (Singapore). Feb 2020 hosted by CF3. IF3 has offered to host.
 		noted No   S3‑191104