TDoc list

Tdoc List

2019-11-22 16:37

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‑193900	Agenda	WG Chairman	agenda		Yes	Yes	revised	No	S3‑194442
		S3‑194442	Agenda	WG Chairman	agenda	-	Yes	Yes	approved	No		S3‑193900
3	IPR Anti-Trust Law and other Reminders
4	Meeting Report
4.1	Approval of the report from previous SA3 meeting(s)	S3‑193901	Report from SA3#96	MCC	report		Yes	YesApproved with an editorial change in tdoc 2862 as commented by Qualcomm. (AS instead of AES). This will be corrected in the final version uploaded to the 3GPP server.	approved	No
		S3‑193902	Report from SA3#96Ad-Hoc	MCC	report		Yes	YesMCC thanked the SA3 leadership for taking care of MCC tasks during the adhoc.	approved	No
4.2	Report from SA plenary	S3‑193904	Report from last SA meeting	WG Chairman	report		Yes	YesHuawei asked when SA3 was going to start working on Release 17. The Chair answered that the release 17 work was based on the prioritization done in SA2, so SA3's work would depend on their progress. Vodafone asked about items such as SBA. Can SBA be classed as release 16? The Chair answered that it was release 16.	noted	No
4.3	Report from SA3-LI
5	Items for early consideration
5.1	Output of SA3#96-Ad hoc	S3‑194352	Security requirements for UP Gateway Function	Nokia, Nokia Shanghai Bell, Juniper	CR	Agreement	Yes	YesThis CR will go together with the UP Gateway Function new WID that goes to the next SA plenary. That’s why it has the DUMMY WID code. The baseline was agreed and new changes would be merged into the revision.	revised	No	S3‑194443
		S3‑194443	Security requirements for UP Gateway Function	Nokia, Nokia Shanghai Bell, Juniper	CR	Agreement	Yes	Yes	agreed	No		S3‑194352
		S3‑194355	Protection of N9 interface	Nokia, Nokia Shanghai Bell, Juniper Networks	CR	Agreement	Yes	YesThis CR will go together with the UP Gateway Function new WID that goes to the next SA plenary. That’s why it has the DUMMY WID code. The baseline was agreed and new changes would be merged into the revision.	revised	No	S3‑194444
		S3‑194444	Protection of N9 interface	Nokia, Nokia Shanghai Bell, Juniper Networks	CR	Agreement	Yes	Yes	agreed	No		S3‑194355
		S3‑194356	New WID for User Plane Gateway Function for the Inter-PLMN Security	Juniper Networks	WID new	Agreement	Yes	YesVodafone asked if the date was realistic, but Juniper was not confident and the date was proposed to bechanged to March 2020. It was kept open for discussion whether to move it to this date.	revised	No	S3‑194445
		S3‑194445	New WID for User Plane Gateway Function for the Inter-PLMN Security	Juniper Networks	WID new	Agreement	Yes	Yes	agreed	No		S3‑194356
		S3‑194359	Security requirements for SeCoP	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑194446
		S3‑194446	Security requirements for SeCoP	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesAgreed baseline but Ericsson proposed new changes for a revision.	agreed	No		S3‑194359
		S3‑194361	Authentication and authorization between SeCoP and network functions	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S3‑194363	Authentication and authorization between SeCoPs	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S3‑194378	Update to 5G_eSBA WID	Nokia, Nokia Shanghai Bell	WID revised	Approval	Yes	YesKept open in order to discuss the dates.	revised	No	S3‑194600
		S3‑194600	Update to 5G_eSBA WID	Nokia, Nokia Shanghai Bell	WID revised	Approval	Yes	YesChanged to March 2020.	agreed	No		S3‑194378
		S3‑194401	NPN clarifications	Nokia, Nokia Shanghai Bell,Qualcomm	CR	Agreement	Yes	YesVodafone: the change in I.2.1 makes it too broad. Other groups have misinterpreted our specification for this reason. The Chair commented that this was heavily discussed in the previous meeting. Nokia added that this referred to clauses I.2.2 and I.2.3. Qualcomm added that this was not normative but an introduction to other clauses. Vodafone withdrew their comment.	agreed	No
		S3‑194402	Removal of ed.note on conformance tests	Nokia, Nokia Shanghai Bell,Qualcomm	CR	Agreement	Yes	Yes	agreed	No
		S3‑194405	Annex 5GLAN	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑194428
		S3‑194427	Security for TSC service	Nokia, Nokia Shanghai Bell	discussion	Information	Yes	Yes	noted	No
		S3‑194406	Annex TSC security intro	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S3‑194428	Annex 5GLAN	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑194405
5.2	Other items
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑193934	LS on AS key derivation for conditional handover	R2-1911565	LS in		Yes	YesRelated contributions: 4055, 4025.	replied to	No
		S3‑193969	33501-CR on CHO key derivation	Apple	CR	Approval	Yes	YesNokia: add reference to RAN2 spec. Huawei supported this. Christine (Ericsson): wait for the reply, we don’t need to make the changes now. Qualcomm didn’t agree with having the second change as RAN2 was still working on this topic. Wait for their reply.	revised	No	S3‑194448
		S3‑194448	33501-CR on CHO key derivation	Apple	CR	Approval	Yes	YesPostponed in order to add more details: Key derivation in CHO needs to be addressed in the specification.	not pursued	No		S3‑193969
		S3‑193935	LS on impact on UTRAN of 5G SRVCC	R2-1911753	LS in		Yes	Yes	noted	No
		S3‑193937	LS on misalignment in Counter Check Procedure	R2-1911837	LS in		Yes	Yes	noted	No
		S3‑194357	Updates to Counter Check Procedure (Rel-15)	Samsung	CR	Approval	Yes	YesEricsson didn’t agree with this change. Huawei: change from shall not to "should not". Samsung insisted on an existing misalignment with RAN2. There is no benefit with having the removed the sentence according to Samsung. Qualcomm supported Samsung. Alf (NTT-Docomo): just add a note with a clarification. MCC asked if this should be cat-F and Samsung replied that it could be and that a mirror was submitted to this meeting as well. Ericsson commented that this should not be changed in Release 16, so this was taken offline.	revised	No	S3‑194449
		S3‑194449	Updates to Counter Check Procedure (Rel-15)	Samsung	CR	Approval	Yes	YesMirror in 358.	agreed	No		S3‑194357
		S3‑193942	LS on security for multi-CU-UP connectivity	R3-194784	LS in		Yes	Yes	replied to	No
		S3‑194138	Discussion on Security of Multi-CU-UP connectivity	CATT	discussion	Decision	Yes	Yes	noted	No
		S3‑194056	Discussion on LS R3-194784 on Disaggregated CU-UPs in different security domains	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑194139	LS reply to RAN WG3 LS on security for multi-CU-UP connectivity	CATT	LS out	Approval	Yes	YesCATT: it's too late for Release 16 from our point of view. NTT-Docomo didn’t find the text in LS very clear. Qualcomm: the UE is not aware of where the user plane ends, it's handled by the RAN. SA3 needs to study this anyway, as the current architecture is not sufficient; and that's what we need to reply to them. Nokia: study item for this? It's a simple change. Qualcomm replied that this could have a significant impact on the RAN. NTT-Docomo: network side security domain could be affected as well, so this is not so simple. They proposed to take this offline to study the consequences. CATT added that RAN3 was planning to do a WID in Release 17 about this topic.	revised	No	S3‑194450
		S3‑194450	LS reply to RAN WG3 LS on security for multi-CU-UP connectivity	CATT	LS out	Approval	Yes	Yes	approved	No		S3‑194139
		S3‑193944	Reply LS on LS on the IAB-indication to core network	S2-1910281	LS in		Yes	Yes	noted	No
		S3‑193951	LS on Enhancing Location Information Reporting with Dual Connectivity	S3i190671	LS in		Yes	Yes	noted	No
		S3‑193957	N9HR Regulatory Obligations	S3i190548	LS in		Yes	YesORANGE: gNode B encrypts the traffic in the visited network, why encrypting this in the UPF? BT: we have to turn off the encryption in the UPF for LI reasons. It would be nice to turn that back on. Amelia (Article 19): countries cooperating with each other, law enforcement, better than a technical solution like this. BT: make the security hole smaller would be preferable for us. ORANGE: I prefer to have a paper expalining the issues better. It was decided to note the document since the next step would be a Study Item.	noted	No
		S3‑193958	LS on security consideration of performance measurement function protocol	C1-196940	LS in		Yes	YesThere were companies supporting either replying (something is needed)	postponed	No
		S3‑194451	Reply to: LS on security consideration of performance measurement function protocol	ZTE	LS out	approval	Yes	YesNo consensus. Apple asked to have in the minutes: "Apple strongly insists that the current security existing mechanism is NOT sufficient to address the security issue that 3rd part application could modify the PMF packet."	noted	No
		S3‑193949	Reply LS on UP gateway function on the N9 interface	S2-1910808	LS in		Yes	Yes	replied to	No
		S3‑193989	Reply LS on UP gateway function on the N9 interface	Juniper Networks	LS out		Yes	YesNokia: not mandatory for us to follow SA2 guidelines. They didn't agree with removing their descripton. Nokia supported a reply LS, but this needed some reshaping. Ericsson had a similar position; better not to go against SA2.	revised	No	S3‑194452
		S3‑194452	Reply LS on UP gateway function on the N9 interface	Juniper Networks	LS out	-	Yes	Yes	approved	No		S3‑193989
		S3‑193966	draft Reply LS_on_CHO key derivation	Apple	LS out	Approval	Yes	YesEricsson, Qualcomm: remove the last sentence from the LS. This was taken offline.	revised	No	S3‑194447
		S3‑194447	Reply LS_on_CHO key derivation	Apple	LS out	Approval	Yes	Yes	approved	No		S3‑193966
		S3‑193967	Discussion on Consecutive CHO key derivation	Apple	discussion	Endorsement	No	Yes	withdrawn	Yes
		S3‑193970	Discussion on PMF Protocol Security	Apple	discussion	Endorsement	Yes	Yes	noted	No
		S3‑193971	draft reply LS on security consideration of PMF	Apple	LS out	Approval	Yes	Yes	noted	No
		S3‑194025	Discussion on CHO key derivation	Apple	discussion	Endorsement	Yes	Yes	noted	No
		S3‑194055	Discussion paper on LS (R2-1911565) on AS key derivation for Conditional Handovertional	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	YesNokia: it's aligned with SA3 work, no changes need to be made.The discussion was taken in the CR proposed by Apple.	noted	No
		S3‑194057	Discussion paper on PMF protocol security S3-193680	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑194064	LS on security consideration of performance measurement function protocol	ZTE Corporation	LS out	Approval	Yes	Yes	noted	No
		S3‑194336	Reply LS on PMF	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑193987	Introduction of the Inter PLMN UP security function in the architecture	Deutsche Telekom AG	discussion	Decision	Yes	Yes	noted	No
		S3‑194431	Nokia comments on S3-193970 PMF protocol security	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	YesApple: Nokia agrees on the attack and sees no standardization needed? We disagree. Lenovo supported the Apple contribution. Futurewei: application impacting on the UE is out of standardization scope as we concluded in the IoT work item. Qualcomm: no UP integrity protection in LTE. We don’t see the need for new security mechanisms, existing ones are sufficient. ZTE supported this. There was no consensus on the need for sending a reply LS.	noted	No
		S3‑194434	LS on Application Architecture for enabling Edge Applications	S6-192399	LS in	discussion	Yes	Yes	noted	No
		S3‑194435	LS on native 5G NAS security context activation	C1-199003	LS in	discussion	Yes	YesQualcomm: leave it to the AMF to decide.Stick to the top highlighted text. Huawei: Our assumption is to use the native security context as much as possible. It was commented that CT1 was meeting after SA3's next meeting, so it was decided to postpone an answer.	postponed	No
		S3‑194436	LS on GUTI allocation for MT-EDT in 5G CIoT	C1-199005	LS in	discussion	Yes	YesHuawei: we need to discuss this offline, as it implies that MT-EDT might not be needed at all. Qualcomm: how to allocate the GUTI is not in our scope. The utility of this feature is up to other working groups, not to us. Ericsson: we have studied this and we think that the re-allocation is not needed. This had to be taken offline.	noted	No
		S3‑194666	Reply to: LS on GUTI allocation for MT-EDT in 5G CIoT	Ericsson	LS out	approval	Yes	Yes	noted	No
		S3‑194437	LS on Use of 3gpp-Sbi-Target-apiRoot header in HTTP requests from NFs to SEPP	C4-195375	LS in	discussion	Yes	YesThis needed some offline discussion.	replied to	No
		S3‑194453	Reply to: LS on Use of 3gpp-Sbi-Target-apiRoot header in HTTP requests from NFs to SEPP	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑194438	Reply LS on GTP Recovery Counter & GSN node behaviour	C4-195518	LS in	discussion	Yes	YesNo action for SA3.	noted	No
		S3‑194439	LS on ARPF in UDICOM	C4-195553	LS in	discussion	Yes	Yes	postponed	No
		S3‑194440	LS on usage of IMSI during 3GPP based authentication	C4-195574	LS in	discussion	Yes	YesLenovo: we think that nothing needs to be done for this scenario. Qualcomm: Blackberry brought a CR for our previous meeting related to this. SUPI privacy can be compromised, but it's up to the implementers to decide if this can happen, and it should not be specified in our standards. Nokia: this is a mix of 4G and 5G. We should reply because CT4 has a CR pending.	replied to	No
		S3‑194454	Reply to: LS on usage of IMSI during 3GPP based authentication	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑194441	LS on user identity when 5G-AKA or EAP AKA’ is used for SNPN	C6-190468	LS in	discussion	Yes	Yes	replied to	No
		S3‑194455	Reply to: LS on user identity when 5G-AKA or EAP AKA’ is used for SNPN	Samsung	LS out	approval	Yes	YesDisagreement on the statement that if NSI is being present in the USIM, the IMSI stored in the USIM can be used by the ME to derive the NSI.Samsung, IDEMIA in favour, Orange and Qualcomm against. Qualcomm: The disagreement lies in two SUPIs in the same USIM. SA2 has no use case for this.	approved	No
6.2	IETF
6.3	ETSI SAGE	S3‑193950	256 bit radio interface algorithm performance	ETSI SAGE	LS in		Yes	YesCATT: the question depends on the implementation, so it's hard to have a reply. Dedicated hardware needs to be used to achieve the required performance. We should focus on the security algorithm itself and not in its performance. Apple supported CATT: don’t focus on performance issues. Vodafone replied that there are criteria that needed to be taken into account by SAGE. SA3 could very well reply that it is up to them to decide on these parameters. Alex (BT) reminded that HTTP digest and IPSec had a similar issue in the past, and SA3 chose not to intervene so this lead to implementation problems.	replied to	No
		S3‑194288	[DRAFT] Reply to: 256 bit radio interface algorithm performance	Ericsson	LS out	Approval	Yes	YesCATT didn’t fully agree with the commodity hardware statement. Qualcomm: from UE perspective, this doesn’t preclude that SAGE can find other algorithms. Apple wanted to add this clarification. Vodafone: this is implied in all their work, we don’t need to add this clarification to every LS for them. NTT-Docomo: what is "commodity hardware" here? Replace it with something else. CATT agreed. CATT: don’t rule out hardware solutions. Apple wanted to add a sentence on the choosing of algorithms. Vodafone found obvious the process and there wans't any need of stating this. Vodafone explained that SA3 went to SAGE, who provides with algorithms that fulfil SA3's requirements. SA3 is the one choosing the algorithms, not SAGE.	revised	No	S3‑194456
		S3‑194456	Reply to: 256 bit radio interface algorithm performance	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑194288
		S3‑194334	Reply LS to SAGE on 256-bit algorithms	Qualcomm Incorporated	LS out	Approval	Yes	Yes	merged	No	S3‑194456
		S3‑194534	256 bit algorithm candidates	ETIS SAGE	LS in	discussion	Yes	Yes	postponed	No
