Tdoc List

2017-05-22 10:30

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑171000 Agenda WG Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No    
S3‑171001 Report from SA3#86 MCC report  
4.1 Approval of the report from SA3#86 and SA3 ad-hoc
 		Yes
Yes
 		approved No    
S3‑171002 Report from SA3 Adhoc MCC report  
4.1 Approval of the report from SA3#86 and SA3 ad-hoc
 		Yes
Yes
 		approved No    
S3‑171003 SA3 Work Plan MCC Work Plan  
9Review and Update of Work Plan
Yes
Yes
 		noted No    
S3‑171004 Report from last SA meeting WG Chairman report  
4.2Report from SA #75
 		Yes
Yes
 		noted No    
S3‑171005 SA3 meeting calendar MCC other  
10Future Meeting Dates and Venues
 		Yes
Yes
 		noted No    
S3‑171006 Work Plan input from Rapporteurs MCC other  
9Review and Update of Work Plan
Yes
Yes
 		revised No S3‑171446  
S3‑171007 Middlebox security protocol ETSI TC CYBER LS in  
6.9TC-CYBER
 		Yes
Yes
 		replied to No    
S3‑171008 Reply LS on update to key management for application signalling C1-171654 LS in  
5Items for early consideration
 		Yes
Yes
 		replied to No    
S3‑171009 LS on MCData protocol and choice of media plane protocol C1-171820 LS in  
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		replied to No    
S3‑171010 Reply LS on security in E-UTRA-NR Dual Connectivity C1-171941 LS in  
8.3.18Other
 		Yes
Yes
 		noted No    
S3‑171011 Reply LS on LTE call redirection to GERAN C1-171945 LS in  
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑171012 Reply LS on security aspects of external xMB interface for TV services C3-171264 LS in  
5Items for early consideration
 		Yes
Yes
 		replied to No    
S3‑171013 LS on Support of Explicit Bootstrapping in ERP C4-172269 LS in  
7.6.17Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)
 		Yes
Yes
 		replied to No S3‑171379  
S3‑171014 Reply LS on eDRX Configuration and IMSI-paging C4-172276 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑171015 Liaison statement to ETSI 3GPP SA3 ETSI TC CYBER QSC LS in  
6.9TC-CYBER
 		Yes
Yes
 		noted No    
S3‑171016 LS to RIFS and SA3 on Diameter Security GSMA PACKET LS in  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia was in favour of tackling on this work and answer to GSMA. Deutsche Telekom commented that there was no action needed. KPN: we did something in security 10, we can mention in a reply. It was agreed to reply to the LS in 540 about the same topic.
 		noted No    
S3‑171017 LS on LTE call redirection to GERAN R2-169124 LS in  
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑171018 LS on mobility enhancements for NB-IoT R2-1702290 LS in  
7.6.14Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑171019 LS on LTE call redirection to GERAN R2-1702388 LS in  
7.6.1SAE/LTE Security
 		Yes
YesDocomo: Mandating user interaction will not work for LTE devices that have no user. Nokia: Initial Attach: UE authenticated, the attack is possible, there is no solution now. This LS refer to Mobile terminated voice call: there are two solutions, in RAN2 and CT1. 360 was concerned about the initial attach scenario. The Chair clarified that this wasn’t addressed in the LS.
 		replied to No    
S3‑171020 LS on providing WT MAC address to the UE using eNB signalling R2-1702440 LS in  
7.6.1SAE/LTE Security
 		Yes
Yes
 		replied to No    
S3‑171021 LS to SA3 on actions for integrity check failure on SgNB R2-1703959 LS in  
8.3.18Other
 		Yes
Yes
 		replied to No    
S3‑171022 Reply LS on SA3 LS in S3-170944 “LS on security termination for the User Plane in 5G” R2-1703960 LS in  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDeutsche Telekom: what does "low" mean exactly? It's ambiguous and I'm not sure how this impacts our security design. Nokia: it refers to the timing part.DU and CU are almost co-located. KPN agreed with this being too ambiguous. Ericsson: it's saying that latency won’t be a problem. Docomo: it says that they asume that there is no latency.
 		noted No    
S3‑171023 Reply LS on security in E-UTRA-NR Dual Connectivity R2-1703961 LS in  
8.3.18Other
 		Yes
Yes
 		replied to No    
S3‑171024 LS on paging remote UEs over relays R2-1703967 LS in  
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171025 Reply LS on mobility enhancements for NB-IoT UEs R3-170896 LS in  
7.6.14Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑171026 LS on eDRX Configuration and IMSI-paging R3-170908 LS in  
6.13GPP Working Groups
 		Yes
YesNokia: no implication on us, but CT4 and RAN3 need to align. Docomo, DT: some info is being revealed, so this can have repecursions. It was agreed to follow these discussions closely for possible repercusions.
 		noted No    
S3‑171027 Response LS on Progress on Security for LWIP R3-171272 LS in  
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑171028 LS on Status of Higher-Layer Functional split between Central and Distributed unit R3-171306 LS in  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171029 Reply LS on N2 and N3 reference points for 5G system R3-171401 LS in  
8.3.18Other
 		Yes
Yes
 		noted No    
S3‑171030 LS on the support of Unicast and Groupcast transmission over PC5 for eV2X RP-170841 LS in  
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		noted No    
S3‑171031 Reply LS on applicability of WLAN emergency numbers on 3GPP access S1-171446 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑171032 Reply LS on UE-to-NW relaying S2-170398 LS in  
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		postponed No    
S3‑171033 Reply LS on SeDoC related authentication procedure S2-171615 LS in  
6.13GPP Working Groups
 		Yes
YesNokia found the response satisfactory.
 		noted No    
S3‑171034 LS on PC5 Secure Communication S2-171621 LS in  
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		postponed No    
S3‑171035 Reply LS to LS on applicability of WLAN emergency numbers on 3GPP access (C1-170513/S2-171630) S2-172507 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑171036 LS on Security Aspects Related to Non-3GPP authentication for (re)registration S2-172523 LS in  
8.3.18Other
 		Yes
Yestdoc 346 addresses this issue.
 		replied to No    
S3‑171037 LS on E-UTRA in NG-RAN (5G System) S2-172730 LS in  
8.3.18Other
 		Yes
Yes
 		noted No    
S3‑171038 Reply LS to SA3 on standardization of Northbound SCEF API S2-172738 LS in  
6.13GPP Working Groups
 		Yes
YesVodafone thought that the response included wrong statements. No architecture changes are required to enable EMDSDP. BT: do we need to change anything to expose capabilities to a higher layer? Vodafone: BEST is just user data, transparent at this point. You can see from the Attach that is a BEST service. This LS had to be taken offline for further consideration from Vodafone. Huawei commented that there was no concerns and no response was needed. Vodafone: we have covered everything and there is nothing else to do. This was agreed.
 		noted No    
S3‑171039 Reply LS to LS on state of SA3 discussions on NG security architecture S2-172861 LS in  
8.3.18Other
 		Yes
YesVodafone: Combining two different PLMNs, two different accesses, two different technologies? Having two different Home Networks? This is what the LS implies. Orange supported Vodafone. Qualcomm: it's not about having two HPLMNs.
 		noted No    
S3‑171040 LS on 5GS Security aspects seeking resolution S2-172862 LS in  
8.3.18Other
 		Yes
Yes
 		replied to No    
S3‑171041 LS on Use of the long-term identities for Charging in the VPLMN for 5G S5-171890 LS in  
8.3.18Other
 		Yes
Yes
 		noted No    
S3‑171042 Reply LS on addition of KMS URI to configuration parameters S6-170412 LS in  
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		noted No    
S3‑171043 LS on mission critical communication interworking security issues S6-170463 LS in  
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		replied to No    
S3‑171044 Reply LS to NGMN V2X Task-Force SP-170278 LS in  
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		noted No    
S3‑171045 Report from emeeting DoNAS MCC report Approval
4.1 Approval of the report from SA3#86 and SA3 ad-hoc
 		No
No
 		withdrawn Yes    
S3‑171046 Section 5.6.4.2.2 - Resolution of Editor’s Notes InterDigital, Inc. pCR Approval
8.3.6Authorization
 		Yes
Yes
 		left for email approval No    
S3‑171047 Section 5.6.4.3.2 - Resolution of Editor’s Notes. InterDigital, Inc. pCR Approval
8.3.6Authorization
 		Yes
Yes
 		left for email approval No    
S3‑171048 Section 5.6.3.3.1, Key Issue Details InterDigital, Inc. pCR Approval
8.3.6Authorization
 		Yes
Yes
 		left for email approval No    
S3‑171049 TCG progress report InterDigital, Inc. report Information
6.7TCG
 		Yes
Yes
 		noted No    
S3‑171050 Support of 256-bit Keys and Algorithms in 5G AT&T, InterDigital, MITRE discussion Decision
6.3ETSI SAGE
 		Yes
YesDocomo: it makes sense when we want to increase the security of the overall system. The kind of attacks with quantum computers require a large number of resources. This large number of resources could attack anything really. Does this justify the investment for the overall security of the system? AT&T found this justified. Gemalto supported the creation of a WID/SID to have longer keys for the algorithms. Docomo commented that there is more than extending the radio interface to 256 bits. All authentication solutions would need to be reevaluated. There's a lot of additional work. Vodafone: how does this interact with the SAGE work? Interdigital,, Gemalto supported AT&T's proposal for the work item. BT would support depending on the scope. The Chair commented that there are more questions to be answered before starting the work. Starting now would impact the work on the phae one of 5G. Qualcomm: we made a decision to use 128bits for the phase one. This can wait for phase 2. Gemalto: do we need to tell SAGE that we won’t include QSC in phase one? AT&T: I'm ok with not using 256bits in phase one, but SAGE should start the work soon so we have an answer when SA3 tackles this issue. Interdigital: we should tell SAGE when to start. Nokia: we are happy with 128 bits in phase one (specified by mid 2018).We don’t need longer keys algorithms by mid 2018. we might need them after that.
 		noted No    
S3‑171051 Quantum Safe Cryptography and Security Choices for 5G TCG, InterDigital, AT&T, MITRE discussion Presentation
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: specificying this would be fast but to have it in the UE may take long. Whatever we encrypt today, does it have to be like this in 20 years?Does it still matter? That's the question to answer.Qualcomm agreed; a threat analysis would be needed to know what we would gain with longer keys. NCSC: the current keys are considered until 2050. Nothing regarding 128 bits.
 		noted No    
S3‑171052 EPS Authentication with hiding keys assisted by UE - EPS AKA+ ZTE, China Unicom pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No   S3‑170608
S3‑171053 Update of solution 8.5 ZTE pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No   S3‑170609
S3‑171054 Key hierarchy when using UP security function ZTE, China Unicom pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No   S3‑170697
S3‑171055 Hiding keys exchanged between serving network nodes ZTE pCR Approval
8.3.3Security context and key management
 		Yes
Yes
 		left for email approval No   S3‑170611
S3‑171056 Remove EN of security requirements of user plane traffic differentiation ZTE, China Unicom pCR Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
YesEricsson: if we intercept packets we have to describe the presence of a node being simulated, and that doesn't appear here. It was finally approved.
 		approved No    
S3‑171057 Miscellaneous changes to Chapter 6.6 of TS 33.185 CATR pCR  
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
YesNokia and Qualcomm considered that the privacy enhancements should be left open for discussion. Huawei clarified that the "randomize" statement was coming from SA2. Deutsche Telekom disagreed, they were not in favout of having this. Nokia: this is not related to security, let CT take charge of this. ORANGE: V2X application is not specified in 3GPP. Ericsson commented that the tracking issue needed to be considered at the application layer, this was discussed before. Everything was agreed except the statement on privacy enhancements that had to be taken offline. The privacy statement was covered by the note in tdoc 319
 		revised No S3‑171472  
S3‑171058 LS on Use of the long-term identities for Charging in the VPLMN for 5G S3i170148 LS in  
8.3.18Other
 		Yes
Yes
 		noted No    
S3‑171059 Reference to list of 3GPP vendor specific EAP methods Ericsson CR Agreement
7.6.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑171526  
S3‑171060 Alignment of 3GPP-vendor specific EAP method names with TS 24.302 Ericsson CR Agreement
7.6.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑171527  
S3‑171061 LS on LI requirements for CIOT services including BEST services S3i170163 LS in  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
YesORANGE: Why the HPLMN needs to have LI capabilities? Home Office: it doesn’t matter if you are roaming or not.
 		replied to No    
S3‑171062 Reply LS on Middlebox Security Protocol S3i170166 LS in  
6.9TC-CYBER
 		Yes
YesBT: keep the commercial network side and the LI side separate, they have different requirements.
 		noted No    
S3‑171063 LS on IMSI availability in the VPLMN S3i170167 LS in  
8.3.18Other
 		Yes
YesVodafone: Multiple subscriptions with different IMSIs has never been discussed in 5G. Deutsche Telekom: if this hasn't been addressed in SA1 or SA2, let's not worry about it. Nokia: we assume that the UE hasn't been tampered with and the mechanism is to stop the home network relying from the visited network in the three approaches. Home Office: in SA3-Li we are happy without multiple subscriptions if this is the assumption. T-Mobile: Solution one is preferred.
 		replied to No    
S3‑171064 TR 33.885 EN Cleanup Sec 3.1 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171065 TR 33.885 EN Cleanup Sec 4 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171066 TR 33.885 EN Cleanup Sec 5 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171067 TR 33.885 EN Cleanup Sec 5.3 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171068 TR 33.885 EN Cleanup Sec 5.5 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
YesNokia suggested a rewording of the note. Vodafone: it is strange that the TR has different solutions depending on the region. The text should say that some countries have strong requirements some have not.
 		revised No S3‑171476  
