Tdoc List

2017-08-11 15:40

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑171700 Agenda WG Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No    
S3‑171701 Report from SA3#87 MCC report  
4.1 Approval of the report from SA3#87
 		Yes
YesFirst action item was not done (conference call by Nokia) and it will be carried out after the current meeting. China Mobile had held the conference call for the second action item: two contributions were discussed (by China Mobile and KPN). Some open issues with the NAS security when using the USIM. There were input documents for this meeting dealing with this topic.
 		approved No    
S3‑171702 SA3 Work Plan MCC Work Plan  
9Review and Update of Work Plan
Yes
Yes
 		noted No    
S3‑171703 Report from last SA meeting WG Chairman report  
4.2Report from SA #76
 		Yes
YesAlf (NTT-Docomo) attended the meeting as vice-chairman since Anand wasn’t available. Verizon asked about the LS from SA2 about emergency calls for Rel-15. Does this apply for specific deployments?This was taken offline. Vodafone thanked Alf for the effort on having the BEST TS approved in the meeting.
 		noted No    
S3‑171704 SA3 meeting calendar MCC other  
10Future Meeting Dates and Venues
 		Yes
YesDates 2019: Vodafone commented that co-locating with SA2,SA1 would make it more inefficient since it was better to meet after them. The Chair commented that the dates were not fine with SA3 and that more discussions would be needed. This will be the answer sent to the SA Chair. February 2018 location will be San Diego (hosted by Qualcomm).
 		noted No    
S3‑171705 Work Plan input from Rapporteurs MCC other  
9Review and Update of Work Plan
Yes
Yes
 		revised No S3‑172074  
S3‑171706 Reply LS on UE-to-NW relaying S2-170398 LS in  
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171707 LS on PC5 Secure Communication S2-171621 LS in  
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171708 LS on Closed Subscriber Group in 5GS S1-172425 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171709 Reply LS on eDRX Configuration and IMSI-paging C1-172392 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑171710 Reply LS on FEC and ROHC for mission critical services over MBMS C3-173315 LS in  
7.5Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171711 LS on Security for T8 interface C3-173330 LS in  
6.13GPP Working Groups
 		Yes
YesHuawei had a discussion paper on the subjexct in tdoc 1877, and a Study Item to support it. They were discussed as well and a reply was drafted.
 		replied to No    
S3‑171712 Reply LS on eDRX Configuration and IMSI-paging C4-173312 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑171713 Middlebox Security ETSI TC CYBER LS in  
6.9TC-CYBER
 		Yes
YesNokia commented that IETF is involved as well and that they are not keen on some topics of Middle Box security. Alex (BT) Commented that TC CYBER will respond to IETF in an LS.
 		postponed No    
S3‑171714 LS to NGMN and ISG MEC regarding law enforcement requirements in MEC ETSI TC LI LS in  
6.11Other Groups
 		Yes
Yes
 		noted No    
S3‑171715 LS on LI requirements for CIOT services including BEST services ETSI TC LI LS in  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
YesVodafone: They have confused using BEST in a roaming scenario. It was postponed together with the SA3-LI LS.
 		postponed No    
S3‑171716 Reply LS on security for RLF for DoNAS Ues R2-1705939 LS in  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		noted No    
S3‑171717 LS reply to CT1 on GERAN redirection R2-1706149 LS in  
7.6.1SAE/LTE Security
 		Yes
YesSuresh (Nokia) commented that LTE call redirection could be discussed in the conference call. Ericsson commented that in 7.6.1 there were two documents dealing with this issue for the current meeting, so this would be discussed later.
 		noted No    
S3‑171718 LS on encrypting broadcasted positioning data R2-1706150 LS in  
7.6.1SAE/LTE Security
 		Yes
YesNokia commented that this work is scheduled for March 2018 and that could be treated in SA3's next meeting. There are documents in 7.6.1 dealing with this issue.
 		replied to No    
S3‑171719 LS to SA3 on Counter Check Procedure and SCG SRB integrity check failure R2-1706161 LS in  
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171720 Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity R2-1707496 LS in  
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171721 LS reply on NR security input parameters R2-1707498 LS in  
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171722 LS to SA3 on security keys in EN-DC and actions upon DRB IP check failure R2-1707501 LS in  
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171723 Reply LS on Closed Subscriber Group in 5GS RP-171479 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171724 Reply LS on the support of Unicast and Groupcast transmission over PC5 for eV2X S2-173610 LS in  
7.6.20Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		noted No    
S3‑171725 LS on Security Aspects Related to IOPS network with Limited Backhaul S2-174071 LS in  
7.6.10Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)
 		Yes
YesVodafone: do we need a WID for this? The Chair commented that it depended on the amount of work. If they are small changes, no need for it. ORANGE: the macro network HSS wasn't covered by the study in SA3. The LS was postponed for the next meeting.
 		postponed No    
S3‑171726 Reply to LS on State of SA3 discussions on NG security architecture S2-174073 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171727 Reply LS on external interface for TV services S4-170725 LS in  
7.6.7Multimedia Broadcast/Multicast Service (MBMS)
 		Yes
YesThere are some contributions dealing with this in 7.6.7.
 		replied to No    
S3‑171728 LS on secure platform requirements SP-170581 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE saw several problems with the definitions given in the CR for the SA1 TS. Besides, the requirement for 3GPP subscription credential is much wider in SA3. SA3 should send a LS to SA1 pointing out this. Vodafone commented that they had offered this CR, but personally, Tim commented that giving security terms and solutions in a SA1 specification seems to be very strange.Tim preferred that SA1 referred to a SA3 specification or to 21.905. Ericsson: the SA1 TS doesn’t belong to any phase. It's ok to specify these terms, we are going towards that direction anyway. Oberthur: SA1 decided already not to refer to SA3 specs in this case. Vodafone: SA plenary didn’t agree with SA1 and that was the reason why the CR was not accepted. Oberthur: if we do nothing, this will be a maintained working assumption. The plenary asked to finalise the work, so the requirement cannot be removed. If it is removed, the work won’t be complete. ORANGE commented that SA1 and SA3 should coordinate, so the result is to remove this requirement.
 		replied to No    
S3‑171729 Reply LS to IEEE 802.11 Requesting Status and Information on WLAN integration in 3GPP NextGen System SP-170585 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171730 Response LS on Support for fake gNB detection mechanisms R1-1711997 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: we can’t decide which way to go since RAN2 hasn’t replied, only RAN1. It was decided to wait for RAN2's work.
 		noted No    
S3‑171731 LS on 5G Registration via Untrusted Non-3GPP Access S2-174887 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171732 LS on Impacts of using User Identity confidentiality S2-175263 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		replied to No    
S3‑171733 LS on PLMN and RAT selection policies for roaming S2-175286 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE asked to postpone the LS until an answer is reveiced from CT1. Vodafone: this exists already. SA1 will challenge it. BT: the big issue is how to identify securely identify the beacon that tells us in which network we are in. Vodafone: this is about the network being able to move their subscribers for commercial reasons. Ericsson preferred to wait for the SA2 procedure before making a decision. The LS was postponed.
 		postponed No    
S3‑171734 LS reply on NAS SM integrity protection S2-175289 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171735 Reply LS on 5GS Security aspects seeking resolution S2-175309 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesQualcomm: we need to discuss the second requirement on the inclusion of NSSAI in unprotected RRC signallling. There weren't any agreements on this issue so the LS was postponed. Ericsson commented that SA2 will complete their LS for their next meeting.
 		postponed No    
S3‑171736 Modification and resolution of Editor's Note of Key Issue #1 KPN,Huawei,HiSilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171737 Modification and resolution of Editor's Note of Key Issue #2 KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑172156  
S3‑171738 Clarification of Key Issue #3 KPN,Huawei,HiSilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesIt was agreed to add an editor's note on permanent identities and authorization as proposed by NCSC. They were worried about the possibility of the creation of a chain where the eremote UE is another relay.
 		revised No S3‑172157  
S3‑171739 New Key Issue on Service Continuity KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesNokia: add an editor's note on these service continuity scenarios being considered in RAN2 and SA2. Ericsson agreed.
 		revised No S3‑172158  
S3‑171740 New Solutions for Security Service Continuity KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171741 New key issue on authentication of eRelay-UE KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171742 New key issue on protection of UP between eRemote-UE and eNB KPN,Huawei,HiSilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesNokia: If the PC5 is protected since Rel-12, do these threats apply? KPN: this only applies between UE and eNB.
 		approved No    
S3‑171743 New solution on authentication of eRemote-UE via eRelay-UE KPN,Huawei,HiSilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171744 New solution on authentication of eRelay-UE KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171745 New solution on protection of UP between eRemote-UE and eNB KPN,Huawei,HiSilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171746 Discussion document on the LS from TC CYBER regarding BEST VODAFONE Group Plc discussion Information
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		No
No
 		withdrawn Yes    
S3‑171747 Collection of changes to BEST TS as a result of implementations VODAFONE Group Plc CR Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		revised No S3‑172139  
S3‑171748 Disscussion on issues found during implementation of BEST and their fixes VODAFONE Group Plc discussion Information
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
Yes
 		noted No    
S3‑171749 Draft skeleton document for TR on Long Term Key Update (LTKUP) following conf calls VODAFONE Group Plc draft TR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
YesORANGE: adding key issues without content? I'd rather treat the content before having a skeleton advancing empty clauses that haven't been approved yet. Vodafone: there is content in the following documents. This was approved conditionally. The next version will introduced the agreed modifications.
 		approved No    
S3‑171750 pCR TR33.XXX LTKUP - update to sections 4 5 and 6 as discussed on conf calls VODAFONE Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑172160  
S3‑171751 pCR to TR 33.xxx - LTKUP - re-organisation of Key issues section into Key Issues and evaluation criteria VODAFONE Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑172161  
S3‑171752 pCR to TR 33.xxx - LTKUP - addition of key issue content VODAFONE Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
YesGemalto: Don’t use the term SIM, use the term UICC. Gemalto: remove key issue on OTA Keys exposed. ORANGE supported this and it was agreed.
 		revised No S3‑172162  
S3‑171753 pCR to 33.xxx - LTKUP - addition of evaluation criteria VODAFONE Group Plc other Approval
8.5.6Other study items
 		No
No
 		withdrawn Yes    
S3‑171754 pCR to TR33.xxx - LTKUP - addition of soultion - multiple long term keys VODAFONE Group Plc other Approval
8.5.6Other study items
 		No
No
 		withdrawn Yes    
S3‑171755 pCR to 33.xxx - LTKUP - addition of solution - Diffe-helman key negotiation VODAFONE Group Plc other Approval
8.5.6Other study items
 		No
No
 		withdrawn Yes    
S3‑171756 pCR to 33.xxx - LTKUP - addition of a solution - eSIM VODAFONE Group Plc other Approval
8.5.6Other study items
 		No
No
 		withdrawn Yes    
S3‑171757 proposed response LS to RAN2 - LS to SA3 on security keys in EN-DC and actions upon DRB IP check failure VODAFONE Group Plc LS out Approval
6.13GPP Working Groups
 		No
No
 		withdrawn Yes    
S3‑171758 Interim agreement for protecting anchor key for primary authentication ZTE Corporation pCR Approval
8.3.3Security context and key management
 		Yes
YesORANGE: integrity protected instead of "tampering". BT argeed. It was agreed to modify the question to use "confidentiallity and integrity protected".
 		revised No S3‑172102  
S3‑171759 Lightweight secure way for protecting anchor key transmitting - EAP-AKA’ ZTE Corporation pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia, NTT-Docomo didn’t agree with the document, especially on the AUSF computing the generated encoding key that is described here. China Mobile agreed with this being a lightweight solution. They have contribution 935 related to this one. Ericsson didn’t see how this worked. Both documents were noted.
 		noted No    
S3‑171760 [MCSec] 33180 CR Ambient listening and viewing Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑171761 [MCSec] 33180 CR Broadcast and emergency security Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		revised No S3‑172113  
S3‑171762 [MCSec] 33180 CR Group Regroup fix Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		merged No S3‑172108  
S3‑171763 [MCSec] 33180 CR IdM token exchange fix Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
No
 		withdrawn Yes    
