Tdoc List

2018-01-26 14:57

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑180000 Agenda WG Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No    
S3‑180001 Report from SA3#89 MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
YesHuawei commented that S3-173137 had been not treated instead of "rejected".This was fixed.
 		revised No S3‑180365  
S3‑180002 SA3 Work Plan MCC Work Plan  
9Review and Update of Work Plan
Yes
Yes
 		noted No    
S3‑180003 Report from last SA meeting WG Chairman report  
4.2Report from SA Plenary
 		Yes
Yes
 		noted No    
S3‑180004 SA3 meeting calendar MCC other  
10Future Meeting Dates and Venues
 		Yes
Yes
 		revised No S3‑180366  
S3‑180005 Work Plan input from Rapporteurs MCC other  
9Review and Update of Work Plan
Yes
Yes
 		revised No S3‑180346  
S3‑180006 Corrections to clause 5.3 Requirements on the AMF NEC Telecom MODUS Ltd. pCR Approval
7.2.5.10Editorials
 		Yes
YesOverlapping with 182 and 183, which had the same changes.
 		revised No S3‑180422  
S3‑180007 Corrections to clause 5.2 Requirements on the gNB NEC Telecom MODUS Ltd. pCR Approval
7.2.4.5Editorials
 		Yes
Yes
 		merged No S3‑180422  
S3‑180008 NAS security conference call notes NEC Telecom MODUS Ltd. report Information
7.2.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180009 TCG progress report InterDigital, Inc. other Information
6.7TCG
 		Yes
Yes
 		noted No    
S3‑180010 Discussion Paper on the need and ways to make SUPI protection opaque to IMSI sniffers InterDigital, Inc. discussion Decision
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180011 PCR to Annex C for making SUPI protection opaque to IMSI sniffers InterDigital, Inc. pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180012 Authentication for Untrusted Non-3GPP Access using EAP Motorola Mobility, Lenovo, LG Electronics, Nokia, KPN, Broadcom, Brocade pCR Approval
7.2.11.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180455 S3‑173251
S3‑180013 Addition of EAP-5G method ID Lenovo, Motorola Mobility CR Approval
7.2.11.1Miscellaneous
 		Yes
Yes
 		agreed No    
S3‑180014 Remaining restructuring of Clause 6.9 (Security handling in mobility) Ericsson, NEC Corporation pCR  
7.2.3.6Miscellaneous
 		Yes
Yes
 		approved No    
S3‑180015 How AMF and SEAF deal with null-scheme SUCI CATT pCR Agreement
7.2.14.2SUCI and Schemes
 		No
Yes
 		withdrawn Yes    
S3‑180016 Privacy requirement improvement related to using non null-scheme CATT pCR Agreement
7.2.14.2SUCI and Schemes
 		No
Yes
 		withdrawn Yes    
S3‑180017 Privacy requirement of using SUCI in initial registration procedure CATT pCR Agreement
7.2.14.2SUCI and Schemes
 		No
Yes
 		withdrawn Yes    
S3‑180018 Solution for meeting LI and privacy requirements CATT pCR Agreement
7.2.14.1SUPI and LI
 		No
Yes
 		withdrawn Yes    
S3‑180019 Solution for raw public key provisioning CATT pCR Agreement
7.2.14.2SUCI and Schemes
 		No
Yes
 		withdrawn Yes    
S3‑180020 Security aspects of RESUME REJECT in INACTIVE state in NR ZTE Corporation discussion Discussion
7.2.4.3RRC security
 		Yes
YesNokia considered that there was a more simple way of doing this. Ericsson: this brings additional overhead and signalling.We have an alternative in 342.
 		noted No   S3‑173072
S3‑180021 Handling of user-related keys – key setting ZTE Corporation pCR Approval
7.2.2.2Key derivation NAS related
 		Yes
Yes
 		merged No    
S3‑180022 Discussion on multi-NAS in same PLMN – structure of 5G security context ZTE Corporation, Huawei, Hisilicon discussion Discussion
7.2.5.7Multi-NAS security
 		Yes
YesThe group decided to endorse for proposal one the following statement: same NAS keys and NAS algorithms can be used to protect NAS connections terminated in the same AMF. Also endorsed for proposal two: each NAS connection will be assigned an unique identifier. Proposal three was not agreed.
 		noted No    
S3‑180023 Discussion on multi-NAS in same PLMN – NAS message handling after first registration procedure ZTE Corporation discussion Discussion
7.2.5.7Multi-NAS security
 		Yes
YesEricsson didn’t agree with the observation. This was ignored. Proposal one: Vodafone commented that more information was needed. Qualcomm: if you have a fulll context you shall use it. Detailed discussions were needed for this document so it was decided to note ir and try to solve it offline.
 		noted No    
S3‑180024 Discussion on multi-NAS in same PLMN – concurrent NAS message handling ZTE Corporation discussion Discussion
7.2.5.7Multi-NAS security
 		Yes
YesVodafone: easy DoS attack if according to proposal one. Proposal 2: Ericsson commented that they agreed with the issue but they didn’t agree with the proposals. The issue in this document was valid as agreed by the group but there was no consensus with the proposals.
 		noted No    
S3‑180025 Discussion on multi-NAS in same PLMN – re-authentication handling ZTE Corporation discussion Discussion
7.2.5.7Multi-NAS security
 		No
Yes
 		withdrawn Yes    
S3‑180026 Multi-NAS in same PLMN - structure of 5G security context ZTE Corporation pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180027 Multi-NAS in same PLMN - NAS message handling after first registration procedure ZTE Corporation pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180028 Analysis of different approaches for implementing SBA security over N32 reference point TIM (Telecom Italia) s.p.a. discussion Discussion
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180029 Collection of clarifications and editorial changes to BEST TS 33.163 Deutsche Telekom AG CR Approval
7.6.9Security Aspects related to Machine-Type Communication ((e)MTC)
 		Yes
YesBEST is not part of the agenda of this meeting.
 		postponed No    
S3‑180030 Reply LS on LTE call redirection to GERAN C1-175377 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑180031 Reply LS on LTE call redirection to GERAN R2-1714121 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑180032 Response LS on LTE call redirection to GERAN R3-175030 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑180033 Reply LS on PLMN and RAT selection policies for roaming C3-176332 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180034 LS on Use of Subscriber Identity in HTTP URI C4-176395 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180035 LS on a potential USIM solution for PLMN and RAT selection policies for roaming C6-170696 LS in  
7.2.16PLMN RAT selection
 		Yes
Yes
 		postponed No    
S3‑180036 LS on maximum data rate of user plane integrity protected data R2-1714125 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
YesThis was replied in SA3#89.
 		noted No    
S3‑180037 LS on Security aspects of supporting LTE connected to 5GC R2-1714244 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		replied to No    
S3‑180038 LS on Removal of 'over LTE' limitation from Mission Critical Specifications S1- 174542 LS in  
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑180039 Reply LS on 5G Identity and Access Management Requirements S1-174557 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180040 Reply LS on selectively disabling legacy radio access S1-174601 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180041 Reply LS on clarification on Restricted Operator Services S1-174604 LS in  
6.13GPP Working Groups
 		Yes
YesVodafone: SA1 is making security assumptions without consulting SA3. BT commented that SA3 had sent an LS to SA1 in March 2017 on this issue and didn't get any response. Vodafone commented that they would check internally with the SA1 colleagues. Qualcomm commented that the intention was that the UE would only accept non integrity protected messages when they wanted to make an RLOS call.
 		replied to No    
S3‑180042 Response to LS on encrypting broadcasted positioning data and LS on provisioning of positioning assistance data via LPPa for broadcast S2-179617 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑180043 LS on end-to-end encryption for mission critical communications between LMR users and 3GPP MC users S6-171838 LS in  
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑180044 Response LS on voice service continuity from 5G to 2/3G SP-171078 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
YesBT commented that this wasn't a priority as discussed in SA plenary since the work item was going to Rel-16.
 		noted No    
S3‑180045 LS on secure storage and processing of subscription credentials S1-173475 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		postponed No    
S3‑180046 LS on security during Resume reject in INACTIVE state in NR R2-1712052 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		replied to No    
S3‑180047 LS on Extension of USAT Application Pairing mechanism C6-170737 LS in  
6.13GPP Working Groups
 		Yes
YesBT: We can have multiple ISIMs in the same UICC, what’s the impact of this? Qualcomm: what's the use case for the ISIM? Gemalto: VoLTE relying on the IMS would be the use case, not M2M specific. Gemalto proposed to respond that there was no requirement but that SA3 would look at it.
 		replied to No    
S3‑180048 How AMF and SEAF deal with null-scheme SUCI CATT pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180049 Privacy requirement improvement related to using non null-scheme CATT pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
YesVodafone disagreed. It’s the ME, not the UE. This was agreed.
 		revised No S3‑180460  
S3‑180050 Privacy requirement of using SUCI in initial registration procedure CATT pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180051 Solution for meeting LI and privacy requirements CATT pCR Approval
7.2.14.1SUPI and LI
 		Yes
YesBT: this is far more reliable for LI.
 		noted No    
S3‑180052 Solution for raw public key provisioning CATT pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180053 Adding context on key setting CATT pCR Approval
7.2.2.2Key derivation NAS related
 		Yes
Yes
 		merged No S3‑180430  
S3‑180054 Adding the abbreviations of NF and NFR CATT pCR Approval
7.2.13.7Editorials
 		Yes
YesDT: NRF is not agreed in SA2 in yet. Agreed to add only NF and wait for SA2 for the other acronym.
 		revised No S3‑180364  
S3‑180055 Clarification on 5G security context CATT pCR Approval
7.2.6.6Miscellaneous
 		Yes
Yes
 		revised No S3‑180446  
S3‑180056 Proposal for UP integrity protection activation CATT pCR Approval
7.2.4.1Userplane open issues
 		Yes
Yes
 		noted No    
S3‑180057 Discussion on Identity Request and Registration Procedures in 5G KPN discussion Approval
7.2.14.4Miscellaneous
 		Yes
Yes
 		not treated No    
S3‑180058 LS to SA2 on Registration Request and Identity Request with clear text SUPI KPN other Approval
7.2.14.4Miscellaneous
 		Yes
Yes
 		not treated No    
S3‑180059 Adding the subscription identification procedure to TS 33.501 KPN, Nokia pCR Approval
7.2.14.4Miscellaneous
 		Yes
Yes
 		not treated No    
S3‑180060 Discussion on PC-5 security KPN discussion Endorsement
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesHuawei: PC-5 needs to be security protected. This is specified in the solution 8 of the TR. SA2 has concluded their work on this, so no reason to send an LS.
 		noted No    
S3‑180061 Discussion and pCR on authorization 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‑180062 Resolving Editor's Note in clause 5.3 KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑180063 Resolving Editor's Note in clause 6.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‑180064 Resolving Editor's Note and adding evaluation in clause 6.4.3 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‑180407  
S3‑180065 Evaluation of solution #6 KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑180066 Evaluation of solution #13 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‑180067 Miscellaneous editorials to TR 33.843 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‑180068 Adding conclusions for key issues 1,4, and 5 and adding an overal conclusions clause KPN pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180411  
S3‑180069 PCR to Section 6.12.2 InterDigital, Inc. pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180070 Adding numbers to the figure for EAP AKA prime KPN pCR Approval
7.2.8.7Editorial corrections
 		Yes
Yes
 		merged No S3‑180344  
S3‑180071 Adding numbers to the figure for 5G AKA KPN pCR Approval
7.2.8.7Editorial corrections
 		Yes
Yes
 		revised No S3‑180396  
S3‑180072 Conclusions from IPX Security Conference calls KPN report Information
7.2.13.1Interconnect (SEPP related)
 		Yes
YesVodafone commented that this misrepresented what was agreed in the meeting in the first line.
 		noted No    
S3‑180073 Removing Editor's note on network sharing KPN pCR Approval
7.2.8.6Authentication in Network sharing/limited deployment scenarios
 		Yes
Yes
 		approved No    
S3‑180074 Normative text for support of both authentication methods and text clarification to distinguish HN and SN Nokia pCR Decision
7.2.8.7Editorial corrections
 		Yes
YesVodafone: note 0 is just describing what roaming is. This is not necessary.The phrase with "allows that" is not well written. MCC commented that NOTE 3 was containing a requirement and that wasn't possible as described in the drafting rules. It was decided to reword "mandatory to support" to "shall support" and remove "in the present release".
 		revised No S3‑180395  
S3‑180075 Editorial clarification in clause on anchor key binding Nokia pCR Decision
7.2.8.7Editorial corrections
 		Yes
Yes
 		approved No    
S3‑180076 Resolving editors notes in clause on key hierarchy Nokia pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180447  
S3‑180077 UDM requirements - key management and privacy - S3-173121 Nokia pCR Decision
7.2.14.3SIDF
 		Yes
Yes
 		not treated No   S3‑173121
S3‑180078 SUCI intro and handling - was S3-173316 Nokia, KPN pCR Decision
7.2.14.5Editorials
 		Yes
