TDoc list

Tdoc List

2019-05-10 15:43

Agenda	Topic	TDoc	Title	Source	Type	For	Avail	Treated	Decision	Wdrn	Replaced-by	Replaces
1	Opening of the meeting
2	Approval of Agenda and Meeting Objectives	S3‑191100	Agenda	WG Vice Chairman	agenda		Yes	Yes	approved	No
3	IPR and Anti-Trust Law Reminder
4	Meeting Reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑191101	Report from SA4#94AH	MCC	report		Yes	Yes	approved	No
		S3‑191598	Report from SA3#94	MCC	report	Approval	Yes	Yes	approved	No
4.2	Report from SA Plenary	S3‑191103	Report from last SA meeting	WG Vice Chairman (Qualcomm)	report		Yes	Yes	noted	No
4.3	Report from SA3-LI
5	Items for early consideration
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑191119	Reply LS on securing warning messages in ePWS	C1-191522	LS in		Yes	Yes	noted	No
		S3‑191120	Reply LS on securing warning messages in ePWS	S1-190503	LS in		Yes	YesBT: PWS has regulatory requirements identified,but SA1 says that this is not the case. Vice Chair: maybe this refers to ePWS, not PWS. Nokia: no specific requirements for IoT devices as opposed to humans. Vodafone: what does an IoT unit do with this message? Ericsson: CT1 decides the specific requirements and they said in the other LS that they haven't concluded this. Vodafone: if the early warning message is a piece of text we would have concerns about this. Vodafone was to ask their SA1 delegates about this for more clarification and maybe respond to SA1. This was taken offline. Nokia: IoT devices can be very different.	noted	No
		S3‑191125	Reply LS on EAS-C&U support	C3-191167	LS in		Yes	Yes	noted	No
		S3‑191126	LS on usage of EPLMNs	S2-1904825	LS in		Yes	YesRelated discussion paper in 462.	replied to	No
		S3‑191599	Reply to: LS on usage of EPLMNs	Vodafone	LS out	approval	Yes	Yes	approved	No
		S3‑191462	Discussion on security aspects of EPLMN in LS from S2 (S3-191126)	Vodafone GmbH	discussion	Discussion	Yes	YesEricsson wasn't sure about proposal C, although they supported a and b. This was taken offline. Qualcomm was fine with informing SA2, but not sure about sending an LS to CT1. It's up to SA3 to work on the security, CT1 is not involved in that.	noted	No
		S3‑191127	Reply LS on Interim conclusions for SA2 study on Radio Capabilities Signalling Optimisations (FS_RACS)	C4-190346	LS in		Yes	Yes	noted	No
		S3‑191129	Reply LS on GTP Recovery Counter & GSN node behaviour	C4-190485	LS in		Yes	Yes	noted	No
		S3‑191135	LS on Handling of non-essential corrections (non-FASMO) CRs and non-backwards compatible CRs	CP-190218	LS in		Yes	Yes	noted	No
		S3‑191148	LS on broadcast assistance data delivery	R2-1905462	LS in		Yes	YesQualcomm had a discussion paper in tdoc 520 proposing a reply.CATT also proposed a reply in 350.	replied to	No
		S3‑191600	Reply to: LS on broadcast assistance data delivery	Intel	LS out	approval	Yes	Yes	approved	No
		S3‑191520	Broadcast of Location Assistance Data for NR	Qualcomm Incorporated	discussion	Decision	Yes	YesEricsson commented that integrity protection should be included here. Qualcomm, Intel: no need to reopen this discussion. This was taken offline.	noted	No
		S3‑191154	Reply LS on authentication of group of IoT devices	S1-190501	LS in		Yes	Yes	replied to	No
		S3‑191601	Reply to: Reply LS on authentication of group of IoT devices	Huawei	LS out	approval	Yes	Yes	approved	No
		S3‑191244	Discussion paper Security of Bulk IoT operations	Huawei, Hisilicon	discussion	Endorsement	Yes	YesVodafone: it misses the point abut auth based on key sharing. ORANGE: SA2 and RAN groups should take care of this as well, not standalone SA3 work. Vodafone: IoT should be more secure, not less secure in our view. Huawei: SA1 is asking us about the authentication procedure. ORANGE: this is part of the registration procedure handled by SA2. IDEMIA agreed that his was to be treated firstly by SA2. BT: use case is about enabling/disabling large number of devices, so you should make it more secure. The term "operations" is more general. Huawei didn’t understand why this was necessarily less secure as stated by some companies. ORANGE: send an LS to SA1. Sony added that SA2 should be added to the recipients as well. The study item in 245 was postponed given that a response from SA1 was needed.	noted	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA	S3‑191137	GSMA DESS - Diameter IPX Network End-to-End Security Solution	GSMA	LS in		Yes	YesSpecific action for SA3, so this LS was postponed for the next meeting.	postponed	No