S3‑171764 [MCSec] 33180 CR IdM token response fix Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑171765 [MCSec] 33180 CR token revocation Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑171766 [MCSec] 33180 CR User location security Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
No
 		withdrawn Yes    
S3‑171767 [MCSec] 33180 CR Video push and pull Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑171768 TCG progress report InterDigital, Inc. other Information
6.7TCG
 		Yes
YesAlec (Interdigital) gave an update on the work of TCG.
 		noted No    
S3‑171769 Questions and interim agreements for KI #8.3-Slice Authentication CATT pCR Approval
8.3.8Network slicing security
Yes
YesORANGE: no slice authentication in phase one.
 		noted No    
S3‑171770 Questions and interim agreements for KI #8.3-NSSAI Security CATT pCR Approval
8.3.8Network slicing security
Yes
Yes
 		noted No    
S3‑171771 Questions and interim agreements for KI #8.2-Security Differentiation CATT pCR Approval
8.3.8Network slicing security
Yes
YesSupported by ORANGE.
 		approved No    
S3‑171772 Evaluation for Network Slicing Security Solution #8.14 CATT pCR Approval
8.3.8Network slicing security
Yes
Yes
 		noted No    
S3‑171773 Support of 256-bit Keys and Algorithms in 5G AT&T, US Dept. of Commerce, Interdigital, MITRE discussion Decision
7.6.21Other work items
 		Yes
YesORANGE: Do we move completely to the new lengths or we will have coexistence of them? Interdigital: there will be coexistence. Gemalto: which release is this heading to? AT&T: Rel-15 for the study and normative in Rel-16. Gemalto: the result of the study will be for phase two then. Vodafone: the study item should be extended to Rel-16, given the load of work. Both study and normative can be done in parallel. CCSA supported the study. Vodafone commented that the work can be sped up with conference calls in order to involve SAGE as soon as possible. NTT-Docomo: 48 bytes for the PDU in PDCP seems to be quite a lot of overhead. AT&T commented that this needed to be studied. The companies welcomed the initiative and encouraged to bring a Study Item for the next meeting to be agreed. BT pointed out that the admininistrative procedures in the French government could delay the inclusion of this work in Rel-16. AT&T: the intention is to bring this into the next meeting in Singapore.
 		noted No    
S3‑171774 Discussion paper on redirection to GERAN Qihoo 360 discussion Discussion
7.6.1SAE/LTE Security
 		No
No
 		withdrawn Yes    
S3‑171775 Discussion paper on redirection to GERAN Qihoo 360 discussion Discussion
7.6.1SAE/LTE Security
 		Yes
YesEricsson: why is this warning message added to current Ues? Qi360: changing the software of the UE. BT: a warning message won’t be enough. An emeeting will be created in order to agree on a LS about this issue.
 		noted No    
S3‑171776 Privacy: Storage, processing and provisioning of the HN public key Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDiscussed with 2087 and 2021. Ericsson: The current agreement is that the public key in the tamper resistant component, processing in the ME. Storage not supported, then there would be no privacy. Legacy Ues would be able to be used in this case.
 		revised No S3‑172151  
S3‑171777 Privacy: Skeleton proposal for privacy related sub-clauses Ericsson, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesIt was also commented that privacy is also about personal data of a human being, and this wasn't covered here. Ericsson agreed but they mentioned having this in another contribution. They commented that it was better by starting like this and then mentioning the human factor. Huawei: find a better name for privacy key. ORANGE: privacy key is solution specific. Remove the definition. The Chair commented that it's more than just a key. ORANGE: the definition will be fine if we agree on the Ericsson's solution. We have to agree on that firstly. There were long discussions on the terminology to use: e.g. SUCI, SUPI identifier, etc.. This had to be taken offline.
 		revised No S3‑172150  
S3‑171778 Privacy: Requirements related to SUPI and SUCI Ericsson, Vodafone, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172116  
S3‑171779 Privacy: Text proposal in Clause 5.4 (visibility and configurability) Ericsson, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesIt was agreed to send a LS to SA1 on the privacy aspects of SUPI privacy and 5G-GUTI privacy. Vodafone: the text in 5.4.2 needs rewording. Ericsson: it is taken from 5.4.1. It is existing text. It was agreed to enhance the wording.
 		revised No S3‑172107  
S3‑171780 Privacy: [DRAFT] LS on visibility of privacy aspects Ericsson, Telecom Italia LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171781 Privacy: proposed changes to authentication procedures (6.1.2, 6.1.3) Ericsson, Vodafone, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172117  
S3‑171782 Privacy: proposed content to 6.8.1 (SUPI) Ericsson, Vodafone, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE opposed to having the editor's note on Privacy provisioning. Gemalto went for having only the first sentence in the editor's note. This was finally agreed. Huawei commented that the clause was more about the SUCI than the SUPI. It was decided to find an appropiate title for 6.8.1.
 		revised No S3‑172118  
S3‑171783 Privacy: 5G-GUTI related requirements and security procedures (6.8.2, 5.1, 5.3) Ericsson, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE: the part about the tampering-resistant hardware needs to go away. Gemalto: ECIES, not decided whether it is mandatory or optional. It should go away too. Disagreement on the architecture of AUSF and SIDF in 5.Y.1. This part was removed. Merged with 904.
 		merged No S3‑172115  
S3‑171784 Privacy: proposed content to 6.8.3 (identification procedure) Ericsson, Vodafone, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE: the last note is normative, it shouldn't be a note. Is it a "may" or a "shall"? NTT-Docomo: this may not be required. Qualcomm commented that this is not required and that they had a contribution on this last note. It was an open issue.
 		noted No    
S3‑171785 Privacy: [DRAFT] Reply LS on Impacts of using User Identity confidentiality Ericsson LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171786 Privacy: SUCI format and generation Ericsson, Vodafone pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE: we don’t need to mention the privacy key here, the text remains consistent.
 		revised No S3‑172143  
S3‑171787 Privacy: SUCI null-scheme normative Annex Ericsson, Vodafone pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDeutsche Telekom: in which cases the SUPI doesn’t need to be encrypted? Ericsson: some regulators could ask this. KPN: It should be optional for operators to deploy this. ORANGE: who is deciding to use the new scheme? BT: the LI requirement does not imply the encryption ON/OFF in the air interface. The VPLM's choice is whether to have it on/off and the HPLMN would act on it (procceed to switch off, or drop the session). Interdigital: this scheme is not required. All the comments were captured in editors' notes.
 		revised No S3‑172105  
S3‑171788 Privacy: SUCI ECIES scheme normative Annex Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesBT: is this quantum safe? Vodafone: we discussed before about quantum timescales being an issue. It's not an issue here. It was argued whether this could be optional or mandatory to support. This depended on the conclusions in other contributions. Ericsson: we need feedback from ETSI SAGE. We prpose to send an LS. Nokia: we need feedback from ETSI SAGE before adding this to an annex. Gemalto agreed. It was noted since companies agreed not to include this in the TS until some feedback was received from ETSI SAGE.
 		noted No    
S3‑171789 Privacy: [DRAFT] LS on Security aspects of ECIES for concealing IMSI or SUPI Ericsson LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172106  
S3‑171790 Privacy: Discussion for drafting reply to S2-175309, relates NSSAI privacy Ericsson discussion Agreement
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesBT commented that the concept of slice is not fully understood in SA3, so this should go for phase 2. ORANGE suppported this. Ericsson, Nokia, Oberthur, Intel,KPN, China Mobile, LG,NEC wanted this for phase 2 as well. Interigital, Qualcomm,CATT, Gemalto and AT&T preferred to treat this in phase one. NTT-Docomo: if we don’t do protection in phase one, can we do it in phase two? ORANGE commented that we needed to know what was being protected, and SA3 didn’t have information about that. Nokia: they are still discussing the business models in SA1. Qualcomm: why are SA1 and SA2 including the NSSAI parameter in phase one then?this is puzzling. AT&T: we are defining the 5G core in phase one. This would mean that we would be having slices without security, and this is not acceptable. Nokia: the registration procedure in slicing becomes a very complicated procedure, this is currently being discussed in SA2.
 		noted No    
S3‑171791 Privacy: [DRAFT] Reply to Reply LS on 5GS Security aspects seeking resolution Ericsson LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171792 Proposal for Disabling Legacy Radio Access MITRE, AT&T, Interdigital discussion Discussion
7.6.21Other work items
 		Yes
YesChina Mobile: thye objected to the contribution. This is not work for SA3, it's RAN specific. Vodafone: ability to select RANs is in a SA1 spec. It is right to make statements so other groups can take action. Current phones cannot restrict access to 2G/3G. BT agreed with this. The user should be aware about this. Emergency calls that can be made only in 2G, what happens? Sprint: SA1 will deal with this. It’s related to regulatory aspects. Vodafone: action should be taken in SA1. AT&T was happy with this feedback. Sending an LS to SA1 was agreed.
 		noted No    
S3‑171793 Interim agreement on UP security Huawei & Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesVodafone:if you re-authenticate during a session you are changing the protection. Nokia: the granularity comes down to the radio bearer, cannot apply the policy to all the bearers; it would not be optimal. Ericsson: just put Yes in the interim agreement. ORANGE: this doesn’t help at all,we will have the same discussion in the normative part. Qualcomm supported this. The Chair proposed to not to duplicate topics from the interim agreements in the TR and the TS at the same time. This was agreed.
 		noted No    
S3‑171794 UP integrity protection policy determination solution Huawei & Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No    
S3‑171795 Requirements of security algorithms selection Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDiscusssed with 932.
 		noted No    
S3‑171796 Algorithm Identifier Values Huawei, Hisilicon, CATR, CATT pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesKPN didn't agree with the requirements on individual elements like UE and gN ("shall implement.."). NTT-Docomo preferred the original structure like KPN. Nokia: this needs a proper paper to support this discussion. Better to postpone for the next meeting. Qualcomm: include only what's agreed in the TR (remove the requirements after "0011"). NTT-Docomo queried about having bit patterns. Why do we need this? It is stage 3. It was agreed to keep the bit pattern in order to have more control of this, as proposed by BT and Qualcomm.
 		revised No S3‑172092  
S3‑171797 Key setting during primary authentication Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDiscussed with 922.
 		noted No    
S3‑171798 UP security mechanisms Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172169  
S3‑171799 Interim agreement for PDCP SN refreshment Huawei & Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171800 PDCP SN refereshment solution Huawei & Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171801 Security policy determination Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171802 AKAstar discussion of options 1 and 2 Huawei & Hisilicon discussion Discussion
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesCommented in 2072. BT: this can also apply to 4G. Huawei: The UE not present attack exists in 3G and 4G networks so we should retro fit it to them. Nokia: it doesn’t work given the assumption from the last meeting. KPN: it's only about authentication. The operator drops you to 4G/3G. The attack still happens. It might not be needed. Interdigital: how's the complexity increased? Huawei: compared to EAPS-AKA, the interface between the UE and ASF doesn't change.Compared to EAPS-AKA*, no hashes in option 1. Option 2 is comparable, roughly the same as EAPS-AKA*. Nokia asked whether some other company felt the need to change the current solution in the TS. Either way seemed to be fine for the rest. Huawei commented that the purpose was to have a working agreement and bring a pCR for the next meeting. The documents were noted; the Chair welcomed more input for the next meetings to continue the discussions. Huawei proposed to have a conference call on this topic in 2072 and 802, chaired by Qualcomm. This was agreed.
 		noted No    
S3‑171803 AKAstar pCR for option 1 Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171804 AKAstar pCR for option 2 Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171805 DN authorization grant and revocation Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171806 ID linkage verification in secondary authentication Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171807 Secondary authentication for multiple PDU sessions Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171808 Discussion paper on slice authentication Huawei & Hisilicon discussion Approval
8.3.8Network slicing security
Yes
YesORANGE: no phases in SA1, so slice authentication doesn’t fit right now in phase one of the SA3 work. Huawei: secondary authentication is mandatory. ORANGE: this is specific to some use cases. Huawei: we haven't agreed on anything about this topic yet. We need authentication after primary authentication. ORANGE: this is not needed and it has been discussed several times. Gemalto: other groups are working in slicing, we cannot skip them. ORANGE: slice specific authentication is not being considered in the other groups. Gemalto and China Mobile supported the proposal of having the slice authentication. Ericsson didn’t see that this fit anywhere. Who will be doing this authentication on behalf of the operator? The operator itself to access their own slices after the primary authentication? ORANGE: there is no assumption in SA2 for phase one in the slice authentication topic. The Chair commented that he wasn't sure about having slice authentication for SA3's phase one.
 		noted No    
