TDoc list

Tdoc List

2018-03-02 12:54

Agenda	Topic	TDoc	Title	Source	Type	For	Avail	Treated	Decision	Wdrn	Replaced-by	Replaces
1	Opening of the Meeting
1.1	Approval of last SA3 meeting report	S3‑180840	Report from SA3#90	MCC	report		Yes	Yes Action item for Nokia remains open until next meeting.	approved	No
2	Approval of Agenda and Meeting Objectives	S3‑180500	Agenda	WG Chair	agenda		Yes	Yes Tim (Vodafone) commented that they had two concerns: - PLMN RAT selection should not be part of the 5G work item. The documents should be treated somewhere else. - No voting should be performed without having agreed on the questions before the meeting. This could go against the working procedures. ORANGE commented that PLMN RAT selection had been on the 5G agenda item in the last three meetings, so why disagreeing on this now? Docomo commented that this is based on incoming LS and not in the WID objectives. The LS should describe where this work should be placed. SA3 should not make the decision of this being part of the 5G work and it should be escalated to SA/CT. This part can be added with a CR in 33.501 later. ORANGE: CT1 does the stage 2 of this work as a 5G item. BT commented that this had to be part of the 5G since the signalling must be received in the 5G network. Vodafone replied that this worl is part of a Study Item. CT1 taking care of this was decided in Gothenburg (previous meeting) and not earlier than that. ORANGE commented that the 5G feature list was not exhaustive, left deliberatly open to introduce more features. This is clearly a 5G feature. Vodafone agreed with Docomo and had a sustained objection to treat this in the 5G agenda item. This objection was asked to be minuted. They also commented that they would object to all documents in that agenda item. ORANGE: PLMN RAT selection moved somewhere else would mean that it would not go into TS 33.501. Samsung,NEC and Qualcomm supported ORANGE. Ericsson clarified that this was part of 5G phase one. The Chair decided to keep it in the 5G item and discuss offline how to handle this issue. Ericsson commented that CMPv2 was supposed to be in the agenda, and that the documents were present in AoB agenda item. And additional agenda item was added here. The Chair commented that the voting questions could be decided during the meeting. Vodafone commented that this was going against 3GPP working procedures. This had to be discussed offline. NOTE from MCC: this is unusual but the working procedures recommend an appropriate timing without specifying when, hence allowed.	revised	No	S3‑180847
		S3‑180847	Agenda	WG Chair	agenda	-	Yes	Yes	revised	No	S3‑180996	S3‑180500
		S3‑180996	Agenda	WG Chair	agenda	-	Yes	Yes Revised to move the PLMN RAT selection documents to another agenda item.	approved	No		S3‑180847
3	IPR and Anti-Trust Law Reminder
4	Work Areas
4.1	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
4.1.1	Key hierarchy
4.1.1.1	Miscellaneous	S3‑180509	Overview of 5G security architecture	Huawei, Hisilicon, China Mobile, CATR, ZTE	pCR	Approval	Yes	Yes ORANGE: relationship number VI is not correct, according to TS 33.102. Huawei agreed that this could be changed. ORANGE: what is relationship II? Huawei: Network Domain Security. Telecom Italia suggested some changes in bullet number one. IDEMIA: I) should go to USIM.	revised	No	S3‑180858
		S3‑180858	Overview of 5G security architecture	Huawei, Hisilicon, China Mobile, CATR, ZTE	pCR	Approval	Yes	Yes	approved	No		S3‑180509
		S3‑180771	Key hierarchy	Nokia	pCR	Decision	Yes	Yes	revised	No	S3‑180859
		S3‑180859	Key hierarchy	Nokia,Lenovo	pCR	Decision	Yes	Yes	approved	No		S3‑180771
		S3‑180539	Discussion on deletion of Kseaf	ZTE Corporation, Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑180581	Re-discussion on deleting KSEAF from key hierarchy	Huawei, Hisilicon, ZTE	discussion	Endorsement	Yes	Yes Qualcomm: no need to re-open these discussions after what we have agreed. NEC: there would be a backward compatilibity issue here. Docomo: keep the Kseaf. KPN, BT, DT agreed. China Mobile: ask SA2. BT: SA3 decided to keep it; security issues are dealt here. The Chair commented that there was major support on keeping the Kseaf.	noted	No
		S3‑180782	Adding the identifier of KSEAF	Qualcomm Incorporated	pCR	Approval	Yes	Yes There was some disagreement to remove the editor's note on KAUSF and KSEAF needing to be identified. This was considered still an open issue for some companies. Huawei: when do we need to identify the KSEAF? Docomo: Once the KAUSF is identified the KSEAF is identified as well, and viceversa.	revised	No	S3‑180860
		S3‑180860	Adding the identifier of KSEAF	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑180782
		S3‑180760	Resolving Editor’s Notes in clause 6.2.2	NEC	pCR	Approval	Yes	Yes Huawei: we don’t agree with "The KSEAF shall be stored at the SEAF". Docomo: take the requirement out of the note. We also need to number the notes.	revised	No	S3‑180867
		S3‑180867	Resolving Editor’s Notes in clause 6.2.2	NEC	pCR	Approval	Yes	Yes	approved	No		S3‑180760
		S3‑180573	Resolving Editor's Notes in clauses 6.2.1 and 6.2.2.1	KPN N.V.	pCR	Approval	Yes	Yes Only the first change was approved.	revised	No	S3‑180868
		S3‑180868	Resolving Editor's Notes in clauses 6.2.1 and 6.2.2.1	KPN N.V.	pCR	Approval	Yes	Yes	approved	No		S3‑180573
4.1.1.2	Editorials	S3‑180522	Resolving Editor’s Note in clause 3.1 and cleaning up some definitions	KPN	pCR	Approval	Yes	Yes The definition clause affects tdoc 830 from IDEMIA.	revised	No	S3‑180869
		S3‑180869	Resolving Editor’s Note in clause 3.1 and cleaning up some definitions	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑180522
		S3‑180518	deleting the duplicate ENs about the Kausf storage	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180871
		S3‑180871	deleting the duplicate ENs about the Kausf storage	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180518
		S3‑180772	Correction to clause 6.1.4	Nokia	pCR	Decision	Yes	Yes	revised	No	S3‑180872
		S3‑180872	Correction to clause 6.1.4	Nokia	pCR	Decision	Yes	Yes	approved	No		S3‑180772
4.1.2	Key derivation
4.1.2.1	Key derivation mobility related	S3‑180726	Input to horizontal key derivation at AMF change	Ericsson	pCR	Approval	Yes	Yes	noted	No
4.1.2.2	Key derivation NAS related
4.1.2.3	Key derivation AS related	S3‑180652	Addressing EN in Key setting clause	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180994	Addressing EN in Key setting clause	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑180724	Derivation of KgNB and KN3IWF	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180995
		S3‑180657	Making Kupint & Kupenc per PDU session. Key hirariechy, who will be taking this?	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	revised	No	S3‑180839
4.1.2.4	Miscellaneous	S3‑180519	deleting the duplicate ENs about ngKSI	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180861
		S3‑180861	deleting the duplicate ENs about ngKSI	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180912	S3‑180519
		S3‑180912	deleting the duplicate ENs about ngKSI	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180982	S3‑180861
		S3‑180982	deleting the duplicate ENs about ngKSI	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180912
		S3‑180586	Remove the service network name from the key material used to derive KAUSF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180781	Deleting the editor’s note on KAUSF derivation	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑180601	Resolving Editor’s note in clause on key setting	CATT	pCR	Approval	Yes	Yes	merged	No	S3‑180862
		S3‑180651	Delete EN in section 6.2.2.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑180746	Agenda and notes of conference call on bidding down between 5G releases	Ericsson	report	Information	Yes	Yes	noted	No
		S3‑180747	Coexistence of Phase 1 and 2 AMF with standalone SEAF	Ericsson	discussion	Information	Yes	Yes Discussed in the conference call. Provided for information.	noted	No
		S3‑180546	Editorial modification on keys in AMF	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑180997
		S3‑180997	Editorial modification on keys in AMF	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑180546
4.1.2.5	Editorials	S3‑180626	Corrections on clause number of Annex A	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180995
		S3‑180995	Corrections on clause number of Annex A	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180626
		S3‑180663	Moving interfaces Xn, N2, and N3 security requirements to a proper clause	Huawei, Hisilicon,NEC	pCR	Approval	Yes	Yes	approved	No		S3‑180658
		S3‑180773	Editorial correction to annex A.6	Nokia	pCR	Decision	Yes	Yes	approved	No
		S3‑180658	Moving interfaces Xn, N2, and N3 security requirements to a proper clause	Huawei, Hisilicon	pCR	Approval	No	Yes	revised	No	S3‑180663
4.1.3	Mobility
4.1.3.1	Key derivations during handovers	S3‑180578	Resolving Editor’s Notes on horizontal K'AMF derivation during mobility	Huawei; Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180953
		S3‑180953	Resolving Editor’s Notes on horizontal K'AMF derivation during mobility	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180578
		S3‑180790	pCR to propose a KAMF derivation function and resolve ENs regarding KAMF derivation	Qualcomm Incorporated	pCR	Approval	Yes	Yes Discussed together with 577 and 726. Nokia supported the Downlink count option. NEC: which downlink count you refer to? There are two. Qualcomm: the one for the 3GPP access.	noted	No
		S3‑180577	Resolving Editor’s Notes on Input parameters for K'AMF derivation	Huawei; Hisilicon	pCR	Approval	Yes	Yes Huawei: the advantage is that you don’t need to derive a new KAMF.ZTE supported this, as they considered this was the simplest way. Ericsson: you need to signal the GUAMI to the UE first before the connection and this would be redundant, since you have to send it again later. Samsung preferred the NONCE solution. Qualcomm agreed to go this way to progress.	noted	No
4.1.3.2	Security in AMF change between AMF sets	S3‑180728	N2-handover with horizontal key derivation	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180954
		S3‑180954	N2-handover with horizontal key derivation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180728
		S3‑180540	Discussion on N2 handover procedure	ZTE Corporation	discussion	Endorsement	Yes	Yes	noted	No
		S3‑180541	N2 handover procedure	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑180955
		S3‑180955	N2 handover procedure	ZTE Corporation,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180541
		S3‑180616	Resolving Editors notes - 6.9.3 Key handling in mobility registration update - list of parameters to be stored in the UDSF as part of the 5G security context	BT plc	pCR	Agreement	Yes	Yes Ericsson commented that this interface was supposed to be proprietary and that removing the editor's note should be enough.	revised	No	S3‑180956
		S3‑180956	Resolving Editors notes - 6.9.3 Key handling in mobility registration update - list of parameters to be stored in the UDSF as part of the 5G security context	BT plc	pCR	Agreement	Yes	Yes	approved	No		S3‑180616
4.1.3.3	Security in AMF change within an AMF set
4.1.3.4	Resolving Editor’s Notes in Clause 8.3 (Access Stratum)
4.1.3.5	Parameter/Message Name alignment
4.1.3.6	Miscellaneous	S3‑180550	Modification on Xn handover procedure	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑180852
		S3‑180852	Modification on Xn handover procedure	ZTE Corporation,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180550
		S3‑180632	Clean up the EN in 6.9.4.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
4.1.3.7	Editorials	S3‑180625	Resolving the Annex on Security handling in mobility (clause 6.9) and deleting Editor’s Note in clauses 6.9.2.3.4 and 6.9.4.5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
4.1.4	AS Security	S3‑180972	LS on UP security policy handling during handover	Ericsson	LS out	Approval	Yes	Yes	approved	No
		S3‑180986	LS on security context setup	Ericsson	LS out	Approval	Yes	Yes	approved	No