6.4	GSMA
6.5	TCG	S3‑193910	TCG progress - report from TCG rapporteur	InterDigital Communications	other	Information	Yes	YesPublication of new or revised deliverables (incremental changes from the status reported at SA3#96). • TCG Mobile Device Runtime Integrity Preservation – publication November 2019. The following public URL is available starting on 11/11/2019: https://trustedcomputinggroup.org/resource/tcg-runtime-integrity-preservation-in-mobile-devices/ • TCG TPM 2.0 Mobile Command Response Buffer Errata – publication November 2019 • TCG Trusted Attestation Protocol (TAP) Use Cases – publication November 2019 • TCG TSS 2.0 Overview and Common Structures – published October 2019 • TCG TSS 2.0 Feature API (FAPI) – public review October 2019 • TCG TSS 2.0 JSON Datatypes and Policy Language – public review October 2019 • TCG TPM 2.0 Authenticated Countdown Timer (ACT) Command – public review October 2019 • TCG Platform Certificate Profile – public review October 2019 • TCG PC Client Specific TPM Protection Profile (PTP) – public review October 2019 • TCG Trusted Attestation Protocol (TAP) Info Model – published September 2019 • TCG TSS 2.0 Enhanced System Level API (ESAPI) – published September 2019 • TCG TSS 2.0 System Level API (SAPI) – published August 2019 • TCG Guidance for Secure Update of S/W and F/W – public review August 2019 • TCG RIV: Network Equipment Remote Attestation – public review June 2019 TCG Trusted Attestation Protocol (TAP) Info Model – publication August 2019 • TCG Trusted Attestation Protocol (TAP) Use Cases – public review August 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG Mobile Device Runtime Integrity Preservation – public review August 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG TPM 2.0 Auto Thin Profile – publication August 2019 • TCG TSS 2.0 Enhanced System Level API (ESAPI) – publication August 2019 • TCG TSS 2.0 System Level API (SAPI) – publication August 2019 2. Meetings • TCG Members Meeting in Miami, Florida USA – 10-13 February 2020 • 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.6	OneM2M
6.7	TC-CYBER
6.8	ETSI NFV
6.9	CVDs and Research	S3‑194063	Top research papers published in 2019 on 4G and 5G security	CableLabs	discussion	Information	Yes	YesCableLabs encouraged delegates to inform on similar papers presented in other conferences. Vodafone: dangerous precedent here, especially if we show papers that haven't been properly reviewed. There is an established process in 3GPP CVD for this. We need a filter in advance to this.	noted	No
6.10	Other Groups	S3‑193932	LS on O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs	O-RAN Alliance	LS in		Yes	YesNokia: there is no security group in O-RAN, so we don’t know what they are asking us to do.	noted	No
		S3‑193933	Reply LS to “O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs”	SP-190947	LS in		Yes	Yes	noted	No
		S3‑193952	LS on SG17 new work item X.sles “Security measures for location enabled smart office services”	ITU-T SG17	LS in		Yes	Yes	noted	No
		S3‑193954	LS on status of draft Recommendation ITU-T Q.SR-Trust “Signalling requirements and architecture for interconnection between trustable network entities”	ITU-T SG11	LS in		Yes	Yes	noted	No
		S3‑193955	LS on SG11 activities related to improvement of the SS7 security including for digital financial services	SP-190586	LS in		Yes	Yes	noted	No
7	Work Areas
7.1	Security aspects of 5G System - Phase 1 (Rel-15)	S3‑193946	LS Response Reply LS on support of non-3GPP only UE and support for PEI in IMEI format	S2-1910679	LS in		Yes	Yes	noted	No
		S3‑193947	LS Response on Security Aspects of AMF Re-allocation Procedure	S2-1910724	LS in		Yes	Yes	noted	No
		S3‑193978	Issue of re-authentication when AMF re-allocation via NAS reroute	vivo, Apple	discussion	Endorsement	Yes	YesNokia: against SA2 decision. There was no agreement as Nokia and Qualcomm were against it. There was no issue for them.	noted	No
		S3‑194027	Horizontal derivation when AMF re-allocation	Apple, vivo	CR	Approval	Yes	Yes	merged	No	S3‑194691
		S3‑194031	CR-R16-Horizontal derivation when AMF re-allocation	Apple, vivo	CR	Approval	Yes	Yes	merged	No	S3‑194692
		S3‑194065	Considerations on security handling of registration with AMF re-allocation	ZTE Corporation	discussion	Endorsement	Yes	Yes	noted	No
		S3‑194066	Security handling in registration with AMF re-allocation	ZTE Corporation	CR	Agreement	Yes	Yes	merged	No	S3‑194692
		S3‑194196	Clarification on AMF reallocation via direct NAS reroute for Rel-15	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm: we are adding new functionality in the UE and we don’t agree with that. ZTE: changes should go to Release 16 only.	not pursued	No
		S3‑194197	Clarification on AMF reallocation via direct NAS reroute for Rel-16	Huawei, Hisilicon	CR	Approval	Yes	Yes	not pursued	No
		S3‑194198	Clarification on primary authentication in direct NAS reroute for Rel-15	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑194691
		S3‑194691	Clarification on primary authentication in direct NAS reroute for Rel-15	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑194198
		S3‑194199	Clarification on primary authentication in direct NAS reroute for Rel-16	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑194692
		S3‑194692	Clarification on primary authentication in direct NAS reroute for Rel-16	Huawei, Hisilicon,ZTE	CR	Approval	Yes	Yes	agreed	No		S3‑194199
		S3‑194315	Solving AMF re-allocations issues for via the RAN	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑194420	Comments on S3-194315	HUAWEI TECHNOLOGIES Co. Ltd.	discussion	Discussion	Yes	Yes	noted	No
		S3‑194195	Solving registration failure in registration procedure with AMF reallocation	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm didn’t see any advantages in this proposal. Nokia wanted to wait for SA2's discussions. All agreed on having an issue for Release 16. The Chair asked if SA3 needed to wait for SA2's progress and Huawei strongly disagreed. This had to be taken offline. NTT-Docomo: Rel-15 UEs that end up in the wrong place? What do we do about them? Non-backward compatible changes are a cause for concern.	not pursued	No
		S3‑194076	Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility	Intel Corporation (UK) Ltd	CR		Yes	Yes	revised	No	S3‑194458
		S3‑194458	Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility	Intel Corporation (UK) Ltd	CR	-	Yes	YesQualcomm wanted to add in the cover sheet that it is not a change of behaviour of the ME but for alignment.	agreed	No		S3‑194076
		S3‑194293	Idle mode mobility from 5GS to EPS	Ericsson	CR	Agreement	Yes	YesHuawei: not needed. The first change is a default rule that everybody knows. Ericsson: everybody in SA3 but not outside this group. Huawei: clause 8.6.1 already describes that, why repeat? Nokia supported that this change was not necessary. There was no support for this CR.	not pursued	No
		S3‑194294	Idle mode mobility from 5GS to EPS	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194295	Idle mode mobility from EPS to 5GS	Ericsson	CR	Agreement	Yes	YesMCC: NOTE 2 contains normative language and that needs to be changed. Huawei had also some issues and this was taken offline.	revised	No	S3‑194460
		S3‑194460	Idle mode mobility from EPS to 5GS	Ericsson	CR	Agreement	Yes	Yes	not pursued	No		S3‑194295
		S3‑194282	AMF re-allocation	Ericsson	discussion	Endorsement	Yes	YesHuawei: SA2 is waiting for SA3's feedback, and SA3 is waiting for SA2's feedback. We are playing ping pong here.	noted	No
		S3‑194296	Idle mode mobility from EPS to 5GS	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194461	Idle mode mobility from EPS to 5GS	Ericsson	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑194358	Updates to Counter Check Procedure (Rel-16)	Samsung	CR	Approval	Yes	Yes	revised	No	S3‑194601
		S3‑194601	Updates to Counter Check Procedure (Rel-16)	Samsung	CR	Approval	Yes	Yes	agreed	No		S3‑194358
		S3‑194111	Add Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm: we have this supported in LTE, so why do we need to repeat it for 5G as well? This was taken offline.	agreed	No
		S3‑194462	Add Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure	Huawei, Hisilicon	CR	Approval	No	Yes	withdrawn	Yes
		S3‑194112	Mirror for Adding Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑194142	Discussion on the Xn-Handover message	CATT	discussion	Decision	Yes	YesThis was kept open until RAN3 had discussed the issue during the week and confirm the scenario. CATT got feedback from RAN3: it was considered a rare case and the final decision was to be taken by SA3. It was finally noted but further action will be taken in the next meeting.	noted	No
		S3‑194321	CR on clarification of ARFCN in KgNB derivation	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesHuawei: just put he reference. Qualcomm: better to give more information. The description would not be self-contained.	agreed	No
		S3‑194322	CR on clarification of ARFCN in KgNB derivation	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S3‑194298	Error handling against violation of the basic validation rules	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesEricsson pointed out that this should go to Release 15. It was clarified that this was pointing to the Release 15 functionality of the SEPP. It was commented that the editor's note already appeared in the SCAS spec. This had to be taken offline.	not pursued	No
		S3‑194134	Amendment on 4.2.2.1.2 on AMF	Huawei, Hisilicon	CR	Approval	No	Yes	withdrawn	Yes
		S3‑194457	Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility	Intel	CR	Agreement	Yes	Yes	agreed	No
7.2	Security Assurance Specification for 5G (Rel-16)	S3‑194224	Fix some reference numbers	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑194342	33.511 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesOverlapping with 223 and 270. The editor's notes were challenged and it was suggested to have an action point instead. Futurewei suggested to convert it into a note. Ericsson preferred to remove the editor's note and minute that the threat reference had to be replaced. Ericsson suggested: Some of the threat references are not aplicable to the requirements and they need to be replaced with new threat references that are applicable. Huawei: The whole test case needs to be revisited. The text to be minuted was taken offline. Futurewei: the removal of these test cases should not be brought back again. This has come several times already. Nokia asked to minute the following comment: "The threats referenced in sub-clauses 4.2.2.1.1, 4.2.2.1.2, 4.2.2.1.4, 4.2.2.1.5 4.2.2.1.6, 4.2.2.1.7, 4.2.2.1.8, and 4.2.2.1.9 are not applicable to the requirements to be tested, and need to be replaced with new threats to be captured in TR 33.926".	revised	No	S3‑194473
		S3‑194473	33.511 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑194342
		S3‑194131	Adding some evidence	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑194223	Update test cases for gNB SCAS	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑194474
		S3‑194474	Update test cases for gNB SCAS	Huawei, Hisilicon	CR	Approval	Yes	YesRevised to address an editorial change: removal of automatic bullet lists.	agreed	No		S3‑194223
		S3‑194270	Test cases referring to TS 33.117	Ericsson	CR	Agreement	Yes	YesHuawei and CATT objected to this CR.	not pursued	No
		S3‑194133	Fix the threat reference numbers for AMF	Huawei, Hisilicon	CR	Approval	Yes	YesOverlap with 343. Tdoc number on the cover is wrong. Nokia asked to be minuted: Nokia asked to be minuted the following comment: "The threat referenced in sub-clause 4.2.2.3.1 is not applicable to the requirement to be tested, and needs to be replaced with a new threat to be captured in TR 33.926".	merged	No	S3‑194475
		S3‑194343	33.512 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑194475
		S3‑194475	33.512 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell,Huawei	CR	Approval	Yes	Yes	agreed	No		S3‑194343
		S3‑194132	Modify the message names	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑194344	33.513 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesOverlap with 135.	revised	No	S3‑194476
		S3‑194476	33.513 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell,Huawei	CR	Approval	Yes	Yes	agreed	No		S3‑194344
		S3‑194135	Fix the threat reference numbers for UPF	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑194476
		S3‑194345	33.514 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑193907	Alignment with TR 33.926	Futurewei Technologies	CR	Agreement	Yes	YesOverlap with 908,347.	merged	No	S3‑194477
		S3‑193908	Reference Correction	Futurewei Technologies	CR	Agreement	Yes	Yes	merged	No	S3‑194477
		S3‑193909	Adding missing abbreviations	Futurewei Technologies	CR	Agreement	Yes	Yes	agreed	No
		S3‑194347	33.515 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑194477
		S3‑194477	33.515 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell,Futurewei	CR	Approval	Yes	Yes	agreed	No		S3‑194347
		S3‑194348	33.516 Corrections for alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑194349	33.517 Adding abbreviations and corrections for alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑194478
		S3‑194478	33.517 Adding abbreviations and corrections for alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesBringing back the removed editor's note.	agreed	No		S3‑194349
		S3‑194350	33.518 Adding abbreviations and corrections for alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑194067	Editorial correction in TS 33.519	ZTE Corporation	CR	Agreement	Yes	Yes	merged	No	S3‑194479
		S3‑194351	33.519 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑194479
		S3‑194479	33.519 Corrections for clean-up and alignment	Nokia, Nokia Shanghai Bell,ZTE	CR	Approval	Yes	Yes	agreed	No		S3‑194351
		S3‑194158	Miscellaneous Editorial clarifications in 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑194301	33.117 Adding abbreviations and corrections for alignment	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑194159	Miscellaneous Editorial clarifications in 33.117	Huawei, Hisilicon	CR	Approval	Yes	YesHuawei commented that there were some issues that they couldn’t fix. E.g. references such as [ef]. Huawei asked to minute that there were references that were unresolved and that anyone was welcome to fix them.	agreed	No
		S3‑194157	Miscellaneous Editorial clarifications in 33.916	Huawei, Hisilicon	CR	Approval	Yes	YesHuawei wanted to point out that there were unresolved editor's notes in the specification.	agreed	No
		S3‑194161	Update of clause 4	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson argued that having the text in the document was OK.Nokia supported Ericsson.	not pursued	No
		S3‑194419	Clarification on aspects specific to the network product class UDM and AMF	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑194179
7.3	eMCSec R16 security (Rel-16)	S3‑193926	LS on IANA assigned values for mission critical	C1-195042	LS in		Yes	Yes	replied to	No
		S3‑194603	Reply to: LS on IANA assigned values for mission critical	Motorola Solutions	LS out	approval	Yes	Yes	approved	No
		S3‑193930	LS on how the IWF obtains key material for interworking group and private communications	C1-196979	LS in		Yes	YesThe response will be included in the reply to tdoc 433.	noted	No
		S3‑193914	[MCXSec] 33180 R16 Missing Abbreviations (Mirror)	Airbus	CR	Agreement	Yes	Yes	revised	No
		S3‑193915	[MCXSec] 33180 R16 Reference Addition (Mirror)	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193916	[MCXSec] 33180 R16 Correction concerning IdM client (Mirror)	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193995	[33.180] R16 Fix bad reference (mirror)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑193996	[33.180] R16 - Consistent use of off-network	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑194499
		S3‑194499	Consistent use of off-network	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑193996
		S3‑193997	[33.180] R16 KM client to KMS security	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑193998	[33.180] R16 - TrK ID and InK ID	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑194500
		S3‑194500	[33.180] R16 - TrK ID and InK ID	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑193998
		S3‑193999	[33.180] R16 - InterSD KM record	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑194000	[33.180] R16 ETSI Plugtest clarifications	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑194362	Algorithm negotiation procedure for MC Service	Samsung	CR	Approval	Yes	Yes	revised	No	S3‑194652
		S3‑194652	Algorithm negotiation procedure for MC Service	Samsung,Motorola Solutions	CR	Approval	Yes	Yes	agreed	No		S3‑194362
		S3‑194001	LS to CT1 on 3rd ETSI MCX Remote Plugtest	Motorola Solutions UK Ltd.	LS out	Agreement	Yes	Yes	revised	No	S3‑194501
		S3‑194501	LS to CT1 on 3rd ETSI MCX Remote Plugtest	Motorola Solutions UK Ltd.	LS out	Agreement	Yes	Yes	revised	No	S3‑194611	S3‑194001
		S3‑194611	LS to CT1 on 3rd ETSI MCX Remote Plugtest	Motorola Solutions UK Ltd.	LS out	Agreement	Yes	Yes	approved	No		S3‑194501
		S3‑194433	Reply LS on how the IWF obtains key material for interworking group and private communications	S6-192194	LS in	discussion	Yes	Yes	postponed	No
		S3‑194502	Minutes of the Mission Critical offline session	Qualcomm	report	Information	Yes	Yes	noted	No
7.4	Security aspects of single radio voice continuity from 5GS to UTRAN (Rel-16)
7.5	Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (Rel-16)	S3‑194360	Description of CAPIF reference point: 3e,4e,5e,7 and 7e	Samsung	CR	Approval	Yes	YesTim (Motorola Solutions): we are missing CAPIF-2e's definition here. Henrik (Ericsson): CAPIF-7e is similar to CAPIF-2e in the third paragraph. These were agreed and addressed in the revision.	revised	No	S3‑194464
		S3‑194464	Description of CAPIF reference point: 3e,4e,5e,7 and 7e	Samsung	CR	Approval	Yes	Yes	agreed	No		S3‑194360
7.6	Security of URLLC for 5GS (Rel-16)	S3‑194421	living CR of URLLC	Huawei, Hisilicon	draftCR		Yes	Yes	revised	No	S3‑194467
		S3‑194467	living CR of URLLC	Huawei, Hisilicon	draftCR	-	No	Yes	left for email approval	No		S3‑194421
		S3‑194125	Clean up	Huawei, Hisilicon	draftCR	Approval	Yes	YesNokia and Qualcomm didn’t agree with the change in the general clause. This had to be taken offline.	revised	No	S3‑194469
		S3‑194469	Clean up	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑194125
		S3‑194225	Resolve EN about how to ensure the UP security policy to be the same	Ericsson	draftCR	Approval	Yes	Yes	revised	No	S3‑194470
		S3‑194470	Resolve EN about how to ensure the UP security policy to be the same	Ericsson,Huawei	draftCR	Approval	Yes	Yes	approved	No		S3‑194225
		S3‑194122	Ensure the same setting for UP policy	Huawei, Hisilicon	draftCR	Approval	Yes	YesNokia agreed with removing the editor's note but wanted some rewording of the preceding text.	merged	No	S3‑194470
		S3‑194123	Clarification on UP security policy preconfiguration	Huawei, Hisilicon	draftCR	Approval	Yes	YesQualcomm didn’t see the need of the new text at all, for the "preferred" option and so on. Nokia wasn't sure about this either. Huawei added that this clarification was needed. This was taken offline.	approved	No
		S3‑194226	Resolve EN about MN being preconfigured with SN capability to perform UP IP	Ericsson	draftCR	Approval	Yes	Yes	noted	No
		S3‑194124	Further clarification on UP activation status	Huawei, Hisilicon	draftCR	Approval	Yes	YesNokia found that there was a lot of text here. Qualcomm preferred to have an option with minimal text.	noted	No
		S3‑194061	URLLC living CR: clarifications related to security policy	Nokia, Nokia Shanghai Bell	other	Approval	Yes	Yes	noted	No
		S3‑194472	URLLC living CR: clarifications related to security policy	Nokia, Nokia Shanghai Bell,Huawei,Ericsson	other	Approval	No	Yes	withdrawn	Yes
		S3‑194418	Comment on S3-194061	Huawei, HiSilicon	other		Yes	Yes	noted	No
7.7	Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16)	S3‑193956	LS on SUCI computation from an NSI	CP-192262	LS in		Yes	Yes	replied to	No
		S3‑194335	Reply LS on SUCI computation from an NSI	Qualcomm Incorporated	LS out	Approval	Yes	YesOrange commented that the derivation still needed to be standardised. Qualcomm replied that this was up to CT4. Thales: consider whether the identifiers are active or not. IMSI and NSI can be stored in SA6. NSI can be activated with a defined mechanism. It is possible to have two identifiers and having one activated in SA6. Thales: confirm that the NSI for AKA based authentication is always derived from the IMSI. Orange confirmed that.	revised	No	S3‑194548
		S3‑194548	Reply LS on SUCI computation from an NSI	Qualcomm Incorporated	LS out	Approval	Yes	Yes	approved	No		S3‑194335
		S3‑194319	Removing editor's note on capturing all the details for alternative authentication methods	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑194549
		S3‑194549	Removing editor's note on capturing all the details for alternative authentication methods	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑194319
		S3‑194409	Authentication of a TSC enabled UE	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesQualcomm: "specified in this document". We refer to requirements that are all over the document. Orange: specify clause 6.1. This had to be taken offline. Editorial corrections. MCC commented: Just "UE" and not "5GS UE".	revised	No	S3‑194550
		S3‑194550	Access security for a TSC-enabled UE	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑194409
		S3‑194424	UP security in TSC	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑194553	S3‑194410
		S3‑194553	UP security in TSC	Nokia, Nokia Shanghai Bell,Huawei	CR	Agreement	Yes	Yes	agreed	No		S3‑194424
		S3‑194093	DraftCR_TSC protection	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	merged	No	S3‑194553
		S3‑194386	CAG cell access check	Samsung	draftCR	Approval	Yes	YesNokia, Huawei, Ericsson objected to this.	noted	No
		S3‑194404	CAG ID privacy	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194164	CAG ID privacy	Huawei, Hisilicon	draftCR	Approval	Yes	YesOpen depending on the agreements on the CAG ID privacy.	noted	No
		S3‑194410	UP security in TSC	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑194424
		S3‑194459	Adding TSC abbreviation	Nokia	CR	Agreement	Yes	Yes	agreed	No