S3‑171809 Interim agreements for KI8.3 Huawei & Hisilicon pCR Approval
8.3.8Network slicing security
Yes
Yes
 		noted No    
S3‑171810 Interim agreement for KI8.2 Huawei & Hisilicon pCR Approval
8.3.8Network slicing security
Yes
YesVodafone: waste of time since this is phase two material.
 		noted No    
S3‑171811 New SID on security aspect of 5G network slicing provisioning Huawei, Hisilicon, ZTE, CATR, CATT,China Mobile,China Unicom SID new Agreement
8.5.6Other study items
 		Yes
YesNokia: we approved a WID in 2075 about this on Northbound API security. Huawei: that is not an interface in the management plane. Huawei: the list of participants in this document is not correct. ORANGE: exposure to third parties is not clear. Huawei agreed to refine this. ORANGE added that external work can be added in the objectives without mentioning the other 3GPP groups. The Chair commented that December 2017 was too ambitious given the current workload. Besides, ORANGE mentioned that there was no meeting before September 2017 so presenting this for information was impossible. ORANGE: we are bound to other work items, we may have to wait for their results and delay the work.
 		revised No S3‑172179  
S3‑171812 Security procedure for EAP-TLS Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑171996  
S3‑171813 Discussion on LS R2-1706150 encrypting positioning data Nokia discussion Discussion
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑171814 Discussion on i/c LS R2-1706151 ENDC Security Nokia discussion Endorsement
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171815 pCR to 33.899 Security solution for SMS over NAS Nokia pCR Approval
8.3.1Security architecture
 		Yes
YesIt was proposed to carry on without the evaluation due to the lack of time for discussions.
 		revised No S3‑172184  
S3‑171816 Question and Interim Agreement on authentication of the user Alibaba (China) Group., Ltd. pCR Approval
8.3.2Authentication
 		Yes
YesORANGE: who's the user? How does it impact the core network? I don’t agree with the biometric authentication. Alibaba: the original conclusion was TBD. Vodafone: we already have authentication of the user. The question should have been about additional authentication mechanisms in phase one. The asnwer was TBD. The origiinal question is wrong, misleading. Vodafone didn't agree with the document and admitted that the original agreed question was poor. BT: this implies creating a database for biometric data and it implies a higher seccurity risk. Locally is fine, but trying to centralise it would be risky. Alibaba: there are solutions available to solve the high security risk of having a centralised database. Vodafone: we might consider it for phase two, but we don’t have a SID for phase two yet.
 		revised No S3‑172101  
S3‑171817 Updating security threats, requirements and solutions on key issue #2.8 Alibaba (China) Group., Ltd. pCR Approval
8.3.2Authentication
 		Yes
YesNokia: totally new authentication framework. We can have it for the phase two study, but not here. Alibaba: we can remove the solution part. ORANGE: if we have the key issue only, I don’t agree.
 		noted No    
S3‑171818 Interim agreements on key issue#4.17 UP integrity Nokia pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		noted No    
S3‑171819 Clause 6.2 NAS Security Nokia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171820 Annex A on Key derivation Nokia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171821 Adding a solution on key issue #2.8 Alibaba (China) Group., Ltd. pCR Approval
8.3.2Authentication
 		No
No
 		withdrawn Yes    
S3‑171822 Potential key hierarchy in 5G phase 1 Huawei & Hisilicon pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171823 update gNB security requirement Huawei, Hisilicon, China Mobile pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171824 Updates security handling in mobility Huawei, Hisilicon, Deutsche Telekom AG pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171825 Update Interim Agreements for RAN KI # 4.11 & 4.15 Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
YesEricsson: On the third change, this is overlapping with an agreement that we had earlier. HO will follow the LTE procedure. We didn’t agree with pushing it forward.We can improve it during the normative phase. Fourth change: the response should be TBD as it was before.
 		revised No S3‑172103  
S3‑171826 Deleting EN on MASA handling OUT of Sequence Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		approved No    
S3‑171827 Conclusion for generation effective temporary or short-term subscription identifiers Huawei, Hisilicon, China Mobile pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171828 Update solution 2.11 for KI 1.21 Huawei, Hisilicon pCR Approval
8.3.2Authentication
 		Yes
YesNokia: it is not solving the issue that is being raised. Qualcomm agreed.
 		noted No    
S3‑171829 Conclusion and Comparison of Xn handover solutions Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		noted No    
S3‑171830 UE sends SEAF Concealed IMSI during Primary Authentication Huawei, Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE: we are encrypting IMSI again, this has been encrypted already. NAS encryption enabled will do it. Huawei: when NAS encryption is disabled, we need to encrypt it. ORANGE: in that case we don’t care about privacy. Ericsson: this annex is too complex. No one agreed with this contribution.
 		noted No    
S3‑171831 Interim agreements for forward security during handover Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesVodafone: forward security mechanism is ambiguous. Nokia: add a reference to the LTE document where this is defined.
 		revised No S3‑172094  
S3‑171832 Interim Agreement to Key Issue #1.5 and #1.6 Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesQualcomm: SMS over NAS will be integrity and confidentiality protected by default. Is this before you activate NAS security? Huawei: yes, this is the case. Qualcomm agreed but proposed to reword the questions. Ericsson: There are cases with security context where there is only integrity protection.This needs to be mentioned. Nokia: already defined in 33.502, this is not needed. Vodafone: not clear how far the integrity protection is going, between the UE and the NAS. It was agreed to refine the wording to address these comments.
 		revised No S3‑172093  
S3‑171833 pCR to 33.501: Security Aspects of SMS over NAS Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172170  
S3‑171834 pCR to 33.501: Initial NAS security algorithm establishment Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		merged No S3‑172172  
S3‑171835 pCR to 33.501: NAS algorithm handling when AMF change Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		merged No S3‑172172  
S3‑171836 pCR to 33.501: NAS security mode command procedure Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		merged No S3‑172172  
S3‑171837 Discussion on DRB integrity protection check failure Huawei; Hisilicon discussion Discussion
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171838 Discussion on flexibility of retaining or changing AS security key Huawei; Hisilicon discussion Discussion
8.3.4RAN security
 		Yes
Yes
 		noted No    
S3‑171839 Draft LS on Discussion on flexibility of retaining or changing AS security key Huawei; Hisilicon LS out Approval
8.3.4RAN security
 		Yes
Yes
 		noted No    
S3‑171840 Discussion on the handling of NR security capability Huawei; Hisilicon discussion Discussion
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171841 Correction to living document of S3-171487 Huawei; Hisilicon other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		merged No S3‑172149  
S3‑171842 update solutrion #1.40 Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No    
S3‑171843 interim agreement for KI#1.8 Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesORANGE: this is already existing. Huawei: no agreement whether the public key is needed. Vodafone: No need to have interim agreements that are in the TS already, this increases the number of documents.
 		noted No    
S3‑171844 interim agreement for KI#7.2 Huawei; Hisilicon pCR Approval
8.3.7Subscription privacy
 		Yes
YesVodafone: it shall be stored in one or the other. TBD if stored in the ME. ORANGE: we don't know how to provision the ME with the public key yet. China Mobile: storing in the ME is fine with us. BT: do we want to rule out legacy from this feature? Vodafone: there are no standards for provisioning handsets. The ones proposed in OMA are not used. Ericsson: there are contributions about this in the TS.
 		noted No    
S3‑171845 interim agreement for KI#2.4 Huawei; Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		revised No S3‑172100  
S3‑171846 pCR to 33501_some editoral revisions Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171847 interim agreement for E.1.7.2 Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesNokia: the forward security part will bring significant changes. You can always do re-authentication, so it is not needed. I'm fine with backward security. Ericsson and China Mobile supported Nokia with this. Qualcomm objected to having only backwards security. This was left open depending on decisions made in the normative part.
 		noted No    
S3‑171848 UP Security on gNB internal interface Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		No
Yes
 		revised No S3‑171895, S3‑171900  
S3‑171849 configuration and visibility features in TS 33.401 should be reused in 5G. Huawei; Hisilicon pCR Approval
8.3.11Security visibility and configurability
 		No
Yes
 		revised No S3‑171897  
S3‑171850 gNB shall support certificate enrolment in TS 33.310 Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		No
No
 		withdrawn Yes    
S3‑171851 draft CR TR 33.926 eNB Annex Huawei; Hisilicon draftCR Approval
8.5.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		Yes
Yes
 		approved No    
S3‑171852 draft CR TR 33.926 PGW Annex Huawei; Hisilicon draftCR Approval
8.5.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		Yes
YesEricsson: P-GW app and P-GW software difference? MCC queried about referencing to Rel-8 TS 24.401. BT also had their doubts on having to reference to Rel-8 only.
 		approved No    
S3‑171853 GBA use in LTE V2X Huawei; Hisilicon draftCR Approval
7.6.20Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
YesThis should have been a CR, so a new tdoc was given to include this content.
 		noted No    
S3‑171854 eNB SCAS TS Huawei; Hisilicon pCR Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No    
S3‑171855 Update interim agreement in section E.1.11 Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
YesORANGE: it's confusing what is happening in SA2 in this topic. Deciding to go for the service based architecture will have an impact on the timeline of the work. Ericsson: they are already considering REST based protocols, and Diameter. We may need to do something more, as Huawei proposes. China Mobile supported Huawei. We may face different security problems in this case. ORANGE wasn't sure about how the work with SA2 was going to be carried out. Maybe an LS is needed. Huawei: maybe a study would be more appropiate.
 		approved No    
S3‑171856 Update interim agreement in section E.4.6.12 Huawei; Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		noted No    
S3‑171857 Clarification on authentication method selection in AUSF Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: we are having discussions for non-3GPP accesses. It is possible that EPS AKA* will also go for non-3GPP accesses as currentlty discussed in SA2. Add an editor's note about this. Qualcomm: we have an interim agreement, don’t add the editor's note now. NTT-Docomo: why are we having these requirements here instead of in a requirements clause? It was decxided to postpone it.
 		postponed No    
S3‑171858 update the skeleton of TS 33.501 Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesThe content depends on the reply from the LS to SA2 on the service architecture.
 		postponed No    
S3‑171859 Update intrim agreement for section E.4.17 Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		noted No    
S3‑171860 Discussion on non-3GPP solutions Huawei; Hisilicon discussion Discussion
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171861 Discussion on Radio Access network protection Huawei; Hisilicon discussion Discussion
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEricsson: can we agree on the integrity activation for this meeting and continue on the next? Algorithms and confidentiality would go for the next meeting. Nokia mentioned the agreed points in the evening sessions: - How to activate integrity confidentiality. - Granularity. - Integrity should be subject to the process, it's open whether the confidentiality too. - Use of algorithms should be flexible? It was proposed to fix these topics into a document that could be agreed as the next step forward: 164
 		noted No    
S3‑171862 Initial AS security context establishemt Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171863 Procedures for Radio security Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171864 Draft LS reply S2-174887 Huawei; Hisilicon LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171865 move non-3GPP solution from TR 33.899 to TS 33.501 Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171866 Discussion on the third key used for common PDCP Huawei; Hisilicon pCR Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesEricsson: the fact that the option one is not secure, or that they plan to use two keys, it's Huawei's interpretation but not what RAN2 implies. Ericsson: SgNodeB does not transfer any key from the MeNodeB.
 		noted No    
S3‑171867 Draft LS reply R2-1707501 Huawei; Hisilicon LS out Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171868 AS Security Mode Command Procedurey Huawei; Hisilicon pCR Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		revised No S3‑172126  
S3‑171869 Bidding down prevention in X2-handovers Huawei; Hisilicon pCR Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		revised No S3‑172127  
S3‑171870 AS Protection algorithm selection in eNB change Huawei; Hisilicon pCR Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No    
S3‑171871 pCR to TS 33.501 Clause 12.1.2: Resolve EN on Normative language Nokia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171872 pCR to TS 33.501 - Resolve 2nd and 3rd ENs in clause 12.1.2 on Secondary authentication Nokia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171873 pCR to TS 33.501 clause 12: Update text with Service operations used to carry EAP messages Nokia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171874 CR to 33.402: Clarification on Unauthenticated Emergency services over untrusted WLAN Nokia CR Agreement
7.6.1SAE/LTE Security
 		Yes