4.1.4.1	Userplane open issues	S3‑180650	Delete EN of UP security agreement	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180942
		S3‑180751	Clause 6 (agreements forgotten to get recorded)	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑180791	pCR to remove some ENs in Clause 6 that have already been addressed in the present specification or are irrelevant of the present specification	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑180942
		S3‑180661	Update requirements of UP security	Huawei, Hisilicon	pCR	Approval	Yes	Yes Docomo: do we have this concept od deactivation? It was agreed to remove it. Ericsson, Qualcomm: the second requirement in 5.1.3.1 is not really a requirement, it’s a procedure. It was taken offline where to place this second sentence.	revised	No	S3‑180942
		S3‑180942	Update requirements of UP security	Huawei, Hisilicon,ZTE,KPN,Qualcomm	pCR	Approval	Yes	Yes	approved	No		S3‑180661
		S3‑180545	Editorial modification on gNB requirement on (de)activating protection	ZTE Corporation	pCR	Approval	Yes	Yes	merged	No	S3‑180942
		S3‑180525	Resolving Editors' Notes in clauses 5.2.3 and 5.3.3	KPN	pCR	Approval	Yes	Yes	merged	No	S3‑180942
4.1.4.2	Userplane security	S3‑180665	Discussion on security key for CU-CP UP separation	LG Electronics	discussion	Discussion	Yes	Yes	noted	No
		S3‑180839	Security for CU-CP and CU-UP split	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No		S3‑180657
		S3‑180659	UP security keys separation for the case of CU-CP and CU-UP separation.	Huawei, Hisilicon	pCR	Approval	Yes	Yes Vodafone disagreed with this proposal. Ericsson: this has UE impact so we disagree with the key separation. Huawei: we would have here two different entities with the same key for different traffic for the same UE, and this should be communicated to RAN3 in the LS response. Nokia: the two entities are not visible to the UE. The Chair commented that the support was leaning to the Nokia proposal.	noted	No
		S3‑180607	Discussion paper on R3-180630 LS on security for CU-CP/UP separation	Nokia	pCR	Approval	Yes	Yes Huawei and Ericsson: we cannot mandate IPSec here. It was commented that the discussion included a pCR at the end, so the type was changed. The sentence with IPSec was modified to require confidentiality and integrity protection in the E1 interface.	revised	No	S3‑180850
		S3‑180850	Discussion and pCR on R3-180630 LS on security for CU-CP/UP separation	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180607
		S3‑180608	draft_Reply LS to R3-180630 on CU-CP/UP separation	Nokia	LS out	Approval	Yes	Yes Vodafone: The assumption that VM is in the cloud is irrelevant. We don’t agree with this.Ericsson agreed and added that SA3 should not mandate IPsec.	revised	No	S3‑180849
		S3‑180849	Reply LS to R3-180630 on CU-CP/UP separation	Nokia	LS out	Approval	Yes	Yes	approved	No		S3‑180608
		S3‑180511	Resolving Editor’s Note in UP security policy by aligning with SA2 procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180920
		S3‑180748	Clause 6.6.2 (userplane security policy)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180920
		S3‑180920	Clause 6.6.2 (userplane security policy)	Ericsson,Huawei	pCR	Approval	Yes	Yes It was decided to send an LS to RAn2,RAN3 and SA2 to inform them about this document.	approved	No		S3‑180748
		S3‑180645	UP keys are derived after receiving the security policy	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180944
		S3‑180774	Improvement of text in subclause 6.6.2	NEC Europe Ltd	pCR	Approval	Yes	Yes	merged	No	S3‑180944
		S3‑180750	Clause 6.6.2 (userplane security activation)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180944
		S3‑180944	Clause 6.6.2 (userplane security activation)	Ericsson,Huawei,NEC	pCR	Approval	Yes	Yes	approved	No		S3‑180750
		S3‑180643	Transfer Security policy in Xn HO	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180945
		S3‑180945	Transfer Security policy in Xn HO	Huawei, Hisilicon,Ericsson, Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑180643
		S3‑180644	Transfer Security policy in N2 HO	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180946
		S3‑180946	Transfer Security policy in N2 HO	Huawei, Hisilicon,Ericsson, Qualcomm Incorporated, NEC	pCR	Approval	Yes	Yes	approved	No		S3‑180644
		S3‑180943	LS on support of user plane encrytption as part of user plane security policy	Huawei	LS out	Approval	Yes	Yes	approved	No
4.1.4.3	RRC security	S3‑180609	Discussion paper on RAN2 LS R2-1801649 on DRB id value range	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑180610	draft Reply LS to R2-1801649 on RAN2 Assumption about DRB ID value range	Nokia	LS out	Approval	Yes	Yes	revised	No	S3‑180848
		S3‑180848	Reply LS to R2-1801649 on RAN2 Assumption about DRB ID value range	Nokia	LS out	Approval	Yes	Yes	approved	No		S3‑180610
		S3‑180637	AS algorithm selection in state transitions between RRC-INACTIVE to RRC-CONNECTED states	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180638	Key Handling at Transitions between RRC-INACTIVE and RRC-CONNECTED states	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180639	Key Handling during mobility in RRC-INACTIVE state	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180752	Clause 6.8.2.1 (key handling – RRC INACTIVE/CONNECTED state transition)	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑180874	Clause 6.8.2.1 (key handling – RRC INACTIVE/CONNECTED state transition)	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑180753	Clause 6.8.2.2 (key handling – RRC INACTIVE mobility)	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑180596	Adding context on RRC security mechanisms	CATT	pCR	Approval	Yes	Yes	merged	No	S3‑180947
		S3‑180641	RRC Security Mechanisms	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180947
		S3‑180947	RRC Security Mechanisms	Huawei, Hisilicon,CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180641
		S3‑180749	Editor Note in clause 6.7.4 about the use of AS SMC in DC	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180948
		S3‑180948	Editor Note in clause 6.7.4 about the use of AS SMC in DC	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180749
		S3‑180640	Security handling for RRC Connection Re-establishment Procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑180660	Retain Key policy on gNB	Huawei, Hisilicon	pCR	Approval	No	Yes	revised	No	S3‑180662
		S3‑180662	Retain Key policy on gNB	Huawei, Hisilicon,Chinamobile	pCR	Approval	Yes	Yes	noted	No		S3‑180660
4.1.4.4	Miscellaneous
4.1.4.5	Editorials	S3‑180642	Add Skeleton for Dual Connectivity	Huawei, Hisilicon	pCR	Approval	Yes	Yes Docomo: When are we planning to fill in the text? I'd rather have this as a draftCR/CR in the next meeting.	noted	No
4.1.5	NAS security
4.1.5.1	Requirements	S3‑180689	NIA0 support in the AMF	Orange	pCR	Approval	Yes	Yes	revised	No	S3‑180873
		S3‑180873	NIA0 support in the AMF	Orange	pCR	Approval	Yes	Yes	approved	No		S3‑180689
4.1.5.2	Protection of initial NAS message	S3‑180744	Removal of initial NAS protection (clause 6.4.6)	Ericsson	pCR	Approval	Yes	Yes Deutsche Telekom didn’t agree with removing this clause. They wanted to see a detail of what Ies to protect and which ones not to protect. Ericsson: the work here on the IEs hasn’t progressed with contributions, hence we remove it. Qualcomm: ask SA2 whether we are protecting an IE that is needed. Huawei: too late to go back to SA2 to ask for any changes, we agree with Ericsson. The Chair asked for a show of hands: BT,Nokia,Huawei, China Mobile supported this document. Against: Deutsche Telekom, Qualcomm, T-Mobile.	noted	No
		S3‑180778	Removal of the hashing method from NAS SMC as security covered by the initial NAS message protection	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑180534	resolving editor’s notes on protection the initial NAS message	China Mobile Com. Corporation	pCR		Yes	Yes	revised	No	S3‑181005
		S3‑181005	resolving editor’s notes on protection the initial NAS message	China Mobile Com. Corporation	pCR	-	Yes	Yes	approved	No		S3‑180534
		S3‑180777	Adding the details to the protection of the initial message clause	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑180973	Alignment between partial cyphering and hashing method for initial NAS security	Qualcomm	pCR	Approval	No	Yes	approved	No
		S3‑180981	LS on initial NAS protection	Qualcomm	LS out	Approval	Yes	Yes	approved	No
4.1.5.3	NAS algorithm selection	S3‑180742	Negotiation of NR & LTE algorithms with 5GC	Ericsson	pCR	Approval	Yes	Yes It was agreed to add the abreviations of g-NodeB and NG-RAN and so on instead of the definitions (which are in the SA2 and RAN documents).	revised	No	S3‑180875
		S3‑180875	Negotiation of NR & LTE algorithms with 5GC	Ericsson	pCR	Approval	Yes	Yes Addressing comments from Qualcomm and Docomo.	approved	No		S3‑180742
4.1.5.4	NAS integrity and confidentiality mechanisms	S3‑180740	Content to Clause 6.4.3 on NAS integrity mechanisms	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180876
		S3‑180876	Content to Clause 6.4.3 on NAS integrity mechanisms	Ericsson,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑180740
		S3‑180623	Adding context on NAS integrity mechanisms and deleting Editor’s Note in clauses 6.4.3.1 and 6.4.3.3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180876
		S3‑180624	Adding context on NAS confidentiality mechanisms and deleting Editor’s Note in clause 6.4.4.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180877
		S3‑180877	Adding context on NAS confidentiality mechanisms and deleting Editor’s Note in clause 6.4.4.1	Huawei, Hisilicon,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180624
		S3‑180741	Content to Clause 6.4.4 on NAS Confidentiality mechanisms	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180877
4.1.5.5	NAS Security Mode Command	S3‑180535	resolving editor’s note on NAS SMC procedure failures	China Mobile Com. Corporation	pCR		Yes	Yes	approved	No
		S3‑180631	Clean up the EN in 6.7.2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑181006
		S3‑181006	Clean up the EN in 6.7.2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180631
		S3‑180552	Modification on NAS SMC procedure	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑180664	Resolving EN on security capability mismatch in 6.7.2	LG Electronics	pCR	Approval	Yes	Yes	revised	No	S3‑180878
		S3‑180878	Resolving EN on security capability mismatch in 6.7.2	LG Electronics	pCR	Approval	Yes	Yes	approved	No		S3‑180664
4.1.5.6	NAS security handling during state-transitions
4.1.5.7	Multi-NAS security	S3‑180630	Clean up the EN in 6.4.5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180879
		S3‑180879	Clean up the EN in 6.4.5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180630
		S3‑180649	Initial value of NAS count	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑180551	Enforce common NAS context for multiple registrations in same PLMN	ZTE Corporation	pCR	Approval	Yes	Yes Ericsson didn’t see it clear why the second Editor's note was removed. It was agreed to leave both editor's notes.	revised	No	S3‑180880
		S3‑180880	Enforce common NAS context for multiple registrations in same PLMN	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑180551
		S3‑180646	The value Unique NAS connection identifier	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180881
		S3‑180881	The value Unique NAS connection identifier	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180646
		S3‑180647	GUTIs are used to distinguish different security context from different PLMNs	Huawei, Hisilicon	pCR	Approval	Yes	Yes Ericsson: you can also use the PLMNid as well, better than the GUTI, that might change in the same PLMN several times. This is more an implementation issue. Nokia agreed with Ericsson.	noted	No
		S3‑180537	Discussion on authentication and NAS SMC with race condition	ZTE Corporation	discussion	Endorsement	Yes	Yes	noted	No
		S3‑180538	Rules on concurrent running of authentication and NAS SMC procedure	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑180737	Security contexts established independently by separate primary	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑180648	solve re-authentication problem in multi NAS connection	Huawei, Hisilicon	pCR	Approval	Yes	Yes Qualcomm, Nokia and Ericsson didn’t agree with the use of timers.	noted	No
		S3‑180653	Address concurrency issue in multi NAS connection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180882
		S3‑180882	Address concurrency issue in multi NAS connection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180653
		S3‑180745	Agreement for NAS security activation for multiple NAS connections	Ericsson	discussion	Endorsement	Yes	Yes Qualcomm: Not key change but security context change in the last bullet.	endorsed	No
		S3‑180738	Rules on Concurrent Running of Security Procedures	Ericsson	pCR	Approval	Yes	Yes Ericsson: we are not closing this discussion, just starting it to trigger the work; this is a huge table that needs further input from companies. The Chair commented for the minutes that more rules are expected on this topic.	approved	No