6.5	OMA
6.6	TCG	S3‑191108	TCG progress report	InterDigital	other	Information	Yes	Yes• Publication of new or revised deliverables (incremental changes from the status reported at SA3#94): o TCG TSS 2.0 TAB and Resource Manager – published April 2019 o TCG TSS 2.0 TPM Command Transmission Interface (TCTI) – published April 2019 o TCG TSS 2.0 System Level API (SAPI) – public review April 2019 o TCG TSS 2.0 Enhanced System Level API (ESAPI) – public review April 2019 o TCG PC Client Device Driver Design Principles for TPM 2.0 – public review February 2019 o TCG Platform Certificate Profile – public review February 2019 o TCG Trusted Platform Module 2.0 r1.50 – public review January 2019 o TCG TSS 2.0 Response Code API – public review January 2019 o TCG Trusted Attestation Protocol (TAP) Information Model – public review January 2019 2. Meetings • TCG Members Meeting in Warsaw, Poland – 10-13 June 2019 • TCG Annual Members Meeting in Toronto, Canada - 15-17 October 2019 • MPWG meets every Thursday at 10-11 ET • TMS WG meets every Monday and Friday at 12-13 ET • CyRes WG meets every Wednesday at 11-12:30 ET	noted	No
6.7	oneM2M
6.8	TC-CYBER
6.9	ETSI NFV
6.10	CVDs and Research	S3‑191623	Way forward in CVD and research	CableLabs	discussion	discussion	Yes	YesQualcomm: published papers can be discussed publicly in the SA3 mail list. Vodafone: uncomfortable to discuss these papers in an open meeting. It was decided to continue the discussions in the next meeting on how to address the academic papers. Qualcomm warned about legal issues if a private discussion group for SA3 was created, so they wanted to check back at home the implications of this. MCC reminded that there existed a closed group for VCD where papers could be discussed before their publication and a first response could be given before discussions in SA3.	noted	No
		S3‑191743	Handling of UE radio network capabilities in 4G and 5G	GSMA	LS in	discussion	Yes	YesVodafone: RAN2 should do something first, and they are meeting next week. Our next meeting is after SA, so we would have to have a conference call to address this to meet the deadline. Qualcomm: the issue is in RAN. It's a gNodeB configuration. It's a "should" requirement from the network side to first activate security. NTT-Docomo: we could have a conference call to address this. Qualcomm: RAN is meeting next week and then in August. It was decided to postpone and come up with a conference call between June and August if necessary.	postponed	No
6.11	Other Groups	S3‑191136	LS on the availability of and requesting feedback on the stable draft TR 103 582 from ETSI STF555 - "Study of use cases and communications involving IoT devices in emergency situations"	ETSI SC EMTEL	LS in		Yes	YesVodafone: we already missed the deadline given in here, so I propose to postpone this for the next meeting.	postponed	No
		S3‑191158	Approval of Smart Secure Platform requirement specification	ETSI TC SCP	LS in		Yes	Yes	noted	No
		S3‑191159	LS/r on SG17 work item X.5Gsec-q: Security guidelines for applying quantum-safe algorithms in 5G systems	ITU-T SG17	LS in		Yes	Yes	noted	No
		S3‑191160	LS on SG17 new work item X.5Gsec-ecs: Security Framework for 5G Edge Computing Services	ITU-T SG17	LS in		Yes	YesChina Unicom presented the document and commented that they were also participating.	noted	No
7	Work Areas
7.1	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
7.1.1	Key hierarchy
7.1.2	Key derivation	S3‑191203	KAUSF desynchronization problem and solutions	NEC Europe Ltd	discussion	Information	Yes	YesSuperseeded by tdoc 204.	noted	No
		S3‑191204	KAUSF desynchronization problem and solutions – updated version after conf call on 25 Apr.	NEC Europe Ltd	discussion	Endorsement	Yes	YesQualcomm: we don’t agree with bullets 3,4 and 5. More analysis is needed and it should be considered for Rel-16, not Rel-15. Ericsson agreed with Qualcomm. NEC was fine with having the work in Rel-16 instead of Rel-15, for bullets 3-5. Qualcomm didn’t see a need for bullets 3-5, independently from the release. Huawei only supported bullet 2. Samsung didn't agree with 3-5 either. Nokia needed to look at proposal 2, not agreeing on the rest.	noted	No
		S3‑191208	UDM triggered authentication	NEC Europe Ltd	draftCR	Discussion	Yes	YesMore analysis was needed on this proposal. Ericsson: if this is for Rel-16 we need a new Work Item and it is too early for that.	noted	No
		S3‑191205	Aligning the storage timing of KAUSF in 5G AKA with EAP-AKA'	NEC Europe Ltd	CR	Agreement	Yes	YesNokia didn’t agree with the changes. It seemed that companies were OK with the idea, but the wording was not correct. Qualcomm: no impact on the ME.	revised	No	S3‑191603
		S3‑191603	Aligning the storage timing of KAUSF in 5G AKA with EAP-AKA'	NEC Europe Ltd	CR	Agreement	Yes	Yes	agreed	No		S3‑191205
		S3‑191206	Synchronization of KAUSF between AUSF and UE	NEC Europe Ltd	draftCR	Discussion	Yes	Yes	not pursued	No
		S3‑191209	KAUSF key setting in EAP AKA’	NEC Europe Ltd	draftCR	Discussion	Yes	Yes	not pursued	No
		S3‑191207	Using Key Identifiers between AUSF and UE for UPU and SoR	NEC Europe Ltd	draftCR	Discussion	Yes	Yes	noted	No
		S3‑191446	Rectifying incorrect limitation for horiz/vert key derivation	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑191604
		S3‑191604	Rectifying incorrect limitation for horiz/vert key derivation	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑191446
		S3‑191367	Corrections on the s-Kgnb derivation	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: Wrong key name and second change does not need to be there.	revised	No	S3‑191605
		S3‑191605	Corrections on the s-Kgnb derivation	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑191367
7.1.3	Mobility	S3‑191407	Clarification on securing the procedure of idle mobility from 5GS to EPS over N26 interface	Huawei, Hisilicon	CR	Approval	Yes	YesNokia: add explanation on this in 8.5.1. Ericsson: why a separate clause? Just add a note. Vodafone: is this essential? Add the word in the title. Ericsson: all CRs cat-F are supposed to be essential anyway. No need for this.	revised	No	S3‑191606
		S3‑191606	Clarification on securing the procedure of idle mobility from 5GS to EPS over N26 interface	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑191407
		S3‑191411	Registration failure in registration procedure with AMF reallocation caused by slicing	Huawei, Hisilicon	discussion	Discussion	Yes	YesVodafone: this is lack of efficiency, not a security hole. Huawei: you will never be registered successfully, it's a denial of service. Ericsson: step 7 discarded by UE according to Huawei, but we don’t agree. The Vice Chair (NTT-Docomo) commented that confusion with the CT1 specification seemed to be the source of the discussion. An LS could be sent to them. Qualcomm agreed with sending an LS to CT1 ccSA2. It was a CT1 decision according to them. The vice chair asked if this was a Rel-15 issue, and Qualcomm replied that Rel-15 shouldn't be ruled out. This was taken offline.	noted	No
		S3‑191412	Solving registration failure in initial registration procedure with AMF reallocation	Huawei, Hisilicon	CR	Approval	Yes	YesThere was an agreement that this was a problem to be fixed, but Qualcomm preferred to contact SA2 and CT1 as well with an LS before agreeing with this CR. It was agreed the existence of an issue that needed to be solved; it was asked to be minuted "the issues in tdoc 411 need further investigation." The Chair declared the CRs as not pursued but pointed out that Huawei could bring back revisions of them to continue discussions in the next meeting.	not pursued	No
		S3‑191413	Solving registration failure in initial registration procedure with AMF reallocation	Huawei, Hisilicon	CR	Approval	Yes	Yes	not pursued	No
		S3‑191419	NAS recovery with the soure AMF in handover failure	Huawei, Hisilicon	CR	Approval	Yes	YesRelated to the LS in 147. Vodafone: this needs rewording.	merged	No	S3‑191607
		S3‑191449	Verification failure of NAS container	Ericsson	CR	Agreement	Yes	YesIntel didn’t see the need of this. How does the AMF will know to do the same?	merged	No	S3‑191607
		S3‑191512	Clarification for the NAS MAC failure case in N2 HO	Qualcomm Incorporated	CR	Agreement	Yes	YesVodafone: wording issues. Huawei: we are not addressing how often this happens. It's a new feature and if this happens often the RAN2 LS is a good place to start, but we need to agree on how often this happens. Ericsson commented that this was out of scope of SA3.	revised	No	S3‑191607
		S3‑191607	Clarification for the NAS MAC failure case in N2 HO	Qualcomm Incorporated,Huawei,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑191512
7.1.4	AS security	S3‑191143	Reply LS on Dual Connectivity	R2-1902677	LS in		Yes	Yes450 related to this LS.	noted	No
		S3‑191144	Reply LS on Enforcement of maximum supported data rate for integrity protection	R2-1902700	LS in		Yes	Yes	noted	No
		S3‑191379	Add detials on handling UP security in RRC inactive scenario	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm needed to take this offline.	revised	No	S3‑191609
		S3‑191609	Add detials on handling UP security in RRC inactive scenario	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑191379
		S3‑191395	Discussion on Key handling on UE for Reestablishment Procedure in case of N2 handover failure	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191394	CR to TS33501-RRC Reestablishment security handling when N2 Handover fails	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm: this is not needed in Rel-15 and it should be discussed separately in Rel-16. Ericsson agreed: RAN groups consider this as a rare case and they don’t want to optimize for this. Huawei: let's ask RAN2 about their opinion on this.It is not a radio link failure. Ericsson: this is to be handled by RAN2, no LS needed. Qualcomm agreed. Huawei considered it to be a valid security issue. There was no agreement to have this for Rel-15, and more offline discussion was needed for Rel-16.	not pursued	No
		S3‑191450	Security algorithm change by SN	Ericsson	CR	Agreement	Yes	YesHuawei: this change is not needed.	not pursued	No
		S3‑191483	CR to 33.501 6.6.4 UP integrity mechanisms - UE to gNB ntegrity protection check failure reporting	BT plc	CR	Approval	Yes	YesIt was commented that TEIx for Rel-16 category-B and C was not recommended anymore by SA. The WI code would have to be taken into account. Deutsche Telekom: do we want to make this mandatory? Qualcomm: RAN2 asked SA3 last year about this being necessary and now we are reopening the issue changing our mind. Nokia: network and UE can verify that the integrity is failing already. We don’t agree with this change either. Samsung: When the PDCP error happens, it is reported to the RRC layer. RRC layer knows the reason why the packet is dropped. RAN2 implements the behaviour on how to act in case there is such failure. Qualcomm: this is a RAN level discussion. They discussed this in Rel-15 and there was no agreement. Lenovo didn’t agree with this either. This was taken offline.	not pursued	No
		S3‑191705	Security of RRC Reestablishment during N2 HO	Huawei	LS out	Approval	Yes	YesQualcomm and Ericsson were against sending this LS. Huawei pointed out that most companies were OK with this.	noted	No
7.1.5	NAS security	S3‑191147	LS on Security failure of NAS container in HO command	R2-1905460	LS in		Yes	Yes419,449 and 512 handle this issue.	replied to	No
		S3‑191608	Reply to: LS on Security failure of NAS container in HO command	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑191124	LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode	C1-192804	LS in		Yes	YesTdocs 452, 501, 502,503 are related documents. Tentative response from Qualcomm in 505.	replied to	No
		S3‑191346	CR to TS33.501 - NAS SMC figure correction	CATT	CR		Yes	Yes	agreed	No
		S3‑191387	Clarification for Initial NAS Message Protection	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: valid scenario but the additional changes are already described somewhere else. This had to be taken offline.	revised	No	S3‑191611
		S3‑191611	Clarification for Initial NAS Message Protection	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑191387
		S3‑191447	UP policy handling in case of unauthenticated emergency calls	Ericsson	CR	Agreement	Yes	YesCableLabs agreed with the change, it clarifed an ambiguity. Alex (BT): this wording infers that the AMF may not accept unauthentication in emergency calls and this is a requirement for the network. The problem is in "in the case" words. This change was removed. Qualcomm: ME is not affected.	revised	No	S3‑191612
		S3‑191612	UP policy handling in case of unauthenticated emergency calls	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑191447
		S3‑191448	Remove EN in clause 10.2.2.2	Ericsson	CR	Agreement	Yes	YesHuawei: specification of the messages is a CT1 issue. There were different concerns about this and Ericsson decided to bring it back during the next meeting.	not pursued	No
		S3‑191501	Correction to the handling of security context in the multi-NAS scenario	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑191783
		S3‑191783	Correction to the handling of security context in the multi-NAS scenario	Qualcomm Incorporated,Ericsson,Huawei	CR	Agreement	Yes	Yes	agreed	No		S3‑191501
		S3‑191502	Description of issue of clashing ngKSIs with multi-NAS security	Qualcomm Incorporated	discussion	Discussion	Yes	YesHuawei considered this as a very rare case. Ericsson:	noted	No
		S3‑191503	Clashing ngKSI for different security contexts in multi-NAS scenarios	Qualcomm Incorporated	CR	Agreement	Yes	YesQualcomm will bring a revised version for the next meeting.	not pursued	No
		S3‑191122	LS on handling of non-zero ABBA value in Release 15	C1-191686	LS in		Yes	Yes	replied to	No
		S3‑191504	Response LS on handling of non-zero ABBA value in Release 15	Qualcomm Incorporated	LS out	Approval	Yes	Yes	revised	No	S3‑191613
		S3‑191613	Response LS on handling of non-zero ABBA value in Release 15	Qualcomm Incorporated	LS out	Approval	Yes	Yes	approved	No		S3‑191504
		S3‑191505	Response LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode	Qualcomm Incorporated	LS out	Approval	Yes	Yes	revised	No	S3‑191610
		S3‑191610	Response LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode	Qualcomm Incorporated	LS out	Approval	Yes	Yes	approved	No		S3‑191505
		S3‑191549	Clarification to Initial NAS message protection	Samsung	CR	Approval	Yes	YesThis had to be discussed offline and Samsung will bring a modified version for the next meeting.	not pursued	No
7.1.6	Security context
7.1.7	Visibility and Configurability
7.1.8	Primary authentication	S3‑191230	Discussion paper on Re-authentication and UE context handling	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	YesEricsson: number 6 not to be handled in Rel-16. They didn't agree with the rest of the points. Qualcomm: this could create more issues than actually solving anything. Samsung supported point 6 (for Rel-16) but agreed with Qualcomm for the rest, on being careful with how to handle the issue. BT didn't agree with point 6 on the wording "in any scenario". This was taken offline	noted	No
		S3‑191589	Discussion on removing the authentication result in the UDM	Huawei, Hisilicon	discussion	Discussion	Yes	YesEricsson: the attack is valid in a very rare case. There wasn't much support for this and the accompanying CR was not pursued.	noted	No		S3‑191417
		S3‑191492	Removing the authentication result in the UDM	Huawei, Hisilicon	CR	Approval	Yes	Yes	not pursued	No		S3‑191418
		S3‑191444	Discussion on missing AMF/SEAF behaviour	Ericsson, CableLabs	discussion	Endorsement	Yes	YesHuawei: maybe we don’t need to cope with this until someone comes with a security threat and attack related to this. If not, it would be a protocol error left for stage 3. ORANGE: this is an error case, agree with Huawei. Nokia didn't agree either. Ericsson asked what the right behaviour was. Qualcomm answered that this case scenario would not work, it doesn't matter asking about the behaviour.	noted	No
		S3‑191445	Missing AMF/SEAF behaviour	Ericsson, CableLabs	CR	Agreement	Yes	Yes	not pursued	No
		S3‑191417	Discussion on removing the authentication result in the UDM	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	revised	No	S3‑191589
		S3‑191418	Removing the authentication result in the UDM	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑191492
7.1.9	Secondary authentication
7.1.10	Interworking	S3‑191451	Verification failure of NAS MAC in NAS container at 4G to 5G HO	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑191614
		S3‑191452	Handling of 5G security contexts with multiple NAS connections at 4G to 5G HO	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑191783
		S3‑191513	Clarification for the NAS MAC failure case in interworking	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑191614
		S3‑191614	Clarification for the NAS MAC failure case in interworking	Qualcomm Incorporated,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑191513
7.1.11	non-3GPP access
7.1.12	NDS
7.1.13	Service based architecture
7.1.13.1	Interconnect (SEPP related)	S3‑191128	Reply LS on Verification of PLMN-ID in the SEPP	C4-190348	LS in		Yes	Yes	replied to	No
		S3‑191615	Reply to: Reply LS on Verification of PLMN-ID in the SEPP	Deutsche Telekom	LS out	approval	Yes	Yes	approved	No
		S3‑191185	Addition of missing SEPP requirement on JOSE-patch validation	Deutsche Telekom AG	CR	Approval	Yes	YesNokia: modify the following sentence instead of adding the new sentence.	revised	No	S3‑191616
		S3‑191616	Addition of missing SEPP requirement on JOSE-patch validation	Deutsche Telekom AG	CR	Approval	Yes	Yes	agreed	No		S3‑191185
		S3‑191316	Name for N32 application layer security	Ericsson	discussion	Endorsement	Yes	YesVodafone: what happens if other people are using the acronym in their specs? SA has asked for essential corrections in Rel-15. NTT-Docomo: the current acronym is heavily overloaded. NCSC: change the acronym, it's unlikely that many specs are using it. Ericsson:: we would tell CT4 mainly.	noted	No
		S3‑191617	Name clarification for N32 security	Ericsson,NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑191618	LS on clarification for N32 security	Ericsson	LS out	Approval	Yes	YesThe LS will attach the CR in 617 and sent to SA and CT so the Plenary can decide whether to accept it or not.	approved	No
7.1.13.2	Other	S3‑191314	Token-based authorization for NRF's management and discovery services	Ericsson	CR	Agreement	Yes	YesEricsson: this is alignment with CT4. Huawei preferred to keep the note. BT: the cover sheet does not correspond to the clause that is being changed. It is not the right place to make the change. Ericsson commented that if this wasn't accepted, CT4 would have to revert their decision.	revised	No	S3‑191619
		S3‑191619	Token-based authorization for NRF's management and discovery services	Ericsson	CR	Agreement	Yes	YesHuawei didn’t agree with the changes.	not pursued	No		S3‑191314
		S3‑191315	Slice information for token-based authorization	Ericsson	CR	Agreement	Yes	YesDeutsche Telekom: isn’t this a Rel-16 issue? We have a key issue in Rel-16 about this. Ericsson: we do it for Rel-15 then enhancements in Rel-16.	revised	No	S3‑191621
		S3‑191621	Slice information for token-based authorization	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑191315
		S3‑191522	Discussion of SBA authorization selection	China Mobile	discussion	Endorsement	Yes	YesDeutsche Telekom: we should involve CT4 as well and have a discussion on whether we want to do it this way. Nokia didn’t agree with the proposal: Authentication during discovery and authentication during service access are not mutually exclusive as the paper claims.	noted	No
		S3‑191524	Proposal of SBA authorization revision	China Mobile	CR	Approval	Yes	Yes	not pursued	No
7.1.14	Privacy	S3‑191121	LS on Use of SUCI in NAS signalling	C1-191685	LS in		Yes	Yes	replied to	No
		S3‑191752	Reply to: LS on Use of SUCI in NAS signalling	Intel	LS out	approval	Yes	Yes	approved	No
		S3‑191305	Discussion on LS on Use of SUCI in NAS signalling	ZTE Corporation	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191306	Modification on Use of SUCI in NAS signalling	ZTE Corporation	CR	Agreement	Yes	YesQualcomm: it correctly reflects what's happening in CT1. It needs to be verified if this is acceptable from security point of view. This was taken offline.	revised	No	S3‑191704
		S3‑191704	Modification on Use of SUCI in NAS signalling	ZTE Corporation,Intel	CR	Agreement	Yes	Yes	agreed	No		S3‑191306
		S3‑191258	Clarification on Subscription Identifier mechanism for De-registration.	Intel Corporation (UK) Ltd	CR		Yes	YesNokia: the use of SUCI here opens a DoS attack scenario. Qualcomm: Deregistration with the SUCI would happen as part of the registration procedure. IDEMIA: in which case the 5G GUTI is not valid? This is what we need to identify. NTT-Docomo was concerned like Nokia as this could be misused. CableLabs didn’t agree with the attack scenario. Anja (Nokia): SUCI is a one time identifier by design. Qualcomm commented that there is a requirement where the UE will keep sending the same SUCI in a specific situation. Qualcomm: if you read the CT1 specification, it is up to AMF how to handle this. Nokia: CT1 inherited this case from LTE. It was allowed in LTE, but changes adopted for SUCI require a correction in CT1. This had to be taken offline.	revised	No	S3‑191751
		S3‑191751	Clarification on Subscription Identifier mechanism for De-registration.	Intel Corporation (UK) Ltd	CR	-	Yes	YesNokia: this opens up a DoS attack scenario but it's too late to change this in Rel-15. Qualcomm agreed.	agreed	No		S3‑191258
		S3‑191307	LS on Use of SUCI in NAS signalling	ZTE Corporation	LS out	Approval	Yes	Yes	noted	No
		S3‑191257	draft LS response to LS on Use of SUCI in NAS signalling	Intel Corporation (UK) Ltd	response		Yes	Yes	noted	No
		S3‑191163	Clarification of MSIN coding for the ECIES protection shemes	IDEMIA,Gemalto, Qualcomm,Ericsson,Huawei,HiSilicon	CR	Approval	Yes	YesDiscussed with 261.	revised	No	S3‑191624
		S3‑191624	Essential clarification of MSIN coding for the ECIES protection shemes	IDEMIA,Gemalto, Qualcomm,Ericsson,Huawei,HiSilicon,Intel	CR	Approval	Yes	Yes	agreed	No		S3‑191163
		S3‑191261	Input encoding for ECIES protection schemes	Intel Corporation (UK) Ltd	CR		Yes	YesIDEMIA: we don’t need to add anything else to the CT1 work.The new figure was removed.	merged	No	S3‑191624
		S3‑191414	Clarification on the SUCI compuation	Huawei, Hisilicon, Gemalto, IDEMIA	CR	Approval	Yes	YesVodafone: it needs rewording.	revised	No	S3‑191625
		S3‑191625	Clarification on the SUCI compuation	Huawei, Hisilicon, Gemalto, IDEMIA	CR	Approval	Yes	YesAdded a reference as proposed by Ericsson.	agreed	No		S3‑191414
		S3‑191357	Subscriber privacy: ECIES test data for Profile A	Gemalto N.V.	discussion	Discussion	Yes	Yes	noted	No
		S3‑191409	Subscriber privacy: test data for Profile A of SUCI computation	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑191626
		S3‑191220	subscriber privacy: ECIES test data	Gemalto, IDEMIA, Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑191626
		S3‑191626	subscriber privacy: ECIES test data	Gemalto, IDEMIA, Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑191220
		S3‑191453	Missing privacy parameters	Ericsson	CR	Agreement	Yes	YesGemalto added a clarification on NOTE2: "by OTA". IDEMIA: we don’t need to indicate how it is updated, it is up to the operator. Nokia, Qualcomm: all these details are in CT specs; we don’t need this CR. Gemalto supported Ericsson's CR. Qualcomm: it is not an essential correction. Huawei agreed. IDEMIA: not a contentious issue, we can go forward with this change. Ericsson: in which stage 3 document is this covered? ORANGE preferred not to refer to a CT6 specification. ORANGE: Keep 5.2.5 make a new contribution for 5.8.2. Vodafone: no need to standardize what appears in 5.8.2.	revised	No	S3‑191627
		S3‑191627	Missing privacy parameters	Ericsson,Gemalto,IDEMIA	CR	Agreement	Yes	Yes5.8.2 was removed and NOTE 2 modified.	agreed	No		S3‑191453
7.1.15	Incoming and outgoing Lses	S3‑191131	LS on Maximum HTTP payload size	C4-190609	LS in		Yes	Yes	noted	No
		S3‑191156	Reply LS on Clarification of UE Trace support	S2-1902901	LS in		Yes	Yes	noted	No
		S3‑191132	LS on Protected LI Parameters in N4	S3i190254	LS in		Yes	YesBT: LTE solution has security weaknesses to be hardened in 5G.	noted	No
		S3‑191133	Reply LS on Protected LI Parameters in N4	C4-191529	LS in		Yes	Yes	noted	No
		S3‑191134	Reply on LS on Protected LI Parameters in N4	S3i190283	LS in		Yes	Yes	noted	No
		S3‑191150	Response LS on reporting all cell IDs in 5G	R3-191111	LS in		Yes	Yes	noted	No
		S3‑191151	Response LS on reporting all cell IDs in 5G	S2-1904819	LS in		Yes	Yes	noted	No
		S3‑191152	Response LS on reporting all Cell IDs in 5G	S3i190265	LS in		Yes	Yes	noted	No
		S3‑191155	Reply LS on Interception of voice services over new radio in a 5GS environment	S2-1902799	LS in		Yes	Yes	noted	No
		S3‑191628	LS on support of non-3GPP only UE and support for PEI in IMEI format	S2-1904836	LS in	discussion	Yes	Yes	postponed	No
7.1.16	Others	S3‑191562	Addition of AMF/SMF requirement on security logging	Deutsche Telekom AG, NTT Docomo	CR	Approval	Yes	Yes	agreed	No		S3‑191262
		S3‑191313	Various corrections to security protocols and cryptography	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑191130	Reply LS on Nudr Sensitive Data Protection	C4-190534	LS in		Yes	Yes	replied to	No
		S3‑191629	Reply to: Reply LS on Nudr Sensitive Data Protection	Hewlett Packard Enterprise	LS out	approval	Yes	YesNokia had a proposal to make a change in TS 33.501 with a new requirement. It was said that she could bring it back in the next meeting as Ericsson requested more time to check it.	approved	No
		S3‑191420	Missing UDR description in alignment with 29.505	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesVodafone: no point in standardising this now. Telecom Italia pointed out that this was cat-B for Rel-15 and too late to be introduced. It was commented that this was aligning with CT4 changes. BT: unless the vendors update security in UDM/UDR we will have security breaches. This introduces an operational problem. Vodafone agreed. Christine (Ericsson) wanted to take it offline to clarify the concerns on the deployment of this. NTT-Docomo commented: can UDM be virtualised? If so, security is not possible; it would be a red flag. Hpe: we thought that ARPF would be a separate module, have hardware for that one. ORANGE: how do we handle having the right keys in the right hardware when having multiple UDMs? This had to be taken offline.	not pursued	No
		S3‑191421	Adding Nudr service	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	not pursued	No
		S3‑191262	Addition of AMF/SMF requirement on security logging	Deutsche Telekom AG, NTT Docomo	CR	Approval	Yes	Yes	revised	No	S3‑191562
7.2	Security Assurance Specification for 5G (SCAS_5G) (Rel-16)
7.2.1	NR Node B (gNB) (TS 33.511)	S3‑191214	New Test Case: Error handling of malformed JSON object between two network products	NEC Europe Ltd	draftCR	Agreement	Yes	Yes	revised	No	S3‑191487
		S3‑191380	Completing TS 33.511	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson queried about the conclusion on gNB-specific additions to 33.117. Huawei replied that they didn’t find new test cases.	revised	No	S3‑191741
		S3‑191741	Completing TS 33.511	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191380
		S3‑191381	Adding gNB critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson commented that a similar work should be done for the other network product classes. Ericsson: Confidentiality and inegrity protection are missing in X.2.1. The contribution was well received but it needed further discussions.	revised	No	S3‑191630
		S3‑191630	Adding gNB critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑191381
		S3‑191463	Living Document: General SBA/SBI aspects in TS 33.117	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	revised	No	S3‑191631
		S3‑191631	Living Document: General SBA/SBI aspects in TS 33.117	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	approved	No		S3‑191463
		S3‑191487	New Test Case: Error handling of malformed JSON object between two network products	NEC Europe Ltd	draftCR	Agreement	Yes	YesHuawei: what is a malformed JSON object? NEC: NOTE 1 explains it. Huawei: the test case needs more work. Ericsson supported this. Ericsson added that this could mean having malformed JSON objects everywhere.	revised	No	S3‑191701	S3‑191214
		S3‑191701	New Test Case: Error handling of malformed JSON object between two network products	NEC Europe Ltd	draftCR	Agreement	Yes	Yes	noted	No		S3‑191487
		S3‑191640	Adapting maximum HTTP payload size to CT4 specification	Deutsche Telekom	pCR	Approval	Yes	Yes	approved	No
		S3‑191785	Draft TS 33.511	Huawei	draft TS	Approval	Yes	Yes	approved	No
		S3‑191786	Cover sheet TS 33.511	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
7.2.2	Access and Mobility Management Function (TS 33.512)	S3‑191401	Test case on UE security capability invalid or unacceptable	Huawei, Hisilicon	pCR	Approval	Yes	YesDeutsche Telekom: expected result should be reworded. Nokia had some comments that needed to be taken offlien. Ericsson: there is no threat, not clearly motivated. The test is very unspecific, not clear what the test should do. Huawei: CT1 has specified what's invalid or unacceptable.We can focus on the clear scenarios if needed. Nokia: we need to do firstly a threat analysis and afterwards the test case. Huawei: it's in the rational. Nokia: it should be documented in the TR 33.926.	revised	No	S3‑191650
		S3‑191650	Test case on UE security capability invalid or unacceptable	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191401
		S3‑191400	Removing the EN on AMF log	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑191651
		S3‑191560	Removing the EN on AMF log	NTT DOCOMO, Deutsche Telekom	pCR		Yes	Yes	revised	No	S3‑191651
		S3‑191651	Removing the EN on AMF log	NTT DOCOMO, Deutsche Telekom,Huawei	pCR	-	Yes	Yes	approved	No		S3‑191560
		S3‑191181	Addition of Network Product Class Description for AMF	Deutsche Telekom AG	CR	Approval	Yes	YesMCC was hesitant about referring to Release 16 version of TS 23.501. The reference pointed to Rel-16 by default. Ericsson commented that in fact the reference should be for the Release 15 version of TS 23.501. It was decided to work with draftCRs so this was converted into a new document in 653.	not pursued	No
		S3‑191653	Addition of Network Product Class Description for AMF	Deutsche Telekom AG	draftCR	Approval	Yes	Yes	approved	No
		S3‑191182	Addition of AMF-related Security Problem Descriptions	Deutsche Telekom AG	CR	Approval	Yes	YesHuawei: add the threat rational.	revised	No	S3‑191654
		S3‑191654	Addition of AMF-related Security Problem Descriptions	Deutsche Telekom AG	CR	Approval	Yes	Yes	agreed	No		S3‑191182
		S3‑191652	Draft TS 33.512	Deutsche Telekom	draft TS	Approval	Yes	Yes	approved	No
7.2.3	User Plane Function (UPF) (TS 33.513)
7.2.4	Unified Data Management (UDM) (TS 33.514)
7.2.5	Session Management Function (SMF) (TS 33.515)	S3‑191396	Security Assurance Requirements and Test Case on TEID Uniqueness for SMF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191655
		S3‑191655	Security Assurance Requirements and Test Case on TEID Uniqueness for SMF	Huawei, Hisilicon,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑191396
		S3‑191465	SMF Test Case: TEID Uniqueness	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson: it needs more work on the threats, it seems to be incomplete. Docomo had some issues that were taken offline.	merged	No	S3‑191655
		S3‑191656	Draft TS 33.515	Huawei	draft TS	Approval	Yes	Yes	approved	No
7.2.6	Authentication Server Function (AUSF) (TS 33.516)	S3‑191320	Using STRIDE methodology for NPCD, SPD, assets and threats	Ericsson	discussion	Endorsement	Yes	YesHuawei wasn’t sure about adding anything else to the process that was being performed in LTE and now in 5G.	noted	No
7.2.7	Security Edge Protection Proxy (SEPP) (TS 33.517)	S3‑191186	Testcase: Replacing confidential IEs with NULL in original N32-f message	Deutsche Telekom AG	pCR	Approval	Yes	Yes	revised	No	S3‑191657
		S3‑191657	Testcase: Replacing confidential IEs with NULL in original N32-f message	Deutsche Telekom AG	pCR	Approval	Yes	Yes	approved	No		S3‑191186
		S3‑191466	New Annex for the SEPP in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesHuawei: In x.2.3.1 the effect would be a worse problem than a waste of system resources. This was taken offline.	revised	No	S3‑191659
		S3‑191659	New Annex for the SEPP in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	approved	No		S3‑191466
		S3‑191467	Updates to SEPP Test Cases	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson: remove editor's note on requirement to be added in 33.501. Huawei didn't agree with the last change, it was not needed according to them. Related to contribution 469 according to Nokia, but it was clarified that the SCAS work didn’t depend on study work, so the last change was removed.	revised	No	S3‑191660
		S3‑191660	Updates to SEPP Test Cases	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191467
		S3‑191658	Draft TS 33.517	Nokia	draft TS	Approval	Yes	Yes	approved	No
7.2.8	Network Resource Function (NRF) (TS 33.518)	S3‑191397	Discussion on the security test of NRF authorization	Huawei, Hisilicon	discussion	Discussion	Yes	YesEricsson: 33.926 should contain the threat part. Huawei: we just want to show that the threat exists and we can ome back later with a contribution for 33.926.	noted	No
		S3‑191398	Way forward on the security test of NRF authorization	Huawei, Hisilicon	discussion	Endorsement	Yes	YesEricsson: not clear what we are endorsing. It was generally agreed and the wording was worked out offline.	revised	No	S3‑191662
		S3‑191662	Way forward on the security test of NRF authorization	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	endorsed	No		S3‑191398
		S3‑191399	Security Assurance Requirement and Test for NRF authorization on the NF discovery	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia preferred to have another name for the test. They had other comments that had to be taken offline.	revised	No	S3‑191663
		S3‑191663	Security Assurance Requirement and Test for NRF authorization on the NF discovery	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191399
		S3‑191468	New Annex for the NRF in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	revised	No	S3‑191664
		S3‑191664	New Annex for the NRF in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	approved	No		S3‑191468
		S3‑191665	Draft TS 33.518	Nokia	draft TS	Approval	Yes	Yes	approved	No
7.2.9	Network Exposure Function (NEF) (TS 33.519)
7.3	eMCSec R16 security (MCXSec) (Rel-16)	S3‑191157	LS on LI Impacts for LMR-LTE Interworking study	S3i190281	LS in		Yes	Yes	noted	No
		S3‑191171	[33.180] R16 Pre-established PCK	Motorola Solutions UK	CR	Agreement	Yes	Yes	revised	No	S3‑191647
		S3‑191647	[33.180] R16 Establishment of PCK for MCData	Samsung	CR	Agreement	Yes	Yes	agreed	No		S3‑191171
7.4	Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)	S3‑191384	a skeleton of security aspects of 5G SRVCC to UTRAN	Huawei, Hisilicon	CR	Approval	Yes	YesORANGE: plenary decision is against X.3 (return from UTRAN to E-UTRAN or NR). We don’t need it. Huawei clarified that this wasn't a CR but a draftCR. Qualcomm commented that this was a baseline, with agreed changes from the Kochi meeting; removing X.3 would need another contribution. It was agreed to remove X.3. The living document/draft CR will be in 648 and will capture the agreements of this meeting.	not pursued	No
		S3‑191500	Key derivation for SRVCC from 5G to UTRAN CS	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑191382	security procedures of 5G SRVCC to UTRAN	Huawei, Hisilicon	CR	Approval	Yes	YesContent will be merged with China Unicom's agreed content in 649.	not pursued	No
		S3‑191293	Key derivation during SRVCC from 5G to UTRAN CS	China Unicom,CATT	CR		Yes	YesX.1.2 will be removed and the content merged with Huawei's contribution.	not pursued	No
		S3‑191294	Emergency call in SRVCC from NR to UTRAN	China Unicom, CATT	CR		Yes	YesORANGE: the second paragraph doesn't make any sense.What keys are derived in here? It was clarified that the handing over to 3G should be similar as the procedure in 4G, so the wording should explain this better. Content will merge into 649.	not pursued	No
		S3‑191648	skeleton of security aspects of 5G SRVCC to UTRAN	China Unicom	draftCR	Approval	Yes	YesNew version of the living document.	approved	No
		S3‑191649	Security procedures of 5G SRVCC to UTRAN	Huawei,China Unicom,CATT	other	Approval	Yes	Yes	approved	No