S3‑171069 TR 33.885 EN Cleanup Sec 5.7 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		merged No S3‑171476  
S3‑171070 TR 33.885 EN Cleanup Sec 5.8 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
YesChange from "requirements" to "potential requirements".
 		approved No    
S3‑171071 TR 33.885 EN Cleanup Sec 5.9 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
YesVodafone had issues with the sentence above the note. Huawei: we assume that the V2X service is the LTE service. Authentication of V2X enabled UE is ambiguous. Vodafone: there are many inaccurate issues here, we shouldn’t send the TR for approval. What’s the purpose if the TR is not accurate enough? The Chair commented that we can send the TR for approval and stop the work anyway. Alf (Docomo): are we going to use this TR for further work? We have the TS already. Marcus (Huawei): bad idea to withdraw the TR.
 		revised No S3‑171477  
S3‑171072 TR 33.885 EN Cleanup Sec 5.11 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171073 TR 33.885 EN Cleanup Sec 5.16 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		merged No S3‑171478  
S3‑171074 TR 33.885 EN Cleanup Sec 6 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171075 TR 33.885 EN Cleanup Sec 6.1.1 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171076 TR 33.885 EN Cleanup Sec 6.3 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171077 TR 33.885 EN Cleanup Sec 6.5 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171078 TR 33.885 EN Cleanup Sec 6.6 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		revised No S3‑171479  
S3‑171079 TR 33.885 EN Cleanup Sec 6.8 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171080 TR 33.885 EN Cleanup Sec 6.9 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171081 TR 33.885 EN Cleanup Sec 6.12.2 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171082 TR 33.885 EN Cleanup Sec 6.13 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171083 TR 33.885 EN Cleanup Sec 6.14.2 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171084 TR 33.885 EN Cleanup Sec 6.15 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171085 TR 33.885 EN Cleanup Sec Annex D Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
YesMCC commented that the link should be added to the references clause of the document.
 		revised No S3‑171481  
S3‑171086 TR 33.885 EN Cleanup Sec Sec Annex X Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171087 Misc Changes to TS 33.185 Sec 6.5 Huawei, HiSilicon pCR Decision
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		revised No S3‑171468  
S3‑171088 Abbreviations in TS 185 Huawei, HiSilicon pCR Decision
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171089 Liaison Statement on 5G Identity and Access Management GSMA LS in  
8.3.18Other
 		Yes
YesBT: their concern here is the identities in IoT.We would duplicate work that is being done. Vodafone: we will get requirements from SA1, not from here.
 		noted No    
S3‑171090 report from 3GPPSA3-Emeeting on DoNAS(NB-IOT) VODAFONE Group Plc report Information
7.6.14Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑171091 Report of 3GPPSA3-Emeeting on DoNAS(NB-IOT) VODAFONE Group Plc report Approval
4.1 Approval of the report from SA3#86 and SA3 ad-hoc
 		Yes
YesOfficial report of the emeeting on DoNAS, prepared by Vodafone.
 		revised No S3‑171447  
S3‑171092 draft TSxx.xxx BEST TS v0.0.1 (status following SA3#86bis) VODAFONE Group Plc other Information
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		noted No    
S3‑171093 pCR to BEST TS xx.xxx v 0.0.1 - changes agreed at BEST adhocs since Busan VODAFONE Group Plc other Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No    
S3‑171094 draft TSxx.xxx BEST v0.0.2 - BEST TS including S3-171093 as agreed in conf calls VODAFONE Group Plc other Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		revised No S3‑171538  
S3‑171095 pCR to BEST TS xx.xxx v0.0.2 - Addition of error codes VODAFONE Group Plc other Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		No
No
 		withdrawn Yes    
S3‑171096 New WID on Study on Long Term Key Update Procedures VODAFONE Group Plc WID new Agreement
8.6.5Other study items
 		Yes
YesBT: a lot of work will be done somewhere else.We will support the SID. TIM: the attacker will be able to find the new key after being compromised with the first one. What's the point? Vodafone: it's a way of better protecting yourself. Intel: remote SIM provisioning would be a solution for this? Vodafone: remote SIM provision is heavy and costly. It is not the only solution. Telia Sonera: it seems that you are ignoring the GSMA work. Vodafone: GSMA work may find different solutions that fit different use cases from us. Deutsche Telekom supported this SID. Vodafone commented that they have some potential solutions in mind and some examples can be found in TR 33.899. KPN supported this SID. Ericsson: is this related to 5G? Vodafone: it's applicable to 5G, but potentially to LTE, UMTS and so on. ORANGE: remove everything solution specific from the justification. We don’t need to say that we need something between the UE and the HSS, or that we will have a potential standard for that. This is coming from a solution in the TR 33.899 from 5G. China Mobile supported this SID. Gemalto: impacts of the algorithms.BT supported this. ORANGE: out of scope of 3GPP, it doesn't have to be part of the objectives. G&D: support of no algorithms in here. Other supporters were added (e.g. 360.) ORANGE: why changing the identifiers? We need a justification for this. Vodafone: it's part of the study.It's not a study about changing profiles between operators.ORANGE commented that they wanted this into the justification. G&D: identifiers can still be an output of the study, we can remove this statement to avoid confusion.
 		revised No S3‑171448  
S3‑171097 pCR to TR33.899 - corrections to solution 7.2 VODAFONE Group Plc pCR Agreement
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171098 pCR to align interim agreement on KI#1.3 and KI#1.4 KPN pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No    
S3‑171099 pCR to 33.899 to extend solution #7.7 on revealing long-term identity KPN pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171100 Updating solution #7.14 “Privacy protection of permanent or long-term subscription identifier using ABE” TELECOM ITALIA S.p.A. pCR Approval
8.3.7Subscription privacy
 		Yes
YesNokia: why deleting the first editor's note? It's still valid. Telecom Italia: One publick key is easier to trust than multiple keys. It is a question of simplicity. There are a lot of certification authorities, certificates and so on. This was agreed by Nokia. Vodafone: the issue is the management of the master key. What happens if it is compromised, how fast we can change it?That's our concern.
 		approved No    
S3‑171101 Evaluations and conclusions in clause 7 TELECOM ITALIA S.p.A. pCR Approval
8.3.7Subscription privacy
 		Yes
Yesmerged in 508 for evaluation and 509 for the conclusions.
 		merged No S3‑171508  
S3‑171102 Update of key issues of security area #11 Security visibility and configurability LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		left for email approval No    
S3‑171103 Update of solution #11.2 Security visibility solution LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		left for email approval No    
S3‑171104 Update of solution #11.3 Security configurability solution LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		left for email approval No    
S3‑171105 Update of solution #11.4 UE trigger of key and ID refresh LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		left for email approval No    
S3‑171106 Procedure for UE security indication and configuration LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		left for email approval No    
S3‑171107 Conclusion for Security area #11: Security visibility and configurability LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		left for email approval No    
S3‑171108 Questions and agreement for Security area #11: Security visibility and configurability LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		merged No S3‑171557  
S3‑171109 Clarification of ID change for V2X PC5 LG Electronics pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171110 Update of V2X UE privacy solution with LI support LG Electronics pCR Approval
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171111 New SID on security aspects of 3GPP support of advanced V2X services LG Electronics SID new Approval
8.6.5Other study items
 		Yes
Yes
 		noted No    
S3‑171112 Updated SID on architecture enhancements for 3GPP support of advanced V2X services LG Electronics SID new Approval
8.6.5Other study items
 		Yes
YesThe Chair commented that SA3 should do their own SID document and not integrate it wit the SA2 WID. BT commented that the low latency issue hasn't been dealt with and it is not included in the objectives. Huawei: this is way too early for us. I don’t believe that there is anything to look for us at this early stage. Qualcomm supported but better to wait for a couple of meetings until SA3 gets more material from SA2. ORANGE agreed. The number of companies agreeing to delaying were the same as the number of companies who wanted to start. The Chair commented that LG could bring the SID with contributions to have the work started if the progress in SA2 allowed to do that. The SID was noted.
 		noted No    
S3‑171113 [FS_MC_SEC] MCData Payload security NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
YesAirbus: no mechanisms for OTA distribution? NCSC: not defined yet, this is done for alignment.
 		approved No    
S3‑171114 [FS_MC_SEC] MCData Key Management NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		revised No S3‑171454  
S3‑171115 [FS_MC_SEC] MCData Key Distribution NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		revised No S3‑171455  
S3‑171116 [MCSEC] Protection of full XML document NCSC pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171117 Reply LS on update to key management for application signalling NCSC LS out Approval
5Items for early consideration
 		Yes
YesEricsson: On point 3, rhere are backward compatibility issues with Rel-13 and we are not addressing CT1 concerns.
 		revised No S3‑171451  
S3‑171118 [MCSEC] Adding MSCCK functionality for back-compatibility NCSC pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
YesEricsson: how do you decide between the two procedures, MSCCK and MuSiK? NCSC: it's configured in the server.
 		revised No S3‑171457  
S3‑171119 [MCSEC] Discussion doc on update to MCPTT Multicast signalling NCSC discussion Discussion
5Items for early consideration
 		Yes
Yes
 		noted No    
S3‑171120 [FS_MC_SEC] Evaluation of Application Signalling Protection (Sol #1.4) NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171121 [FS_MC_SEC] Adding MSCCK functionality for back-compatibility into evaluation clause NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		revised No S3‑171452  
S3‑171122 [FS_MC_SEC] MCData Evaluation NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171123 [MCSEC] Update to MCData security NCSC pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
YesAirbus wanted to add a note on the open issues of authenticated payload.This wasn't agreed.
 		revised No S3‑171459  
S3‑171124 [MCSEC] Addition of descriptive clauses NCSC pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		No
No
 		withdrawn Yes    
S3‑171125 Interim Agreements: How to implement increased home control in EPS AKA* Ericsson pCR Approval
8.3.2Authentication
 		Yes
YesEricsson: This shows that the solution from Nokia in 373 is not valid. Nokia: in this case remove Note 1. Docomo:How does the UE know when to do what? Nokia: When it does the 5G authentication. NAS protocol between the UE and the 5G core must be different from the 4G core so the UE knows it's in the 5G network. It was suggested to add an editor's note on the need of deciding between the solution in 376 and 314.
 		revised No S3‑171500  
S3‑171126 Annex on the additional EAP methods Ericsson, Samsung, Qualcomm Incorporated, Nokia, Intel, Huawei pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesIt was argued the use of "can"; MCC commented that in this context it was better to use "can" instead of "may". Revised to address other comments.
 		revised No S3‑171506  
S3‑171127 Adding references to GIA4, GEA5/GIA5 and stage 3 GMM specifications, and removing corresponding editor's notes. Ericsson CR Approval
7.6.13Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)
 		Yes
Yes
 		revised No S3‑171534  
S3‑171128 Adding references to GIA4, GEA5/GIA5 and stage 3 GMM specifications, and removing corresponding editor's notes. Ericsson CR Approval
7.6.13Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)
 		Yes
Yes
 		revised No S3‑171535  
S3‑171129 reply LS on LTE call redirection to GERAN Ericsson LS out Approval
7.6.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑171554  
S3‑171130 Update of Key issue #4.2 Security requirements on gNB Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171131 Questions and agreements on key issue #4.2 Security requirements on the gNB Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		noted No    
S3‑171132 pCR to 33.501: requirements on gNB Ericsson pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesInterdigital wondered why the interface is IP-based only in 5.2.5. Ericsson: this is in line with the split architecture that is being discussed in RAN.We agree with removing it if needed. Telia Sonera recommended to have a note on the general clause. Qualcomm: why remove 5.3.2? These requirements also apply to gNodeB. It was commented that SCAS requirements for eNodeB could also apply here. Deutsche Telekom: eNodeB SCAS is not ready yet,a bit premature to refer to it now.
 		revised No S3‑171493  
S3‑171133 Questions for Key issue #7.2: Storage and configuration of key related to encryption of permanent identifiers Ericsson pCR Approval
8.3.7Subscription privacy
 		Yes
YesORANGE: we are not trying to specify 3GPP specific methods for the question "By which methods shall it be allowed to configure the keys related to concealing the permanent subscription identifier?". This was asked to be in the minutes. Suggested a third question: If mulitple entities are allowed which is their priority?This was agreed.
 		revised No S3‑171549  
S3‑171134 Security aspects of xMB reference point Ericsson, Qualcomm CR Agreement
5Items for early consideration
 		Yes
YesNokia pointed out that the LS states that there is further cosnideration needed but that we are replying with an answer already.
 		agreed No    
S3‑171135 Alignment of LWIP to stage 3 Ericsson CR Approval
7.6.1SAE/LTE Security
 		Yes
YesBT: XW interface is missing from the figure H.1-1. Figure not changed in the CR, to be fixed.
 		revised No S3‑171555  
S3‑171136 KI#7.2_question_agreement_imsi_priv_privay_in_phase1 Ericsson, Nokia, Vodafone, Intel, KPN, LGE, China Mobile, CATT, NEC, Juniper Networks, T-Mobile, Telenor, Deutsche Telekom, Morpho, IPCom, Telecom Italia pCR Approval
8.3.7Subscription privacy
 		Yes
YesHuawei queried about the emergency calls. Vodafone: Protected identity will impact emergency calls? This is an open issue. BT: Non-3GPP accesses are in scope? E.g. using MAC addresses. Vodafone: it’s still the IMSI for these kind of accesses. BT: in WLAN there is a solution proposed by Apple, for example. Interdigital: what are we trying to protect here? The IMSI? Nokia: Subscription permanent identifier is what we try to protect here. Huawei: it's allowed without subscriptions. Vodafone: most countries forbid this, without subscription. ORANGE: format of the subscription identifier is not defined in SA3. Interdigital: in the TR we have a subscription identifier definition. It's not clear what we want to protect here. ORANGE: the definition is for us alone, not for the overall 3GPP. SA2 is working on the subsucription identifier. Ericsson: is the complete identifier protected? That's an issue as well. On the emergency call part, Vodafone preferred "long term" over "permanent subscription identifier".Nokia replied that that would be a different key issue. A note was added for this.
 		revised No S3‑171511  