Yes
 		not treated No   S3‑173316
S3‑180079 HN authorization of serving network actions directed to the UE Nokia, KPN discussion Discussion
7.2.14.2SUCI and Schemes
 		Yes
YesDocomo: we agreed to have no mechanisms to send the SUPI in the clear. Nokia: this is in 4G. Vodafone: you shouldn’t send the SUPI in 4G.
 		noted No    
S3‑180080 Privacy related function in UDM - Authorization proof Nokia, KPN pCR Decision
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180081 Requirement on AMF related to HN authorization Nokia, KPN pCR Decision
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180082 Requirement on AMF related to LI Nokia pCR Approval
7.2.14.1SUPI and LI
 		Yes
Yes
 		revised No S3‑180458  
S3‑180083 LI conformity when privacy is used - was S3-173124 Nokia, Orange, T-Mobile USA pCR Approval
7.2.14.1SUPI and LI
 		Yes
Yes
 		noted No   S3‑173124
S3‑180084 Resolving editors note on emergency call handling Nokia pCR Decision
7.2.14.5Editorials
 		Yes
Yes
 		not treated No    
S3‑180085 Authorization of SN by UE - was S3-173125 Nokia, LG Electronics pCR Decision
7.2.7.1Miscellaneous
 		Yes
YesORANGE: in the case of roaming, if the UE has selected cyphering as compulsory and the visited network has no cyphering, the UE will not connect to any network. This is hard to sell. AT&T: tell the user that they are going to connect in a non-secure way. He can have the choice.
 		revised No S3‑180454 S3‑173125
S3‑180086 Visibility and configurability supporting serving network authorization - was S3-173126 Nokia, LG Electronics pCR Approval
7.2.7.1Miscellaneous
 		Yes
YesEricsson: why having a list of countries in the USIM? Countries split and change all the time. Docomo: countries seem to be reasonably stable, it's not so often that they change. Vodafone: this has been in the SIM card since Rel-5. Country codes and network names are already recorded there. This has been used regularly. I don’t agree with having the user turning it off.
 		merged No S3‑180454 S3‑173126
S3‑180087 Preventing bidding down between 5G releases - was S3-173128 Nokia, KPN, LG Electronics pCR Approval
7.2.5.9Miscellaneous
 		Yes
Yes
 		noted No   S3‑173128
S3‑180088 Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.14 Nokia CR Agreement
7.6.16Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesMCC commented that normative language cannot be used in Notes ("shall", "should"), which are just informative in nature and cannot be used for requirements and recommendations. The content was fine but the distinction of normative/recommendation and informative text had to be worked offline. The editor's note was removed and added to the report as action item: "It is FFS on how details should be added to the SCAS to indicate whether requirements and associated test cases are applicable to all units or boards within a Network Product."
 		revised No S3‑180419  
S3‑180089 Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.15 Nokia CR Agreement
7.6.16Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
YesMCC pointed out that this CR wasn't necessary since the latest version of the spec is in Rel-14.
 		not pursued No    
S3‑180090 Collection of changes based on feedback from GSMA SECAG - CR to 33.916v1 Rel.14 Nokia CR Agreement
7.6.16Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		revised No S3‑180420  
S3‑180091 Collection of changes based on feedback from GSMA SECAG - CR to 33.916v1 Rel.15 Nokia CR Agreement
7.6.16Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		not pursued No    
S3‑180092 Clause 6 Corrections for 5G AKA over n3gpp access Nokia pCR Approval
7.2.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No    
S3‑180093 Multiple NAS Security Discussion Nokia discussion Agreement
7.2.5.7Multi-NAS security
 		Yes
YesThese proposals were agreed earlier.
 		noted No    
S3‑180094 Clause Annex D Nokia pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180095 Clause 6.3.4.2 Multiple Registration in same PLMN Nokia pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		revised No S3‑180399  
S3‑180096 Clause 6.4.2.2 Multiple active NAS connections in same PLMN Nokia pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		revised No S3‑180400  
S3‑180097 Clause 6.4.5 Handling of NAS counts Nokia pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		revised No S3‑180421  
S3‑180098 Clause 6.2.3 Handling of user related keys Nokia pCR Approval
7.2.2.4Miscellaneous
 		Yes
Yes
 		merged No S3‑180430  
S3‑180099 Security Algorithms Negotiation for Initial AS security context Huawei; HiSilicon;China Mobile pCR Approval
7.2.4.2Userplane security
 		Yes
YesDiscussed with 271.
 		merged No S3‑180425  
S3‑180100 AS Security Negotiation and Activation Huawei; HiSilicon pCR Approval
7.2.4.2Userplane security
 		Yes
YesNokia: Don’t specify what is cyphered. Huawei agreed to remove this part.
 		revised No S3‑180426  
S3‑180101 Meeting SUPI privacy and LI Requirements Huawei, Hisilicon, Intel pCR Approval
7.2.14.1SUPI and LI
 		No
Yes
 		revised No S3‑180206  
S3‑180102 Moving UE handling SUCI to SUCI clause Huawei, Hisilicon, CMCC pCR Approval
7.2.14.5Editorials
 		Yes
Yes
 		not treated No    
S3‑180103 Adding Forward & Backward Security definition Huawei, Hisilicon pCR Approval
7.2.4.4Miscellaneous
 		Yes
YesEricsson had a proposal to generalize these definitions, instead of a KgNB. MCC commented that requirements were not allowed in definitions so the shall had to go.
 		revised No S3‑180429  
S3‑180104 Flexible retaining AS keys solution Huawei, Hisilicon, CMCC pCR Approval
7.2.3.1Key derivations during handovers
 		Yes
YesNokia didn’t agree with these changes. The first paragraph was new to them. Ericsson opposed to this as well, so it was finally noted.
 		noted No    
S3‑180105 Intra-gNB retaining AS keys exception Huawei, Hisilicon, CMCC pCR Approval
7.2.3.1Key derivations during handovers
 		Yes
YesThis was taken offline as Ericsson had some issues with the changes.
 		revised No S3‑180433  
S3‑180106 Address EN in requirements for gNB setup and configuration Huawei, Hisilicon, pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		approved No    
S3‑180107 Requirements for UP and CP for the gNB Huawei, Hisilicon, CMCC pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180456  
S3‑180108 Security Procedures between 5G Network Functions Huawei, Hisilicon pCR Approval
7.2.12.1Miscellaneous
 		Yes
YesReworded to "shall be supported".
 		revised No S3‑180367  
S3‑180109 The impaction of 256 bit keys for NG areas CATT other  
8.4Other study areas
 		Yes
Yes
 		withdrawn Yes    
S3‑180110 The clarification of the entropy CK and IK CATT other  
8.4Other study areas
 		Yes
Yes
 		withdrawn Yes    
S3‑180111 Adding content to NAS security Huawei, Hisilicon pCR Approval
7.2.5.4NAS integrity and confidentiality mechanisms
 		Yes
Yes
 		merged No S3‑180400  
S3‑180112 Adding key issue to Living Document S3-173482 Huawei, Hisilicon; Samsung other Approval
7.2.16PLMN RAT selection
 		Yes
Yes"..during the registration process" is solution-specific. This was agreed to be removed. Vodafone: 3.1 is a new clause and we don’t think that the title is an issue. Altering and blocking have different solutions; they should not be combined.The requirements need to be reworded. The clause title and requirements were changed as proposed by Vodafone.
 		revised No S3‑180369  
S3‑180113 Adding potential solution for living document S3-173482 Huawei, Hisilicon; Samsung other Approval
7.2.16PLMN RAT selection
 		Yes
YesVodafone disagreed: This is a strong financial incentive for the networks to do as little authentication as they can. NTT-Docomo agreed and added that it should be written into the evaluation clause. Huawei: this is a CT1 decision. It was agreed to let CT1 know with an LS (contained in 373) that they should not to continue work on this solution. Samsung didn't find any technical reasons to reject this.
 		revised No S3‑180372  
S3‑180114 Interworking with EPC without N26 interface in single-registration mode Huawei, Hisilicon pCR Approval
7.2.10.6Miscellaneous
 		Yes
YesEricsson: too much text; security-wise we just refer to 33.401. Nokia agreed.
 		revised No S3‑180444  
S3‑180115 Clarification of Introduction 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
YesVodafone: the introduction is too obscure. The whole clause needs rewriting.ORANGE agreed. Vodafone: it needs to properly introduce the service and be increased in size.
 		revised No S3‑180405  
S3‑180116 Delete Editor’s notes in clause 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‑180117 Clarification of solution #4 Huawei, Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180407  
S3‑180118 Clarification of solution #8 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‑180119 Add Evaluation for Solution #12 Huawei, Hisilicon 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‑180409  
S3‑180120 Clarification of solution #7 Huawei, Hisilicon pCR Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
YesORANGE: remove "minor" from the impact.
 		revised No S3‑180408  
S3‑180121 Conclusion for the Key Issues Huawei, Hisilicon 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‑180411  
S3‑180122 Add Evaluation for Solution #6 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‑180123 Add Evaluation for Solution #13 Huawei, Hisilicon 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‑180410  
S3‑180124 Discussion on deleting KSEAF from key hierarchy Huawei, Hisilicon discussion Endorsement
7.2.1.1Miscellaneous
 		Yes
YesQualcomm and DT disagreed.China Mobile supported this contribution. Nokia commented that they assume that SA2 doesn’t want a standalone SEAF. ORANGE: send an LS to SA2, as we are speculating what they are doing with SEAF and AMF in phase two. The Chair asked for a show of hands for this document: In favour of 124: China Mobile, Ericsson, Huawei,ZTE,Nokia Opposed to 124: DT, Qualcomm, Docomo, BT, KPN,NCSC, NEC This had to be taken offline for conversations with SA2. It was finally noted, may be considered later in phase two.
 		noted No    
S3‑180125 Clarification on security in AMF change within an AMF set Huawei, Hisilicon pCR Approval
7.2.3.3Security in AMF change within an AMF set
 		Yes
Yes
 		noted No    
S3‑180126 Removal of the number of AVs requested in Authentication Information Request message Huawei, Hisilicon pCR Approval
7.2.8.15G AKA over 3gpp/non3gpp access
 		Yes
YesKPN wasn't happy with the 5G HE AV being configured in the UDM. BT supported this point, but there was no other support for this. Only the first change was agreed.
 		revised No S3‑180391  
S3‑180127 Resolve Editor’s Note in clause 6.1.3.2 of TS 33.501 Huawei, Hisilicon pCR Approval
7.2.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		noted No    
S3‑180128 Adding 5G Authentication Confirmation Answer for 5G-AKA Huawei, Hisilicon pCR Approval
7.2.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		merged No S3‑180393  
S3‑180129 pCR to TS 33.501 Security Handling for RRC Connection Re-establishment Procedure Huawei, Hisilicon pCR Approval
7.2.4.3RRC security
 		Yes
YesEricsson: postpone this since it's a new feature, different from LTE and may be better to present it in RAN. Nokia agreed. This topic was postponed and it will be brought back in the next meetings after offline discussion.
 		noted No    
S3‑180130 Draft Reply LS on security during Resume reject in INACTIVE state in NR Huawei, Hisilicon LS out Approval
7.2.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180131 Discussion on security during Resume reject in INACTIVE state in NR Huawei, Hisilicon discussion Endorsement
7.2.4.3RRC security
 		Yes
YesEricsson: check with RAN2 the signalling of the figure.We cannot require additional signalling for a situation that is not critical. Intel: keep the solution simple.RAN doesn’t want to add integrity check to reduce the additional load in the network. Huawei: we have to tell RAN that there is a security issue and propose a solution. They will decide if there is too much signalling or not. Nokia: don't load the gNodeB with more signalling.
 		noted No    
S3‑180132 Delete allowed NSSAI in NAS SMC Huawei, Hisilicon pCR Approval
7.2.5.5NAS Security Mode Command
 		Yes
Yes
 		approved No    
S3‑180133 Discussion on Protection of initial NAS message Huawei, Hisilicon discussion Endorsement
7.2.5.2Protection of initial NAS message
Yes
YesKPN,Vodafone and Qualcomm disagreed with this contribution.
 		noted No    
S3‑180134 pCR to TS 33.501 delete protection of initial NAS message Huawei, Hisilicon pCR Approval
7.2.5.2Protection of initial NAS message
Yes
Yes
 		noted No    
S3‑180135 pCR to TS 33.501 key identification Huawei, Hisilicon pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180430  
S3‑180136 pCR to TS 33.501 key lifetimes Huawei, Hisilicon pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		merged No S3‑180430  
S3‑180137 Clean up the EN in 6.1.3.1 Huawei, Hisilicon pCR Approval
7.2.8.2EAP AKA’ over 3gpp/non3gpp access
 		Yes
Yes
 		revised No S3‑180344  
S3‑180138 Clean up the EN in 6.2.1 Huawei, Hisilicon pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180448  
S3‑180139 Procedures for security context transfer in idle mode mobility Huawei, Hisilicon pCR Approval
7.2.3.6Miscellaneous
 		Yes