7.5	Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16)	S3‑191547	Security Requirements for CAPIF-3e/4e/5e reference points	Samsung	CR	Approval	Yes	Yes	agreed	No
7.6	Other work areas
7.6.1	SAE/LTE Security
7.6.2	IP Multimedia Subsystem (IMS) Security	S3‑191590	Secure LI Data Access Living Document	BT plc	other	Agreement	No	Yes	withdrawn	Yes
7.6.3	Network Domain Security (NDS)
7.6.4	UTRAN Network Access Security
7.6.5	GERAN Network Access Security
7.6.6	Generic Authentication Architecture (GAA)
7.6.7	Security Aspects of Home(e)NodeB (H(e)NB)
7.6.8	Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)	S3‑191113	[MCPTT] 33179 R13. Clarification of the references to RFC 3711	Airbus DS SLC	CR	Approval	Yes	YesMotorola: it should be 40 bits. Airbus: the way it is written it refers to 32 bits. Motorola: standards says 32 bits, errata says 40 bits. We need to use 40 bits.	revised	No	S3‑191641
		S3‑191641	[MCPTT] 33179 R13. Clarification of the references to RFC 3711	Airbus DS SLC	CR	Approval	Yes	Yes	agreed	No		S3‑191113
		S3‑191114	[MCSec] 33180 R14. Clarification of the references to RFC 3711	Airbus DS SLC	CR	Approval	Yes	Yes	revised	No	S3‑191642
		S3‑191642	[MCSec] 33180 R14. Clarification of the references to RFC 3711	Airbus DS SLC	CR	Approval	Yes	Yes	agreed	No		S3‑191114
		S3‑191115	[MCSec] 33180 R15. Clarification of the references to RFC 3711	Airbus DS SLC	CR	Approval	Yes	Yes	revised	No	S3‑191643
		S3‑191643	[MCSec] 33180 R15. Clarification of the references to RFC 3711	Airbus DS SLC	CR	Approval	Yes	Yes	agreed	No		S3‑191115
		S3‑191165	[33.179] R13 XSD Corrections	Motorola Solutions UK	CR	Agreement	Yes	Yes	agreed	No
		S3‑191166	[33.180] R14 XSD Corrections	Motorola Solutions UK	CR	Agreement	Yes	Yes	agreed	No
		S3‑191167	[33.180] R15 XSD Corrections (mirror)	Motorola Solutions UK	CR	Agreement	Yes	Yes	agreed	No
		S3‑191168	{33.179] R13 Remove IANA editor's notes	Motorola Solutions UK	CR	Agreement	Yes	Yes	revised	No	S3‑191644
		S3‑191644	{33.179] R13 Remove IANA editor's notes	Motorola Solutions UK	CR	Agreement	Yes	Yes	agreed	No		S3‑191168
		S3‑191169	[33.180] R14 Remove IANA editor’s notes	Motorola Solutions UK	CR	Agreement	Yes	Yes	revised	No	S3‑191645
		S3‑191645	[33.180] R14 Remove IANA editor’s notes	Motorola Solutions UK	CR	Agreement	Yes	Yes	agreed	No		S3‑191169
		S3‑191170	[33.180] R15 Remove IANA editor’s notes (mirror)	Motorola Solutions UK	CR	Agreement	Yes	Yes	revised	No	S3‑191646
		S3‑191646	[33.180] R15 Remove IANA editor’s notes (mirror)	Motorola Solutions UK	CR	Agreement	Yes	Yes	agreed	No		S3‑191170
		S3‑191542	Discussion on Action Item 94/1	Samsung	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191753	IANA assigned values for mission critical	Motorola	LS out	Approval	Yes	Yes	approved	No
7.6.9	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑191321	Corrections on IP packet forwarding	Ericsson	CR	Agreement	Yes	YesMCC commented that Rel-14 and Rel-15 should be changed as well making this CR a mirror. Huawei warned about implications in GSMA's work (NISAs), given that they were using 33.117 and that could affect them. Huawei wanted more time in order to make sure that the Rel-14,Rel-15 didn’t have immediate impacts on the pilot testing.	revised	No	S3‑191632
		S3‑191632	Corrections on IP packet forwarding	Ericsson	CR	Agreement	Yes	YesThe changes of this CR were agreed and Ericsson will bring this CR again in the next meeting; also CRs for Rel-14 and Rel-15 in order to send them to SA as a pack provided that there were no impacts as requested by Huawei.	not pursued	No		S3‑191321