7.8	Security of the enhancement to the 5GC location services	S3‑194150	Draft CR as a living baseline for 5GS LCS normative work	CATT	draftCR	Approval	Yes	YesLiving document used as a baseline for the contributions in this meeting.	revised	No	S3‑194465
		S3‑194465	Draft CR as a living baseline for 5GS LCS normative work	CATT	draftCR	Approval	Yes	Yes	approved	No		S3‑194150
		S3‑194153	Draft CR for eLCS on access point security	CATT	draftCR	Approval	Yes	Yes	merged	No	S3‑194466
		S3‑194090	resolving editor's note on the move of access point	Huawei, Hisilicon	draftCR	Approval	Yes	YesEricsson: moving the access point is not relevant here.Huawei conceded to go for Ericsson's proposal for the resolution of the second editor's note. Qualcomm: All release 16 Ues don’t have to support this. Clarify that it is optional.	merged	No	S3‑194466
		S3‑194271	Resolving ENs in Draft CR as a living baseline for 5GS LCS normative work	Ericsson	draftCR	Approval	Yes	YesNokia supported this solution but didn’t see why changing "should" to "shall". Ericsson: what to do if the UE doesn’t receive this lst? In this case the UE would not be able to send its location for emergency purposes. Nokia didn’t agree with mandating this behaviour. This was taken offline.	revised	No	S3‑194466
		S3‑194466	Resolving ENs in Draft CR as a living baseline for 5GS LCS normative work	Ericsson,Huawei,CATT	draftCR	Approval	Yes	Yes	approved	No		S3‑194271
7.9	Security Aspects of the 5G Service Based Architecture (Rel-16)	S3‑193943	Reply LS on eSBA NF Set	S2-1910148	LS in		Yes	Yes	noted	No
		S3‑194250	Editorials and corrections to Security requirements for SeCoP	Ericsson	draftCR	Approval	Yes	Yes	revised	No	S3‑194517
		S3‑194517	Editorials and corrections to Security requirements for SeCoP	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194250
		S3‑194367	TLS between NF and SEPP based on custom HTTP header	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑194518
		S3‑194518	TLS between NF and SEPP based on custom HTTP header	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑194367
		S3‑194256	Security for roaming interfaces in indirect communication	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑194519
		S3‑194519	Security for roaming interfaces in indirect communication	Ericsson,Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑194256
		S3‑194370	Mutual authentication between Network Functions	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194520	Mutual authentication between Network Functions	Nokia, Nokia Shanghai Bell	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑194372	NF consumer authentication by the producer in direct communication scenarios	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194521	NF consumer authentication by the producer in direct communication scenarios	Nokia, Nokia Shanghai Bell	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑194252	Using Rel-15 token-based authorization in indirect communication scenarios	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194522	Using Rel-15 token-based authorization in indirect communication scenarios	Ericsson	draftCR	Agreement	No	Yes	left for email approval	No
		S3‑194187	Service access authorization of a NF Set	Huawei, Hisilicon	draftCR	Approval	Yes	YesContent is moved to the CR in 523.	noted	No
		S3‑194523	Service access authorization of a NF Set	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑194365	Resource Level Authorization using Access Tokens	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesCompeting contribution in 261. Huawei:The key issue in the TR (number 29) is not concluded yet. 365, 261 were taken offline since they depended on the outcome of the key issue.	merged	No	S3‑194659
		S3‑194261	Resource Level Authorization using Access Tokens	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194659	Resource Level Authorization using Access Tokens	Ericsson,Nokia	draftCR	Agreement	No	Yes	left for email approval	No
		S3‑194430	Commenting contribution on S3-194261 – Resource Level Authorization using Access Tokens	Nokia, Nokia Shanghai Bell	discussion	Information	Yes	Yes	noted	No
		S3‑194262	Authorization using Access Tokens based on NF-Subtype	Ericsson	CR	Agreement	Yes	YesNokia: the key issue is still open. This was left open depending on the outcome of the key issue.	not pursued	No
		S3‑194376	SBA Network Function TLS certificate profile	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194524	SBA Network Function TLS certificate profile	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesThis draftCR will be used as a baseline for discussions and it will be brought back next meeting.	noted	No
		S3‑194374	TLS entity certificate profile for SBA	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesHuawei: this is too early. BT: TLS profiles defined in 33.210 already? MCC added that a draftCR would be more appropriate in order to introduce content with latercontributions, given that this CR was just introducing empty clauses. Nokia commented that there was only one meeting left before the freeze of Release 16.	not pursued	No
		S3‑194251	Editorials and corrections to Protection of N9 interface	Ericsson	draftCR	Approval	Yes	YesIt will go to tdoc 444.	approved	No
7.10	Authentication and key management for applications based on 3GPP credential in 5G (Rel-16)	S3‑194340	pCR: Adding UE – AF interface to the AKMA Reference Model	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑194160	Update on AKMA reference model	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesQualcomm: it should be an editor's note. China Mobile commented that this would mean that SA3 would have to resolve it and that wasn't necessary.	approved	No
		S3‑194127	AKMA network functions	Huawei, Hisilicon	pCR	Approval	Yes	YesOverlapping with tdoc 200. Qualcomm: we don’t need the AMF for RAN. Vodafone: why so many network functions interfacing here? It woud be an ideal point for an attack, creating a security hole. We should be cautious and connect what we absolutely need.	merged	No	S3‑194641
		S3‑194200	Add AAnF description into clause 4.2	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesQualcomm: requirements should go to the requirements clause, not here. Huawei: remove the editor's note.	revised	No	S3‑194641
		S3‑194641	Add AAnF description into clause 4.2	China Mobile, Nokia, Nokia Shanghai Bel, Huaweil	pCR	Approval	Yes	Yes	approved	No		S3‑194200
		S3‑194128	AKMA interface description	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: remove N1,N2. Qualcomm: Namf not needed for AKMA either.	revised	No	S3‑194642
		S3‑194642	AKMA interface description	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194128
		S3‑194129	AKMA security principles and requirements	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: lifetime of the keys is operators' decision.The first sentence of the last requirement was removed. Qualcomm and Orange didn’t agree with these requirements. Only the last sentence went into the merge.	merged	No	S3‑194643
		S3‑194201	Add content to clause 4.4	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑194643
		S3‑194643	Add content to clause 4.4	China Mobile, Nokia, Nokia Shanghai Bell,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑194201
		S3‑194272	Update of the key hierarchy	Ericsson	pCR	Approval	Yes	YesOverlapping with 341.	noted	No
		S3‑194341	pCR: pCR: Udpate of AKMA Key Hierarchy	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑194130	AKMA key management	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: explicit/implicit lifetime was clear in the context of the TR but not so clear here. An editor's note was added to explain these in the future.	revised	No	S3‑194644
		S3‑194644	AKMA key management	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194130
		S3‑194228	Clause 6.X – Deriving AKMA key during UE registration	Nokia, Nokia Shanghai Bell, China Mobile	pCR	Approval	Yes	YesQualcomm proposed two editor's notes on the association with the UE is FFS.	revised	No	S3‑194645
		S3‑194645	Clause 6.X – Deriving AKMA key during UE registration	Nokia, Nokia Shanghai Bell, China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑194228
		S3‑194229	Clause 6.Y – Deriving AF key for a specific Application function	Nokia, Nokia Shanghai Bell, China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑194156	Add Abrreviations to TS 33.535	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑193985	End-to-end security	KPN, China Mobile	pCR	Approval	Yes	YesIt will come back in the next meeting since it depends on other discussions.	noted	No
		S3‑194640	Draft TS 33.535	China Mobile	draft TS	Approval	No	Yes	left for email approval	No
7.11	Evolution of Cellular IoT security for the 5G System (Rel-16)	S3‑193927	Reply LS on NAS Aspects of Mobile-terminated Early Data Transmission	C1-195111	LS in		Yes	YesPart of this LS was addressed as a new LS sent from last SA3's meeting. Ericsson believed that there were still open issues and wanted to have minuted that they would bring contributions in the future to address them: "Ericsson has noted that the UP case is different ass the GUTI is not revealed in the uplink and may not need GUTI reallocation. Therefore, Ericsson may bring related contributions next meeting."	noted	No
		S3‑193928	Reply LS on Mobile-terminated Early Data Transmission	R2-1911603	LS in		Yes	YesNo actions for SA3.	noted	No
		S3‑193936	Reply LS on bulk authentication issue for IoT devices	R2-1911790	LS in		Yes	Yes	noted	No
		S3‑194426	Forwarding of Reply LS on GUTI allocation for 5G CIoT	C1-198560	LS in		Yes	Yes	noted	No
		S3‑193948	Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC	S2-1910789	LS in		Yes	Yes	replied to	No
		S3‑194482	Reply to: Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC	Huawei	LS out	approval	Yes	Yes	approved	No
		S3‑194098	Discussion on Security for truncation of 5G-S-TMSI	Huawei, Hisilicon	discussion	Endorsement	Yes	YesQualcomm: not a DoS issue. We can modify whatever messages in the middle and cause this DoS. Ericsson: the RAN cannot recreate the full 5G S-TMSI. Qualcomm: this does not introduce a new security issue. It was agreed not to describe the DoS attack in the LS.	noted	No
		S3‑194100	Reply LS to SA2 on Security Issue on 5G-S-TMSI Truncation Procedure	Huawei, Hisilicon	LS out	Approval	Yes	YesEricsson agreed with this LS with minor changes. Qualcomm didn’t agree with the DoS issue. The attack is based on man in the middle but it doesn’t lead to DoS.	noted	No
		S3‑194320	Reply LS to SA2 on RRC Connection Reestablishment for CP for NB-IoT	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑194242	DraftCR – Living document for supporting 5G CIoT security	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑194483
		S3‑194483	DraftCR – Living document for supporting 5G CIoT security	Ericsson	draftCR	Approval	No	Yes	left for email approval	No		S3‑194242
		S3‑194101	CIoT Title Modifications to draft CR	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑194236	[Draft CR] RRC Connection Re-Establishment for the control plane for NB-IoT radio access connected to 5GC	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑194484
		S3‑194484	[Draft CR] RRC Connection Re-Establishment for the control plane for NB-IoT radio access connected to 5GC	Ericsson,Huawei	other	Approval	Yes	Yes	approved	No		S3‑194236
		S3‑194099	Security Procedure for RRCConnectionRe-establishment Procedure for Control Plane Optimization for 5GS CIoT	Huawei, Hisilicon	draftCR	Approval	Yes	YesClarifications and additions needed to be discussed offline. Huawei argued that it was too early to add the false base station scenario as proposed by Ericsson.	merged	No	S3‑194484
		S3‑194102	Skeleton for Security handling in User Plane CIoT 5GS Optimization	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑194103	General for Security handling in User Plane CIoT 5GS Optimization	Huawei, Hisilicon	draftCR	Approval	Yes	YesEricsson wanted to align with the progress in RAN groups through the addition of two editor's notes.	revised	No	S3‑194485
		S3‑194485	General for Security handling in User Plane CIoT 5GS Optimization	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑194103
		S3‑194104	Security handling in Connection Suspend Procedure for User Plane CIoT 5GS Optimization	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	revised	No	S3‑194486
		S3‑194486	Security handling in Connection Suspend Procedure for User Plane CIoT 5GS Optimization	Huawei, Hisilicon	draftCR	Approval	Yes	YesRevised to address Ericsson's comments.	approved	No		S3‑194104
		S3‑194105	Security handling in Connection Resume in CM-IDLE with Suspend to a new ng-eNB for User Plane CIoT 5GS Optimization	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	revised	No	S3‑194487
		S3‑194487	Security handling in Connection Resume in CM-IDLE with Suspend to a new ng-eNB for User Plane CIoT 5GS Optimization	Huawei, Hisilicon	draftCR	Approval	Yes	YesAddressing Ericsson's comments. Disagreement on linking this to the results of the false base station topic.Huawei didn’t want to do any link but Ericsson claimed that there was relation with the message parameters exposed here (fro "source C-NRTI..to the end of Note 1).	approved	No		S3‑194105
		S3‑194106	Security handling in Connection Resume in CM-IDLE with Suspend to the same ng-eNB for User Plane CIoT 5GS Optimization	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑194323	RRC UE capability transfer procedure for CP only CIoT UEs	Qualcomm Incorporated	CR	Agreement	Yes	YesMCC argued that the CR was not introducing a correction but only adding an editor's note promising work. This was not adequate for a spec under change control and it would be better to bring the changes directly when the work in the study was mature. Qualcomm commented that without this editor's note 6.5.3 would It was proposed to add this to the living document and progress the work there; this was agreed. The CR was not pursued but the editor's note was added to the living document to continue the work there.	not pursued	No
		S3‑194237	[Draft CR] RRC Connection Resume and Suspend procedures for the user plane for NB-IoT radio access connected to 5GC	Ericsson	other	Approval	No	Yes	withdrawn	Yes