YesNokia: this needs a terminology cleanup.
 		revised No S3‑180435  
S3‑180140 Subscription identification procedure Huawei, Hisilicon pCR Approval
7.2.14.4Miscellaneous
 		Yes
Yes
 		not treated No    
S3‑180141 Corrections on NAS security mode command procedure (subclause 6.7.2) Huawei, Hisilicon pCR Approval
7.2.5.10Editorials
 		Yes
Yes
 		approved No    
S3‑180142 Scope of CAPIF security Huawei, Hisilicon pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		No
Yes
 		revised No S3‑180207  
S3‑180143 Security requirements on CAPIF entities Huawei, Hisilicon pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		No
Yes
 		revised No S3‑180208  
S3‑180144 Additional security requirements for 3rd party API provider Huawei, Hisilicon pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180392  
S3‑180145 Delete the mandatory implementation of NIA0 in gNB Huawei, Hisilicon pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180431  
S3‑180146 Change the support of NIA0 in SgNB for ENDC Huawei, Hisilicon CR Approval
7.1EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
YesVodafone: we had decided to keep this in the last meeting. Nokia commented that there was no need to disable it. Unauthenticated emergency calls may change this based on some LS responses that SA3 is waiting for, so we would have to change this in any case. Better to wait until we get the feedback from SA2 and others. Postponed for the next meeting.
 		postponed No    
S3‑180147 Idle mode mobility from 5GS to EPS with N26 Huawei, Hisilicon pCR Approval
7.2.10.2Idle mode 5G-4G
 		Yes
Yes
 		merged No S3‑180440  
S3‑180148 Handover procedure from 5GS to EPS with N26 Huawei, Hisilicon pCR Approval
7.2.10.3Handover 5GC-EPS
 		Yes
Yes
 		merged No S3‑180441  
S3‑180149 pCR to TS 33.501 Key Handing at Transitions between RRC-INACTIVE to RRC-CONNECTED states Huawei, Hisilicon pCR Approval
7.2.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180150 pCR to TS 33.501 Key Handing during mobility in RRC-INACTIVE state Huawei, Hisilicon pCR Approval
7.2.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180151 pCR to TS 33.501 AS algorithm selection in state transitions between RRC-INACTIVE to RRC-CONNECTED states Huawei, Hisilicon pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180152 Authentication in the service registration procedure Huawei, Hisilicon pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesNokia preffered to have the authentication to be done in the transport layer (e.g. using certificates) instead of the application layer. Vodafone asked: If using transport level, can we have different levels of service? Huawei replied that this was the case. Ericsson: if there is a proxy in between this might not work. This is not the way to go. Deutsche Telekom: preconfiguring RAND is odd.
 		noted No    
S3‑180153 [eMCSec] 33180 R15 IWF security Motorola Solutions UK Ltd. CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180386  
S3‑180154 Authorization of NF service discovery Huawei, Hisilicon pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesChina Mobile: add an editor's note about NF instance to be releaved to the NRF in HPLMN. Ericsson: this can be summarised in a couple of sentences, it's overly complicated.
 		revised No S3‑180360  
S3‑180155 Authorization of NF service access Huawei, Hisilicon other Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesContribution to the living document.
 		approved No    
S3‑180156 [eMCSec] 33.180 R15 Interworking media and signaling Motorola Solutions UK Ltd. CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180376  
S3‑180157 Authorization of SCS/AS to send requests for the 3GPP Network Entity Huawei, Hisilicon CR Approval
7.4Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
 		Yes
YesORANGE: we cannot adapt to all types of third party networks. You are proposing an authorization mechanism here, not a security procedure. ORANGE wasn't convinced why it is for multiple authorization mechanisms.Keep only the first sentence. We need an authorization mechanism, but which one is not clear. It was clarified that this was a contribution to the draft CR from the previous meeting, so the type had to be changed to "other". It was asked to be minuted that OATH is a good candidate for this. There was no consensus on this so Huawei decided not to pursue this.
 		not pursued No    
S3‑180158 [eMCSec] 33180 R15 Interworking key mgmt (InterSD) Motorola Solutions UK Ltd. CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180413  
S3‑180159 [eMCSec] 33180 R15 Interworking key mgmt (MCData) Motorola Solutions UK Ltd. CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		withdrawn Yes    
S3‑180160 [eMCSec] 33180 R15 Interworking SeGy clarification Motorola Solutions UK Ltd. CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180386  
S3‑180161 [FS_MC_Sec] 33880 Interworking eval (InterSD) Motorola Solutions UK Ltd. CR Agreement
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180414  
S3‑180162 [FS_MC_Sec] 33880 Interworking eval (MCData) Motorola Solutions UK Ltd. CR Agreement
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-15)
 		Yes
Yes
 		withdrawn Yes    
S3‑180163 New WID for MONASTERY security Motorola Solutions UK Ltd. WID new Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
YesIt was commented whether it was possible to add a new objective in the existing WID instead of a new WID. MCC commented that for tracking-in-3GPP purposes and given that it was a new topic, it was better to have a separate WID. It was pointed out that this was a Rel-15 WID, so the work would be brought for the next Bis meeting as well.
 		revised No S3‑180385  
S3‑180164 NF Service Discovery Request Procedure Intel pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		noted No    
S3‑180165 NF Service Request Procedure Intel other Approval
7.2.13.5NF-NF Authentication & Authorization
 		Yes
YesDecided to include it in the living document.
 		revised No S3‑180363  
S3‑180166 ID linkage verification in secondary authentication Huawei & Hisilicon pCR Approval
7.2.9.3Efficiency / security improvement
 		Yes
YesORANGE: sending the IMSI to a third party? This has privacy issues, it's internal to the network. There wasn't any support for this change.
 		noted No    
S3‑180167 DN authorization grant and revocation Huawei & Hisilicon pCR Approval
7.2.9.2Incomplete procedure
 		Yes
YesEricsson: SA2 makes these kind of decisions.What security issues or threats are we addressing here? We cannot redefine PDU procedures. Qualcomm agreed with Ericsson. There wasn't much support for this document, so it was noted. Huawei commented that the procedure was missing and needed to be there.
 		noted No    
S3‑180168 Secondary Authentication for multiple PDU sessions Huawei & Hisilicon pCR Approval
7.2.9.3Efficiency / security improvement
 		Yes
Yes
 		approved No    
S3‑180169 A key issue proposal on security capability for TR33.811 Huawei, Hisilicon, China Moible, China Unicom, CATR, CATT pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
YesVodafone had issues with the term "network operator", there are better terms in SA3 terminology. ORANGE: the threats don’t seem to be threats, only the last one. ORANGE: We don’t need to define all security options that are available for a network slice because they are in TS 33.401 already. NCSC: catalog the options that are available instead of relying on 33.401.
 		revised No S3‑180437  
S3‑180170 A key issue proposal on security level Huawei, Hisilicon, China Moible, China Unicom, CATR, CATT pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
YesBT: "level" implies some kind of judgment. Better use "security profile". NCSC: these are the same key issues as the last one. Vodafone didn’t like the idea of standardising different security profiles; it would restrict the market. Better to define the parameters that describe the profile instead of defining the profile. KPN didn’t support this contribution. NCSC: these requirements are not requirements, they need some work. It was decided to note this contribution and work on 169.
 		noted No    
S3‑180171 A key issue proposal on isolation degree Huawei, Hisilicon, China Moible, China Unicom, CATR, CATT pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
YesVodafone: isolation changes second by second in a SBA. It cannot be a criteria. ORANGE supported Vodafone. Huawei commented that the term "isolation" was used by SA5. BT commented that SA5 has a catalog of features; when they are not available this doesn’t mean that there is isolation. Vodafone commented that regardless of what SA5 has worked on, isolation cannot be guaranteed. The Vice Chair (Alf) encouraged Huawei to work on this offline and come back in the next meeting if they had any agreements.
 		noted No    
S3‑180172 draft LS on the status of work on interfaces Huawei & Hisilicon LS out Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180436  
S3‑180173 Security Procedures for EAP-TLS Huawei, Hisilicon, Ericsson, Qualcomm Incorporated, China Mobile pCR Approval
7.2.8.4Authentication using EAP TLS
 		Yes
YesORANGE: Add an editor's note about the privacy of the private certificate. Also on how the UDM is involved in this procedure. BT: add that there is no support of roaming. ORANGE: Key hierarchy is FFS.
 		revised No S3‑180394  
S3‑180174 pCR for overview of 5G security architecture Huawei, Hisilicon, China Mobile, CATR, ZTE pCR Approval
7.2.1.1Miscellaneous
 		Yes
YesVodafone: it's not readable in black and white. Nokia: not a clear representation and it's misleading. Dragan(IDEMIA) agreed. Huawei: we are just showing the main points. The figure was not clear enough for the companies. Nokia clarified that there was a similar picture in 33.401. The consensus was that such figure could be welcome but some discussions were needed to agree on a figure.
 		noted No    
S3‑180175 UP policy Huawei, Hisilicon, pCR Approval
7.2.4.1Userplane open issues
 		Yes
YesDiscussed with 286. Ericsson: some aspects are still ongoing work in SA2 and they can be fixed later. Merged with 286.
 		revised No S3‑180423  
S3‑180176 Modification of Kausf Huawei, Hisilicon, pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		merged No S3‑180395  
S3‑180177 Merge two procedures of SBA authorization Huawei, Hisilicon, other Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		approved No    
S3‑180178 Key distribution and key derivation scheme Huawei, Hisilicon, pCR Approval
7.2.1.1Miscellaneous
 		Yes
YesDocomo: the note is a definition and it needs to be checked if the definition applies to the whole spec. There were some issues as well with the figure 6.2.2-1.
 		revised No S3‑180450  
S3‑180179 Confidentiality protection of NSST Huawei, Hisilicon, pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑180180 Confidentiality protection of NSI monitoring data Huawei, Hisilicon, pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑180181 Replay protection for UP, RRC and NAS Huawei, Hisilicon, pCR Approval
7.2.4.4Miscellaneous
 		Yes
YesNokia: Replay protection is built-in in the protocol, no need to add this. China Mobile: replay protection is a different requirement so we agree with Huawei.
 		approved No    
S3‑180182 Integrity for UP, RRC and NAS Huawei, Hisilicon, pCR Approval
7.2.4.5Editorials
 		Yes
Yes
 		merged No S3‑180422  
S3‑180183 Confidentiality for UP, RRC and NAS Huawei, Hisilicon, pCR Approval
7.2.4.5Editorials
 		Yes
Yes
 		merged No S3‑180422  
S3‑180184 NF Service Register Request Procedure Intel pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesEricsson didn’t support this method. NTT-Docomo and DT: use certificates. Ericsson agreed to use them for authorization, they preferred to use standardised solutions in any case. Intel: registration request and response is coming from SA2, this is not a new method. We are adding protection for that. Intel clarified that this is for authentication.
 		revised No S3‑180358  
S3‑180185 Security requirements for Service Request Intel pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesChina Mobile argued that there was no need to have the sessions.The communication can be secured by the signalling, no need to have a secure session.Whether it is session based or not, that's another discussion. Ericsson: pre-configured discovery between the two NFs, how is the second requirement fulfilled? Intel: it is assuming that there is no pre-configuration.
 		revised No S3‑180361  
S3‑180186 Solution to prevent unauthorized access to external Data Network Intel pCR Approval
7.2.9.1MitM
 		Yes
Yes
 		noted No    
S3‑180187 Discussion paper on voice service continuity between 5G and 3G China Unicom, Huawei, HiSilicon, ZTE, CATR, OPPO discussion  
8.5New study item proposals
 		Yes
Yes
 		noted No    
S3‑180188 New study item on Security aspects of single radio voice continuity from 5G to 3G China Unicom, Huawei, HiSilicon, ZTE, CATR, OPPO SID new  
8.5New study item proposals
 		Yes
YesAlex (BT): 2G needs to be removed from here. The SA plenary position was to agree to do this for 3G. This could be a WID for Rel-16 instead, and wait for the work done in SA1. KPN:opening a WID, how do we capture our thoughts? Keep it as SID. NTT-Docomo: Remark that this is 5G to UTRAN CS.
 		revised No S3‑180384  
S3‑180189 Discussion paper on encrypted traffic detection and verification China Unicom, Huawei, HiSilicon, ZTE, CATR, OPPO discussion  
8.5New study item proposals
 		Yes
Yes
 		noted No    
S3‑180190 Study on security aspects of encrypted traffic detection and verification China Unicom, ZTE, Huawei, HiSilicon, CATR, OPPO SID new  
8.5New study item proposals
 		Yes
YesEricsson: wait for SA2 to work further.Nokia agreed. There wasn't much support for this Study item.
 		noted No    
S3‑180191 Key issue on topology hiding of the service China Unicom, China Mobile pCR  
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180392  
S3‑180192 ey issue on secure communication between functions in CAPIF China Unicom, China Mobile pCR  
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180392  
S3‑180193 draft Reply LS on security during Resume reject in INACTIVE state in NR Intel LS out Approval
7.2.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180194 Discussion on Security Issues with RRC Reject for INACTIVE Mode Intel discussion Discussion
7.2.4.3RRC security
 		Yes