Yes
 		agreed No    
S3‑171875 A security solution for service based architecture Huawei, Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171876 Soltuion for 5G initial NAS message protection Huawei, Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No    
S3‑171877 Discussion on security of SCEF Northbound API interfaces Huawei, Hisilicon discussion Discussion
7.6.9Security Aspects related to Machine-Type Communication ((e)MTC)
 		Yes
Yes
 		noted No    
S3‑171878 New WID for Northbound APIs Security for SCEF - SCSAS Interworking (NAPS_Sec) Huawei, Hisilicon WID new Agreement
7.6.9Security Aspects related to Machine-Type Communication ((e)MTC)
 		Yes
YesEricsson pointed out that the discussion proposes a study but this is a work item proposal. Huawei commented that this is a short WID and that’s the intention. Ericsson supported this. BT commented that the scope misses security functions that pass on the interface. Not clear whether this is for Rel-15/ 5G. Status of the underliying 3GPP access network to be inclluded in the scope in order to support this WID. Nokia commented that the dates proposed were wrong (they don’t show SA dates and what it shows in SA3 dates is very unrealistic). Vodafone commented that the entities to be secured need to be identified: what do they mean with "users" here? The scope needs to be more specific. MCC commented that the output should be CRs impacting TS 33.187. The wrong table was filled up. MCC commented that in section 8 no 3GPP working groups should be added since the will not be involved in the SA3 WID work.
 		revised No S3‑172075  
S3‑171879 GSMA eUICC based solution for LTKUP Huawei; Hisilicon pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
YesORANGE: confirm the descriptions with GSMA (SGP.22). Add an editor's note about this. Vodafone: is it OK to reference to a GSMA document? Copyright issues and so on. It was confirmed that SGP.22 was a GSMA public document so it was correct to reference to it. MCC commented that the paragraph "In the latest version of SGP.22 when drafting this TR,.." should be removed as no mentioning of the time when the spec was drafted should be put into a specification. Vodafone agreed to replace it with a reference to SGP.22 as Rapporteur's work.
 		revised No S3‑172163  
S3‑171880 Revised eUICC solution for LTKUP Huawei; Hisilicon pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
YesORANGE and BT objected to this document. Vodafone: it is described as a GSMA solution that doesn't exist. Nokia: isn’t it correct in a 3GPP study to take a GSMA solution and propose a modification? Vodafone disagreed with this. KPN agreed with Vodafone. MCC commented that they felt uncomfortable with taking a solution from GSMA and modifying it.Mirko would check this internally. Vodafone: create a solution and don’t mention GSMA. NTT-Docomo: outcome of the study could go to GSMA and propose a modification. There was no agreement and the document had to be noted.
 		noted No    
S3‑171881 Reply LS on LI Requirements for CIoT services including BEST services S3i170239 LS in  
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		Yes
YesBT: End-to-end media IMS could apply here. Verizon: just have integrity protection in this situation. KPN: we would be happy to transport data for Vodafone. No need to change the service. The regulation in Netherlands is going towards device manipulation. If the UE is moving towards end-to-end encryption we don’t need to act further. Everything can be solved in the roaming agreement. Vodafone: Location of the customer is ON. No impact in LI if running only integrity protection. ORANGE: the LI requirement in the VPLMN needs to be fulfilled without the help of the HPLMN. Vodafone: the VPLMN needs to ask HPLMN not to allow cyphering. We tell the customer that the traffic will not be encrypted in certain countries. We have the tools to know where the customer is and act on it. This is all covered in the TR. ORANGE: TC LI and SA3-LI are not proposing what needs to be done. SA3 doesn’t have the right skills to understand the LI requirements. BT: SA3-LI should not act on the service architecture either. SA3 should give feedback on the way the think it should be done with the minimum impact. Confidentiality is fine enough. Vodafone proposed to have conference calls to discuss the response LS. ORANGE: SA3-LI is meeting before Reno, we need to respond before.
 		postponed No    
S3‑171882 LS on Undetectability of LI Data stored in a UDSF S3i170259 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171883 Address Mapping Requirements S3i170260 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171884 LS on Impacts of using User Identity confidentiality S2-175263 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
No
 		withdrawn Yes    
S3‑171885 Reply LS on 5GS Security aspects seeking resolution S2-175309 LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
No
 		withdrawn Yes    
S3‑171886 Key Issue #11.3: User control of security China Unicom pCR  
8.3.11Security visibility and configurability
 		Yes
YesLG didn’t support this. Ericsson: we should have a proper discussion on this. Vodafone agreed.
 		noted No    
S3‑171887 Key Issue #11.2: User awareness of security China Unicom pCR  
8.3.11Security visibility and configurability
 		Yes
Yes
 		noted No    
S3‑171888 AS algo. initial context (8.1.2.1.1 ) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171889 AS algo negotiation during Xn-handover (8.1.2.1.2) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesAn editor's note was proposed to check with RAN that the procedure on RRC connection reconfiguration detailed here is correct. Huawei commented that it was coming from LTE and that it was reasonable. Another editor's note was added on the mechanism to be verified as well.
 		revised No S3‑172165  
S3‑171890 AS algo negotiation during N2-handover (8.1.2.1.3) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEPS security context has been replaced by 5GS security context. This will be replaced by 5G security context.
 		revised No S3‑172166  
S3‑171891 AS algo negotiation during intra-gNB handover (8.1.2.1.4) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesHuawei: clarfy what is intra-gNB. An editor's note was added for this.
 		revised No S3‑172167  
S3‑171892 AS security mode command procedure (8.1.2.2) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172168  
S3‑171893 Discussion on rogue gNB detection Motorola Mobility, Lenovo pCR Approval
8.3.4RAN security
 		Yes
YesEricsson: the introduction reads as an evaluation.
 		noted No    
S3‑171894 Discussion on 5G Registration via Untrusted Non-3GPP Access Motorola Mobility, Lenovo, Broadcom, Brocade discussion Endorsement
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171895 UP Security on gNB internal interface Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesConfiguration and authentication of gNBs needed to be clarified according to Nokia. This was added in an editor's note.
 		revised No S3‑172177 S3‑171848
S3‑171896 CR for modify the text format of X5.2 in TS 33.203 - R14 Huawei, Hisilicon CR Approval
7.6.21Other work items
 		Yes
Yes
 		revised No S3‑172141  
S3‑171897 configuration and visibilityfeatures in TS 33.401 should be reused in 5G. Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		merged No S3‑172107 S3‑171849
S3‑171898 CR for modify the text format of X5.2 in TS 33.203 - R13 Huawei, Hisilicon CR Approval
7.6.21Other work items
 		Yes
Yes
 		not pursued No    
S3‑171899 CR to 33.501: Privacy of the Subscriber permanent identifier Intel Corporation (UK) Ltd pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
No
 		withdrawn Yes    
S3‑171900 UP Security on gNB internal interface Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: we are adding requirements to an interface that hasn't been standardized. ORANGE: they haven't decided whether to specify this interface. Ericsson: this interface is being specified in RAN.
 		revised No S3‑172178 S3‑171848
S3‑171901 CR to 33.501: Secondary Re-Authentication Intel Corporation (UK) Ltd pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171902 flexible retain key solution Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		approved No    
S3‑171903 Secure paging using scrambling temporary subscriber identifier Intel Corporation (UK) Ltd pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
No
 		withdrawn Yes    
S3‑171904 pCR to TS33.501 - security requirements on subscription identifiers CATT pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesVodafone: configurable by whom? CATT: by the operator. It was agreed to add this. Nokia: why should it be configurable? It doesn’t affect any interoperability scenario. NTT-Docomo: the MNO can decide about the refresh frequency. BT: does the first requirement imply integrity protection mandatory? Ericsson: privacy will be optional for the operator. SUPIs are never sent in clear text. Vodafone and China Mobile agreed. Interdigital: is the whole SUPI or the ID part of the SUPI being sent? It was agreed to have that SUPI should not transferred in clear air text over 5G RAN. Second requirement was removed.
 		revised No S3‑172115  
S3‑171905 pCR to TS33.501 - skeleton and text for slice security clause CATT pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesThe Chair asked the attendees whether slicing was part of phase two.Huawei said phase one, but Vodafone recalled having it for phase two, ORANGE: SUPI privacy has priority. Vodafone: slicing is being considered in other groups and we have been asked about NSSAI by LS.
 		noted No    
S3‑171906 Evaluation for Securing and refreshing the temporary subscriber identifiers. Intel Corporation (UK) Ltd pCR  
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171907 Security Architecture developed by 5G-ENSURE project Ericsson, Telecom Italia, Thales, NEC pCR Approval
8.3.1Security architecture
 		Yes
YesORANGE objected to this. Huawei: it’s not a solution, it’s an annex. Ericsson: this is coming from an EU project, 5G-Ensure, it’s not a solution but information about their work. ORANGE: this is unrelated to our work, no point to have this in our TR. BT agreed with ORANGE.
 		noted No    
S3‑171908 Discussion for PC5 Security between Remote UE and Relay UE Intel Corporation (UK) Ltd discussion  
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171909 Reply LS on PC5 Secure Communication Intel Corporation (UK) Ltd LS out  
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171910 Update diagrams for Securing and refreshing the temporary subscriber identifiers. Intel Corporation (UK) Ltd pCR  
8.3.7Subscription privacy
 		Yes
Yes
 		approved No    
S3‑171911 eRemote-UE Authentication with MITM detection Intel Corporation (UK) Ltd pCR  
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesSony: this is protection for the control plane only, not the user plane. This was agreed. Huawei: the first step in the figure does not correspond to the text. This was agreed to be fixed. Nokia: secure channel in step d? Is it IPSec? An editor's note was added. ORANGE: this is a LTE study item, and you are mentioning gNB. This was agreed to be fixed. ORANGE doubted that this solution was solving the introduced the issue. ORANGE asked to add the assumption that the channel eRemoteUE and eRelay UE is encrypted.
 		revised No S3‑172180  
S3‑171912 LIAISON STATEMENT ON ZUC-256 algorithm CCSA LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171913 pCR to 33.899: Updates to Solution #7.2 Intel Corporation (UK) Ltd pCR  
8.3.7Subscription privacy
 		Yes
Yes
 		revised No S3‑172185  
S3‑171914 Reply LS on security aspects with FEC and ROHC over MBMS S6-171105 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑171915 Resolving two editor’s notes about reuse of Charging ID and TEID China Mobile, Telecom Italia, China Unicom CR Approval
7.1.1Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
YesEricsson agreed with the content but wasn't sure about placing it here. What is the tester doing with this statement?
 		revised No S3‑172123  
S3‑171916 Questions and interim agreements for KI #8.3 China Mobile, China Unicom pCR  
8.3.8Network slicing security
Yes
Yes
 		noted No    
S3‑171917 Q&IA related to the Usability of legacy USIM in key issue #2.1 China mobile, KPN pCR  
8.3.2Authentication
 		Yes
YesVodafone: there may be problems when introducing the 5G core. It is up to us to say whether it will be secure to access 5G services with a legacy SIM, not whether the legacy SIM can be used for 5G services. Vodafone: Rel-8 to Rel-14 would be legacy. Qualcomm: what is the difference between Rel-8 and Rel-99? They are the same.Vodafone disagreed. Splitting security between the handset and the SIM should not be done. Qualcomm objected to distinguishing from Releases since they didn’t understand why Rel-99 couldn’t be used. NTT-Docomo: first question you can use the term LTE USIM. Ericsson commented that they had contributions for the TS that addressed this question.
 		revised No S3‑172099  
S3‑171918 pCR Security enhancement to the attach procedure relying on the public key of the home network China Mobile pCR  
8.3.7Subscription privacy
 		Yes
YesThe evaluation part was removed. It was reminded that contributions that introduce new parts should have revision marks. ORANGE:we are seeing solutions that don’t solve the problems. Nokia also had many issues with this contribution.
 		noted No    