7.6.10	Security Aspects of Narrowband IOT (CIoT)	S3‑191153	Reply LS on UP Integrity Protection for Small Data in Early Data Transfer	R3-191116	LS in		Yes	YesRAN3 will be included in the response for RAN2 LS.	noted	No
		S3‑191140	Reply LS on EDT integrity protection	R2-1902439	LS in		Yes	Yes	replied to	No
		S3‑191247	CR for removing EDT UP IP solution using PDCP PDU hashes.	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑191633
		S3‑191259	Solution for integrity protection of UL EDT data	Intel Corporation (UK) Ltd	discussion	Decision	Yes	Yes	noted	No
		S3‑191440	Correction of ShortResumeMAC-I calculation for EDT	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑191633
		S3‑191633	Correction of ShortResumeMAC-I calculation for EDT	Ericsson,Huawei	CR	Agreement	Yes	Yes	agreed	No		S3‑191440
		S3‑191441	LS on integrity protection for EDT	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑191246	draft reply LS to RAN2/RAN3 on EDT UP IP	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑191634
		S3‑191634	Reply LS to RAN2/RAN3 on EDT UP IP	Huawei, Hisilicon	LS out	Approval	Yes	Yes	approved	No		S3‑191246
7.6.11	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)
7.6.12	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.6.13	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
7.6.14	PLMN RAT selection (Steering of Roaming) (Rel-15)
7.6.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑191172	Interface and protocol stack clarifications and corrections to TS 33.163	Juniper Networks	CR	Approval	Yes	YesVodafone: it is not 4 scenarios but three in here. Juniper: four scenarios in Rel-16.	revised	No	S3‑191635
		S3‑191635	Interface and protocol stack clarifications and corrections to TS 33.163	Juniper Networks	CR	Approval	Yes	Yes	agreed	No		S3‑191172
		S3‑191173	Interface and protocol stack clarifications and corrections to TS 33.163	Juniper Networks	CR	Approval	Yes	Yes	revised	No	S3‑191636
		S3‑191636	Interface and protocol stack clarifications and corrections to TS 33.163	Juniper Networks	CR	Approval	Yes	Yes	agreed	No		S3‑191173
		S3‑191174	Making UE initiated key refresh optional in TS33.163	Juniper Networks	CR		Yes	YesIt was queried whether there was work planned for Rel-16. Vodafone commented that a WID was planned for Rel-17. MCC reminded about the SA's statement on the use of TEI16 WID code and eventually the WID code for Rel-15 was also added in the cover page.	revised	No	S3‑191637
		S3‑191637	Making UE initiated key refresh optional in TS33.163	Juniper Networks	CR	-	Yes	Yes	agreed	No		S3‑191174
7.6.16	Other work items	S3‑191308	Deprecation of TLS 1.1	Ericsson	CR	Agreement	Yes	YesORANGE: why removing reference to RFC4366? Vodafone: add reference in TLS 1.2 in clause 6.2.3. Cover page needed to be fixed as well.	revised	No	S3‑191638
		S3‑191638	Deprecation of TLS 1.1	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑191308
		S3‑191309	Using EAP-TLS with TLS 1.3	Ericsson	discussion	Discussion	Yes	YesApple: editor's note to consider current discussions in IETF. Ericsson commented that this was a discussion paper and that the CR would come back in the next meeting. Huwaei received confirmation that this would be only for rel-16.	noted	No
		S3‑191310	References to several obsoleted RFCs	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑191311	TLS OCSP stapling	Ericsson	CR	Agreement	Yes	YesORANGE: this is a new feature, not a correction. Ericsson clarified that OSCP stapling referred to certificate signing in a way that the certificate authority didn’t need to be online. It was commented that Ericsson would come back with the same CR and an accompanying WID for the next meeting.	not pursued	No
		S3‑191312	References to several obsoleted RFCs	Ericsson	CR	Agreement	Yes	YesRelying on 1310 discussions.	agreed	No
7.7	New Work Item proposals	S3‑191288	WID on security of URLLC	Huawei, HiSilicon	WID new	Endorsement	Yes	Yes	revised	No	S3‑191725
		S3‑191725	WID on security of URLLC	Huawei, HiSilicon	WID new	Endorsement	Yes	Yes	agreed	No		S3‑191288
		S3‑191433	Discussion WID 5GS Vertical_LAN_SEC	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	Yes	noted	No
		S3‑191434	WID proposal for 5GS Vertical_LAN_SEC	Nokia, Nokia Shanghai Bell	WID new	Agreement	Yes	Yes	revised	No	S3‑191726
		S3‑191726	WID proposal for 5GS Vertical_LAN_SEC	Nokia, Nokia Shanghai Bell	WID new	Agreement	No	Yes	agreed	No		S3‑191434
8	Studies
8.1	Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)	S3‑191162	Reply LS on User Plane Security for 5GC Roaming	SP-190252	LS in		Yes	Yes	noted	No
		S3‑191588	User Plane Security for 5GC Roaming (re: S3-191016)	GSMA	LS in		Yes	Yes	noted	No
		S3‑191218	Discussion on N9 security	Deutsche Telekom AG, NTT Docomo	discussion	Endorsement	Yes	YesEricsson: why is this a discussion and not a key issue? We have an ongoing study.	noted	No
		S3‑191177	Discussion document on roaming UP gateway	Juniper Networks	discussion	Endorsement	Yes	YesEricsson: we should study this properly with direct contributions to the TR, instead of discussion papers. Hans (DT) commented that available solutions needed to be discussed and this is what was done in this paper. Ericsson: postpone this for the next meeting with conclusions and evaluations. There was support to endorse this paper so a revision number was given to reformulate the proposal.	revised	No	S3‑191666
		S3‑191666	Discussion document on roaming UP gateway	Juniper Networks	discussion	Endorsement	Yes	Yes	endorsed	No		S3‑191177
		S3‑191175	Corrections for Key Issue #27 Support of a UP gateway function on the N9 interface	Juniper Networks	pCR	Approval	Yes	Yes	approved	No
		S3‑191178	Solution for KI #27: Roaming UP gateway	Juniper Networks	pCR	Approval	Yes	Yes	merged	No	S3‑191661
		S3‑191219	Solution to KI #26: NDS/IP on the inter-PLMN N9 interface	Juniper Networks, Nokia	pCR	Approval	Yes	YesBT: add an editor's note on how the control plane enforces policy NDS/IP and N9 security. NTT-Docomo: not the control plane but the SMF who enforces the policy.	revised	No	S3‑191668
		S3‑191668	Solution to KI #26: NDS/IP on the inter-PLMN N9 interface	Juniper Networks, Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑191219
		S3‑191525	eSBA: Solution to KI #27 - UP Gateway function for protection of inter-PLMN N9 interface	Nokia, Nokia Shanghai Bell,Juniper	pCR	Approval	Yes	Yes	revised	No	S3‑191661
		S3‑191661	eSBA: Solution to KI #27 - UP Gateway function for protection of inter-PLMN N9 interface	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191525
		S3‑191299	Addition of SEPP requirement on N32 error handling	Deutsche Telekom AG, NTT Docomo	draftCR	Approval	Yes	YesIt was clarified that a WID was needed in order to have this eventually as a draftCR converted into a CR. Deutsche Telekom agreed to create a pCR with the key ssue and capture this in TR 33.855 (tdoc 669).	noted	No
		S3‑191469	Error handling for PLMN ID mismatch at SEPP	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesHuawei: we don’t include it in SCAS because it's purely for Rel-16. The SCAS WID is based on Rel-15 specifications. Vodafone: on the sentence about the receiving SEPP, this cannot be a "shall". NTT-Docomo: better say "shall support". Huawei: check CT4 specs for the error messages. Vodafone: we are not sending an error message to an attacker. It was questioned whether this was a draftCR since it was part of the study item. This had to be shaped to be inserted into the TR instead. It was decided finally to note the document.	noted	No
		S3‑191484	Discussion paper on Service access authorization for Indirect communication with delegated discovery (Model D)	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	Yes	noted	No
		S3‑191485	eSBA: Solution to KI #22 - Service access authorization for Indirect Communication with delegated discovery (Model D)	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson: different deployment scenarios should be considered. An editor's note was added about this.	revised	No	S3‑191671
		S3‑191671	eSBA: Solution to KI #22 - Service access authorization for Indirect Communication with delegated discovery (Model D)	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191485
		S3‑191490	eSBA: Solution to KI#22 - Service access authorization for Indirect Communication without delegated discovery (Model C)	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑191521	eSBA: Solution to KI #21: Protection of SeCoP interfaces	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑191523	eSBA: Solution to KI #23: NF to NF authentication and authorization in Indirect communications model	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑191672
		S3‑191672	eSBA: Solution to KI #23: NF to NF authentication and authorization in Indirect communications model	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesAdding editor's note on the different deployment scenarios. Added statement on key issue addressed.	approved	No		S3‑191523
		S3‑191403	Key issue on authorization for delegated "Subscribe-Notify" interaction scenarios	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: this is not written as a key issue. A key issue is not a study.	revised	No	S3‑191673
		S3‑191673	Key issue on authorization for delegated "Subscribe-Notify" interaction scenarios	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191403
		S3‑191404	New solution for delegated "Subscribe-Notify" interaction authorization	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191415	New KI: Access token sharing between NFs	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone didn't agree with the solution. Deutsche Telekom: the potential requirement is too weak.	noted	No
		S3‑191416	New solution for service access authorization within a NF Set	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: the text of the potential requirement does not have any relation to security.Deutsche Telekom and Nokia didn’t agree with this change either. The change was removed.	revised	No	S3‑191674
		S3‑191674	New solution for service access authorization within a NF Set	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191416
		S3‑191532	eSBA: NF Consumer authentication for based on signed API Request	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑191675	eSBA: NF Consumer authentication for based on signed API Request	Nokia, Nokia Shanghai Bell	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑191176	Solution to KI #26: NDS/IP on the inter-PLMN N9 interface	Juniper Networks	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑191183	On configurational error handling on N32 by the receiving SEPP	Deutsche Telekom AG	discussion	Endorsement	No	Yes	withdrawn	Yes
		S3‑191184	Addition of SEPP requirement on configurational error handling	Deutsche Telekom AG	draftCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑191667	Draft TR 33.855	Deutsche Telekom	draft TR	Approval	Yes	Yes	approved	No
		S3‑191669	Key issue of signalling between SEPP and IPX provider	Deutsche telekom	pCR	Approval	Yes	Yes	approved	No
8.2	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)
8.3	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
8.4	Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)	S3‑191295	Overview of TR33.856	China Unicom	CR		Yes	Yes	revised	No	S3‑191788
		S3‑191788	Overview of TR33.856	China Unicom	CR	-	Yes	Yes	agreed	No		S3‑191295
		S3‑191296	Content of clause 3 for TR33.856	China Unicom, CATT	CR		Yes	Yes	agreed	No
8.5	Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)	S3‑191561	Meeting minutes of AKMA conference calls	China Mobile	discussion	Information	Yes	Yes	not treated	No
		S3‑191537	Work Plan for moving forward AKMA	China Mobile	discussion	Endorsement	Yes	Yes	not treated	No
		S3‑191554	Editorial Changes to TR 33.835 v0.4.0	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑191213	Restoring lost figures in the latest draft update of AKMA TR at SA3 #94ah	NEC Europe Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑191479	Restore figures in Solution 3	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑191408	New KI: AKMA push	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191179	Update of solution #17 – Efficient key derivation for e2e security	KPN	pCR	Approval	Yes	Yes	not treated	No
		S3‑191211	Resolving Editor’s Notes and adding conclusion to solution #18 (Key Separation for AKMA AFs using counters)	NEC Europe Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑191212	Resolving Editor’s Notes and adding conclusion to solution #20 (Key Identification when Implicit bootstrapping is used)	NEC Europe Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑191290	Evaluation for solution 4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191386	Resovle Editor's notes in Solution for Key freshness in AKMA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191471	Solution 2 Evaluation	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑191472	Solution 3 Evaluation	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑191534	AKMA: Implicit bootstrapping using NEF as the AKMA Anchor Function	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑191548	Individual Evaluations of solution #7- #12	China Mobile	pCR		Yes	Yes	not treated	No
		S3‑191558	Individual Evaluation of solution #6	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑191187	AKMA solution set analysis	KPN	discussion	Discussion	Yes	Yes	not treated	No
		S3‑191540	Discussion on AKMA overall evaluation methodology	China Mobile, ZTE Corporation	discussion	Endorsement	Yes	Yes	not treated	No
		S3‑191545	pCR of clause 7- evaluation and conclusion	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑191210	Discussion on AKMA overall conclusions	NEC Europe Ltd	discussion	Endorsement	Yes	Yes	not treated	No
		S3‑191544	pCR of clause 7- evaluation and conclusion	China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑191546	pCR of clause 7- evaluation and conclusion	China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑191557	Individual Evaluation of solution #6	China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
