TDoc list

Tdoc List

2018-01-26 14:57

Agenda	Topic	TDoc	Title	Source	Type	For	Avail	Treated	Decision	Wdrn	Replaced-by	Replaces
1	Opening of the meeting
2	Approval of Agenda and Meeting Objectives	S3‑180000	Agenda	WG Chairman	agenda		Yes	Yes	approved	No
3	IPR and Anti-Trust Law Reminder
4	Meeting Reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑180001	Report from SA3#89	MCC	report		Yes	YesHuawei commented that S3-173137 had been not treated instead of "rejected".This was fixed.	revised	No	S3‑180365
		S3‑180365	Report from SA3#89	MCC	report	-	Yes	Yes	approved	No		S3‑180001
4.2	Report from SA Plenary	S3‑180003	Report from last SA meeting	WG Chairman	report		Yes	Yes	noted	No
4.3	Report from SA3-LI
5	Items for early consideration	S3‑180204	a new WID for 5G SCAS	Huawei, Hisilicon	WID new	Approval	Yes	Yes	revised	No	S3‑180334
		S3‑180334	a new WID for 5G SCAS	Huawei, Hisilicon,Ericsson	WID new	Approval	Yes	Yes	revised	No	S3‑180335	S3‑180204
		S3‑180223	LS to CT3 CT4 on SBI Design and its Security Implications	Deutsche Telekom AG	LS out	Approval	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‑180389	LS to CT3 CT4 on SBI Design and its Security Implications	Deutsche Telekom AG	LS out	Approval	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‑180339	Commenting contribution on draft LS to CT3, CT4 (S3-180223)	Nokia	discussion	Approval	Yes	Yes	noted	No
		S3‑180341	Comment contribution to S3-180223 (LS to CT3 CT4 on SBI Design and its Security Implications)	Ericsson	LS out	Approval	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	No	Yes	withdrawn	Yes
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑180030	Reply LS on LTE call redirection to GERAN	C1-175377	LS in		Yes	Yes	noted	No
		S3‑180031	Reply LS on LTE call redirection to GERAN	R2-1714121	LS in		Yes	Yes	noted	No
		S3‑180032	Response LS on LTE call redirection to GERAN	R3-175030	LS in		Yes	Yes	noted	No
		S3‑180041	Reply LS on clarification on Restricted Operator Services	S1-174604	LS in		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‑180347	Reply LS on clarification on Restricted Operator Services	Vodafone	LS out	approval	Yes	Yes	approved	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		Yes	Yes	noted	No
		S3‑180047	LS on Extension of USAT Application Pairing mechanism	C6-170737	LS in		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‑180415	Reply to: LS on Extension of USAT Application Pairing mechanism	Gemalto	LS out	approval	Yes	Yes	approved	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA
6.5	3GPP2
6.6	OMA
6.7	TCG	S3‑180009	TCG progress report	InterDigital, Inc.	other	Information	Yes	Yes	noted	No
6.8	oneM2M
6.9	TC-CYBER
6.10	ETSI NFV security
6.11	Other Groups
7	Work Areas
7.1	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)	S3‑180146	Change the support of NIA0 in SgNB for ENDC	Huawei, Hisilicon	CR	Approval	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‑180209	Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity	R2-1714124	LS in		No	Yes	withdrawn	Yes
7.2	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
7.2.1	Key hierarchy
7.2.1.1	Miscellaneous	S3‑180124	Discussion on deleting KSEAF from key hierarchy	Huawei, Hisilicon	discussion	Endorsement	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‑180076	Resolving editors notes in clause on key hierarchy	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180447
		S3‑180447	Resolving editors notes in clause on key hierarchy	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180076
		S3‑180138	Clean up the EN in 6.2.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180448
		S3‑180448	Clean up the EN in 6.2.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180138
		S3‑180221	Adding details of K’AMF to clause 6.2.1	NEC Telecom MODUS Ltd.	pCR	Approval	Yes	Yes	revised	No	S3‑180449
		S3‑180449	Adding details of K’AMF to clause 6.2.1	NEC Telecom MODUS Ltd.	pCR	Approval	Yes	Yes	approved	No		S3‑180221
		S3‑180174	pCR for overview of 5G security architecture	Huawei, Hisilicon, China Mobile, CATR, ZTE	pCR	Approval	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‑180176	Modification of Kausf	Huawei, Hisilicon,	pCR	Approval	Yes	Yes	merged	No	S3‑180395
		S3‑180178	Key distribution and key derivation scheme	Huawei, Hisilicon,	pCR	Approval	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‑180450	Key distribution and key derivation scheme	Huawei, Hisilicon,	pCR	Approval	Yes	Yes	approved	No		S3‑180178
		S3‑180308	Assignment of KSIamf	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180430
		S3‑180292	On feature set relevance for independent SEAF deployment	Ericsson	discussion	Approval	No	Yes	withdrawn	Yes
7.2.1.2	Editorials
7.2.2	Key derivation
7.2.2.1	Key derivation mobility related
7.2.2.2	Key derivation NAS related	S3‑180021	Handling of user-related keys – key setting	ZTE Corporation	pCR	Approval	Yes	Yes	merged	No
		S3‑180053	Adding context on key setting	CATT	pCR	Approval	Yes	Yes	merged	No	S3‑180430
7.2.2.3	Key derivation AS related
7.2.2.4	Miscellaneous	S3‑180098	Clause 6.2.3 Handling of user related keys	Nokia	pCR	Approval	Yes	Yes	merged	No	S3‑180430
		S3‑180323	Storage of key material in the UE	Gemalto, IDEMIA	pCR	Approval	Yes	Yes	revised	No	S3‑180452
		S3‑180452	Storage of key material in the UE	Gemalto, IDEMIA,Qualcomm	pCR	Approval	Yes	Yes	approved	No		S3‑180323
		S3‑180257	Keys in the UE	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑180452
		S3‑180322	Handling of 5G security contexts in the UE	Gemalto, IDEMIA	pCR	Approval	Yes	YesVodafonel replace UICC with USIM. ORANGE: The same with the related contributions that will merge.	merged	No	S3‑180452
7.2.2.5	Editorials
7.2.3	Mobility
7.2.3.1	Key derivations during handovers	S3‑180104	Flexible retaining AS keys solution	Huawei, Hisilicon, CMCC	pCR	Approval	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	Yes	YesThis was taken offline as Ericsson had some issues with the changes.	revised	No	S3‑180433
		S3‑180433	Intra-gNB retaining AS keys exception	Huawei, Hisilicon, CMCC	pCR	Approval	Yes	Yes	approved	No		S3‑180105
7.2.3.2	Security in AMF change between AMF sets	S3‑180328	Clause 6.9 (policy dependent horizontal K_AMF derivation)	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑180320	Clause 6.9.2.3 (horizontal K_AMF derivation at N2-Handover)	Ericsson, Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑180230	KAMF Derivation when AMF set changes during idle mode mobility	Huawei; Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180434
		S3‑180321	Clause 6.9.3 (horizontal K_AMF derivation at mobility registration update)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180434
		S3‑180434	Clause 6.9.3 (horizontal K_AMF derivation at mobility registration update)	Ericsson,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑180321
		S3‑180330	Clause 6.9 and new Annex (input parameter for horizontal K_AMF derivation)	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180434