S3‑171919 Clarification of key period calculation Motorola Solutions UK Ltd. CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑171920 [DRAFT] Reply LS to RAN2 on security keys in EN-DC and actions upon DRB IP check failure China Mobile LS out  
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171921 Clarification of security domain parameters and UK-ID Motorola Solutions UK Ltd. CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑171922 Overall presentation of skeleton updates for mapping content under clause 7 in TS 33.401 to clause 8 in TS 33.501 Ericsson discussion Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDiscussed with 931,2038
 		noted No    
S3‑171923 Discussion on the signalling and negotiation of the NR security capabilities Ericsson discussion Endorsement
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171924 Reply LS proposal on algorithm selection in E-UTRA-NR Dual Connectivity Ericsson LS out Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171925 Mechanism for NR security capabilities signalling and negotiation Ericsson other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesNokia: why do we need translation in the eNodeB? Ericsson: we want to avoid SgNB doing some kind of mapping to 5G language. Nokia doubted that a translation would be needed in phase one. Huawei: we need a LTE traditional procedure to support MeNodeB. They supported Nokia. Ericsson:The algorithms in 5G will be different from the ones in 4G, at least they will change in name.
 		noted No    
S3‑171926 Update of clause 6.2 on NAS security Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesDiscussed with 819. NTT-Docomo preferred this version. Both contributions had to be discussed offline.
 		approved No    
S3‑171927 Update of content of clause 6.3 on security negotiation Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesOverlapping with 2033, 1834
 		revised No S3‑172172  
S3‑171928 Update of clause 6.6 on key hierarchy Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171929 Update of clause 6.7 on security contexts Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171930 Update of clause 6.3 skeleton on Security negotiation Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171931 Update for skeleton of clause 8 on Security Procedures between UE and 5G Access Network Functions Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172152  
S3‑171932 Update of clause 5 skeleton on Security Requirements and Features Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesOverlaps with 795. It is aligned with that contribution so this was noted.
 		noted No    
S3‑171933 Update of clause 8.1.1.2 ‘5G-RAN key identification‘ in TS 33.501 Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171934 Update of clause 8.1.1.3 ‘5G-RAN key lifetimes‘ in TS 33.501 Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171935 pCR Security enhancement to the EAP-AKA' China Mobile pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171936 Clarifications and editorial corrections related to SRTCP protection Motorola Solutions UK Ltd. CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		revised No S3‑172114  
S3‑171937 Encryption parameter clarification for group call Motorola Solutions UK Ltd. CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		revised No S3‑172109  
S3‑171938 pCR Security enhancement to the EPS-AKA* China Mobile pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: similar to the previous ones. The anchor is masked, but the mask can be computed by an attacker listening to the air interface. Vodafone recommended to have a more detailed review of the documents dealing with this issue by having a conference call. The document was finally noted.
 		noted No    
S3‑171939 Encryption parameters clarification for private call Motorola Solutions UK Ltd. CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		merged No S3‑172109  
S3‑171940 pCR Adding Editor’s note to the EPS-AKA* and EAP-AKA' China Mobile pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: I'm not convinced that we can do anything about this. Vodafone: I don’t want to leave an editor's note like this in the document but I would rather see solutions directly.
 		noted No    
S3‑171941 AMF vs SEAF in solution 1.49 fo TR 33.899 Nokia pCR  
8.3.1Security architecture
 		Yes
Yes
 		approved No    
S3‑171942 Adding ENs to clause 11 of TS 33.501 Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171943 Observations on the solution for untrusted non-3GPP access in S2-174885 Nokia discussion  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171944 Observations on the solution for untrusted non-3GPP access in S2-174886 Nokia discussion  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171945 TR - LI compliance Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		revised No S3‑172081  
S3‑171946 TS - LI compliance when applying subscriber privacy Nokia pCR Decision
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172082  
S3‑171947 TR - KI - Avoiding IMSI Paging Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesORANGE: no point of having new key issues in the TR. Nokia: we had agreed on this.
 		approved No    
S3‑171948 TR - Privacy Agreement - IMSI Paging Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesEricsson: SA2 is already taking care of this. They agreed on not having an IMSI based paging. Ericsson supported this contribution. China Mobile: they don't have a document with the official agreement about this. A note was added on the need of syncronizing with SA2.
 		revised No S3‑172104  
S3‑171949 TR - discussion and agreement - NSSAI Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171950 TS - NSSAI privacy Nokia pCR Decision
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesCATT didn’t agree with this contribution.
 		noted No    
S3‑171951 TR - agreement - privacy indication Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑171952 TS - Requirements on privacy management added to clause 5 Nokia pCR Decision
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesVodafone: it looks like we are mandating privacy in 5G. Ericsson: we don’t need to specify databases and interfaces for privacy issues. ORANGE supported this and Vodafone's comment. Ericsson: there are other ways to implement this. We can just put it in a informative annex. Vodafone: not clear what is mandatory and what is optional. ORANGE: some requirements are implementation specific. BT objected to this contribution. Qualcomm as well.
 		noted No    
S3‑171953 TS - Privacy management service Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
YesIt was decided to move it to the TR instead of the TS. Ericsson: this is following the TS format, it’s normative.
 		noted No    
S3‑171954 TS - Privacy requirement for gNB Nokia pCR Decision
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesHuawei queried what triggered the requirements in 5.2.8. They didn't think it was necessary. Qualcomm supported this. Alf (NTT-Docomo): this is not a requirement,although I agree with the principles.
 		noted No    
S3‑171955 Discussion of open issues in TR 33.885 Nokia discussion Discussion
8.5.5Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		noted No    
S3‑171956 Draft reply LS on 5G Registration via Untrusted Non-3GPP Access Nokia LS out  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171957 How to use EPS AKA* for untrusted non-3GPP access Nokia discussion  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171958 EPS AKA* to be used over all access network types – clause 6 Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171959 EPS AKA* to be used over all access network types – clause 11 Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171960 Re-ordering of clause 6 Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171961 Key hierarchy Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171962 Update of clause 8.1.1.1 ‘5G-RAN key setting during primary authentication in TS 33.501 Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNTT-Docomo: Raised the question: Take from 33.401 and do the modifications like Ericsson proposes or we do a fresh start instead in 33.501? Huawei: if there is anything in 33.401 applicable in 501 just bring a contribution. We don’t need to bring everything from 401. Nokia: fresh start is too cumbersome and there is not time, let's bring the 401 approach. NEC supported it. NTT-Docomo pointed out to fix the normative language mistakes that are coming from 401 so as not to make the same errors. The proposal would be to bring things from 33.401, but instead of copying directly into the TS have a running pCR to be able to adjust the language firstly. New language is merged into this running pCR.
 		noted No    
S3‑171963 Handling security contexts within the serving network Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171964 Update of clause 5.4.1 ‘Requirements for algorithm selection‘ in TS 33.501 Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171965 Distribution of security contexts Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171966 Security handling in state transitions Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171967 Clarification on how the authentication method, and the variant is chosen between AUSF and UDM/ARPF Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE: remove the note on the Annex B. Nokia: first sentence in the removed note should stay.
 		revised No S3‑172146  
S3‑171968 Security handling in mobility Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑171969 xMB interface security Ericsson discussion  
7.6.21Other work items
 		Yes
Yes
 		noted No    
S3‑171970 Need for key left at the AUSF Nokia, Ericsson pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE preferred to remove the feature. Merged with 2022.
 		merged No S3‑172145  
S3‑171971 User-based authorization for xMB Ericsson LM CR  
7.6.21Other work items
 		Yes
Yes
 		revised No S3‑172136  
S3‑171972 Computation of key left at the AUSF for EPS AKA* Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171973 Computation of key left at the AUSF for EAP-AKA’ Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171974 Key Issue on Authentication of eRemote UE during one-to-one Communication Establishement Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesORANGE: the real requirement is the authentication of the remote UE and the network. Huawei: the key issue is the authentication of the remote UE and UE before the remote UE authenticates in the network. Nokia agreed with ORANGE and found the requirement too ambiguous. It was decided to remove the requirements and add an editor's note stating the need of clarifying the key issue.
 		revised No S3‑172181  
S3‑171975 Title Modification for Key Issue #5 Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171976 Overview of REAR Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesKPN: some text in the architecture clause doesn't belong there. They should be moved to the scope clause. MCC: "use "this document" instead of "this study". ORANGE: simply refer to the architecture in SA2. This was agreed. ORANGE: the introduction is giving a solution already.Remove the second paragraph. MCC: reword the "shall"s in there.
 		revised No S3‑172155  
S3‑171977 Solution of Authorization for Indirect 3GPP Communication Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesEricsson: not sure that this is part of SA3 scope, since the authorization is discussed in SA2. Nokia: a security solution is neeeded here, not entirely in the scope of SA2. Editor's notes were added to address Nokia's and Ericsson's issues.
 		revised No S3‑172182  
S3‑171978 Solution of IMSI privacy for Attach via eRelay UE Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesORANGE: we should go back to the requirement and modify it a little bit.
 		revised No S3‑172183  
S3‑171979 eRelay Discovery Enhancement Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171980 Solution for Protection of CP between eRemote UE and Network Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171981 Enhancement of Setting up Connection between eRemote UE and eRelay UE Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesORANGE didn’t get the key issue.Besides, there's a lot of exchange before securing PC5 and during that the attack is still possible. Ericsson: this is using basically Prose? Huawei: the deviation from ProSe is in step 3 and 4. According to ORANGE, the key issue in 1974 wasn't clear enough to justify this solution. Huawei was encouraged to clarify the key issue for the next meeting.
 		noted No    
S3‑171982 Granularity of anchor key binding Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172186  
S3‑171983 Derivation of anchor key for EAP-AKA’ Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171984 Rename EPS AKA* to 5G AKA Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesIt was decided to rename it to 5G AKA.
 		approved No    
S3‑171985 Discussion on i/c LS R2-1706161 on DRB IP failure and counter check Nokia discussion Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑171986 Security messages on N12 Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑171987 Discussion on LTE redirection to GERAN Ericsson discussion Endorsement
7.6.1SAE/LTE Security
 		Yes
YesNokia proposed a conference call after the meeting to discuss this issue.Huawei agreed. Ericsson: we need the solution discussed in RAN2/CT1. Nokia: what's a legacy UE? Ericsson: the one that is in the field right now.
 		noted No    
S3‑171988 Reply LS on connection establishment over PC5 Huawei; Hisilicon LS out Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesKPN: we can use the reply to the other LS in here too.
 		noted No    
S3‑171989 Security messages on N13 Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		merged No S3‑172146  
S3‑171990 More than one authentication vector may be sent to SEAF Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesMCC commented that the NOTE should be plain text since a recommendation is being given. "It is recommended…" has the same meaning as a "you should.." so this would be normative language contained in an informative note. Nokia commented that this was taken literally from 4G, and MCC replied that it would be better to change it now. The Chair commented that this case has appeared often and that this could be taken offline and considered in a later review.
 		approved No    
S3‑171991 Linking increased home control to subsequent procedures Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEricsson: this is not urgent. We can postpone a decision given that there are potentially better solutions. BT considered important since it could affect the QoS for the subscribers. Deutsche Telekom: it needs to be somewhere. Let's agree on this and keep it until something else shows up. Otherwise we will stand here suffering from fake location updates with no apparent solution given. ORANGE, KPN, NTT-Docomo supported DT.
 		approved No    
S3‑171992 Requirements on core network interconnection security Nokia pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEricsson: heavily assumed that we will use Diameter: end-to-end confidentiality and integrity protection requirement. China Mobile: where is the threat? Nokia: we have the TR 33.899 for that, we don't put them in the TS. Ericsson: this is very solution-specific. Deutsche Telekom supported this contribution. Ericsson wasn't convinced to have the requirements for the solutions, given that they may be found by GSMA or with the help of GSMA.
 		revised No S3‑172174  
S3‑171993 Draft LS on 3GPP Requirements on Core Network Interconnection Security Nokia LS out  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172175  
S3‑171994 Reply LS on PC5 Secure Communication Huawei; Hisilicon LS out Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesIntel: too soon to say that we shall provide integrity and confidentiality protection, we need to study these attacks. KPN, ORANGE: let's study the attacks in our TR and come back later with some conclusions. Ericsson: these attacks could be relevant, at least answer SA2 with the attacks we find relevant to study.
 		noted No    