4.1.5.8	SMS over NAS	S3‑180743	Updates to SMS over NAS security clause	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180905
		S3‑180905	Updates to SMS over NAS security clause	Ericsson,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180743
		S3‑180805	Clean up of ENs in Clause 12 Security aspects of NAS over SMS	Nokia	pCR	Approval	Yes	Yes Huawei: this is a security procedure for a SA2 issue. Ericsson: there is a note on the SA2 spec that this is depending on a solution from CT1, and it’s likely that it will not incorporated in phase two.	merged	No	S3‑180905
4.1.5.9	Miscellaneous	S3‑180775	Justification on the need for security feature bidding down	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes BT and Docomo supported this contribution. Since there seemed to be a general support to this the document was endorsed.	endorsed	No
		S3‑180776	Adding a generic bid down solution to the 5G TS	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑180883	S3‑180243
		S3‑180883	Adding a generic bid down solution to the 5G TS	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑180776
		S3‑180612	Text for Clause 6.8.1.2.3 crypto separation for n3gpp	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180884
		S3‑180884	Text for Clause 6.8.1.2.3 crypto separation for n3gpp	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180612
		S3‑180613	Clean up of ENs in Clause 6.2.3 Handling of User related keys	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180862
		S3‑180862	Clean up of ENs in Clause 6.2.3 Handling of User related keys	Nokia,CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180613
4.1.5.10	Editorials
4.1.6	Security context
4.1.6.1	Multiple registrations	S3‑180597	Clarification on the scenario when UE has multiple registrations in different PLMNs	CATT	pCR	Approval	Yes	Yes	revised	No	S3‑180984
		S3‑180984	Clarification on the scenario when UE has multiple registrations in different PLMNs	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180597
		S3‑180598	Clarifications on the scenario when UE has multiple registrations in same PLMNs	CATT	pCR	Approval	Yes	Yes Ericsson: this is misplaced, it should go somewhere else. Huawei: temporary identifier, what does it mean? CATT: GUTI.	revised	No	S3‑180985
		S3‑180985	Clarifications on the scenario when UE has multiple registrations in same PLMNs	CATT	pCR	Approval	Yes	Yes Ericsson noted that this part needed some cleaning up. Nokia commented that this text would have to go somewhere else.	approved	No		S3‑180598
		S3‑180654	Delete EN in key handling of state transition	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
4.1.6.2	KDF agility
4.1.6.3	Intra-serving network handling
4.1.6.4	UE handling	S3‑180796	Deleting EN about RES* calculation in 5G AKA	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
4.1.6.5	Emergency call	S3‑180673	Resoving Editor’s Note on key generation for Unauthenticated IMS Emergency Sessions during handover	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No
4.1.6.6	Miscellaneous	S3‑180739	AS security establishment during transition from RM-DEREGISTERED to RM-REGISTERED	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180980
		S3‑180980	AS security establishment during transition from RM-DEREGISTERED to RM-REGISTERED	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180739
4.1.6.7	Editorials
4.1.7	Visibility and Configurability
4.1.7.1	Miscellaneous	S3‑180614	Resolving Editors notes 5.4.1 Security Visibility	BT plc	pCR	Agreement	Yes	Yes BT and ORANGE supported this, with modifications. KPN: not always we have a human with the UE.It depends on the application.	merged	No	S3‑180987
		S3‑180798	Resolution for ENs related to Security Visibility	Qualcomm Incorporated, Samsung	pCR	Approval	Yes	Yes	revised	No	S3‑180987
		S3‑180987	Resolution for ENs related to Security Visibility	Qualcomm Incorporated, Samsung,BT	pCR	Approval	Yes	Yes It was agreed that the content of this document needs to be revised and added to an informative annex.	approved	No		S3‑180798
		S3‑180671	Security visibility of N3IWF identity confirmation	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	noted	No
4.1.7.2	Editorials
4.1.8	Primary authentication
4.1.8.1	5G AKA over 3gpp/non3gpp access	S3‑180582	Remove the authentication function on SEAF in 5G-AKA	Huawei, Hisilicon	pCR	Approval	Yes	Yes KPN and Qualcomm disagreed with the changes. BT: it’s a bit late to introduce a big change in the security architecture.	noted	No
		S3‑180583	Remove the expiry timer in 5G-AKA	Huawei, Hisilicon	pCR	Approval	Yes	Yes Nokia: the timer was added to avoid the UDM being overloaded with multiple requests.	merged	No	S3‑180909
		S3‑180829	Pre-fetching AVs in 5G-AKA	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180909
		S3‑180909	Pre-fetching AVs in 5G-AKA	Ericsson,BT,Huawei,Lenovo,NTT-Docomo	pCR	Approval	Yes	Yes	approved	No		S3‑180829
		S3‑180619	Resolving Editors notes 6.1.3.2 - expiry time of an AV	BT plc	pCR	Agreement	Yes	Yes	merged	No	S3‑180909
		S3‑180736	5G-ACA when confirmation of RES* is not correct	Ericsson	pCR	Approval	Yes	Yes Similar to 584, they were merged.	revised	No	S3‑180910
		S3‑180910	5G-ACA when confirmation of RES* is not correct	Ericsson,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑180736
		S3‑180585	Clarification for SUPI delivery in 5G-AKA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180911
		S3‑180730	pCR to 33.501 – Timing of SUPI Reveal	Vodafone GmbH	pCR	Approval	Yes	Yes ORANGE preferred the Note here to the option in 585. It was also agreed to have normative text instead of the note. ORANGE: Do you need to know the SUPI when authenticating from LI perspective? Mark: no, we are fine with this document.	revised	No	S3‑180911
		S3‑180911	pCR to 33.501 – Timing of SUPI Reveal	Vodafone GmbH,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑180730
		S3‑180817	AUSF informing UDM that a successful or unsuccessful authentication of a subscriber has occurred	Ericsson	pCR	Approval	Yes	Yes ORANGE: why "The feature to link authentication confirmation to subsequent procedures is optional to support within the home network"? This was optional to use, not to support. Nokia: we don’t need this, it is up to the operator. It was agreed to remove it.	revised	No	S3‑180913
		S3‑180913	AUSF informing UDM that a successful or unsuccessful authentication of a subscriber has occurred	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180817
		S3‑180831	Further details on UE behaviour at 5G AKA procedure	Ericsson	pCR	Approval	Yes	Yes Nokia had doubts on the USIM being able to compute the keys in step 8. Vodafone clarified that this indeed happens, and also that the text was taken from LTE. Qualcomm: there is normative text in the note "The ME shall perform additional verifications as described in step 8 in Figure 6.1.3.2-1 in clause 6.1.3.2.".	revised	No	S3‑180914
		S3‑180914	Further details on UE behaviour at 5G AKA procedure	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180831
		S3‑180727	pCR to TS33.501 - Session binding to prevent potential 5G-AKA vulnerability	Vodafone GmbH	pCR	Approval	Yes	Yes NCSC: In Step 5 send more information. Nokia: This is presenting a solution against an attack scenario cited by an external paper by researchers. The scenario they cited is not new and it exists even in LTE. But in actual implementations this attack doesn’t happen because of the reliability mechanisms built in to the transport protocol. It may be a good idea to build the transaction identifier in to the authentication protocol, but the current proposal is not correct. When the source AUSF requests Authentication vectors from ARPF/UDM, it is requesting using the SUCI/SUPI it received from the UE. To bind the response it receives from the ARPF/UDM, the response message should contain the SUCI/SUPI from the Request message, not the actual /de-concealed SUPI by the UDM for which the AVs are generated. NEC: having the SUPI go back is a concern and may be subject to IMSI catchers. It was discussed how to handle comments from parties outside 3GPP (e.g. researchers). The Chair commented that 3GPP was setting up an official procedure to answer to these kind of comments.	noted	No
		S3‑180584	Resolve Editor's Note in clause 6.1.3.2 of TS 33.501	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180910
		S3‑180830	Definition on subscription credentials	IDEMIA	pCR	Decision	Yes	Yes ORANGE: the definition is wrong, it is not a subscriber credential.	revised	No	S3‑180870
		S3‑180870	Definition on subscription credentials	IDEMIA	pCR	Decision	Yes	Yes	approved	No		S3‑180830
		S3‑180691	USIM storage and usage for primary authentication	Orange	pCR	Approval	Yes	Yes The Chair proposed a show of hands: Who supports tdoc 691? Vodafone, BT, TIM, IDEMIA,ORANGE,DT, KPN. USIM in tamper resistant secure hardware? Qualcomm, Lenovo, Nokia, Samsung, China Mobile, Ericsson, Huawei, Intel, Sprint. Who objects to store the USIM in the UICC tdoc 691? Samsung, Qualcomm, Intel, Ericsson,Nokia, Huawei. Gemalto: what's the timeline for this? There may be things happening in ETSI SCP. ORANGE replied that SSP could be included later.	revised	No	S3‑181008
		S3‑181008	USIM storage and usage for primary authentication	Orange	pCR	Approval	Yes	Yes	approved	No		S3‑180691
		S3‑180832	Definition on tamper resistant secure hardware component	IDEMIA	pCR	Decision	Yes	Yes ORANGE: we prefer to have a requirement more than a definition. Vodafone: ETSI SSP has created an STF to develop specs for the SSP for June.There may be technical issues that would not be accepted, this is the risk. Vodafone is the STF leader and will make sure that this is aligned with SA3 work. KPN: the note doesn’t help, I prefer ORANGE's option. Qualcomm didn’t agree with having this proposal.Don't restrict this to the UICC. Samsung and Huawei supported this. BT: what happens if you have EAP TLS in primary authentication? ORANGE replied that EAP TLS is used in very specific scenarios and should go into an informative annex.We have to make sure that certificates are appropiately stored in the device. ORANGE: Any secure element that claims to be tamper resistance we will have an inter-operatibility issue and it will go into conflict with GSMA work in embedded UICCs. Vodafone: we support that the USIM shall reside in the UICC. It is mandatory in the industry as ORANGE has pointed out. Vodafone,ORANGE: a 5G spec not putting the USIM in the UICC would not be acceptable for us. BT agreed, but they liked the eUICC concept.	noted	No
		S3‑181009	LS on secure storage and processing of subscription credentials	ORANGE	LS out	Approval	Yes	Yes	approved	No
4.1.8.2	EAP AKA’ over 3gpp/non3gpp access	S3‑180733	Annex F: the subscriber identity used with key derivation in EAP-AKA’	Ericsson	pCR	Approval	Yes	Yes Qualcomm: Why not using USIP for the calculation in all cases? This was taken offline.	noted	No
		S3‑180915	Annex F: the subscriber identity used with key derivation in EAP-AKA’	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑180599	Modifications of N12 message context description	CATT	pCR	Approval	Yes	Yes Overlaps with 809.	merged	No	S3‑180916
4.1.8.3	Roaming/Multiple Authentication vectors
4.1.8.4	Authentication using EAP TLS	S3‑180512	Resolving Editor’s notes related with key derivation for EAP-TLS	Huawei, HiSilicon, Qualcomm Incorporated, Ericsson	pCR	Approval	Yes	Yes BT: where to keep a list of serving network names? ORANGE:A list maintaining a list of serving network names? IETF will not do that. This concept is not clear in the contribution. This had to be clarified offline.	revised	No	S3‑180919
		S3‑180919	Resolving Editor’s notes related with key derivation for EAP-TLS	Huawei, HiSilicon, Qualcomm Incorporated, Ericsson,CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180512
		S3‑180600	Resolving Editor’s notes in clause on EAP-TLS	CATT	pCR	Approval	Yes	Yes	merged	No	S3‑180919
		S3‑180515	Resolving Editor’s notes on Privacy Issues for EAP-TLS	Huawei, HiSilicon, Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑180921
		S3‑180921	Resolving Editor’s notes on Privacy Issues for EAP-TLS	Huawei, HiSilicon, Qualcomm Incorporated,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180515
		S3‑180734	Privacy with EAP-TLS	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180921
		S3‑180835	Alignement related to private networks	IDEMIA	pCR	Approval	Yes	Yes	revised	No	S3‑180922
		S3‑180922	Alignement related to private networks	IDEMIA	pCR	Approval	Yes	Yes	approved	No		S3‑180835