S3‑171137 KI#7.2_quesions_imsi_priv_solution_types Ericsson, Nokia, Vodafone, Intel, KPN, LGE, China Mobile, CATT, NEC, Juniper Networks, TeliaSonera, Deutsche Telekom, T-Mobile, Morpho, IPCom, Telecom Italia pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		approved No    
S3‑171138 KI#7.2_agreements_imsi_priv_solution_types Ericsson, Nokia, Vodafone, Intel, LGE, China Mobile, CATT, NEC, Juniper Networks, Deutsche Telekom, T-Mobile, Morpho, IPCom pCR Approval
8.3.7Subscription privacy
 		Yes
YesVodafone: wording is not correct ("significant hassles, last resort"). Second and third bullets were decided to be removed. AT&T: according to SA plenary, there is a phase going to an existing EPC core whereas a "1.5" phase it goes to the 5G core. The Chair confirmed that the understanding of "phase one" for SA3 is the one with 5G core. Interidigital: hard to answer the question when we don’t know what to protect. ORANGE: there are no contributions that address this issue. Qualcomm wanted to have HN pseudonym as possible solution in E72A2. ORANGE agreed with the answer no for that question. This was conceded by Qualcomm. Huawei disagreed with E72C2, but as it was the same discussion as the show of hands, the group procceeded with the "no". For E72D2, Huawei also disagreed. They proposed to have options for the privacy solution but ORANGE rejected this categorically. It was decided to agree with this one as well. AT&T: PKI management; there automated procedures for millions of them. There's no such complexity of PKIs.
 		revised No S3‑171513  
S3‑171139 KI#7.1_KI#7.4_questions_agreements_GUTI Ericsson, Intel pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		merged No S3‑171550  
S3‑171140 KI#7.3_KI#7.5_KI#7.7_KI#7.8_KI#7.9_questions_agreements Ericsson, Intel pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171141 Conclusion_bidding_down_aspects_privacy_(was_S3-170879) Ericsson, Nokia, Vodafone pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		merged No S3‑171509  
S3‑171142 Evaluations_two_pseudonym_solutions_(was_S3-170746) Ericsson pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171143 Update_solution_#7.15_addressing_LI_aspects_(was_S3-170896) Ericsson pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171144 Update_KI_#7.9_privacy_aspects_of_MCC_MNC_(was_S3-170748) Ericsson pCR Approval
8.3.7Subscription privacy
 		Yes
YesVodafone: it doesn't addess the case of miultiple subscriptions for the same user.
 		noted No    
S3‑171145 Key issue update, questions and agreements for key handling in state transition from RRC_INACTIVE state to RRC_CONNECTED state Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		revised No S3‑171573  
S3‑171146 Update of KI #4.4 and questions and agreements on KI #4.4 Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		revised No S3‑171571  
S3‑171147 EN-DC in option 3a/3x Ericsson pCR Approval
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesQualcomm disagreed. Ericsson pointed out that solution one was what was given to SA3 and that needed to be the working assumption. Qualcomm: the solution is not being imposed according to the LS from RAN. It's a preference. Huawei supported the Ericsson proposal. Nokia commented that both CT1 and RAN2 feedbacks were slightly different from each other and from there SA3 should study which one to use. Qualcomm: ask CT1 in a LS if they have any issues with SA3 using variant one and wait for the next meeting.
 		revised No S3‑171486  
S3‑171148 Some comments on proposed text for supporting Option 3 Ericsson pCR Approval
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesSome of its content will go into 487
 		merged No S3‑171487  
S3‑171149 Security solution for key handling in state transition from RRC inactive state to RRC connected state Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171150 Security solution on mobility in RRC_INACTIVE state Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171151 Clarifications on solution #4.10 (detection type solution) Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171152 Minor clarification on KI #4.14 regarding constant RAN level identifiers Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171153 Questions and interim agreements for KI #4.5, KI #4.6, KI #4.9, KI #4.12, KI #4.15, KI #4.16, KI #4.17 Ericsson pCR Approval
8.3.4RAN security
 		Yes
YesQualcomm: E4.17, do we need this level of detail in the questions? Huawei liked the questions as they were.It was agreed to leave it as it was.
 		revised No S3‑171569  
S3‑171154 Questions and interim agreements for KI #8.3 CATT pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171155 Evaluation for Network Slicing Security Solution #8.7 CATT pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171156 Network Slicing Security Architecture and General Procedure CATT pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171157 Question for NG2 handover China Mobile, Huawei pCR Approval
8.3.4RAN security
 		Yes
YesOverlaps with 1153. It was agreed to merge the question with E.4.9 in 1153.
 		merged No S3‑171569  
S3‑171158 Questions for security of Xn handover China Mobile pCR Approval
8.3.4RAN security
 		Yes
Yes
 		merged No S3‑171569  
S3‑171159 Questions for Security algorithm negotiation between UE and RAN China Mobile pCR Approval
8.3.4RAN security
 		Yes
YesOverlaps with 1153. Ericsson: it’s the same as our document so we can merge. Huawei didn’t agree that they were the same. Qualcomm: how to define the negotiation? Leave the Interim agreement TBD. It was decided to merge with 1153.
 		merged No S3‑171569  
S3‑171160 Conclusion and interim agreements for KI# 4.4 and KI #4.7 China Mobile pCR Approval
8.3.4RAN security
 		Yes
YesThe first part overlaps with 1146. Huawei supported the Interim agreement in E.4.7..Both were agreed.
 		revised No S3‑171572  
S3‑171161 Update of Key Issue #4.7 China Mobile pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171162 pCR to adding new key issue: User location confidentiality China Mobile pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171163 pCR remove the editor’s note in solution #7.10 China Mobile pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171164 pCR update the solution #7.10 China Mobile pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171165 Questions related to concealing permanent subscription identifier in key issue #7.1 China Mobile pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171166 Questions related to Termination of EAP method in key issue #2.1 China Mobile pCR Approval
8.3.2Authentication
 		Yes
YesQualcomm: we have this already in the TS.
 		noted No    
S3‑171167 Questions related to the Usability of legacy USIM in key issue #2.1 China Mobile pCR Approval
8.3.2Authentication
 		No
Yes
 		revised No S3‑171351  
S3‑171168 Questions and agreement for KI #8.2 China Mobile pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171169 Questions and agreement for KI #8.3 China Mobile pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171170 Discussion and pCR for V2X privacy China Mobile pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
YesORANGE: the first requirement looks like a legal requirement on the network. We don’t use the term pseudonomity in 33.401. Vodafone: we have agreed on confidentiality being the same as in LTE. I don’t see why we need this clause at all.It's saying "for the Uu interface we need to use the LTE specs". LG: this is a different case. This document overlapped with tdoc 319 and was merged with it.
 		merged No S3‑171473  
S3‑171171 Resolving non-technical editor’s notes China Mobile pCR Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		approved No    
S3‑171172 Resolving technical editor’s notes and adding sections to align with TS33.117 China Mobile pCR Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		approved No    
S3‑171173 Discussion for User-to-User DDoS Attack Prevention China Mobile discussion Endorsement
8.6.5Other study items
 		Yes
YesDocomo: have you seen this happening to the network? Do you think that standards can define interfaces to fix this? China Mobile confirmed that they have seen this happening. They don’t propose any solutions but they would like to address this. ORANGE: are you proposing a DoS from the user to the network? China Mobile: the attack comes from software, not the UE. ORANGE: do you foresee something that needs to be done in 3GPP? Does GSMA know this problem?It's more appropiate to raise this issue in there.
 		noted No    
S3‑171174 Questions and Interim Agreements on Security for Handover within 5GS NEC EUROPE LTD pCR Approval
8.3.1Security architecture
 		Yes
YesNokia: we don’t need a question for this. Ericsson doubted whether the first question was needed. Handover will be studied but this contribution depends on other contributions that need to be agreed as well. They depend on the strcuture of the TR. Qualcomm: why do we need this question for the study?Of course we need to study it in phase one,it's obvious.
 		noted No    
S3‑171175 Key Issue on Handover within 5G Systems NEC EUROPE LTD pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171176 Update of Solution #1.31 NEC EUROPE LTD pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171177 Update of Solution #1.32 NEC EUROPE LTD pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171178 Inter NG RAN Handover with Xn interface NEC EUROPE LTD pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171179 Intra AMF, Intra SMF, Inter NG RAN handover without Xn interface NEC EUROPE LTD pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171180 Intra AMF, Inter SMF, Inter NG RAN handover without Xn interface NEC EUROPE LTD pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171181 Inter AMF, Intra SMF, Inter NG RAN handover without Xn interface NEC EUROPE LTD pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171182 Inter AMF, Inter SMF, Inter NG RAN handover without Xn interface NEC EUROPE LTD pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171183 Intra NG RAN Handover NEC EUROPE LTD pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEricsson: it's too early to include this content. We would have to include all the details: names, keys, etc.. We propose to postpone for next meeting. Nokia agreed with Ericsson. Alignment with RAN2 and RAN3 is needed as well. Docomo agreed with this. Ericsson: I'm not sure we have an agreed solution. NEC: no key issue with the handover. This was agreed in the TR. We can add this and update it later. Ericsson: the question is update it to what. It was agreed to work with this offline and come back for the next meeting.
 		noted No    
S3‑171184 Update of solution #4.6 on security mechanism for deployment scenario of option 3 NEC EUROPE LTD pCR Approval
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesNEC wanted to send this info in the LS, but it was finally agreed not to do it.
 		approved No    
S3‑171185 EN-DC (E-UTRAN – New Radio) Dual Connectivity NEC EUROPE LTD CR  
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesDiscussed with the related document 324. Parts of this CR were merged with the Qualcomm proposal in 324.
 		not pursued No    
S3‑171186 Solution for forward and backward security of Xn handover Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171187 Solution2.12 handling Privacy and Meeting LI Requirements in all Scenarios Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171188 Conclusion and interim agreements for KI # 4.11 & 4.15 Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
YesIt overlaps with 1153. Ericsson: too early for E4.15.
 		revised No S3‑171570  
S3‑171189 MASA Response to Evaluation# 2. Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171190 Solution for IMSI Privacy while meeting LI Requirements Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
YesNokia: evaluation for 2.12 should be taken into account. A note was added to address this. Nokia: as a general statement, we are not in favour of this kind of solution.
 		revised No S3‑171510  
S3‑171191 MASA handling OUT of Sequence Scenario Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171192 MASA Modular Approach Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171193 MASA Update Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171194 MASA crypto analysis conclusion Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171195 Interim Agreement Analysis and Impact of Primary Authentication Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171196 Interim Agreement Proposal for IMSI privacy Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		revised No S3‑171544  
S3‑171197 Interim Agreement for 5G NR Primary Authentication Alternative Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171198 EPS-AKAi: A primary authentication solution for 5G NR access Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171199 Resolving Editors Notes in Security requirements on gNB Potential security requirements V3 Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171200 backward security for RRC inactive state to RRC active state Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171201 Anti-DDOS for RRC inactive state to RRC active state Huawei, Hisilicon, China Mobile pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171202 Generate Temporary or short-term subscription identifiers by Random Number Generator Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171203 Interim Agreement for Using effective temporary or short-term subscription identifiers Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		postponed No    
S3‑171204 MASA support 4G USIM and clarification. Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171205 Questions and interim agreement for NG2 handover procedure Huawei, Hisilicon, China Mobile pCR Approval
8.3.4RAN security
 		Yes
No
 		withdrawn Yes    
S3‑171206 Update solution 2.11 for KI 1.21 interim agreement Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171207 Interim Agreement for KI#1.21 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesORANGE: Anti-DoS atack? Huawei: solutions in phase one for DoS attack to the core network. ORANGE proposed some rewording: should antiDoS attack protection be addressed? Huawei agreed. Qualcomm: UP or CP attacks? KPN: we have a key issue referring to the signalling. Ericsson: already discussed but not agreed. Not appropiate to have a mechanism to detect bad behaving User Equipments. Juniper Networks: DoS attacks is a huge topic. We need to narrow it down. KPN: we have tdoc 386 with a more detailed approach on DoS attacks.
 		merged No S3‑171564  
S3‑171208 IMSI privacy solutions evaluation & Discussion Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
YesDeutsche Telekom:LI requirements need to be Yes, as we have seen in their LS during this meeting. Huawei agreed, as an outcome of this meeting it will be updated. Nokia: "it increases the number of times" we don’t know how many times MCC+MNC is sent. Vodafone: it isn't clear how to integrate this document into the TR. Huawei: evaluation parts can be merged into the evaluation. The Chair replied that the best option give the lack of time would be to add an additional section for this document. Ericsson wasn't happy with the table and with the overall document. They commented that in some parts it seems that they are promoting their own solutions. Due to these and other concerns the document was noted.
 		noted No    
S3‑171209 Security threats of key issue #3.3 “Principles of security negotiation” Huawei, Hisilicon pCR Approval
8.3.3Security context and key management
 		Yes
Yes
 		left for email approval No    
S3‑171210 solution for UP security negotiationV3 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171211 Interim agreement for UP integrity Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesVodafone: it's not clear where the application resides. TIM commented that the group should try to make fundamental questions instead of making 1000 questions. Vodafone: I said that before, we should go and put content in the TS instead. Nokia: we don’t need in phase one, it should be left to the operator. Ericsson pointed out that it overlapped with 279.
 		noted No    
S3‑171212 update interim agreement on reducing the impact of secert key lekage Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171213 agreement on support ERP Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
YesNokia: we don’t need this in 5G. Qualcomm and Ericsson commented that the answer should be "no in phase one". This was agreed.
 		revised No S3‑171567  