S3‑171995 CR to TS 33.250_Authentication extension validation NEC Corporation CR Agreement
7.1.1Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		revised No S3‑172119  
S3‑171996 Security Procedures with EAP-TLS Huawei, Hisilicon pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No   S3‑171812
S3‑171997 Security for the RLFs for UEs doing user plane over control plane using NAS level security Qualcomm Incorporated CR Agreement
7.6.14Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesNokia: UL/XDL_NAS_MAC are defined anywhere? Qualcomm implied that was not necessary, it's well explained in the clause.
 		revised No S3‑172137 S3‑171325
S3‑171998 Adding bidding down security based on AS signalling to the EN-DC draft CR Qualcomm Incorporated other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesQualcomm questioned combining LTE/NR in the same signalling as Ericsson proposed. They would support a negotiation where it is indicated the algorithms supported for LTE and for NR. Nokia: maybe we are creating a problem by defining two sets. The Chair clarified that cryptographic algortihms are the same in NR. Qualcomm: inputs to NR are not the same as in LTE since the bearer IDs are different. We should have separate bits to say these algos support LTE and these support NR. Qualcomm: Happy to do the /NAS based solution as long as we have separate bits for the NR capability and for the LTE capability. Ericsson: in the case the issue is that the legacy eNodeB doesn’t understand the new capabilities.All eNodeBs would need to be upgraded. Huawei: the NAS solution is the way to go. How do you transfer the capabilities to the MeNodeB? If you come to the Ericsson: MeNodeB from a legacy eNodeB handover (x2 interface) you will not get this information. Huawei: the legacy issue is not a priority now. The Chair commented that the general feeling is going for an AS based solution, but the Qualcomm proposal needed to be commented offline.
 		noted No    
S3‑171999 Proposed response LS on algorithm selection in E-UTRA-NR Dual Connectivity Qualcomm Incorporated LS out Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172000 Discussion on the details of the NR security algorithms Qualcomm Incorporated other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesVodafone: SAGE would like to have requests the earlier the better. Conference calls with them, with decision power, would ease the process.
 		revised No S3‑172083  
S3‑172001 Proposed reponse LS on NR security input parameters Qualcomm Incorporated LS out Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesEricsson: this is still being discussed, not decided in RAN2 yet. If this is changed, we need to know fast, we should tell RAN2. It's a bit early to involve SAGE now. Nokia: it's still OK to let SAGE know about this possible change of the number of bits. The sentence will be reworded to transfer the message to SAGE in any case. The Chair commented that it's better to be proactive and tell SAGE about the implications of RAN2's work given the timing implications. Nokia: there is no drastic change in the algorithms, it’s just a change of the range of a parameter. Don't involve SAGE yet. Ericsson: just put them in copy in the LS. Nokia: SAGE will know about this anyway, they will know through Vodafone about these discussions.
 		noted No    
S3‑172002 Discussion on the choice of keying method and impact of failed integrity protection check for UP traffic Qualcomm Incorporated other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		merged No S3‑172149  
S3‑172003 Proposed response LS on security keys in EN-DC and actions upon DRB IP check failure Qualcomm Incorporated LS out Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172004 Discussion on the privacy considerations of NSSAI Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesBT: either encrypt all or encrypt nothing, otherwise you allow to correlate stuff.
 		noted No    
S3‑172005 Proposed response LS on 5GS Security aspects seeking resolution Qualcomm Incorporated LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172006 Providing details on the calculation of keys for the AUSF and SEAF Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEricsson supported the changes in the editor's notes. Nokia: you are creating an intermediate layer and move everything to the AUSF. This organization seems dubious.Ericsson supported Nokia. Huawei supported this contribution. Offline discussions were needed to procceed.
 		noted No    
S3‑172007 Protecting the initial NAS messages Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: it contains details still being discussed like NSSAI. Ericsson: it maybe disaligned with the SMS protection solution that has been agreed. Two editor's notes were added, some of the language needed to be normative. With this modifications the document was approved.
 		revised No S3‑172171  
S3‑172008 Identifying a problem with secondary authentication Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑172009 Security handling for interworking between NextGen Core and EPC Qualcomm Incorporated other Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑172010 pCR to provide a normative text for the AMF key derivation/refresh Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesThis contribution clashed with 1961, 1968.
 		noted No    
S3‑172011 pCR to provide a normative text for AS key derivation Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑172012 pCR to provide a normative text for AS key hierarchy Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑172013 pCR on adding bidding down protection requirement in Phase 1 for features that may be added later Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesMCC and Ericsson: no mention of future releases or phases in the specification. It was agreed to add an editor's note on the necessity of rephrasing this to accommodate the 3GPP drafting rules. LG: what features? Security features? All features? It was agreed to have "security features".
 		revised No S3‑172176  
S3‑172014 pCR to provide a solution for interworking between NextGen Core and EPC Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑172015 Analysis of the solutions proposed in SA2 LS for Registration over untrusted n3gpp Qualcomm Incorporated other Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesMotorola: Qualcomm's solution was rejected in SA2, let's discuss only the issues agreed in SA2. ORANGE: Qualcomm's solution is in our TR. Why doesn't this work? Motorola commented that they were not involved personally in the discussion and that they would have to check with their colleagues. Qualcomm pointed out that SA2 is waiting for SA3's response, the solution is not rejected. Verizon: Let's send SA2 our security concerns for SA2 solutions and comment what SA2 should do. Nokia: SA2 cannot address the detailed security concerns. Intel commented that SA3 should understand why the Qualcomm solution doesn't work given that it is in our TR. Ericsson: SA2 is asking to assess the security solutions they propose and SA3 should reply to that. Afterwards we can decide whether the existing solution is better. An evening drafting session was created to try to merge all the contributions related to the LS from SA2.
 		noted No    
S3‑172016 Proposed Reply LS on 5G Registration via Untrusted Non-3GPP Access Qualcomm Incorporated LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172017 Impacts of IMSI/SUPI privacy on UE Identity handling procedures Qualcomm Incorporated other Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEricsson: the procedure doesn't have security concerns. Let SA2 deal with this. Verizon: there are security concerns when sending the SUPI. Nokia: SA2 has defined the registration procedure with the SUPI. They have to adapt their procedure accordingly to what SA3 proposes. We don’t need an extra message as Ericsson proposes since it's already there. Huawei: if the AMF doesn’t need the message with the temporary ID it has to request the identity of the user. Something needs to be done. Qualcomm: in that scenario in 4G it's a reject from the MME. So a new attach is performed. That's what the AMF will do, reject so the process restarts. Nokia: SA2 can use the identity request procedure as well, but they may not want it for non-3GPP networks.
 		noted No    
S3‑172018 Proposed Reply LS on Impacts of using User Identity confidentiality Qualcomm Incorporated LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172019 pCR : Security for Non-3GPP access to 5GC Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172020 pCR : Security visibility and Configurability Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEricsson didn’t agree with the user plane being negotiated on a per radio bearer basis. This hadn't been agreed by the group.This was removed. Discussed together with 897 from Huawei, that overlapped with the same topic.They were finally merged with 779.
 		merged No S3‑172107  
S3‑172021 pCR : 5GS Subscription Privacy General aspects Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesVodafone: storage of the key in the ME, you are not mentioning any security whatsoever, which is similar to the Ericsson contribution that I objected to. There are no reliable, cheap methods to update the mobile handset. Qualcomm: there are operators who think differently from Vodafone. China Mobile: the public key can be put in the ME. Ericsson: the public key is public by definition, why do we need to protect it?
 		merged No S3‑172151  
S3‑172022 Some corrections and clarification to the authentication text Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesMerged with 970.
 		revised No S3‑172145  
S3‑172023 Corrections to xMB security aspects Qualcomm Incorporated CR Agreement
7.6.7Multimedia Broadcast/Multicast Service (MBMS)
 		Yes
Yes
 		not pursued No    
S3‑172024 Proposed reply LS on encrypting broadcasted positioning data Qualcomm Incorporated LS out Approval
7.6.1SAE/LTE Security
 		Yes
YesErisson: we should not tell them which method to use. E-SMLC is not more secure than cyphering by an eNB. Ask for more information. The LS was replied in 134.
 		noted No    
S3‑172025 Ciphering of Broadcast Assistance Data Qualcomm Incorporated discussion Decision
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑172026 KeNB calculation at initisation of S1-U DRBs for UEs using control plane optimisations Qualcomm Incorporated CR Agreement
7.6.14Security Aspects of Narrowband IOT (CIoT)
 		Yes
YesNokia had a problem with the note. It was decided to remove it. Vodafone: the first paragraph is a very long sentence. It was agreed to reword the first paragraph to make it simpler to read and understand.
 		revised No S3‑172138  
S3‑172027 CR to TS 33.250_Emergency PDN Connection Release NEC Corporation CR Agreement
7.1.1Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		revised No S3‑172122  
S3‑172028 pCR to TS 33.216_RRC and UP downlink ciphering at the eNB NEC Corporation pCR Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
YesEricsson: the precondition needs to be made similar to the rest of preconditions in the document. The UE should be simulated. BT: We need to be very strict to avoid having those keys getting out to the wild.
 		revised No S3‑172128  
S3‑172029 pCR to TR 33.926_Inactive Emergency PDN Connection Release NEC Corporation draftCR Approval
8.5.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		Yes
Yes
 		revised No S3‑172121  
S3‑172030 pCR to TS 33.501_5G Key Hierarchy NEC Corporation, AT&T pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		not treated No    
S3‑172031 Interim agreements for key issue #7.2 Gemalto N.V. pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		revised No S3‑172088  
S3‑172032 Security Keys in EN-DC Samsung pCR Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172033 pCR to TS 33.501_NAS SMC procedure NEC Corporation, AT&T pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		merged No S3‑172172  
S3‑172034 Securing the Network Steering Information Samsung pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesPostponed together with the associated LS. Vodafone noted that they will reject the solution in the next meeting.
 		postponed No    
S3‑172035 [DRAFT] Response LS on security keys in EN-DC and actions upon DRB IP check failure Ericsson LS out Decision
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesEricsson: it would be acceptable if the eNodeB didn’t have integrity protection. We haven't agreed to make eNodeB user plane integrity mandatory, but it should be OK for the 5G core, packets are dropped. RAN2 may specify some recovery mechanisms for recovery of the dropped packets.
 		noted No    
S3‑172036 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‑172037 pCR to TS 33.501_Update to EAP-AKA’ NEC Corporation pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesNokia: this doesn’t work for EAP-AKA'.
 		noted No    
S3‑172038 pCR to TS 33.501_Skeleton for security handling in mobility NEC Corporation pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesOverlaps with 1968. Nokia: the NAS doesn’t see anything about the HO preparation. Huawei: tdoc 1931 is the preferred way for clause 8.3
 		noted No    
S3‑172039 pCR to TR 33.899_Update IA KI_1.18_Flexible security policies negotiation in control plane NEC Corporation pCR Approval
8.3.1Security architecture
 		Yes
YesChina Mobile: why more than one KDF? Nokia: in case there is a risk of bidding down attacks, there may be more than one needed. Huawei: what kind of risk,high or low? This is undetermined.
 		revised No S3‑172096  
S3‑172040 pCR to TR 33.899_Discussion on inputs for key derivation NEC Corporation pCR Discussion
8.3.1Security architecture
 		Yes
Yes
 		noted No    
S3‑172041 [eMCSEC]: Key Issue on Edge Security for TR 33.880 NCSC pCR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑172042 [eMCSEC]: Solution for Signalling Proxy for TR 33.880 NCSC pCR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		revised No S3‑172133  
S3‑172043 [eMCSEC]: Modification of Key Issue #1.4 TR 33.880 NCSC pCR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑172044 [eMCSEC]: Solution for Signalling Authentication for TR 33.880 NCSC pCR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		revised No S3‑172111  
S3‑172045 [eMCSEC]: Modification of Solution #1.1 in TR 33.880 NCSC pCR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		revised No S3‑172112  
S3‑172046 Corrections to MCData security procedures Samsung, NCSC CR Approval
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		revised No S3‑172130  
S3‑172047 pCR to TR 33.899_IA on inputs for key derivation NEC Corporation pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		noted No    
S3‑172048 pCR to TR 33.899_Solution to KI #13.1 NEC Corporation pCR Approval
8.3.13Interworking and migration
Yes
Yes
 		revised No S3‑172148  