4.1.8.5	Enhancements to authentication (Diffie-Hellman proposals etc)
4.1.8.6	Authentication in Network sharing/limited deployment scenarios
4.1.8.7	Editorial corrections	S3‑180510	Clearfy the seaf and amf requirements	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑180621	Corrections on Initiation of authentication procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180924
		S3‑180924	Corrections on Initiation of authentication procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180621
		S3‑180622	Resolving Editor’s Note in clause 6.1.3.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes Ericsson: not the right reference. It's not currently in TS 24.502. This was taken offline.	noted	No
		S3‑180756	Usage and Identification of Key left at AUSF	NEC Europe Ltd	pCR	Approval	Yes	Yes Nokia: keep the editor's note on KAUSF, there are still open issues. Ericsson: we cannot agree with this document in the current form.	noted	No
		S3‑180759	Resolving EN on Clarification of how AUSF determines a clear text SUPI	NEC Europe Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑180925
		S3‑180925	Resolving EN on Clarification of how AUSF determines a clear text SUPI	NEC Europe Ltd,KPN	pCR	Approval	Yes	Yes	approved	No		S3‑180759
		S3‑180770	Clarification on AKA	Nokia	pCR	Decision	Yes	Yes	noted	No
		S3‑180806	SBA message names in N12 and N13	Ericsson, KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑180809	Authentication related services provided by AUSF	Ericsson	pCR	Approval	Yes	Yes There is an LS to CT4 and SA2 in 814 related to this document.	revised	No	S3‑180916
		S3‑180916	Authentication related services provided by AUSF	Ericsson,CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180809
		S3‑180813	Authentication related services provided by UDM	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180917
		S3‑180917	Authentication related services provided by UDM	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180813
		S3‑180815	Corrections to multiple authentication vector text references	SAMSUNG	pCR		Yes	Yes	approved	No
4.1.9	Secondary authentication
4.1.9.1	MitM
4.1.9.2	Incomplete procedure	S3‑180517	DN triggered Secondary re-authentication procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
4.1.9.3	Efficiency / security improvement	S3‑180516	ID linkage verification in secondary authentication-v2	Huawei, Hisilicon	pCR	Approval	Yes	Yes Ericsson: Where's the PUI defined? SA2 uses the term but it doesn’t seem to be defined. Ericsson: in step 13, is it describing behaviour externally to the network? We don’t do that. Step 13 was not agreed. The definition of PUI had to be checked offline.	revised	No	S3‑180908
		S3‑180908	ID linkage verification in secondary authentication-v2	Huawei, Hisilicon	pCR	Approval	No	Yes	noted	No		S3‑180516
4.1.9.4	Miscellaneous
4.1.9.5	Editorial and clarification
4.1.10	Interworking
4.1.10.1	Idle mode 4G-5G	S3‑180628	Discussion on protect the RR message during idle mobility from EPS to 5GS	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑180629	Clean up the EN in 8.2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180957
		S3‑180704	Agreement for EN on inclusion of TAU in idle mode mobility from EPS to 5GS	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑180705	Agreement for EN on protection of RR message using mapped security context in idle mode mobility from EPS to 5GS	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑180706	Agreement for EN on activation of mapped security context in idle mode mobility from EPS to 5GS	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑180707	pCR for idle mode mobility from EPS to 5GS	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180957
		S3‑180784	pCR to resolve ENs and update the registration procedure for mobility from EPS to 5GS	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑180957
		S3‑180957	pCR to resolve ENs and update the registration procedure for mobility from EPS to 5GS	Qualcomm Incorporated,Ericsson,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑180784
4.1.10.2	Idle mode 5G-4G	S3‑180635	Clean up the EN in 8.5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180958
		S3‑180700	Agreement for EN on TAU protection in idle mode mobility from 5GS to EPS	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑180701	Agreement for EN on KASME generation in idle mode mobility from 5GS to EPS	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑180702	Agreement for EN on the need for a NAS SMC in idle mode mobility from 5GS to EPS	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑180703	pCR for idle mode mobility from 5GS to EPS	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180958
		S3‑180958	pCR for idle mode mobility from 5GS to EPS	Ericsson,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑180703
		S3‑180787	pCR to resolve ENs and update the idle mode mobility procedure from 5GS to EPS over N26	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑180788	pCR to resolve ENs regarding the triggering of NAS SMC in mobility from 5GS to EPS over N26	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑180792	Setting EEA7 and EIA7 to enable AMF to force MME to run a NAS SMC	Qualcomm Incorporated	CR	Agreement	Yes	Yes	not pursued	No
4.1.10.3	Handover 5GC-EPS	S3‑180633	Clean up the EN in 8.3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180959
		S3‑180708	IW HO from 5G to 4G	Ericsson	pCR	Approval	Yes	Yes Huawei didn’t agree with the details, but Ericsson replied that this was coming from 33.401 and it wasn't the implementation of a new solution.	revised	No	S3‑180959
		S3‑180959	IW HO from 5G to 4G	Ericsson,Huawei,HiSilicon,Qualcomm	pCR	Approval	Yes	Yes	approved	No		S3‑180708
		S3‑180785	pCR to resolve ENs and update the handover procedure from 5GS to EPS over N26	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑180959
4.1.10.4	Handover EPS-5GC	S3‑180634	Clean up the EN in 8.4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180960
		S3‑180709	IW HO from 4G to 5G	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180960
		S3‑180786	pCR to resolve ENs and update the handover procedure from EPS to 5GS over N26	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑180960
		S3‑180960	pCR to resolve ENs and update the handover procedure from EPS to 5GS over N26	Qualcomm Incorporated,Huawei,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180786
4.1.10.5	Security context mapping	S3‑180636	Clean up the EN in 8.6	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180961
		S3‑180762	Resolution of editor’s notes in clause 8.6	NEC Europe Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑180961
		S3‑180961	Resolution of editor’s notes in clause 8.6	NEC Europe Ltd,Qualcomm,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑180762
		S3‑180789	pCR to resolve ENs and update the security context mapping in interworking	Qualcomm Incorporated	pCR	Approval	Yes	Yes Huawei: KSEAF doesn't have any value in this case. Ericsson agreed. The involvement of the SEAF is not required in the interworking. Docomo: Generate a new KSEAF will not lead to a security issue. If the AMF is not trustworthy it can use the redirection to generate the new KSEAF.	merged	No	S3‑180961
4.1.10.6	Miscellaneous
4.1.10.7	Editorials
4.1.11	non-3GPP access
4.1.11.1	Miscellaneous	S3‑180611	Clean up of ENs in Clause 7.2.1 Authentication for Untrusted non-3GPP Access	Nokia, Motorola Mobility, Lenovo	pCR	Approval	Yes	Yes	revised	No	S3‑180940
		S3‑180940	Clean up of ENs in Clause 7.2.1 Authentication for Untrusted non-3GPP Access	Nokia, Motorola Mobility, Lenovo	pCR	Approval	Yes	Yes	approved	No		S3‑180611
		S3‑180669	Resolving Editor’s Note on N3IWF authentication	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	revised	No	S3‑180941
		S3‑180941	Resolving Editor’s Note on N3IWF authentication	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑180669
		S3‑180699	New key for IPSec in non-3GPP access	Ericsson	pCR	Approval	Yes	Yes	noted	No
4.1.11.2	Editorials
4.1.12	NDS
4.1.12.1	Miscellaneous	S3‑180615	Resolving Editors notes 5.2.9 – Detailed Security Requirements for F1 interface	BT plc	pCR	Agreement	Yes	Yes Telecom Italia: it's supposed to remove an editor's note what it stays. The new text is confusing.	revised	No	S3‑180949
		S3‑180949	Resolving Editors notes 5.2.9 – Detailed Security Requirements for F1 interface	BT plc	pCR	Agreement	Yes	Yes The new text goes away and the editor's note is removed.	approved	No		S3‑180615
		S3‑180618	Resolving Editors notes 9.1.2.2 - DIAMETER or GTP - Network layer IPsec support mandatory or optional	BT plc	pCR	Agreement	Yes	Yes	revised	No	S3‑180950
		S3‑180950	Resolving Editors notes 9.1.2.2 - DIAMETER or GTP - Network layer IPsec support mandatory or optional	BT plc	pCR	Agreement	Yes	Yes	approved	No		S3‑180618
4.1.12.2	Editorials	S3‑180620	Resolving Editor’s Note in clause 5.2.4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑180951
		S3‑180951	Resolving Editor’s Note in clause 5.2.4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑180620
4.1.13	Service based architecture
4.1.13.1	Interconnect (SEPP related)	S3‑180675	Adding normative text on SEPP to the security architecture section	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180891
		S3‑180891	Adding normative text on SEPP to the security architecture section	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180675
		S3‑180677	Discussion on re-prioritizing SBA security work for Phase 1	Nokia	discussion	Decision	Yes	Yes DT wanted to avoid TLS and go for a viable solution in Rel-16. They didn’t want to enforce a solution that added very little advantages. Docomo: Application layer between the SEPPs supported on TLS can work in this case. TLS is not the only solution, we need something on top of that. BT supported this. Vodafone: for me this solution is a backup, while we work on the other solutions. This is better than having no security solution at all.	noted	No
		S3‑180889	Discussion on re-prioritizing SBA security work for Phase 1	Nokia	discussion	Decision	No	Yes	withdrawn	Yes
		S3‑180710	Stepwise way forward for SBA security: SEPP- SEPP security capability negotiation	Ericsson	pCR	Approval	Yes	Yes Telecom Italia: does this work if only TLS is used in Rel-15? Ericsson: yes. Nokia didn’t agree with steps 0 and 4 in figure 9.1.3.X. Just a secure connection established should be displayed. BT didn’t agree with this. ORANGE preferred to move this to the living document.	revised	No	S3‑180893
		S3‑180893	Stepwise way forward for SBA security: SEPP- SEPP security capability negotiation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180710
		S3‑180711	Policies for IE protection at SEPP	Ericsson	pCR	Approval	Yes	Yes Deutsche Telekom supported this. Nokia commented that this was a lot of work and it was better to put it into the living document for further study. There were different options to choose from. Ericsson preferred to have it in the TS already since they thought that after its approval it would be more difficult to add more content. MCC commented that it was possible to add this later since the TS was to be approved when it’s completed in its 80%. SBA would have to be added as outstanding work left in the TS cover. BT preferred to see the whole thing going into the TS. For example CT4 would likely prefer to have this content in Rel-15. Telecom Italia asked about the living document. The Chair commented that the living document served as a study given that the SBA task came really late to SA3. It was decided to split it into a living document and to the TS.	noted	No
		S3‑180896	Policies for IE protection at SEPP	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑180712	TLS for SEPP-IPX communication	Ericsson	pCR	Approval	Yes	Yes DT: the use should be optional, not mandatory. Telecom Italia: in the conference call we had agreed on a different solution from TLS. Why did we do the conference call? Vodafone: we have talked with IPX providers, they are OK with having direct TLS and not hop-by-hop. DT: it's really hard to enforce having end-to-end TLS when transitioning to Rel-16. The Chair commented that CT needed a SA3 solution for May, and an exception should be avoided at all costs. It was argued whether gor for "shall be used" or "shall be supported". The second option was chosen. Note from MCC: "Technical standards specify functionality which shall be implemented. They do not specify whether users use that functionality or not".	revised	No	S3‑180890
		S3‑180890	TLS for SEPP-IPX communication	Ericsson	pCR	Approval	Yes	Yes MCC warned that NOTE 1 was wrong since it contained normative language. Besides, recommending to "use" a particular functionality is language reserved to regulators. The document was approved but MCC commented that they would discuss this internally and may come back with a comment in plenary prior to the approval of the specification.	approved	No		S3‑180712
		S3‑180713	Root key distribution and PKI for SEPP out of scope	Ericsson	other	Approval	Yes	Yes	approved	No
		S3‑180836	Requirements for secure API design for SBA	Deutsche Telekom AG	pCR	Approval	Yes	Yes	noted	No
		S3‑180895	Requirements for secure API design for SBA	Deutsche Telekom AG	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑180841	Commenting contribution on S3-180836 - Requirements for secure API design for SBA	Nokia	discussion	Approval	Yes	Yes	noted	No
		S3‑180846	comments Requirements for secure API design for SBA (making text more normative)	NTT DOCOMO	pCR	Approval	Yes	Yes	noted	No
		S3‑180729	Presentation of Solution that is compatible with end-to-end security between SEPPs and mediation services	KPN N.V.	discussion	Discussion	Yes	Yes	noted	No
		S3‑180731	pCR to living document on SBA (S3-180352)	KPN N.V.	other	Approval	Yes	Yes	approved	No
		S3‑180732	pCR based on S3-180729 (E2E between SEPPs with mediation services)	KPN N.V.	pCR	Approval	Yes	Yes	noted	No
		S3‑180897	Policies for IE protection at SEPP(content for living document)	Ericsson	other	Approval	No	Yes	approved	No