S3‑171214 Update the skeleton to support security on service based architecture Huawei, Hisilicon pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171215 Interim agreement for support security on service based architecture in 5G phase 1 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesORANGE: what is a service based architecture? Huawei: covered in SA2, it should be studied. ORANGE: I prefer to have a contribution where it is explained how the security is impacted. Vodafone: which requirements and key issues is this question related to? Huawei: we will update with the key issue associated. Ericsson: we need to address it if it is in the SA2 TS. Vodafone: this refers to something that doesn’t belong to phase one,as we defined in a table in December. Huawei replied that this is not in that table. China Mobile: we need to answer whether we need security for the service architecture.
 		noted No    
S3‑171216 Security capability handling for EN-DC Huawei, Hisilicon discussion Discussion
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesEricsson didn’t understand how to handle proposal 3 according to Qualcomm's proposal in 338. It was agreed to send an LS to both RAN2 and CT1 to state that no decision has been made on the three options and that will be done in the next meeting. Huawei reminded that the majority of companies in CT1 didn’t like option one.
 		noted No    
S3‑171217 AS algorithms selection Huawei, Hisilicon pCR Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
YesEricsson: there is no format of evidence. Huawei suggested to remove the term "simulated eNodeB". This was agreed.
 		revised No S3‑171519  
S3‑171218 Verify RRC integrity protection Huawei, Hisilicon pCR Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		revised No S3‑171520  
S3‑171219 Verify the feature of EIA0 Huawei, Hisilicon pCR Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		revised No S3‑171521  
S3‑171220 Verify key refresh at eNB Huawei, Hisilicon pCR Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		revised No S3‑171522  
S3‑171221 The skeleton of TR 33843 Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesMCC pointed out that the template was wrong. ORANGE asked what this had to do with REAR, but it was pointed out that it was in the approved study.
 		revised No S3‑171575  
S3‑171222 The reference of TR 33843 Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171223 The scope of TR 33843 Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑171577  
S3‑171224 key issue authentication and authorization Huawei, Hisilicon, China Mobile pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑171578  
S3‑171225 key issue security on service continuity Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171226 key issue security on discovery Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesORANGE: alignment with 33.303 in an editor's note. MCC: avoid mentioning Releases, reference other specifications.
 		revised No S3‑171581  
S3‑171227 key issue security of UP between eRemote UE and network Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑171582  
S3‑171228 key issue security of CP between eRemote UE and network Huawei, Hisilicon, China Mobile pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171229 discussion-authentication and authorization of eRemote UE Huawei, Hisilicon discussion Discussion
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑171230 a solution of key isolation in inter-AMF mobility Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171231 add evaluation of solution #2.29 Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171232 interim agreement for KI#1.7 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		merged No S3‑171556  
S3‑171233 interim agreement for KI#2.4 Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171234 interim agreement for KI#2.8 Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171235 interim agreement for KI#7.1 Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
YesORANGE didn’t agree with the UE being able to trigger a temp id refresh procedure.
 		merged No S3‑171550  
S3‑171236 interim agreement for KI#7.4 Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		postponed No    
S3‑171237 interim agreement for KI#11.1 and #11.2 Huawei, Hisilicon pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		left for email approval No    
S3‑171238 interim agreement for KI#11.3 Huawei, Hisilicon pCR Approval
8.3.11Security visibility and configurability
 		Yes
Yes
 		left for email approval No    
S3‑171239 Clarification for KDF negotiation Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171240 Clarification for solution #1.13 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171241 A security solution for SMS over NAS Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171242 Interim Agreement for KI1.18 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		revised No S3‑171563  
S3‑171243 Interim Agreement for KI1.5 on integrity for uplink NAS signalling Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171244 Interim Agreement for KI1.5 and KI1 6 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171245 Enhanced NAS token solution for LTE redirection attack Huawei, Hisilicon CR Agreement
7.6.1SAE/LTE Security
 		Yes
YesNokia: Enhancement of the proposal of including a NAS token.I see some problems in the communication between MME and UE. MCC note: this document was reserved as CR but it contains a discussion paper. It was decided to note it since conference calls will deal with this issue before the next meeting.
 		not pursued No    
S3‑171246 Solution for key Handling in RRC Inactive state to RRC active state transition Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No    
S3‑171247 5G security architecture discussion Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171248 Annex for 5G security architecture Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171249 Interim agreement for the key hierarchy Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		noted No    
S3‑171250 Interim agreement for the anchor key Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171251 Solution for key hierarchy in 5G phase1 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171252 Example Procedure for non-AKA EAP-based Authentication Method in 5G Huawei, Hisilicon pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesSome language should be corrected (e.g. use of "we"). Vodafone: this is not an interim agreement so we should not procceed with it. The Chair asked the authors to work on this document and bring an updated version for the next meeting.
 		noted No    
S3‑171253 Editor’s Note for Key Issue #4.4 Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
YesOverlaps with 146. China Mobile supported this.
 		left for email approval No    
S3‑171254 Questions and agreement for KI8.2 Huawei, Hisilicon pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171255 Questions and agreement for KI8.3 Huawei, Hisilicon pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171256 Interim Agreement for KI8.4 Huawei, Hisilicon pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171257 Interim Agreement for KI8.5 Huawei, Hisilicon pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171258 Interim Agreement for KI8.7 Huawei, Hisilicon pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171259 Use of legacy USIM and NextGen ME in solution #7.12 Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171260 Network slice life-cycle security update Huawei, Hisilicon pCR Approval
8.3.16 Management Security
Yes
Yes
 		left for email approval No    
S3‑171261 Soltuion for service based architecture Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171262 Question and interim agreement for co-location of the SCMF and the SEAF Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		revised No S3‑171415  
S3‑171263 Question and interim agreement for AUSF in visited network Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
No
 		withdrawn Yes    
S3‑171264 Deleting the EN in the section 4.2.6 of TS33.250 Huawei, Hisilicon pCR Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
YesEricsson: why removing the configuration? They didn't agree with the changes. Deutsche Telekom only agreed with removing the editor's note.
 		revised No S3‑171516  
S3‑171265 pCR to 33.899: Updates to Solution #7.2 Intel pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171266 pCR to 33.899: Updates to Key agreements to key issue #4.14 Intel pCR Approval
8.3.4RAN security
 		Yes
Yes
 		approved No    
S3‑171267 pCR to 33.899: Updates to Key Issue #7.1 Intel pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		revised No S3‑171546  
S3‑171268 pCR to TR 33.899: Securing and refreshing the temporary subscriber identifiers. Intel pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171269 Discussion for Securing and refreshing the temporary subscriber identifiers. Intel discussion Discussion
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171270 pCR to TR 33.899: Securing the permanent device identifiers. Intel pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171271 Changes to Security Key Update Intel, Qualcomm, Nokia CR Approval
7.6.1SAE/LTE Security
 		Yes
YesEricsson didn’t agree with the change from shall to may. Intel: discussed and agreed in the Sophia meeting. This is done to avoid additional overhead in the handshake. Samsung: agreed only in certain scenarios, not all of them.
 		revised No S3‑171547  