7.2.3.3	Security in AMF change within an AMF set	S3‑180125	Clarification on security in AMF change within an AMF set	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
7.2.3.4	Resolving Editor’s Notes in Section 8.3 (Access Stratum)
7.2.3.5	Parameter/Message Name alignment
7.2.3.6	Miscellaneous	S3‑180139	Procedures for security context transfer in idle mode mobility	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: this needs a terminology cleanup.	revised	No	S3‑180435
		S3‑180435	Procedures for security context transfer in idle mode mobility	Huawei, Hisilicon	pCR	Approval	Yes	YesAdding an editor's note.	approved	No		S3‑180139
		S3‑180014	Remaining restructuring of Clause 6.9 (Security handling in mobility)	Ericsson, NEC Corporation	pCR		Yes	Yes	approved	No
7.2.3.7	Editorials
7.2.4	AS security
7.2.4.1	Userplane open issues	S3‑180287	Clause 6 (user plane security – non-activation of integrity protection)	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑180288	Annex D.1 (user plane security – null-integrity not allowed for DRBs)	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑180056	Proposal for UP integrity protection activation	CATT	pCR	Approval	Yes	Yes	noted	No
		S3‑180175	UP policy	Huawei, Hisilicon,	pCR	Approval	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‑180423	UP policy	Huawei, Hisilicon,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180175
		S3‑180256	User plane integrity protection granularity	Qualcomm Incorporated	pCR	Approval	Yes	YesNoted as it was simialr to 286.	noted	No
		S3‑180286	Clause 6 (user plane security – security policy)	Ericsson	pCR	Approval	Yes	YesQualcomm preferred this contribution to 175 since it was more detailed. It was decided to merge both contributions.	merged	No	S3‑180423
		S3‑180289	Clause 6 (user plane security – conflict between RAN and CN)	Ericsson	pCR	Approval	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‑180424	Clause 6 (user plane security – conflict between RAN and CN)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180289
7.2.4.2	Userplane security	S3‑180099	Security Algorithms Negotiation for Initial AS security context	Huawei; HiSilicon;China Mobile	pCR	Approval	Yes	YesDiscussed with 271.	merged	No	S3‑180425
		S3‑180271	Clause 6.7.3.0 (user plane and RRC security - initial AS security context establishment)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180425
		S3‑180425	Clause 6.7.3.0 (user plane and RRC security - initial AS security context establishment)	Ericsson,Huawei,HiSilicon,China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑180271
		S3‑180100	AS Security Negotiation and Activation	Huawei; HiSilicon	pCR	Approval	Yes	YesNokia: Don’t specify what is cyphered. Huawei agreed to remove this part.	revised	No	S3‑180426
		S3‑180426	AS Security Negotiation and Activation	Huawei; HiSilicon,Ericsson	pCR	Approval	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‑180270	Clause 6.7.4 (user plane and RRC security - AS SMC procedure)	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180426
		S3‑180285	Clause 6.6.3 (user plane – security activation)	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180426
7.2.4.3	RRC security	S3‑180020	Security aspects of RESUME REJECT in INACTIVE state in NR	ZTE Corporation	discussion	Discussion	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‑180131	Discussion on security during Resume reject in INACTIVE state in NR	Huawei, Hisilicon	discussion	Endorsement	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‑180130	Draft Reply LS on security during Resume reject in INACTIVE state in NR	Huawei, Hisilicon	LS out	Approval	Yes	Yes	noted	No
		S3‑180194	Discussion on Security Issues with RRC Reject for INACTIVE Mode	Intel	discussion	Discussion	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‑180193	draft Reply LS on security during Resume reject in INACTIVE state in NR	Intel	LS out	Approval	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	Yes	Yes	noted	No		S3‑173389
		S3‑180149	pCR to TS 33.501 Key Handing at Transitions between RRC-INACTIVE to RRC-CONNECTED states	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180272	Clause 6.8.2.1 (key handling – RRC INACTIVE/CONNECTED state transition)	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑180150	pCR to TS 33.501 Key Handing during mobility in RRC-INACTIVE state	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180273	Clause 6.8.2.2 (key handling – RRC INACTIVE mobility)	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑180129	pCR to TS 33.501 Security Handling for RRC Connection Re-establishment Procedure	Huawei, Hisilicon	pCR	Approval	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‑180297	Signalling procedure for periodic local authentication	Samsung	pCR	Approval	Yes	Yes	revised	No	S3‑180428
		S3‑180428	Signalling procedure for periodic local authentication	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑180297
7.2.4.4	Miscellaneous	S3‑180103	Adding Forward & Backward Security definition	Huawei, Hisilicon	pCR	Approval	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‑180429	Adding Forward & Backward Security definition	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180103
		S3‑180106	Address EN in requirements for gNB setup and configuration	Huawei, Hisilicon,	pCR	Approval	Yes	Yes	approved	No
		S3‑180107	Requirements for UP and CP for the gNB	Huawei, Hisilicon, CMCC	pCR	Approval	Yes	Yes	revised	No	S3‑180456
		S3‑180456	Requirements for UP and CP for the gNB	Huawei, Hisilicon, CMCC	pCR	Approval	Yes	Yes	approved	No		S3‑180107
		S3‑180135	pCR to TS 33.501 key identification	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180430
		S3‑180430	pCR to TS 33.501 key identification	Huawei, Hisilicon,ZTE, CATT,Nokia,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180135
		S3‑180136	pCR to TS 33.501 key lifetimes	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180430
		S3‑180145	Delete the mandatory implementation of NIA0 in gNB	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180431
		S3‑180431	Delete the mandatory implementation of NIA0 in gNB	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180145
		S3‑180151	pCR to TS 33.501 AS algorithm selection in state transitions between RRC-INACTIVE to RRC-CONNECTED states	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180181	Replay protection for UP, RRC and NAS	Huawei, Hisilicon,	pCR	Approval	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‑180246	Discussion on the use of the serving network identity to generate keys that are used in the AUSF	Qualcomm Incorporated	discussion	Discussion	Yes	YesNo one saw an issue in the key derivation in the AUSF. The document was noted.	noted	No
		S3‑180248	Adding requirements on CU-DU split based on the key derivation used	Qualcomm Incorporated	pCR	Approval	Yes	YesEricsson didn’t agree with the requirement. This was taken offline.	noted	No
		S3‑180432	Adding requirements on CU-DU split based on the key derivation used	Qualcomm Incorporated	pCR	Approval	No	Yes	withdrawn	Yes
7.2.4.5	Editorials	S3‑180007	Corrections to clause 5.2 Requirements on the gNB	NEC Telecom MODUS Ltd.	pCR	Approval	Yes	Yes	merged	No	S3‑180422
		S3‑180182	Integrity for UP, RRC and NAS	Huawei, Hisilicon,	pCR	Approval	Yes	Yes	merged	No	S3‑180422
		S3‑180183	Confidentiality for UP, RRC and NAS	Huawei, Hisilicon,	pCR	Approval	Yes	Yes	merged	No	S3‑180422
7.2.5	NAS security
7.2.5.1	Requirements	S3‑180276	New requirements for algorithm selection in TS 33.501	Ericsson	pCR	Approval	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
7.2.5.2	Protection of initial NAS message	S3‑180133	Discussion on Protection of initial NAS message	Huawei, Hisilicon	discussion	Endorsement	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	Yes	Yes	noted	No
		S3‑180277	Clause 6.4.6 (rectifying partial protection aspects)	Ericsson	pCR	Approval	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	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