7.12	Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16)	S3‑194126	Living doc for 5WWC	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	revised	No	S3‑194529
		S3‑194529	Living doc for 5WWC	Huawei, Hisilicon	draftCR	Approval	No	Yes	left for email approval	No		S3‑194126
		S3‑194286	Introducing missing definitions of untrusted and trusted non-3GPP accesses	Ericsson	draftCR	Approval	Yes	YesConcerns on the skeleton structure as stated by Huawei. ORANGE had concerns on whether this clause was necessary according to the content.	revised	No	S3‑194530
		S3‑194530	Introducing missing definitions of untrusted and trusted non-3GPP accesses	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194286
		S3‑194287	Determining trust relationship in the UE	Ericsson	draftCR	Approval	Yes	Yes	revised	No	S3‑194531
		S3‑194531	Determining trust relationship in the UE	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194287
		S3‑194146	Removal of Editor’s Note and update of the Figure 6.Y.4-1	Lenovo, Motorola Mobility	draftCR	Approval	Yes	Yes	approved	No
		S3‑194113	Editorial change for trusted non-3GPP access	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	revised	No	S3‑194532
		S3‑194532	Editorial change for trusted non-3GPP access	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑194113
		S3‑194283	TNAP mobility using ERP	Ericsson	discussion	Endorsement	Yes	YesDiscussed together with tdoc 116.	noted	No
		S3‑194116	Using ERP for intra-TNAN mobility	Huawei, Hisilicon	draftCR	Approval	Yes	YesLenovo asked to postpone this in order to analize it with more detail.This topic will be brought back in the next meeting.	noted	No
		S3‑194114	Update content for trusted non-3GPP access	Huawei, Hisilicon	draftCR	Approval	Yes	YesNokia: not comfortable with enabling cyphering in IpSec.	revised	No	S3‑194533
		S3‑194533	Update content for trusted non-3GPP access	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑194114
		S3‑194284	Trusted access key hierarchy	Ericsson	draftCR	Approval	Yes	YesHuawei had some comments on the key names and this was left for offline discussion.	revised	No	S3‑194606
		S3‑194606	Trusted access key hierarchy	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194284
		S3‑194285	Trusted access key derivation	Ericsson	draftCR	Approval	Yes	Yes	revised	No	S3‑194607
		S3‑194607	Trusted access key derivation	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194285
		S3‑194115	Corrections on N5CW connects 5GC via trusted non-3GPP access	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑194608	Corrections on N5CW connects 5GC via trusted non-3GPP access	Huawei, Hisilicon	draftCR	Approval	No	Yes	withdrawn	Yes
		S3‑194117	Move Requirement of 5G-RG to clause 5	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	revised	No	S3‑194609
		S3‑194609	Move Requirement of 5G-RG to clause 5	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑194117
		S3‑194118	Delete an assumption sentence	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑194119	Add a new clause for N5CW privacy	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑194400	Removing ENs in annex X in the living document for 5WWC	CableLabs, Charter Communications,Lenovo, Motorola Mobility, EricssonRogers Communications, Nokia, Nokia Shanghai Bell,	CR	Approval	Yes	YesOrange: hard to understand what's new and what's existent. CableLabs: red text is new. Blue text is existent.	not pursued	No		S3‑194030
		S3‑194610	Removing ENs in annex X in the living document for 5WWC	CableLabs, Charter Communications,Lenovo, Motorola Mobility, EricssonRogers Communications, Nokia, Nokia Shanghai Bell,	draftCR	Approval	Yes	YesRevised to show better the changes with the revision marks.	approved	No
		S3‑194030	Removing ENs in annex X in the living document for 5WWC	CableLabs, Charter Communications, Rogers Communications, Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑194400
		S3‑194694	5WWC	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
7.13	Security aspects of Enhancement of Network Slicing (Rel-16)	S3‑193929	LS on network slice-specific authentication and authorization	C1-196903	LS in		Yes	YesNo action for SA3.	noted	No
		S3‑193953	LS on SG17 new work item X.nsom-sec “Security requirements and architecture for network slice orchestration and management”	ITU-T SG17	LS in		Yes	YesNo action for SA3.	noted	No
		S3‑193945	Reply LS on AUSF role in slice specific authentication	S2-1910668	LS in		Yes	Yes	postponed	No
		S3‑194535	Reply to: Reply LS on AUSF role in slice specific authentication	Ericsson	LS out	approval	Yes	YesNokia objected, as Telecom Italia, Orange. Ericsson, HP , Huawei, Interdigital supported this LS.	noted	No
		S3‑194054	Discussion on LS from SA2 on AUSF role	Huawei, HiSilicon	discussion	Agreement	Yes	YesNokia: proposal 2 is a big impact on the architecture. There is also a proxy in the SA2 call flow with the same functionality as the proposed new NF. Ericsson agreed with Nokia. HP agreed with Huawei's proposal. Nokia: security for the new slice specific authentication workflow is not broken from the security perspective. Huawei should go to SA2 to defend their proposal. This was taken offline.	noted	No
		S3‑193965	Draft for ‘proposed structure for network slice security procedures’	InterDigital Communications	draftCR	Approval	Yes	Yes	merged	No	S3‑194536
		S3‑194045	Add content to Clause X.X.2 of eNS	Huawei, HiSilicon	draftCR	Approval	Yes	Yes	revised	No	S3‑194536
		S3‑194536	Add content to Clause X.X.2 of eNS	Huawei, HiSilicon,Nokia,Ericsson, Interdigital	draftCR	Approval	Yes	Yes	approved	No		S3‑194045
		S3‑194214	DraftCR - Proposed flow for clarifying primary authentication steps	Ericsson	draftCR	Approval	Yes	Yes	merged	No	S3‑194536
		S3‑194058	Proposed text for clause x.2 of living CR for eNS	Nokia, Nokia Shanghai Bell	other	Approval	Yes	Yes	merged	No	S3‑194536
		S3‑194046	Amendment to Clause X.X.3 of Slice specific authentication procedure	Huawei, HiSilicon	draftCR	Approval	Yes	YesDiscussed together with 212. Nokia: This is not aligned with SA2.how does roaming work? Unclear how Every AMF in the network gets to the AAA proxy. Huawei replied that this was an SA2 issue. Ericsson: this solution doesn’t work. Qualcomm: align the message names properly in all steps.	merged	No	S3‑194537
		S3‑194212	DraftCR – Proposed call flow for Network Slice Specific Authentication and Authorization	Ericsson	draftCR	Approval	Yes	YesChina Mobile:NSSAI sent to the AAA server from network operator in step 7. NSSAI is a private part of the network's operator topology. Ericsson: this is needed in the AAA server for revocation procedures to work. Huawei disagreed, as there was alternative information that could be sent, some transformation of the information like done with the SUPI. Nokia was aligned with Ericsson. Nokia: no privacy sensitive information in the NSSAI today.	revised	No	S3‑194537
		S3‑194537	DraftCR – Proposed call flow for Network Slice Specific Authentication and Authorization	Ericsson,Huawei	draftCR	Approval	Yes	Yes	approved	No		S3‑194212
		S3‑194047	Note for the User ID privacy protection in Clause X.X.3	Huawei, HiSilicon	draftCR	Approval	Yes	YesNokia disagreed with the note.Orange commented that it should be a recommendation and not mandatory. It was also discussed whether it had to be a note or not. MCC commented that notes were informative, and any normative language (recommendation or requirement) could not be used in them. It was agreed to make it plain text and have it as a recommendation.	revised	No	S3‑194538
		S3‑194538	Note for the User ID privacy protection in Clause X.X.3	Huawei, HiSilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑194047
		S3‑194048	Discussion on Authentication method negotiation	Huawei, HiSilicon	discussion	Endorsement	Yes	YesNokia,Qualcomm: we don’t need this.Ericsson agreed ith them, that if this was needed, it would be related to the AAA server.	noted	No
		S3‑194049	Authentication method negotiation	Huawei, HiSilicon	draftCR	Approval	Yes	Yes	noted	No
		S3‑194213	DraftCR - Proposed flow for Re-authentication and Re-authorization	Ericsson	draftCR	Approval	Yes	YesNokia: early to adopt this. Add an editor's note. Ericsson replied that SA3 needed to send these flows to SA2, so an editor's note may not be approriate. Huawei: reference to the SA2 document instead of copying the whole content from SA2. What if they update their part? Qualcomm agreed, no need to have a duplication in both groups since SA2 and SA3 could be updating the same text differently.The Chair agreed that this was a general problem and it needed to be discussed further. SA3 should make sure that work is not duplicated by communicating changes to SA2. This was taken offline.	revised	No	S3‑194539
		S3‑194539	DraftCR - Proposed flow for Re-authentication and Re-authorization	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194213
		S3‑194215	DraftCR – Proposing a new AUSF service to support NSSAA flow	Ericsson	draftCR	Approval	Yes	YesThis depends on the outcome of the discussion on the AUSF involvement (LS in 535). Taken offline to address the	revised	No	S3‑194540
		S3‑194540	DraftCR – Proposing a new AUSF service to support NSSAA flow	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194215
		S3‑194541	Living document on slice specific authentication procedures	Nokia	draftCR	Approval	No	Yes	left for email approval	No
7.14	Security for NR Integrated Access and Backhaul (Rel-16)	S3‑194368	Requirements for Secure environment of the IAB node	Samsung	draftCR		Yes	YesEricsson, Orange: reference this clause from the annex.	revised	No	S3‑194594
		S3‑194594	Requirements for Secure environment of the IAB node	Samsung	draftCR	-	Yes	Yes	approved	No		S3‑194368
		S3‑194274	[Draft CR] Security requirements for F1 interface	Ericsson	draftCR	Approval	Yes	Yes	approved	No
		S3‑194275	[Draft CR] Security requirements on the IAB node, IAB donor and 5GC supporting IAB architecture	Ericsson	draftCR	Approval	Yes	YesQualcomm: IAB donor instead of parent IAB.	revised	No	S3‑194595
		S3‑194595	[Draft CR] Security requirements on the IAB node, IAB donor and 5GC supporting IAB architecture	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194275
		S3‑194369	IAB-node integration procedure	Samsung	draftCR	Approval	Yes	YesNokia: phases are related to the deployment. Samsung replied that this was a security sequence and not related to the deployment phase. Orange agreed that this was confusing. Nokia added that additional text should be Samsung: this is not new, this is part of definitions given in RAN. MCC commented that the last paragraph didn’t seem appropriate for a general clause since it was introducing requirements. In addition to this, it looked like a requirement was given to the attackers as well.	revised	No	S3‑194597
		S3‑194597	IAB-node integration procedure	Samsung,Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194369
		S3‑194277	[Draft CR] General introduction to IAB-node Integration Procedure	Ericsson	draftCR	Approval	Yes	Yes	merged	No	S3‑194597
		S3‑194371	IAB-UE part set-up procedure	Samsung	draftCR	Approval	Yes	Yes	revised	No	S3‑194598
		S3‑194598	IAB-UE part set-up procedure	Samsung,Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194371
		S3‑194278	[Draft CR] Authentication of IAB nodes	Ericsson	draftCR	Approval	Yes	Yes	merged	No	S3‑194598
		S3‑194279	[Draft CR] Authorization of IAB nodes	Ericsson	draftCR	Approval	Yes	Yes	merged	No	S3‑194598
		S3‑194276	[Draft CR] Security mechanisms for the F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU	Ericsson	draftCR	Approval	Yes	Yes	noted	No
		S3‑194373	F1 interface set-up procedure	Samsung	draftCR	Approval	Yes	Yes	noted	No
		S3‑194280	[Draft CR] Update of general introduction to IAB	Ericsson	draftCR	Approval	Yes	Yes	approved	No
		S3‑194281	Draft CR - Security for Integrated Access and Backhaul in EN-DC	Ericsson	draftCR	Approval	Yes	Yes	merged	No	S3‑194599
		S3‑194375	Solution for IAB Architecture	Samsung	draftCR	Approval	Yes	YesORANGE: Requirements for subscription credential storage are not in TS 33.401 but in a CT spec. This was taken offline.	revised	No	S3‑194599
		S3‑194599	Solution for IAB Architecture	Samsung .Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑194375
		S3‑194417	[Draft CR]Solution for IAB Architecture (Baseline version)	Samsung	draftCR	Approval	Yes	Yes	revised	No	S3‑194596
		S3‑194596	[Draft CR]Solution for IAB Architecture (Baseline version)	Samsung	draftCR	Approval	No	Yes	left for email approval	No		S3‑194417
7.15	Security aspects of SEAL (Rel-16)	S3‑194387	Skeleton for SEAL TS 33.434	Samsung	pCR	Approval	Yes	YesMotorola proposed some changes in the structure of the TS.	revised	No	S3‑194627
		S3‑194627	Skeleton for SEAL TS 33.434	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑194387
		S3‑194388	Scope for SEAL TS 33.434	Samsung	pCR	Approval	Yes	YesTim (Motorola) suggested to add more wording to extend the scope.	revised	No	S3‑194628
		S3‑194628	Scope for SEAL TS 33.434	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑194388
		S3‑194389	Adding reference, term, abbreviation to the SEAL TS 33.434	Samsung	pCR	Approval	Yes	Yes	revised	No	S3‑194629
		S3‑194629	Adding reference, term, abbreviation to the SEAL TS 33.434	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑194389
		S3‑194390	Security requirements for SEAL	Samsung	pCR	Approval	Yes	YesOrange: differences between the different services written here? They seem to be three different services. The VAL service is not defined. Motorola provided a few more comments that had to be taken offline.	revised	No	S3‑194631
		S3‑194631	Security requirements for SEAL	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑194390
		S3‑194391	Security for SEAL interfaces	Samsung	pCR	Approval	Yes	YesMotorola asked to add an editor's note on additional references needed to align with the SA6 specification.The terminology also needed to be aligned with the SA6 architecture.	revised	No	S3‑194632
		S3‑194632	Security for SEAL interfaces	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑194391
		S3‑194392	VAL user authentication and authorization	Samsung	pCR	Approval	Yes	YesHuawei commented that this was quite a large content and asked to have more time to review it properly. Motorola also had numerous comments. Samsung replied that they would bring back this and the following contributions for the next meeting (addressing the comments from the companies).	noted	No
		S3‑194393	Security procedure for S-KMC and S-KMS	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑194394	Annex X: OpenID Connect	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑194395	Annex Y for TS 33.434	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑194630	Draft TR 33.434	Samsung	draft TS	Approval	Yes	Yes	approved	No
7.16	Security Aspects of 3GPP support for Advanced V2X Services (Rel-16)	S3‑193939	LS on PC5-S Signaling and PC5-RRC connection for NR sidelink communication	R2-1914151	LS in		Yes	Yes	noted	No
		S3‑194248	pCR for eV2X TS	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑194613
		S3‑194312	Proposed text for the early clauses for V2X TS	Qualcomm Incorporated, LG Electronics	other	Approval	Yes	Yes	approved	No
		S3‑194614	Proposed text for the early clauses for V2X TS	Qualcomm Incorporated, LG Electronics	other	Approval	No	Yes	withdrawn	Yes
		S3‑194313	Proposed text for security for V2X over Uu reference point clause	Qualcomm Incorporated, LG Electronics	other	Approval	Yes	Yes	revised	No	S3‑194615
		S3‑194615	Proposed text for security for V2X over Uu reference point clause	Qualcomm Incorporated, LG Electronics,Ericsson	other	Approval	Yes	Yes	approved	No		S3‑194313
		S3‑194314	Proposed inclusion of groupcast and broadcast privacy solutions	Qualcomm Incorporated, LG Electronics	other	Approval	Yes	Yes	revised	No	S3‑194613
		S3‑194613	Proposed inclusion of groupcast and broadcast privacy solutions	Qualcomm Incorporated, LG Electronics,Ericsson	other	Approval	Yes	Yes	approved	No		S3‑194314
		S3‑194605	Notes on the V2X offline session	NTT-Docomo	report	Information	Yes	Yes	noted	No
		S3‑194625	Draft TS 33.xyz on V2X	Lge	other	Approval	No	Yes	left for email approval	No
7.17	User Plane Gateway Function for Inter-PLMN Security (Rel-16)	S3‑194399	Source IP address range check for UPGF	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesJuniper networks: remove "that intercepts outgoing GTP-U traffic originated from a UPF". Ericsson added that in fact the whole paragraph was not needed. Docomo: which source address are you referring to? This was taken offline.	revised	No	S3‑194463
		S3‑194463	Source IP address range check for UPGF	Nokia, Nokia Shanghai Bell	draftCR	Approval	No	Yes	merged	No	S3‑194443	S3‑194399
		S3‑194397	UPGF - Align with Inter PLMN UP Security Function (IPUPS)	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesHuawei, Juniper: bring back the first sentence. Docomo: don’t change the acronym. This was finally noted.	noted	No
7.18	Provision of Access to Restricted Local Operator Services by Unauthenticated UEs – Security Aspects (Rel-16)	S3‑194337	Security aspects of RLOS	Qualcomm Incorporated	CR	Agreement	Yes	YesNokia: delete "manufactring time" from step 3. Vodafone: "where RLOS are supported"? Qualcomm replied that it referred to the regions where RLOS was supported. ORANGE commented on step 3 that the integrity of the white list was not ensured. It was agreed to bring back the manufacturing time and make it more strict. Orange: what is "valid USIM" in step 4? Qualcomm replied that if there is a USIM present with a ISIM that matches the MCC. It was agreed to remove "valid".	revised	No	S3‑194633
		S3‑194633	Security aspects of RLOS	Qualcomm Incorporated	CR	Agreement	Yes	YesThe last sentence on the whitelist had to be discussed internally in MCC. If necessary, it would be modified in the next SA plenary directly.	agreed	No		S3‑194337
7.19	Other work areas
7.19.1	SAE/LTE Security	S3‑193968	33401-CR on CHO key derivation	Apple	CR	Approval	Yes	YesDepending on the discussion for 448.	revised	No	S3‑194602
		S3‑194602	33401-CR on CHO key derivation	Apple	CR	Approval	Yes	Yes	not pursued	No		S3‑193968