S3‑171272 Discussion for RAN2 LS regarding WT MAC address for uplink traffic Intel, Qualcomm, Nokia discussion Discussion
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑171273 Reply LS on on providing WT MAC address to the UE using eNB signalling Intel LS out Approval
7.6.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑171528  
S3‑171274 Discussion on security for multiple NAS connections (KI #1.7) Ericsson discussion Discussion
8.3.1Security architecture
 		Yes
Yes
 		noted No    
S3‑171275 New solution for the protection of multiple NAS connections (KI #1.7) Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171276 Trust model and key hierarchy discussion for Next Generation systems (KI #1.7) Ericsson pCR Discussion
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171277 New key hierarchy proposal for Next Generation systems (KI #1.7) Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171278 Discussion on the feasibility of the support and negotiation of a PDU Session specific-security features (KI #1.16) Ericsson pCR Discussion
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171279 Questions and interim agreements on the granularity of the UP protection (KI #1.16) Ericsson pCR Approval
8.3.1Security architecture
 		Yes
YesORANGE didn’t agree with having E1X22 in phase one. Ericsson agreed with delaying this in phase one but pointed out it was coming from the TR.
 		revised No S3‑171562  
S3‑171280 Solution for a PDU session-specific security negotiation (KI #1.16) Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171281 Discussion on network slice isolation (KI #8.1) Ericsson, Nokia pCR Discussion
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171282 Questions and interim agreements on Network Slice-sepcific keys (KI #8.1) Ericsson, Nokia pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171283 Update of solution #1.36 for SEAF realization via AMF (KI #1.2) Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171284 Resolution of the editor’s notes in solution #6.4 Ericsson pCR Approval
8.3.6Authorization
 		Yes
Yes
 		left for email approval No    
S3‑171285 Content for clause 7 on security procedures between 5G Network Functions Ericsson pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: wrongly deleted editor's note in 7.2 due to a misunderstanding. Ericsson understood and agreed. Deutsche Telekom: Note 1 in 7.1.1 should go away. Also, are we changing the SA acronym of AMF to avoid misunerstanding with our AMF? Nokia: we add a note everytime that this can be confusing. As per comments from BT the note was agreed to be reworded. ORANGE: in TS 33.210 implementation of IPSEC was optional. Is it the same case in 5G core network?Ericsson preferred to keep it optional to implement. Telia Sonera, China Mobile and Deutsche Telekom had the same thought. BT: we have a different concept of implementation. It's about turning it on or off. It was agreed in 7.1.1 to add an editor's note on the management plane as suggested by Deutsche Telekom. ORANGE: mandatory use of IPSEC is FFS. An editor's note was added to that effect. MCC reminded that a better standardization term for "mandatory to implement and optional to use" was "shall be supported".
 		revised No S3‑171502  
S3‑171286 Questions and agreements for key issue #1.7 on key hierarchy related to NAS security Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		revised No S3‑171558  
S3‑171287 Questions and interim agreement for key issue #1.7 on key hierarchy related to core network keys Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		revised No S3‑171556  
S3‑171288 Discussion on RAN deployment and interface protection Ericsson pCR Discussion
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDiscussed together with 285.
 		noted No    
S3‑171289 Questions and agreements for key issue #1.7 on key hierarchy related to the access network and air interface protection keys Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		revised No S3‑171559  
S3‑171290 Overall presentation of contributions proposing questions and interim agreements for key issue #1.7 on key hierarchy Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No    
S3‑171291 Security aspects of xMB reference point Ericsson, Qualcomm CR  
5Items for early consideration
 		No
No
 		withdrawn Yes    
S3‑171292 Alignment of LWIP to stage 3 Ericsson CR  
7.6.1SAE/LTE Security
 		No
No
 		withdrawn Yes    
S3‑171293 Discussion on resubmission of S3-170758-759-760-763-765-766-767 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171294 Key issues on identity probing - was 758-458 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171295 Solution - Research Paper - Using pools of IMSIs and indicate in RAND - was 759-452 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171296 Solution - Research Paper - Encrypted pseudonym transported in RAND - was 760-453 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171297 Question to concealment of identifiers OTA - was 763-455 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171298 Question to concealment of temporary identifiers - was 765-456 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesVodafone: define the frequencies at which the refresh occur. This should be included in the questions (standardise triggers for refresh). No agreement has been made for that.
 		revised No S3‑171550  
S3‑171299 Question to full protection of permanent identifier - was 766-203 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		revised No S3‑171512  
S3‑171300 Agreement to full protection of permanent identifier Nokia, Ericsson, Intel, Qualcomm, Morpho, KPN, TNO pCR Decision
8.3.7Subscription privacy
 		Yes
YesQualcomm: there may be other subscription identifiers rather than the IMSI, according to SA2. The Chair asked: shall the routing information be hidden at the air interface (question in 299)? Interidigital: preserving network policy should be optional (yes/maybe for the above question). The Chair proposed a show of hands: Show of hands per company for question in 299; who supports the response "no" (privacy protected)? Vodafone,KPN,ORANGE,Oberthur,Juniper,Intel,Ericsson,Nokia,LG,Deutsche Telekom, Docomo,IPCom,NEC,Qualcomm,UK government, US department of commerce, China Mobile. Same question, yes privacy protection: AT&T, TIM, Interdigital, BT,360,Huawei, Neul Limited Motorola Solutions abstained. The Chair commented that this could go to a technical vote for the next meeting if there was no agreement. AT&T proposed to go on with the "no" response so as not to waste time, Interdigital agreed. The Chair asked the group if it was OK to procceed with "no" as the response to 299. There was no opposition and the document was approved.
 		approved No    
S3‑171301 Question to slice identifier protection - was 767-204 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesORANGE: the key issue is not about correlation of the slice id and the subscription id. Qualcomm agreed. Nokia: the question is here because there was a discussion in the Busan adhoc and this is still an open issue. Vodafone: No difference with the situation of having two base statiion with two network ids. Vodafone: Why the extra protection of the NSSAI if we have privacy protection for the subscriber already? Interidigital: we don’t need it. It all was reduced to the question of the need of the extra protection for NSSAI. It was commented that the issue was more about confidentiality protection. Vodafone: It's purely about slicing, not the privacy. BT: you can identify the customer by the slice he's using, so Vodafone is wrong.
 		revised No S3‑171551  
S3‑171302 Agreement to slice identifier protection Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesQualcomm: it shall be supported (optional to use). Vodafone: we need for phase one a clear statement of what needs to be protected. T-Mobile: this means no confidentiality protection in phase one. ORANGE: not crutial for phase one. Vodafone: capability yes. Ericsson: not in phase one. BT: not on phase one. NEC: wait for SA2 procedures to finish this discussion. Nokia: they are waiting for us. Huawei: not for phase one. Docomo: not for the initial registration but for the subsequent use of the slice. ORANGE and NEC were fine with this. ORANGE: we need an answer for this meeting. ORANGE: we say no and we work more on this when discuss the solution. Ericsson agreed, but some companies disagreed. The Chair proposed as suggested by ORANGE: NSSAI shall be confidentiality protected whenever NAS confidentiality protection is enabled. This was agreed. Vodafone objected to the answer of this question being agreed in this meeting as many issues have been identified that need further thought before concluding on this interim agreement
 		revised No S3‑171552  
S3‑171303 Question on synchronization and recovery - was 764 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesDocomo: questions are too specific. Deutsche Telekom proposed to have a question on real identity, can an attacket force the UE to reveal the real identity? ORANGE supported it with some rewording (is it acceptable..?) KPN: the response would be NO. The rest of the questions were not generally supported so they were removed.
 		revised No S3‑171548  
S3‑171304 Solution on synchronisation and recovery Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171305 Solution variant to 7.3 based on encrypted IMSI only - was 757 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		revised No S3‑171553  
S3‑171306 Proposed answers to questions on synchronization and recovery Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesORANGE: no solutions for Over The Top for the 3GPP network.
 		noted No    
S3‑171307 Additional privacy related questions for security visibility and configurability - related to S3-170852 Nokia pCR Decision
8.3.11Security visibility and configurability
 		Yes
Yes
 		revised No S3‑171557  
S3‑171308 Solution on efficient handling of privacy protected AV requests by HSS-AUSF or SLF Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171309 V2X MB2 interface requirements Nokia pCR Decision
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171310 V2X privacy requirements Nokia pCR Decision
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
YesORANGE: what is the UE identity? Nokia: it's the IMSI. ORANGE: this is not defined anywhere. Is the IMSI distributed over the PC5 interface? Ericsson: this is LTE, we don’t try to change the legacy system, it's conflicting with what we already have. This had to be taken offline.
 		revised No S3‑171470  
S3‑171311 V2X privacy solution Nokia pCR Decision
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
YesEricsson: transmission of broadcast messages over PC5 is confusing. Nokia: we can enhance MBMS to be used here. Ericsson: you cannot use MBMS on PC5. Nokia clarified that the "LTE identity" is the IMSI. BT: have a general section on privacy issues only. Ericsson: we don’t have a privacy solution and we need to make it clear in the TS. Nokia: Resource allocation and how it is dynamically done is not SA3's business and does not need to be here. Vodafone: there is no user interface specified for V2X in 3GPP. We need to make it clear. This had to be taken offline. A sentence on user consent was added to tdoc 319 to address this document.
 		merged No S3‑171473  
S3‑171312 V2X key issue enhanced Nokia pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
YesVodafone: to have the means for trust/confidence would be a better rewording.
 		revised No S3‑171478  
S3‑171313 Resolution of ENs in solutions 1.23 and 1.24 Nokia pCR  
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171314 pCR to TS35.501 - Authentication procedure for EPS AKA* - possible variant VODAFONE Group Plc pCR Agreement
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDiscussed together with Nokia's solution in tdoc 373. Main difference is the Resp. No big difference between this and Nokia's solution, Vodafone opted to follow Nokia's option.
 		noted No    
S3‑171315 Interim Agreements on Key Issue # 4.1: AS security during RRC idle mode Samsung pCR Approval
8.3.4RAN security
 		Yes
Yes
 		noted No    
S3‑171316 Question and Interim Agreements on Key Issue # 1.3: User plane integrity between UE and network Samsung pCR  
8.3.1Security architecture
 		Yes
Yes
 		revised No S3‑171561  
S3‑171317 Background to proposed SA3 handling of LS from TC CYBER Home Office, BT, Telefonica discussion Discussion
6.9TC-CYBER
 		Yes
Yes
 		noted No    
S3‑171318 New Key Issue in response to in ETSI TC CYBER on middlebox security Home Office, BT, Telefonica pCR Approval
8.3.1Security architecture
 		Yes
YesVodafone supported this contribution. BT suggested the change of some requirements to adjust to this. Qualcomm: it’s more appropiate to look at this from the access and core network point of view, a separate study item would be required. Nokia: is this relevant to the other 5G work we are doing? I think it isn't. Nokia: it's about inter operator links. Sprint disagreed. Docomo: Who authorizes the middleboxes to be there? It's premature before seeing protocols that can support this. NCSC: hop by hop doesn’t have an issue. Security across domains is the key issue here and needs to be recorded. Vodafone: at application level, is the middle box for them as well? Home Office: the intention is that it is transparent for them.
 		noted No    
S3‑171319 Adding information on lack of Uu privacy to the V2X CR Qualcomm Incorporated, Ericsson, LG pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
YesORANGE: we have LTE privacy at least. Telia Sonera supported this document. Ericsson: we are not addressing that the operator cannot track users in V2X, as required by SA1. ORANGE: just reference to 33.401. BT,Nokia: not only 33.401. Qualcomm: it's important to note the requirements that we are not addressing. ORANGE: they don't have any requirements for the IMSI privacy. Vodafone suggested to move the text on the technical solution to a note. This was accepted.
 		revised No S3‑171473  
S3‑171320 Clarifying some text on the procedures for the security of V2X data Qualcomm Incorporated pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
YesVodafone: it seems that we are enforcing the policy to be the same.
 		revised No S3‑171469  
S3‑171321 Correcting the XML for the UE to PKMF interface Qualcomm Incorporated CR Agreement
7.6.12Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)
 		Yes
Yes
 		agreed No    
S3‑171322 Correcting the XML for the UE to PKMF interface Qualcomm Incorporated CR Agreement
7.6.12Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)
 		Yes
Yes
 		revised No S3‑171533  
S3‑171323 Tidying up the eNB to eNB dual connectivity Qualcomm Incorporated CR Agreement
7.6.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑171529  
S3‑171324 Solution for Dual Connectivity between MeNB and SgNB Qualcomm Incorporated CR Agreement
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesEricsson preferred to have the content in an annex as Qualcomm proposed.This was agreed. Vodafone pointed out that both Annex A and E needed to be normative. Ericsson commented that the NR capability should be left out when merging with 185, as it is still an open issue. Qualcomm agreed. It was agreed to create a DraftCR (living document) to include agreed content until the next meeting.
 		not pursued No    
S3‑171325 Security for the RLFs for UEs doing user plane over control plane using NAS level security Qualcomm Incorporated CR Agreement
7.6.1SAE/LTE Security
 		Yes
YesIt will come back for the next meeting.
 		postponed No    
S3‑171326 Proposed questions and agreements on the derivation of the anchor key Qualcomm Incorporated pCR Approval
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171327 Simplified symmetric key privacy solution that enable routing to multiple AUSFs Qualcomm Incorporated pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171328 Generic introductory text for the Authentication clause of TS 33.501 Qualcomm Incorporated pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDocomo warned about the ambiguous use of mays and shoulds that may or may not be normative language. Ericsson commented that the second paragraph in 6.1.1.1 hasn’t been defined yet and that it should be removed.
 		revised No S3‑171496  
S3‑171329 EAP based secondary authentication with PDU session authorization information Qualcomm Incorporated pCR Approval
8.3.2Authentication
 		Yes
YesDiscussed with 1331, and 1431.
 		noted No    
S3‑171330 Security procedures between UE and external data networks via the 5G network Qualcomm Incorporated pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171331 pCR to provide an update to the Key Issue #1.5 to add a PDU session authorization token in the NAS SM signalling Qualcomm Incorporated pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171332 PMSI usage in EAP-AKA' Qualcomm Incorporated pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No   S3‑170833
S3‑171333 pCR to update solution #7.4: Privacy enhanced Mobile Subscriber Identifier (PMSI) to clarify the PMSI synchronization Qualcomm Incorporated pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No   S3‑170836
S3‑171334 pCR to provide an evaluation on the solution #7.4 Privacy enhanced Mobile Subscription Identifier (PMSI) Qualcomm Incorporated pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No   S3‑170837
S3‑171335 pCR to provide an evaluation on the solutions for identity privacy Qualcomm Incorporated pCR Approval
8.3.7Subscription privacy
 		Yes
YesEricsson didn’t agree with a big part of this document,es pecially the second section. Vodafone proposed to add computation at the UE China Mobile: the conclusion is not complete because other solutions are not considered. It's not valid either cause it uses different situations for the comparisons. Ericsson: there are some agreements in this conclusion. China Mobile: why there are no issues with the UE having incorrect symmetric key? Ericsson agreed that this wasn’t mentioned. Revised to address comments from Ericsson, Nokia and Interdigital.
 		merged No S3‑171509 S3‑170838
S3‑171336 pCR to provide an evaluation on the solutions for identity privacy Qualcomm Incorporated pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No   S3‑170832
S3‑171337 Agreements related to UE (re)registration and NAS security procedures in 5GS Qualcomm Incorporated discussion Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171338 NR algorithm selection in EN-DC Qualcomm Incorporated pCR Approval
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171339 Details of the calculation of HASH_MME and HASH_UE Qualcomm Incorporated CR Agreement
7.6.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑171530  
S3‑171340 New Solution response to work in ETSI TC CYBER on middlebox security Home Office, BT, Telefonica pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		noted No    
S3‑171341 N3gpp access merged Call flow Nokia, Qualcomm, Intel, Huawei, Broadcom pCR Approval
8.3.1Security architecture
 		Yes
YesT-Mobile: Update the call flow to address the privacy of the user identity (reflect what is encrypted and so on).
 		revised No S3‑171565  
S3‑171342 Draft reply to LS from TC CYBER on middlebox security Home Office, BT, Telefonica LS out Approval
6.9TC-CYBER
 		Yes
YesDocomo: not sure that TC CYBER is the place to define such protocol but IETF.
 		revised No S3‑171449  
S3‑171343 BEST TS33.xyz Section 6.2.1 - IP EMSDP PDU Juniper Networks other Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No    
S3‑171344 N3GPP access key issue and agreement Nokia, Qualcomm, Intel, Huawei, Broadcom pCR Approval
8.3.1Security architecture
 		Yes
YesDependant of tdoc 341.
 		revised No S3‑171566  
S3‑171345 BEST TS33.xyz Section 6.2.2 - EMSDP Payload Format Juniper Networks other Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No    
S3‑171346 draft_reply to SA2 on S2-172523 n3gpp authentication for re-registration Nokia LS out Approval
8.3.1Security architecture
 		Yes
YesQualcomm commented that option 2 is better, in order to minimise the impact on the UE. The NAS message should be kept the same. Vodafone: option 2 protects the identities more than option 1.This should be added in the response to the LS. Ericsson: the privacy solution is handled separately and it will be similar for both options. We support option one, achieving an architecture that is agnostic to the access. Nokia: privacy concerns are the same for both options, the parameters are the same. We agree with Ericsson. BT preferred option one because it was simpler for them. Huawei and Intel went for option one.Intel commented that the first option was simpler to implement for CT1. Huawei: if we have a privacy solution for option one equal to what we have in LTE, it's fine. 3GPP and non-3GPP accesses should have the same privacy protection.
 		revised No S3‑171488  
S3‑171347 Detailing of ToC for TS 33.501 wrt authentication Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE didn’t agree with the wording in 6.1.1.1. Why referencing to an informative Annex? Discussed with tdoc 285 and 378.
 		revised No S3‑171495  
S3‑171348 Key Managemat Procedure between the HSE and EAS China Mobile Com. Corporation other  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
YesVodafone asked for more time to work with China Mobile for the next meeting. There was agreement on the work needing to be done.
 		noted No    
S3‑171349 UP Integrity KI and requirements Nokia pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171350 Alignment according to withdrawal of I-WLAN - Rel-13 Gemalto N.V. CR Agreement
7.6.18Other work items
 		Yes
YesQualcomm: this feature is not in 402, so it would be considered as a new feature. Is there a use case to have such scenario in 402? I don’t think we need to move this to 402. Gemalto: for EAP AKA in 4G we think it should be available in the 33.402 document. Qualcomm: I-WLAN features will be discontinued from Rel-13. This is a I-WLAN specific feature and we have no requirements for this in 402. BT: this scenario has no use cases. Deutsche Telekom and ORANGE agreed.
 		not pursued No    
S3‑171351 Questions related to the Usability of legacy USIM in key issue #2.1 China Mobile, KPN pCR Approval
8.3.2Authentication
 		Yes
YesQualcomm: why not Rel-99 USIM? Nokia: Rel-99 USIMs can be used for LTE access. This is not correct. Docomo: From Rel-99 to Rel-8, there is a new separation bit, so the USIMs are different. Oberthur: there are other non security features that differ Rel-99 and Rel-8 SIMs. The first question doesn't work, you need to update the card.It will never attach to 5G. Deutsche Telekom: then ,the answer is no. Oberthur: 5G authentication will never happen. KPN: so we all get rid of all SIM cards in the World? What happens to my customers? Oberthur: you can send new SIMs or update them. TIM: operators will not throw milllions of SIMs away because of 5G. This wasn't defined in SA1. Vodafone agreed with the question one. ORANGE: this is valid for legacy SIMs. TIM: this is a generic issue, not privacy. TIM: if we have any doubt these requirements, we need to ask SA1. ORANGE: we need to study technically this, not for business reasons. SA1 cannot decide that. Gemalto supported ORANGE. This is a security group, we need to study if there is a security issue and we don’t know the conclusions yet. G&D supported ORANGE's position. We need to consider the USIM evolution. Deutsche Telekom and Telia Sonera supported ORANGE's proposal as well. Gemalto: if we answer no to the questions, it doesn’t mean that we have to replace all USIMs. Qualcomm supported ORANGE. TIM objected to this contribution. The Chair asked if this question blocked the work. It didn’t seem to be the case. He also pointed out that the question needed some clarification. Nokia suggested to discuss this in a conference call. BT commented that the impact on the UICC appears on the CR cover, so this can be discussed further depending on the technical issue. The Chair commented that there is no restric rule for that and that it was better to reach an agreement beforehand in a conference call. It was decided to have a conference call to clarify this contribution: questions on the use of legacy USIMs.
 		noted No   S3‑171167
S3‑171352 UP Integrity solution Nokia pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171353 Requirements for secure storage and processing of subscription credentials ORANGE pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesGemalto: subscription credentials stored and processed in the UICC, was a solution in the TR.We disagree with this. Sony agreed with Gemalto. ORANGE: is the UICC one of the solutions? Also, we are not excluding other options as the following editor's note is stating. Intel supported Gemalto and preferred to have the UICC solution removed. It was agreed to remove the last sentence and editor's note.
 		revised No S3‑171492  
S3‑171354 New Key issue avoiding IMSI paging Nokia pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171355 HASH Derivation for NAS security mode command procedure Huawei, Hisilicon CR  
7.6.1SAE/LTE Security
 		Yes
Yes
 		merged No S3‑171530  
S3‑171356 pCR to S3-170916 - Change to Key Hierarchy KPN, Nokia other Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		revised No S3‑171539  
S3‑171357 Initiation of authentication Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑171358 BEST TS 33.xyz Section 4.4.2 - EAS Registration Nokia other  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No    
S3‑171359 BEST TS 33.xyz Section 4.4.4 - Key Refresh Nokia other  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		revised No S3‑171442  
S3‑171360 BEST TS33.xyz Section 3-4 - Editorial and interface Corrections Juniper Networks other Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
YesAll these type of documents will be implemented in the draft spec in tdoc 538.
 		approved No    
S3‑171361 Dynamic pseudonyms as short-term subscription identifiers TELECOM ITALIA S.p.A. pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171362 Initiation of authentication Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesSome concerns on the editor's note and its links with the privacy work. Nokia: The Home network determines what authentication method to use. Qualcomm: better rename EPS AKA* since we are creating a new protocol and may not have to be related to the one that is in the TR. Ericsson: we discourage MME to handle more than one authentication vector, which is not here. Nokia: it's a recommendation. Some operators would like to have batches of authentication vectors to be used in case of outage of the HPLMN. Docomo: roaming in a malicious network then coming back to the trusted network is a confusing use case. Deutsche Telekom: if we allow this, we have to deal with the consequences. This can lead to greater complexity. Vodafone confirmed that the batches of authentication vectors are a useful tool for operators. An editor's note and some text revisions were done in order to address all comments.
 		revised No S3‑171497  
S3‑171363 Authentication procedure for EAP-AKA’ Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑171364 New key issue avoiding IMSI paging Nokia pCR Approval
8.3.7Subscription privacy
 		No
No
 		withdrawn Yes    
S3‑171365 BEST TS 33.xyz Section 4.4.3 - Key Request Nokia other  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No    
S3‑171366 Adding a requirement within 3GPP TS 33.250 on “Unpredictable GTP TEID” TELECOM ITALIA S.p.A., KPN pCR Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
YesEricsson doubted whether this was necessary, as there were other issues. Deutsche Telekom: GTP spoof has been treated since a long time ago and we shouldn’t discuss whether this is a real threat or not. It is correct that there are other solutions but this one is the simplest so far. Docomo: this is a valid threat and we should try to protect agains it.
 		approved No    
S3‑171367 Comments on S3-171144, Privacy aspects of MCC/MNC in IMSI InterDigital, Inc., AT&T discussion Decision
8.3.7Subscription privacy
 		Yes
YesVodafone: even if I give you a random number I can guess your identity by identifying other factos like the time you turn on, or the places you appear, etc.. There's no such thing as real privacy. Ericsson: Encrypting MSIDN it will be more complex to track someone. T-Mobile: IMSI catcher needs close proximity and knowledge of the user. Interdigital: hability to know the information by catching ovber the air is the real issue. Deutsche Telekom: don’t forget that these are options for the operators and that in some countries they will not be allowed to use it. If we raise the bar too high and design an overly complex solution, we take the risk that it will not be used at all. Docomo supported this; it needs to be taken into consideration. No apparent agreement between companies since their positions were quite fixed.
 		noted No    
S3‑171368 Question and interim agreement on support for secondary authentication by an authenticator in the Data network Nokia pCR  
8.3.2Authentication
 		No
No
 		withdrawn Yes    
S3‑171369 Adding test case for the requirement on unpredictable TEID generated by the PGW. TELECOM ITALIA S.p.A., KPN pCR Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		revised No S3‑171515  
S3‑171370 Authentication procedure for EAP-AKA’ Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesQualcomm and Ericsson: same key derivation for all EAP methods would be more desireable. Which key to be used should be left for further study: MSK or derived from MSK.
 		revised No S3‑171499  
S3‑171371 Authentication procedure for EPS AKA* Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑171372 Question and interim agreement on support for secondary authentication by an authenticator in the Data network Nokia pCR Approval
8.3.2Authentication
 		Yes
Yes
 		noted No    
S3‑171373 Authentication procedure for EPS AKA* Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesSolution from the TR.
 		noted No    
S3‑171374 Protecting EAP messages between 3GPP Network and external DN-AAA server Nokia pCR Approval
8.3.1Security architecture
 		No
No
 		withdrawn Yes    
S3‑171375 Protecting EAP messages between 3GPP Network and external DN-AAA server Nokia pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		left for email approval No    
S3‑171376 Authentication procedure for EPS AKA* - possible variant Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesThe solutions over the table were in tdocs 314 and 376. This tdoc presents a modified authentication response. Variation of 376. Vodafone didn’t favour the original . Ericsson was in favour of this solution. Gemalto commented that there is no requirement for support of legacy USIM. Nokia: It shall be possible to compute this in the ME. Oberthur: SA1 defines new requirements, if there are not new requirements the old ones are applicable. Keep it as it is. Docomo: we need to make sure that the serving network name is something that we can use. KPN had a slight preference for Vodafone's solution, as Huawei. Vodafone went for this solution eventually. Huawei disagreed with this solution.
 		revised No S3‑171545  
S3‑171377 Linking increased home control to subsequent procedures Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDeutsche Telekom: maybe to make 6.1.4.2 normative? Ericsson: There may be other ways to do this. It's not clear for us whether this could become normative so we suggest to postpone for the next meeting. Docomo preferred to have this normative, Vodafone as well. BT was concerned to have this in the normative part of the TS.
 		revised No S3‑171501  
S3‑171378 Question and Interim Agreement on linking increased home control to subsequent procedures Nokia pCR  
8.3.2Authentication
 		Yes
YesHuawei: is this going to an informative annex? Ericsson: what do we have to decide now that this is going to be informative? Docomo: it can only be informative. Remove the "informative". Ericsson: we don’t need to agree now that this is going to be a guidance.
 		revised No S3‑171494  
S3‑171379 Reply LS on Support of Explicit Bootstrapping in ERP ORANGE LS out Approval
7.6.17Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)
 		Yes
Yes
 		revised No S3‑171532  
S3‑171380 Remove support of ERP Explicit Boostrapping ORANGE other Approval
7.6.17Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)
 		Yes
No
 		withdrawn Yes    
S3‑171381 Secondary authentication by an external DN-AAA server Nokia pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesAlf (Docomo): restrict the shalls to the requirements clauses. Ericsson: make the figure editable. Qualcomm didn’t agree with the editor's note (EAP auth role) being in the TS. Ericsson agreed with removing the editor's note.
 		revised No S3‑171505  
S3‑171382 Security procedures on N12 Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesQualcomm: reword EAP-AKA' success according to what's being discussed in this meeting. MCC suggested to remove the note in EAP-AKA' Success so as not to name stages or releases in the content of the TS.This was agreed.
 		revised No S3‑171503  
S3‑171383 Security procedures on N12 Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑171384 Security procedures on N12 Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑171385 Security procedures on N12 Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑171386 Interim agreement on DoS KPN pCR Approval
8.3.1Security architecture
 		Yes
YesEricsson: it is not realistic to have mechanisms like this at the core network. T-Mobile commented that it is not sufficient to solve such problems from the UE side. ORANGE supported this question. Nokia disagreed with the question, Qualcomm needed some rewording.
 		revised No S3‑171564  
S3‑171387 EAP based Secondary authentication with an external Authenticator Nokia pCR Approval
8.3.2Authentication
 		Yes
YesQualcomm: the justification is very weak for the EAP authentication by an external authenticator. Ericsson didn’t suppor this either. Deutsche Telekom: it looks similar to 329. where we didn’t want to overload the authentication with additional features.
 		noted No   S3‑170749
S3‑171388 Resolution of editor's notes in 33.116 NTT DOCOMO other Agreement
7.1.1Security Assurance Specification for 3GPP network product classes (General, TS 33.117) (SCAS-SA3)
 		Yes
No
 		withdrawn Yes    
S3‑171389 Resolution of editor's notes in 33.117 NTT DOCOMO, KPN other Agreement
7.1.2Security Assurance Specification for 3GPP network product classes (MME, TS 33.116) (SCAS-SA3)
 		Yes
No
 		withdrawn Yes    
S3‑171390 Resolution of editor's notes in 33.916 NTT DOCOMO other Agreement
8.6.4TR on Security Assurance scheme for 3GPP network products (33.916) (SCAS-SA3TR)
 		Yes
No
 		withdrawn Yes    
S3‑171391 pCR to S3-170916 - Editorial changes to align terminology on key names KPN, Nokia other  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		No
No
 		withdrawn Yes    
S3‑171392 [FS_MC_Sec] 33880 pCR editorial updates Motorola Solutions Danmark A/S pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		revised No S3‑171456  
S3‑171393 [MCSec] 33.180 pCR Inter-domain IdM profile corrections Motorola Solutions Danmark A/S pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
YesAirbus found confusing the addition of "primary or partner" in B.9. It was agreed to remove it. Some rewording in B.6.4 was also suggested by Airbus and agreed.
 		revised No S3‑171458  
S3‑171394 [MCSec] 33180 pCR editorial updates Motorola Solutions Danmark A/S pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171395 [MCSec] 33180 pCR requirement updates Motorola Solutions Danmark A/S pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		revised No S3‑171460  
S3‑171396 WID MSec continuation work Motorola Solutions Danmark A/S WID new Agreement
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
YesNCSC commented that there is a strong dependence on SA6, so any delay in their work would delay SA's work as well. They have to finish their work the meeting before december 18.
 		revised No S3‑171465  
S3‑171397 Security procedures on N13 Nokia pCR  
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDocomo: we didn't try to secure Diameter in security area 10. Nokia:we do some solutions; public keys techniques, or protecting the internal AVP. Docomo: a lot of diameter things happening are not visible in the standards. We would like them to find a security solution. Nokia: CT4 defines AVPs, so we can do it in 3GPP. IETF has draft for the solutions in security. We should come back to them with some joint input with GSMA. We don’t define security end-to-end but we can provide with requirements.
 		revised No S3‑171504  
S3‑171398 Question and agreement on granularity of anchor key binding to serving network Nokia pCR  
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171399 Network Slice Corrections to clause 5.8.3.1 Nokia,Ericsson pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171400 pCR to TR 33.899 on granularity of anchor key binding to serving network Nokia pCR  
8.3.2Authentication
 		Yes
Yes
 		left for email approval No    
S3‑171401 Key issue details for clause 5.10.3.2.1 Nokia pCR  
8.3.10Network domain security
 		Yes
Yes
 		left for email approval No    
S3‑171402 Network Slice Corrections to clause 5.8.3.2 Nokia,Ericsson pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171403 Network Slice Correction to clause 5.8.3.4 Nokia,Ericsson pCR Approval
8.3.8Network slicing security
Yes
Yes
 		left for email approval No    
S3‑171404 Threats alignment between 5.10.3.2.2 and 5.3.3.1.2 Nokia pCR  
8.3.10Network domain security
 		Yes
Yes
 		left for email approval No    
S3‑171405 Addition of requirements for 5.10.3.2.3 Nokia pCR  
8.3.10Network domain security
 		Yes
Yes
 		left for email approval No    
S3‑171406 Enhancing solution 10.1 Nokia pCR  
8.3.10Network domain security
 		Yes
Yes
 		left for email approval No    
S3‑171407 drfat_LS On Clarifications on false eNB detection to RAN groups Nokia LS out Approval
8.3.4RAN security
 		Yes
YesDeutsche Telekom: is this for the eNodeB or for the gNodeB? Nokia: will change for gNodeB.
 		revised No S3‑171568  
S3‑171408 Discussion paper on RAN2 LS on LTE call redirection ( R2-1702388) to GERAN Nokia discussion Endorsement
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑171409 draft_LS reply to LTE call redirection to GERAN Nokia LS out Approval
7.6.1SAE/LTE Security
 		Yes
YesDocomo commented that the CS fallback/redirection to 2G wasn't the way. 360 and Huawei supported this. Your first reject it and then redirect it to 2G and registers into the CS fallback. Better to fix the problem of having a call being sent over 3G even if we don’t want it in 2G.CS fallback call that we don’t want to have in 2G. It doesn’t matter if we want the authentication call before or not. Nokia: distinguish between idle mode and terminating call. This attack doesn’t have to be with the CSFB, it's a more general attack. It's not about voice calls but forcing the UE not to go to an available 4G network. Docomo: why is it an issue if we go to 2G? 2G is not so well protected. If there is an incoming call, yoCSFB and any type attack that will force the UE to be in 2G to receive this call will be bad. Ericsson and BT agreed with Docomo. BT commented that a long term solution was needed. Ericsson: why is RAN2 working on this if this a SA3 issue? Nokia: this problem has been lingering since quite a long time. They copied us a few meetings back in a LS asking for feedback that we didn’t provide. It's not a 2G issue. Docomo: the UE needs to be aware that this is something that happens in a 2G network.it should reject unprotected redirections. The Chair commented that there is a bigger problem that we already knew. Can we solve such problem? With offline discussions, are companies aware of a bigger problem or not? Is there hope for a solution for this problem?
 		noted No    
S3‑171410 Editorial changes to align key names KPN, Nokia other Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No    
S3‑171411 New Key Issue on AKA via eRelay KPN pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑171579  
S3‑171412 New Key Issue on attach via eRelay KPN pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑171580  
S3‑171413 New Key issue on Managing handovers of eRemote UE KPN pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171414 UP confidentiality and integrity protection in 5G KPN pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia had an issue with the PDCP layer. This wasn't needed according to them. BT: we need to look closely at what support means. Nokia: support means implemented or not. They proposed to follow 401. The meaning of support wasn't clear in the room.
 		revised No S3‑171491  
S3‑171415 Question and interim agreement for co-location of the SCMF and the SEAF Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		revised No S3‑171560 S3‑171262
S3‑171416 Key issue on location information protection China Unicom, CATR pCR  
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171417 Key issue on subscribed service information protection China Unicom, CATR pCR  
8.3.7Subscription privacy
 		Yes
Yes
 		left for email approval No    
S3‑171418 CR to TR33.926 on Adding a generic threat on “User Session Tampering” TELECOM ITALIA S.p.A., KPN other Approval
8.6.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		Yes
No
 		withdrawn Yes    
S3‑171419 TS 33.402 - Align with CT1 TS 24.302 for obtaining IMEI using Mobile Equipment Identity signalling Nokia other Agreement
7.6.18Other work items
 		Yes
No
 		withdrawn Yes    
S3‑171420 Update of references to GSMA NESAS documents in TR 33.916 Deutsche Telekom AG CR Agreement
8.6.4TR on Security Assurance scheme for 3GPP network products (33.916) (SCAS-SA3TR)
 		Yes
Yes
 		agreed No    
S3‑171421 TR 33.885: conclusion on V2X Entities Secure Environment Gemalto N.V. pCR Approval
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		revised No S3‑171480  
S3‑171422 TS 33.185: V2X Entities Secure Environment Gemalto N.V. pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
YesVodafone: is this spec applicable to LTE only or 5G as well? The answer was LTE only. Vodafone: then we don’t need it. This has been specified already. Gemalto: this was in the TR. Why is it different now in the TS? KPN supported Vodafone. If this is agreed here, we have to add it to all LTE specs. BT supporting having this. Vodafone:it should be USIM and not UICC. This was agreed.. Telia Sonera supported BT: this is a new use case.
 		revised No S3‑171467  
S3‑171423 Alignment according to withdrawal of I-WLAN feature - Rel-14 Gemalto N.V. CR Agreement
7.6.18Other work items
 		Yes
Yes
 		not pursued No    
S3‑171424 Comments on S3-171271: Changes to Security Key Update Samsung discussion Discussion
7.6.1SAE/LTE Security
 		Yes
Yes
 		endorsed No    
S3‑171425 256-bit algorithms for 5G ETSI SAGE LS in  
6.3ETSI SAGE
 		Yes
YesBT doubted whether anything else besides radio should have 256bits.
 		noted No    
S3‑171426 Setting the salt value in UE and P-CSCF when using AES-GCM/AES-GMAC in IPSec ESP in IMS access security Nokia CR  
7.6.2IP Multimedia Subsystem (IMS) Security
 		Yes
Yes
 		agreed No    
S3‑171427 Setting the salt value in UE and P-CSCF when using AES-GCM/AES-GMAC in IPSec ESP in IMS access security Nokia CR  
7.6.2IP Multimedia Subsystem (IMS) Security
 		Yes
Yes
 		agreed No    
S3‑171428 Introduction of a new value range for the input value FC for the key derivation function (KDF) for use in TS 33.203 Nokia CR  
7.6.2IP Multimedia Subsystem (IMS) Security
 		Yes
Yes
 		agreed No    
S3‑171429 Introduction of a new value range for the input value FC for the key derivation function (KDF) for use in TS 33.203 Nokia CR  
7.6.2IP Multimedia Subsystem (IMS) Security
 		Yes
Yes
 		agreed No    
S3‑171430 Correction of reference Nokia, Vodafone CR  
7.6.1SAE/LTE Security
 		Yes
Yes
 		agreed No    
S3‑171431 Comments on S3-171331 as well as 1329, 1330 pCR to provide an update to the Key Issue #1.5 to add a PDU session authorization token in the NAS SM signalling Nokia response Agreement
8.3.1Security architecture
 		Yes
YesQualcomm disagreed with the paragraph where the Nokia states that the UE is happy with the 3GPP network is talking to an ext DN the UE is associated with. Orange supported Nokia. ORANGE: Relationship between external DN and operator. The same as EAPS AKA*. Qualcomm: only some of the allowed roaming networks have a relation with the DN AAA.
 		left for email approval No    
S3‑171432 Allocation of FC values for BEST KPN, Vodafone CR Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		revised No S3‑171542 S3‑170670
S3‑171433 [MCSEC] Addition of descriptive clauses NCSC pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171434 Remove support of ERP Explicit Boostrapping ORANGE CR Agreement
7.6.17Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)
 		Yes
Yes
 		revised No S3‑171531  
S3‑171435 Resolution of editor's notes in 33.116 NTT DOCOMO CR Agreement
7.1.1Security Assurance Specification for 3GPP network product classes (General, TS 33.117) (SCAS-SA3)
 		Yes
Yes
 		agreed No    
S3‑171436 Resolution of editor's notes in 33.117 NTT DOCOMO, KPN CR Agreement
7.1.2Security Assurance Specification for 3GPP network product classes (MME, TS 33.116) (SCAS-SA3)
 		Yes
Yes
 		agreed No    
S3‑171437 Resolution of editor's notes in 33.916 NTT DOCOMO CR Agreement
8.6.4TR on Security Assurance scheme for 3GPP network products (33.916) (SCAS-SA3TR)
 		Yes
Yes
 		agreed No    
S3‑171438 CR to TR33.926 on Adding a generic threat on “User Session Tampering” TELECOM ITALIA S.p.A., KPN CR Agreement
8.6.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		Yes
YesEricsson doubted whether this was required at all.
 		revised No S3‑171514  
S3‑171439 TS 33.402 - Align with CT1 TS 24.302 for obtaining IMEI using Mobile Equipment Identity signalling Nokia CR Agreement
7.6.18Other work items
 		Yes
Yes
 		agreed No    
S3‑171440 Draft reply LS to CT3 and SA4 on xMB security Ericsson LS out  
5Items for early consideration
 		Yes
Yes
 		revised No S3‑171450  
S3‑171441 Reply LS on secure storage and processing of subscription credentials within the NG UE ETSI TC SCP LS in  
8.3.18Other
 		Yes
Yes
 		noted No    
S3‑171442 BEST TS 33.xyz Section 4.4.4 - Key Refresh Nokia other -
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		revised No S3‑171541 S3‑171359
S3‑171443 Reply LS on NAS SM integrity protection S1-172226 LS in discussion
8.3.18Other
 		Yes
Yes
 		noted No    
S3‑171444 LS on Closed Subscriber Group in 5GS S1-172425 LS in discussion
8.3.18Other
 		Yes
YesQualcomm: wait for SA2 and RAN to see if the CSGs are the same as in LTE. Oberthur: there are no specific requirements from SA1 for this. Vodafone: they want to use this in phase one, although there is no use case. It was decided to postpone since the next SA3 meeting would before SA1's.
 		postponed No    
S3‑171445 Reply LS on addition of KMS URI to configuration parameters S6-170795 LS in discussion
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		noted No    
S3‑171446 Work Plan input from Rapporteurs MCC other -
9Review and Update of Work Plan
No
No
 		reserved No   S3‑171006
S3‑171447 Report of 3GPPSA3-Emeeting on DoNAS(NB-IOT) VODAFONE Group Plc report Approval
4.1 Approval of the report from SA3#86 and SA3 ad-hoc
 		Yes
YesRevised to correct the table of attendees.
 		approved No   S3‑171091
S3‑171448 New WID on Study on Long Term Key Update Procedures VODAFONE Group Plc WID new Agreement
8.6.5Other study items
 		Yes
Yes
 		agreed No   S3‑171096
S3‑171449 Reply to LS from TC CYBER on middlebox security Home Office LS out Approval
6.9TC-CYBER
 		Yes
Yes
 		approved No   S3‑171342
S3‑171450 Reply LS to CT3 and SA4 on xMB security Ericsson LS out -
5Items for early consideration
 		Yes
Yes
 		approved No   S3‑171440
S3‑171451 Reply LS on update to key management for application signalling NCSC LS out Approval
5Items for early consideration
 		Yes
Yes
 		approved No   S3‑171117
S3‑171452 [FS_MC_SEC] Adding MSCCK functionality for back-compatibility into evaluation clause NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171121
S3‑171453 Reply to: LS on MCData protocol and choice of media plane protocol NCSC LS out approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171454 [FS_MC_SEC] MCData Key Management NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171114
S3‑171455 [FS_MC_SEC] MCData Key Distribution NCSC pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171115
S3‑171456 [FS_MC_Sec] 33880 pCR editorial updates Motorola Solutions Danmark A/S pCR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171392
S3‑171457 [MCSEC] Adding MSCCK functionality for back-compatibility NCSC pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171118
S3‑171458 [MCSec] 33.180 pCR Inter-domain IdM profile corrections Motorola Solutions Danmark A/S pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171393
S3‑171459 [MCSEC] Update to MCData security NCSC pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171123
S3‑171460 [MCSec] 33180 pCR requirement updates Motorola Solutions Danmark A/S pCR Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171395
S3‑171461 Draft TR 33.880 NCSC draft TR Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171462 Cover sheet TR 33.880 NCSC TS or TR cover Approval
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		No
No
 		withdrawn Yes    
S3‑171463 Draft TS 33.180 NCSC draft TS Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171464 Cover sheet TS 33.180 NCSC TS or TR cover Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171465 WID MSec enhancements Motorola Solutions Danmark A/S WID new Agreement
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
YesAdding new supporters, correcting some issues on name and acronym and impacted existing specs table. Motorola commented that they wished to continue using TR 33.880 and extend the study. MCC commented that the Study item may have to be revised since the justification and objectives may have changed. The original study was intended for Release 14. The Study item had to be checked offline, but in any case this WID was correct and agreed.
 		agreed No   S3‑171396
S3‑171466 Reply LS to SA6 on mission critical communication interworking security issues NCSC LS out Approval
7.2Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171467 TS 33.185: V2X Entities Secure Environment Gemalto N.V. pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171422
S3‑171468 Misc Changes to TS 33.185 Sec 6.5 Huawei, HiSilicon pCR Decision
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171087
S3‑171469 Clarifying some text on the procedures for the security of V2X data Qualcomm Incorporated pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171320
S3‑171470 V2X privacy requirements Nokia pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171310
S3‑171471 V2X privacy solution Nokia pCR Decision
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		No
No
 		withdrawn Yes    
S3‑171472 Miscellaneous changes to Chapter 6.6 of TS 33.185 CATR pCR -
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171057
S3‑171473 Adding information on lack of Uu privacy to the V2X CR Qualcomm Incorporated, Ericsson, LG pCR Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171319
S3‑171474 Draft TS 33.185 Huawei draft TS Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171475 Cover sheet TS 33.185 Huawei TS or TR cover Approval
7.3Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171476 TR 33.885 EN Cleanup Sec 5.5 Huawei, HiSilicon pCR Approval
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171068
S3‑171477 TR 33.885 EN Cleanup Sec 5.9 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171071
S3‑171478 V2X key issue enhanced Nokia pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171312
S3‑171479 TR 33.885 EN Cleanup Sec 6.6 Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171078
S3‑171480 TR 33.885: conclusion on V2X Entities Secure Environment Gemalto N.V. pCR Approval
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		No
YesORANGE: subscription credentials resides in the USIM in the 3GPP, but for non 3GPP where do they reside? UICC is a better term than USIM. Gemalto agreed. This would be consistent with TS 33.402. ORANGE agreed as well. Vodafone: What entity in the UICC has these credentials? This was taken offline and finally approved.
 		approved No   S3‑171421
S3‑171481 TR 33.885 EN Cleanup Sec Annex D Huawei, HiSilicon pCR Decision
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171085
S3‑171482 Draft TR 33.885 Huawei draft TR Approval
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
YesVodafone commented that they preferred to have this specification withdrawn and not to be sent for approval.
 		approved No    
S3‑171483 Cover sheet TR 33.885 Huawei TS or TR cover Approval
8.2Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑171484 Reply to: LS to SA3 on actions for integrity check failure on SgNB Huawei LS out approval
8.3.18Other
 		Yes
Yes
 		approved No    
S3‑171485 Reply to: Reply LS on security in E-UTRA-NR Dual Connectivity Qualcomm LS out approval
8.3.18Other
 		Yes
YesSA3 is still analyzing the three options, so no final decision has been made in SA3 during this meeting.
 		approved No    
S3‑171486 EN-DC in option 3a/3x Ericsson pCR Approval
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesKeeps the interim agreements part and states only "yes".
 		approved No   S3‑171147
S3‑171487 Solution for Dual Connectivity between MeNB and SgNB Qualcomm Incorporated draftCR Approval
7.5EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesContains the merge of 324,487 and 148. This will be a living document that eventually will become a CR when the content is agreed.
 		approved No    
S3‑171488 Reply to SA2 on S2-172523 n3gpp authentication for re-registration Nokia LS out Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171346
S3‑171489 Reply to: LS on 5GS Security aspects seeking resolution Nokia LS out approval
8.3.18Other
 		Yes
YesVodafone strongly disagreed with "the NSSAI shall be confidentiality protected whenever a NAS security context is available (as far as regulation allows)". They also suggested to remove explanation on the rule about interim agrements going to the TS. Nokia commented that this was coming from interim agreements already approved. This is a SA3 working procedure. ORANGE also expressed their concerns on questioning such working procedures.
 		approved No    
S3‑171490 Reply to: LS on IMSI availability in the VPLMN T-Mobile LS out approval
8.3.18Other
 		Yes
Yes
 		approved No    
S3‑171491 UP confidentiality and integrity protection in 5G KPN pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171414
S3‑171492 Requirements for secure storage and processing of subscription credentials ORANGE pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171353
S3‑171493 pCR to 33.501: requirements on gNB Ericsson pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171132
S3‑171494 Question and Interim Agreement on linking increased home control to subsequent procedures Nokia pCR -
8.3.2Authentication
 		Yes
Yes
 		approved No   S3‑171378
S3‑171495 Detailing of ToC for TS 33.501 wrt authentication Nokia pCR -
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171347
S3‑171496 Generic introductory text for the Authentication clause of TS 33.501 Qualcomm Incorporated pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171328
S3‑171497 Initiation of authentication Nokia pCR -
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171362
S3‑171498 Evaluations and conclusions in clause 7 updated as a result of FS_NSA conference calls Vodafone pCR Approval
8.3.7Subscription privacy
 		Yes
YesIssues in 5.7.4.4.4 for Qualcomm. Telecom Italia commented that they had comments since the Tenerife meeting for the evaluation of 7.14. Nokia commented that there were some other conclusions for 5.7.5 from other companies that could be added here. It was seen that a better solution would be to have a separate document for this. AT&T: What part of the IMSI needs to be protected must be very clear.
 		revised No S3‑171508  
S3‑171499 Authentication procedure for EAP-AKA’ Nokia pCR -
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171370
S3‑171500 Interim Agreements: How to implement increased home control in EPS AKA* Ericsson pCR Approval
8.3.2Authentication
 		Yes
Yes
 		approved No   S3‑171125
S3‑171501 Linking increased home control to subsequent procedures Nokia pCR -
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171377
S3‑171502 Content for clause 7 on security procedures between 5G Network Functions Ericsson pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171285
S3‑171503 Security procedures on N12 Nokia pCR -
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171382
S3‑171504 Security procedures on N13 Nokia pCR -
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171397
S3‑171505 Secondary authentication by an external DN-AAA server Nokia pCR Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171381
S3‑171506 Annex on the additional EAP methods Ericsson, Samsung, Qualcomm Incorporated, Nokia, Intel, Huawei pCR -
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171126
S3‑171507 Reply to: Reply LS on SA3 LS in S3-170944 “LS on security termination for the User Plane in 5G” Deutsche Telekom LS out approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑171508 Evaluations and conclusions in clause 7 updated as a result of FS_NSA conference calls Vodafone pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171498
S3‑171509 Conclusions in clause 7 Vodafone pCR Approval
8.3.7Subscription privacy
 		Yes
YesContains the conclusions of S3-171101 as well.
 		approved No    
S3‑171510 Solution for IMSI Privacy while meeting LI Requirements Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171190
S3‑171511 KI#7.2_question_agreement_imsi_priv_privay_in_phase1 Ericsson, Nokia, Vodafone, Intel, KPN, LGE, China Mobile, CATT, NEC, Juniper Networks, T-Mobile, Telenor, Deutsche Telekom, Morpho, IPCom, Telecom Italia pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171136
S3‑171512 Question to full protection of permanent identifier - was 766-203 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171299
S3‑171513 KI#7.2_agreements_imsi_priv_solution_types Ericsson, Nokia, Vodafone, Intel, LGE, China Mobile, CATT, NEC, Juniper Networks, Deutsche Telekom, T-Mobile, Morpho, IPCom,ORANGE pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171138
S3‑171514 CR to TR33.926 on Adding a generic threat on “User Session Tampering” TELECOM ITALIA S.p.A., KPN CR Agreement
8.6.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		Yes
Yes
 		agreed No   S3‑171438
S3‑171515 Adding test case for the requirement on unpredictable TEID generated by the PGW. TELECOM ITALIA S.p.A., KPN pCR Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		approved No   S3‑171369
S3‑171516 Deleting the EN in the section 4.2.6 of TS33.250 Huawei, Hisilicon pCR Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		approved No   S3‑171264
S3‑171517 Draft TS 33.250 China Mobile draft TS Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		approved No    
S3‑171518 Cover sheet TS 33.250 China Mobile TS or TR cover Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		approved No    
S3‑171519 AS algorithms selection Huawei, Hisilicon pCR Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No   S3‑171217
S3‑171520 Verify RRC integrity protection Huawei, Hisilicon pCR Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
YesRemoving the term "simulated eNodeB"
 		approved No   S3‑171218
S3‑171521 Verify the feature of EIA0 Huawei, Hisilicon pCR Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No   S3‑171219
S3‑171522 Verify key refresh at eNB Huawei, Hisilicon pCR Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
YesEricsson suggested to add the screeshot of relevant changes. Also removing the simulated eNodeB term.
 		approved No   S3‑171220
S3‑171523 Draft TS 33.216 Huawei draft TS Approval
7.1.4Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No    
S3‑171524 Draft TS 33.501 NTT-Docomo draft TS Approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
Yes
 		left for email approval No    
S3‑171525 Revised SID MCPTT NCSC SID revised Agreement
8.4Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
YesThe SID was revised to keep working in TR 33.880 introducing the new activity in Rel-15.
 		agreed No    
S3‑171526 Reference to list of 3GPP vendor specific EAP methods Ericsson CR Agreement
7.6.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑171059
S3‑171527 Alignment of 3GPP-vendor specific EAP method names with TS 24.302 Ericsson CR Agreement
7.6.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑171060
S3‑171528 Reply LS on on providing WT MAC address to the UE using eNB signalling Intel LS out Approval
7.6.1SAE/LTE Security
 		Yes
Yes
 		approved No   S3‑171273
S3‑171529 Tidying up the eNB to eNB dual connectivity Qualcomm Incorporated CR Agreement
7.6.1SAE/LTE Security
 		Yes
YesChanged the Release since not possible to have Cat-D for Rel-14 (frozen).
 		agreed No   S3‑171323
S3‑171530 Details of the calculation of HASH_MME and HASH_UE Qualcomm Incorporated CR Agreement
7.6.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑171339
S3‑171531 Remove support of ERP Explicit Boostrapping ORANGE CR Agreement
7.6.17Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)
 		Yes