4.1.13.2	Protection of Attributes	S3‑180676	Introduction to Application layer security in SEPP	Nokia	pCR	Approval	Yes	Yes Ericsson: no need to have the overview text. Have the titles as an editor's note as to-do list in the TS. The Chair proposed to have it in the living document so as not to add another editor's note on the TS.	revised	No	S3‑180892
		S3‑180892	Introduction to Application layer security in SEPP	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180676
		S3‑180845	Integrity protection for SBA over N32	NTT DOCOMO INC.	discussion	Presentation	Yes	Yes	revised	No	S3‑180898
		S3‑180898	Integrity protection for SBA over N32	NTT DOCOMO INC.	other	Approval	No	Yes This will go to the living document.	approved	No		S3‑180845
4.1.13.3	Transport security (intra and inter-PLMN)	S3‑180617	Resolving Editors notes - 9.1.3.2 Protection at the network or transport layer – TLS certificate profiles	BT plc	pCR	Approval	Yes	Yes	revised	No	S3‑180899
		S3‑180899	Resolving Editors notes - 9.1.3.2 Protection at the network or transport layer – TLS certificate profiles	BT plc	pCR	Approval	Yes	Yes	approved	No		S3‑180617
		S3‑180529	Discussion and pCR to resolving TLS 1.3 Editor’s Notes in section 9.1.3.1	China Mobile Com. Corporation	pCR		Yes	Yes	approved	No
4.1.13.4	NF-NRF Authentication & Authorization	S3‑180714	SBA Authorization Framework	Ericsson	pCR	Approval	Yes	Yes DT: no time to define a new functionality for SAF. ORANGE: colocate this functionality in the NRF. ORANGE: do we need all these functionalities if we are in the same network domain? The functionality should be supported, optional to use.	merged	No	S3‑180885
		S3‑180678	Discussion paper on OAuth based service authorization framework for SBA	Nokia	discussion	Approval	Yes	Yes	noted	No
		S3‑180680	OAuth based service authorization framework for SBA	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180885
		S3‑180885	OAuth based service authorization framework for SBA	Nokia,Huawei,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180680
		S3‑180513	Authorization of NF service Access in the same PLMN	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180885
		S3‑180715	Discussion and pCR for inter-PLMN token-based authorization.	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑180886
		S3‑180681	OAuth based service authorization framework for SBA in roaming scenarios	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180886
		S3‑180886	OAuth based service authorization framework for SBA in roaming scenarios	Nokia,Huawei,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180681
		S3‑180521	Authorization of NF service Access across PLMNs	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180886
		S3‑180514	Resolving editors notes about authentication in service authorization	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No
		S3‑180520	Resolving editors note in Authorization of NF service access	Huawei, Hisilicon	pCR	Approval	Yes	Yes DT didn’t agree with this document. It was agreed to merge it with 885.	merged	No	S3‑180885
		S3‑180508	9.1.3.4.2 clarification PCR	InterDigital, Inc.	pCR	Approval	Yes	Yes	revised	No	S3‑180900
		S3‑180900	9.1.3.4.2 clarification PCR	InterDigital, Inc.	pCR	Approval	Yes	Yes	approved	No		S3‑180508
		S3‑180530	pCR to resolving authentication Editor’s Notes in section 9.1.3.4	China Mobile Com. Corporation	pCR		Yes	Yes	revised	No	S3‑180901
		S3‑180901	pCR to resolving authentication Editor’s Notes in section 9.1.3.4	China Mobile Com. Corporation	pCR	-	Yes	Yes	approved	No		S3‑180530
4.1.13.5	NF-NF Authentication & Authorization	S3‑180682	Discussion paper on Service access authorization for 5G SBA	Nokia	discussion	Endorsement	Yes	Yes	revised	No	S3‑180887
		S3‑180887	Discussion paper on Service access authorization for 5G SBA	Nokia	discussion	Endorsement	Yes	Yes It will go into the living document in 528.	endorsed	No		S3‑180682
		S3‑180683	Service access authorization based on static configuration	Nokia	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑180526	Resolution of Editor's Notes in clause 5.7	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑180527	Resolution of Editor’s Notes in 5.10	KPN	pCR	Approval	Yes	Yes	approved	No
4.1.13.6	Miscellaneous	S3‑180834	General guidelines for secure protocol design	Deutsche Telekom AG	pCR	Approval	Yes	Yes ORANGE: these are not guidelines, they are requirements. Ericsson: why have them in the TS when we can just send it to them in a LS? Or at least have it in an informative annex. Nokia and ORANGE preferred to have this out of the TS. KPN agreed that telling other 3GPP groups what to do was not appropriate for the specification. NOTE from MCC: agree with this. Docomo: LS send an LS. A 800 series TR could also serve as repository of this kind of text, or ask CT if they have a TR where they can store these guidelines.	noted	No
		S3‑180842	Commenting contribution on S3-180834 - General guidelines for secure protocol design	Nokia	discussion	Discussion	Yes	Yes	noted	No
		S3‑180674	SBA: Removing section on Diameter and GTP	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180902
		S3‑180902	SBA: Removing section on Diameter and GTP	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180674
		S3‑180528	Living Document: Security of Service Based Architecture of 5G phase 1	China Mobile Com. Corporation	other		Yes	Yes	revised	No	S3‑180888
		S3‑180888	Living Document: Security of Service Based Architecture of 5G phase 1	China Mobile Com. Corporation	other	-	Yes	Yes	approved	No		S3‑180528
		S3‑180692	Agenda and notes of SA3 conference call on SBA/N32 security	Deutsche Telekom AG	other	Information	Yes	Yes	noted	No
		S3‑180696	Agenda and notes of joint conference call on SBA/N32 security	Deutsche Telekom AG	other	Information	Yes	Yes	noted	No
		S3‑180894	LS on guidelines for secure protocol design	Deutsche Telekom	LS out	Approval	Yes	Yes	approved	No
		S3‑180903	LS Reply on SBI Design and its Security Implications	C4-182244	LS in	discussion	Yes	Yes	postponed	No
		S3‑180923	General guidelines for secure protocol design (contribution to the living document)	Deutsche Telekom	other	Approval	Yes	Yes	approved	No
		S3‑180962	API-related requirements for the SEPP	Deutsche Telekom	other	Approval	Yes	Yes	approved	No
4.1.13.7	Editorials	S3‑180532	pCR to resolving Editor’s Notes in section 9.1.1	China Mobile Com. Corporation	pCR		Yes	Yes	approved	No
		S3‑180721	Requirements for the protection of attributes on N32	Deutsche Telekom AG	pCR	Approval	Yes	Yes	revised	No	S3‑180904
		S3‑180904	Requirements for the protection of attributes on N32	Deutsche Telekom AG	pCR	Approval	Yes	Yes	approved	No		S3‑180721
		S3‑180531	pCR to resolving Editor’s Notes in section 9.1.1	China Mobile Com. Corporation	pCR		No	Yes	withdrawn	Yes
4.1.14	Privacy
4.1.14.1	SUPI and LI	S3‑180684	Proposal and Discussion for Privacy and LI solution	KPN, DT, BT, NTT DOCOMO, NEC	discussion	Approval	Yes	Yes Huawei, Samsung: binding the SUPI is overloading the functionality with another layer of variables. Ericsson: solution must contain hash+SUPI as endorsed in a previous meeting, and this doesn’t appear in the proposed solution. Huawei: Hash of the SUPI fails when compared with the hash of the SUPI of the network the connection is terminated. KPN: go forward to the other two solutions without binding the SUPI. This solution was named key binding.	noted	No
		S3‑180965	PCR Proposal and Discussion for Privacy and LI solution	KPN	pCR	Approval	Yes	Yes On the technical vote: Nokia commented that key binding solution seemed to be the most supported solution, so they decided not to go for a vote. Nokia: By choosing this solution and not going for a vote we are going against an agreement from the last meeting. They wanted to see how many companies wanted to support the combined solution. Nokia requested to have minuted the following: With this result, Nokia is not insisting on the combined solution though the objections raised by several companies as minuted under the discussion in S3-180769 against key binding solution are still seen as valid and have not been answered. Nokia: Some companies support key binding alone, some supported combined solution, we want to see how many. Tdoc 965 key binding solution show of hands; support:ing companies: - Huawei, ORANGE,Docomo, T-Mobile,TIM,DT, NEC, Samsung, China Mobile, Qualcomm, Ericsson, CATT, LG, Intel, KPN, Home Office, NCSC, NTEC, NIST,BT, Airbus,Sprint, ZTE. Tdoc 963 combined solution support: - Nokia, Interdigital, Lenovo, IDEMIA, Gemalto, AT&T. No voting was needed so the group moved forward with this document.	approved	No
		S3‑180768	Discussion on LI conformity by verification hash with ppt attachment	Nokia	discussion	Discussion	Yes	Yes Huawei: this is error prone if the serving network doesn't use the SUPI from the HPLMN to create a hash. Interdigital supported this option. ORANGE: French authorities want to avoid things becoming easier in privacy. 5G should be as difficult as 4G to change the USIM.	noted	No
		S3‑180769	5G AKA with verification hash	Nokia, Gemalto, IDEMIA	pCR	Decision	Yes	Yes Nokia commented that they had a merger of verification hash and key binding solutions. Some companies were uncomfortable with new solutions presented for this meeting: Qualcomm and Huawei. Qualcomm: if the hash function falls down it weakens the whole thing. We cannot accept any solution that includes hash verification. Huawei supported this. BT commented that merging existing solutions should not be a problem since it was common practice. ORANGE agreed. The Chair commented that there had to be consensus for the merging and it was a normal procedure in 3GPP. Companies were allowed to object a merging of existing solutions, since this meant that the consensus was not reached. The Chair asked for a show of hands: -Tdoc 684 Key binding: Verizon, Docomo, BT, TIM, DT, Juniper, NEC, China Mobile, NCSC, Home Office, NTAC, NIST,KPN. - Tdoc 769 Verification has solution: Gemalto, Interidigital, Lenovo, Nokia, IDEMIA. - Tdoc 963 combined solution: Interdigital, Juniper, T-mobile, Docomo, DT, China Mobile,Lenovo, Nokia, NEC, IDEMIA, Gemalto, Vodafone, KPN, NIST. - Tdoc 818 NAS SMC: Samsung, Ericsson, Qualcomm, Huawei, CATT, Intel, ZTE. Docomo recommended to merge some of these building blocks with consensus. It was pointed out that both tdocs 769 and 818 didn’t have any operator support. ORANGE: TS 33.501 will not be ready for approval if a solution is not decided here. Additional show of hands for who was objecting to the documents: -Tdoc 684: Nokia, Interdigital, Huawei, Ericsson,CATT. -Tdoc 769: Qualcomm, Ericsson, Huawei, Intel, ZTE, CATT, TIM. -Tdoc 963: Qualcomm, Ericsson, Huawei, ZTE, Intel, CATT. -Tdoc 818 NAS SMC: Interdigital, Lenovo, Nokia, T-Mobile. After offline discussions Qualcomm asked the companies supporting the NAS SMC solution if the key binding solution was acceptable for them in order to go forward. Nokia emphasized to hold their objection against the stand-alone solution "SUPI key binding" because of the issues raised by several companies as summarized here: Samsung – no dedicated error scenario Huawei – binding is overloading the functionality Ericsson – agreement from last meeting - solution shall be based on hash – key binding is not a hash Docomo – should be a cryptographic failure, binding does allow failure in normal operation Nokia – fraud scenario is not addressed, but operator wants to know, why failure happens Nokia – full AKA run before failure is discovered	noted	No
		S3‑180966	5G AKA with verification hash	Nokia, Gemalto, IDEMIA	pCR	Decision	No	Yes	withdrawn	Yes
		S3‑180818	Clause 6.7.2 (NAS SMC, SUPI from UE for LI)	Ericsson, Qualcomm Incorporated, Samsung, Huawei, Hisilicon, Intel	pCR	Approval	Yes	Yes ORANGE: If the AMF needs to validate the SUPI.. This has to be always done. Ericsson: comditional because the AMF may know the UE already, so the SUPI verification was done. Vodafone: serving networks giving auth vectors to third parties is an issue. There is no verification of these auth vectors were in the network were these vectors were created. Verizon: serving network should only receive a hash,not the SUPI.We agreed this in the last meeting. Interdigital: Reject should be done at earlier stages, before authentication.	noted	No
		S3‑180591	Solution for SUPI privacy and LI requirement	CATT	pCR	Approval	Yes	Yes Qualcomm: you are including both SUCI and SUPI in your solution, this is the only difference with our solution.	noted	No
		S3‑180590	Requirement for SUPI privacy and LI	CATT	pCR	Approval	Yes	Yes Verizon: not acceptable. BT: it introduces VPLMN control, which is not what we want.	noted	No
		S3‑180542	Discussion on visited network control of using null-scheme	ZTE Corporation	discussion	Endorsement	Yes	Yes	noted	No
		S3‑180543	Visited network control of null-scheme	ZTE Corporation	pCR	Approval	Yes	Yes Qualcomm: we discussed this during the last meeting and agreed to take it in phase two. ORANGE: we don't need the visited network to force the new scheme. This was noted since there was no support for this.	noted	No
		S3‑180963	Combined solution: Verification hash and SUPI key binding	Nokia, Gemalto, IDEMIA, Interdigital, AT&T, Lenovo	discussion	discussion	No	Yes See discussion to the different solutions under S3-180769 Nokia stated: It looks like the key binding only has the most support by companies after NAS SMC solution promoters moved to support the key binding solution as stand-alone final LI/Privacy solution. If this assumption is this still correct and NAS SMC solution is not on the table anymore, I think we do not need a voting. Nokia requested to minute the following: By choosing the key binding solution we are deciding against an agreement that SA3 made in the last meeting and therefore would still like to see, how many companies would support a combined solution, because merged solution (963) was having in the first round of show of hands the most supporters. Another show of hands was done: Key binding – 965: 23 companies; Merger – 963: 6 companies With this result, Nokia asked to be minuted: We are not insisting on the combined solution though the objections raised by several companies as minuted under the discussion in S3-180769 against key binding solution are still seen as valid and have not been answered. No voting was needed. Group moved forward with S3-180965.	noted	No
		S3‑180983	LS on LI SUPI privacy	BT	LS out	Approval	Yes	Yes	approved	No