YesEricsson: this doesn’t solve the problem. Intel: proposal 2 is an option, we recommend proposal one. Ericsson didn’t see any viable solution to be sent to RAN2. There are threats and we are aware of them, we can reply with this. Intel: RAN2 is not asking for a solution, it's just asking if there is any concern from SA3. It was decided to go for the reply LS in 349 and note the related documents here.
 		noted No    
S3‑180195 Binding Primary and Secondary authentication Intel discussion Endorsement
7.2.9.1MitM
 		Yes
Yes
 		noted No    
S3‑180196 Secondary Re-Authentication Intel pCR Approval
7.2.9.2Incomplete procedure
 		Yes
Yes
 		revised No S3‑180379  
S3‑180197 Discussion on the enhancement of SUCI construction scheme LG Electronics discussion Discussion
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180198 Additional input for SUCI construction - Annex C. LG Electronics pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180199 Draft LS on the security of a known part of plaintext for subscription identifier LG Electronics LS out Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180200 Clarification of security visibility LG Electronics pCR Approval
7.2.7.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180453  
S3‑180201 Clarification on network slice access authentication and authorization LG Electronics pCR Approval
7.2.9.5Editorial and clarification
 		Yes
Yes
 		noted No    
S3‑180202 Add context for multiple registrations in the same PLMN Huawei, Hisilicon pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180203 Add a new requirement in scenario when UE has multiple registration in different PLMNs Huawei, Hisilicon pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		revised No S3‑180398  
S3‑180204 a new WID for 5G SCAS Huawei, Hisilicon WID new Approval
5Items for early consideration
 		Yes
Yes
 		revised No S3‑180334  
S3‑180205 new SID on security of 5WWC Huawei, Hisilicon SID new Agreement
8.5New study item proposals
 		Yes
YesORANGE: fourth bullet point, replace equipment with UE. The only equipment that can access the public network are the UE. Broadcom: consider the solution/s that SA2 will find. DT: subscription privacy of wired network entity? What's that? Qualcomm: time scales are too tight, the workload is high and this is not realistic. Vodafone: we object to this, we don’t have the time to work on this study item in SA3 given the workload. NTT-Docomo: tell SA that security work in this time scale is not realistic. BT: this work needs to be done, and the interest is evident from the list of supporting companies. The Chair suggested to work on this offline and bring it back for the next meeting. Vodafone commented that the list of supporting companies are coming from the SA2 work, not for this work item.
 		noted No    
S3‑180206 Meeting SUPI privacy and LI Requirements Huawei, Hisilicon, Intel, China Mobile, CATT pCR Approval
7.2.14.1SUPI and LI
 		Yes
Yes
 		noted No   S3‑180101
S3‑180207 Scope of CAPIF security Huawei, Hisilicon, China Mobile pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
YesNEC commented that the scope here was too short and needed more wording. The Vice Chair proposed to accept this and bring more proposals for the next meeting.
 		approved No   S3‑180142
S3‑180208 Security requirements on CAPIF entities Huawei, Hisilicon, China Mobile pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180392 S3‑180143
S3‑180209 Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity R2-1714124 LS in  
7.1EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑180210 Inter Operator Signalling Security in 5G Proposal Deutsche Telekom AG discussion Decision
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180211 Discussion and pCR for SUCI home routing China Mobile pCR Approval
7.2.14.3SIDF
 		Yes
YesVodafone: keys stored in something else that the AUSF? Ericsson: SIDF colocated in the UDM was the agreement and this is against that. Vodafone: Add extra bits for routing, no need for SIDF.ORANGE supported this. Nokia: postpone the discussion since this is changing an agreement. Huawei supported this. Nokia, Ericsson didn’t support this change in 5.5.1.Huawei commented that this is a problem that needs to be addressed.
 		noted No    
S3‑180212 Requirements on SIDF NEC Telecom MODUS Ltd. pCR Approval
7.2.14.3SIDF
 		Yes
Yes
 		not treated No    
S3‑180213 Discussion and pCR for privacy calculation in UE side China Mobile, ZTE pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180214 Updates to Clause 6.12.2 regarding protection scheme identification NEC Telecom MODUS Ltd. pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180215 Enhancing the security of the key KAMF China Mobile,Huawei, Hisilicon; Deutsche Telekom AG discussion Discussion
7.2.5.5NAS Security Mode Command
 		Yes
Yes
 		noted No    
S3‑180216 Handover from 5GS to EPS NEC Telecom MODUS Ltd. pCR Approval
7.2.10.3Handover 5GC-EPS
 		Yes
Yes
 		merged No S3‑180441  
S3‑180217 Enhance the security of the key KAMF in the NAS SMC procedure China Mobile; Huawei; Hisilicon; Deutsche Telekom AG discussion Discussion
7.2.5.5NAS Security Mode Command
 		Yes
Yes
 		noted No    
S3‑180218 Handover from EPS to 5GS NEC Telecom MODUS Ltd. pCR Approval
7.2.10.4Handover EPS-5GC
 		Yes
Yes
 		merged No S3‑180442  
S3‑180219 Updating NAS security mode command procedure China Mobile,Huawei, Hisilicon, Deutsche Telekom AG pCR Approval
7.2.5.5NAS Security Mode Command
 		Yes
Yes
 		noted No    
S3‑180220 Annex-DH usage modes, DH capability identifier and the calculation of KAMF' China Mobile, Huawei, Hisilicon, Deutsche Telekom AG pCR Approval
7.2.5.5NAS Security Mode Command
 		Yes
Yes
 		noted No    
S3‑180221 Adding details of K’AMF to clause 6.2.1 NEC Telecom MODUS Ltd. pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180449  
S3‑180222 New WID on GBA enhancements for Internet of Things China Mobile, CATR, China Unicom WID new Agreement
7.7New Work Item proposals
 		Yes
YesEricsson: it should be a study first and wider in scope, considering discussions in IETF. Qualcomm: in the objectives, which protocols other than HTTP? The Chair commented that the overal opinion seemed that the work should start with a study item first. ORANGE: include 5G in the scope, e.g. SSO in 5G. Nokia: there is no time to have a new study item given the workload with 5G. Vodafone expressed their concerns on study items taking out time for 5G items. BT suggested to handle every normative item in 5G as a priority before heading for study item work. The Chair pointed out that prioritization will serve that purpose and that contributions can be always accepted as a 3GPP working procedure. Gemalto: some study items are essential for future normative work, ORANGE: this should be decided each meeting, not as a general rule. The Chair decided to use prioritization in the next meetings. Vodafone wanted their objection recorded if this issue was commented in SA plenary; they preferred to have study items delayed until August. Ericsson asked to delay this study item for the next meeting in order to have internal discussions about it.There may be several studies in here. There was no agreement and the document was noted and expected to come back for the meeting SA3#91.
 		noted No    
S3‑180223 LS to CT3 CT4 on SBI Design and its Security Implications Deutsche Telekom AG LS out Approval
5Items for early consideration
 		Yes
YesDT commented that the security is best done at application layer level and tracing data should be protected. This needed a joint discussion with CT4. Vodafone: this release should secure a subset, and secure the whole thing properly in the next release. It is too rushed. Nokia: We don’t want to limit the progress of CT4's work. Nokia also preffered to have discussions with CT4. NTT-Docomo: delaying the work would not be advisable in this case. Vodafone: nobody will use this spec until the end of the next release, as seen with interconnect contacts. A single meeting cannot cover this whole work. The parties involved took the matter offline.
 		revised No S3‑180389  
S3‑180224 Security requirements on the CAPIF-4 reference point China Mobile, Huawei pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180392  
S3‑180225 Discussion and pCR about NF authentication for SBA China Mobile other Approval
7.2.13.5NF-NF Authentication & Authorization
 		Yes
YesContribution to the living document. NTT-Docomo commented that this will be a problem in the evaluation. BT was concerned that this suggests that whatever the vendors build is depending on the deployment of the operator. Vodafone commented that it was difficult to track what this contribution was affecting and how. The use of living documents was confusing. NTT-Docomo: this document is too vague, not clear what needs to be done. 264 displays Nokia's opinion on this issue.
 		noted No    
S3‑180226 [eMCSEC] Notifying the use of Security Gateways NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑180227 [eMCSEC] LS to SA6 on Security Gateway notification NCSC LS out Approval
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180387  
S3‑180228 [eMCSEC] Security Gateway clause update and move to annex NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		merged No S3‑180386  
S3‑180229 Document showing the changes to SeGy functionality NCSC discussion Discussion
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑180230 KAMF Derivation when AMF set changes during idle mode mobility Huawei; Hisilicon pCR Approval
7.2.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		merged No S3‑180434  
S3‑180231 Interworking: Handover from EPS to 5GS Nokia pCR Approval
7.2.10.4Handover EPS-5GC
 		Yes
Yes
 		revised No S3‑180442  
S3‑180232 Interworking: Handover from 5GC to EPS Nokia pCR Approval
7.2.10.3Handover 5GC-EPS
 		Yes
Yes
 		merged No S3‑180441  
S3‑180233 Interworking: Idle mode mobility from EPS to 5GS Nokia pCR Approval
7.2.10.1Idle mode 4G-5G
 		Yes
Yes
 		merged No S3‑180439  
S3‑180234 Interworking; Idle mode mobility from 5G to 4G Nokia pCR Approval
7.2.10.2Idle mode 5G-4G
 		Yes
Yes
 		revised No S3‑180440  
S3‑180235 Adding Emergency Services paragraph for Subscription Identification procedure KPN N.V. pCR Approval
7.2.14.4Miscellaneous
 		Yes
Yes
 		not treated No    
S3‑180236 Secondary authentication: Clause 12.1.2: Resolve ENs Nokia pCR Approval
7.2.9.5Editorial and clarification
 		Yes
Yes
 		approved No    
S3‑180237 Secondary Authentication: Align with SA2 procedure and removal of EN on making the figure updatable Nokia pCR Approval
7.2.9.4Miscellaneous
 		Yes
Yes
 		merged No S3‑180380  
S3‑180238 SBA: Prioritization for Phase 1 Nokia pCR Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑180353  
S3‑180239 SBA: Resolve EN on Information Elements that require protection Nokia other Approval
7.2.13.2Protection of Attributes
 		Yes
Yes
 		revised No S3‑180354  
S3‑180240 Protecting the IMSI and IMEI in NAS Security Mode Command Qualcomm Incorporated discussion Endorsement
7.2.14.1SUPI and LI
 		Yes
YesBT: if we are forced to turn NAS encryption off, it's doubtful we can encrypt partially in all scenarios. Verizon: we can protect privacy without having to encrypt the IMSI. IMEI is a device parameter, not an user parameter. Docomo: much cheaper to change the IMSI than the IMEI. Docomo: the question is: are we allowed to protect IMSI even if the encryption is not there? Nokia: ask SA3-LI with an LS if we are allowed to send the IMSI at all in this situation. BT: UE needs to send IMSI in some form. The restriction would be you can’t send it when NAS encryption is off. I wouldn’t like that option as BT. Alex commented that a possible LS would not be answered until after the SA3#90Bis meeting.
 		noted No    
S3‑180241 Removing allowed NSSAI from NAS Security Mode procedure Qualcomm Incorporated pCR Approval
7.2.5.5NAS Security Mode Command
 		Yes
Yes
 		noted No    
S3‑180242 Removal of the hashing method from NAS SMC as security covered by the initial NAS message protection Qualcomm Incorporated pCR Approval
7.2.5.2Protection of initial NAS message
Yes
YesHuawei and Ericsson didn’t support this. Nokia had some issues as well. Vodafone was in favour of this contribution. DT supported this contribution since it protects the information as much as possible. There was no consensus on this contribution hence it was noted.
 		noted No    
S3‑180243 Adding a generic bid down solution to the 5G TS Qualcomm Incorporated pCR Approval
7.2.5.9Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180244 Discussion on the whether there is a need for one NAS SMC to change the security context on both 3GPP and non-3GPP access in the same PLMN Qualcomm Incorporated discussion Endorsement
7.2.5.7Multi-NAS security
 		Yes
YesEricsson and Nokia commented that there many more details behind. Huawei: it's not clear enough, too generic. The Chair saw that in general people agreed on this but a more detailed statement would be needed.
 		noted No    
S3‑180245 Discussion on completing the LTE bidding down procedures Qualcomm Incorporated discussion Discussion
7.6.1SAE/LTE Security
 		Yes
Yes
 		noted No    
S3‑180246 Discussion on the use of the serving network identity to generate keys that are used in the AUSF Qualcomm Incorporated discussion Discussion
7.2.4.4Miscellaneous
 		Yes
YesNo one saw an issue in the key derivation in the AUSF. The document was noted.
 		noted No    
S3‑180247 Adding references to the algorithm test data Qualcomm Incorporated pCR Approval
7.2.17Others
 		Yes
Yes
 		revised No S3‑180416  