YesAdding the reference to the RFC in clause 2. Removing "in this release" in the NOTE, as commented by MCC.
 		agreed No   S3‑171434
S3‑171532 Reply LS on Support of Explicit Bootstrapping in ERP ORANGE LS out Approval
7.6.17Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)
 		Yes
Yes
 		approved No   S3‑171379
S3‑171533 Correcting the XML for the UE to PKMF interface Qualcomm Incorporated CR Agreement
7.6.12Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)
 		Yes
Yes
 		agreed No   S3‑171322
S3‑171534 Adding references to GIA4, GEA5/GIA5 and stage 3 GMM specifications, and removing corresponding editor's notes. Ericsson CR Approval
7.6.13Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)
 		Yes
Yes
 		agreed No   S3‑171127
S3‑171535 Adding references to GIA4, GEA5/GIA5 and stage 3 GMM specifications, and removing corresponding editor's notes. Ericsson CR Approval
7.6.13Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)
 		Yes
Yes
 		agreed No   S3‑171128
S3‑171536 LS on a new requirement on “Unpredictable GTP TEID” Telecom Italia LS out Approval
7.1.3Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		approved No    
S3‑171537 Reply to: LS on LI requirements for CIOT services including BEST services Vodafone LS out approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No    
S3‑171538 draft TSxx.xxx BEST v0.0.2 - BEST TS including S3-171093 as agreed in conf calls VODAFONE Group Plc other Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No   S3‑171094
S3‑171539 pCR to S3-170916 - Change to Key Hierarchy KPN, Nokia other Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No   S3‑171356
S3‑171540 Liaison Statement to 3GPP SA3: GSMA Activity on Securing Diameter Interfaces GSMA FASG LS in discussion
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171541 BEST TS 33.xyz Section 4.4.4 - Key Refresh Nokia,China Mobile other -
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		approved No   S3‑171442
S3‑171542 Allocation of FC values for BEST KPN, Vodafone CR Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
YesThe CR will be revised during the SA plenary to introduce the TS number once the BEST WID is approved.
 		agreed No   S3‑171432