4.1.14.2	SUCI and Schemes	S3‑180716	Annex C (SUCI – ECIES profiles)	Ericsson, Vodafone	pCR	Approval	Yes	Yes NIST suggested to change some profiles to make them mandatory. Vodafone: we don’t believe that a single curve is trusted all around the World. We prefer having five curves. Huawei: Two curves here are not widely implemented, so we have concerns about this. The curve in Qualcomm's proposal is fine with us.We don’t have a strong opinion on the number of curves. The Chair commented that there was general support for having two curves. Qualcomm asked whether it was better to restrict to two curves in Rel-15, and go for the rest in later releases. Curve A and C were the preferred ones by NIST, NCSC and Vodafone.	revised	No	S3‑180964
		S3‑180964	Annex C (SUCI – ECIES profiles)	Ericsson, Vodafone,Qualcomm	pCR	Approval	No	Yes It was agreed to use the two curves A and C. Negotiation will be included.	approved	No		S3‑180716
		S3‑180793	Support of privacy schemes and profiles by the UE	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑180964	S3‑180258
		S3‑180524	Resolving Editors' notes in clause 5.1.5	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑180757	Resolving an EN on randomness of SUCI in Clause 6.12.2	NEC Europe Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑180967
		S3‑180967	Resolving an EN on randomness of SUCI in Clause 6.12.2	NEC Europe Ltd	pCR	Approval	Yes	Yes	approved	No		S3‑180757
		S3‑180821	Clause 6.12.2 (SUCI – behaviours when USIM calculates SUCI)	Ericsson, Gemalto, IDEMIA	pCR	Approval	Yes	Yes Huawei: the deletion of the parameters by the ME is implementation specific, no need to mandate this. Gemalto: you could be changing the UICC from the ME and this could not detect the change. We have a contribution to avoid this happening. Huawei: any update in the USIM would not be seen by the ME. Huawei: this update is rare, so not relevant.	revised	No	S3‑180968
		S3‑180968	Clause 6.12.2 (SUCI – behaviours when USIM calculates SUCI)	Ericsson, Gemalto, IDEMIA,CATT	pCR	Approval	Yes	Yes	revised	No	S3‑181011	S3‑180821
		S3‑181011	Clause 6.12.2 (SUCI – behaviours when USIM calculates SUCI)	Ericsson, Gemalto, IDEMIA,CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180968
		S3‑180574	SUCI calculation in the ME	Gemalto, IDEMIA, Ericsson	pCR	Approval	Yes	Yes Gemalto commented that this was a subset of the CATT proposal.	merged	No	S3‑180968
		S3‑180594	SUCI structure and SUCI generation conditions	CATT	pCR	Approval	Yes	Yes Interdigital: Easier for the attacker to grab the SUCI. Ericsson proposed to remove the extended Home Network Identifier. ORANGE asked whether there was a definition for the Home Network Identifier. This wasn't clear.	merged	No	S3‑180968
		S3‑180820	Annex C (SUCI – scheme properties)	Ericsson	pCR	Approval	Yes	Yes Huawei: why maximum size? This is implementation specific. Ericsson: there should be a limit for the max size of the SUCI. Nokia preferred to have one size for the SUCI instead of this maximum. A scheme identifier only would be preferable. The maximum size was removed. Interdigital warned that the scheme identifier may be used to track the SUCI.BT supported this and a note was added for this issue.	revised	No	S3‑180969
		S3‑180969	Annex C (SUCI – scheme properties)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑180820
		S3‑180595	AMF de-conceal null-scheme SUCI	CATT	pCR	Approval	Yes	Yes Docomo: the first requirement is obvious that can be done so we don’t need it as a requirement. The requirement was removed since there was no support for this as for the rest of the document.	noted	No
		S3‑180693	Resolution of EN in 6.1.2 - recognizing null-SUCI	KPN N.V.	pCR	Approval	Yes	Yes	merged	No	S3‑180925
		S3‑180549	Modification on UE privacy requirement	ZTE Corporation	pCR	Approval	Yes	Yes Apple didn’t agree with ME supporting the null-scheme, as they describe in 580.	noted	No
		S3‑180580	Privacy Preservation of SUPI	Apple (UK) Limited	pCR	Approval	Yes	Yes Vodafone: we will not provision public keys in every handset. BT (Alex): HPLMN's choice to support this, it cannot be mandatory. Ericsson: this is questioning the decision we made about legacy USIMs after long discussions. We already have content in the TS assuming what kind of USIMs we use. I propose to note this. There wasn't support for this document, so it was noted.	noted	No
		S3‑180592	Privacy requirements updated for clarification	CATT	pCR	Approval	Yes	Yes	revised	No	S3‑180970
		S3‑180970	Privacy requirements updated for clarification	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180592
		S3‑180593	UE privacy protection scheme requirements	CATT	pCR	Approval	Yes	Yes	revised	No	S3‑180971
		S3‑180971	UE privacy protection scheme requirements	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180593
		S3‑180533	Discussion and pCR for privacy calculation in UE side	China Mobile Com. Corporation	pCR		Yes	Yes TIM: what’s the 5G USIM in the figure? There was no support for this, hence it was noted.	noted	No
		S3‑180505	Discussion Paper on the need and ways to make SUPI protection opaque to IMSI sniffers	InterDigital, Inc.	discussion	Discussion	Yes	Yes NCSC: This is not protecting against IMSI grabbers at all. This only works for passive sniffing. Ericsson: this use case is very rare. Besides, SA3 should not get involved with cryptographic schemes, this is SAGE work. Nokia supported to have a look at this use case. T-Mobile found it useful too. BT(Alex) commented that this would need an IMSI redesigning. Deutsche-Telekom, Docomo proposed an encoding solution. This would be for the next meeting. ORANGE didn’t think it was a problem. Some other companies that this use case was worth considering (e.g. Samsung, Nokia, KPN,T-Mobile). The Chair commented that the problem was understood but companies wanted to have a solution going another way. Contributions are welcome for the next meeting.	noted	No
		S3‑180502	6.12.2 PCR for making SUPI protection opaque to IMSI sniffers	InterDigital, Inc.	pCR	Approval	Yes	Yes	noted	No
		S3‑180503	C3.2 PCR for making SUPI protection opaque to IMSI sniffers	InterDigital, Inc.	pCR	Approval	Yes	Yes	noted	No
		S3‑180504	C3.3 PCR for making SUPI protection opaque to IMSI sniffers	InterDigital, Inc.	pCR	Approval	Yes	Yes	noted	No
		S3‑180506	PCR for making SUPI protection opaque to IMSI sniffers	InterDigital, Inc.	pCR	Approval	Yes	Yes	noted	No
		S3‑180666	Discussion on SUCI construction scheme	LG Electronics	discussion	Discussion	Yes	Yes	noted	No
		S3‑180667	Parameter for SUPI encryption	LG Electronics	pCR	Approval	Yes	Yes Vodafone: SAGE's position is that they don’t need to be involved. Ericsson: not necessary now.	noted	No
		S3‑180668	Draft LS on subscription identifier encryption	LG Electronics	LS out	Approval	Yes	Yes	noted	No
4.1.14.3	SIDF	S3‑180723	Requirement on routing SUCI	CATT	pCR	Approval	Yes	Yes TIM: what’s the value of this new text? ORANGE, Vodafone agreed.	noted	No
		S3‑180766	UDM - SIDF discussion	Nokia	pCR	Discussion	Yes	Yes	noted	No
		S3‑180767	UDM - SIDF discussion implemented in pCR	Nokia	pCR	Decision	Yes	Yes ORANGE: the first part mixes implementation, use case, business parts. They didn’t support this contribution.	noted	No
		S3‑180758	Resolving EN on UDM Instance selection	NEC, CMCC	pCR	Approval	Yes	Yes	noted	No
		S3‑180761	discussion paper on embedded routing information in SUCI	Vodafone GmbH	discussion	Agreement	Yes	Yes	noted	No
		S3‑180763	pCR to 33.501 - addition of routing information into SUCI	Vodafone GmbH	pCR	Agreement	Yes	Yes LG,Gemalto, BT,IDEMIA supported this contribution.	noted	No
		S3‑180824	Clause 6.12.5 (NF discovery with SUCI)	Ericsson	pCR	Approval	Yes	Yes Ericsson: the motivation behind the contribution is that this is privacy sensitive info that is better not to standardise. KPN and CATT preferred this solution. Nokia supported this but wondered why the SUPI needed to be sent. Ericsson pointed out that the difference between the Vodafone and Ericsson's proposal is "Do we standardise the location of the routing information that is sent OTA?". Vodafone rephrased to "are you fine with the routing information being sent OTA?". It was decided to note all documents and take this offline.A conference call was recommended to come back with a combined solution during the next meeting.	noted	No
		S3‑180822	Clause 6.12.5 (SIDF – size of SUCI)	Ericsson	pCR	Approval	Yes	Yes ORANGE: this will not work, eventually it is implementation specific and we cannot impose requirements on propietary solutions. Gemalto wasn't happy with the contribution. Nokia either.	noted	No
		S3‑180823	Clause 6.12.5 (SIDF – validating calculation of the SUCI)	Ericsson, Gemalto	pCR	Approval	Yes	Yes Nokia: enough to verify the Home network identifier. Why the protection scheme? ORANGE didn’t support this contribution either.	noted	No
		S3‑180548	Modification on SIDF privacy requirement	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑180725	Refine requirements of SIDF	CATT	pCR	Approval	Yes	Yes ORANGE: there is no visited network's UDM. It doesn’t exist.	noted	No
		S3‑180755	Requirement on SIDF	NEC, Nokia, CMCC	pCR	Approval	Yes	Yes	revised	No	S3‑180974
		S3‑180974	Requirement on SIDF	NEC, Nokia, CMCC	pCR	Approval	Yes	Yes	approved	No		S3‑180755
		S3‑180765	Revision of S3-180077 UDM requirements - key management and privacy - NEC-Nokia merger	Nokia, NEC	pCR	Decision	Yes	Yes ORANGE: this is implementation specific. Ericsson and Gemalto agreed, there were many implementation details.	noted	No
		S3‑180837	SIDF description	CATT	pCR	Approval	Yes	Yes	noted	No