S3‑180248 Adding requirements on CU-DU split based on the key derivation used Qualcomm Incorporated pCR Approval
7.2.4.4Miscellaneous
 		Yes
YesEricsson didn’t agree with the requirement. This was taken offline.
 		noted No    
S3‑180249 Identifying problems with secondary authentication Qualcomm Incorporated pCR Approval
7.2.9.1MitM
 		Yes
Yes
 		noted No   S3‑173301
S3‑180250 pCR to update the secondary authentication procedure to include the authentication/authorization confirmation between UE and SMF when a key generating EAP method is used Qualcomm Incorporated pCR Approval
7.2.9.3Efficiency / security improvement
 		Yes
Yes
 		noted No   S3‑173302
S3‑180251 pCR to update the secondary EAP authentication clause to take into account the roaming scenario Qualcomm Incorporated pCR Approval
7.2.9.2Incomplete procedure
 		Yes
Yes
 		revised No S3‑180380 S3‑173303
S3‑180252 pCR to provide a normative text for handover from 5GC to EPC Qualcomm Incorporated pCR Approval
7.2.10.3Handover 5GC-EPS
 		Yes
Yes
 		revised No S3‑180441 S3‑173305
S3‑180253 pCR to provide a normative text for handover from EPC to 5GC Qualcomm Incorporated pCR Approval
7.2.10.4Handover EPS-5GC
 		Yes
Yes
 		merged No S3‑180442 S3‑173305
S3‑180254 pCR to provide a text for idle mode mobility from 5GC to EPC Qualcomm Incorporated pCR Approval
7.2.10.2Idle mode 5G-4G
 		Yes
Yes
 		merged No S3‑180440 S3‑173305
S3‑180255 pCR to provide a text for idle mode mobility from EPC to 5GC Qualcomm Incorporated pCR Approval
7.2.10.1Idle mode 4G-5G
 		Yes
Yes
 		merged No S3‑180439 S3‑173305
S3‑180256 User plane integrity protection granularity Qualcomm Incorporated pCR Approval
7.2.4.1Userplane open issues
 		Yes
YesNoted as it was simialr to 286.
 		noted No    
S3‑180257 Keys in the UE Qualcomm Incorporated pCR Approval
7.2.2.4Miscellaneous
 		Yes
Yes
 		merged No S3‑180452  
S3‑180258 Support of privacy schemes and profiles by the UE Qualcomm Incorporated pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
YesVodafone: cool wit this as long as it is not just a single scheme.
 		noted No    
S3‑180259 pCR: Multiple Registrations in different PLMNs using K_AUSF (Updated) Qualcomm Incorporated pCR Approval
7.2.6.1Multiple registrations
 		Yes
YesDiscussed together with 284. Ericsson: the whole solution is really complex and totally new, for being optional. Ericsson: this is an optimization that can be used later in phase two. Huawei and Intel supported this view.
 		noted No    
S3‑180260 SBA: Considerations on applying security on HTTP message payload Nokia discussion Decision
7.2.13.2Protection of Attributes
 		Yes
Yes
 		noted No    
S3‑180261 Reply LS on Use of Subscriber Identity in HTTP URI Nokia LS out Approval
7.2.13.2Protection of Attributes
 		Yes
Yes
 		noted No    
S3‑180262 Clarification need of CMPv2 in TS 33.310 Ericsson discussion Endorsement
7.6.3Network Domain Security (NDS)
 		Yes
YesIt was agreed to treat this in the Bis meeting in San Diego. It was commented that it was needed to go back up to Rel-10.
 		noted No    
S3‑180263 SBA: Resolve EN on use of JOSE with multiple HTTP Sessions between two NFs. Nokia other Approval
7.2.13.2Protection of Attributes
 		Yes
YesNTT-Docomo: This implies a binding between request and response that needs to be captured in an editor's note.
 		revised No S3‑180356  
S3‑180264 SBA: Service access authorization Nokia pCR Approval
7.2.13.5NF-NF Authentication & Authorization
 		Yes
YesNTT-Docomo: this implies a change of all software of all NFs at the same time when it is easier to change the hardware.BT agreed. Huawei agreed with NTT-Docomo. Ericsson preffered a token-based proposal and not this one.
 		noted No    
S3‑180265 Clause 6.7.2 (NAS SMC, SUPI from UE for LI) Ericsson pCR Approval
7.2.14.1SUPI and LI
 		Yes
YesVodafone: it was generally agreed that the visited network should not tamper with the information that is passing. NTT-Docomo: requirement of sending the SUPI over the air and protecting it. BT: if SA3 accepts that authentication fails when messing with the SUPI/IMSI, that would work well with the LI group and BT would support this contribution. The Nokia solution is more difficult to live with for LI. Docomo: nobody seems to be objecting to using a hash. In this case the Ericsson proposal would be straightforward. I like the partial protection of the IMEI from the Qualcomm proposal. Combining both would be a good privacy solution. BT: hash based solution is fine if authentication fails. If any possiblity allows the UE to connect, LI will not agree.KPN agreed with this. If the SUPI is not the same in both sides, the connection shall fail. Huawei: LI should just accept the SUPI from the home network and make things easier. ORANGE replied that these are regulatory requirements that operators need to comply with. It looked like the hash-based Ericsson solution seemed to be the most accepted. BT commented that there was no chance to bring back this discussion to the next SA3 meeting.
 		noted No    
S3‑180266 Clause 5.1.5 (SUCI – on-the-fly indication to use null-scheme) Ericsson pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180267 NF discovery with SUCI Ericsson pCR Approval
7.2.14.3SIDF
 		Yes
YesKPN supported this way ahead as opposed to the China Mobile solution in 211. Nokia preferred to further study the new Annex. Noted to give it more time for further study.
 		noted No    
S3‑180268 Clause 6.12.4 (subscription identification procedure) Ericsson pCR Approval
7.2.14.4Miscellaneous
 		Yes
Yes
 		not treated No    
S3‑180269 Clauses 6.12.1 and 6.12.2 (Moving SUCI related text from 6.12.1 to 6.12.2) Ericsson pCR Approval
7.2.14.5Editorials
 		Yes
Yes
 		not treated No    
S3‑180270 Clause 6.7.4 (user plane and RRC security - AS SMC procedure) Ericsson pCR Approval
7.2.4.2Userplane security
 		Yes
Yes
 		merged No S3‑180426  
S3‑180271 Clause 6.7.3.0 (user plane and RRC security - initial AS security context establishment) Ericsson pCR Approval
7.2.4.2Userplane security
 		Yes
Yes
 		revised No S3‑180425  
S3‑180272 Clause 6.8.2.1 (key handling – RRC INACTIVE/CONNECTED state transition) Ericsson pCR Approval
7.2.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180273 Clause 6.8.2.2 (key handling – RRC INACTIVE mobility) Ericsson pCR Approval
7.2.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180274 (Clause 6.3.4) Multiple registrations in the same PLMN’s serving network Ericsson pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180275 (Clause 6.4 ) Multiple active NAS connections in the same PLMN’s serving network Ericsson pCR Approval
7.2.5.4NAS integrity and confidentiality mechanisms
 		Yes
Yes
 		merged No S3‑180400  
S3‑180276 New requirements for algorithm selection in TS 33.501 Ericsson pCR Approval
7.2.5.1Requirements
 		Yes
YesQualcomm: c) is a solution. Ericsson: this is coming from 33.401, but we need to check there to see if it is the same. NTT-Docomo: if it is a solution we don’t need to put it. We endorse it. Qualcomm: what does "endorse" mean here? Just remove it. ORANGE commented that these requirements were not necessary. The Chair decided to note it eventually.
 		noted No    
S3‑180277 Clause 6.4.6 (rectifying partial protection aspects) Ericsson pCR Approval
7.2.5.2Protection of initial NAS message
Yes
Yes
 		noted No    
S3‑180278 Exception lists of NAS and RRC message to be integrity protected and encrypted Ericsson pCR Approval
7.2.5.9Miscellaneous
 		Yes
YesThis was taken offline for discussion with the CT1 colleagues and finally agreed by Qualcomm.
 		approved No    
S3‑180279 Handover from 5GS to EPS Ericsson pCR Approval
7.2.10.3Handover 5GC-EPS
 		Yes
Yes
 		merged No S3‑180441  
S3‑180280 Idle mode mobility from 5GS to EPS Ericsson pCR Approval
7.2.10.2Idle mode 5G-4G
 		Yes
Yes
 		merged No S3‑180440  
S3‑180281 Idle mode mobility from EPS to 5GS Ericsson pCR Approval
7.2.10.1Idle mode 4G-5G
 		Yes
Yes
 		revised No S3‑180439  
S3‑180282 Handover from EPS to 5GS Ericsson pCR Approval
7.2.10.4Handover EPS-5GC
 		Yes
Yes
 		merged No S3‑180442  
S3‑180283 Mapping of security contexts during interworking between EPS and 5GS Ericsson pCR Approval
7.2.10.5Security context mapping
 		Yes
Yes
 		revised No S3‑180443  
S3‑180284 Multiple registrations in different PLMNs serving networks Ericsson pCR Approval
7.2.5.7Multi-NAS security
 		Yes
YesDiscussed together with 259 (Qualcomm).
 		merged No S3‑180398  
S3‑180285 Clause 6.6.3 (user plane – security activation) Ericsson pCR Approval
7.2.4.2Userplane security
 		Yes
Yes
 		merged No S3‑180426  
S3‑180286 Clause 6 (user plane security – security policy) Ericsson pCR Approval
7.2.4.1Userplane open issues
 		Yes
YesQualcomm preferred this contribution to 175 since it was more detailed. It was decided to merge both contributions.
 		merged No S3‑180423  
S3‑180287 Clause 6 (user plane security – non-activation of integrity protection) Ericsson pCR Approval
7.2.4.1Userplane open issues
 		Yes
Yes
 		approved No    
S3‑180288 Annex D.1 (user plane security – null-integrity not allowed for DRBs) Ericsson pCR Approval
7.2.4.1Userplane open issues
 		Yes
Yes
 		approved No    
S3‑180289 Clause 6 (user plane security – conflict between RAN and CN) Ericsson pCR Approval
7.2.4.1Userplane open issues
 		Yes
YesHuawei didn't agree with this proposal. Integrity protection will be dropped as well in any congestion situation. Ericsson: we don’t mention congestion. Huawei: The RAN will never overrule the security policy coming from the core network. The RAN knows how to deal with the resources in case of congestion. Qualcomm: The core network will tell when to disable the integrity protection. Huawei: what happens when the RAN cannot fulfil the integrity protection during a congestion? Huawei: RAN complies with the user plane policy security and will handle the congestion by itself. No need for negotiation, it will never override the CN policy. Ericsson: agreements don't mention congestion. The discussion was taken offline and the agreements recorded in 424.
 		revised No S3‑180424  
S3‑180290 On the need for multiple NAS SMC procedures Ericsson discussion Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180291 Proposal for way forward on the biding problem in the secondary Ericsson discussion Endorsement
7.2.9.1MitM
 		Yes
YesIntel: this is man-in-the-middle attack. Ericsson: It's not a man-in-the-middle but an authenticated UE that is misbehaving. China Mobile: this is not related to secondary authentication. ORANGE was supporting Ericsson here. BT supported this paper, there is a threat in the secondary authentication. ORANGE this is not a problem of 3GPP, we provide only the transport. KPN agreed. Nokia pointed out that this was not part of phase one.
 		noted No    
S3‑180292 On feature set relevance for independent SEAF deployment Ericsson discussion Approval
7.2.1.1Miscellaneous
 		No
Yes
 		withdrawn Yes    
S3‑180293 New annex for 3GPP 5G profile on RFC 5448 EAP-AKA’ Ericsson pCR Approval
7.2.8.2EAP AKA’ over 3gpp/non3gpp access
 		Yes
Yes
 		approved No    
S3‑180294 Clarifications and clean-up of 5G AKA procedure Ericsson pCR Approval
7.2.8.7Editorial corrections
 		Yes
YesNTT-Docomo: timer being optional and auth confirmation being optional is against what we had agreed in Singapore. Everybody was agreeing on having the authentication confirmation. Ericsson asked: For 5G AKA, do we need one authentication vector? BT preferred to have several auth vectors, but it was pointed out that long discussions before had led to having just one authentication per request for 5G.
 		revised No S3‑180393  
S3‑180295 Construction of serving network name with 5G AKA and EAP-AKA’ Ericsson pCR Approval
7.2.8.15G AKA over 3gpp/non3gpp access
 		Yes
YesKPN didn’t understand the need for this, so it was taken offline.They didn't agree with the separation character either.Vodafone and ORANGE supported this.
 		revised No S3‑180390  
S3‑180296 Adding forward secrecy for AKA in phase 2 without bidding-down problems Ericsson pCR Approval
7.2.8.5Enhancements to authentication (Diffie-Hellman proposals etc)
 		Yes
Yes
 		noted No    
S3‑180297 Signalling procedure for periodic local authentication Samsung pCR Approval
7.2.4.3RRC security
 		Yes
Yes
 		revised No S3‑180428  