7.2.5.3	NAS algorithm selection
7.2.5.4	NAS integrity and confidentiality mechanisms	S3‑180111	Adding content to NAS security	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180400
		S3‑180275	(Clause 6.4 ) Multiple active NAS connections in the same PLMN’s serving network	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180400
7.2.5.5	NAS Security Mode Command	S3‑180215	Enhancing the security of the key KAMF	China Mobile,Huawei, Hisilicon; Deutsche Telekom AG	discussion	Discussion	Yes	Yes	noted	No
		S3‑180217	Enhance the security of the key KAMF in the NAS SMC procedure	China Mobile; Huawei; Hisilicon; Deutsche Telekom AG	discussion	Discussion	Yes	Yes	noted	No
		S3‑180219	Updating NAS security mode command procedure	China Mobile,Huawei, Hisilicon, Deutsche Telekom AG	pCR	Approval	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	Yes	Yes	noted	No
		S3‑180241	Removing allowed NSSAI from NAS Security Mode procedure	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑180132	Delete allowed NSSAI in NAS SMC	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
7.2.5.6	NAS security handling during state-transitions	S3‑180310	Registration state transitions in TS 33.501	Ericsson, Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180397
		S3‑180397	Registration state transitions in TS 33.501	Ericsson, Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180310
		S3‑180311	Connection state transitions in TS 33.501	Ericsson, Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
7.2.5.7	Multi-NAS security	S3‑180008	NAS security conference call notes	NEC Telecom MODUS Ltd.	report	Information	Yes	Yes	noted	No
		S3‑180203	Add a new requirement in scenario when UE has multiple registration in different PLMNs	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180398
		S3‑180398	Add a new requirement in scenario when UE has multiple registration in different PLMNs	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180203
		S3‑180284	Multiple registrations in different PLMNs serving networks	Ericsson	pCR	Approval	Yes	YesDiscussed together with 259 (Qualcomm).	merged	No	S3‑180398
		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	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‑180290	On the need for multiple NAS SMC procedures	Ericsson	discussion	Approval	Yes	Yes	noted	No
		S3‑180022	Discussion on multi-NAS in same PLMN – structure of 5G security context	ZTE Corporation, Huawei, Hisilicon	discussion	Discussion	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‑180093	Multiple NAS Security Discussion	Nokia	discussion	Agreement	Yes	YesThese proposals were agreed earlier.	noted	No
		S3‑180095	Clause 6.3.4.2 Multiple Registration in same PLMN	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180399
		S3‑180399	Clause 6.3.4.2 Multiple Registration in same PLMN	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180095
		S3‑180274	(Clause 6.3.4) Multiple registrations in the same PLMN’s serving network	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑180026	Multi-NAS in same PLMN - structure of 5G security context	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑180202	Add context for multiple registrations in the same PLMN	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180096	Clause 6.4.2.2 Multiple active NAS connections in same PLMN	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180400
		S3‑180400	Clause 6.4.2.2 Multiple active NAS connections in same PLMN	Nokia,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180096
		S3‑180097	Clause 6.4.5 Handling of NAS counts	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180421
		S3‑180421	Clause 6.4.5 Handling of NAS counts	Nokia	pCR	Approval	Yes	YesSA3 expressed their preference for a token-based solution (instead of a static one).	approved	No		S3‑180097
		S3‑180094	Clause Annex D	Nokia	pCR	Approval	Yes	Yes	noted	No
		S3‑180023	Discussion on multi-NAS in same PLMN – NAS message handling after first registration procedure	ZTE Corporation	discussion	Discussion	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	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‑180027	Multi-NAS in same PLMN - NAS message handling after first registration procedure	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑180025	Discussion on multi-NAS in same PLMN – re-authentication handling	ZTE Corporation	discussion	Discussion	No	Yes	withdrawn	Yes
7.2.5.8	SMS over NAS
7.2.5.9	Miscellaneous	S3‑180087	Preventing bidding down between 5G releases - was S3-173128	Nokia, KPN, LG Electronics	pCR	Approval	Yes	Yes	noted	No		S3‑173128
		S3‑180243	Adding a generic bid down solution to the 5G TS	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑180343	Comment contribution to S3-180087 and S3-180243	Ericsson Limited	discussion	Endorsement	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‑180278	Exception lists of NAS and RRC message to be integrity protected and encrypted	Ericsson	pCR	Approval	Yes	YesThis was taken offline for discussion with the CT1 colleagues and finally agreed by Qualcomm.	approved	No
7.2.5.10	Editorials	S3‑180006	Corrections to clause 5.3 Requirements on the AMF	NEC Telecom MODUS Ltd.	pCR	Approval	Yes	YesOverlapping with 182 and 183, which had the same changes.	revised	No	S3‑180422
		S3‑180422	Corrections to clause 5.3 Requirements on the AMF	NEC Telecom MODUS Ltd.,Huawei,HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180006
		S3‑180141	Corrections on NAS security mode command procedure (subclause 6.7.2)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
7.2.6	Security context
7.2.6.1	Multiple registrations	S3‑180259	pCR: Multiple Registrations in different PLMNs using K_AUSF (Updated)	Qualcomm Incorporated	pCR	Approval	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
7.2.6.2	KDF agility
7.2.6.3	Intra-serving network handling
7.2.6.4	UE handling	S3‑180313	New UE requirement to store two 5G security contexts in TS 33.501	Ericsson, Qualcomm Incorporated	pCR	Approval	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‑180445	New UE requirement to store two 5G security contexts in TS 33.501	Ericsson, Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑180313
7.2.6.5	Emergency call
7.2.6.6	Miscellaneous	S3‑180055	Clarification on 5G security context	CATT	pCR	Approval	Yes	Yes	revised	No	S3‑180446
		S3‑180446	Clarification on 5G security context	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180055
7.2.6.7	Editorials
7.2.7	Visibility and Configurability
7.2.7.1	Miscellaneous	S3‑180333	Discussion of security visibility	NTT DOCOMO INC.	discussion	Endorsement	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‑180200	Clarification of security visibility	LG Electronics	pCR	Approval	Yes	Yes	revised	No	S3‑180453
		S3‑180453	Clarification of security visibility	LG Electronics	pCR	Approval	Yes	Yes	approved	No		S3‑180200
		S3‑180085	Authorization of SN by UE - was S3-173125	Nokia, LG Electronics	pCR	Decision	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‑180454	Authorization of SN by UE - was S3-173125	Nokia, LG Electronics	pCR	Approval	Yes	Yes	approved	No		S3‑180085
		S3‑180086	Visibility and configurability supporting serving network authorization - was S3-173126	Nokia, LG Electronics	pCR	Approval	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
7.2.7.2	Editorials
7.2.8	Primary authentication
7.2.8.1	5G AKA over 3gpp/non3gpp access	S3‑180092	Clause 6 Corrections for 5G AKA over n3gpp access	Nokia	pCR	Approval	Yes	Yes	approved	No
		S3‑180295	Construction of serving network name with 5G AKA and EAP-AKA’	Ericsson	pCR	Approval	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‑180390	Construction of serving network name with 5G AKA and EAP-AKA’	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180295
		S3‑180126	Removal of the number of AVs requested in Authentication Information Request message	Huawei, Hisilicon	pCR	Approval	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‑180391	Removal of the number of AVs requested in Authentication Information Request message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180126
		S3‑180127	Resolve Editor’s Note in clause 6.1.3.2 of TS 33.501	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180128	Adding 5G Authentication Confirmation Answer for 5G-AKA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180393