S3‑172049 pCR to TR 33.899_IA on Key refresh during handover with AMF change NEC Corporation pCR Approval
8.3.4RAN security
 		Yes
Yes
 		noted No    
S3‑172050 pCR to TR 33.899_Verifying gNB NEC Corporation pCR Approval
8.3.4RAN security
 		Yes
Yes
 		approved No    
S3‑172051 Clarifications to the user plane integrity requirements in TS 33.501 Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesORANGE: I don’t see the intention of the second NOTE. This is not purely informative. I don’t want a guidance of the usage of this for the operator. Qualcomm supported having this note. Huawei: why "..that are not confidentiality protected"? MCC pointed out that the first note was written as a requirement, not an informative statement. Besides, both notes included the word "must" that cannot be used in 3GPP specifications.
 		revised No S3‑172187  
S3‑172052 CR to TS 33.401_Update of CR on EN-DC NEC Corporation other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		merged No S3‑172149  
S3‑172053 Encryption of positioning broadcast information Ericsson Inc. discussion Endorsement
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑172054 Draft Reply LS to R2-1707501 NEC Corporation LS out Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172055 Clarifications to the user plane integrity requirements in ENDC (option 3) Ericsson other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesNTT-Docomo: eNodeBs in the future may need user plane integrity protection. The wording in E.1.2 should be changed. Ericsson agreed.
 		revised No S3‑172085  
S3‑172056 Updates to S3-171487 (CR to TS 33.401 for Option 3/3a/3x dual connectivity VODAFONE Group Plc draftCR Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		revised No S3‑172067 S3‑171487
S3‑172057 LS on ‘Temporary group call – user regroup’ security NCSC LS out Approval
7.5Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑172110  
S3‑172058 [MCSEC] General corrections to TS 33.180 NCSC CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		revised No S3‑172108  
S3‑172059 LS on configuration data for protection of signalling NCSC LS out Approval
7.5Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
YesMotorola: is this for Rel-14? NCSC: it is for Rel-15 only.
 		revised No S3‑172131  
S3‑172060 [MCSEC] MCData payload authentication correction NCSC CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑172061 New SID for eV2X security LG Electronics SID new Agreement
8.5.6Other study items
 		Yes
YesNokia: last time we had asked for an analysis for the security relevance of this topic. CATT: this is too early. LG: this is only for LTE, not 5G. ORANGE: we don’t have an architecture as a basis for this work. There was no support for this. The Chair recommended LG to discuss this offline since it was not clear to people what needed to be done. Since the dates are for late 2018, the study can be made to be more concrete. The Chair warned that the 5G work may limit the work on other study items during the physical meetings.
 		noted No    
S3‑172062 NSSAI privacy clarification LG Electronics discussion Endorsement
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesQualcomm: if some operators wants privacy protection, why should they wait for phase two? CATT supported Qualcomm.
 		noted No    
S3‑172063 Questions for security area #11 LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
YesVodafone: an application should not be able to drop a call based on its own privacy requirements.
 		noted No    
S3‑172064 Conclusion of security area #11 LG Electronics pCR Approval
8.3.11Security visibility and configurability
 		Yes
YesORANGE didn’t agree with this. Ericsson supported it.
 		noted No    
S3‑172065 pCR to 33501_some editoral revisions Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑172066 Update on the status of the work on SSP (Smart Secure Platform) ETSI TC SCP LS in  
6.11Other Groups
 		Yes
YesVodafone commented that the progress in SCP is very slow and doubted about their ability to finish this on time. ORANGE commented that SCP has been warned that their work will not be included in the 3GPP specs if they don't finish on time.
 		noted No    
S3‑172067 revision of Updates to S3-171487 (CR to TS 33.401 for Option 3/3a/3x dual connectivity following comments VODAFONE Group Plc draftCR Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesEricsson didn’t agree with the X2 interface in figure E.1.2-1. Vodafone: RAN3 latest agreements confirm this. This was taken offline. Qualcomm: the eNodeB to support potential inputs to the same core block? This would be a premature decision and we need to discuss it with RAN2.
 		revised No S3‑172149 S3‑172056
S3‑172068 Response to CCSA liaison statement ZUC-256 algorithm (S3-171912) ETSI SAGE LS in  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesAlex (BT): we already have 256 bits, but we are not using them. Interfaces are for 128 bits. Ericsson:the key length is 256 bits but the algorithms need to be specified for 256 bits. There is a proposal from AT&T for a study (1773). It was concluded to check this document before deciding on a reponse. Interdigital: let's limit it to the radio access.
 		replied to No    
S3‑172069 Further comments to Nokia S3-171814 Discussion on i/c LS R2-1706151 on DC bearers Nokia discussion Endorsement
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesNokia: option one is pure Rel-13 dual connectivity. Ericsson: it's ok to use the same key as long as you don’t change the termination point; this was agreed in SA3 and in you are contradicting this decision here. Nokia: UE performance is affected when rekeying. Ericsson didn’t understand this issue: There weren't performance issues in the dual connectivity. There is no disruption of the service. Verizon: performance impact is not to be decided in SA3. RAN2 wants a good security solution.We should go for option 3. Qualcomm: option 3 has more complexity from the security perspective. Nokia: the number of keys exchanged is reduced and the performance is improved. Huawei pointed out that RAN2 would like a transparent process. Qualcomm: the transparent exchange cannot be achieved in terms of option 2 and option 3. Ericsson: transparency means that the network indicates the UE when to change the key. We have a different understanding of option one despite that most companies seem to go for this option. China Mobile: different keys for LTE PDCP and NR PDCP? Qualcomm: the algorithm is the same in both LTE and PDCP, it's only the message that changes. Ericsson: all three options are possible, but the principle in option one is the most important from the security point of view. Nokia agreed but leaving the door open for using the other two options in a specific circumstance. Qualcomm didn’t see the security gain for having the possibility of using the other two options. Nokia: we agreed and implemented option 1 in Rel-12. We should also agree at least on option 2. Huawei agreed.
 		noted No    
S3‑172070 Comments to S3-171947 pCR New KI - Avoiding IMSI SUPI Paging China Mobile discussion  
8.3.7Subscription privacy
 		Yes
Yes
 		noted No    
S3‑172071 comments to S3-171776 on HN public key Gemalto N.V. pCR  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172087  
S3‑172072 Comments on S3-171802, 03, 04 by Huawei on 'EPS AKAstar procedure' Nokia discussion  
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑172073 Comments on S3-17917 Q&IA related to the Usability of legacy USIM in key issue #2.1 OBERTHUR TECHNOLOGIES pCR Decision
8.3.2Authentication
 		Yes
Yes
 		noted No    
S3‑172074 Work Plan input from Rapporteurs MCC other -
9Review and Update of Work Plan
Yes
Yes
 		noted No   S3‑171705
S3‑172075 New WID for Northbound APIs Security for SCEF - SCSAS Interworking (NAPS_Sec) Huawei, Hisilicon WID new Agreement
7.6.9Security Aspects related to Machine-Type Communication ((e)MTC)
 		Yes
YesVodafone,BT: restrict the scope to securing the interface (they wanted the bullet points in the objective back). If the scope is too wide make it a study item. ORANGE preferred a wider scope (removing the bullet points in the objective), also a study item instead of a work item. Nokia: the WID is progressing in SA2, we received an LS and we replied to them. This is beyond a study item. This was taken offline and an agreement was made.
 		agreed No   S3‑171878
S3‑172076 Reply to: LS on Security for T8 interface Huawei LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑172077 Reply to: LS to SA3 on Counter Check Procedure and SCG SRB integrity check failure Nokia LS out approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172078 Reply to: Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity Ericsson LS out approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172079 Reply to: LS reply on NR security input parameters Qualcomm LS out approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172080 Reply to: LS to SA3 on security keys in EN-DC and actions upon DRB IP check failure Ericsson LS out approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172081 TR - LI compliance Nokia pCR Decision
8.3.7Subscription privacy
 		Yes
Yes
 		approved No   S3‑171945
S3‑172082 TS - LI compliance when applying subscriber privacy Nokia pCR Decision
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
YesNTT-Docomo wasn't sure whether this worked for the already proposed schemes. An editor's note was proposed to warn about this. Ericsson: it's simpler is to send the SUPI when the NAS security is turned ON. Huawei supported this. Ericsson: Let's not make a decision in this meeting and analyze how to fulfil the LI requirement for the next meeting. NTT-Docomo: keep the headline to have a placeholder. Arguments for a solution should be brought for the next meeting. Nokia: keep the assumption. Some companies disagreed with this.
 		noted No   S3‑171946
S3‑172083 Discussion on the details of the NR security algorithms Qualcomm Incorporated other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172000
S3‑172084 DraftCR on EN-DC Qualcomm,NEC,Ericsson,Huawei, HiSilicon draftCR Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172085 Clarifications to the user plane integrity requirements in ENDC (option 3) Ericsson other Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172055
S3‑172086 Reply to: LS on secure platform requirements ORANGE LS out approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesEricsson was concerned that this would re-open long discussions in SA1. The SA1 TS is not phase specific.They have agreed on this topic and they were worried that SA3 would be bringing this phase approach to SA1. Ericsson asked to have minuted that they disagreed with the removal of the definition of subscription credential from the SA1 TS as this LS proposes. Sony had the same objection.
 		approved No    
S3‑172087 comments to S3-171776 on HN public key Gemalto N.V.,ORANGE, Oberthur Technologies, Morpho pCR -
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesBT: if the operator is the only one allowed to provide the handsets this works, but when they are out of their of their control we agree with Vodafone. Qualcomm: there will be operators who will choose to store in the UICC, and there will be operators who will have control over the handset distribution model and they can choose to store in the ME. Why do we standardise to avoid operators having this option? Vodafone: the disagreement on the ME part relies on the provisioning, not the security. Let's add an editor's note on this.
 		merged No S3‑172151 S3‑172071
S3‑172088 Interim agreements for key issue #7.2 Gemalto N.V., ORANGE, Oberthur Technologies, Morpho pCR Approval
8.3.7Subscription privacy
 		Yes
Yes
 		noted No   S3‑172031
S3‑172089 Reply to: Reply LS on 5GS Security aspects seeking resolution Qualcomm LS out approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
No
 		withdrawn Yes    
S3‑172090 Reply to: LS on Impacts of using User Identity confidentiality Qualcomm LS out approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172091 Reply to: LS on 5G Registration via Untrusted Non-3GPP Access Lenovo LS out approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172092 Algorithm Identifier Values Huawei, Hisilicon, CATR, CATT pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171796
S3‑172093 Interim Agreement to Key Issue #1.5 and #1.6 Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		No
Yes
 		approved No   S3‑171832
S3‑172094 Interim agreements for forward security during handover Huawei; Hisilicon pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171831
S3‑172095 Draft TR 33.899 Ericsson draft TR Approval
8.3.18Other
 		No
YesThe Chair commented that the plan was not to present this TR for approval. A note will be added to state that there are no evaluations in the specification. MCC clarified that the Study Item would be stopped, the latest draft approved by the WG but the specification would not be approved at SA level. The interim agreements in this TR will be followed by the group in the normative work.
 		left for email approval No    
S3‑172096 pCR to TR 33.899_Update IA KI_1.18_Flexible security policies negotiation in control plane NEC Corporation pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑172039
S3‑172097 LS on service based architecture ORANGE LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
Yes
 		approved No    
S3‑172098 Reply LS on 256-bit algorithms for 5G AT&T LS out approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172099 Q&IA related to the Usability of legacy USIM in key issue #2.1 China mobile, KPN pCR -
8.3.2Authentication
 		No
Yes
 		noted No   S3‑171917
S3‑172100 interim agreement for KI#2.4 Huawei; Hisilicon pCR Approval
8.3.2Authentication
 		Yes
Yes
 		approved No   S3‑171845
S3‑172101 Question and Interim Agreement on authentication of the user Alibaba (China) Group., Ltd. pCR Approval
8.3.2Authentication
 		Yes
Yes
 		approved No   S3‑171816
S3‑172102 Interim agreement for protecting anchor key for primary authentication ZTE Corporation pCR Approval
8.3.3Security context and key management
 		Yes
Yes
 		approved No   S3‑171758
S3‑172103 Update Interim Agreements for RAN KI # 4.11 & 4.15 Huawei, Hisilicon pCR Approval
8.3.4RAN security
 		Yes
Yes
 		approved No   S3‑171825
S3‑172104 TR - Privacy Agreement - IMSI Paging Nokia pCR Decision
8.3.7Subscription privacy
 		No
Yes
 		approved No   S3‑171948
S3‑172105 Privacy: SUCI null-scheme normative Annex Ericsson, Vodafone pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171787
S3‑172106 LS on Security aspects of ECIES for concealing IMSI or SUPI Ericsson LS out Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesGemalto:ask ETSI SAGE to improve the efficiency. What if companies bring a new scheme next meeting? Ericsson: this is open. IT was pointed out that the LS clarifies that this is a possible candidate.
 		approved No   S3‑171789
S3‑172107 Privacy: Text proposal in Clause 5.4 (visibility and configurability) Ericsson, Telecom Italia,Qualcomm,Huawei,LG pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesBT and Vodafone: on what basis are you displaying to the user?
 		approved No   S3‑171779
S3‑172108 General Corrections to TS 33.180 NCSC,Motorola Solutions,NCSC CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No   S3‑172058
S3‑172109 Correction of parameters for use of MIKEY-SAKKE Motorola Solutions UK Ltd.,NCSC CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No   S3‑171937
S3‑172110 LS on ‘Temporary group call – user regroup’ security NCSC LS out Approval
7.5Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172057
S3‑172111 [eMCSEC]: Solution for Signalling Authentication for TR 33.880 NCSC pCR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑172044
S3‑172112 [eMCSEC]: Modification of Solution #1.1 in TR 33.880 NCSC pCR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No   S3‑172045
S3‑172113 [MCSec] 33180 CR Broadcast and emergency security Motorola Solutions Danmark A/S CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No   S3‑171761
S3‑172114 Clarifications and editorial corrections related to SRTCP protection Motorola Solutions UK Ltd. CR Agreement
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No   S3‑171936
S3‑172115 pCR to TS33.501 - security requirements on subscription identifiers Ericsson, Telecom Italia,CATT pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑172173 S3‑171904
S3‑172116 Privacy: Requirements related to SUPI and SUCI Ericsson, Vodafone, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171778
S3‑172117 Privacy: proposed changes to authentication procedures (6.1.2, 6.1.3) Ericsson, Vodafone, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171781
S3‑172118 Privacy: proposed content to 6.8.1 (SUPI) Ericsson, Vodafone, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171782
S3‑172119 CR to TS 33.250_Authentication extension validation NEC Corporation CR Agreement
7.1.1Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		agreed No   S3‑171995
S3‑172120 Adding P-GW annex Huawei CR Agreement
8.5.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		Yes
Yes
 		agreed No    
S3‑172121 pCR to TR 33.926_Inactive Emergency PDN Connection Release NEC Corporation draftCR Approval
8.5.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		Yes
Yes
 		approved No   S3‑172029
S3‑172122 CR to TS 33.250_Emergency PDN Connection Release NEC Corporation CR Agreement
7.1.1Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		agreed No   S3‑172027
S3‑172123 Resolving two editor’s notes about reuse of Charging ID and TEID China Mobile, Telecom Italia, China Unicom CR Approval
7.1.1Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)
 		Yes
Yes
 		agreed No   S3‑171915
S3‑172124 Draft TS 33.216 Huawei draft TS Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		No
Yes
 		approved No    
S3‑172125 Cover sheet 33.216 Huawei TS or TR cover Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No    
S3‑172126 AS Security Mode Command Procedurey Huawei; Hisilicon pCR Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No   S3‑171868
S3‑172127 Bidding down prevention in X2-handovers Huawei; Hisilicon pCR Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No   S3‑171869
S3‑172128 pCR to TS 33.216_RRC and UP downlink ciphering at the eNB NEC Corporation pCR Approval
7.1.2Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)
 		Yes