7.19.2	IP Multimedia Subsystem (IMS) Security
7.19.3	Network Domain Security (NDS)
7.19.4	UTRAN Network Access Security
7.19.5	GERAN Network Access Security
7.19.6	Generic Authentication Architecture (GAA)
7.19.7	Security Aspects of Home(e)NodeB (H(e)NB)
7.19.8	Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)	S3‑193923	[MCPTT] 33179 R13 Missing Abbreviations	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193920	[MCSec] 33180 R14 Missing Abbreviations	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193917	[eMCSec] 33180 R15 Missing Abbreviations (Mirror)	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193993	[33.180] R14 - Fix bad reference	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑193994	[33.180] R15 Fix bad reference (mirror)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑193924	[MCPTT] 33179 R13 Reference Addition	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193921	[MCSec] 33180 R14 Reference Addition (Mirror)	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193918	[eMCSec] 33180 R15 Reference Addition (Mirror)	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193925	[MCPTT] 33179 R13 Correction concerning IdM client	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193922	[MCSec] 33180 R14 Correction concerning IdM client (Mirror)	Airbus	CR	Agreement	Yes	Yes	agreed	No
		S3‑193919	[eMCSec] 33180 R15 Correction concerning IdM client (Mirror)	Airbus	CR	Agreement	Yes	Yes	agreed	No
7.19.9	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑194299	33.216 Corrections for clean-up and alignment R15	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesFuturewei disagreed with the removal of the test cases since those were being used. China Mobile: why removing 4.2.7? We care about the functional requirements. Futurewei preferred not to see editor's notes and it was asked to minute that the execution steps for Uu reference point in the test case in sub-clause 4.2.2.1.3 needed to be added.	revised	No	S3‑194480
		S3‑194480	33.216 Corrections for clean-up and alignment R15	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑194299
		S3‑194300	33.216 Corrections for clean-up and alignment R16	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesNokia asked to minute the following comment: "The execution steps for Uu reference point in the test case in sub-clause 4.2.2.1.3 need to be added."	revised	No	S3‑194481
		S3‑194481	33.216 Corrections for clean-up and alignment R16	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑194300
7.19.10	Security Aspects of Narrowband IOT (CIoT)	S3‑193938	Reply LS on Handling of UE radio network capabilities in 4G and 5G	R2-1911850	LS in		Yes	Yes	replied to	No
		S3‑194075	Reply LS on Handling of UE radio network capabilities in 4G and 5G	Intel Corporation (UK) Ltd	LS out		Yes	YesQualcomm and Huawei agreed with this reply. Qualcomm added that it should be mentioned that SA3 was still studying this issue. This had to be taken offline as Nokia had issues with the reply to question 1.	revised	No	S3‑194488
		S3‑194488	Reply LS on Handling of UE radio network capabilities in 4G and 5G	Intel Corporation (UK) Ltd	LS out	-	Yes	Yes	approved	No		S3‑194075
		S3‑194241	DRAFT Reply LS on Handling of UE radio network capabilities in 4G and 5G	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑194243	Security of RRC UE capability transfer procedure in EPS	Ericsson	CR	Approval	Yes	YesQualcomm: release 16 new feature, so we should wait for the results of the study to be completed. Ericsson: EPS is not part of the study, this is a different issue. Nokia: this is something new for legacy (LTE) Ues. Qualcomm: we want the same mechanism as 5G in here, but let's wait until the study is finished. Huawei agreed with this.	not pursued	No
		S3‑194244	RRC Connection Resume and Suspend procedures	Ericsson	CR	Approval	Yes	YesNokia wanted to add more text to make it clear. They agreed with the change. Ericsson didn’t find this necessary. Nokia promised to bring a CR next time to propose	agreed	No
		S3‑194245	RRC Connection Resume and Suspend procedures	Ericsson	CR	Approval	Yes	Yes	agreed	No
7.19.11	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)
7.19.12	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.19.13	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
7.19.14	PLMN RAT selection (Steering of Roaming) (Rel-15)	S3‑193931	LS on Clarification on the requirement for steering of roaming	C1-197001	LS in		Yes	YesNo action for SA3.	noted	No
7.19.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
7.19.16	Other work items	S3‑194263	Certificate and CRL profile update	Ericsson	CR	Agreement	Yes	YesHuawei asked these group of CRs to be postponed for the next meeting. MCC commented that the notes were not appropriate as they were predicting the prohibition of features in future 3GPP releases.	not pursued	No
		S3‑194264	TLS Recommended Cipher Suites	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194265	Required TLS extenstions and algorithms	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194266	IKEv2 profile update 33.210	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194267	IKEv2 profile update 33.310	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑194268	Using EAP-TLS with TLS 1.3	Ericsson	CR	Agreement	Yes	YesOrange commented that Annex B was informative so the normative text could not be ntroduced here.	not pursued	No
7.20	New work item proposals	S3‑193913	New WID on Security Aspects of PARLOS	SPRINT Corporation	WID new	Agreement	Yes	Yes	revised	No	S3‑194525
		S3‑194525	New WID on Security Aspects of PARLOS	SPRINT Corporation	WID new	Agreement	Yes	Yes	agreed	No		S3‑193913
		S3‑193979	New WID on eV2X security	LG Electronics Inc.	WID new	Approval	Yes	Yes	revised	No	S3‑194468
		S3‑194468	New WID on eV2X security	LG Electronics Inc.	WID new	Approval	Yes	YesORANGE: the requirements in TR 33.836 are potential, don’t refer to this TR and stick to the TS as a base. Editorial comments from MCC.	agreed	No		S3‑193979
		S3‑193982	Skeleton for TS on eV2X	LG Electronics Inc.	discussion	Agreement	Yes	YesHuawei: 5.2.2 gives the impression that the privacy requirements are the most important. They are part of the security requirements. Article19 objected to removing privacy from the tile of clause 5.2.2. Huawei didn’t agree with keeping it in the title.	revised	No	S3‑194526
		S3‑194526	Skeleton for TS on eV2X	LG Electronics Inc.	other	Approval	Yes	Yes	approved	No		S3‑193982
		S3‑194180	New WID: Work Item on Security Assurance Specification for IMS	Huawei, Hisilicon	WID new	Approval	Yes	YesORANGE: why excluding the IMS Access Gateway from the scope of the WID? Huawei commented that they were open to other network elements. It was agreed to generalize this. It was clarified that this affected Release 17 (wrong templated used for this WID). Nokia: SCAS for 5G or LTE? In SA2 they are working on IMS for 5G. ORANGE: this is SCAS for the previous Release, as we always do. This is SCAS for Release 15.	revised	No	S3‑194527
		S3‑194527	New WID: Work Item on Security Assurance Specification for IMS	Huawei, Hisilicon	WID new	Approval	Yes	Yes	agreed	No		S3‑194180
		S3‑194269	New WID on 3GPP profiles for cryptographic algorithms and IETF protocols	Ericsson	WID new	Agreement	Yes	YesQualcomm: remove PFS objective and justification. NCSC: bullets look like key issues or solutions rather than objectives. Ericsson clarified that there were CRs for this meeting already, but with the WID TEI16 (to be changed to DUMMY).	revised	No	S3‑194528
		S3‑194528	New WID on 3GPP profiles for cryptographic algorithms and IETF protocols	Ericsson	WID new	Agreement	Yes	Yes	agreed	No		S3‑194269
8	Studies
8.1	Study on Security Aspects of the 5G Service Based Architecture	S3‑194167	eSBA: conclusion update on KI #22	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194380	Discussion paper on authorization for Model D Indirect communications	Nokia, Nokia Shanghai Bell	discussion	Agreement	Yes	Yes	noted	No
		S3‑194382	Update to conclusion on Key issue #22: Authorization of NF service access in indirect communication	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑194255	Update to conclusion on Key issue #23: NF to NF authentication and authorization in Indirect communication	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑194504	Update to conclusion on Key issue #23: NF to NF authentication and authorization in Indirect communication	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194194	Security requirement on Key Issue #24: service access authorization of a NF Set	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194505
		S3‑194505	Security requirement on Key Issue #24: service access authorization of a NF Set	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194194
		S3‑194192	Evaluation on service access authorization of a NF Set in non-roaming scenario	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194506
		S3‑194506	Evaluation on service access authorization of a NF Set in non-roaming scenario	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194192
		S3‑194193	Evaluation on service access authorization of a NF Set in roaming scenario	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194507
		S3‑194507	Evaluation on service access authorization of a NF Set in roaming scenario	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194193
		S3‑194186	Conclusion on service access authorization of a NF Set	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194508
		S3‑194508	Conclusion on service access authorization of a NF Set	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194186
		S3‑194425	Update on solution#15 in TR 33.855	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194509	S3‑194183
		S3‑194509	Update on solution#15 in TR 33.855	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194425
		S3‑194185	Conclusion on authorization in the delegated Subscribe-Notify interaction scenarios	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194253	Conclusion of Key Issue #28: Service access authorization in the delegated "Subscribe-Notify" scenarios	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑194165	New KI: Service access authorization for non-delegated subscribe-notify	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194510
		S3‑194510	New KI: Service access authorization for non-delegated subscribe-notify	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194165
		S3‑194182	New solution for authorization in the non-delegated "Subscribe-Notify" interaction scenarios	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194511
		S3‑194511	New solution for authorization in the non-delegated "Subscribe-Notify" interaction scenarios	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194182
		S3‑194184	Conclusion on authorization in the non-delegated Subscribe-Notify interaction scenarios	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194168	eSBA: conclusion update on KI #29	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194512
		S3‑194512	eSBA: conclusion update on KI #29	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No		S3‑194168
		S3‑194258	New Key issue on NF subtypes for authorization granularity	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑194513
		S3‑194513	New Key issue on NF subtypes for authorization granularity	Ericsson	pCR	Approval	Yes	Yes	noted	No		S3‑194258
		S3‑194259	Update of Solution #32: OAuth 2.0 based resource level authorization of NF service consumers	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑194260	Conclusion on NF subtypes for authorization granularity	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑194166	eSBA: add conclusion on KI #5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194254	Conclusion for Key Issue #5 "NF-NF Authorization"	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑194514
		S3‑194514	Conclusion for Key Issue #5 "NF-NF Authorization"	Ericsson	pCR	Approval	Yes	Yes	noted	No		S3‑194254
		S3‑194257	Removal of Editor's Notes for Security of indirect communication in roaming scenarios	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑194515
		S3‑194515	Removal of Editor's Notes for Security of indirect communication in roaming scenarios	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194257
		S3‑194183	Update on solution#15 in TR 33.855	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194425
		S3‑194503	Notes from the eSBA break out session	NTT-Docomo	report	Information	Yes	Yes	noted	No
		S3‑194516	Draft TR 33.855	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
8.2	Study on Authentication and key management for applications based on 3GPP credential in 5G	S3‑193984	Update to Key Issue #6	KPN, China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑194209	Conclusion on end to end security	China Mobile, KPN	pCR	Approval	Yes	YesEricsson: you are proposing an informative annex for normative work. KPN: we want it normative and if this is not agreed it would become informative. Vodafone: this text is not an evaluation or a conclusion. Qualcomm: this is not part of AKMA. It's pat of the interface between UE and application function. This had to be taken offline.	revised	No	S3‑194636
		S3‑194636	Conclusion on end to end security	China Mobile, KPN	pCR	Approval	Yes	Yes	approved	No		S3‑194209
		S3‑194273	Conclusions on Key Management	Ericsson	pCR	Approval	Yes	YesChina Mobile: The case of the reauthentication being not successful is not clear to me. Ericsson replied that this wasn't a reauthentication but another authentication decided by the network, a subsequent authentication. Huawei didn’t agree with this. Taken offline.	revised	No	S3‑194637
		S3‑194637	Conclusions on Key Management	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194273
		S3‑194170	Editoral changes on solution for AKMA change	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: make sure to mention all ocurrences of security contexts here.	revised	No	S3‑194638
		S3‑194638	Editoral changes on solution for AKMA change	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194170
		S3‑194171	Resolving the editor’s notes in the solution of AKMA change	Huawei, Hisilicon	pCR	Approval	Yes	YesQualcomm didn’t agree with this evaluation. No need for two PUSH solutions since SA3 had already a GBA Push work item ongoing. Vodafone supported this.	noted	No
		S3‑194172	AKMA: add conclusion on KI #17	Huawei, Hisilicon	pCR	Approval	Yes	YesTaken offline whether it will have one or two Push solutions.	noted	No
		S3‑194639	AKMA: add conclusion on KI #17	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194210	Add abbreviations and editorial changes to TR 33.835	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑194217	Cover sheet TR 33.835 for approval	China Mobile	TS or TR cover	Approval	Yes	YesVodafone objected sending this document for approval during the current meeting. The document was clashing with other existing specs and Vodafone needed more time to evaluate the TR. China Mobile commented that the completion was above 80% already. Vodafone added that the specification needed to go to EditHelp as well. Vodaone had a sustained objection. They were the only one. NTT-Docomo: there are numerous editor's notes and this should be mentioned in the outstanding issues. Orange: write cleanup in the outstanding issues. Mauro (TIM): if the group agrees on a needed cleanup what's the rush for sending this now instead of the next meeting? China Mobile: SA should know that we have done 80% of the work. BT found it better to delay and joined Vodafone. The Chair commented that the next meeting would focus especially on normative work and that the group would be under a lot of pressure to finish release 16.	revised	No	S3‑194695
		S3‑194695	Cover sheet TR 33.835 for approval	China Mobile	TS or TR cover	Approval	Yes	YesNTT-Docomo commented that they preferred not to spend more time discussing this and send it for approval. Qualcomm: it is clearly more than 80% completed. Lenovo supported sending this for approval. Nokia: let's focus on the TS. ZTE supported sending it for approval. Sending the TR for approval, show of hands: Vodafone objected. Support sending it for approval: Ericsson Apple, ZTE, Huawei,KPN,Lenovo,Qualcomm, Nokia,China Mobile. The Chair decided to send it for approval anyway but warned the delgates that Vodafone could object in plenary and in that case it would be probably brought back to SA3.	approved	No		S3‑194217
		S3‑193983	Update to Key Issue #6	KPN, China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194216	Cover sheet TR 33.835	China Mobile International Ltd	TS or TR cover	Approval	No	Yes	withdrawn	Yes
		S3‑194635	Draft TR 33.835	China Mobile	draft TR	Approval	No	Yes	left for email approval	No
8.3	Study on Evolution of Cellular IoT security for the 5G System	S3‑194240	Removal of three obsolete Editor’s Notes	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193991	KI 14 Potential Security Requirement	NIST, ATT, Sprint Corporation, CableLabs, Deutsche Telekom AG, Cisco	pCR	Approval	Yes	YesEricsson: data format is not security related. NIST: the key issue is on communication in the user plane and prevent any communication that falls outside that scope. Ericsson: we assumed that this key issue should be left without security requirements, and concluded since there is a lot more to be evaluated; the study has continued for way too long.	revised	No	S3‑194490
		S3‑194490	KI 14 Potential Security Requirement	NIST, ATT, Sprint Corporation, CableLabs, Deutsche Telekom AG, Cisco	pCR	Approval	Yes	YesReivsed to re-formulate the security requirement.	approved	No		S3‑193991
		S3‑194080	Updates to Key issue Protection of UE capability transfer for UEs without AS security	Intel Corporation (UK) Ltd	pCR		Yes	Yes080,087,238,324 overlap in this issue.	revised	No	S3‑194491
		S3‑194491	Updates to Key issue Protection of UE capability transfer for UEs without AS security	Intel Corporation (UK) Ltd,Qualcomm,Huawei,Ericsson	pCR	-	Yes	Yes	approved	No		S3‑194080
		S3‑194087	Add the threat and requirement in KI#15	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑194491
		S3‑194238	KI#15 - new requirement for handling UEs without AS security	Ericsson	pCR	Approval	Yes	YesQualcomm: requirement too vague.	merged	No	S3‑194491
		S3‑194324	Security Requirement for KI #15	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑194491
		S3‑193992	New Solution for KI #14	NIST, ATT, Sprint, CableLabs, Deutsche Telekom AG, Cisco	pCR	Approval	Yes	YesEricsson: several editor's notes are needed since this solution is not complete: how it fits into the 3GPP network, how it interacts with the 3GPP elements. Huawei: remove the evaluation part, as it should be evaluated in SA2. Ericsson was also sceptical about this solution as it would require a lot of work and the timeline would not allow to fully study this part. Qualcomm: SA2 study is in Release 17 and this is for Release 16.	revised	No	S3‑194492
		S3‑194492	New Solution for KI #14	NIST, ATT, Sprint, CableLabs, Deutsche Telekom AG, Cisco	pCR	Approval	Yes	Yes	approved	No		S3‑193992
		S3‑194088	Protection of UE capability transfer for CP optimization only CIoT UE	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: System impact, on the NAS protocol, UE capability exchange, etc..An editor's note was added about this. Qualcomm, Ericsson had issue with the evaluation part. This was taken offline.	revised	No	S3‑194493
		S3‑194493	Protection of UE capability transfer for CP optimization only CIoT UE	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194088
		S3‑194079	Security solution for UE Capability Transfer for UE with no AS security.	Intel Corporation (UK) Ltd	pCR		Yes	YesNokia: this changes the behaviour of the base station. Ericsson: this procedure between the RAN and the core network is totally new. Intel agreed to add an editor's note on this.	revised	No	S3‑194494
		S3‑194494	Security solution for UE Capability Transfer for UE with no AS security.	Intel Corporation (UK) Ltd	pCR	-	Yes	YesRemoving steps 1-3. Editor's note on the new call flow RAN- core network. Evaluation was removed as proposed by Qualcomm.	approved	No		S3‑194079
		S3‑194325	AMF verification of the UE radio capabilities for CP optimization only CIoT UE	Qualcomm Incorporated	pCR	Approval	Yes	YesIntel: Hash seems to be sent in the initial request in an open message, add an editor's note. Qualcomm replied that it was mandatorily protected. Ericsson: step 3 might happen before step 2, not ensured that steps happen in this order. This was taken offline.	revised	No	S3‑194495	S3‑193391
		S3‑194495	AMF verification of the UE radio capabilities for CP optimization only CIoT UE	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑194325
		S3‑194239	KI#15 - new solution for handling UEs without AS security	Ericsson	pCR	Approval	Yes	YesQualcomm: this doesn't mitigate the threat. Intel agreed with Qualcomm. Qualcomm: UE capability never verified by the network.	approved	No
		S3‑194496	KI#15 - new solution for handling UEs without AS security	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194326	Hash based UE capability protection for CP optimization only CIoT UE	Qualcomm Incorporated	pCR	Approval	Yes	YesIntel: in the Power ON scenario the initial registration request is sending the hash unprotected.. Ericsson: what happens if there is a mismatch? Huawei also had some issues, so these comments were taken offline.	revised	No	S3‑194497	S3‑193390
		S3‑194497	Hash based UE capability protection for CP optimization only CIoT UE	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑194326
		S3‑194235	Proposed conclusion to KI#1	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑194498
		S3‑194498	Proposed conclusion to KI#1	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194235
		S3‑194234	Proposed revision of conclusion to KI#2	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑194233	Proposed conclusion to KI#3	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑194246	Proposed conclusion to KI #14	Ericsson	pCR	Approval	Yes	YesLeft open since it depended on the discussion about key issue 14.	revised	No	S3‑194604
		S3‑194604	Proposed conclusion to KI #14	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194246
		S3‑194077	Conclusion for Key issue 15	Intel Corporation (UK) Ltd	pCR		Yes	Yes	noted	No
		S3‑194489	draft TR 33.861	Ericsson	draft TR	Approval	No	YesThe Chair asked if this could be sent for approval. Ericsson replied that only one key issue was left and it would be ready for the next meeting.	left for email approval	No