7.2.8.2	EAP AKA’ over 3gpp/non3gpp access	S3‑180293	New annex for 3GPP 5G profile on RFC 5448 EAP-AKA’	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑180344	Clean up the EN in 6.1.3.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180137
		S3‑180137	Clean up the EN in 6.1.3.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180344
7.2.8.3	Roaming/Multiple Authentication vectors
7.2.8.4	Authentication using EAP TLS	S3‑180173	Security Procedures for EAP-TLS	Huawei, Hisilicon, Ericsson, Qualcomm Incorporated, China Mobile	pCR	Approval	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‑180394	Security Procedures for EAP-TLS	Huawei, Hisilicon, Ericsson, Qualcomm Incorporated, China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑180173
7.2.8.5	Enhancements to authentication (Diffie-Hellman proposals etc)	S3‑180296	Adding forward secrecy for AKA in phase 2 without bidding-down problems	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑180336	Comments on Adding forward secrecy for AKA in phase 2 without bidding-down problems	China Mobile; Huawei; Hisilicon	discussion	Discussion	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
7.2.8.6	Authentication in Network sharing/limited deployment scenarios	S3‑180073	Removing Editor's note on network sharing	KPN	pCR	Approval	Yes	Yes	approved	No
7.2.8.7	Editorial corrections	S3‑180074	Normative text for support of both authentication methods and text clarification to distinguish HN and SN	Nokia	pCR	Decision	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‑180395	Normative text for support of both authentication methods and text clarification to distinguish HN and SN	Nokia,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑180074
		S3‑180075	Editorial clarification in clause on anchor key binding	Nokia	pCR	Decision	Yes	Yes	approved	No
		S3‑180294	Clarifications and clean-up of 5G AKA procedure	Ericsson	pCR	Approval	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‑180393	Clarifications and clean-up of 5G AKA procedure	Ericsson,Huawei,HiSilicon	pCR	Approval	Yes	YesContent was approved and merged in 396.	merged	No	S3‑180396	S3‑180294
		S3‑180071	Adding numbers to the figure for 5G AKA	KPN	pCR	Approval	Yes	Yes	revised	No	S3‑180396
		S3‑180396	Adding numbers to the figure for 5G AKA	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑180071
		S3‑180070	Adding numbers to the figure for EAP AKA prime	KPN	pCR	Approval	Yes	Yes	merged	No	S3‑180344
7.2.9	Secondary authentication
7.2.9.1	MitM	S3‑180195	Binding Primary and Secondary authentication	Intel	discussion	Endorsement	Yes	Yes	noted	No
		S3‑180186	Solution to prevent unauthorized access to external Data Network	Intel	pCR	Approval	Yes	Yes	noted	No
		S3‑180249	Identifying problems with secondary authentication	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No		S3‑173301
		S3‑180291	Proposal for way forward on the biding problem in the secondary	Ericsson	discussion	Endorsement	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
7.2.9.2	Incomplete procedure	S3‑180196	Secondary Re-Authentication	Intel	pCR	Approval	Yes	Yes	revised	No	S3‑180379
		S3‑180379	Secondary Re-Authentication	Intel	pCR	Approval	Yes	Yes	approved	No		S3‑180196
		S3‑180167	DN authorization grant and revocation	Huawei & Hisilicon	pCR	Approval	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‑180251	pCR to update the secondary EAP authentication clause to take into account the roaming scenario	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑180380	S3‑173303
		S3‑180380	pCR to update the secondary EAP authentication clause to take into account the roaming scenario	Qualcomm Incorporated,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180251
7.2.9.3	Efficiency / security improvement	S3‑180166	ID linkage verification in secondary authentication	Huawei & Hisilicon	pCR	Approval	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‑180168	Secondary Authentication for multiple PDU sessions	Huawei & Hisilicon	pCR	Approval	Yes	Yes	approved	No
		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	Yes	Yes	noted	No		S3‑173302
7.2.9.4	Miscellaneous	S3‑180237	Secondary Authentication: Align with SA2 procedure and removal of EN on making the figure updatable	Nokia	pCR	Approval	Yes	Yes	merged	No	S3‑180380
7.2.9.5	Editorial and clarification	S3‑180201	Clarification on network slice access authentication and authorization	LG Electronics	pCR	Approval	Yes	Yes	noted	No
		S3‑180236	Secondary authentication: Clause 12.1.2: Resolve ENs	Nokia	pCR	Approval	Yes	Yes	approved	No
7.2.10	Interworking
7.2.10.1	Idle mode 4G-5G	S3‑180281	Idle mode mobility from EPS to 5GS	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180439
		S3‑180439	Idle mode mobility from EPS to 5GS	Ericsson, Qualcomm,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180281
		S3‑180233	Interworking: Idle mode mobility from EPS to 5GS	Nokia	pCR	Approval	Yes	Yes	merged	No	S3‑180439
		S3‑180255	pCR to provide a text for idle mode mobility from EPC to 5GC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑180439	S3‑173305
7.2.10.2	Idle mode 5G-4G	S3‑180280	Idle mode mobility from 5GS to EPS	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180440
		S3‑180147	Idle mode mobility from 5GS to EPS with N26	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180440
		S3‑180234	Interworking; Idle mode mobility from 5G to 4G	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180440
		S3‑180440	Interworking; Idle mode mobility from 5G to 4G	Nokia,Qualcomm, Huawei,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180234
		S3‑180254	pCR to provide a text for idle mode mobility from 5GC to EPC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑180440	S3‑173305
7.2.10.3	Handover 5GC-EPS	S3‑180279	Handover from 5GS to EPS	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180441
		S3‑180148	Handover procedure from 5GS to EPS with N26	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180441
		S3‑180216	Handover from 5GS to EPS	NEC Telecom MODUS Ltd.	pCR	Approval	Yes	Yes	merged	No	S3‑180441
		S3‑180232	Interworking: Handover from 5GC to EPS	Nokia	pCR	Approval	Yes	Yes	merged	No	S3‑180441
		S3‑180252	pCR to provide a normative text for handover from 5GC to EPC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑180441	S3‑173305
		S3‑180441	pCR to provide a normative text for handover from 5GC to EPC	Qualcomm Incorporated,Nokia, NEC,Huawei,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180252
7.2.10.4	Handover EPS-5GC	S3‑180282	Handover from EPS to 5GS	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180442
		S3‑180218	Handover from EPS to 5GS	NEC Telecom MODUS Ltd.	pCR	Approval	Yes	Yes	merged	No	S3‑180442
		S3‑180231	Interworking: Handover from EPS to 5GS	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180442
		S3‑180442	Interworking: Handover from EPS to 5GS	Nokia, Qualcomm, NEC,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180231
		S3‑180253	pCR to provide a normative text for handover from EPC to 5GC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑180442	S3‑173305
7.2.10.5	Security context mapping	S3‑180283	Mapping of security contexts during interworking between EPS and 5GS	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180443
		S3‑180443	Mapping of security contexts during interworking between EPS and 5GS	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180283
7.2.10.6	Miscellaneous	S3‑180114	Interworking with EPC without N26 interface in single-registration mode	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: too much text; security-wise we just refer to 33.401. Nokia agreed.	revised	No	S3‑180444
		S3‑180444	Interworking with EPC without N26 interface in single-registration mode	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180114