S3‑180298 LS (S3-180034/CT4-176395) on the Use of Subscriber Identity in HTTP URI Ericsson LS out Approval
7.2.13.2Protection of Attributes
 		Yes
Yes
 		noted No    
S3‑180299 LS on protection of HTTP messages between SEPPs Ericsson LS out Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180300 Including authentication into authorization aspects Ericsson pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		revised No S3‑180368  
S3‑180301 TLS mandatory to implement for SBA security Ericsson pCR Approval
7.2.13.3Transport security (intra and inter-PLMN)
 		Yes
YesBT commented that the meaning of "use" in this case was ambiguous. The first phrase was reworded to clarify this.
 		revised No S3‑180357  
S3‑180302 Annex C (SUCI – scheme properties) Ericsson pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180303 Clause 6.12.2 (SUCI – behaviours when USIM calculates SUCI) Ericsson pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180304 Clause 6.12.5 (SIDF – size of SUCI) Ericsson pCR Approval
7.2.14.3SIDF
 		Yes
Yes
 		not treated No    
S3‑180305 Clause 6.12.5 (SIDF – validating calculation of the SUCI) Ericsson pCR Approval
7.2.14.3SIDF
 		Yes
Yes
 		not treated No    
S3‑180306 Annex C (SUCI – ECIES profiles) Ericsson pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		revised No S3‑180451  
S3‑180307 CAPIF Security requirements Samsung, Motorola Solutions pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180392  
S3‑180308 Assignment of KSIamf Ericsson pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		merged No S3‑180430  
S3‑180309 Security procedure for CAPIF-1e reference point Samsung pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑180310 Registration state transitions in TS 33.501 Ericsson, Huawei, Hisilicon pCR Approval
7.2.5.6NAS security handling during state-transitions
 		Yes
Yes
 		revised No S3‑180397  
S3‑180311 Connection state transitions in TS 33.501 Ericsson, Huawei, Hisilicon pCR Approval
7.2.5.6NAS security handling during state-transitions
 		Yes
Yes
 		approved No    
S3‑180312 Security Procedure for CAPIF-2e reference point Samsung pCR Agreement
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
YesNEC: it is strange that there are three methods here, which seems like three options. It was clarified that method one and two are authentication and method three is authorization/authentication. BT: how is the method chosen/ negotiated in the fly? Samsung: this is determined in 392. Nokia: method three is fine but the others need some more refinement. Huawei wasn't convinced with the authorization mechanisms for method one and two, so an editor's note was added to address this.
 		revised No S3‑180403  
S3‑180313 New UE requirement to store two 5G security contexts in TS 33.501 Ericsson, Qualcomm Incorporated pCR Approval
7.2.6.4UE handling
 		Yes
YesGemalto: why is the storage at the power-off? It’s different from the EPS. Qualcomm: it includes the de-registration, we can clarify it. Gemalto: CT6 defines the different types of services: support of 5G security context and others. Qualcomm disagreed. Dragan (IDEMIA): we need to stay general, not to focus on 5G security context. We need to mention 5G security services. It was agreed to reword this sentence in the revision and text from 33.401.
 		revised No S3‑180445  
S3‑180314 CAPIF security within PLMN Trust Domain Samsung pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
YesNEC: this is in a solution section and we have two requirements. Huawei: the second line is too broad, you cannot mention that the whole TS 33.310 applies; refer to the right clause. China commented that the first sentence wasn't clear enough and needed to be more specific about what exactly is being taken from TS 33.310. MCC agreed with this.
 		revised No S3‑180404  
S3‑180315 LS to CT1 on Protected Payload message type NCSC LS out Approval
7.6.18Security of the Mission Critical Service (MCSec)
 		Yes
Yes
 		revised No S3‑180388  
S3‑180316 New key issue on UE behaviour on failing integrity check Ericsson other Approval
7.2.16PLMN RAT selection
 		Yes
YesVodafone: The wording for the key issue looks like a requirement.It's missing here to describe some means of receiving the message correctly (e.g. a request to be resent). Huawei commented that they didn’t agree with the requirements. This had to be taken offline.
 		revised No S3‑180370  
S3‑180317 New solution: Protected UE configuration update commands Ericsson other Approval
7.2.16PLMN RAT selection
 		Yes
Yes
 		revised No S3‑180374  
S3‑180318 New solution: key management via AUSF Ericsson pCR Approval
7.2.16PLMN RAT selection
 		Yes
YesVodafone: UDM knows everytime that the auth process is being done.Narrow it down to authentication for network access. Sending keys out every time we need an authentication might be a problem.
 		revised No S3‑180375  
S3‑180319 Addition of soltion to living document (Steering of roaming) Vodafone GmbH other Approval
7.2.16PLMN RAT selection
 		Yes
YesDT: Take out the DH example. This was agreed. ORANGE: if you are proposing a new secure channel here you should consider the LI aspects with an editor's note.
 		revised No S3‑180377  
S3‑180320 Clause 6.9.2.3 (horizontal K_AMF derivation at N2-Handover) Ericsson, Huawei, Hisilicon pCR Approval
7.2.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		approved No    
S3‑180321 Clause 6.9.3 (horizontal K_AMF derivation at mobility registration update) Ericsson pCR Approval
7.2.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		revised No S3‑180434  
S3‑180322 Handling of 5G security contexts in the UE Gemalto, IDEMIA pCR Approval
7.2.2.4Miscellaneous
 		Yes
YesVodafonel replace UICC with USIM. ORANGE: The same with the related contributions that will merge.
 		merged No S3‑180452  
S3‑180323 Storage of key material in the UE Gemalto, IDEMIA pCR Approval
7.2.2.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180452  
S3‑180324 SUCI calculation Gemalto N.V. pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		not treated No    
S3‑180325 Clarification for TCP connection reuse Ericsson Limited CR Agreement
7.6.2IP Multimedia Subsystem (IMS) Security
 		Yes
Yes
 		revised No S3‑180417  
S3‑180326 pCR to 33.501 - SUPI Encryption Protocol: issues identified by ETSI SAGE VODAFONE Group Plc pCR Approval
7.2.14.1SUPI and LI
 		Yes
YesBT supported this contribution. Vodafone was happy with merging this paper with any solution as long as the fraud part was covered. Change one was not agreed. Ericsson wanted to discuss more deeply the editor's notes on the fraud cases in change two, so it was suggested to have a dedicated conference call to discuss them.
 		noted No   S3‑173260
S3‑180327 Considerations on Network Function Authorization in 5G SBA Deutsche Telekom AG discussion Discussion
7.2.13.5NF-NF Authentication & Authorization
 		Yes
Yes
 		noted No    
S3‑180328 Clause 6.9 (policy dependent horizontal K_AMF derivation) Ericsson pCR Approval
7.2.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		approved No    
S3‑180329 Attributes requiring confidentiality protection on the N32 interface Deutsche Telekom AG, KPN pCR Approval
7.2.13.2Protection of Attributes
 		Yes
YesChina Mobile commented that the confidentiality protection for location data should be optional (not a "shall"). ORANGE commented that this was only for roaming. What's the reason for not having location data confidentiality protected? It was commented that some countries would not allow to have this as a requirement. Vodafone: put it as "shall" unless local regulators don’t allow it.
 		revised No S3‑180355  
S3‑180330 Clause 6.9 and new Annex (input parameter for horizontal K_AMF derivation) Ericsson pCR Approval
7.2.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		merged No S3‑180434  
S3‑180331 Discussion on SUPI privacy proposals NTT DOCOMO INC. discussion Decision
7.2.14.1SUPI and LI
 		Yes
YesNTT Docomo: Proposal one not needed to be known in the access network. China Mobile: we would like to have the SUPI accessible in the clear, known in the VPLMN including the base station. It was pointed out that there was a requirement on this. BT commented that SA3 would be changing the requirement that's being worked in SA3-LI and that a contribution should be sent to SA3-LI for discussion. BT wanted to have minuted the documentation of this requirement. Vodafone: CMCC wants the requirement on the VPLMN irrespectible of the HPLMN wanting to prevent the encryption of the SUPI. Huawei: HPLMN can decide on the privacy of the SUPI. Qualcomm: on "the SUPI shall be able to be sent clear over the air", What happens with the privacy of the SUPI in this case? We can disregard everything. BT: 3GPP works on requirements that are written down somewhere.If we are coming up with new requirements we need to communicate this with LS. The Chair asked if there was any requirement on "the SUPI should not be in the clear". Qualcomm: this is not a requirement from the LI perspective. ORANGE: is there any TS describing LI activities over the air? There is nothing on lawful interception over the air. This issue had to be taken offline. The Chair commented that if there was no agreement on this issue he would need to know if there was an official regulator requirement or a company requirement.
 		noted No    
S3‑180332 [eMCSEC] Adding Integrity Key for KMS communications NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑180333 Discussion of security visibility NTT DOCOMO INC. discussion Endorsement
7.2.7.1Miscellaneous
 		Yes
YesBT: API design is not out of scope. Docomo: better an API written in the language of the applications than a 3GPP API. BT: find security features that need to be indicated; e.g. type of authentication, privacy and so on. We cannot do this at this meeting. Docomo clarified that this is visibility of security features from the UE side. Configurability is done elsewhere. Huawei: details of what should be there, will come next meeting. ORANGE supported the contribution, also commented that if there is no support of this there will be no visibility at all. Ericsson: this doesn’t have implications on the network architecture, should we do this in phase two? Qualcomm wasn't sure about the practical value of proposal 2. DT supported this contribution. The group had a general understanding of this issue but was not in the situation to endorse the whole paper.
 		noted No    
S3‑180334 a new WID for 5G SCAS Huawei, Hisilicon,Ericsson WID new Approval
5Items for early consideration
 		Yes
Yes
 		revised No S3‑180335 S3‑180204
S3‑180335 New WID for 5G SCAS Huawei, Hisilicon,Ericsson WID new Agreement
7.7New Work Item proposals
 		Yes
YesBT: HSS/UDM is a critical element and it should be considered as well. DT:Consider SBA as well? China Mobile: we have concerns about the network functions, they could be virtualised. Study the virtualisation of network functions first. Huawei commented that the work item should focus on the physical elements and focus on the virtualised aspects in a study item. NTT-Docomo supported the first two objectives. Alex (BT): assume that the network will be partly virtualised at least even in early stages. Nokia preferred a study item, but the consensus was to make it as a work item.
 		revised No S3‑180383 S3‑180334
S3‑180336 Comments on Adding forward secrecy for AKA in phase 2 without bidding-down problems China Mobile; Huawei; Hisilicon discussion Discussion
7.2.8.5Enhancements to authentication (Diffie-Hellman proposals etc)
 		Yes
YesBT: Diffie-Hellman is not quantum-safe. Better bundled with the crypto upgrade to 256 bits. Mark (National Technical Assistance), Qualcomm,ORANGE, and Nokia supported Ericsson in having it for phase 2. Ericsson: if for phase two, we need to add something to the protocols now. The Chair pointed out that this activity would go for phase two and no hooks would be worked on this phase.
 		noted No    
S3‑180337 Comments on S3-180306 - Annex C (SUCI – ECIES profiles) Vodafone pCR Agreement
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		merged No S3‑180451  
S3‑180338 Business rationale for requirements in “S3-172175: DESS Update and Requirements for Securing Inter-PLMN Signalling Interfaces in 5G” GSMA FASG DESS LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180339 Commenting contribution on draft LS to CT3, CT4 (S3-180223) Nokia discussion Approval
5Items for early consideration
 		Yes
Yes
 		noted No    
S3‑180340 Comment contribution to S3-180223 (LS to CT3 CT4 on SBI Design and its Security Implications) Ericsson LS out Approval
5Items for early consideration
 		No
Yes
 		withdrawn Yes    
S3‑180341 Comment contribution to S3-180223 (LS to CT3 CT4 on SBI Design and its Security Implications) Ericsson LS out Approval
5Items for early consideration
 		Yes
Yes
 		noted No    
S3‑180342 Draft reply LS to R2-1712052 = S3-173023 on security during Resume reject in INACTIVE state in NR (to: RAN2; cc: -; contact: Ericsson) Ericsson LS out Approval
7.2.4.3RRC security
 		Yes
Yes
 		noted No   S3‑173389
S3‑180343 Comment contribution to S3-180087 and S3-180243 Ericsson Limited discussion Endorsement
7.2.5.9Miscellaneous
 		Yes
YesNo need for having another mechanism for bidding down attacks. Not clear why the existing mechanisms don’t work for 5G. Docomo: we want to protect network capabilities, not UE capabilities. Ericsson: why does the network need to send to the UE what the support of SEAF? There are no security reasons for this. China Mobile: in phase two SEAF and AMF are co-located so we should postpone this issue for phase two. Qualcomm: SEAF controls what security features are used. Interdigital: if the AMF is trusted, Ericsson is correct. Ericsson: there is a phase one of AMFs connected with SEAF, and in the phae two AMFs will be connected to the SEAF. You’re assuming that the SEAF is introduced totally new without a transition. Docomo: if the AMF+ is not trusted it may not send the correct information to the UE. This had to be taken offline. The Chair queried whether this was a problem to be solved at phase one. This issue was taken to the conference call.
 		noted No    