S3‑171543 Cover sheet TS BEST specification Vodafone TS or TR cover Approval
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
YesIt will be revised during the SA plenary to introduce the TS number once the BEST WID is approved.
 		approved No    
S3‑171544 Interim Agreement Proposal for IMSI privacy Huawei, Hisilicon pCR Approval
8.3.7Subscription privacy
 		No
Yes
 		left for email approval No   S3‑171196
S3‑171545 Authentication procedure for EPS AKA* - possible variant Nokia,Ericsson pCR -
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171376
S3‑171546 pCR to 33.899: Updates to Key Issue #7.1 Intel pCR Approval
8.3.7Subscription privacy
 		No
Yes
 		left for email approval No   S3‑171267
S3‑171547 Changes to Security Key Update Intel, Qualcomm Incorporated, Nokia, Samsung CR Approval
7.6.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑171271
S3‑171548 Question on synchronization and recovery - was 764 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesContaining the agreed question
 		approved No   S3‑171303
S3‑171549 Questions for Key issue #7.2: Storage and configuration of key related to encryption of permanent identifiers Ericsson pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171133
S3‑171550 Question to concealment of temporary identifiers - was 765-456 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesEricsson disagreed with the way that their question from 7.4 was integrated here. Ericsson will bring a contribution for the next meeting to address their concerns for question (1).
 		approved No   S3‑171298