7.2.10.7	Editorials
7.2.11	non-3GPP access
7.2.11.1	Miscellaneous	S3‑180012	Authentication for Untrusted Non-3GPP Access using EAP	Motorola Mobility, Lenovo, LG Electronics, Nokia, KPN, Broadcom, Brocade	pCR	Approval	Yes	Yes	revised	No	S3‑180455	S3‑173251
		S3‑180455	Authentication for Untrusted Non-3GPP Access using EAP	Motorola Mobility, Lenovo, LG Electronics, Nokia, KPN, Broadcom, Brocade	pCR	Approval	Yes	Yes	approved	No		S3‑180012
		S3‑180013	Addition of EAP-5G method ID	Lenovo, Motorola Mobility	CR	Approval	Yes	Yes	agreed	No
7.2.11.2	Editorials
7.2.12	NDS
7.2.12.1	Miscellaneous	S3‑180108	Security Procedures between 5G Network Functions	Huawei, Hisilicon	pCR	Approval	Yes	YesReworded to "shall be supported".	revised	No	S3‑180367
		S3‑180367	Security Procedures between 5G Network Functions	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180108
7.2.12.2	Editorials
7.2.13	Service based architecture
7.2.13.1	Interconnect (SEPP related)	S3‑180072	Conclusions from IPX Security Conference calls	KPN	report	Information	Yes	YesVodafone commented that this misrepresented what was agreed in the meeting in the first line.	noted	No
		S3‑180238	SBA: Prioritization for Phase 1	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180353
		S3‑180353	SBA: Prioritization for Phase 1	Nokia	other	Approval	Yes	Yes	approved	No		S3‑180238
		S3‑180028	Analysis of different approaches for implementing SBA security over N32 reference point	TIM (Telecom Italia) s.p.a.	discussion	Discussion	Yes	Yes	noted	No
		S3‑180210	Inter Operator Signalling Security in 5G Proposal	Deutsche Telekom AG	discussion	Decision	Yes	Yes	noted	No
		S3‑180299	LS on protection of HTTP messages between SEPPs	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑180352	Living document on SBA	China Mobile	other	discussion	Yes	Yes	noted	No
7.2.13.2	Protection of Attributes	S3‑180261	Reply LS on Use of Subscriber Identity in HTTP URI	Nokia	LS out	Approval	Yes	Yes	noted	No
		S3‑180298	LS (S3-180034/CT4-176395) on the Use of Subscriber Identity in HTTP URI	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑180239	SBA: Resolve EN on Information Elements that require protection	Nokia	other	Approval	Yes	Yes	revised	No	S3‑180354
		S3‑180354	SBA: Resolve EN on Information Elements that require protection	Nokia	other	Approval	Yes	Yes	approved	No		S3‑180239
		S3‑180329	Attributes requiring confidentiality protection on the N32 interface	Deutsche Telekom AG, KPN	pCR	Approval	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‑180355	Attributes requiring confidentiality protection on the N32 interface	Deutsche Telekom AG, KPN	pCR	Approval	Yes	Yes	approved	No		S3‑180329
		S3‑180260	SBA: Considerations on applying security on HTTP message payload	Nokia	discussion	Decision	Yes	Yes	noted	No
		S3‑180263	SBA: Resolve EN on use of JOSE with multiple HTTP Sessions between two NFs.	Nokia	other	Approval	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‑180356	SBA: Resolve EN on use of JOSE with multiple HTTP Sessions between two NFs.	Nokia	other	Approval	Yes	Yes	approved	No		S3‑180263
7.2.13.3	Transport security (intra and inter-PLMN)	S3‑180301	TLS mandatory to implement for SBA security	Ericsson	pCR	Approval	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‑180357	TLS mandatory to implement for SBA security	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180301
7.2.13.4	NF-NRF Authentication & Authorization	S3‑180300	Including authentication into authorization aspects	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180368
		S3‑180368	Including authentication into authorization aspects	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180300
		S3‑180152	Authentication in the service registration procedure	Huawei, Hisilicon	pCR	Approval	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‑180184	NF Service Register Request Procedure	Intel	pCR	Approval	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‑180358	NF Service Register Request Procedure	Intel	other	Approval	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‑180154	Authorization of NF service discovery	Huawei, Hisilicon	pCR	Approval	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‑180360	Authorization of NF service discovery	Huawei, Hisilicon	pCR	Approval	Yes	YesIt was agreed to summarize this contribution into a single sentence.	approved	No		S3‑180154
		S3‑180164	NF Service Discovery Request Procedure	Intel	pCR	Approval	Yes	Yes	noted	No
		S3‑180155	Authorization of NF service access	Huawei, Hisilicon	other	Approval	Yes	YesContribution to the living document.	approved	No
		S3‑180185	Security requirements for Service Request	Intel	pCR	Approval	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‑180361	Security requirements for Service Request	Intel	pCR	Approval	Yes	YesAgreed to remove the second and third requirements.	approved	No		S3‑180185
		S3‑180177	Merge two procedures of SBA authorization	Huawei, Hisilicon,	other	Approval	Yes	Yes	approved	No
		S3‑180359	Adding an editor's note on NF Service Register Request Procedure	Intel	pCR	Approval	Yes	YesAdding an editor's note based on the tdoc 358.	approved	No
7.2.13.5	NF-NF Authentication & Authorization	S3‑180225	Discussion and pCR about NF authentication for SBA	China Mobile	other	Approval	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‑180327	Considerations on Network Function Authorization in 5G SBA	Deutsche Telekom AG	discussion	Discussion	Yes	Yes	noted	No
		S3‑180264	SBA: Service access authorization	Nokia	pCR	Approval	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‑180165	NF Service Request Procedure	Intel	other	Approval	Yes	YesDecided to include it in the living document.	revised	No	S3‑180363
		S3‑180363	NF Service Request Procedure	Intel	other	Approval	Yes	Yes	approved	No		S3‑180165
7.2.13.6	Miscellaneous
7.2.13.7	Editorials	S3‑180054	Adding the abbreviations of NF and NFR	CATT	pCR	Approval	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‑180364	Adding the abbreviations of NF and NFR	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180054
7.2.14	Privacy
7.2.14.1	SUPI and LI	S3‑180240	Protecting the IMSI and IMEI in NAS Security Mode Command	Qualcomm Incorporated	discussion	Endorsement	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‑180331	Discussion on SUPI privacy proposals	NTT DOCOMO INC.	discussion	Decision	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‑180083	LI conformity when privacy is used - was S3-173124	Nokia, Orange, T-Mobile USA	pCR	Approval	Yes	Yes	noted	No		S3‑173124
		S3‑180051	Solution for meeting LI and privacy requirements	CATT	pCR	Approval	Yes	YesBT: this is far more reliable for LI.	noted	No
		S3‑180206	Meeting SUPI privacy and LI Requirements	Huawei, Hisilicon, Intel, China Mobile, CATT	pCR	Approval	Yes	Yes	noted	No		S3‑180101
		S3‑180265	Clause 6.7.2 (NAS SMC, SUPI from UE for LI)	Ericsson	pCR	Approval	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‑180082	Requirement on AMF related to LI	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180458
		S3‑180458	Requirement on AMF related to LI	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180082
		S3‑180326	pCR to 33.501 - SUPI Encryption Protocol: issues identified by ETSI SAGE	VODAFONE Group Plc	pCR	Approval	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‑180018	Solution for meeting LI and privacy requirements	CATT	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑180101	Meeting SUPI privacy and LI Requirements	Huawei, Hisilicon, Intel	pCR	Approval	No	Yes	revised	No	S3‑180206
		S3‑180457	SUPI and LI	WG Chair	other	Endorsement	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