4.1.14.4	Miscellaneous	S3‑180627	Subscription identification procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑180975
		S3‑180826	Clause 6.12.4 (subscription identification procedure)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑180975
		S3‑180975	Clause 6.12.4 (subscription identification procedure)	Ericsson,Huawei,KPN	pCR	Approval	Yes	Yes	approved	No		S3‑180826
		S3‑180679	Adding Emergency Services paragraph for Subscription Identification procedure	KPN N.V.	pCR	Approval	Yes	Yes	merged	No	S3‑180975
		S3‑180816	Resolving Editors' Notes in clause 6.12	KPN N.V.	pCR	Approval	Yes	Yes	noted	No
		S3‑180579	Generation and rotation of subscription temporary identifier	Apple (UK) Limited	pCR	Approval	Yes	Yes ORANGE: this may lead to DoS attacks. Vodafone agreed: the handset is not the right place where to make the decision whether it needs to be updated.	noted	No
		S3‑180779	Protecting IMEI in NAS Security Mode Command	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑180838	Introduction of the Subscription Concealed Identifier to EPC	Apple (UK) Limited	CR	Discussion	Yes	Yes Mark: This doesn’t support LI requirements. ORANGE: this has a big impact on the network, too many changes to be done.	not pursued	No
4.1.14.5	Editorials	S3‑180544	Editorial modification on AMF privacy requirement	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑180976
		S3‑180976	Editorial modification on AMF privacy requirement	ZTE Corporation	pCR	Approval	Yes	Yes It was noted that the requirement was changed in another approved contribution.	approved	No		S3‑180544
		S3‑180547	Editorial modification on SEAF privacy requirement	ZTE Corporation	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑180602	Resolving Editor’s note in clause on Subscription temporary identifier	CATT	pCR	Approval	Yes	Yes	approved	No
		S3‑180695	USIM terminology fix	Orange	pCR	Approval	Yes	Yes	revised	No	S3‑180977
		S3‑180977	USIM terminology fix	Orange	pCR	Approval	Yes	Yes	approved	No		S3‑180695
		S3‑180656	Moving UE handling SUCI to SUCI clause	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	merged	No	S3‑180978
		S3‑180764	Revision of S3-180078 SUCI intro and handling - NEC-KPN-Nokia merger	Nokia, KPN, NEC	pCR	Decision	Yes	Yes	revised	No	S3‑180978
		S3‑180978	Revision of S3-180078 SUCI intro and handling - NEC-KPN-Nokia merger	Nokia, KPN, NEC,Ericsson,Huawei,China Mobile	pCR	Decision	Yes	Yes	revised	No	S3‑181010	S3‑180764
		S3‑181010	Revision of S3-180078 SUCI intro and handling - NEC-KPN-Nokia merger	Nokia, KPN, NEC,Ericsson,Huawei,China Mobile	pCR	Decision	Yes	Yes	approved	No		S3‑180978
		S3‑180827	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	merged	No	S3‑180978
4.1.15	Incoming and outgoing LSes	S3‑180555	Reply LS on security aspects of supporting LTE connected to 5GC	C1-180485	LS in		Yes	Yes	noted	No
		S3‑180556	LS on selectively disabling legacy radio access	C1-180711	LS in		Yes	Yes	noted	No
		S3‑180557	Reply LS on PLMN and RAT selection policies for roaming	C1-180761	LS in		Yes	Yes Vodafone: the CRs have ignored what we had agreed. These CRs are agreed but not approved formally in SA, we cannot accept them at this point. The authentication is SA3's business and not CT1's. NEC: SA or CT plenary? Docomo: make it clear what part of TS 33.501 is affected by this issue.	replied to	No
		S3‑180558	Reply LS on SBI Design and its Security Implications	C3-180339	LS in		Yes	Yes	noted	No
		S3‑180560	LS on RAN2 Assumption about DRB ID value range	R2-1801649	LS in		Yes	Yes Docomo: their assumption is correct. Nokia had tdocs 609 and 610 related to this.	replied to	No
		S3‑180561	LS on security for CU-CP/UP separation	R3-180630	LS in		Yes	Yes	replied to	No
		S3‑180562	Reply to LS on handling concurrent running of security procedures	R3-180632	LS in		Yes	Yes	noted	No
		S3‑180808	Reply LS on User Plane Security Policy	R3-180637	LS in		Yes	Yes Nokia: We don’t need a policy to enable encripytion from the SMF. Ericsson commented that they were fine with having that confidentiality would be removed from the UP policy keeping the integrity part. The confidentiality protection will be kept mandatory. Nokia: this means that we add more signalling. The LS was noted since this discussion didn’t impact it.	noted	No
		S3‑180564	LS on secure storage and processing of subscription credentials	S1-173475	LS in		Yes	Yes	replied to	No
		S3‑180833	Reply-LS to S3-180564 on secure storage and processing of subscription credentials	KPN N.V.	LS out	Approval	Yes	Yes	revised	No	S3‑180851
		S3‑180851	Reply-LS to S3-180564 on secure storage and processing of subscription credentials	KPN N.V.	LS out	Approval	Yes	Yes	approved	No		S3‑180833
		S3‑180814	[DRAFT] LS on authentication related services provided by AUSF and UDM	Ericsson	LS out	Approval	Yes	Yes Nokia: SA3 should not create terminology to be defined in CT3. Vodafone: we are talking about reservation of the names in 23.502 and used in TS 23.501, but the functionality shouldn’t be moved to TS 23.502.	revised	No	S3‑180918
		S3‑180918	LS on authentication related services provided by AUSF and UDM	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑180814
		S3‑180563	Reply LS on User Plane Security Policy	R3-180637	LS in		Yes	Yes	withdrawn	Yes
		S3‑180853	Reply LS on selectively disabling legacy radio technologies	S1-180634	LS in	discussion	Yes	Yes	noted	No
		S3‑180854	LS on support of Voice Service Continuity from 5G System to UTRAN CS	S1-180595	LS in	discussion	Yes	Yes It was noted that this was going for Rel-16.	noted	No
4.1.16	PLMN RAT selection
4.1.17	Others	S3‑180523	Resolving Editors' Notes in clause 5.1.4	KPN	pCR	Approval	Yes	Yes ORANGE: Leave the requirement. Vodafone didn’t agree with the "securityt evaluated" statement.	noted	No
		S3‑180655	pCR to 33.501 - removal of editor's notes on clause content	NTT DOCOMO INC.	pCR	Approval	Yes	Yes	approved	No
		S3‑180988	33.501 Editorials	Ericsson	discussion	Endorsement	No	Yes	endorsed	No
		S3‑180670	Security requirements for NEF	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180990
		S3‑180990	Security requirements for NEF	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180670
		S3‑180672	Security for NEF	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑180991
		S3‑180991	Security for NEF	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑180672
		S3‑180687	Resolve EN in 5.10	Orange	pCR	Approval	Yes	Yes MCC commented that instances of 4G should be replaced by LTE in the specification.	approved	No
		S3‑180797	Resolving ENs in 5.1.4	Qualcomm Incorporated	pCR	Approval	Yes	Yes GEMALTO: just leave "out of scope", I don’t agree with "determined by the issuer..". This NOTE was reworded. Vodafone: I'd rather store the certifications and analize them as part of the provisioning process. We will bring a contribution for this for the next meeting.	revised	No	S3‑180989
		S3‑180989	Resolving ENs in 5.1.4	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑180797
		S3‑180819	Resolving Editor's Note on IMEI by changing to PEI	KPN N.V.	pCR	Approval	Yes	Yes	revised	No	S3‑180993
		S3‑180993	Resolving Editor's Note on IMEI by changing to PEI	KPN N.V.	pCR	Approval	Yes	Yes	approved	No		S3‑180819
		S3‑180825	Removing of Editor’s Notes about SIDF, SUCI and SUPI in clause 3.3	KPN N.V.	pCR	Approval	Yes	Yes	noted	No
		S3‑180856	Draft TS 33.501	NTT-Docomo	draft TS	Approval	No	Yes	left for email approval	No
		S3‑180857	Cover sheet TS 33.501	NTT-Docomo	TS or TR cover	Approval	No	Yes It was clarified that PLMN RAT selection depended on CT1 progress on the matter.	approved	No
		S3‑180992	Replacement of the 4G term	Ericsson	pCR	Approval	Yes	Yes	approved	No
4.2	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑180559	LS on extension of S6x interface for BEST	C4-176388	LS in		Yes	Yes	noted	No
		S3‑180572	Collection of clarifications and editorial changes to BEST TS 33.163	Deutsche Telekom AG	CR	Approval	Yes	Yes	revised	No	S3‑180930	S3‑180029
		S3‑180930	Collection of clarifications and editorial changes to BEST TS 33.163	Deutsche Telekom AG	CR	Approval	Yes	Yes	agreed	No		S3‑180572
4.3	Mission Critical Security Enhancements (eMCSec) (Rel-15)	S3‑180565	[eMCSEC] 33180 R14 GMK management	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	revised	No	S3‑180863
		S3‑180863	[eMCSEC] 33180 R14 GMK management	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No		S3‑180565
		S3‑180566	[eMCSEC] 33180 R14 key storage and persistence	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	revised	No	S3‑180864
		S3‑180864	[eMCSEC] 33180 R14 key storage and persistence	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No		S3‑180566
		S3‑180567	[eMCSEC] 33180 R15 GMK management (mirror)	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	revised	No	S3‑180865
		S3‑180865	[eMCSEC] 33180 R15 GMK management (mirror)	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No		S3‑180567
		S3‑180568	[eMCSEC] 33180 R15 key storage and persistence (mirror)	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	revised	No	S3‑180866
		S3‑180866	[eMCSEC] 33180 R15 key storage and persistence (mirror)	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No		S3‑180568
		S3‑180799	[eMCSEC] Adding Integrity Key for KMS communications - Correcting XML	NCSC	CR	Agreement	No	Yes	withdrawn	Yes		S3‑180332
		S3‑180800	[eMCSec] 33.180 R15 Interconnection and Interworking media and signaling	NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑180926	S3‑180376
		S3‑180926	[eMCSec] 33.180 R15 Interconnection and Interworking media and signaling	NCSC,Motorola Solutions	CR	Agreement	Yes	Yes	agreed	No		S3‑180800
		S3‑180801	[eMCSEC] Cleanup of EAR description	NCSC	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑180802	[eMCSEC] Providing details of EARs into Annex J	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑180803	[eMCSEC] Clarification of purpose of Inter-domain user service authorisation	NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑180906
		S3‑180906	[eMCSEC] Clarification of purpose of Inter-domain user service authorisation	NCSC	CR	Agreement	Yes	Yes	agreed	No		S3‑180803
		S3‑180804	[eMCSEC] Correction of reference to SA1 specification	NCSC	CR	Agreement	Yes	Yes	agreed	No
4.4	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)	S3‑180587	Authorization for NAPS	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No
		S3‑180928	Draft CR on NAPS-Sec	Huawei,HiSilicon,NEC,Samsung	draftCR	Approval	Yes	Yes	approved	No
		S3‑180929	Security requirements and procedures for T8 reference point	Huawei	CR	Agreement	Yes	Yes	agreed	No