8.6	Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)	S3‑191435	CIoT: Definitions and Abbreviations	Ericsson	pCR	Approval	Yes	YesVodafone: Some of these are already in 21.905. NTT-Docomo: there may be other acronyms that can be added here.	revised	No	S3‑191676
		S3‑191676	CIoT: Definitions and Abbreviations	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑191435
		S3‑191229	New KI: Separation of CP and UP in NAS CP Optimization	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesNokia admitted that this issue could be late for this Release and asked if it was to be pushed for the next release. Vodafone: this doesn’t seem to be a security issue. Qualcomm had the same concern. If CT groups had a problem with this they should contact SA3. CableLabs: this can cause denial of service. I agree with this key issue. Vodafone understood the idea but didn’t agree with the writing. Qualcomm: SA2 decided not to procceed with this one. ORANGE didn’t agree with this key issue. This was taken offline.	noted	No
		S3‑191248	EDT UP IP for multiple PDCP PDUs	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191249	update solution#4 with UP IP during EDT for multiple PDCP PDUs.	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: split into two separate solutions. Overlapping with 437. Huawei: we are not bringing another solution, just details for an existing solution.	revised	No	S3‑191678
		S3‑191678	update solution#4 with UP IP during EDT for multiple PDCP PDUs.	Huawei, Hisilicon	pCR	Approval	Yes	YesIt was agreed to fix a typo and replace gNodeB.	approved	No		S3‑191249
		S3‑191437	CIoT: Update to Solution #4	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑191679
		S3‑191679	CIoT: Update to Solution #4	Ericsson	pCR	Approval	Yes	YesRevised as a completely new solution. Editors note from Qualcomm. Reformulation from Vodafone.	approved	No		S3‑191437
		S3‑191436	CIoT: Evaluation to Solution #4	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191180	Update of Solution #6 – Use of UE Configuration Update	KPN	pCR	Approval	Yes	YesEditor's note on maximum amount of minutes as proposed by Vodafone. Vodafone: more likely that it's an malicious application. Evaluation part was removed.	revised	No	S3‑191680
		S3‑191680	Update of Solution #6 – Use of UE Configuration Update	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑191180
		S3‑191252	Updating solution#7	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: this needs rewording. Ericsson: other Ues can take turns when attacking. Huawei: it's an engineering issue. Vodafone: there is no way of permanently block a misbehaving UE. Huawei: the gNodeB informs the core network to do something about it and we don’t specify more than that.	revised	No	S3‑191681
		S3‑191681	Updating solution#7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191252
		S3‑191510	Resolving EN in Solution 9	Qualcomm Incorporated	pCR	Approval	Yes	YesVodafone: very confusing. Not an outstanding issue since it will be treated in Rel-16 as written here. Huawei: this CIoT activity depends on SA2's agreements and here it seems that we deviating from that. This needed reformulating and Huawei wanted to include a reference to the work in SA2.	revised	No	S3‑191682
		S3‑191682	Resolving EN in Solution 9	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei commented and asked to be minuted: "All solutions which include short UP packets in NAS messages, e.g., Registration Request, Registration Complete, etc. depend on SA2 decision"	approved	No		S3‑191510
		S3‑191511	Resolving EN in Solution 10	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑191683
		S3‑191683	Resolving EN in Solution 10	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑191511
		S3‑191365	Delete EN in solution12	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: time limit to the filters?An editor's note was added for this. Reference to the relevant spec in SA2 in step 4 was added.	revised	No	S3‑191684
		S3‑191684	Delete EN in solution12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191365
		S3‑191366	Add evalution in solution12	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: reformulate the last two sentences. Ericsson: If PDU sessions are not terminated the network will keep the PDU sessions open and this would be a waste or resources. In the end Ericsson conceded and the revision only took care of the rewording.	revised	No	S3‑191685
		S3‑191685	Add evalution in solution12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191366
		S3‑191189	Proposal for improvement FS_CIoT_sec_5G solution #15	Philips International B.V.	pCR	Approval	Yes	Yes	revised	No	S3‑191686
		S3‑191686	Proposal for improvement FS_CIoT_sec_5G solution #15	Philips International B.V.	pCR	Approval	Yes	Yes	approved	No		S3‑191189
		S3‑191188	Proposal for editor's notes in FS_CIoT_sec_5G solution #15	Philips International B.V.	pCR	Approval	Yes	YesVodafone: this needs rewriting. Qualcomm suggested an editor's note. Vodafone wanted a statement in the evaluation on injected first messages. MCC added that the use of "must" was not allowed in 3GPP and it needed rewording.	revised	No	S3‑191687
		S3‑191687	Proposal for editor's notes in FS_CIoT_sec_5G solution #15	Philips International B.V.	pCR	Approval	Yes	Yes	approved	No		S3‑191188
		S3‑191388	Resolve ENs on Solution to Mitigate DDoS Attack based on RAN	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone didn’t agree with the term "massive misbehaving infrequent CIOT Ues". Huawei replied that this was coming from SA2. Vodafone: how do you get out of the blacklist? Huawei: there is a timer. Vodafone: this timer doesn’t appear in here. The blacklist applies to a collection of Ues and not a single UE. The timer applies to which UE? The first one? An editor's note was added to address this.	revised	No	S3‑191688
		S3‑191688	Resolve ENs on Solution to Mitigate DDoS Attack based on RAN	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191388
		S3‑191389	Solution to Mitigate DDoS Attack based on RAN Caused by Massive Misbehaving Frequent CIoT Ues	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: now the CIoT Ues are frequent, whereas in other contributions they were infrequent.Huawei replied that this was to be reworded like in the previous contribution and that the term "frequent" was coming from SA2.	merged	No	S3‑191688
		S3‑191390	Solution to Mitigate DDoS Attack on AMF caused by Massive Misbehaving Infrequent CIoT Ues	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191689
		S3‑191689	Solution to Mitigate DDoS Attack on AMF caused by Massive Misbehaving Infrequent CIoT Ues	Huawei, Hisilicon	pCR	Approval	Yes	YesWording changes as proposed by Vodafone.	approved	No		S3‑191390
		S3‑191438	CIoT: Conclusion to KI#2 and KI#3	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191234	conclusion on KI#5	Huawei, Hisilicon	pCR	Approval	Yes	YesIt was queried whether anyone was going to bring another solution. Ericsson preferred to postpone this for the next meeting.	noted	No
		S3‑191677	Draft TR 33.861	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
8.7	Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)	S3‑191123	LS on SUPI formats for 5WWC	C1-192776	LS in		Yes	Yes	noted	No
		S3‑191139	Response to 3GPP SA2 liaison S2-1902902 on ‘LS on updating the status of 5WWC normative work’	BBF	LS in		Yes	Yes	noted	No
		S3‑191586	Residential use case for 5G Core with fixed broadband access	CableLabs	LS in		Yes	Yes	noted	No
		S3‑191193	New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC	CableLabs	pCR	Approval	Yes	Yes	revised	No	S3‑191702	S3‑191192
		S3‑191702	New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC	CableLabs	pCR	Approval	Yes	Yes	noted	No		S3‑191193
		S3‑191138	Reply LS on Authentication for UEs not Supporting NAS	S2-1904829	LS in		Yes	Yes	replied to	No
		S3‑191713	Reply LS on Authentication for UEs not Supporting NAS	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑191221	Discussion on proposed response to incoming LS (S3-191138) on authentication of UEs not supporting NAS	Charter Communications, CableLabs	discussion	Discussion	Yes	YesOn question one: ORANGE: stick to what is written in TS 33.501. There are statements here that don’t adhere to what is in the spec. Ericsson: it is not sufficient because it is a Rel-15 spec and this is new material for Rel-16. BT didn’t agree, it's the storage what matters. Telecom Italia: SA2's interest lies in TS 33.501 annex B only. Cablelabs replied that there was a key issue on 5WWC. Charter communications: consider the Rel-16 context only, not Rel-15. AT&T: use the EAP framework if you want to use the 3GPP network. Charter Communications: this is cable access, not 3GPP access. ORANGE: if the use case is similar for non-public networks it is perfectly fine to use annex B of TS 33.501. In 5WWC the case is different. Nokia: is it possible for 3GPP to support this in Rel-16? Vodafone: Non private networks should not be in the scope of this TR, otherwise we will have a whole range of new use cases that will blur the security. Charter: Non public networks is another WID that doesn’t cover fixed access. Telecom Italia: 5WWC should not just use annex B, they need to stick to the TR. This had to be taken offline.	revised	No	S3‑191703
		S3‑191703	Discussion on proposed response to incoming LS (S3-191138) on authentication of UEs not supporting NAS	Charter Communications, CableLabs	discussion	Discussion	No	Yes	noted	No		S3‑191221
		S3‑191318	New Key Issue: SUCI-to-SUPI mapping for the FN-RG	Ericsson	pCR	Approval	Yes	YesORANGE: replace visited network by serving network since are not covering roaming now. Telecom Italia: How is the SUCI computed in the Home gateway if it doesn’t have an UICC? Ericsson replied that it wasn't computed by the home gateway but somewhere else in the network. Telecom Italia: potential architecture requirement instead of a security requirement? Ericsson SUCI to SUPI mapping is in our scope and we need to tell SA2 about this. Telecom Italia suggested that this had to be described as a security requirement, with a threat and so on. Vodafone agreed. Vodafone: the key issue is the mapping of SUCI to SUPI. The security threat was not related and scrapped from here.	revised	No	S3‑191690
		S3‑191690	New Key Issue: SUCI-to-SUPI mapping for the FN-RG	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑191318
		S3‑191319	New Solution: SUCI-to-SUPI mapping for the FN-RG	Ericsson	pCR	Approval	Yes	YesNokia: the mapping is not explained. Huawei: a similar figure is available in the TR (solution #4) and there is a bunch of editor's notes in there as well. This solution exists already.Bring this back in the next meeting detailing the mapping. Nokia supported this.	noted	No
		S3‑191371	Add introduction part	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: the introduction is not needed. MCC: the first two sentences are in fact the scope of the document. Only the reference part stays.	revised	No	S3‑191706
		S3‑191706	Add references	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191371
		S3‑191372	Add content to clause 4	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: refer to relevant SA2 specs. Nokia: refer to all possible scenarios.	revised	No	S3‑191707
		S3‑191707	Add content to clause 4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191372
		S3‑191373	Delete Editor's Note in KI#4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191708
		S3‑191708	Delete Editor's Note in KI#4	Huawei, Hisilicon	pCR	Approval	Yes	YesThe requirement was removed since the security of the nterface was not in the scope of the document.	approved	No		S3‑191373
		S3‑191374	Add requirement and delete EN for KI#13	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191709
		S3‑191709	Add requirement and delete EN for KI#13	Huawei, Hisilicon	pCR	Approval	Yes	YesRemoving the e.g. as proposed by Ericsson.	approved	No		S3‑191374
		S3‑191375	Delete one Editor’s Note in solution3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191376	Delete EN for solution 5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191317	New Solution: Transport security for the interfaces between W-5GAN and 5GC	Ericsson	pCR	Approval	Yes	YesHuawei: simplify the content, no need to list every interface.	approved	No
		S3‑191377	Add conclusion on KI#3	Huawei, Hisilicon	pCR	Approval	Yes	YesTelecom Italia: getting to a solution without an evaluation?	revised	No	S3‑191711
		S3‑191711	Add conclusion on KI#3	Huawei, Hisilicon	pCR	Approval	Yes	YesFirst paragraph: reference to the solution. Second paragraph is gone as proposed by Nokia.	approved	No		S3‑191377
		S3‑191378	Add Conclusion on KI#4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191486	Evaluation of Solution #1	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	revised	No	S3‑191712
		S3‑191712	Evaluation of Solution #1	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑191486
		S3‑191192	New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC	CableLabs	pCR	Approval	Yes	Yes	revised	No	S3‑191193
		S3‑191710	Draft TR 33.807	Huawei	draft TR	Approval	Yes	Yes	approved	No
8.8	Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)	S3‑191527	Providing some evaluation for solution #2 in TR 33.815	Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑191593
		S3‑191528	Proposed conclusion for establishing the RLOS call	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑191594
		S3‑191541	pCR to 33.815 on authentication of network	NTT DOCOMO	pCR	Approval	Yes	YesQualcomm: this assumes that the user has an active USIM, but this is not what's happening in SA1.SA2. They didn’t agree with the key issue. Sony supported Qualcomm. ORANGE supported the requirement. Vodafone: how do you identify that you are an US person without credentials?Only US customers would expect this service. Vodafone supported this key issue. Deutsche Telekom wanted to have this key issue as well. There was a big risk of weakening the security to satisfy a specific issue for US customers. Ericsson: this key issue is against the PARLOS concept. IDEMIA supported the key issue. Nokia: this is written with the assumption that this will be an universal feature, and this is not the way it should be addresses. I don’t agree with the key issue. Samsung supported this. NTT-Docomo: International (non-US) customers would have to deal with the fact that they will possess an UE vulnerable to man-in-the-middle attacks. BT supported Docomo. There was no agreement with this document.	noted	No
		S3‑191550	Clarification to Solution#1 of PARLOS	Samsung	pCR	Approval	Yes	YesVodafone: any authentication in the PARLOS network here? Samsung: it's just an update on an existing procedure. Vodafone wasn't sure that this would work technically. ORANGE: evaluation needs to be updated, add it here. Maybe add a note on the technical feasbility of this solution.	noted	No
		S3‑191727	Clarification to Solution#1 of PARLOS	Samsung	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑191593	Providing some evaluation for solution #2 in TR 33.815	Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd	pCR	Approval	Yes	YesBT: no need for man in the middle. The attacker can just call asking the user to make a call to to PARLOS. Qualcomm: it doesn’t need to be an RLOS number, it can be a premium number or whatever. Vodafone:add an editor's note on the hability of the user to identify the trust of the PARLOS network needing to be provided. NTT-Docomo: paragraph three needs to go away.	revised	No	S3‑191728	S3‑191527
		S3‑191728	Providing some evaluation for solution #2 in TR 33.815	Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd	pCR	Approval	Yes	Yes	approved	No		S3‑191593
		S3‑191594	Proposed conclusion for establishing the RLOS call	Qualcomm Incorporated, Ericsson, Verizon UK Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑191595	S3‑191528
		S3‑191595	Proposed conclusion for establishing the RLOS call	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd	pCR	Approval	Yes	Yes	noted	No		S3‑191594
		S3‑191729	Draft TR 33.815	Qualcomm	draft TR	Approval	Yes	Yes	approved	No
8.9	Study on 5G security enhancement against false base stations	S3‑191391	Solution for Protection of RRCReject Message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191393	Add New Security Threat and Requirement for Key Issue #1 for Protection of NAS Reject Message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191789
		S3‑191789	Add New Security Threat and Requirement for Key Issue #1 for Protection of NAS Reject Message	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson didn’t agree with the requirement, so an editor's note was added as suggested bu NTT-Docomo.	approved	No		S3‑191393
		S3‑191392	Solution for Protection of NAS Reject Message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191240	Secuirty threat for RRCResumeRequest tampering.	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191241	Solution for protecting RRCResumeRequest against tampering	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191242	Address EN in solution #1 “The above text needs to be updated ….”	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191243	Draft LS to RAN2 on UECapabilitiesEnquire after AS SMC	Huawei, Hisilicon	LS out	Approval	Yes	Yes	not treated	No
		S3‑191345	Protection of unicast message	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑191620
		S3‑191620	Protection of unicast message	Apple Computer Trading Co. Ltd	pCR	Approval	No	YesQualcomm added three editor's notes related to the key provisioning from 781 and one on camping. ORANGE also added some editor's notes and corrections.	approved	No		S3‑191345
		S3‑191454	New solution (SERSI - SERving network controlled SI signatures) - builds on Solution#7	Ericsson	pCR	Approval	Yes	YesApple: to be merged to solution 7. Add an editor's note on the assesment of this. Qualcomm, ORANGE: we need to reformat the existing solution. Samsung,Intel supported the editor's note in order to move forward. ORANGE wanted to restructure the contribution firstly. AT&T supported having this in. Ericsson: merge with solution 7, there are 10 companies supporting this. AT&T: reformatting is editorial, there is no technical justification against this. CableLabs supported AT&T. Telecom Italia was against having this in. The vice chair (Docomo) proposed to minute: This type of solution should go in but it needs to come back with the proper formatting according to Annex A. There was opposition to the formatting but a general agreement to the solution. The vice chair encouraged to discuss offline on this document and noted it.	noted	No
		S3‑191195	Using symmetric algorithm with assistance of USIM and home network	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑191508	Shared key based MIB/SIB protection	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑191780
		S3‑191780	Shared key based MIB/SIB protection	Qualcomm Incorporated	pCR	Approval	Yes	YesAdding an editor's note as proposed by Huawei.	approved	No		S3‑191508
		S3‑191267	Certificate based solution for 5GFBS	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑191781
		S3‑191781	Certificate based solution for 5GFBS	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	YesIntroducing editor's notes as proposed by ORANGE: roaming aspects, MNO controlling the revocation of CA, other signature algorithms are FFS. Qualcomm: issue of camping needs to be clarified.Editor's note on this was added. Also editor's notes on the manufacturing time, interworking with UE USIM and gNodeB.	approved	No		S3‑191267
		S3‑191268	ID based solution for 5GFBS	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	YesORANGE: Threats are not mitigated with signed messages,roaming scenarios are FFS. Qualcomm: PKG deployment is FFS. MCC: add references to IEEE, RFC, ISO SC27 and other mentioned bodies.	revised	No	S3‑191782
		S3‑191782	ID based solution for 5GFBS	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	Yes	approved	No		S3‑191268
		S3‑191235	Resolve EN "signaling details of how the UE hands over to false base station	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191236	Solution #6: Resolve EN Handover Attemp Failure Counter	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191237	Solution#4: resolving EN network verification of the hashes of MIB/SIBs	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191238	Solution#4: Resolving EN Impact on UE power consumption	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191239	Solution #4: Details on the hash algorithm used for MIB/SIB hashes.	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191251	Enabling UE to detect FBS	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191455	Conclusion on KI#3'S second requirement (reactive action)	Ericsson	pCR	Approval	Yes	YesHuawei: too early.	noted	No
		S3‑191464	Resolving the ENs in solution #5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191488	Mitigation against the authentication relay attack with different PLMNs	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesEricsson: indications in the victim (UE) may or may not be standardised. An editor's note was added for this. Qualcomm: general error handling on the UE may be affected. Editor's note added on this.	revised	No	S3‑191790
		S3‑191790	Mitigation against the authentication relay attack with different PLMNs	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑191488
		S3‑191489	Removal of Editor’s Notes of Solution #5	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	not treated	No
		S3‑191509	Security requirement for KI #7	Qualcomm Incorporated	pCR	Approval	Yes	YesEricsson,Huawei: this is not a requirement, but an evaluation.	noted	No
		S3‑191256	Protecting IOT Devices Against False Base Station Attacks	Qihoo 360	discussion	Discussion	Yes	YesDeutsche Telekom: what's the proposal to endorse? Qihoo: just for discussion. Apple: we can have key issues for these kind of devices. Huawei: we don’t know if this has any impact on our study. CableLabs: capture this content somewhere, it's a good input. The Chair suggested Qihoo360 to bring a pCR for the next meeting or some endorsement proposal. Huawei proposed a key issue for the CIoT study.	noted	No
		S3‑191269	Modification for AnnexA	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑191347	Way forward for evaluation for every solution	Apple Computer Trading Co. Ltd	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191344	Identity based Signature against false base station on Key Issue #2	Huawei, HiSilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑191779	Draft TR 33.809	Apple	draft TR	Approval	No	Yes	left for email approval	No