7.2.14.2	SUCI and Schemes	S3‑180079	HN authorization of serving network actions directed to the UE	Nokia, KPN	discussion	Discussion	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	Yes	Yes	noted	No
		S3‑180081	Requirement on AMF related to HN authorization	Nokia, KPN	pCR	Decision	Yes	Yes	noted	No
		S3‑180266	Clause 5.1.5 (SUCI – on-the-fly indication to use null-scheme)	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑180049	Privacy requirement improvement related to using non null-scheme	CATT	pCR	Approval	Yes	YesVodafone disagreed. It’s the ME, not the UE. This was agreed.	revised	No	S3‑180460
		S3‑180460	Privacy requirement improvement related to using non null-scheme	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180049
		S3‑180258	Support of privacy schemes and profiles by the UE	Qualcomm Incorporated	pCR	Approval	Yes	YesVodafone: cool wit this as long as it is not just a single scheme.	noted	No
		S3‑180306	Annex C (SUCI – ECIES profiles)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180451
		S3‑180451	Annex C (SUCI – ECIES profiles)	Ericsson,Vodafone	pCR	Approval	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‑180337	Comments on S3-180306 - Annex C (SUCI – ECIES profiles)	Vodafone	pCR	Agreement	Yes	Yes	merged	No	S3‑180451
		S3‑180214	Updates to Clause 6.12.2 regarding protection scheme identification	NEC Telecom MODUS Ltd.	pCR	Approval	Yes	Yes	not treated	No
		S3‑180303	Clause 6.12.2 (SUCI – behaviours when USIM calculates SUCI)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑180324	SUCI calculation	Gemalto N.V.	pCR	Approval	Yes	Yes	not treated	No
		S3‑180302	Annex C (SUCI – scheme properties)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑180048	How AMF and SEAF deal with null-scheme SUCI	CATT	pCR	Approval	Yes	Yes	not treated	No
		S3‑180050	Privacy requirement of using SUCI in initial registration procedure	CATT	pCR	Approval	Yes	Yes	not treated	No
		S3‑180213	Discussion and pCR for privacy calculation in UE side	China Mobile, ZTE	pCR	Approval	Yes	Yes	not treated	No
		S3‑180197	Discussion on the enhancement of SUCI construction scheme	LG Electronics	discussion	Discussion	Yes	Yes	not treated	No
		S3‑180198	Additional input for SUCI construction - Annex C.	LG Electronics	pCR	Approval	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	Yes	Yes	not treated	No
		S3‑180010	Discussion Paper on the need and ways to make SUPI protection opaque to IMSI sniffers	InterDigital, Inc.	discussion	Decision	Yes	Yes	not treated	No
		S3‑180011	PCR to Annex C for making SUPI protection opaque to IMSI sniffers	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑180069	PCR to Section 6.12.2	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑180052	Solution for raw public key provisioning	CATT	pCR	Approval	Yes	Yes	not treated	No
		S3‑180015	How AMF and SEAF deal with null-scheme SUCI	CATT	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑180016	Privacy requirement improvement related to using non null-scheme	CATT	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑180017	Privacy requirement of using SUCI in initial registration procedure	CATT	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑180019	Solution for raw public key provisioning	CATT	pCR	Agreement	No	Yes	withdrawn	Yes
7.2.14.3	SIDF	S3‑180211	Discussion and pCR for SUCI home routing	China Mobile	pCR	Approval	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‑180267	NF discovery with SUCI	Ericsson	pCR	Approval	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‑180304	Clause 6.12.5 (SIDF – size of SUCI)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑180305	Clause 6.12.5 (SIDF – validating calculation of the SUCI)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑180212	Requirements on SIDF	NEC Telecom MODUS Ltd.	pCR	Approval	Yes	Yes	not treated	No
		S3‑180077	UDM requirements - key management and privacy - S3-173121	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑173121
7.2.14.4	Miscellaneous	S3‑180057	Discussion on Identity Request and Registration Procedures in 5G	KPN	discussion	Approval	Yes	Yes	not treated	No
		S3‑180058	LS to SA2 on Registration Request and Identity Request with clear text SUPI	KPN	other	Approval	Yes	Yes	not treated	No
		S3‑180059	Adding the subscription identification procedure to TS 33.501	KPN, Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑180140	Subscription identification procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑180268	Clause 6.12.4 (subscription identification procedure)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑180235	Adding Emergency Services paragraph for Subscription Identification procedure	KPN N.V.	pCR	Approval	Yes	Yes	not treated	No
7.2.14.5	Editorials	S3‑180084	Resolving editors note on emergency call handling	Nokia	pCR	Decision	Yes	Yes	not treated	No
		S3‑180078	SUCI intro and handling - was S3-173316	Nokia, KPN	pCR	Decision	Yes	Yes	not treated	No		S3‑173316
		S3‑180102	Moving UE handling SUCI to SUCI clause	Huawei, Hisilicon, CMCC	pCR	Approval	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	Yes	Yes	not treated	No
7.2.15	Incoming and outgoing LSes	S3‑180033	Reply LS on PLMN and RAT selection policies for roaming	C3-176332	LS in		Yes	Yes	noted	No
		S3‑180036	LS on maximum data rate of user plane integrity protected data	R2-1714125	LS in		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		Yes	Yes	replied to	No
		S3‑180348	Reply to: LS on Security aspects of supporting LTE connected to 5GC	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑180039	Reply LS on 5G Identity and Access Management Requirements	S1-174557	LS in		Yes	Yes	noted	No
		S3‑180040	Reply LS on selectively disabling legacy radio access	S1-174601	LS in		Yes	Yes	noted	No
		S3‑180044	Response LS on voice service continuity from 5G to 2/3G	SP-171078	LS in		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		Yes	Yes	postponed	No
		S3‑180046	LS on security during Resume reject in INACTIVE state in NR	R2-1712052	LS in		Yes	Yes	replied to	No
		S3‑180349	Reply to: LS on security during Resume reject in INACTIVE state in NR	Intel	LS out	approval	Yes	Yes	approved	No
		S3‑180034	LS on Use of Subscriber Identity in HTTP URI	C4-176395	LS in		Yes	Yes	noted	No
		S3‑180350	Reply to: LS on Use of Subscriber Identity in HTTP URI	Deutsche Telekom	LS out	approval	No	Yes	withdrawn	Yes
		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		Yes	Yes	noted	No
		S3‑180351	NGMN White Paper on Service-based Architecture in 5G	NGMN	LS in	discussion	Yes	YesThe Chair encouraged the delegates to have a look at the white paper.	noted	No