S3‑180344 Clean up the EN in 6.1.3.1 Huawei, Hisilicon pCR Approval
7.2.8.2EAP AKA’ over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180137
S3‑180345 NESAS Pilot Findings and Recommendations to SA3 GSMA SECAG LS in Information
7.6.16Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		replied to No    
S3‑180346 Work Plan input from Rapporteurs MCC other -
9Review and Update of Work Plan
No
Yes
 		noted No   S3‑180005
S3‑180347 Reply LS on clarification on Restricted Operator Services Vodafone LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑180348 Reply to: LS on Security aspects of supporting LTE connected to 5GC Ericsson LS out approval
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		approved No    
S3‑180349 Reply to: LS on security during Resume reject in INACTIVE state in NR Intel LS out approval
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		approved No    
S3‑180350 Reply to: LS on Use of Subscriber Identity in HTTP URI Deutsche Telekom LS out approval
7.2.15Incoming and outgoing LSes
 		No
Yes
 		withdrawn Yes    
S3‑180351 NGMN White Paper on Service-based Architecture in 5G NGMN LS in discussion
7.2.15Incoming and outgoing LSes
 		Yes
YesThe Chair encouraged the delegates to have a look at the white paper.
 		noted No    
S3‑180352 Living document on SBA China Mobile other discussion
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180353 SBA: Prioritization for Phase 1 Nokia other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No   S3‑180238
S3‑180354 SBA: Resolve EN on Information Elements that require protection Nokia other Approval
7.2.13.2Protection of Attributes
 		Yes
Yes
 		approved No   S3‑180239
S3‑180355 Attributes requiring confidentiality protection on the N32 interface Deutsche Telekom AG, KPN pCR Approval
7.2.13.2Protection of Attributes
 		Yes
Yes
 		approved No   S3‑180329
S3‑180356 SBA: Resolve EN on use of JOSE with multiple HTTP Sessions between two NFs. Nokia other Approval
7.2.13.2Protection of Attributes
 		Yes
Yes
 		approved No   S3‑180263
S3‑180357 TLS mandatory to implement for SBA security Ericsson pCR Approval
7.2.13.3Transport security (intra and inter-PLMN)
 		Yes
Yes
 		approved No   S3‑180301
S3‑180358 NF Service Register Request Procedure Intel other Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesAgreed to use the public key for this purpose and remove everything else. It was agreed to add this to the living document.
 		approved No   S3‑180184
S3‑180359 Adding an editor's note on NF Service Register Request Procedure Intel pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesAdding an editor's note based on the tdoc 358.
 		approved No    
S3‑180360 Authorization of NF service discovery Huawei, Hisilicon pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesIt was agreed to summarize this contribution into a single sentence.
 		approved No   S3‑180154
S3‑180361 Security requirements for Service Request Intel pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
YesAgreed to remove the second and third requirements.
 		approved No   S3‑180185
S3‑180362 Draft TS 33.501 NTT-Docomo draft TS Approval
7.2.17Others
 		No
YesReady on Wednesday 31st January Comments Thursday 1st February Final version Friday 2nd February KPN: too many editor's notes in this spec, shouldn't we remove some? Vodafone agreed with this. BT volunteered to help KPN with the removal of some editor's notes 33.501 will be sent for approval in the March plenary.
 		left for email approval No    
S3‑180363 NF Service Request Procedure Intel other Approval
7.2.13.5NF-NF Authentication & Authorization
 		Yes
Yes
 		approved No   S3‑180165
S3‑180364 Adding the abbreviations of NF and NFR CATT pCR Approval
7.2.13.7Editorials
 		Yes
Yes
 		approved No   S3‑180054
S3‑180365 Report from SA3#89 MCC report -
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
Yes
 		approved No   S3‑180001
S3‑180366 SA3 meeting calendar MCC other -
10Future Meeting Dates and Venues
 		No
YesAd-hoc in July 2018 was removed.
 		noted No   S3‑180004
S3‑180367 Security Procedures between 5G Network Functions Huawei, Hisilicon pCR Approval
7.2.12.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180108
S3‑180368 Including authentication into authorization aspects Ericsson pCR Approval
7.2.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		approved No   S3‑180300
S3‑180369 Adding key issue to Living Document S3-173482 Huawei, Hisilicon; Samsung other Approval
7.2.16PLMN RAT selection
 		Yes
Yes
 		approved No   S3‑180112
S3‑180370 New key issue on UE behaviour on failing integrity check Ericsson other Approval
7.2.16PLMN RAT selection
 		Yes
Yes
 		approved No   S3‑180316
S3‑180371 Living document on PLMN RAT selection ORANGE other Approval
7.2.16PLMN RAT selection
 		Yes
Yes
 		noted No    
S3‑180372 Adding potential solution for living document S3-173482 Huawei, Hisilicon; Samsung other Approval
7.2.16PLMN RAT selection
 		Yes
Yes
 		approved No   S3‑180113
S3‑180373 Concerns of the use of authentication for steering of roaming Vodafone LS out Approval
7.2.16PLMN RAT selection
 		Yes
YesThis was sent during the meeting.
 		approved No    
S3‑180374 New solution: Protected UE configuration update commands Ericsson other Approval
7.2.16PLMN RAT selection
 		Yes
YesAdding editor's notes addressing the received comments.
 		approved No   S3‑180317
S3‑180375 New solution: key management via AUSF Ericsson other Approval
7.2.16PLMN RAT selection
 		Yes
Yes
 		approved No   S3‑180318
S3‑180376 [eMCSec] 33.180 R15 Interworking media and signaling Motorola Solutions UK Ltd. CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180156
S3‑180377 Addition of solution to living document (Steering of roaming) Vodafone GmbH other Approval
7.2.16PLMN RAT selection
 		Yes
Yes
 		approved No   S3‑180319
S3‑180378 Reply to: LS on a potential USIM solution for PLMN and RAT selection policies for roaming Vodafone LS out approval
7.2.16PLMN RAT selection
 		No
Yes
 		withdrawn Yes    
S3‑180379 Secondary Re-Authentication Intel pCR Approval
7.2.9.2Incomplete procedure
 		Yes
Yes
 		approved No   S3‑180196
S3‑180380 pCR to update the secondary EAP authentication clause to take into account the roaming scenario Qualcomm Incorporated,Nokia pCR Approval
7.2.9.2Incomplete procedure
 		Yes
Yes
 		approved No   S3‑180251
S3‑180381 New SID on GBA enhancements China Mobile, CATR, China Unicom SID new Agreement
7.7New Work Item proposals
 		No
Yes
 		withdrawn Yes    
S3‑180382 Presentation for Joint SA3/SA6 meeting NCSC other Presentation
7.8Documents on joint meeting with SA6 regarding eMCSec
 		Yes
YesSlide 4: SA6 agreed to the assumptions. InterSD vs SDS: who makes the decision? SA3 or SA6? Motorola solutions: InterSD would seem easier for SA6 according to some informal discussions we've had. Motorola Solutions (SA3): we are OK with this in SA3. It was noted that the InterSD message must be identifiable. SA6 will take care of the documentation and flows of these messages. IWF to the client security would be work for SA3. There are no new reference points so we would use existing ones. It was agreed that service independence aspects should be added. Slide 8: Discreet listening/viewing One SA6 opinion was that this should be considered inRel-16. This was agreed. Police of Netherlands: collection and storage? this is real time. Peter (NCSC): it's SA6 who decides how and when this data is stored. Slide 9: Temporary group call/user regroup SA6 recognises the problem and it needs to be discussed further.Downstream groups face the same issue. T-Dek (SA6): There are two models: Group ID pre-alocated before the group is formed. SA3 mechanisms are based on this model. Temporary group call is based on the case when the Group ID is not pre-alocated, that is part of the SA1 requirements. It's not appropriate to discard this for the security. We need to enhance the procedure, it's not complete. This is SA6 perspective. The SA6 Chair commented that it will be decided whether this will go to Rel-15 or Rel-16. Alan (SA6): it's a deployment decision whether they want to use an unsecure call. Adrian (SA6) supported that. It's an operational deployment choice. Peter (NCSC): the media security is mandatory in 3GPP. It's a requirement that wouldn't be applied in this case. The Chair (SA3) commented that this could be enhanced in Rel-16 but SA6. Motorola (SA6): It was also commented from an SA6 delegate that cat-F CRs could be brought to enhance this. Firstnet (SA6): we are ok with having it in Rel-16.
 		noted No    
S3‑180383 New WID for 5G SCAS Huawei, Hisilicon,Ericsson WID new Agreement
7.7New Work Item proposals
 		Yes
YesVodafone commented that there isn’t much time to deal with this and that 5G should have preference.
 		agreed No   S3‑180335
S3‑180384 New study item on Security aspects of single radio voice continuity from 5G to 3G China Unicom, Huawei, HiSilicon, ZTE, CATR, OPPO SID new -
8.5New study item proposals
 		Yes
Yes
 		agreed No   S3‑180188
S3‑180385 New WID for MONASTERY security Motorola Solutions UK Ltd. WID new Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180163
S3‑180386 [eMCSec] 33180 R15 Interworking SeGy clarification Motorola Solutions UK Ltd. CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180160
S3‑180387 [eMCSEC] LS to SA6 on Security Gateway notification NCSC LS out Approval
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180227
S3‑180388 LS to CT1 on Protected Payload message type NCSC LS out Approval
7.6.18Security of the Mission Critical Service (MCSec)
 		Yes
Yes
 		approved No   S3‑180315
S3‑180389 LS to CT3 CT4 on SBI Design and its Security Implications Deutsche Telekom AG LS out Approval
5Items for early consideration
 		Yes
YesSent to CT3 and CT4 during the meeting. Joint meeting between SA3,CT3 and CT4: SA3 has agreed on securing individual elements in the interconnect with different security levels. No security in the transport layer, as concluded in SA3, hence security in the application layer. Alf: all info stuck in JSON objects would be easier for us, instead of spreading this info. Question: will the SEPP be application/message content aware? RESTful API design you include parameters in the URI, SUPI is one example of such parameters. DT answered that the SEPP will not be content agnostic. Tim (VF): the SUPI will need to be protected separately for example. Nagendra (Nokia): SEPP has to be HTTP aware.If CT4 follows API conventions it should be easy for us. Alf (Docomo): it would be nice to have it as agnostic as possible. It needs help from the interface to know what data is being transported. IPX providers should help with this to the operators, it depends on the business models. CT3/CT4 person: portions of the URI are a parameter, as for REST design. Everytime you update the structure of the API you need to update the SEPP, it's a strong requirement. Ericsson: it's aboutd ynamically informing the SEPP about where the info is and what can be protected. In CT4,UID is a generic element that may contain SUPI in some cases, it’s a very challenging requirement what SA3 needs. CT4 Chair: In the security for interconnection you don’t need to be application aware. Jesus: other info elements like session IDs are parts of the URI that can be subject of potential attacks and need protection. It was asked whether the IPX providers were trustable. KPN answered that they are not necessarily trust entities. Vodafone: even in your network there are different levels of trust. The CT Chair commented that the SEPP being updated all the time with the different applications can cause a bottleneck in the communications.Ericsson replied that the bottleneck would be in the control plane, so the impact would be "less horrific". DT: avoid duplicate IEs in JSON objects. CT Chair: these requirements are pretty restrictive for a RESTful/HTPP approach. It would be good to re-think this. DT: it's still possible to have duplicated IEs but not the same parameter duplicated in the same message. Jesus: we never put two elements of the same name in a flat structure, so this is easy to achieve. Docomo suggested conference calls or SBA meetings between groups since there was some work needed between the groups. Minimize the potential impact and come up with a list of information elements that need to be available for the IPX providers. CT4 Chair: we can the collect the set of requirements and design guidelines for the groups involved in SBA. This would be under control of CT3/CT4. It wa ssuggested to have a list of sensitive items at the end of each release, as it is done with SA5. CT Chair: the document should be in both places, CT4 and CT4, like when it was done with AKA. We are most likely to inform other groups like SA6. Jesus: for IFs designed towards external parties, the security has been taken care of. CT Chair: we need something to report to plenary in March. Conference calls should be set up. CT3 Chair: do we need to answer the questions in the LS before the conference calls? SA3 agreed that this would be helpful. It was agreed to have the LS as a start for the conference calls.
 		approved No   S3‑180223
S3‑180390 Construction of serving network name with 5G AKA and EAP-AKA’ Ericsson pCR Approval
7.2.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180295
S3‑180391 Removal of the number of AVs requested in Authentication Information Request message Huawei, Hisilicon pCR Approval
7.2.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180126
S3‑180392 CAPIF Security requirements Samsung, Motorola Solutions,China Unico,Huawei,China Mobile, HiSilicon pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180307
S3‑180393 Clarifications and clean-up of 5G AKA procedure Ericsson,Huawei,HiSilicon pCR Approval
7.2.8.7Editorial corrections
 		Yes