8.10	Study of KDF negotiation for 5G System Security
8.11	Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)	S3‑191227	eNS Update to solution 1 Slice specific secondary authentication	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesHuawei: some issues that were agreed not to have here are coming back: secondary authentication in step 11 for example. We should use the term "slice specific authentication". Huawei: this doesn’t address key issue 4 (privacy), remove it from the evaluation. Nokia: NAS messages are protected already, no parameter is exposed. ORANGE and Qualcomm agreed: adding a sentence clarifying this would be sufficient. Gemalto: the requirement doesn't show explicit end points, only addresses the privacy of the user.	revised	No	S3‑191730
		S3‑191730	eNS Update to solution 1 Slice specific secondary authentication	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191227
		S3‑191328	Removing ENs for solution #2	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191732
		S3‑191732	Removing ENs for solution #2	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191328
		S3‑191329	Add Evaluation to Solution #2	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191733
		S3‑191733	Add Evaluation to Solution #2	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191329
		S3‑191322	Update to solution #3 on NSaaS security features	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: the new text is not clear. ORANGE: secondary authentication is ortogonal to the slices, why is this here?When you configure the secondary authentication you don’t know to which external network you are connecting to. Qualcomm agreed with ORANGE. Secondary authentication is a different issue from slice specific authentication.	noted	No
		S3‑191323	Conclusion to KI #3	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: it's too early to conclude, some other companies might come back with other solutions.	noted	No
		S3‑191118	Update to solution #4	InterDigital Belgium. LLC	pCR	Approval	Yes	YesNokia: clarify the dependency between the RAT and access type.The document was revised to address this.	revised	No	S3‑191734
		S3‑191734	Update to solution #4	InterDigital Belgium. LLC	pCR	Approval	Yes	Yes	approved	No		S3‑191118
		S3‑191326	Solution to KI #4	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: What is this solution about and what is being protected? This is not a new solution. Qualcomm:this doesn’t add any value. There is no requirement to protect the user id between the UE and the AAA; we would need to revisit the key issue. Qualcomm proposed to add an editor's note on the above. This was agreed. The evaluation was removed as well.	revised	No	S3‑191735
		S3‑191735	Solution to KI #4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191326
		S3‑191327	Conclusion to KI #4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191331	Discussions on Key Issue AMF key separation	Huawei, HiSilicon	discussion	Agreement	Yes	YesNokia disagreed witht the key issue. The Chair commented that this was discussed in the previous meeting and it had been seen that SA2 pushed this issue to Rel-17. ORANGE: this issue was out of scope in SA2 and they didn’t agree with any solution. Huawei is making an invalid interpretation. Nokia: the UE cannot connect to two AMF at the same time. The figure is wrong. Huawei proposed an LS to SA2 if there was no agreement with this paper. ORANGE agreed to ask SA2 if this had been pushed to Rel-17. Qualcomm replied that they had checked the SA2 report and this had been pushed to Rel-17. Huawei disagreed and commented that they had a different interpretation. There wasn't support for the LS. This discussion was noted and all the related documents.	noted	No
		S3‑191332	Overview on solutions to AMF key separation	Huawei, HiSilicon	discussion	Agreement	Yes	Yes	noted	No
		S3‑191333	pCR on AMF key separation solutions solution 1	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191334	pCR on AMF key separation solutions solution 2	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191335	pCR on AMF key separation solutions solution 3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191325	Discussion paper on KI#6 on NSSAI in RRC	Huawei, HiSilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑191324	A solution to NSSAI protection at AS transmission	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: How the authorised NSSAI for the UE is configured in the serving network needs more details. This was added in an editor's note.	revised	No	S3‑191736
		S3‑191736	A solution to NSSAI protection at AS transmission	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191324
		S3‑191439	Solution to protect user ID over the air interface	Ericsson	pCR	Approval	Yes	YesEditor's note added on protection is needed between serving network to AAA server. Secondary authentication was changed to slice specific authentication. Lenovo proposed to remove the evaluation part. This was agreed.	revised	No	S3‑191738
		S3‑191738	Solution to protect user ID over the air interface	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑191439
		S3‑191499	Proposed solution for protecting the S-NSSAI for transmission at the AS layer	Qualcomm Incorporated	pCR	Approval	Yes	YesIt was agreed to include the same editor's note as 736.	revised	No	S3‑191737	S3‑190791
		S3‑191737	Proposed solution for protecting the S-NSSAI for transmission at the AS layer	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑191499
		S3‑191360	pCR to TR33.813 - Key issue for deeper UP protection termination	CATT	pCR		Yes	YesNokia: this is not relevant to Rel-16, maybe for Rel-17. CATT: this is required by the market. Telecom Italia: SA1 addresses this kind of use cases, not here. ORANGE: SA1 should not go into security requirements. ORANGE: we need to control the UPF due to lawful interception requirements. This is material for a new study item. CATT: we wanted to know if this was feasible work for the future.	noted	No
		S3‑191361	pCR to TR33.813 - Key issue for UP key separation	CATT	pCR		Yes	YesTelecom Italia: this input should start from an SA1 requirement. ORANGE: we need a discussion paper with more details.	noted	No
		S3‑191362	pCR to TR33.813 - Solution for UP key separation	CATT	pCR		Yes	Yes	noted	No
		S3‑191228	Preliminary comparison of solutions	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesNokia clarified that this reflected results before the current meeting. The Chair asked if conclusions should be postponed to the next meeting. Telecom Italia: "not applicable" means no solution? Nokia confirmed this. The table was revised to address the results from the current meeting. Qualcomm: it shouldn't be a conclusion but in an annex. Nokia: the conclusion text should follow this. An overall evaluation clause was added to the conclusion in order to accommodate this table.	revised	No	S3‑191739
		S3‑191739	Preliminary comparison of solutions	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191228
		S3‑191330	Conclusion to KI #1	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: the conclusion needs to be expanded.	noted	No
		S3‑191731	Draft TR 33.813	Nokia	draft TR	Approval	Yes	Yes	approved	No
8.12	Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)	S3‑191141	LS on RAN2 conclusion for NR positioning SI	R2-1902479	LS in		Yes	Yes	replied to	No
		S3‑191142	LS on RAN2 conclusion for NR positioning SI	R3-191141	LS in		Yes	Yes	noted	No
		S3‑191442	Discussion on RAN2 conclusion for NR positioning SI	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191350	LS reply to RAN WG2 LS on broadcast assistance data delivery	CATT	LS out		Yes	Yes	noted	No
		S3‑191443	LS on security and privacy aspects of NR positioning	Ericsson	LS out	Approval	Yes	Yes	revised	No	S3‑191750
		S3‑191750	LS on security and privacy aspects of NR positioning	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑191443
		S3‑191364	Reply LS on RAN2 conclusion for NR positioning	Huawei, Hisilicon	pCR	Approval	Yes	YesIntel supported this response. CATT wasn't convinced with the physical risk.Qualcomm agreed with this, they preferred to wait for RAN's progress. Huawei: we do have requirements for a secure environment and we should tell them about them. It was agreed that SA3 needed to wait for RAN's progress in this work. CATT: RAN will finish this work in December, our work item will be really delayed.	noted	No
		S3‑191351	pCR to TR33.814 - Key issue for confidentiality protection of broadcast assistance data	CATT	pCR		Yes	YesQualcomm: we already agreed in the LS in tdoc 600 for a solution for this.	noted	No
		S3‑191353	pCR to TR33.814 - Key issue for integrity protection of broadcast assistance data	CATT	pCR		Yes	Yes	revised	No	S3‑191602
		S3‑191602	pCR to TR33.814 - Key issue for integrity protection of broadcast assistance data	CATT	pCR	-	Yes	YesSame as tdoc 351. This was already addressed in tdoc 600.	noted	No		S3‑191353
		S3‑191297	Key issue for encryption of broadcast assistance data in eLCS	CAICT, China Unicom	pCR		No	Yes	withdrawn	Yes
		S3‑191298	Key issue for encryption of broadcast assistance data in eLCS	CAICT, China Unicom	pCR		Yes	Yes	noted	No
		S3‑191352	pCR to TR33.814 - Key issue for distribution of assistance data ciphering key	CATT	pCR		Yes	YesQualcomm: SA2 has decided to do the same for the 5G system in Rel-16. This is not needed.	noted	No
		S3‑191354	pCR to TR33.814 - Key issue for the security architecture of eLCS	CATT	pCR		Yes	Yes	noted	No
		S3‑191349	pCR to TR33.814 - Key issue for security aspect of eLCS architecture enhancement	CATT	pCR		Yes	YesEricsson commented that it was better to bring this back in a later stage.	noted	No
		S3‑191363	Address EN in key issue 4	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia didn't know what the role of the AMF was in the enforcement of the privacy. ORANGE didn’t understand the meaning of privacy control here, but since it was part of existing text of the specification they withdrew their comment. Qualcomm didn’t agree with the AMF/UE enforcing the privacy control.	noted	No
		S3‑191368	Address EN and update in key issue 5	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia and Ericsson had concerns on the requirements so the editor's note came back.	revised	No	S3‑191754
		S3‑191754	Address EN and update in key issue 5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191368
		S3‑191190	New solution to key issue 5 in TR 33.814 (FS_eLCS_Sec): UE faking/altering location measurements	Philips International B.V.	pCR	Approval	Yes	YesORANGE: there are no requirements.	noted	No
		S3‑191369	A solution to prevent from providing faked/altered location estimate	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191355	pCR to TR33.814 - Solution of ciphering algorithms	CATT	pCR		Yes	Yes	noted	No
		S3‑191356	pCR to TR33.814 - Solution of provisioning keys for broadcast assistance data protection	CATT	pCR		Yes	Yes	noted	No
		S3‑191358	pCR to TR33.814 - The solution for the distribution of broadcast assistance data deciphering key	CATT	pCR		Yes	Yes	noted	No
		S3‑191359	pCR to TR33.814 - The analysis of security architecture of eLCS	CATT	pCR		Yes	YesCATT proposed to move the content to clause 4. Qualcomm and Ericsson commented on the figure and CATT agreed to bring this back in the next meeting.	noted	No
		S3‑191470	Update to Solution#4 Enhance privacy control in LCS	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑191755	Draft TR 33.814	CATT	draft TR	Approval	Yes	Yes	approved	No
8.13	Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)	S3‑191281	Reference part	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191284	Delete the EN of Introduction	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191285	Abbreviations	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191215	Evaluation and text for resolving editor’s note for solution #5 in TR 33.825	NEC Europe Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑191723
		S3‑191723	Evaluation and text for resolving editor’s note for solution #5 in TR 33.825	NEC Europe Ltd,Huawei	pCR	Approval	No	Yes	noted	No		S3‑191215
		S3‑191286	Delete the EN of solution 5	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191724
		S3‑191724	Delete the EN of solution 5	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191286
		S3‑191507	Evaluation of solution #5: Security for redundant data transmission	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑191274	Evaluation for solution 5	Huawei, HiSilicon	pCR	Approval	Yes	Yes	merged	No	S3‑191723
		S3‑191283	Adding the key issue details and threats for KI #1	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191279	Deleting EN of solution 4	Huawei, HiSilicon	pCR	Approval	Yes	YesMCC commented that the introduction could not have normative requirements and proposed to reformulate the paragraph in present tense removing the shall and "it is required".	revised	No	S3‑191757
		S3‑191757	Deleting EN of solution 4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191279
		S3‑191280	Evaluation for solution 4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191758
		S3‑191758	Evaluation for solution 4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191280
		S3‑191277	Deleting the EN of solution 3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191759
		S3‑191759	Deleting the EN of solution 3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191277
		S3‑191275	Evaluation for solution 3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191278	Adding more clarification text of solution 7	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191760
		S3‑191760	Adding more clarification text of solution 7	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191278
		S3‑191477	Solution #7 evaluation	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑191287	Evaluation for solution 6	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson: solution 6 is out of scope. Delete the evaluation.	revised	No	S3‑191761
		S3‑191761	Evaluation for solution 6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191287
		S3‑191474	URLLC: Resolving EN in solution #8	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑191742
		S3‑191742	URLLC: Resolving EN in solution #8	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑191474
		S3‑191475	URLLC: Evaluation to solution #8	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑191762
		S3‑191762	URLLC: Evaluation to solution #8	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑191475
		S3‑191506	Missing implementation of S3-190797: Conclusion on KI #8 for Study on the security for URLLC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑191276	Security solutions summary	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson: where to put this table?	revised	No	S3‑191763
		S3‑191763	Security solutions summary	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191276
		S3‑191270	Conclusion for key issue 1	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson: remove solution 5.	revised	No	S3‑191764
		S3‑191764	Conclusion for key issue 1	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191270
		S3‑191271	Conclusion for key issue 2	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191478	Conclusion to KI#1 and KI#2	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191272	Conclusion for key issue 3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191476	URLLC: Recommendation for KI#3	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191273	Conclusion for key issue 4	Huawei, HiSilicon	pCR	Approval	Yes	YesBT: we need to check the relation with the SA2 specification. Add an editor's note. Ericsson: we don’t agree with solution 3 part. This was removed.	revised	No	S3‑191765
		S3‑191765	Conclusion for key issue 4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191273
		S3‑191282	Way forward of FS_5G_URLLC security study	Huawei, HiSilicon	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑191756	Draft TR 33.825	Huawei	draft TR	Approval	Yes	Yes	approved	No
		S3‑191787	Cover sheet TR 33.825	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