7.2.16	PLMN RAT selection	S3‑180035	LS on a potential USIM solution for PLMN and RAT selection policies for roaming	C6-170696	LS in		Yes	Yes	postponed	No
		S3‑180378	Reply to: LS on a potential USIM solution for PLMN and RAT selection policies for roaming	Vodafone	LS out	approval	No	Yes	withdrawn	Yes
		S3‑180112	Adding key issue to Living Document S3-173482	Huawei, Hisilicon; Samsung	other	Approval	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‑180369	Adding key issue to Living Document S3-173482	Huawei, Hisilicon; Samsung	other	Approval	Yes	Yes	approved	No		S3‑180112
		S3‑180316	New key issue on UE behaviour on failing integrity check	Ericsson	other	Approval	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‑180370	New key issue on UE behaviour on failing integrity check	Ericsson	other	Approval	Yes	Yes	approved	No		S3‑180316
		S3‑180113	Adding potential solution for living document S3-173482	Huawei, Hisilicon; Samsung	other	Approval	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‑180372	Adding potential solution for living document S3-173482	Huawei, Hisilicon; Samsung	other	Approval	Yes	Yes	approved	No		S3‑180113
		S3‑180317	New solution: Protected UE configuration update commands	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑180374
		S3‑180374	New solution: Protected UE configuration update commands	Ericsson	other	Approval	Yes	YesAdding editor's notes addressing the received comments.	approved	No		S3‑180317
		S3‑180318	New solution: key management via AUSF	Ericsson	pCR	Approval	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‑180375	New solution: key management via AUSF	Ericsson	other	Approval	Yes	Yes	approved	No		S3‑180318
		S3‑180319	Addition of soltion to living document (Steering of roaming)	Vodafone GmbH	other	Approval	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‑180377	Addition of solution to living document (Steering of roaming)	Vodafone GmbH	other	Approval	Yes	Yes	approved	No		S3‑180319
		S3‑180371	Living document on PLMN RAT selection	ORANGE	other	Approval	Yes	Yes	noted	No
		S3‑180373	Concerns of the use of authentication for steering of roaming	Vodafone	LS out	Approval	Yes	YesThis was sent during the meeting.	approved	No
7.2.17	Others	S3‑180247	Adding references to the algorithm test data	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑180416
		S3‑180416	Adding references to the algorithm test data	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑180247
		S3‑180362	Draft TS 33.501	NTT-Docomo	draft TS	Approval	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
7.3	Mission Critical Security Enhancements (eMCSec) (Rel-15)	S3‑180038	LS on Removal of 'over LTE' limitation from Mission Critical Specifications	S1- 174542	LS in		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		Yes	Yes	noted	No
		S3‑180332	[eMCSEC] Adding Integrity Key for KMS communications	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑180160	[eMCSec] 33180 R15 Interworking SeGy clarification	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑180386
		S3‑180386	[eMCSec] 33180 R15 Interworking SeGy clarification	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑180160
		S3‑180153	[eMCSec] 33180 R15 IWF security	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	merged	No	S3‑180386
		S3‑180229	Document showing the changes to SeGy functionality	NCSC	discussion	Discussion	Yes	Yes	noted	No
		S3‑180228	[eMCSEC] Security Gateway clause update and move to annex	NCSC	CR	Agreement	Yes	Yes	merged	No	S3‑180386
		S3‑180226	[eMCSEC] Notifying the use of Security Gateways	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑180227	[eMCSEC] LS to SA6 on Security Gateway notification	NCSC	LS out	Approval	Yes	Yes	revised	No	S3‑180387
		S3‑180387	[eMCSEC] LS to SA6 on Security Gateway notification	NCSC	LS out	Approval	Yes	Yes	approved	No		S3‑180227
		S3‑180156	[eMCSec] 33.180 R15 Interworking media and signaling	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑180376
		S3‑180376	[eMCSec] 33.180 R15 Interworking media and signaling	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑180156
		S3‑180158	[eMCSec] 33180 R15 Interworking key mgmt (InterSD)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑180413
		S3‑180413	[eMCSec] 33180 R15 Interworking key mgmt (InterSD)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑180158
		S3‑180159	[eMCSec] 33180 R15 Interworking key mgmt (MCData)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑180163	New WID for MONASTERY security	Motorola Solutions UK Ltd.	WID new	Agreement	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‑180385	New WID for MONASTERY security	Motorola Solutions UK Ltd.	WID new	Agreement	Yes	Yes	agreed	No		S3‑180163
		S3‑180427	Changes to TS 33.180 from SA3#90	NCSC	other	Information	Yes	Yes	noted	No
7.4	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)	S3‑180157	Authorization of SCS/AS to send requests for the 3GPP Network Entity	Huawei, Hisilicon	CR	Approval	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‑180459	Exception Sheet NAPS-Sec	Huawei	WI exception request	Agreement	Yes	Yes	withdrawn	Yes
7.5	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)	S3‑180207	Scope of CAPIF security	Huawei, Hisilicon, China Mobile	pCR	Approval	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‑180307	CAPIF Security requirements	Samsung, Motorola Solutions	pCR	Approval	Yes	Yes	revised	No	S3‑180392
		S3‑180392	CAPIF Security requirements	Samsung, Motorola Solutions,China Unico,Huawei,China Mobile, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180307
		S3‑180224	Security requirements on the CAPIF-4 reference point	China Mobile, Huawei	pCR	Approval	Yes	Yes	merged	No	S3‑180392
		S3‑180191	Key issue on topology hiding of the service	China Unicom, China Mobile	pCR		Yes	Yes	merged	No	S3‑180392
		S3‑180192	ey issue on secure communication between functions in CAPIF	China Unicom, China Mobile	pCR		Yes	Yes	merged	No	S3‑180392
		S3‑180144	Additional security requirements for 3rd party API provider	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180392
		S3‑180208	Security requirements on CAPIF entities	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	merged	No	S3‑180392	S3‑180143
		S3‑180309	Security procedure for CAPIF-1e reference point	Samsung	pCR	Approval	Yes	Yes	approved	No
		S3‑180312	Security Procedure for CAPIF-2e reference point	Samsung	pCR	Agreement	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‑180403	Security Procedure for CAPIF-2e reference point	Samsung	pCR	Agreement	Yes	Yes	approved	No		S3‑180312
		S3‑180314	CAPIF security within PLMN Trust Domain	Samsung	pCR	Approval	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‑180404	CAPIF security within PLMN Trust Domain	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑180314
		S3‑180142	Scope of CAPIF security	Huawei, Hisilicon	pCR	Approval	No	Yes	revised	No	S3‑180207
		S3‑180143	Security requirements on CAPIF entities	Huawei, Hisilicon	pCR	Approval	No	Yes	revised	No	S3‑180208
		S3‑180401	Draft TS 33.122	Samsung	draft TS	Approval	Yes	Yes	approved	No
7.6	Other work areas
7.6.1	SAE/LTE Security	S3‑180245	Discussion on completing the LTE bidding down procedures	Qualcomm Incorporated	discussion	Discussion	Yes	Yes	noted	No
7.6.2	IP Multimedia Subsystem (IMS) Security	S3‑180325	Clarification for TCP connection reuse	Ericsson Limited	CR	Agreement	Yes	Yes	revised	No	S3‑180417
		S3‑180417	Clarification for TCP connection reuse	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No		S3‑180325