4.5	Security Aspects of Narrowband IOT (CIoT)	S3‑180553	Reply LS on Early Data Transmission	C1-175310	LS in		Yes	Yes	noted	No
		S3‑180554	LS on Status of Specifications Covering Requirements for IoT Modules	C1-175380	LS in		Yes	Yes	noted	No
4.6	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)	S3‑180780	Corrections and clarification for EDCE5	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑180855
		S3‑180855	Corrections and clarification for EDCE5	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑180780
		S3‑180783	Emergency call handling for EDCE5	Qualcomm Incorporated	CR	Agreement	Yes	Yes Docomo: Is there any requirement for supporting unauthenticated emergency calls?	not pursued	No
		S3‑180952	Preventing the use of NIA0 between the UE and sgNodeB	Qualcomm	CR	Agreement	Yes	Yes	agreed	No
4.7	Security Architecture for the Mobile Communication System for Railways (MONASTERY_SEC) (Rel-15)	S3‑180569	[MONASTERY_SEC] 33180 R15 functional alias(es)	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	revised	No	S3‑180907
		S3‑180907	[MONASTERY_SEC] 33180 R15 functional alias(es)	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No		S3‑180569
		S3‑180570	[MONASTERY_SEC] 33180 R15 multi-talker	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	revised	No	S3‑180927
		S3‑180927	[MONASTERY_SEC] 33180 R15 multi-talker	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes Changing the category given that it is adding new functionality. Motorola commented that the MONASTERY WID was closed for Rel-15, but a new WID in Rel-16 was being prepared.	agreed	No		S3‑180570
4.8	CMPv2	S3‑180719	Clarification need of CMPv2 in TS 33.310	Ericsson	discussion	Decision	Yes	Yes	noted	No
		S3‑180720	Use of fields in CMPv2	Ericsson	CR	Agreement	Yes	Yes Deutsche Telekom had concerns with this, it wasn't helpful for them. Vodafone agreed with DT. Huawei: this is not a problem. After 10 years we haven’t seen any issues.	postponed	No
4.9	PLMN RAT selection	S3‑180735	Discussion on SoR mechanism	NEC Corporation	discussion	Discussion	Yes	Yes Vodafone: There are more issues with overloading the authentication. This is just one of the cases.	endorsed	No
		S3‑180754	[DRAFT] LS on SoR mechanism	NEC Corporation	LS out	Agreement	Yes	Yes Huawei: no security issue when this authentication method. NEC: there is a dependency of the VPLMN to implement this functionality and they have no incentive to implement this functionality.	revised	No	S3‑180998
		S3‑180998	LS on SoR mechanism	NEC Corporation	LS out	Approval	Yes	Yes	approved	No		S3‑180754
		S3‑180807	Security mechanism for steering of roaming during authentication procedure	SAMSUNG	other		Yes	Yes	revised	No	S3‑181001
		S3‑181001	Security mechanism for steering of roaming during authentication procedure	SAMSUNG	other	-	Yes	Yes	approved	No		S3‑180807
		S3‑180810	AUSF Protecting the Steering of Roaming Information	SAMSUNG	other		Yes	Yes	approved	No
		S3‑180795	Proposed solution and conclusion for PLMN/RAT seleection	Qualcomm Incorporated	other	Approval	Yes	Yes ORANGE: no update in the USIM. Qualcomm agreed with this change. Huawei: It should be optional for the HPLMN according to CT1, this is not the case here. ORANGE didn’t think this was a major issue. Vodafone: I object because it ties with authentication.We don’t agree with the role of the UDM here either. Qualcomm clarified that this worked with any authentication and clarified the role of the UDM. BT: in CT1 there are companies that don’t want a separate network element. It is mentioned in the LS. Samsung: they prefer a control plane mechanism. Qualcom was fine with this. IDEMIA: why not updating the USIM? ORANGE: there is no requirement for this. Vodafone, ORANGE wanted the conclusion to be deleted. This was agreed.	revised	No	S3‑181000
		S3‑181000	Proposed solution and conclusion for PLMN/RAT seleection	Qualcomm Incorporated	other	Approval	Yes	Yes Huawei: this solution will only work for 5G SIM.	approved	No		S3‑180795
		S3‑180576	Adding conclusion to living document S3-180371	Huawei; Hisilicon	other	Approval	Yes	Yes Vodafone: I'm happy with this but deleting the conclusion. Vodafone:there are a lot pre Rel-8 sIMs cards in the market. You cannot guarantee that the AMF bit is available. Huawei: this is for 5G. Vodafone: we agreed with China Mobile to include legacy USIMs in this solution.	revised	No	S3‑181002
		S3‑181002	Adding conclusion to living document S3-180371	Huawei; Hisilicon	other	Approval	Yes	Yes	approved	No		S3‑180576
		S3‑180811	Conclusions for Security of PLMN/RAT selection policies for roaming	SAMSUNG	other		Yes	Yes	noted	No
		S3‑180812	pCR Security of PLMN/RAT selection policies for roaming	SAMSUNG Electronics Co., Ltd.	pCR		Yes	Yes	noted	No
		S3‑180828	Adding clauses for requirements and procedures for steering of UE in VPLMN	Ericsson	pCR	Approval	Yes	Yes Vodafone preferred to see this in the next meeting. Docomo agreed, they suggested to work on the requirements instead of adding this into the TS.	revised	No	S3‑181003
		S3‑181003	Adding clauses for requirements and procedures for steering of UE in VPLMN	Ericsson,Qualcomm	other	Approval	Yes	Yes Agreed to move it to the living document.	approved	No		S3‑180828
		S3‑180794	Support for Steering of Roaming UE in 5GS	Qualcomm Incorporated	pCR	Approval	Yes	Yes The requirements part will be added to the living document.	merged	No	S3‑181003
		S3‑180685	Living Document: Security of PLMN/RAT selection policies for roaming	Orange	other	Endorsement	Yes	Yes	revised	No	S3‑180999
		S3‑180999	Living Document: Security of PLMN/RAT selection policies for roaming	Orange	other	Endorsement	Yes	Yes	endorsed	No		S3‑180685
5	Studies
5.1	Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-15)
5.2	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)	S3‑180507	Solution for LTK generation	InterDigital, Inc.	pCR	Approval	Yes	Yes Vodafone: LTK solution is preemptive as well as reactive. The diagram suggests an only reactive solution. Ericsson: where would Diffie-Hellman be included? Interdigital: this solution can include Diffie-Hellman. Qualcomm: step 2 is optional but it triggers step 3. Vodafone: it jumps directly to step 5. This was clarified in the revision.	revised	No	S3‑180932
		S3‑180932	Solution for LTK generation	InterDigital, Inc.	pCR	Approval	Yes	Yes	approved	No		S3‑180507
		S3‑180571	Key Issue 7.x - LTK update via partial Profile Update	InterDigital, Inc.	pCR	Approval	Yes	Yes ORANGE: this is putting requirements for something that is not done in 3GPP. Vodafone: we can put it in the evaluation clause.	merged	No	S3‑180932
		S3‑180575	Solution#2 enhancement	Gemalto N.V.	pCR	Approval	Yes	Yes Vodafone: This seems to be part of the solution, given where it is inserted. ORANGE: no need to add another key.Sending the OTA message is optional.	revised	No	S3‑180933
		S3‑180933	Solution#2 enhancement	Gemalto N.V.	pCR	Approval	Yes	Yes	approved	No		S3‑180575
		S3‑180686	pCR to TR 33.834 - Updates to clauses 1 to 8 to prepare for approval	Vodafone GmbH	pCR	Agreement	Yes	Yes MCC asked whether the references to GSMA were publicly available. It was commented that the Global Platform ones were not available and this had to be taken offline for discussion with MCC.	revised	No	S3‑180843
		S3‑180688	pCR to TR 33.834 - Update to solution 1 to correct references and update the evalustion	Vodafone GmbH	pCR	Agreement	Yes	Yes	revised	No	S3‑180844
		S3‑180690	pCR to TR 33.834 - update of reference numbers and conclusion to solution 2	Vodafone GmbH	pCR	Agreement	Yes	Yes Alf: Remove the sentence on the extra processing power. This sentence was replaced as Docomo suggested.	revised	No	S3‑180934
		S3‑180934	pCR to TR 33.834 - update of reference numbers and conclusion to solution 2	Vodafone GmbH	pCR	Approval	Yes	Yes	approved	No		S3‑180690
		S3‑180694	pCR to 33.834 - update of solution evaluation for Solution 3	Vodafone GmbH	pCR	Agreement	Yes	Yes	revised	No	S3‑180935
		S3‑180935	pCR to 33.834 - update of solution evaluation for Solution 3	Vodafone GmbH	pCR	Agreement	Yes	Yes	approved	No		S3‑180694
		S3‑180697	pCR to 33.834 - Update of reference numbers and solution evaluation for solution 4	Vodafone GmbH	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑180698	pCR to 33.834 - removal of template Ki issues and Solutions in preparation for Specification approval	Vodafone GmbH	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑180722	pCR to 33.834 - Addition of conclusions and removal of Annex A	Vodafone GmbH	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑180843	pCR to TR 33.834 - Updates to clauses 1 to 8 to prepare for approval	Vodafone GmbH	pCR	Agreement	Yes	Yes	approved	No		S3‑180686
		S3‑180844	pCR to TR 33.834 - Update to solution 1 to correct references and update the evalustion	Vodafone GmbH	pCR	Agreement	Yes	Yes	revised	No	S3‑181007	S3‑180688
		S3‑181007	pCR to TR 33.834 - Update to solution 1 to correct references and update the evalustion	Vodafone GmbH	pCR	Agreement	Yes	Yes	approved	No		S3‑180844
		S3‑180931	Draft TR 33.834	Vodafone	draft TR	Approval	Yes	Yes	approved	No
5.3	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)	S3‑180588	Threats and potential countermeasures posed due to quantum computing	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑180937
		S3‑180937	Threats and potential countermeasures posed due to quantum computing	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑180588
		S3‑180536	pCR to TR 33.841 - Assessment of quantum computing impact timelines	China Mobile Com. Corporation	pCR		Yes	Yes	merged	No	S3‑180938
		S3‑180589	Assessment of quantum computing impact timelines	NCSC	pCR		Yes	Yes	revised	No	S3‑180938
		S3‑180938	Assessment of quantum computing impact timelines	NCSC,China Mobile	pCR	-	Yes	Yes	approved	No		S3‑180589
		S3‑180603	The impaction of 256 bit keys for NG areas and requirement of a longer MAC	CATT	pCR	Approval	Yes	Yes NCSC had quite a few issues with the paper. There were many issues from NCSC and ORANGE and Vodafone commented that a conference call could progress this.	noted	No
		S3‑180604	The impaction of 256 bit keys for NG areas	CATT	pCR	Approval	Yes	Yes	noted	No
		S3‑180717	Update to Clause 7 – IV entropy	Ericsson	pCR	Approval	Yes	Yes ORANGE expressed their concerns on the format of the contributions were making them hard to implement in the TR. Vodafone commented that this would be solved in the next meeting.	approved	No
		S3‑180605	The clarification of the entropy CK and IK	CATT	pCR	Approval	Yes	Yes Alf(Docomo): the concept of entropy is used here in a confusing way, although I agree with the meaning. An editor's note was added for this.	revised	No	S3‑180939
		S3‑180939	The clarification of the entropy CK and IK	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑180605
		S3‑180606	The clarification of the entropy CK and IK	CATT	pCR	Approval	Yes	Yes NCSC had some issues as well that had be to taken offline and brought back in the next meeting.	noted	No
		S3‑180718	Update to Clause 10 – RES and Editorials	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑180936	Draft TR 33.841	Vodafone	draft TR	Approval	Yes	Yes	approved	No
6	Any Other Business	S3‑180501	Work Plan input from the Rapporteurs	MCC	other	Information	Yes	Yes	revised	No	S3‑181004
		S3‑181004	Work Plan input from the Rapporteurs	MCC	other	Information	Yes	Yes	noted	No		S3‑180501
		S3‑180979	SA3 calendar	WG Chair	other	Information	Yes	Yes	noted	No
7	Close