8.4	Study on 5G security enhancement against false base stations	S3‑194208	Updates to solution #17 - resolving Ens	Ericsson	pCR	Approval	Yes	YesOrange: confused with the terminology ("newer network?), add an editor's note about that. Get rid of the shalls, the evaluation should be removed. The network negotiation to support the feature is FFS.	revised	No	S3‑194668
		S3‑194668	Updates to solution #17 - resolving Ens	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194208
		S3‑194107	Conclusion for RRC Resume Request Protection	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange,Samsung, Qualcomm objected to this conclusion.	noted	No
		S3‑194202	Updates to solution #7 - capability negotiation	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑194667
		S3‑194667	Updates to solution #7 - capability negotiation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194202
		S3‑194203	Updates to solution #7 - network sharing	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑194682	Updates to solution #7 - network sharing	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194204	Updates to solution #7 - signature schemes and length	Ericsson	pCR	Approval	Yes	YesOrange: the ETSI SAGE sentences should be removed.	revised	No	S3‑194683
		S3‑194683	Updates to solution #7 - signature schemes and length	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194204
		S3‑194109	Evaluation for solution #7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194328	Evaluation on UE behavior on detection of false signature	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No		S3‑193363
		S3‑194329	Evaluation on signing key management	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No		S3‑193364
		S3‑194028	5GFBS-Update for solution#11	Apple	pCR	Approval	Yes	Yes	revised	No	S3‑194685
		S3‑194685	5GFBS-Update for solution#11	Apple	pCR	Approval	Yes	YesRemoving the editor's note on legacy USIMs.	approved	No		S3‑194028
		S3‑194327	Shared key based MIB/SIBs integrity information provided by gNB	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑194686	S3‑193361
		S3‑194686	Shared key based MIB/SIBs integrity information provided by gNB	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑194327
		S3‑193975	5GFBS-conclusion of key issue#2	Apple	pCR	Approval	Yes	YesOverlapping with 062,108, 339. There was no consensus for a way forward for key issue 2. Orange commented that the solutions of these documents had numerous security issues. The Chair asked who supported and who objected every solution: 395: Apple,Ericsson, Samsung, Commscope Objection: Orange, Qualcomm 4062: CableLabs, Apple, Samsung,Intel,BT,Commscope,Ericsson Objections: Orange, Qualcomm 108: Huawei, Qualcomm Objection: Orange,CalbleLabs,Ericsson, Commscope, Apple 339: Qualcomm, Huawei,Nokia,Deutsche Telekom,Orange Objection: Apple, Ericsson, CableLabs	noted	No
		S3‑194062	Way forward on key issue 2 in TR 33.809	CableLabs	discussion	Endorsement	Yes	Yes	noted	No
		S3‑194108	Conclusion for Key Issue #2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194339	Proposed way forward for KI#2 in TR 33.809	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑193940	LS to SA3 on False Base Station Detection	R3-196256	LS in		Yes	Yes	noted	No
		S3‑193941	Reply LS to SA3 on FBS detection	R2-1914224	LS in		Yes	Yes	postponed	No
		S3‑194206	[DRAFT] Reply LS on false base station detection	Ericsson	LS out	Approval	Yes	Yes	merged	No	S3‑194687
		S3‑194033	Reply LS to RAN2 on FBS detection	Huawei, HiSilicon	LS out	Approval	Yes	YesQualcomm: we don’t have the detailed answers for these questions. We need to estabilise the solutions before we can answer to RAN2. Futurewei: if we postpone this we don’t get any progress until the July meeting next year. Apple: work on this offline and we may agree on an answer fr this meeting.	revised	No	S3‑194687
		S3‑194687	Reply LS to RAN2 on FBS detection	Huawei, HiSilicon	LS out	Approval	Yes	Yes	noted	No		S3‑194033
		S3‑194032	Update solution 4 to clarify MIB/SIB Hash report	Huawei, HiSilicon	pCR	Approval	Yes	YesTaken offline to keep note 3 and try to reach an agreement with Qualcomm.	revised	No	S3‑194688
		S3‑194688	Update solution 4 to clarify MIB/SIB Hash report	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194032
		S3‑194330	Solution #4 Evaluation (Enriched MR)	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei didn’t agree with the text. This is talking only about the detection part. Ericsson didn’t agree either.	noted	No		S3‑193365
		S3‑194034	Preventing UE from Connecting to FBSs	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson: this solution is not needed. This will introduce significant delay and cause the handover procedure to fail. Samsung supported this.	noted	No
		S3‑194035	Preventing UE from reselecting to FBS	Huawei, HiSilicon	pCR	Approval	Yes	YesNot needed, as it doesn’t adress the key issue properly. Orange: if the message coming from the network to the UE is not delivered for any reason, the UE cannot know that the message was intended to be sent. The UE doesn’t expect this message. You just need as an attacker to prevent the delivery of this message to the UE.	noted	No
		S3‑194036	Handover UE under MitM FBS attacks	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson: Why do you assume that the man in the middle is gone after the handover? This will not work.	noted	No
		S3‑194110	Address EN in solution 6 and solution 18	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia; whatever you send it will be accepted by the base station because you are connected to it. Nokia disagreed with the change. Ericsson was of the similar opinion. The dumb repeater does nothing else than repeating, so why the overhead? Huawei replied that the repeater was not really dumb. This was taken offline.	revised	No	S3‑194689
		S3‑194689	Address EN in solution 6 and solution 18	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No		S3‑194110
		S3‑194207	Way forward - KI#3 False RBS detection	Ericsson	pCR	Approval	Yes	YesQualcomm: perform the evaluation before concluding. Orange: this conclusion means that we should do nothing and it is left to implementation.They didn’t agree with this way forward.	noted	No
		S3‑194205	[DRAFT] LS out to SA5 about SON poisoning	Ericsson	LS out	Approval	Yes	YesNokia: what do you want SA5 to do? Orange: better talk to your SA5 colleagues about this. It is not clear what SA5 needs to do about it. NTT-Docomo: clarify what they really need to do. This was taken offline.	noted	No
		S3‑194144	Update of Solution#15	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No
		S3‑194190	Resolving the ENs of solution#5 in the TR 33.809	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	YesInterdigital: refer to a generic satellite system, not specifically GPS. Revised to address this and other comments with editor's notes.	revised	No	S3‑194690
		S3‑194690	Resolving the ENs of solution#5 in the TR 33.809	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑194190
		S3‑194191	Conclusion on mitigation against the authentication relay attack	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	YesOrange disagreed with it.	noted	No
		S3‑193976	5GFBS-Update for solution#7	Apple	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194665	Notes from the offline session on false base stations	NTT-Docomo	report	Information	Yes	Yes	noted	No
		S3‑194684	Draft TR 33.809	Apple	draft TR	Approval	No	Yes	left for email approval	No
8.5	Study on Security aspects of Enhancement of Network Slicing	S3‑194050	Conclusion to KI#3	Huawei, HiSilicon	pCR	Approval	Yes	YesOrange objected to having normative work for this key issue.Ericsson agreed.	noted	No
		S3‑194051	Solution 8 update	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson: IDLE case: AMF relocation is to be avoided as an assumption, and this is implying that the relocation is needed. Capture this in the evaluation. Interdigital: signalling overheard is a concern here. Nokia disagreed with removing the editor's note. This didn't seem to be working.	revised	No	S3‑194542
		S3‑194542	Solution 8 update	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194051
		S3‑194317	Clarifications to solution #10 on protecting S-NSSAIs	Qualcomm Incorporated	pCR	Approval	Yes	YesInterdigital: clarification of the Distribution of the Key ID is not here (Idle mode mobility). Add an editor's note about that. Qualcomm replied that this comment hadn't been done before when they were asked to bring a contribution with additional clarifications.	revised	No	S3‑194544
		S3‑194544	Clarifications to solution #10 on protecting S-NSSAIs	Qualcomm Incorporated	pCR	Approval	Yes	YesAdding the editor's note.	approved	No		S3‑194317
		S3‑194318	Update to the evaluation of solution #10 on protecting S-NSSAIs	Qualcomm Incorporated	pCR	Approval	Yes	YesNokia commented that the impact of the idle mobility issue had to be considered. Ericsson: update this according to the editor's note added in the previous contribution. Nokia: retain the editor's note.	revised	No	S3‑194545
		S3‑194545	Update to the evaluation of solution #10 on protecting S-NSSAIs	Qualcomm Incorporated	pCR	Approval	Yes	YesBringing back the editor's note.	approved	No		S3‑194318
		S3‑194094	Adding evaluation to solution #10 in TR 33.813	Huawei, Hisilicon	pCR	Approval	Yes	YesQualcomm: the previous document covers this already. We don’t agree.	noted	No
		S3‑193964	TR 33.813 - update for solution #11	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑193911	TR 33.813 - update for the evaluation for solution #11	InterDigital Communications	pCR	Approval	Yes	YesQualcomm: this solution doesn't protect from attacks of people with the same NSSAI. It exists for both insiders and non-insiders.Don’t remove the editor's note. Nokia: the group size is too big, it is not a corner case.	revised	No	S3‑194546
		S3‑194546	TR 33.813 - update for the evaluation for solution #11	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193911
		S3‑194068	Update of solution #12 in TR 33.813	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑194547
		S3‑194547	Update of solution #12 in TR 33.813	ZTE Corporation	pCR	Approval	Yes	YesIt brings back the last editor's note.	approved	No		S3‑194068
		S3‑194052	Overal evaluation to solutions addressing KI#6	Huawei, HiSilicon	pCR	Approval	Yes	YesInterdigital: Idle mobility needs to be revisited as we have done in previous papers. It was agreed to add an editor's note. Qualcomm: the table is already out of date according to the progress today. Orange: no additional value of this table for the TR.	noted	No
		S3‑194053	Conclusions to KI #6	Huawei, HiSilicon	pCR	Approval	Yes	YesDiscussed together with tdoc 211.	noted	No
		S3‑194211	Conclusion on KI#6	Ericsson, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesInterdigital needed to see an additional analysys. The proposed solutions in the TR should be completed first before writing this evaluation. This was noted. The Chair recommended to keep working offline with this conclusion for the next meeting in order to finish the study.	noted	No
		S3‑194059	Key Issue#7 on revocation of rejected NSSAI	Nokia, Nokia Shnghai Bell, Lenovo, Motorola Mobility	pCR	Approval	Yes	YesOrange: this looks more like a stage 3 issue. No need to have it in the document. Lenovo commented that CT had been working in parallel to study how to do the revocation and it needed to be addressed in SA3 as well. Qualcomm commented that this was a CT1 issue, not appropriate for SA3. Huawei stressed the importance of this issue and that it should be worked on in SA3. Nokia: no new solution proposed here. This is aligned with CT1. Orange: note the document and see if CT1 asks something to be done in SA3. Orange asked to be minuted: "If needed this will be handled in the normative work."	noted	No
		S3‑194060	Solution for KI#7 on revocation of rejected NSSAI	Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	noted	No
		S3‑194143	Conclusion for KI#7	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	noted	No
		S3‑194543	Draft TR 33.813	Nokia	draft TR	Approval	No	Yes	left for email approval	No
8.6	Study on SECAM and SCAS for 3GPP virtualized network products	S3‑194136	Corrections on clause 4.3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194561
		S3‑194561	Corrections on clause 4.3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194136
		S3‑194162	remove unspecified SDOs	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194562
		S3‑194562	remove unspecified SDOs	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194162
		S3‑194231	Add Definition of Execution Environment Interface in 33.818	Nokia, Nokia Shanghai Bell, China Mobile	pCR	Approval	Yes	Yes	merged	No	S3‑194563
		S3‑194141	Clarifying interfaces in clause 5.2.3.3.4 and clause 5.2.3.4.5	China Mobile	pCR	Approval	Yes	Yes	revised	No	S3‑194563
		S3‑194563	Clarifying interfaces in clause 5.2.3.3.4 and clause 5.2.3.4.5	China Mobile,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑194141
		S3‑194145	Adding security requirements for GVNP of type 1	China Mobile	pCR	Approval	Yes	Yes	revised	No	S3‑194564
		S3‑194564	Adding security requirements for GVNP of type 1	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑194145
		S3‑194147	Adding security functional requirements deriving virtualisation and related test cases for GVNP of type 1	China Mobile	pCR	Approval	Yes	Yes	noted	No
		S3‑194565	Adding security functional requirements deriving virtualisation and related test cases for GVNP of type 1	China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194232	[DRAFT] LS on SECAM Accreditation for Virtualised Network Products (VNPs)	Nokia, Nokia Shanghai Bell, China Mobile	LS out	Approval	Yes	Yes	revised	No	S3‑194567
		S3‑194567	LS on SECAM Accreditation for Virtualised Network Products (VNPs)	Nokia, Nokia Shanghai Bell, China Mobile	LS out	Approval	Yes	Yes	approved	No		S3‑194232
		S3‑194612	Draft TR 33.818	China Mobile	draft TR	Approval	No	Yes	left for email approval	No