S3‑171551 Question to slice identifier protection - was 767-204 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171301
S3‑171552 Agreement to slice identifier protection Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171302
S3‑171553 Solution variant to 7.3 based on encrypted IMSI only - was 757 Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171305
S3‑171554 reply LS on LTE call redirection to GERAN Ericsson LS out Approval
7.6.1SAE/LTE Security
 		Yes
Yes
 		approved No   S3‑171129
S3‑171555 Alignment of LWIP to stage 3 Ericsson CR Approval
7.6.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑171135
S3‑171556 Questions and interim agreement for key issue #1.7 on key hierarchy related to core network keys Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171287
S3‑171557 Additional privacy related questions for security visibility and configurability - related to S3-170852 Nokia pCR Decision
8.3.11Security visibility and configurability
 		No
Yes
 		left for email approval No   S3‑171307
S3‑171558 Questions and agreements for key issue #1.7 on key hierarchy related to NAS security Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171286
S3‑171559 Questions and agreements for key issue #1.7 on key hierarchy related to the access network and air interface protection keys Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171289
S3‑171560 Question and interim agreement for co-location of the SCMF and the SEAF Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171415
S3‑171561 Question and Interim Agreements on Key Issue # 1.3: User plane integrity between UE and network Samsung pCR -
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171316
S3‑171562 Questions and interim agreements on the granularity of the UP protection (KI #1.16) Ericsson pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171279
S3‑171563 Interim Agreement for KI1.18 Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesRemoving any reference of the solution for KDF negotiation as proposed by ORANGE. Agreement is TBD.
 		approved No   S3‑171242
S3‑171564 Interim agreement on DoS KPN pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171386
S3‑171565 N3gpp access merged Call flow Nokia, Qualcomm, Intel, Huawei, Broadcom pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171341
S3‑171566 N3GPP access key issue and agreement Nokia, Qualcomm, Intel, Huawei, Broadcom pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171344
S3‑171567 agreement on support ERP Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		approved No   S3‑171213
S3‑171568 LS On Clarifications on false eNB detection to RAN groups Nokia LS out Approval
8.3.4RAN security
 		Yes
Yes
 		approved No   S3‑171407
S3‑171569 Questions and interim agreements for KI #4.5, KI #4.6, KI #4.9, KI #4.12, KI #4.15, KI #4.16, KI #4.17 Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		left for email approval No   S3‑171153
S3‑171570 Conclusion and interim agreements for KI # 4.11 & 4.15 Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		approved No   S3‑171188
S3‑171571 Update of KI #4.4 and questions and agreements on KI #4.4 Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		approved No   S3‑171146
S3‑171572 Conclusion and interim agreements for KI# 4.4 and KI #4.7 China Mobile pCR Approval
8.3.4RAN security
 		Yes
Yes
 		approved No   S3‑171160
S3‑171573 Key issue update, questions and agreements for key handling in state transition from RRC_INACTIVE state to RRC_CONNECTED state Ericsson pCR Approval
8.3.4RAN security
 		Yes
Yes
 		approved No   S3‑171145
S3‑171574 Reply to: Liaison Statement to 3GPP SA3: GSMA Activity on Securing Diameter Interfaces KPN LS out approval
7.4Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171575 The skeleton of TR 33843 Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171221
S3‑171576 Draft TR 33.843 Huawei draft TR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		No
Yes
 		left for email approval No    
S3‑171577 The scope of TR 33843 Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		No
Yes
 		left for email approval No   S3‑171223
S3‑171578 key issue authentication and authorization Huawei, Hisilicon, China Mobile pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesMCC pointed out that better than mentioning SA1,SA2 and Rel-13 Prose, Rel-15 Prose and so on, there should be references to the referred documents and avoid mentioning working groups or Releases. Added an editor's note for alignment with TS 33.303.
 		approved No   S3‑171224
S3‑171579 New Key Issue on AKA via eRelay KPN pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171411
S3‑171580 New Key Issue on attach via eRelay KPN pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171412
S3‑171581 key issue security on discovery Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171226
S3‑171582 key issue security of UP between eRemote UE and network Huawei, Hisilicon pCR Approval
8.5Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171227
S3‑171583 draft TR 33.899 Ericsson draft TR Approval
8.3.18Other
 		No
Yes
 		left for email approval No