8.14	Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)	S3‑191526	Scope of a SECAM SCAS for 3GPP virtualized network products	China Mobile, CAICT	pCR		Yes	Yes	not treated	No
		S3‑191530	Scope of SECAM evaluation for 3GPP virtualized network products	China Mobile, CAICT	pCR	Approval	Yes	Yes	not treated	No
		S3‑191531	Scope of SECAM Accreditation for 3GPP virtualized network products	China Mobile, CAICT	pCR	Approval	Yes	Yes	not treated	No
		S3‑191533	Adding roles in SECAM for 3GPP virtualized network products into clause 4.6	China Mobile, CAICT	pCR	Approval	Yes	Yes	not treated	No
		S3‑191535	Adding contents into clause 4	China Mobile, CAICT	pCR	Approval	Yes	Yes	not treated	No
8.15	Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)	S3‑191425	Solution and Conclusion on 5GLAN authentication	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesMCC reminded to add the references of the named specifications (e.g. 33.501) in clause 2 of the next draft TR.	approved	No
		S3‑191426	Solution on SMF handling the UP security policy for a 5GLAN Group	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑191427	Solution and conclusion for TSC	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesTaken offline to express that the authentication procedure in 33.501 is to be followed.	revised	No	S3‑191767
		S3‑191767	Solution and conclusion for TSC	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191427
		S3‑191106	Discussion on possible privacy/confidentiality attacks in PLMN integrated NPN	InterDigital	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191553	Resolution of Editor’s note on privacy impact in Solution #3	Samsung	pCR	Approval	Yes	Yes	revised	No	S3‑191768
		S3‑191768	Resolution of Editor’s note on privacy impact in Solution #3	Samsung	pCR	Approval	Yes	YesEditor's note was finally kept.	approved	No		S3‑191553
		S3‑191592	Comment on contribution S3-191553	InterDigital Belgium. LLC	discussion	Discussion	Yes	Yes	noted	No
		S3‑191596	New KI for PLMN integrated NPN	InterDigital Germany GmbH	pCR	Approval	Yes	YesThere was no agreement with the security threats and requirements.	revised	No	S3‑191769	S3‑191107
		S3‑191769	New KI for PLMN integrated NPN	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	approved	No		S3‑191596
		S3‑191597	New KI for Public network integrated NPN	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	revised	No	S3‑191770	S3‑191164
		S3‑191770	New KI for Public network integrated NPN	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	approved	No		S3‑191597
		S3‑191233	Non-AKA based EAP methods with credentials stored and processed in UDM/ARPF	CableLabs	pCR	Approval	Yes	YesORANGE didn’t agree with the key issue. The key hierarchy key issue is already covered somewhere else. Qualcomm argued that the use case was supported by the Rel-15 frameork	noted	No
		S3‑191428	Key issue on PNiNPN authentication	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson didn’t see the threat clearly. ORANGE: the security requirements don’t match because you can access the NPN networks without authenticating, you cannot mandate authentication. Qualcomm: we should close the TR without adding more key issues. Nokia: we want to close on this key issue. Telecom Italia: the solution should not exist. No support for this document, hence it was noted.	noted	No
		S3‑191429	Solution and evaluation for PNiNPN authentication	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE: not needed. We should not put material from our specifications in the TRs. This is exisitng already.	noted	No
		S3‑191339	Discussion on Architecture of PLMN integrated NPN	Huawei, HiSilicon	discussion	Agreement	Yes	Yes	noted	No
		S3‑191348	Amendment to Key Issue# 2.1	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: SA2 already created an architecture that doesn't imply changes in the security architecture. No work for us in this key issue. Huawei: you mention the standalone case, this is for the integrated case.	noted	No
		S3‑191338	Solution for efficient authentication for access between NPN and PLMN	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191424	Solutions and conclusion for SNPN service access via PLMN and vice versa	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE: everything is captured in the SA2 specification.The solution is in their document already. This will not prodce eventually CRs into 33.501. Gemalto: we need a conclusion on this key issue, otherwise this will come back. The Chair commented that existing solutions can apply. ORANGE didn’t agree since this didn’t have any impact on our specifications. ORANGE: just say that no normative work is required. Everything was gone except the conclusion, which was reworded.	revised	No	S3‑191771
		S3‑191771	Solutions and conclusion for SNPN service access via PLMN and vice versa	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191424
		S3‑191370	update in solution 4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191772
		S3‑191772	update in solution 3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191370
		S3‑191495	Proposed evaluation details for solution #4 in TR 33.819	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑191552	Editor’s note for KI #1.1	Samsung	pCR	Approval	Yes	Yes	approved	No
		S3‑191496	Proposed conclusion details for key issue #1.1 in TR 33.819	Qualcomm Incorporated	pCR	Approval	Yes	YesEricsson: too early.	noted	No
		S3‑191551	Alignment of the term Non-Standalone NPN	Samsung	pCR	Approval	Yes	Yes	approved	No
		S3‑191555	Resolution of Editor’s note on entities protected in Solution #3	Samsung	pCR	Approval	Yes	Yes	approved	No
		S3‑191556	Evaluation to Solution #3	Samsung	pCR	Approval	Yes	YesEricsson: how do you know that the UE is present without authentication and not a reply attack? Samsung: this is always possible but it is not addressed in this key issue. Editor's note added: change of CAGid by the network, provisioning of the updated id to the UE is out of scope of this solution.	revised	No	S3‑191773
		S3‑191773	Evaluation to Solution #3	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑191556
		S3‑191430	Summary of security aspects covered in this study	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑191774
		S3‑191774	Summary of security aspects covered in this study	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesLast part from "the key issues are grouped.." removed as proposed by Qualcomm.	approved	No		S3‑191430
		S3‑191422	Unified EAP authentication framework	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE: not needed. There is no key issue or requirements. Nokia replied that this was coming from an endorsed document from the last meeting. ORANGE commented that the agreement was about going directly to CRs in the normative phase instead of introducing content in the TR. ORANGE added that the usual procedure from SA3 was based on key issues and there was no point in changing this working methodology.	noted	No
		S3‑191493	Proposed evaluation details for solution #5 in TR 33.819	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑191423	Conclusion on EAP authentication framework	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑191494	Proposed conclusion details for key issue #5.1 in TR 33.819	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑191431	Security for non-public networks	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	YesMCC commented that this could not be input for the study, since CRs are part of normative work. Qualcomm and Nokia replied that thhey wanted to collect comments and agree on a way forward for the future. MCC added that in order to procceed with these CRs a normative WID would be needed.	noted	No
		S3‑191432	NPN references in existing text	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	YesGemalto: the USIM always resides in the UICC, not only for PLMNs.	noted	No
		S3‑191497	Motivation and comments on a draft CR for non-public networks	Qualcomm Incorporated	discussion	Discussion	Yes	Yes	noted	No
		S3‑191498	Security for non-public networks	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191107	New KI for PLMN integrated NPN	InterDigital	pCR	Approval	Yes	Yes	revised	No	S3‑191596
		S3‑191164	New KI for Public network integrated NPN	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	revised	No	S3‑191597
		S3‑191766	Draft TR 33.819	Nokia	draft TR	Approval	Yes	Yes	approved	No
		S3‑191791	Cover sheet TR 33.819	Nokia	TS or TR cover	Approval	Yes	Yes	approved	No
8.16	Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)	S3‑191482	pCR to TR33.935 - Addition of Diffie - Helman Key agreements section	Vodafone GmbH	pCR	Approval	Yes	Yes	withdrawn	Yes
8.17	Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)	S3‑191146	Response LS on full data rate support for UP IP	R2-1905455	LS in		Yes	YesLenovo: what are the implications of this in our study? Qualcomm replied that SA3 should focus on the LTE part, and for the NR it is fine to meet the requirement. Huawei: it seems that they didn’t get our requirement.	noted	No
		S3‑191191	Proposal for FS_UP_IP_Sec Key Issue #3 and 5: Zero-overhead user plane integrity protection on the link layer	Philips International B.V.	pCR	Approval	Yes	Yes	revised	No	S3‑191691
		S3‑191691	Proposal for FS_UP_IP_Sec Key Issue #3 and 5: Zero-overhead user plane integrity protection on the link layer	Philips International B.V.	pCR	Approval	Yes	YesLenovo: for NR or LTE? Philips: for both. Huawei: for LTE it is impossible. Vodafone: this is not a TS, we don’t need approval from RAN2 to introduce a solution in the TR, it is not a conclusion. Lenovo,Ericsson, Nokia: let's not advance with this given the answer from RAN2 in their LS.	noted	No		S3‑191191
		S3‑191263	Modification to key issue#1	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	Yes	approved	No
		S3‑191264	Modification to Key issue#4	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	Yes	noted	No
		S3‑191265	Integrity protection between SgNB and UE in NGEN-DC	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	YesHuawei, NEC: this is already covered in TS 33.501. Vodafone: key issue 4 still exists, so this is valid as a solution. Huawei: just refer to TS 33.501. Vodafone: we need a contribution evaluating this. MCC: reword last sentence to say that this is covered by TS 33.501. Huawei: add an editor's note indicating that if TS 33.501 is changed, the solution needs to be aligned. The solution details were removed.	revised	No	S3‑191776
		S3‑191776	Integrity protection between SgNB and UE in NGEN-DC	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	Yes	approved	No		S3‑191265
		S3‑191266	Solution for Key issue #5	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	YesQualcomm: not in the scope of the study item based on the RAN2 LS. NCSC: remove the IV generation part. Ericsson: we don’t need this. Qualcomm: we need to revisit the key issues based on RAN2's answer. Lenovo agreed.	noted	No
		S3‑191543	Solution for integrity protection of UP signalling messages	Samsung	pCR	Approval	Yes	Yes	approved	No
		S3‑191775	Draft TR 33.853	Vodafone	draft TR	Approval	Yes	Yes	approved	No
8.18	Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)	S3‑191217	Scope for TR 33 848	BT plc	pCR	Agreement	Yes	Yes	revised	No	S3‑191714
		S3‑191714	Scope for TR 33 848	BT plc	pCR	Agreement	Yes	Yes	approved	No		S3‑191217
		S3‑191216	Initial Key Issues for TR 33.848	BT plc	pCR	Agreement	Yes	Yes	revised	No	S3‑191721
		S3‑191721	Initial Key Issues for TR 33.848	BT plc	pCR	Agreement	Yes	Yes	approved	No		S3‑191216
		S3‑191222	Virtualisation Background and Concepts	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑191715
		S3‑191715	Virtualisation Background and Concepts	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑191222
		S3‑191223	Discussion on structure of TR 33.848: Study on Security Impacts of Virtualisation	NCSC	discussion	Discussion	Yes	Yes	noted	No
		S3‑191224	Key Issue: Establishment of trust domains for Network Functions	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑191716
		S3‑191716	Key Issue: Establishment of trust domains for Network Functions	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑191224
		S3‑191225	Key Issue: Confidentiality of Sensitive Data	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑191717
		S3‑191717	Key Issue: Confidentiality of Sensitive Data	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑191225
		S3‑191226	Key Issue: Availability of Network Functions	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑191718
		S3‑191718	Key Issue: Availability of Network Functions	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑191226
		S3‑191563	Virtualisation Study Key Issue 1	BT Group	pCR	Agreement	Yes	Yes	revised	No	S3‑191719
		S3‑191719	Virtualisation Study Key Issue 1	BT Group	pCR	Agreement	Yes	Yes	approved	No		S3‑191563
		S3‑191564	Virtualisation Study Key Issue 2	BT Group	pCR	Agreement	Yes	Yes	revised	No	S3‑191720
		S3‑191720	Virtualisation Study Key Issue 2	BT Group	pCR	Agreement	Yes	YesLast sentence was removed as challenged by Gemalto. MCC: remove the "must". We don't have to refer to ETSI ISG NFV phase one as a whole, better refer to specific documents.	approved	No		S3‑191564
		S3‑191565	Virtualisation Study Key Issue 3	BT Group	pCR	Agreement	Yes	Yes	approved	No
		S3‑191566	Virtualisation Study Key Issue 4	BT Group	pCR	Agreement	Yes	Yes	approved	No
		S3‑191567	Virtualisation Study Key Issue 5	BT Group	pCR	Agreement	Yes	YesHuawei: what's the requirement for 3GPP here? BT: good question, not trivial. It was commented that most probably there would be no requirements, but it was good to document it. This was asked to be captured in the minutes.	revised	No	S3‑191778
		S3‑191778	Virtualisation Study Key Issue 5	BT Group	pCR	Agreement	Yes	Yes	approved	No		S3‑191567
		S3‑191568	Virtualisation Study Key Issue 6	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191569	Virtualisation Study Key Issue 7	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191570	Virtualisation Study Key Issue 8	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191571	Virtualisation Study Key Issue 9	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191572	Virtualisation Study Key Issue 10	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191573	Virtualisation Study Key Issue 11	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191574	Virtualisation Study Key Issue 12	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191575	Virtualisation Study Key Issue 13	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191576	Virtualisation Study Key Issue 14	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191577	Virtualisation Study Key Issue 15	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191578	Virtualisation Study Key Issue 16	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191579	Virtualisation Study Key Issue 17	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191580	Virtualisation Study Key Issue 18	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191581	Virtualisation Study Key Issue 19	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191582	Virtualisation Study Key Issue 20	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191583	Virtualisation Study Key Issue 21	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191584	Virtualisation Study Key Issue 22	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191585	Virtualisation Study Key Issue 23	BT Group	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191587	Virtualisation Study Key Issue 24	BT plc	pCR	Agreement	Yes	Yes	not treated	No
		S3‑191722	Draft TR 33.848	BT	draft TR	Approval	Yes	Yes	revised	No	S3‑191777
		S3‑191777	Draft TR 33.848	BT	draft TR	Approval	Yes	Yes	approved	No		S3‑191722
8.19	Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)	S3‑191336	A key issue on forward secracy	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191473	Co-existence of LTKUP and PFS	Ericsson	discussion	Discussion	Yes	Yes	not treated	No
		S3‑191196	way forward against attack using authentication	ZTE Corporation	discussion	Endorsement	Yes	YesZTE: this involves both Rel-15 and Rel-16. Gemalto: how and where to address this topic? Rel-15 or Rel-16? Ericsson: all contributions changing the core of SA3 cannot be handled in Rel-15 at this stage. Nokia: we are touching the core of authentication mechanism so this needs to be analysed carefully. It was commented that this content was related to the study in 8.19. The CRs in that case would not be considered as such in the study, but as pseudo CRs.	noted	No
		S3‑191480	New KI: Leakage of long-term key	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑191197	Structure RAND for authentication – HE part	ZTE Corporation	CR	Agreement	Yes	Yes	not treated	No
		S3‑191198	Structure RAND for authentication – ME part	ZTE Corporation	CR	Agreement	Yes	Yes	not treated	No
		S3‑191199	Structure RAND for authentication – ME part	ZTE Corporation	CR	Agreement	Yes	Yes	not treated	No
		S3‑191200	Handling of Sync failure for 5G AKA	ZTE Corporation	CR	Agreement	Yes	Yes	not treated	No
		S3‑191337	A solution to forward secracy	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191481	New solution: EAP-AKA´ PFS	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑191201	Modification on linkability issue1	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑191559	Mitigation against linkability attack	Gemalto N.V.	pCR	Approval	Yes	Yes	not treated	No
		S3‑191383	mitigate the linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191402	New solution for linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191231	New KI: Updating UDM with UE deregistration status	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑191410	New KI: KAUSF storing at UE side	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191529	Adding MACS as an input parameter to the calculation of AK* to provide freshness	Qualcomm Incorporated	CR	Agreement	Yes	Yes	not treated	No		S3‑190376
		S3‑191202	Conclusion on linkability issue	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