8.7	Study on Security for 5GS Enhanced support of Vertical and LAN Services	S3‑194082	Address the EN in Solution #17	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194423	TSC gPTP message protection	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑194407
		S3‑194083	Conclusion on protection of time synchronization	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194422	TSC conclusion	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson: lot of text that seems normative. SA3 should make a recommendation rather than specifying with "shalls". Sentences were reworded to remove the "shalls". Revised to address some Huawei's comments as well.	revised	No	S3‑194552	S3‑194408
		S3‑194552	TSC conclusion	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑194422
		S3‑194222	New conclusion for handling UP security policy in a 5GLAN group	Ericsson	pCR	Approval	Yes	YesHuawei: no normative work is required for this key issue. Ericsson: Then how all Ues in the same group have the same policy then? It was agreed to add an editor's note. The text for this was taken offline.	revised	No	S3‑194555
		S3‑194555	New conclusion for handling UP security policy in a 5GLAN group	Ericsson,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑194222
		S3‑194429	Commenting on S3-194222	Nokia Germany	pCR		Yes	Yes	merged	No	S3‑194555
		S3‑193912	TR 33.819 – update for the evaluation of Hash based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	Yes	noted	No
		S3‑194381	Udpate to Solution #3	Samsung	pCR	Approval	Yes	YesHuawei didn’t agree with the new sentence in the evaluation. This was left for offline discussion. After this discussion Huawei withdrew their comments and this was approved.	approved	No
		S3‑194556	Udpate to Solution #3	Samsung	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194220	New solution to preserve CAG-ID privacy	Ericsson	pCR	Approval	Yes	YesNokia disagreed, as this was against what SA2 was doing. Huawei supported Nokia. Ericsson: we could consider this as a solution. Nokia: come back with this if SA2 changes their mind.	noted	No
		S3‑194379	New Solution to Key Issue #6.2	Samsung	pCR	Approval	Yes	YesHuawei: impact on USIM? Samsung replied that there was none. Qualcomm had concerns on the SUCI calculation procedures.	revised	No	S3‑194557
		S3‑194557	New Solution to Key Issue #6.2	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑194379
		S3‑194221	New conclusion to preserve CAG-ID privacy	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑194377	Solution #13 Evaluation and Conclusion	Samsung, Intel	pCR	Approval	Yes	YesThales: impacts on the ME-UICC interface need to be stated in the evaluation. Huawei, Ericsson didn’t agree with the conclusion. This was removed.	revised	No	S3‑194558
		S3‑194558	Solution #13 Evaluation and Conclusion	Samsung, Intel	pCR	Approval	Yes	Yes	approved	No		S3‑194377
		S3‑194383	Key Issue #6.1 conclusion	Samsung	pCR	Approval	Yes	YesEricsson and Huawei didn’t agree with this conclusion. Ericsson added that the CAG ID was used to prevent access attempts, so it was unclear how this could happen.There were discussions in SA2 on whether the CAG ID should be sent at all. This was left open. After discussions there was no agreement and it was noted.	noted	No
		S3‑194384	Conclusion for Key Issues #6.1 and #6.2	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑194163	Adding conclusion on KI #6.2	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson preferred the Nokia alternative. Qualcomm: there is no security reason for NAS signalling, and in SA2 they are not sure whether this is needed. Huawei: not sending CAG ID would have security issues and would affect SA2 decisions. Samsung replied that conclusion in SA3 should be done when SA2 concluded their discussions. This was left open for discussion.	noted	No
		S3‑194403	CAG ID privacy conclusion	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesInterdigital: wait for SA2's conclusions. Sebastian (Qualcomm): no need to wait, SA3 can work on this and give their view on CAG ID privacy. Futurewei commented that it just has to be protected and that's the view. The Chair asked if SA3 could agree on their view on CAG ID privacy and send it to other groups. Interdigital: this is solution-specific. This was left for offline discussions in order to agree on a common view that could be sent to SA2. Samsung thought that it was too early and they needed to wait for SA2. Interdigital supported this. Qualcomm, Ericsson supported going for the study now.	revised	No	S3‑194693
		S3‑194693	CAG ID privacy conclusion	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No		S3‑194403
		S3‑194554	Reply LS on Sending CAG ID in NAS layer	R3-197591	LS in	discussion	Yes	YesNokia: we should add in the conclusion clause that for the broadcast part CAG ID privacy will not be considered given the complexity of the possible solutions. Ericsson commented that there was no need to send the CAG ID in the NAS layer as RAN3 had concluded.Qualcomm added that only if it went through the NAS it would be protected.	replied to	No
		S3‑194559	Reply to: Reply LS on Sending CAG ID in NAS layer	Qualcomm	LS out	approval	Yes	Yes	approved	No
		S3‑194407	TSC gPTP message protection	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑194423
		S3‑194408	TSC conclusion	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑194422
		S3‑194551	Draft TR 33.819	Nokia	draft TR	Approval	No	Yes	left for email approval	No
		S3‑194696	Presentation of TR 33.819 to SA plenary	Nokia	TS or TR cover	Approval	Yes	Yes	approved	No
8.8	Study on LTKUP Detailed solutions	S3‑193988	LTKUP: editorial corrections to solution 5 in TR 33.935	THALES	pCR	Approval	Yes	Yes	approved	No
		S3‑194634	Draft TR 33.935	Vodafone	draft TR	Approval	Yes	Yes	approved	No
8.9	Study on User Plane Integrity Protection	S3‑193972	UP IP-update for solution#9	Apple	pCR	Approval	Yes	YesQualcomm had some issues with this and it was left open.	revised	No	S3‑194698
		S3‑194698	UP IP-update for solution#9	Apple	pCR	Approval	Yes	Yes	approved	No		S3‑193972
		S3‑194120	UE activates UP IP over eUTRA to EPC	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: remove the evaluation. Vodafone proposed to add an editor's note in order to have something that could be changed instead of starting from zero. Qualcomm agreed to remove the evaluation. This implied a major impact and a proper study was needed here.	revised	No	S3‑194671
		S3‑194671	UE activates UP IP over eUTRA to EPC	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194120
		S3‑194121	Update conclusion clause	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑194151	Revise the Evaluations for Solution 5 in TR 33.853	China Mobile	pCR		Yes	YesVodafone: it needs better English. Qualcomm didn’t agree with the document.	noted	No
		S3‑194152	Discussion on the UP IP for 5G RAN connected 5GC	China Mobile	discussion	Endorsement	Yes	Yes	noted	No
		S3‑194154	Add the conclusion on the UP IP for 5G RAN connected to 5GC	China Mobile International Ltd	pCR		No	Yes	withdrawn	Yes
		S3‑194230	Add the conclusion on the UP IP for 5G RAN connected to 5GC	China Mobile	pCR	Approval	Yes	YesVodafone didn’t see where this solution was coming from.	noted	No
		S3‑194289	UP-IP: Resolving editor's note in solution #7	Ericsson	pCR	Approval	Yes	YesQualcomm: this doesn’t address the RAN part.	approved	No
		S3‑194290	Conclusion on Key Issue 6: UE connected to 5GC indicating support of UP IP over eUTRA	Ericsson	pCR	Approval	Yes	YesCompeting with 338.	noted	No
		S3‑194338	Proposed conclusion for KI#6 in TR 33.853	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑194396	Conclusion to Key Issue #5	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑194672	Draft TR 33.853	Vodafone	draft TR	Approval	No	Yes	left for email approval	No
8.10	Study on Security Impacts of Virtualisation	S3‑194002	DTR 33848 KI1 – clause 5_2_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194568
		S3‑194568	DTR 33848 KI1 – clause 5_2_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194002
		S3‑194003	DTR 33848 KI2 – clause 5_3_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194569
		S3‑194569	DTR 33848 KI2 – clause 5_3_3	T-Mobile USA Inc.	other	Approval	Yes	YesChina Mobile asked to be minuted :The requirement is not complete.	approved	No		S3‑194003
		S3‑194004	DTR 33848 KI3 – clause 5_4_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194570
		S3‑194570	DTR 33848 KI3 – clause 5_4_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194004
		S3‑194005	DTR 33848 KI4 – clause 5_5_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194571
		S3‑194571	DTR 33848 KI4 – clause 5_5_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	noted	No		S3‑194005
		S3‑194006	DTR 33848 KI5 – clause 5_6_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194572
		S3‑194572	DTR 33848 KI5 – clause 5_6_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194006
		S3‑194007	DTR 33848 KI6 – clause 5_7_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194573
		S3‑194573	DTR 33848 KI6 – clause 5_7_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194007
		S3‑194008	DTR 33848 KI7 – clause 5_8_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194574
		S3‑194574	DTR 33848 KI7 – clause 5_8_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194008
		S3‑194009	DTR 33848 KI8 – clause 5_9_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194575
		S3‑194575	DTR 33848 KI8 – clause 5_9_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194009
		S3‑194010	DTR 33848 KI9 – clause 5_10_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194576
		S3‑194576	DTR 33848 KI9 – clause 5_10_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194010
		S3‑194011	DTR 33848 KI11 – clause 5_12_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194578
		S3‑194578	DTR 33848 KI11 – clause 5_12_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194011
		S3‑194012	DTR 33848 KI12 – clause 5_13_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194579
		S3‑194579	DTR 33848 KI12 – clause 5_13_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194012
		S3‑194013	DTR 33848 KI13 – clause 5_14_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194580
		S3‑194580	DTR 33848 KI13 – clause 5_14_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194013
		S3‑194014	DTR 33848 KI14 – clause 5_15_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194581
		S3‑194581	DTR 33848 KI14 – clause 5_15_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194014
		S3‑194015	DTR 33848 KI15 – clause 5_16_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194584
		S3‑194584	DTR 33848 KI15 – clause 5_16_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194015
		S3‑194016	DTR 33848 KI16 – clause 5_17_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194585
		S3‑194585	DTR 33848 KI16 – clause 5_17_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194016
		S3‑194017	DTR 33848 KI17 – clause 5_18_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	noted	No
		S3‑194018	DTR 33848 KI18 – clause 5_19_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	noted	No
		S3‑194019	DTR 33848 KI19 – clauses 5_20_2 and 3	T-Mobile USA Inc.	other	Approval	Yes	Yes	merged	No	S3‑194588
		S3‑194020	DTR 33848 KI20 – clause 5_21_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194589
		S3‑194589	DTR 33848 KI20 – clause 5_21_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194020
		S3‑194021	DTR 33848 KI21 – clause 5_22_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194590
		S3‑194590	DTR 33848 KI21 – clause 5_22_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194021
		S3‑194022	DTR 33848 KI22 – clause 5_23_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194591
		S3‑194591	DTR 33848 KI22 – clause 5_23_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194022
		S3‑194023	DTR 33848 KI23 – clause 5_24_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194592
		S3‑194592	DTR 33848 KI23 – clause 5_24_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194023
		S3‑194024	DTR 33848 KI24 – clause 5_25_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	revised	No	S3‑194593
		S3‑194593	DTR 33848 KI24 – clause 5_25_3	T-Mobile USA Inc.	other	Approval	Yes	Yes	approved	No		S3‑194024
		S3‑194353	TR 33.848 Solution – lock-down of infrastructure	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑194582
		S3‑194582	TR 33.848 Solution – lock-down of infrastructure	NCSC	pCR	Approval	Yes	YesThales: do we need to point out what is in scope of ETSI NFV? MCC warned that this was an internal 3GPP specification and could not be shared with external to 3GPP groups. Alex (BT) argued that this was a public document and ETSI being an organizational partner wasn't an impediment to share the specification. MCC commented that this wasn’t enough and that the spec should be changed to a 900 series specification in order to be officially sent to ETSI NFV. This was to be discussed further offline.	approved	No		S3‑194353
		S3‑194354	TR 33.848 Solution – trust domains and separation	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑194583
		S3‑194583	TR 33.848 Solution – trust domains and separation	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑194354
		S3‑194398	Requirements for KI#18 The Startup Paradox	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑194587
		S3‑194587	Requirements for KI#18 The Startup Paradox	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194398
		S3‑194432	Comments to S3-194019 DTR 33.848, Key Issue #19 Clauses 5.20.2 and 5.20.3	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑194588
		S3‑194588	Comments to S3-194019 DTR 33.848, Key Issue #19 Clauses 5.20.2 and 5.20.3	Ericsson,T-Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑194432
		S3‑194560	Notes on the security impacts on the virtualization offline session	NTT-Docomo	report	Information	Yes	Yes	noted	No
		S3‑194624	Draft TR 33.848	BT	draft TR	Approval	Yes	Yes	approved	No
8.11	Study on authentication enhancements in 5GS (FS_AUTH_ENH)	S3‑194346	New KI: Existing authentication procedure lacking the PFS property	Ericsson,Apple, China Mobile, ZTE, Nokia	pCR	Approval	Yes	YesThales: it's been 4 times that this contribution has been brought here and last time there was a show of hands and it was rejected. We still object to the additional complexity that the addition of PFS mechanisms will bring. T-Mobile: it's a study, nothing normative and it is to be investigated. Thales replied that there was enough work already to bring in a new study item. Vodafone: no point of bringing this again if it was rejected before. Ericsson asked a show of hands. Who objected the key issue: Thales, IDEMIA, Qualcomm,Orange,Vodafone. Companies supporting the key issue: Apple Ericsson Nokia, ZTE,China Mobile, Huawei, ZTE, HP, T-Mobile	noted	No		S3‑194297
		S3‑194189	Resolving the ENs in KI#3.1	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: don’t mention CT4, refer to their spec. Ericsson: keep the editor's notes. Vodafone: correct the English. Orange commented that this looked like the problem was coming from CT4, so it had to be fixed in there and not in SA3. Nokia: delete the key issue and send an LS. Orange: keep the key issue and delete the requirements. This was taken offline.	revised	No	S3‑194673
		S3‑194673	Resolving the ENs in KI#3.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194189
		S3‑194069	Update of key issue #3.2 in TR 33.846	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑194084	Address the EN on the reference in key issue 4.1	Huawei, Hisilicon	pCR	Approval	Yes	YesOverlapping with tdoc 026.	merged	No	S3‑194675
		S3‑194071	Update of solution #2.1 in TR 33.846	ZTE Corporation	pCR	Approval	Yes	YesEricsson: no evaluation yet for this one. Vodafone commented that the tendency was to remove the evaluations from the solutions so a different party could write them.	approved	No
		S3‑194086	Address the EN on the NAS procedure impact in Solution#2.4	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: it doesn’t really address the editor's note.This had to be taken offline. Huawei asked to be minuted: "Ericsson rejected the contribution without any explanation."	postponed	No
		S3‑193974	AUTH_Enh-Evaluation for solution#2.4	Apple	pCR	Approval	Yes	YesThales: this solution does not lead to another kind of attack.The last paragraph had to be reformulated.	revised	No	S3‑194677
		S3‑194677	AUTH_Enh-Evaluation for solution#2.4	Apple	pCR	Approval	Yes	Yes	approved	No		S3‑193974
		S3‑194188	Resolving the ENs of solution#2.5 in the TR 33.846	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: describe how the MAC will impacted. The solution relies on the handset based SUCI mechanism. China Mobile: where is the key in step2? Add that the solution doesn't apply to legacy USIMs.	revised	No	S3‑194678
		S3‑194678	Resolving the ENs of solution#2.5 in the TR 33.846	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194188
		S3‑194070	Solution of mitigating the SUPI guessing attacks	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑194026	AUTH_Enh-update for solution#4.1	Apple	pCR	Approval	Yes	Yes	revised	No	S3‑194675
		S3‑194675	AUTH_Enh-update for solution#4.1	Apple,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑194026
		S3‑194085	Add solution details and evaluation to solutioin 4.1	Huawei, Hisilicon	pCR	Approval	Yes	YesQualcomm had issues with the figure and the evaluation. They suggested to send this evaluation to SAGE to confirm that this assumption was Ok. The ealuation was removed.	revised	No	S3‑194679
		S3‑194679	Add solution details and evaluation to solutioin 4.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194085
		S3‑194316	Update to the evaluation of solution #4.1 on protecting SQN in AKA re-synchronisations	Qualcomm Incorporated	pCR	Approval	Yes	YesApple: two editor's notes on more evalutation needed and how to deal with the legacy and new USIM.	revised	No	S3‑194681
		S3‑194681	Update to the evaluation of solution #4.1 on protecting SQN in AKA re-synchronisations	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑194316
		S3‑194169	Conclusion on KI #4.1	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: don’t include internal GSMA internal papers in the zip file. Huawei's understanding was that the research paper had been made public, although a reference should have been added instead of adding the paper. Qualcomm didn’t agree with the solution and conclusions.	noted	No
		S3‑193973	AUTH_Enh-update for solution#9	Apple	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194297	New KI: Existing authentication procedure lacking the PFS property	Ericsson	pCR		No	Yes	revised	No	S3‑194346
		S3‑194674	LS on deleting invalid autnentication results in UDM	Huawei	LS out	Approval	Yes	Yes	approved	No
		S3‑194676	Draft TR 33.846	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
		S3‑194680	LS on resynchronization	Qualcomm	LS out	Approval	Yes	Yes	approved	No
8.12	Study on Security for NR Integrated Access and Backhaul	S3‑194072	Key issue on security attack caused by IAB-node with removable UICC card	ZTE Corporation	pCR	Approval	Yes	YesOrange: this is a deployment decision, up to the network operator. Qualcomm: we don’t need this key issue. IDEMIA agreed.	noted	No
		S3‑194089	Security attack caused by an unauthorized IAB device	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: the note doesn’t make sense without the requirements. Nokia: it assumes that removing the UICC and putting into another IAB node it becomes another IAB node. This is not true.	noted	No
		S3‑194364	Updates to Solution #2.1 on MT functionality	Samsung, Qualcomm Incorporated, Ericsson, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑194366	Updates and evaluation of solution #3.1	Samsung	pCR	Approval	Yes	YesThales, Nokia supported this. Qulacomm: no requirement to have the additional authorization check. Why is this here? Samsung: RAN2 is working on the identification of co-location and verification of the authorization part. It was agreed to remove the sentence where this was mentioned. Qualcomm had numerous comments including the evaluation as well. Both Nokia and Qualcomm had competing evaluations.	revised	No	S3‑194577
		S3‑194577	Updates and evaluation of solution #3.1	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑194366
		S3‑194331	Evaluation on Solution #3.1	Qualcomm Incorporated, Ericsson	pCR	Approval	Yes	Yes	noted	No		S3‑193358
		S3‑194332	Evaluation on Solution #4.2	Qualcomm Incorporated, Ericsson	pCR	Approval	Yes	YesNokia: problematic to use the same F1. Samsung: it becomes more complex with wireless. There would be different procedures. Efficient in wireline would not be efficient with the wireless. The same wireline solution for the wireless would not be necessarily equally efficient. An additional sentence in the evaluation was to be discussed offline.	revised	No	S3‑194586
		S3‑194586	Evaluation on Solution #4.2	Qualcomm Incorporated, Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194332
		S3‑194333	Conclusion on KI #4.1	Qualcomm Incorporated, Ericsson	pCR	Approval	Yes	Yes	noted	No		S3‑193359
		S3‑194073	Definition of IAB-MT	ZTE Corporation	pCR	Approval	Yes	YesNot needed anymore.	noted	No
		S3‑194566	Draft TR 33.824	Samsung	draft TR	Approval	No	Yes	left for email approval	No