7.6.3	Network Domain Security (NDS)	S3‑180262	Clarification need of CMPv2 in TS 33.310	Ericsson	discussion	Endorsement	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
7.6.4	UTRAN Network Access Security
7.6.5	GERAN Network Access Security
7.6.6	Generic Authentication Architecture (GAA)
7.6.7	Multimedia Broadcast/Multicast Service (MBMS)
7.6.8	Security Aspects of Home(e)NodeB (H(e)NB)
7.6.9	Security Aspects related to Machine-Type Communication ((e)MTC)	S3‑180029	Collection of clarifications and editorial changes to BEST TS 33.163	Deutsche Telekom AG	CR	Approval	Yes	YesBEST is not part of the agenda of this meeting.	postponed	No
7.6.10	Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)
7.6.11	Security of MCPTT (MCPTT)
7.6.12	Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)
7.6.13	Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)
7.6.14	New GPRS algorithms for EASE (EASE_ALGOs_SA3)
7.6.15	Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP)
7.6.16	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑180088	Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.14	Nokia	CR	Agreement	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‑180419	Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.14	Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑180088
		S3‑180089	Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.15	Nokia	CR	Agreement	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	Yes	Yes	revised	No	S3‑180420
		S3‑180420	Collection of changes based on feedback from GSMA SECAG - CR to 33.916v1 Rel.14	Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑180090
		S3‑180091	Collection of changes based on feedback from GSMA SECAG - CR to 33.916v1 Rel.15	Nokia	CR	Agreement	Yes	Yes	not pursued	No
		S3‑180345	NESAS Pilot Findings and Recommendations to SA3	GSMA SECAG	LS in	Information	Yes	Yes	replied to	No
		S3‑180418	Reply to: NESAS Pilot Findings and Recommendations to SA3	Nokia	LS out	approval	Yes	Yes	approved	No
7.6.17	Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec)
7.6.18	Security of the Mission Critical Service (MCSec)	S3‑180315	LS to CT1 on Protected Payload message type	NCSC	LS out	Approval	Yes	Yes	revised	No	S3‑180388
		S3‑180388	LS to CT1 on Protected Payload message type	NCSC	LS out	Approval	Yes	Yes	approved	No		S3‑180315
7.6.19	Other work items
7.7	New Work Item proposals	S3‑180222	New WID on GBA enhancements for Internet of Things	China Mobile, CATR, China Unicom	WID new	Agreement	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‑180381	New SID on GBA enhancements	China Mobile, CATR, China Unicom	SID new	Agreement	No	Yes	withdrawn	Yes
		S3‑180335	New WID for 5G SCAS	Huawei, Hisilicon,Ericsson	WID new	Agreement	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‑180383	New WID for 5G SCAS	Huawei, Hisilicon,Ericsson	WID new	Agreement	Yes	YesVodafone commented that there isn’t much time to deal with this and that 5G should have preference.	agreed	No		S3‑180335
7.8	Documents on joint meeting with SA6 regarding eMCSec	S3‑180382	Presentation for Joint SA3/SA6 meeting	NCSC	other	Presentation	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‑180402	LMR interworking key management summary	Harris Corporation	other	Presentation	Yes	Yes	noted	No
8	Studies
8.1	Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-15)	S3‑180161	[FS_MC_Sec] 33880 Interworking eval (InterSD)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑180414
		S3‑180414	[FS_MC_Sec] 33880 Interworking eval (InterSD)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑180161
		S3‑180162	[FS_MC_Sec] 33880 Interworking eval (MCData)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	withdrawn	Yes
8.2	Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)	S3‑180060	Discussion on PC-5 security	KPN	discussion	Endorsement	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‑180115	Clarification of Introduction of REAR	Huawei, Hisilicon	pCR	Approval	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‑180405	Clarification of Introduction of REAR	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180115
		S3‑180116	Delete Editor’s notes in clause 5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑180062	Resolving Editor's Note in clause 5.3	KPN	pCR	Approval	Yes	Yes	noted	No
		S3‑180067	Miscellaneous editorials to TR 33.843	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑180063	Resolving Editor's Note in clause 6.2	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑180117	Clarification of solution #4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180407
		S3‑180064	Resolving Editor's Note and adding evaluation in clause 6.4.3	KPN	pCR	Approval	Yes	Yes	revised	No	S3‑180407
		S3‑180407	Resolving Editor's Note and adding evaluation in clause 6.4.3	KPN,Huawei,HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180064
		S3‑180122	Add Evaluation for Solution #6	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑180065	Evaluation of solution #6	KPN	pCR	Approval	Yes	Yes	noted	No
		S3‑180120	Clarification of solution #7	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: remove "minor" from the impact.	revised	No	S3‑180408
		S3‑180408	Clarification of solution #7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180120
		S3‑180118	Clarification of solution #8	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑180119	Add Evaluation for Solution #12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180409
		S3‑180409	Add Evaluation for Solution #12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180119
		S3‑180123	Add Evaluation for Solution #13	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180410
		S3‑180410	Add Evaluation for Solution #13	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180123
		S3‑180066	Evaluation of solution #13	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑180121	Conclusion for the Key Issues	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180411
		S3‑180411	Conclusion for the Key Issues	Huawei, Hisilicon,KPN	pCR	Approval	Yes	Yes	approved	No		S3‑180121
		S3‑180068	Adding conclusions for key issues 1,4, and 5 and adding an overal conclusions clause	KPN	pCR	Approval	Yes	Yes	merged	No	S3‑180411
		S3‑180061	Discussion and pCR on authorization	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑180406	Draft TR 33.843	Huawei	draft TR	Approval	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‑180412	Cover sheet TR 33.843	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
8.3	Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)	S3‑180172	draft LS on the status of work on interfaces	Huawei & Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑180436
		S3‑180436	draft LS on the status of work on interfaces	Huawei & Hisilicon	LS out	Approval	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‑180169	A key issue proposal on security capability for TR33.811	Huawei, Hisilicon, China Moible, China Unicom, CATR, CATT	pCR	Approval	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‑180437	A key issue proposal on security capability for TR33.811	Huawei, Hisilicon, China Moible, China Unicom, CATR, CATT	pCR	Approval	Yes	YesKey issue will verse on the negotiation.	approved	No		S3‑180169
		S3‑180170	A key issue proposal on security level	Huawei, Hisilicon, China Moible, China Unicom, CATR, CATT	pCR	Approval	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	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‑180179	Confidentiality protection of NSST	Huawei, Hisilicon,	pCR	Approval	Yes	Yes	approved	No
		S3‑180180	Confidentiality protection of NSI monitoring data	Huawei, Hisilicon,	pCR	Approval	Yes	Yes	approved	No
		S3‑180438	Draft TR 33.811	Huawei	draft TR	Approval	No	Yes	approved	No
8.4	Other study areas	S3‑180109	The impaction of 256 bit keys for NG areas	CATT	other		Yes	Yes	withdrawn	Yes
		S3‑180110	The clarification of the entropy CK and IK	CATT	other		Yes	Yes	withdrawn	Yes
8.5	New study item proposals	S3‑180187	Discussion paper on voice service continuity between 5G and 3G	China Unicom, Huawei, HiSilicon, ZTE, CATR, OPPO	discussion		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		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‑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	-	Yes	Yes	agreed	No		S3‑180188
		S3‑180189	Discussion paper on encrypted traffic detection and verification	China Unicom, Huawei, HiSilicon, ZTE, CATR, OPPO	discussion		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		Yes	YesEricsson: wait for SA2 to work further.Nokia agreed. There wasn't much support for this Study item.	noted	No
		S3‑180205	new SID on security of 5WWC	Huawei, Hisilicon	SID new	Agreement	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
9	Review and Update of Work Plan	S3‑180002	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
		S3‑180005	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑180346
		S3‑180346	Work Plan input from Rapporteurs	MCC	other	-	No	Yes	noted	No		S3‑180005
10	Future Meeting Dates and Venues	S3‑180004	SA3 meeting calendar	MCC	other		Yes	Yes	revised	No	S3‑180366
		S3‑180366	SA3 meeting calendar	MCC	other	-	No	YesAd-hoc in July 2018 was removed.	noted	No		S3‑180004
11	Any Other Business
12	Close