YesContent was approved and merged in 396.
 		merged No S3‑180396 S3‑180294
S3‑180394 Security Procedures for EAP-TLS Huawei, Hisilicon, Ericsson, Qualcomm Incorporated, China Mobile pCR Approval
7.2.8.4Authentication using EAP TLS
 		Yes
Yes
 		approved No   S3‑180173
S3‑180395 Normative text for support of both authentication methods and text clarification to distinguish HN and SN Nokia,Huawei pCR Approval
7.2.8.7Editorial corrections
 		Yes
Yes
 		approved No   S3‑180074
S3‑180396 Adding numbers to the figure for 5G AKA KPN pCR Approval
7.2.8.7Editorial corrections
 		Yes
Yes
 		approved No   S3‑180071
S3‑180397 Registration state transitions in TS 33.501 Ericsson, Huawei, Hisilicon pCR Approval
7.2.5.6NAS security handling during state-transitions
 		Yes
Yes
 		approved No   S3‑180310
S3‑180398 Add a new requirement in scenario when UE has multiple registration in different PLMNs Huawei, Hisilicon pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		approved No   S3‑180203
S3‑180399 Clause 6.3.4.2 Multiple Registration in same PLMN Nokia pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		approved No   S3‑180095
S3‑180400 Clause 6.4.2.2 Multiple active NAS connections in same PLMN Nokia,Ericsson pCR Approval
7.2.5.7Multi-NAS security
 		Yes
Yes
 		approved No   S3‑180096
S3‑180401 Draft TS 33.122 Samsung draft TS Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑180402 LMR interworking key management summary Harris Corporation other Presentation
7.8Documents on joint meeting with SA6 regarding eMCSec
 		Yes
Yes
 		noted No    
S3‑180403 Security Procedure for CAPIF-2e reference point Samsung pCR Agreement
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180312
S3‑180404 CAPIF security within PLMN Trust Domain Samsung pCR Approval
7.5Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180314
S3‑180405 Clarification of Introduction 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‑180115
S3‑180406 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)
 		Yes
YesIt was argued whether this was going for information or approval. KPN commented that definitions and abbreviations clauses are empty in the TR and needed to be filled in. The TR will be sent to the plenary for approval.
 		approved No    
S3‑180407 Resolving Editor's Note and adding evaluation in clause 6.4.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‑180064
S3‑180408 Clarification of solution #7 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‑180120
S3‑180409 Add Evaluation for Solution #12 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‑180119
S3‑180410 Add Evaluation for Solution #13 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‑180123
S3‑180411 Conclusion for the Key Issues Huawei, Hisilicon,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‑180121
S3‑180412 Cover sheet TR 33.843 Huawei TS or TR cover Approval
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑180413 [eMCSec] 33180 R15 Interworking key mgmt (InterSD) Motorola Solutions UK Ltd. CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180158
S3‑180414 [FS_MC_Sec] 33880 Interworking eval (InterSD) Motorola Solutions UK Ltd. CR Agreement
8.1Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180161
S3‑180415 Reply to: LS on Extension of USAT Application Pairing mechanism Gemalto LS out approval
6.13GPP Working Groups
 		Yes
Yes
 		approved No    
S3‑180416 Adding references to the algorithm test data Qualcomm Incorporated pCR Approval
7.2.17Others
 		Yes
Yes
 		approved No   S3‑180247
S3‑180417 Clarification for TCP connection reuse Ericsson Limited CR Agreement
7.6.2IP Multimedia Subsystem (IMS) Security
 		Yes
Yes
 		agreed No   S3‑180325
S3‑180418 Reply to: NESAS Pilot Findings and Recommendations to SA3 Nokia LS out approval
7.6.16Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		approved No    
S3‑180419 Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.14 Nokia CR Agreement
7.6.16Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑180088
S3‑180420 Collection of changes based on feedback from GSMA SECAG - CR to 33.916v1 Rel.14 Nokia CR Agreement
7.6.16Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
 		Yes
Yes
 		agreed No   S3‑180090
S3‑180421 Clause 6.4.5 Handling of NAS counts Nokia pCR Approval
7.2.5.7Multi-NAS security
 		Yes
YesSA3 expressed their preference for a token-based solution (instead of a static one).
 		approved No   S3‑180097
S3‑180422 Corrections to clause 5.3 Requirements on the AMF NEC Telecom MODUS Ltd.,Huawei,HiSilicon pCR Approval
7.2.5.10Editorials
 		Yes
Yes
 		approved No   S3‑180006
S3‑180423 UP policy Huawei, Hisilicon,Ericsson pCR Approval
7.2.4.1Userplane open issues
 		Yes
Yes
 		approved No   S3‑180175
S3‑180424 Clause 6 (user plane security – conflict between RAN and CN) Ericsson pCR Approval
7.2.4.1Userplane open issues
 		Yes
Yes
 		approved No   S3‑180289
S3‑180425 Clause 6.7.3.0 (user plane and RRC security - initial AS security context establishment) Ericsson,Huawei,HiSilicon,China Mobile pCR Approval
7.2.4.2Userplane security
 		Yes
Yes
 		approved No   S3‑180271
S3‑180426 AS Security Negotiation and Activation Huawei; HiSilicon,Ericsson pCR Approval
7.2.4.2Userplane security
 		Yes
YesKPN commented that the SMC AS procedure leads to newly agreed keys and will bring a contribution for the next meeting clarifying this aspect.
 		approved No   S3‑180100
S3‑180427 Changes to TS 33.180 from SA3#90 NCSC other Information
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑180428 Signalling procedure for periodic local authentication Samsung pCR Approval
7.2.4.3RRC security
 		Yes
Yes
 		approved No   S3‑180297
S3‑180429 Adding Forward & Backward Security definition Huawei, Hisilicon pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		approved No   S3‑180103
S3‑180430 pCR to TS 33.501 key identification Huawei, Hisilicon,ZTE, CATT,Nokia,Ericsson pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		approved No   S3‑180135
S3‑180431 Delete the mandatory implementation of NIA0 in gNB Huawei, Hisilicon pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		approved No   S3‑180145
S3‑180432 Adding requirements on CU-DU split based on the key derivation used Qualcomm Incorporated pCR Approval
7.2.4.4Miscellaneous
 		No
Yes
 		withdrawn Yes    
S3‑180433 Intra-gNB retaining AS keys exception Huawei, Hisilicon, CMCC pCR Approval
7.2.3.1Key derivations during handovers
 		Yes
Yes
 		approved No   S3‑180105
S3‑180434 Clause 6.9.3 (horizontal K_AMF derivation at mobility registration update) Ericsson,Huawei pCR Approval
7.2.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		approved No   S3‑180321
S3‑180435 Procedures for security context transfer in idle mode mobility Huawei, Hisilicon pCR Approval
7.2.3.6Miscellaneous
 		Yes
YesAdding an editor's note.
 		approved No   S3‑180139
S3‑180436 draft LS on the status of work on interfaces Huawei & Hisilicon LS out Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
YesDoing some rewording with the help of Vodafone. ORANGE found strange that SA3 was asking for information that could be found in SA5 specifications.
 		approved No   S3‑180172
S3‑180437 A key issue proposal on security capability for TR33.811 Huawei, Hisilicon, China Moible, China Unicom, CATR, CATT pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
YesKey issue will verse on the negotiation.
 		approved No   S3‑180169
S3‑180438 Draft TR 33.811 Huawei draft TR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		No
Yes
 		approved No    
S3‑180439 Idle mode mobility from EPS to 5GS Ericsson, Qualcomm,Nokia pCR Approval
7.2.10.1Idle mode 4G-5G
 		Yes
Yes
 		approved No   S3‑180281
S3‑180440 Interworking; Idle mode mobility from 5G to 4G Nokia,Qualcomm, Huawei,Ericsson pCR Approval
7.2.10.2Idle mode 5G-4G
 		Yes
Yes
 		approved No   S3‑180234
S3‑180441 pCR to provide a normative text for handover from 5GC to EPC Qualcomm Incorporated,Nokia, NEC,Huawei,Ericsson pCR Approval
7.2.10.3Handover 5GC-EPS
 		Yes
Yes
 		approved No   S3‑180252
S3‑180442 Interworking: Handover from EPS to 5GS Nokia, Qualcomm, NEC,Ericsson pCR Approval
7.2.10.4Handover EPS-5GC
 		Yes
Yes
 		approved No   S3‑180231
S3‑180443 Mapping of security contexts during interworking between EPS and 5GS Ericsson pCR Approval
7.2.10.5Security context mapping
 		Yes
Yes
 		approved No   S3‑180283
S3‑180444 Interworking with EPC without N26 interface in single-registration mode Huawei, Hisilicon pCR Approval
7.2.10.6Miscellaneous
 		Yes
Yes
 		approved No   S3‑180114
S3‑180445 New UE requirement to store two 5G security contexts in TS 33.501 Ericsson, Qualcomm Incorporated pCR Approval
7.2.6.4UE handling
 		Yes
Yes
 		approved No   S3‑180313
S3‑180446 Clarification on 5G security context CATT pCR Approval
7.2.6.6Miscellaneous
 		Yes
Yes
 		approved No   S3‑180055
S3‑180447 Resolving editors notes in clause on key hierarchy Nokia pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180076
S3‑180448 Clean up the EN in 6.2.1 Huawei, Hisilicon pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180138
S3‑180449 Adding details of K’AMF to clause 6.2.1 NEC Telecom MODUS Ltd. pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180221
S3‑180450 Key distribution and key derivation scheme Huawei, Hisilicon, pCR Approval
7.2.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180178
S3‑180451 Annex C (SUCI – ECIES profiles) Ericsson,Vodafone pCR Approval
7.2.14.2SUCI and Schemes
 		No
YesQualcomm commented that these are too many profiles: We haven’t heard any argument why one profile is not sufficient. Vodafone: SAGE has trust issues with having a single profile. ORANGE supported Vodafone. Intel supported Qualcomm. KPN preferred multiple curves, but better to have a single decent curve than multiple curves that don’t work as Ericsson. Qualcomm: No reason to mandate multiple curves in the ME. Samsung and NEC supported this at least for phase one.The scheme can be selected by negotiation. Docomo: we cannot retrofit more curves (update all USIMS in the field), we need to have more curves in the beginning if that's the plan for phase two. It was noted that this topic had to be agreed in the next meeting. NCSC: If we can clarify whether more curves can be added in the future, then we can reach an agreement. Ericsson: we will need more curves.
 		noted No   S3‑180306
S3‑180452 Storage of key material in the UE Gemalto, IDEMIA,Qualcomm pCR Approval
7.2.2.4Miscellaneous
 		Yes
Yes
 		approved No   S3‑180323
S3‑180453 Clarification of security visibility LG Electronics pCR Approval
7.2.7.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180200
S3‑180454 Authorization of SN by UE - was S3-173125 Nokia, LG Electronics pCR Approval
7.2.7.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180085
S3‑180455 Authentication for Untrusted Non-3GPP Access using EAP Motorola Mobility, Lenovo, LG Electronics, Nokia, KPN, Broadcom, Brocade pCR Approval
7.2.11.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180012
S3‑180456 Requirements for UP and CP for the gNB Huawei, Hisilicon, CMCC pCR Approval
7.2.4.4Miscellaneous
 		Yes
Yes
 		approved No   S3‑180107
S3‑180457 SUPI and LI WG Chair other Endorsement
7.2.14.1SUPI and LI
 		Yes
YesIt was decided that partial IMEI encryption wasn't an issue here. "SMC must fail cryptographically if the UE and HPLMN responses don’t matcht (leading to no service provisioning to UE)"-> BT favoured this statement to fulfil the LI requirement no matter the solution found. Nokia and Huawei disagreed with the last point ("6") since it was restricting too much the solution. The Chair requested a show of hands: Support of point two ("NAS SMC will include a hash of SUPI + something") --> Docomo, Sony, KPN,BT,ORANGE,Intel,NEC,Samsung,Huawei, Ericson,Ipcom,CATT,Home Office, NIST,Airbus,ZTE, DT,AT&T,ZTE, Vodafone,OTD,French Ministry, NTECH. Support for "Hash of SUPI + something": ORANGE, Nokia, SDT, T-mobile, ORANGE, Interdigital, Gemalto, IDEMIA, Motorola, NIST, AT&T. Objections to sentence in point two: Tmobile, Nokia, Gemalto IDEMIA. NAS SMC was removed from "NAS SMC will include a hash of SUPI + something". Once the basics were agreed, the presentation was endorsed.
 		endorsed No    
S3‑180458 Requirement on AMF related to LI Nokia pCR Approval
7.2.14.1SUPI and LI
 		Yes
Yes
 		approved No   S3‑180082
S3‑180459 Exception Sheet NAPS-Sec Huawei WI exception request Agreement
7.4Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
 		Yes
Yes
 		withdrawn Yes    
S3‑180460 Privacy requirement improvement related to using non null-scheme CATT pCR Approval
7.2.14.2SUCI and Schemes
 		Yes
Yes
 		approved No   S3‑180049