Yes
 		approved No   S3‑172028
S3‑172129 Adding eNB Annex to support SCAS_eNB Huawei CR Agreement
8.5.1Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)
 		No
Yes
 		agreed No    
S3‑172130 Corrections to MCData security procedures Samsung, NCSC CR Approval
7.4Security of the Mission Critical Service (MCSec) (Rel-14)
 		Yes
Yes
 		agreed No   S3‑172046
S3‑172131 LS on configuration data for protection of signalling NCSC LS out Approval
7.5Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172059
S3‑172132 Draft TR 33.880 NCSC draft TR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		Yes
Yes
 		approved No    
S3‑172133 [eMCSEC]: Solution for Signalling Proxy for TR 33.880 NCSC pCR Approval
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)
 		No
Yes
 		approved No   S3‑172042
S3‑172134 Reply to: LS on encrypting broadcasted positioning data Ericsson LS out approval
7.6.1SAE/LTE Security
 		Yes
Yes
 		approved No    
S3‑172135 Reply to: Reply LS on external interface for TV services Ericsson LS out approval
7.6.7Multimedia Broadcast/Multicast Service (MBMS)
 		Yes
Yes
 		approved No    
S3‑172136 User-based authorization for xMB Ericsson LM CR -
7.6.21Other work items
 		Yes
Yes
 		agreed No   S3‑171971
S3‑172137 Security for the RLFs for UEs doing user plane over control plane using NAS level security Qualcomm Incorporated CR Agreement
7.6.14Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		agreed No   S3‑171997
S3‑172138 KeNB calculation at initisation of S1-U DRBs for UEs using control plane optimisations Qualcomm Incorporated CR Agreement
7.6.14Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		agreed No   S3‑172026
S3‑172139 Collection of changes to BEST TS as a result of implementations VODAFONE Group Plc CR Agreement
7.6.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)
 		No
Yes
 		agreed No   S3‑171747
S3‑172140 V2X TR correction Nokia CR Agreement
8.5.5Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑172141 CR for modify the text format of X5.2 in TS 33.203 - R14 Huawei, Hisilicon CR Approval
7.6.21Other work items
 		Yes
YesMCC noted that editorial changes are only allowed in Rel-15, so the CR was changed to this Release.
 		agreed No   S3‑171896
S3‑172142 GBA use in LTE V2X Huawei CR Agreement
7.6.20Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)
 		Yes
Yes
 		agreed No    
S3‑172143 Privacy: SUCI format and generation Ericsson, Vodafone pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171786
S3‑172144 LS to SA1 on selective disabling of Legacy Radio Access AT&T LS out Approval
7.6.21Other work items
 		Yes
Yes
 		approved No    
S3‑172145 Some corrections and clarification to the authentication text Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172022
S3‑172146 Clarification on how the authentication method, and the variant is chosen between AUSF and UDM/ARPF Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171967
S3‑172147 Draft TS 33.501 NTT-Docomo draft TS Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
Yes
 		left for email approval No    
S3‑172148 pCR to TR 33.899_Solution to KI #13.1 NEC Corporation pCR Approval
8.3.13Interworking and migration
Yes
Yes
 		approved No   S3‑172048
S3‑172149 revision of Updates to S3-171487 (CR to TS 33.401 for Option 3/3a/3x dual connectivity following comments VODAFONE Group Plc draftCR Approval
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172067
S3‑172150 Privacy: Skeleton proposal for privacy related sub-clauses Ericsson, Telecom Italia pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171777
S3‑172151 Privacy: Storage, processing and provisioning of the HN public key Ericsson, Orange, Oberthur Technologies, Morpho, Gemalto, China Mobile, Vodafone pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
YesQualcomm: we cannot allow the geneation of the SUCI in the tamper resistant component. ORANGE: Mandatory support of the new scheme has been agreed in another document. Nokia disagreed. Vodafone: subscription privacy is optional in 5G. Otherwise 5G won't be deployed in certain countries. Nokia: how often are you going to do this? This is adding complexity to lots of network components. NOTE 1 should be an editor's note. It is FFS. BT agreed with Vodafone: this may cause that 5G won't be deployed in certain parts of the World. China Mobile and BT supported to study further the legacy aspect.It was asked to be minuted the following statement from China Mobile:
 		approved No   S3‑171776
S3‑172152 Update for skeleton of clause 8 on Security Procedures between UE and 5G Access Network Functions Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171931
S3‑172153 Reply to: LS on PC5 Secure Communication and UE-to-NW relaying Intel LS out approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172154 Draft TR 33.843 Huawei draft TR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		No
Yes
 		left for email approval No    
S3‑172155 Overview of REAR Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171976
S3‑172156 Modification and resolution of Editor's Note of Key Issue #2 KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171737
S3‑172157 Clarification of Key Issue #3 KPN,Huawei,HiSilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171738
S3‑172158 New Key Issue on Service Continuity KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171739
S3‑172159 Draft TR 33.834 Vodafone draft TR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑172160 pCR TR33.XXX LTKUP - update to sections 4 5 and 6 as discussed on conf calls VODAFONE Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171750
S3‑172161 pCR to TR 33.xxx - LTKUP - re-organisation of Key issues section into Key Issues and evaluation criteria VODAFONE Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171751
S3‑172162 pCR to TR 33.xxx - LTKUP - addition of key issue content VODAFONE Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171752
S3‑172163 GSMA eUICC based solution for LTKUP Huawei; Hisilicon pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171879
S3‑172164 Agreements and open issues on Radio Access network protection NTT-Docomo discussion Endorsement
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		endorsed No    
S3‑172165 AS algo negotiation during Xn-handover (8.1.2.1.2) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171889
S3‑172166 AS algo negotiation during N2-handover (8.1.2.1.3) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171890
S3‑172167 AS algo negotiation during intra-gNB handover (8.1.2.1.4) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171891
S3‑172168 AS security mode command procedure (8.1.2.2) Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
Yes
 		noted No   S3‑171892
S3‑172169 UP security mechanisms Huawei & Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171798
S3‑172170 pCR to 33.501: Security Aspects of SMS over NAS Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171833
S3‑172171 Protecting the initial NAS messages Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172007
S3‑172172 Update of content of clause 6.3 on security negotiation Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171927
S3‑172173 pCR to TS33.501 - security requirements on subscription identifiers Ericsson, Telecom Italia,CATT pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172115
S3‑172174 Requirements on core network interconnection security Nokia pCR -
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171992
S3‑172175 LS on 3GPP Requirements on Core Network Interconnection Security Nokia LS out -
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
Yes
 		approved No   S3‑171993
S3‑172176 pCR on adding bidding down protection requirement in Phase 1 for features that may be added later Qualcomm Incorporated pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172013
S3‑172177 UP Security on gNB internal interface Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		No
Yes
 		approved No   S3‑171895
S3‑172178 UP Security on gNB internal interface Huawei; Hisilicon pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171900
S3‑172179 New SID on security aspect of 5G network slicing provisioning Huawei, Hisilicon, ZTE, CATR, CATT,China Mobile,China Unicom SID new Agreement
8.5.6Other study items
 		Yes
Yes
 		agreed No   S3‑171811
S3‑172180 eRemote-UE Authentication with MITM detection Intel Corporation (UK) Ltd pCR -
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171911
S3‑172181 Key Issue on Authentication of eRemote UE during one-to-one Communication Establishement Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171974
S3‑172182 Solution of Authorization for Indirect 3GPP Communication Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171977
S3‑172183 Solution of IMSI privacy for Attach via eRelay UE Huawei; Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171978
S3‑172184 pCR to 33.899 Security solution for SMS over NAS Nokia pCR Approval
8.3.1Security architecture
 		Yes
Yes
 		approved No   S3‑171815
S3‑172185 pCR to 33.899: Updates to Solution #7.2 Intel Corporation (UK) Ltd pCR -
8.3.7Subscription privacy
 		Yes
YesRemoving the evaluation part.
 		approved No   S3‑171913
S3‑172186 Granularity of anchor key binding Nokia pCR -
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑171982
S3‑172187 Clarifications to the user plane integrity requirements in TS 33.501 Ericsson pCR Approval
7.3Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
 		Yes
Yes
 		approved No   S3‑172051
S3‑172188 Solution for dual connectivity between MeNB and SgNB Qualcomm,NEC,Ericsson,Huawei, HiSilicon,Nokia, Samsung, NTT-Docomo,Vodafone,BT CR Agreement
7.2EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		agreed No