8.13	Study on Security Aspects of 3GPP support for Advanced V2X Services	S3‑193960	33.836 – update of evaluation for the Solution #1	InterDigital Communications	pCR	Approval	Yes	Yes	revised	No	S3‑194616
		S3‑194616	33.836 – update of evaluation for the Solution #1	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193960
		S3‑193961	TR 33.836 – update of evaluation for the solution #4	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑194617	TR 33.836 – update of evaluation for the solution #4	InterDigital Communications	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑193962	TR 33.836 - proposed conclusion for KI#1	InterDigital Communications	pCR	Approval	Yes	Yes	merged	No	S3‑194618
		S3‑194309	Proposed conclusion for Key Issue #1 on Unicast privacy	Qualcomm Incorporated	pCR	Approval	Yes	YesIt was asked to be minuted:The agreement is to use solution 1.	revised	No	S3‑194618
		S3‑194618	Proposed conclusion for Key Issue #1 on Unicast privacy	Qualcomm Incorporated,Interdigital	pCR	Approval	Yes	Yes	approved	No		S3‑194309
		S3‑193959	TR 33.836 – update of evaluation for the solution #2	InterDigital Communications	pCR	Approval	Yes	Yes	revised	No	S3‑194620
		S3‑194620	TR 33.836 – update of evaluation for the solution #2	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193959
		S3‑194303	Resolving the Editor’s note on privacy in the evaluation of solution #8	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑194621	Resolving the Editor’s note on privacy in the evaluation of solution #8	Qualcomm Incorporated	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194081	Updates to solution 9	Intel Corporation (UK) Ltd	pCR		Yes	Yes	revised	No	S3‑194619
		S3‑194619	Updates to solution 9	Intel Corporation (UK) Ltd	pCR	-	Yes	Yes	approved	No		S3‑194081
		S3‑194306	Proposal of an evaluation of solution #12 on protecting the traffic at the PDCP layer	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑194622	Proposal of an evaluation of solution #12 on protecting the traffic at the PDCP layer	Qualcomm Incorporated	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194302	Adding the provisioning of security policy to solution #16	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑194623
		S3‑194623	Adding the provisioning of security policy to solution #16	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑194302
		S3‑194307	Proposal of an evaluation of solution #16 on the activation of user plane security in NR PC5 unicast	Qualcomm Incorporated	pCR	Approval	Yes	YesInterdigital: the solution is needed but we need a key issue for this. Qualcomm replied that it was part of key issue 2, protection of UP data. Revised to address this comment.	revised	No	S3‑194646
		S3‑194646	Proposal of an evaluation of solution #16 on the activation of user plane security in NR PC5 unicast	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑194307
		S3‑194173	Resolving the EN and adding the evaluation of solution #17	Huawei, Hisilicon	pCR	Approval	Yes	YesInterdigital disagreed wtih the first paragraph. This was removed.	revised	No	S3‑194647
		S3‑194647	Resolving the EN and adding the evaluation of solution #17	Huawei, Hisilicon	pCR	Approval	Yes	YesAdded a statement on the solution being suitable for apps when the operators know the keys. Addressing Privacy issues with GUTI aspects. First paragraph removed and last paragraph reworded.	approved	No		S3‑194173
		S3‑194175	eV2X: Solution for the UP security activation policy handling in NR PC5 unicast	Huawei, Hisilicon	pCR	Approval	Yes	YesInterdigital: linked to the new requirement we added in a previous document on key issue 2.	revised	No	S3‑194648
		S3‑194648	eV2X: Solution for the UP security activation policy handling in NR PC5 unicast	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194175
		S3‑194304	Protection of IEs in Direct Communication Request message	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑194649
		S3‑194649	Protection of IEs in Direct Communication Request message	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑194304
		S3‑194305	Proposal of an evaluation of solution protecting IEs in Direct Communication Request message	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑194308	Proposal conclusion for key issue #2 on security for eV2X unicast messages over PC5	Qualcomm Incorporated	pCR	Approval	Yes	YesCompeting conclusion with Huawei's proposals in the following contributions.	revised	No	S3‑194650
		S3‑194650	Proposal conclusion for key issue #2 on security for eV2X unicast messages over PC5	Qualcomm Incorporated,Interdigital,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑194308
		S3‑194176	eV2X: Conclusion on one requirement of KI#2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑194650
		S3‑194174	eV2X: Conclusion on KI#2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194178	eV2X: Conclusion on KI#2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑193963	TR 33.836 - Proposed conclusion for KI#2	InterDigital Communications	pCR	Approval	Yes	Yes	merged	No	S3‑194650
		S3‑194148	Update of solution#14	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesHuawei: this is not addressing the availability part of the editor's note. Lenovo: the UE has an internal clock and we don’t depend on any time information from the outside.	approved	No
		S3‑194149	Solution#14 Evaluation	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesEricsson: what happens if you are running out of battery? Lenovo: same as going out of coverage. For LG the evaluation needed to be completed with additional statements on UE out of coverage scenario.	revised	No	S3‑194651
		S3‑194651	Solution#14 Evaluation	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑194149
		S3‑194413	Privacy solution for groupcast	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesHuawei didn’t agree with the solution, as this was against SA2's work on the creation and management of the group.	noted	No
		S3‑194414	Evaluation to privacy solution for groupcast	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑194041	New Solution for secure identifier conversion in groupcast	Huawei, HiSilicon	pCR	Approval	Yes	YesLG: not aligned with SA2 architecture. Orange: add an editor's note to improve this alignment. Huawei clarified that this was part of the SA2 architecture and not something new. Interdigital: group setup and provisioning need coverage. That's a problem. An editor's note was added about this. Orange: remove the evaluation part, this is not complete.	revised	No	S3‑194653
		S3‑194653	New Solution for secure identifier conversion in groupcast	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194041
		S3‑194155	Solution for destination L2 privacy	Ericsson	pCR	Approval	Yes	YesHuawei disagreed with this solution.There were several issues that were not specified. Lenovo: How many IDs will you have to ensure your privacy? What will be the size of the set of the group IDs?	noted	No
		S3‑194037	Conclusion for Key Issue #3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194038	Conclusion for Key Issue #4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑194310	Proposed conclusion for Key Issue #4 on security of identifier conversion in groupcast communication	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei didn’t agree with this conclusion. LG supported Qualcomm.	noted	No
		S3‑194311	Proposed conclusion for Key Issue #6 on Security of the UE service authorization and revocation	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei contribution had the same conclusion but Qualcomm was happy with going forward with tdoc 044.	noted	No
		S3‑194044	Conclusions to KI #6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑194097	Providing analysis to Solution #13 in TR 33.836	Huawei, Hisilicon	pCR	Approval	Yes	YesInterdigital: it's a solution adopted from SA2 but not an invention of SA3. It was added a reference to the SA2 spec where this was coming from.	revised	No	S3‑194654
		S3‑194654	Providing analysis to Solution #13 in TR 33.836	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑194097
		S3‑194039	Conclusion for Key Issue #8	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑194074	Add a note to key issue #9 in TR 33.836	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑194095	Providing some updates to Solution #15 in TR 33.836	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑194096	Evaluation of Solution #15 in TR 33.836	Huawei, Hisilicon	pCR	Approval	Yes	YesInterdigital: no requirements for key issue 9. Then we cannot have an evaluation. Huawei replied that this was an optimization issue and not security specific.Interdigital asked what was being solved here. Huawei asked where this could be handled then. LG replied that possibly RAN2 and an LS could be sent to them.	noted	No
		S3‑194042	New solution to KI#9	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194697
		S3‑194697	New solution to KI#9	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No		S3‑194042
		S3‑194040	Conclusion for Key Issue #9	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193981	Conclusion for Key issue 9	LG Electronics Inc.	pCR	Agreement	Yes	YesHuawei proposed to wait for RAN2 response to the LS before concluding on this key issue. Qualcomm disagreed and preferred to conclude this in the current meeting. It's been taken on by other groups already (e.g. SA2). MCC suggested to remove the second sentence which was mentioning other working groups; as confirmed by Qualcomm this was already considered in other working groups anyway. Nokia suggested to add text on this key issue being out of scope of SA3.	noted	No
		S3‑194656	Conclusion for Key issue 9	LG Electronics Inc.	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑193980	Conclusion for Key issue 10	LG Electronics Inc.	pCR	Agreement	Yes	Yes	merged	No	S3‑194657
		S3‑194177	eV2X: conclusion on KI #10	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑194657
		S3‑194657	eV2X: conclusion on KI #10	Huawei, Hisilicon,LG	pCR	Approval	Yes	YesRemoving "release 16" from the conclusion as MCC explained that this was a release 16 document anyway hence there was no need to mention it.	approved	No		S3‑194177
		S3‑193990	Draft LS on PC5 unicast and groupcast security protection	InterDigital Communications	LS out	Decision	Yes	YesQualcomm agreed with the LS but they wanted to enhance the first bullet.	revised	No	S3‑194658
		S3‑194658	LS on PC5 unicast and groupcast security protection	InterDigital Communications	LS out	Decision	Yes	Yes	approved	No		S3‑193990
		S3‑194043	Addition of security threats and security requirements to KI#9	Huawei, HiSilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑194179	Clarification on aspects specific to the network product class UDM and AMF	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑194419
		S3‑194626	Draft TR 33.836	Lge	draft TR	Approval	No	Yes	left for email approval	No
		S3‑194655	LS on minimizing the impact of privacy protection mechanisms in the application layer	Huawei	LS out	Approval	Yes	Yes	noted	No
8.14	Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication	S3‑193986	Authentication subscription data	KPN, Nokia	pCR	Approval	Yes	YesEricsson: possible to merge with 292. Nokia: address 2G and 3G? China Mobile had issues with the AMF in the case of the subscriber using 3G or 4G as well. Orange disagreed with Note 2.The SUPI specific parameter is part of the authentication subsription data when it is derived. The note was removed.	revised	No	S3‑194660
		S3‑194660	Authentication subscription data	KPN, Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑193986
		S3‑194247	Key issue on Protection of long-term key during storage in UDR	KPN, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesVodafone: missing the threat on the user data being uncovered (decoding previously recorded previous communications) when the long term key is known by the attacker. Orange: who is the entity targeted in the first requirement? NTT-Docomo: another missing threat on someone stealing the service on behalf of someone else. A consumer paying for someone else using their service.Copying a protected key in a different subscription. Then the corresponding requirement. IDEMIA: remove the sentence on creating unauthorised USIMs.	revised	No	S3‑194661
		S3‑194661	Key issue on Protection of long-term key during storage in UDR	KPN, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑194247
		S3‑194249	Key issue on Protection of long-term key during transfer out of UDR	KPN, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesOrange had problems with the requirements.Related to the previous document (661).	revised	No	S3‑194662
		S3‑194662	Key issue on Protection of long-term key during transfer out of UDR	KPN, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑194249
		S3‑194291	ARPF Deployment models	Ericsson	pCR	Approval	Yes	YesVodafone asked why this had become an informative annex. Nokia commented that the clause was not completely related to the study but it was worth including it. Vodafone commented that as a TR all content was informative anyway.	approved	No
		S3‑194292	Security Parameter Storage	Ericsson	pCR	Approval	Yes	YesKPN: 4.1.2 and 4.1.3 overlap with our document and could go to clause 5. There is potential to merge. Orange: remove the e.g. in the first bullet point. Remove "identifier" in the second bullet. Ericsson replied that it was implementation specific, it would become more flexible. It was agreed to add proprietary algorithms. Vodafone: remove the last two sentences of 4.2.1.	revised	No	S3‑194664
		S3‑194664	Security Parameter Storage	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑194292
		S3‑194385	Updated TR33.845 - includes docs agreed at SA3#95 Adhoc	Vodafone España SA	draft TR	Agreement	Yes	Yes	approved	No
		S3‑194411	UDR study - title correction	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesIt was clarified that the WID title was reworded before being sent to SA, although the spec title wasn’t aligned yet.	revised	No	S3‑194669
		S3‑194669	UDR study - title correction	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑194411
		S3‑194412	UDR study - intro	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑194670
		S3‑194670	UDR study - intro	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesFirst paragraph and first sentence of last paragraph are gone as requested by Orange.	approved	No		S3‑194412
		S3‑194663	Draft TR 33.845	Vodafone	draft TR	Approval	No	Yes	left for email approval	No
8.15	Other study areas
8.16	New study item proposals	S3‑193977	SID on privacy enhancement of 3GPP access and non-3GPP access in EPS	Apple	SID new	Approval	No	Yes	withdrawn	Yes
		S3‑194029	SID on privacy enhancement of 3GPP access and non-3GPP access in EPS	Apple, Google, AT&T, Verizon UK Ltd, Accuris Networks, Charter Communications, Cablelabs, ARTICLE19, Sprint, Broadcom, Comcast	SID new	Approval	Yes	YesChina Mobile objected to this Study Item. Apple clarified that this was a study and that there would be no impact on existing solutions. Qualcomm didn't support it either: The phase 1 study already concluded that there was no further work necessary. No need to reopen this. Qualcomm, Nokia, Huawei, ZTE and Futurewei objected to this study. Interdigital, Article19 also supported the study apart from the source companies. Apple didn't see the point of objecting to a study and declared that there was no concrete reason for this.	noted	No
		S3‑194078	New SID on the security of the system enablers for devices having multiple Universal Subscriber Identity Modules (USIM)	Intel Corporation (UK) Ltd	SID new		Yes	Yes	revised	No	S3‑194471
		S3‑194471	New SID on the security of the system enablers for devices having multiple Universal Subscriber Identity Modules (USIM)	Intel Corporation (UK) Ltd	SID new	-	Yes	YesORANGE: objectives are not clear. SA2 has just started and it's not clear either what SA3 has to do.Better to wait for SA2 to see if they have any specific security issues that we need to address with a study. Qualcomm supported this. Thales: SA2 SID has two USIMs (5GS and EPS) but the scope of the SID in SA3 is different.. Intel replied that this was aligned with the scenarios described in SA1. Ericsson: let us be careful as SA2 might advance some security work if we wait for too long. Alex (BT): SA plenary has prohibited the multi-operator scenario.	noted	No		S3‑194078
		S3‑194091	Discussion on security of 5MBS enhancement	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑194092	5MBS_Sec_SID_SA3	Huawei, Hisilicon	SID new	Approval	Yes	YesQualcomm: we support this but it is too early. Bring it back in February. Juniper supported this.	noted	No
		S3‑194137	New SID: Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC	China Unicom	SID new		Yes	YesHuawei: based on the SA6 study. Qualcomm: too early based on SA2's progress. ORANGE supported this. BT: SA is currently working on the Release 17 prioritization and it could impact on this topic significantly. AT&T supported approving this study item given the current work in SA6 as they could benefit from the work in here. Qualcomm preferred to discuss this in February next year given that this was Release 17 work.	noted	No
		S3‑194181	New SID: Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC	Huawei, Hisilicon	SID new	Approval	Yes	YesHuawei: based on the SA2 study. AT&T: SA2 and SA6 have separate architectures so we want to support a split of study items. CableLabs supported initiating the work now. Telecom Italia: puzzled with having two studies with the same title. SA3 should have a single SID about this topic. Huawei wondered who supported having to split the study into two. The Chair commented that part of the reason was to have two rapporteurs,practice that had been deprecated in SA. This was a possible solution for that.	noted	No
		S3‑194140	Discussion about a new study on 5G Prose security	CATT	discussion	Decision	Yes	YesCATT added that SA2 had planned to finish in June and that SA3 should consider that.	noted	No
		S3‑194218	Discussion on new SID for enhanced security to support new Non Public Network evolvement	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑194219	New SID: Study on enhanced security support for Non-Public Networks	Ericsson	SID new	Agreement	Yes	YesORANGE: this is very early work in SA2. Everything is open and it is not time to start the work in SA3 yet. Ericsson: there are several agreements from which we can start the work. There is a risk that they will do some security work if we don’t start soon. ORANGE: this will lead to overlapping key issues being worked in both SA2 and SA3, and I want to avoid that. Nokia: it is too early to start the work. SA3 should continue the work in Vertical LAN and not compete with eNPN.	noted	No
		S3‑194227	Necessity discussion for security study of eNA phase 2	China Mobile	discussion	Discussion	Yes	Yes	noted	No
		S3‑194415	Discussion of New Study - eNPN Vertical_LAN_SEC	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	YesNokia asked if Vertical LAN should continue as it is,with eNPN topics. Huawei preferred to split the topic as in SA2. Ericsson shared the same view. ORANGE commented that ojectives should not be key issues in SA2 so as not to have the same discussions as in SA2.	noted	No
		S3‑194416	Enhanced NPN Security for Vertical and LAN Services.doc	Nokia, Nokia Shanghai Bell	SID new	Agreement	Yes	Yes	noted	No
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑193903	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑193906	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑194699
		S3‑194699	Work Plan input from Rapporteurs	MCC	other	-	Yes	Yes	noted	No		S3‑193906
10	Future Meeting Dates and Venues	S3‑193905	SA3 meeting calendar	WG Chair	other		Yes	YesAnja (Nokia) didn’t like to have SA3#100Bis. The Chair commented that the workload didn't seem to decrease and that the meeting could always be cancelled if not needed. Bath (UK) confirmed for SA3#100.	noted	No
11	Any Other Business
12	Closing of the meeting