8.20	Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)	S3‑191149	LS to SA2 and SA5 on IAB impact to CN	R2-1905475	LS in		Yes	Yes	noted	No
		S3‑191194	IAM Security	AT&T,Interdigital	discussion		Yes	YesEricsson: we are aligned with AT&T's view.Qualcomm also shared their opinion and they had related contributions. Huawei commented that they had contributions addressing this as well. Alex(BT): make sure that this will scale out in software.	noted	No
		S3‑191516	Status on RAN WI NR_IAB	Qualcomm Incorporated	discussion	Information	Yes	YesHuawei: RAN3 can inform us by LS about their progress.	noted	No
		S3‑191514	Draft CR to 38300 for IAB	Qualcomm Incorporated	discussion	Information	Yes	YesCompany of the previous contribution for information.	noted	No
		S3‑191515	Draft CR to 38401 for IAB	Qualcomm Incorporated	discussion	Information	Yes	YesCompany of the previous contribution for information.	noted	No
		S3‑191456	IAB - terminology	Ericsson	pCR	Approval	Yes	YesHuawei: this is not related to SA3, let's reference the RAN specs because the definitions can change. Qualcomm suggested to keep them as they were useful with an editor's note explaining that they may be temporary.	revised	No	S3‑191692
		S3‑191692	IAB - terminology	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑191456
		S3‑191536	IAB Architecture	Samsung	pCR	Approval	Yes	Yes	revised	No	S3‑191694
		S3‑191694	IAB Architecture	Samsung	pCR	Approval	Yes	YesAdding an editor's note on alignment with RAN specs.	approved	No		S3‑191536
		S3‑191457	IAB - security architecture diagram key issue	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191491	IAB - security architecture diagram solution	Ericsson-LG Co., LTD	pCR	Approval	Yes	Yes	revised	No	S3‑191695
		S3‑191695	IAB - security architecture diagram solution	Ericsson-LG Co., LTD	pCR	Approval	Yes	Yes	approved	No		S3‑191491
		S3‑191458	A new KI for the authentication framework for the UE	Ericsson	pCR	Approval	Yes	YesHuawei: we don’t need to mention framework here. Ericsson: we want to capture that the UE is transparent to this authentication. ORANGE: we don’t need this key issue. The UE is authenticated to the network according to TS 33.501. Qualcomm: this TR analyses changes to what's in TS 33.501 already. We don’t want to re-open key issues. ORANGE: be more precise, not just "transparent". The Chair proposed to add a statement addressing this somewhere like in clause 4.	revised	No	S3‑191696
		S3‑191696	A new KI for the authentication framework for the UE	Ericsson,Intel	pCR	Approval	Yes	Yes	approved	No		S3‑191458
		S3‑191459	A new KI for the authentication framework for an IAB node acting as a MT	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑191697
		S3‑191697	A new KI for the authentication framework for an IAB node acting as a MT	Ericsson,Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑191459
		S3‑191460	A new KI for activating communication security in IAB node	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑191698
		S3‑191698	A new KI for activating communication security in IAB node	Ericsson,Intel	pCR	Approval	Yes	Yes	approved	No		S3‑191460
		S3‑191538	Key Issue on IAB Node authentication and authorization	Samsung R&D Institute India	pCR	Approval	Yes	YesContent related to authentication was merged with the revision of 459.	merged	No	S3‑191697
		S3‑191461	A solution for mutual authentication between a UE and a 3GPP network supporting the IAB architecture	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑191696
		S3‑191539	Solution for IAB Node authentication and authorization	Samsung	pCR	Approval	Yes	YesHuawei: this is mixing LTE and 5G details, so it's confusing. Added an editor's note on the need to separate both authentication details. ORANGE: remove the evaluation, add an editor's note on the difference between MT and UE (which will be decided in RAN groups). It was decided to add a statement on the IP node acting as an UE instead of the editor's note.	revised	No	S3‑191699
		S3‑191699	Solution for IAB Node authentication and authorization	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑191539
		S3‑191250	F1-U security analysis for IAB architecture	Huawei, Hisilicon	discussion	Endorsement	Yes	YesORANGE: this challenges the TS 33.501 5G architecture. This is misplaced. Juniper, AT&T, Vodafone,BT objected to the document. ORANGE: f1 security activation is optional for the operator, this was agreed. Huawei: we didn’t analyse the security threats for f1. If there are no threats we don’t need the security requirement. Vodafone: we cannot be reactive, do something when we have a security threat. Not having identified the threat doesn't mean that there is no threat. NTT-Docomo didn’t agree with the way the document was written. There wasn't any support for this document, hence it was noted.	noted	No
		S3‑191254	Key Issues on F1-U security for IAB architecture	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191518	Commonalities between IAB and Wireline Fronthaul for CU/DU	Qualcomm Incorporated	discussion	Discussion	Yes	Yes	noted	No
		S3‑191517	F1 interface security for IAB	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei only supported the f1 control, but objected to the requirements and threats. Ericsson,ORANGE, NTT-Docomo, Vodafone, Juniper,BT, AT&T supported these requirements.. BT: the requirement should distinguish between wireless and wireline. Huawei: no additional requirements to end-to-end PDCP security protection. There are no attacks for this. NTT-Docomo: clarify the end-to-end between the terminating points. The security requirements were reworded to say "shall support" instead.	revised	No	S3‑191700
		S3‑191700	F1 interface security for IAB	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑191517
		S3‑191519	Solution for F1 interface security for IAB	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑191260	key issue for IAB Handover	Intel Corporation (UK) Ltd	pCR		Yes	YesInterdigital: no connection between threats and requirements. Intel agreed to remove the requirements. Qualcomm didn’t understand the threats. IAB node communication security was to be covered in 698 and the UE handovers being transparent aspects in 696.	merged	No	S3‑191696
		S3‑191255	F1-U security when UE UP is e2e PDCP protected	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191253	Clarification for F1-U protection	Huawei, Hisilicon	CR	Approval	Yes	YesNTT-Docomo,ORANGE, AT&T: the change is not needed. Huawei: capture it in a note since this is confusing for external readers. Juniper didn’t agree with this CR either. Samsung supported the contribution since it was adding some clarification. Huawei: no security reason against this. In the end there was no agreement and the document was not pursued.	not pursued	No
		S3‑191693	Draft TR 33.824	Samsung	draft TR	Approval	Yes	Yes	approved	No
8.21	Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)	S3‑191302	Clause 4 Security Aspects of Advanced V2X services	LG Electronics	pCR	Approval	Yes	YesNEC: references are not included in here.	revised	No	S3‑191744
		S3‑191744	Clause 4 Security Aspects of Advanced V2X services	LG Electronics	pCR	Approval	Yes	Yes	approved	No		S3‑191302
		S3‑191161	LS to request inputs on the Vehicular Multimedia technical report and to invite participation from relevant stakeholders	ITU-T Focus Group on Vehicular Multimedia (FG-VM)	LS in		Yes	Yes	noted	No
		S3‑191145	LS on protection of PC5-RRC messages for sidelink unicast communication	R2-1905332	LS in		Yes	Yes	replied to	No
		S3‑191300	Discussion about RAN2 LS on protection of PC5-RRC messages for sidelink unicast communication	LG Electronics	discussion	Discussion	Yes	Yes	noted	No
		S3‑191301	Reply LS on protection of PC5-RRC messages for sidelink unicast communication	LG Electronics	LS out	Approval	Yes	Yes	noted	No
		S3‑191591	Comments on S3-191301, Draft Reply LS on protection of PC5-RRC messages for sidelink unicast communication	InterDigital Germany GmbH	LS out	Approval	Yes	YesCATT commented that there was no intervention of the operator through PC5, car-to-car communication/unicast security is established in a different scenario from the operator's network. LG: there is still information exchange with gNodeB. Nokia: we need more information on the PC5 protocol layer to answer question 2.	revised	No	S3‑191622
		S3‑191622	Reply LS on protection of PC5-RRC messages for sidelink unicast communication	InterDigital Germany GmbH,LG	LS out	Approval	Yes	Yes	approved	No		S3‑191591
		S3‑191232	Nokia comments on LS R2-1905332 PC5-RRC message protection	Nokia, Nokia Shnghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑191109	New Key Issue for TR 33.836 - privacy protection for unicast messages over PC5	InterDigital Germany GmbH	pCR	Approval	Yes	YesBT: split between short term and long term linkabilities. These are two different scenarios. We have to avoid tracking vehicles in the long term, for example. An editor's note was added to that effect.	revised	No	S3‑191746
		S3‑191746	New Key Issue for TR 33.836 - privacy protection for unicast messages over PC5	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	approved	No		S3‑191109
		S3‑191111	New Key Issue for TR 33.836 - security for eV2X unicast messages over PC5	InterDigital Germany GmbH	pCR	Approval	Yes	YesLG and Qualcomm had their doubts on the last wo requirements. MCC had doubts on the "shall be used and protected" or "shall be supported and may be used" wordings. Qualcomm: further requirements are FFS. MCC: "shall be supupported and may be used", the "may be used" is already in the meaning of "supported". Qualcomm: add reference to the PROSE spec for the NOTE.	revised	No	S3‑191747
		S3‑191747	New Key Issue for TR 33.836 - security for eV2X unicast messages over PC5	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	approved	No		S3‑191111
		S3‑191303	New key issue on AS layer signalling protection for unicast mode over PC5	LG Electronics	pCR	Approval	Yes	YesLG asked to have it noted and commented that they would come back with further details in the next meeting.	noted	No
		S3‑191110	New Key Issue for TR 33.836 - privacy protection for multicast messages over PC5	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	revised	No	S3‑191670
		S3‑191670	New Key Issue for TR 33.836 - privacy protection for multicast messages over PC5	InterDigital Germany GmbH,LG	pCR	Approval	Yes	Yes	approved	No		S3‑191110
		S3‑191340	New Key Issue-Security of identifiers in group communication	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑191740
		S3‑191740	New Key Issue-Security of identifiers in group communication	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191340
		S3‑191385	KI_security for setting up multicast	Huawei, Hisilicon	pCR	Approval	Yes	YesQualcomm: better reword the requirements to include the support. LG: too early for this key issue, but I can live with it. The requirement was removed and an editor's note was added.	revised	No	S3‑191748
		S3‑191748	KI_security for setting up multicast	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191385
		S3‑191304	New key issue on security and privacy of groupcast over PC5 for V2X communication	LG Electronics	pCR	Approval	Yes	Yes	merged	No	S3‑191670
		S3‑191112	New Key Issue for TR 33.836 - Security of the UE service authorization and revocation	InterDigital Germany GmbH	pCR	Approval	Yes	YesGemalto: "shall provide means" is too vague. Qualcomm: is this key issue going to the normative phase in SA2? Is the revocation in scope? An editor's note was added to check this in the future.	revised	No	S3‑191749
		S3‑191749	New Key Issue for TR 33.836 - Security of the UE service authorization and revocation	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	approved	No		S3‑191112
		S3‑191116	New Key Issue for TR 33.836 - Security of the UE service provisioning	InterDigital Germany GmbH	pCR	Approval	Yes	Yes	noted	No
		S3‑191341	New Key Issue-cross-RAT PC5 control authorization indication	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191342	New Key Issue-Security visibility including human factors	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: what is expected from 3GPP here? This is an application layer issue, out of scope. BT, Gemalto agreed.	noted	No
		S3‑191343	New Key Issue-Driving information privacy protection	Huawei, HiSilicon	pCR	Approval	Yes	YesBT, ORANGE: this is application layer as well, especially speed, brake and acceleration. Interdigital: two positions in time gives us the speed. Qualcomm: is SA2 proposing to have specific location information in their V2X work? This belongs to the location work item. LG didn’t support this.	noted	No
		S3‑191117	References	InterDigital Germany GmbH	pCR	Approval	Yes	YesQualcomm, MCC: add the references in the contributions where they are mentioned.	approved	No
		S3‑191745	Draft TR 33.836	LG	draft TR	Approval	Yes	Yes	approved	No
8.22	Other study areas
8.23	New study item proposals	S3‑191245	Study Item: Security of Bulk IoT operations	Huawei, Hisilicon	SID new	Approval	Yes	Yes	postponed	No
		S3‑191289	Discussion on security of 5G eMBMS enhancement	Huawei, HiSilicon	discussion	Endorsement	Yes	YesVodafone: it doesn’t provide a really good reason apart from saying that SA2 is working on 5G MBMS. Huawei: just a warning on that we will have to work on this in the near future. We don’t intend to start working on this now. It was commented that this could be part of Rel-17 work. Qualcomm agreed with this and added that it was a bit too early to start any activity on this issue.	noted	No
		S3‑191291	Security aspects on enhancement of support for Edge Computing in 5GC	China Unicom, CAICT, China Telecom	discussion		Yes	YesVodafone: work on URLCC hasn’t finished yet. Wy having a rel-17 SID when we haven’t finished work on URLCC Rel-16? Huawei: this is a different topic, it's on edge computing. ORANGE: too many studies in SA3 at this moment. Let's postpone and wait for progress from SA2.	noted	No
		S3‑191292	New SID: Study on security aspects of enhancement of support for Edge Computing in 5GC	China Unicom, CAICT, China Telecom, ZTE	SID new		Yes	Yes	revised	No	S3‑191639
		S3‑191639	New SID: Study on security aspects of enhancement of support for Edge Computing in 5GC	China Unicom, CAICT, China Telecom, ZTE,Huawei	SID new	-	Yes	YesORANGE: very little work done in SA2 since their study item was approved in the last plenary. Qualcomm agreed. The Chair asked if it was ok to wait for SA2's progress. China Unicom asked when it was good time to bring back this. Qualcomm replied that it would be a good timing when SA2 had drafted some conclusions in their study. This was agreed, China Unicom asked for offline feedback for their study paper.	noted	No		S3‑191292
		S3‑191405	Discussions on security of mobile edge computing	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑191406	New SID: Study on Security Aspects of enhancement of support for Edge Computing in 5GC	Huawei, Hisilicon	SID new	Approval	Yes	Yes	merged	No	S3‑191639
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑191102	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑191105	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑191792
		S3‑191792	Work Plan input from Rapporteurs	MCC	other	-	No	Yes	noted	No		S3‑191105
10	Future Meeting Dates and Venues	S3‑191104	SA3 meeting calendar	MCC	other		Yes	Yes	revised	No	S3‑191793
		S3‑191793	SA3 meeting calendar	MCC	other	-	No	YesPossibility of one or two adhocs in 2020, for further consideration. November 2020, it could be NAF or Huawei (Singapore). Feb 2020 hosted by CF3. IF3 has offered to host.	noted	No		S3‑191104
11	Any Other Business	S3‑191784	Draft agenda SA3_95-BIS	WG Chair	discussion	Discussion	No	YesOrder of study items will be reverse of what was treated during this meeting. The Chair recommended to have conference calls in order to save meeting time and progress in the work, and avoid non treated documents.	noted	No
12	Close