TDoc list

Tdoc List

2018-11-16 14:56

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‑183200	Agenda	WG Chairman	agenda		Yes	Yes	revised	No	S3‑183253
		S3‑183253	Agenda	WG Chairman	agenda	Approval	Yes	Yes	approved	No		S3‑183200
3	IPR and Anti-Trust Law Reminder
4	Meeting reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑183201	Report from SA3#92	MCC	report		Yes	Yes	approved	No
		S3‑183206	Report from SA3#92Ad-Hoc	MCC	report		Yes	Yes	approved	No
4.2	Report from SA Plenary	S3‑183203	Report from last SA meeting	WG Chairman	report		Yes	YesORANGE queried about the GSMA LS on SoR (Steering of Roaming). Ericsson commented that they had some input prepared to be checked later in the meeting.	noted	No
4.3	Report from SA3-LI	S3‑183634	TS 33 127 v110	BT plc	draft TS	Agreement	Yes	YesBT commented that this revision was a correction on a wrongly implemented CR. It was brought to this meeting for approval. BT commented that this draft was sent for information and approval to the next SA plenary.	approved	No		s3i180608
		S3‑183635	Cover sheet for presentation of TS 33.127 to SA Plenary	SA3 (SA3-LI)	TS or TR cover	Agreement	Yes	Yes	approved	No		s3i180603
5	Items for early consideration
5.1	CRs from SA3#92bis	S3‑183207	Intra-gNB-CU term synchronization	Huawei, HiSilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183208	Update RNA Update Procedure Security	Huawei, HiSilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183209	N2 HO: Handling source algorithms for RRC Reestablishment procedure	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183210	Handling of UP security policy in MR-DC	Huawei, Hisilicon, Qualcomm Incorporated, Ericsson	CR	Approval	Yes	Yes	revised	No	S3‑183835
		S3‑183835	Handling of UP security policy in MR-DC	Huawei, Hisilicon, Qualcomm Incorporated, Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑183210
		S3‑183211	Delete EN in SBA Requirements	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183212	Clarifications on AccessToken_Get Response message	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183213	Editorial corrections on Authorization of NF service access	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183214	Add discover procedure as a pre-requisite for obtaining access token	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183215	correction on the mobility from 5G to 4G	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183216	Clarification on handover from EPS to 5GS	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑183836
		S3‑183217	Editorial corrections on the 5GS to EPS handover procedure	Huawei, HiSilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183218	Clarification for Target to Source container	Huawei, HiSilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183219	Multiple NAS connections: clarification on the action of MAC verification in registration request over non-3gpp access	Huawei, HiSilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183220	Interworking – correcting keying material in HO request message (EPS to 5GS)	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑183836
		S3‑183836	Interworking – correcting keying material in HO request message (EPS to 5GS)	Ericsson,Huawei	CR	Agreement	Yes	Yes	agreed	No		S3‑183220
		S3‑183221	Length of IV salt and sequence counter	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑183222	Correction to the Security Service for Steering of Roaming	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑183223	Mobility – Clarification of downlink NAS COUNT in N2 handover	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑183224	NAS key refresh	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑183225	Caching access tokens	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑183226	Addition of multiple instance IDs to OAuth2.0 access token claims	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑183227	Corrections to references for security related service in clause 14	CATT	CR	Agreement	Yes	Yes	agreed	No
		S3‑183228	Correction to Nudm_UEAuthentication_ResultConfirmation service	CATT	CR	Agreement	Yes	Yes	agreed	No
		S3‑183229	Correction to 5G AKA procedure – no need for "SUPI or SUCI" (in step 10)	Orange, Ericsson, Nokia	CR	Approval	Yes	Yes	agreed	No
		S3‑183233	Adjusting the description of the initial NAS protection method	Qualcomm Incorporated, ZTE, China Mobile	CR	Agreement	Yes	Yes	not pursued	No
		S3‑183234	Acknowledging possibility of early calculation of EMSK	Qualcomm Incorporated, Huawei, Hsilicon	CR	Agreement	Yes	Yes	agreed	No
		S3‑183235	Precedence of protection policies on the N32 interface	Telekom Deutschland GmbH	CR	Approval	Yes	Yes	agreed	No
		S3‑183236	Handling of encrypted IEs on the N32 interface	Telekom Deutschland GmbH	CR		Yes	Yes	agreed	No
		S3‑183237	Corrections and additions in definitions and related clauses	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑183072
		S3‑183238	Clarification to AUSF key derivation	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑183097
		S3‑183239	Clarification to support of authentication methods	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑183077
		S3‑183240	Adding reference to 33.501 in 33.102	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑182957
		S3‑183241	Alignment regarding KEY reference to 33.220	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑183098
		S3‑183242	Misleading text with reference regarding serving network name	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑183099
		S3‑183243	Clarification on first bits of EMSK	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑182960
		S3‑183244	Removing mandatory text from note	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑182967
		S3‑183245	Reference correction	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	agreed	No		S3‑182968
		S3‑183246	Remove EN in 13.2	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑183247	Clarifications to clause 13.2.1	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑183248	Remove EN in 13.2.2.1	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑183249	Correction in step 2 of 13.2.2.2	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑183250	Corrections in 13.2.2.4 on N32-f context ID	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑183251	Clarifications and corrections in clause 13.2.4	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑183254	Multiple NAS Connection: Correcting NAS link identifier	Nokia	CR	Approval	Yes	Yes	agreed	No
		S3‑183255	CR to 33210 r15 adding references for the TLS Protocol Profiles clause	Juniper Networks, Ericsson	CR		Yes	Yes	agreed	No
		S3‑183256	CR to 33210 r16 adding Other 3GPP Profiles clause and references	Juniper Networks, Ericsson	CR		Yes	Yes	agreed	No
		S3‑183257	CR to 33310 r16 removing annex e	Juniper Networks, Ericsson	CR		Yes	Yes	agreed	No
5.2	Others
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑183276	LS to 3GPP TSG-SA WG6 on Use of ITS Dedicated Spectrum within V2X UE	ETSI TC ITS	LS in		Yes	YesNo action for SA3.	noted	No
		S3‑183653	3GPP SA3 statement	SA3 WG vice chair (NTT-Docomo)	other	Information	Yes	Yes	endorsed	No
		S3‑183706	LS on IAB security	R2-1818748	LS in	Discussion	Yes	YesIt was pointed out that this could have security implications that would need further study in SA3, hence the answers would be very short. Huawei commented that the answer was not trivial and more time was needed. Nokia was in line with this.Huawei pointed out that this was Rel-16 and there was no hurry. AT&T preferred to reply to RAN2 in the short deadline given by them. The Chair proposed to answer with a disclaimer given that SA3 was not aware of the full picture, just a preliminary reply. This was what Ericsson had in mind. Qualcomm agreed with this reply. Huawei: we don’t have a deadline in the LS. This can be seen for the next meeting. Nokia supported this. It was agreed to propose a draft that could be discussed. BT: the intention of RAN2 was to have a response for this week. The Chair confirmed that he was personaly contacted to have a reply for the meeting week. Qualcomm commented that RAN2 needed SA3's response to conclude their study and even a preliminary response would be useful for them. Juniper: they should design a protocol that doesn’t depend on our schoosing.	replied to	No
		S3‑183711	Reply to: LS on IAB security	Ericsson	LS out	approval	Yes	Yes	approved	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA
6.5	OMA
6.6	TCG
6.7	oneM2M
6.8	TC-CYBER
6.9	ETSI NFV
6.10	Other Groups	S3‑183277	LS on Joint ETSI - OSA Workshop: Open Implementations & Standardization	ETSI	LS in		Yes	YesAlex (BT) commented that this clashed with SA plenary. It was commented that SA3 could make a contribution about SA3 security.	noted	No
		S3‑183286	LS on SG17 work item X.5Gsec-q: Security guidelines for applying quantum-safe algorithms in 5G systems	ITU-T SG17	LS in		Yes	Yes	replied to	No
		S3‑183482	LS_to_LS on SG17 work item X 5Gsec-q	China Mobile	LS out		Yes	Yes	noted	No
		S3‑183793	Reply-LS on work item "X.5Gsec-q"	ETSI TC Cyber WG QSC	LS in	discussion	Yes	Yes	noted	No
		S3‑183794	Liaison Statement to ITU-T SG17: Response to proposal for ITU-T SG17 question on quantum-safe communication	ETSI TC Cyber WG QSC	LS in	discussion	Yes	Yes	noted	No
7	Work Areas
7.1	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
7.1.1	Key hierarchy	S3‑183554	Correction to Key hierarchy diagram	Samsung	CR		Yes	Yes	revised	No	S3‑183678
		S3‑183678	Correction to Key hierarchy diagram	Samsung	CR	-	Yes	YesRevised to make the figure bigger.	agreed	No		S3‑183554
7.1.2	Key derivation	S3‑183504	Alignment on KEY	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S3‑183556	Corrections to KSEAF derivation in Key distribution and derivation	Samsung	CR	Approval	Yes	Yes	agreed	No
7.1.3	Mobility	S3‑183345	Clarification on how AMF confirm UE SUPI	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: some incorrect statements in the note. Nokia: this is not needed. Huawei: without this, external people to SA3 will not understand the procedure. Docomo supported the fact that this was not needed.	not pursued	No
7.1.4	AS security	S3‑183318	AS subscription temperary identifier privacy	ZTE Corporation	CR	Approval	Yes	YesNokia: 5.3.X should be in a RAN spec. Ericsson: this new clause is not needed. It was agreed to remove the new clause from the CR and reword the statement on the gNB in the second change (since it wasn’t clear to which gNB it was referring).	revised	No	S3‑183663
		S3‑183663	AS subscription temperary identifier privacy	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑183318
		S3‑183408	Discussion on Support AS Security Algorithms Negotiation during INACTIVE transition and RRC Reestablishment in R15	Huawei, Hisilicon	discussion	Discussion	Yes	YesVodafone: the conclusion of the study is to do nothing for four years (potentially the next generation after 5G). NCSC: observations 1 and 2 should actually be included in the study.	noted	No
		S3‑183342	Update RRC reestablishment security procedure based on RAN2 agreement	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson, Qualcomm: it is too late to introduce this feature now.	revised	No	S3‑183664
		S3‑183664	Update RRC reestablishment security procedure based on RAN2 agreement	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑183342
		S3‑183621	Clarification on RRC Inactive procedure support by ng-eNB	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑183665
		S3‑183665	Clarification on RRC Inactive procedure support by ng-eNB	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑183621
		S3‑183407	CR-to-TS33501-RRC Reestablishment security handling when N2 Handover happens	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm: it impacts ASN.1 and it's too late for this. Ericsson: too late for this, it's more about optimization than a security issue. Docomo commented that this could go to Rel-16. The Chair commented that this should be brought back in Rel-16. This was agreed.	not pursued	No
		S3‑183322	Proposal about improvement of the UP security policy	China Mobile	CR	Approval	Yes	YesEricsson didn’t agree with the wording. Docomo was OK with having a default behaviour described here, by rewording the changes. This was taken offline.	revised	No	S3‑183666
		S3‑183666	Proposal about improvement of the UP security policy	China Mobile	CR	Approval	Yes	Yes	agreed	No		S3‑183322
		S3‑183586	Support of UP security policy in ng-eNB	Ericsson	draftCR	Approval	Yes	YesContent goes into the CR in 586 unchanged.	approved	No
		S3‑183667	Support of UP security policy in ng-eNB	Ericsson	CR	Approval	Yes	Yes	agreed	No
		S3‑183344	Adding UP security policy in SN Addition/modification Request message	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑183740
		S3‑183740	Adding UP security policy in SN Addition/modification Request message	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑183344
		S3‑183361	UP IP handling for split PDU session in MR-DC scenarios	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: UP security policy should be the same and this CRs allows to have different UP security policies. Intel: No difference between eNodeB and gNoeb termination points. Nokia: expanding this feature in Rel-15 does not make sense. Huawei: we are not proposing having different UP security policies in the same PDU session. It is the same for the PDU session. Ericsson: all bearers terminated in the same node should have the same secirity policy; the problem lies in the split.	not pursued	No
		S3‑183362	Adding NR-DC to the scenarios of MR-DC	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson didn’t agree with the changes.	revised	No	S3‑183668
		S3‑183668	Adding NR-DC to the scenarios of MR-DC	Huawei, Hisilicon,Qualcomm,Ericsson	CR	Approval	Yes	Yes	merged	No	S3‑183835	S3‑183362
		S3‑183606	Draft CR to S3-183210 (Handling of UP security policy in MR-DC)	Ericsson	draftCR	Agreement	Yes	YesQualcom disagreed. Not in line with what SA3 has agreed before. Huawei supported this CR. Nokia commented that this would introduce unnecessary complexity.Qualcomm agreed, this could be potentially a problem. Ericsson replied that RAN could be consulted on the supposed complexity of this.	merged	No	S3‑183668
		S3‑183669	Draft CR to S3-183210 (Handling of UP security policy in MR-DC)	Ericsson	draftCR	Agreement	No	Yes	withdrawn	Yes
		S3‑183622	NR-NR Dual Connectivity	Qualcomm Incorporated	CR	Agreement	Yes	YesEricsson commented that the used baseline was incorrect since the content in 6.10.4 was different from what appeared here. Huawei agreed.	merged	No	S3‑183668
		S3‑183437	Reply LS on security requirements for Integrity protection for DRBs in MR-DC	Huawei, Hisilicon	LS out		Yes	Yes	revised	No	S3‑183660
		S3‑183660	Reply LS on security requirements for Integrity protection for DRBs in MR-DC	Huawei, Hisilicon	LS out	-	Yes	Yes	approved	No		S3‑183437
		S3‑183317	Editorial modification on gNB requirement	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No
		S3‑183602	Discussion on the applicability of gNB requirements to ng-eNB	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑183644	NG-RAN – clause 6.9.2.2	Ericsson	CR	Agreement	Yes	YesIt was commented that it should be "NG-RAN node" instead of "NG-RAN". Nokia didn't agree with the new term KNG-RAN. This was confusing. Ericsson replied that this was defined in the SA3 spec already.	revised	No	S3‑183670	S3‑183603
		S3‑183670	NG-RAN – clause 6.9.2.2	Ericsson	CR	Agreement	No	Yes	agreed	No		S3‑183644
		S3‑183645	NG-RAN – clause 6.9.2.3.3	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑183671	S3‑183604
		S3‑183671	NG-RAN – clause 6.9.2.3.3	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑183645
		S3‑183646	NG-RAN – clause 6.9.2.3.4	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑183672	S3‑183605
		S3‑183672	NG-RAN – clause 6.9.2.3.4	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑183646
		S3‑183603	NG-RAN – clause 6.9.2.2	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑183644
		S3‑183604	NG-RAN – clause 6.9.2.3.3	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑183645
		S3‑183605	NG-RAN – clause 6.9.2.3.4	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑183646
		S3‑183587	E-UTRA connected to 5GC	Ericsson	draftCR	Approval	No	Yes	withdrawn	Yes
7.1.5	NAS security	S3‑183313	Modification of initial NAS message protection	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑183673
		S3‑183314	Modification on NAS SMC procedure	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑183673
		S3‑183315	Handling of initial NAS message other than RR when failure occur	ZTE Corporation	CR	Approval	Yes	YesEricsson: not clear if this is needed.	not pursued	No
		S3‑183588	Handling of initial NAS protection failures	Ericsson	draftCR	Approval	Yes	Yes	noted	No
		S3‑183589	Way forward on how to address mobility cases for the initial NAS protection mechanism	Ericsson	discussion	Endorsement	Yes	YesEricsson pointed out that relying on the CT1 solution is not very optimised.	noted	No
		S3‑183590	Handling of mobility scenarios involving an AMF key change for the initial NAS protection mechanism	Ericsson	draftCR	Approval	Yes	Yes	noted	No
		S3‑183591	Handling of mobility scenarios involving an AMF key change for the initial NAS protection mechanism	Ericsson	draftCR	Approval	Yes	Yes	noted	No
		S3‑183609	Discussion on the CT1 LS on initial NAS security	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183610	Adjusting the description of the initial NAS protection method	Qualcomm Incorporated	draftCR	Agreement	Yes	YesContents will be merged into 673 since this is a draftCR.	noted	No
		S3‑183673	Aligning the description of the initial NAS security procedures based on the CT1 agreements	Qualcomm Incorporated,ZTE	CR	Agreement	Yes	Yes	agreed	No
		S3‑183611	LS on initial NAS message protection	Qualcomm Incorporated	LS out	Approval	Yes	YesVodafone: who makes the decision on what goes on clear and what doesn’t? Qualcomm replied that it will be up to SA3.	revised	No	S3‑183741
		S3‑183741	LS on initial NAS message protection	Qualcomm Incorporated	LS out	Approval	Yes	Yes	approved	No		S3‑183611
		S3‑183374	Initial NAS Discussion on privacy solutions	Intel Corporation (UK) Ltd	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183642	Comments on S3-183374	Nokia, Nokia Shanghai Bell	discussion	Approval	Yes	YesEricsson: we should point out the implications for our preferences. Trust on the VPLMN was widely discussed in the group. Docomo didn’t see this as a big issue. Verizon preferred the solution in 565. Vodafone didn’t want visited networks breaking the level of security that the Home Network had decided. Ericsson wanted to highlight the security aspects in order to reveal the slices that are privacy sensitive. We cannot say that both solutions have the same level of security since one exposes more information than the other. Alex (BT): we need to accept that the VPLMN will have some control on this. It was agreed to write down the results of the discussions on the LS in 659.	noted	No
		S3‑183316	Editorial modification on initial NAS message protection	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑183673
		S3‑183612	Discussion on the SA2 LS on initial NAS security	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183613	LS on initial NAS message protection	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑183614	Network control of sending S-NSSAIs in the RRC signalling	Qualcomm Incorporated	CR	Agreement	Yes	Yes	not pursued	No
		S3‑183550	Discussion on the Reply LSs on initial NAS security agreements	Samsung	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183641	Comments on S3-183550 NSSAI inclusion in NAS	Nokia, Nokia Shangahi bell	other	Approval	Yes	YesSamsung: the attack is difficult but still feasible. NCSC didn’t see this attack as feasible.	noted	No
		S3‑183325	Discussion on i/c LS S2-1811543 NSSAI in RRC message	Nokia, AT&T, Verizon Wireless, Inter Digital	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183326	draft-LS out reply to i/c LS on NSSAI in RRC message	Nokia	other	Approval	Yes	Yes	noted	No
		S3‑183584	Multiple NAS connections and algorithm change	Ericsson	draftCR	Approval	Yes	YesQualcomm: Very restrictive behaviour in the UE and it is also introducing a new requirement on the UE that will make it unnecessarily complex.	noted	No
		S3‑183585	Multiple NAS connecions: mobility with horizontal KAMF derivation	Ericsson	draftCR	Approval	Yes	Yes	noted	No
		S3‑183615	Discussion on CT1 on Scenarios with multiple registrations to the same AMF	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183616	Addressing possible security context mismatch on non-3GPP acces when multiply registered on one PLMN	Qualcomm Incorporated	CR	Agreement	Yes	Yes	not pursued	No
		S3‑183601	Handling of NAS COUNTs	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑183674
		S3‑183674	Handling of NAS COUNTs	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑183601
		S3‑183328	Clarify SUPI format in KAMF computation	Nokia	CR	Approval	Yes	YesEricsson: this is stage 3 information; is it in our scope? Nokia confirmed this. Qualcomm had some issues with this so it had to be taken offline. They also commented that some alingment might be needed with CT4.	revised	No	S3‑183675
		S3‑183675	Clarify SUPI format in KAMF computation	Nokia	CR	Approval	No	Yes	agreed	No		S3‑183328
		S3‑183360	Clarification: AMF confirming UE SUPI in case NAS SMC failed	Huawei, Hisilicon	CR	Approval	Yes	YesNokia wanted to have some clarifications and a reference to the requirement needed to be added.	revised	No	S3‑183676
		S3‑183676	Clarification: AMF confirming UE SUPI in case NAS SMC failed	Huawei, Hisilicon,Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑183360
		S3‑183624	Security mechanism for UE Parameters Update via UDM Control Plane Procedure	Qualcomm Incorporated	CR	Agreement	Yes	YesVodafone: strong objection to having this in Rel-15. Vodafone asked to have minuted: Updating routing id over the air is a very poor procedure. Their objection was sustained. Qualcomm: this is a SA2 related CR and it's a Plenary discussion. IDEMIA: is this essential for Rel-15? Ericsson: it's the security solution for a SA2 CR. ORANGE: this is cat-B, not F. The Chair asked the companies to start focusing on Rel-16 instead of keep bringing input for Rel-15.	revised	No	S3‑183742
		S3‑183742	Security mechanism for UE Parameters Update via UDM Control Plane Procedure	Qualcomm Incorporated,Huawei	CR	Agreement	Yes	YesVodafone withdrew their sustained objection after a note was added in 6.Y.1. They asked to be minuted that they were not satisfied with having this CR for Rel-15 and that they may raise this concern in the next SA Plenary.	agreed	No		S3‑183624
		S3‑183636	Comments on S3-183624	NEC Corporation	other	Agreement	Yes	YesVodafone: we deal with this in the previous meeting, no point in going through this again. Provisioning is ut of scope of 3GPP.	noted	No
		S3‑183472	Discussion on UE Parameters Update via UDM Control Plane Procedure	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183474	Solution for UE Parameters Update via UDM Control Plane Procedure	Huawei, Hisilicon	CR	Agreement	Yes	YesVodafone: This is not aligned with a decision taken in SA2 since they haven't agreed in anything based on the LS that we sent during the last meeting. There are also a lot of points here that are out of scope of 3GPP. ORANGE: SA2 hasn’t answered our LS so we shouldn't waste on figuring out a solution. Docomo was more interested in the integrity protection of the ME back channel going to the Home Network. NEC: we cannot ignore that SA2 will go forward in two weeks when they have their meeting. Vodafone insisted that SA3 could not procceed without a response from SA2. Nokia: SA2 has discussed this and agreed on solutions and they are available for us, although we haven’t received a response.	merged	No	S3‑183742
		S3‑183329	Editorial correction in Clause 6.9.3.2	Nokia	CR	Approval	Yes	YesIt was commented that removing the "H" from the parameter name was not possible since this was used by CT4 and mentioned in other parts of the SA3 spec.	revised	No	S3‑183677
		S3‑183677	Editorial correction in Clause 6.9.3.2	Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑183329
		S3‑183402	Editorial corrections on NAS SMC procedure	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
7.1.6	Security context
7.1.7	Visibility and Configurability
7.1.8	Primary authentication	S3‑183501	Clarification to the transfer of authentication success result to the UDM	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S3‑183503	Correction of formatting error	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesDocomo commented that there was a reason for having the formatting; it was done to point out that the paragraph was independent.	not pursued	No
		S3‑183594	Update of EAP-AKA’ reference to make it compatible with 5G	Ericsson	draftCR	Agreement	Yes	YesMCC had issues with referencing documents that don’t exist ("future updates" or versions that will superced the current one). Ericsson commented that the current version does not work with 5G. NCSC also had issues with this. Huawei proposed to add an editor's note stating that the draft could not referenced until it was formally approved in IETF. Agreed content goes to 679.	noted	No
		S3‑183679	Update of EAP-AKA’ reference to make it compatible with 5G	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑183595	Update of EAP-AKA’ RFC 5448 in progress	Ericsson	discussion	Discussion	Yes	Yes	noted	No
7.1.9	Secondary authentication	S3‑183467	CR on Secondary Re-authentication	Huawei, HiSilicon	CR	Agreement	Yes	Yes	revised	No	S3‑183661
		S3‑183661	CR on Secondary Re-authentication	Huawei, HiSilicon	CR	Agreement	Yes	YesRewording proposed by Nokia.	agreed	No		S3‑183467
7.1.10	Interworking	S3‑183400	correction on handover procedure from 5G to 4G	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183476	Clarification on interworking	Huawei, Hisilicon	CR	Agreement	Yes	YesQualcomm didn’t agree with some of the changes. This was revised to that effect.	revised	No	S3‑183680
		S3‑183680	Clarification on interworking	Huawei, Hisilicon	CR	Agreement	Yes	Yes	agreed	No		S3‑183476
		S3‑183618	Corrections on the number of bits of downlink NAS COUNT value to be delivered in the 5GS to EPS handover procedure	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑183619	Clarification on storing the selected EPS NAS algorithms	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑183620	KgNB derivation in EPS to 5GS handover	Qualcomm Incorporated	draftCR	Approval	Yes	YesEricsson: not sure that we need these changes. There was no issue with the KgNb. This had to be taken offline.	noted	No
		S3‑183797	KgNB derivation in EPS to 5GS handover	Qualcomm Incorporated	CR	Approval	Yes	Yes	agreed	No
		S3‑183623	KgNB derivation in N2 handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑183643	Discussion on the changes proposed in S3-183620 and S3-183623	Qualcomm Incorporated	discussion		Yes	Yes	noted	No
7.1.11	non-3GPP access
7.1.12	NDS	S3‑183230	Adding references for the TLS Protocol Profiles clause	Juniper Networks, Ericsson	CR		No	Yes	withdrawn	Yes
		S3‑183231	Update NDS/IP scope with application layer crypto profiles	Juniper Networks, Ericsson	CR		No	Yes	withdrawn	Yes
		S3‑183232	Move TLS crypto profiles to TS 33.210	Juniper Networks, Ericsson	CR		No	Yes	withdrawn	Yes
		S3‑183381	Corrections to 9. Security procedures for non-service based interfaces	LG Electronics	CR	Agreement	Yes	Yes	agreed	No
7.1.13	Service based architecture
7.1.13.1	Interconnect (SEPP related)	S3‑183647	NF-SEPP TLS handling	Ericsson Hungary Ltd	draftCR	Approval	Yes	Yes	noted	No		S3‑183566
		S3‑183441	Telescopic FQDN creation within the SEPP	Telekom Deutschland GmbH, Nokia	CR	Approval	Yes	Yes	not pursued	No
		S3‑183546	Issue with using wildcard certificates in SEPP	Nokia, Nokia Shanghai Bell	discussion	Agreement	Yes	Yes	noted	No
		S3‑183633	Resolution of Editor’s note on wildcard certificates in S3-183441	Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH	CR	Agreement	Yes	Yes	not pursued	No
		S3‑183638	Scenarios that require generation of telescopic FQDN in SEPP	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	not pursued	No
		S3‑183548	Telescopic FQDN for callback URIs	Nokia, Nokia Shanghai Bell	discussion	Agreement	Yes	Yes	noted	No
		S3‑183468	Discussion on verification of PLMN ID in N32 message	Huawei, Hisilicon	discussion	Endorsement	Yes	YesVodafone didn’t agree with concern one. SA3 provides the tools to GSMA to implement the roaming agreements. The split of work between SA3 and GSMA is correct. They didn’t agree on concern 3 either. Ericsson commented that the most important point was that SEPP should check whether the PLMNid was fake. Vodafone didn’t object to this, but they wanted tools to prevent roaming agreements giving away information, come up wit some specific rules to avoid this. DT commented that the SEPP could enforce some checks and the details could be figured out offline. Ericsson, NEC: let us not put all the rules in our documents as this would be a great amount of work. We provide the tools but not the rules. Juniper supported this as well. NTT-Docomo: PLMNid should be available and the rules are implementation specific. An offline session was needed in order to come out with a joint agreement in a CR.	noted	No
		S3‑183639	Verification of PLMN ID in N32 message	Huawei, Hisilicon	CR	Agreement	Yes	Yes	not pursued	No		S3‑183469
		S3‑183443	Verification of the PLMN-ID by the receiving SEPP	Telekom Deutschland GmbH, Nokia	CR	Approval	Yes	Yes	not pursued	No
		S3‑183442	Corrections to N32 Protection Policies	Telekom Deutschland GmbH, Nokia	CR	Approval	Yes	Yes	revised	No	S3‑183684
		S3‑183684	Corrections to N32 Protection Policies	Telekom Deutschland GmbH, Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑183442
		S3‑183522	N32: remove redundant references to encrypted IEs	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑183685
		S3‑183685	N32: remove redundant references to encrypted IEs	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑183522
		S3‑183480	CR to TS 33.501 regarding N32-f key hierarchy	China Mobile	CR		Yes	Yes	agreed	No
		S3‑183547	Security between SEPP and IPX	Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH	CR	Approval	Yes	YesNEC: Say "should use" instead of "SA3 strongly recommends".	revised	No	S3‑183686
		S3‑183686	Security between SEPP and IPX	Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH	CR	Approval	Yes	Yes	agreed	No		S3‑183547
		S3‑183549	Two parallel N32-c connections between SEPPs	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑183687
		S3‑183687	Two parallel N32-c connections between SEPPs	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑183549
		S3‑183469	Verification of PLMN ID in N32 message	Huawei, Hisilicon	CR	Agreement	Yes	Yes	revised	No	S3‑183639
		S3‑183648	Draft CR Corrections to N32 Protection Policies	Telekom Deutschland	draftCR	Approval	Yes	Yes	noted	No
		S3‑183649	Draft CR Adopting more normative language in clause 13	Telekom Deutschland	draftCR	discussion	Yes	YesEricsson: you are going too far beyond the descriptive language in some points. Some other companies had also comments on other instances of the text so this was taken offline. Agreements are taken in S3-183688.	noted	No
		S3‑183655	Two parallel N32-c connections between SEPPs	Nokia	draftCR	discussion	Yes	YesAgreed content goes into S3-183687.	noted	No
		S3‑183656	Security between SEPP and IPX	Nokia	draftCR	discussion	Yes	YesAgreed content goes into 686.	noted	No
		S3‑183657	Editorial corrections in 13.2	Nokia	draftCR	discussion	Yes	YesAgreed content is included in S3-183689.	noted	No
		S3‑183681	Inter PLMN routing	Nokia	discussion	Discussion	No	Yes	withdrawn	Yes
		S3‑183682	Inter PLMN routing	Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑183683	Verification of PLMNid by the receiving SEPP	Deutsche Telekom	CR	Agreement	Yes	Yes	agreed	No
		S3‑183789	LS on verification of PLMN-ID in the SEPP	Deutsche Telekom	LS out	Approval	Yes	Yes	approved	No
7.1.13.2	Other	S3‑183478	Update on access token in roaming scenario	Huawei, Hisilicon	CR	Agreement	Yes	Yes	revised	No	S3‑183743
		S3‑183743	Update on access token in roaming scenario	Huawei, Hisilicon	CR	Agreement	Yes	Yes	agreed	No		S3‑183478
		S3‑183479	Remove the shared secret based token protection mechanism from the token related procedure	Huawei, Hisilicon	CR	Agreement	Yes	YesChina Mobile objected to this contribution. Nokia was in favour of not changing it either, maybe leave it as an implementation issue.	not pursued	No
		S3‑183523	pSEPP-pNF authentication	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑183444	Adopting more normative language in clause 13	Telekom Deutschland GmbH, Nokia	CR	Approval	Yes	Yes	revised	No	S3‑183688
		S3‑183688	Adopting more normative language in clause 13	Telekom Deutschland GmbH, Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑183444
		S3‑183422	Editorial corrections on Application layer security on the N32 interface	Huawei, Hisilicon	CR	Approval	Yes	YesNokia: it overaps with some other contributions.	merged	No	S3‑183689
		S3‑183499	Shift of text from SEPP intro to subclause	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesEricsson: the new clause should be an introduction of 13.2 and not the whole clause 13.	revised	No	S3‑183690
		S3‑183690	Shift of text from SEPP intro to subclause	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑183499
		S3‑183540	Editorial corrections in 13.2	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑183689
		S3‑183689	Editorial corrections in 13.2	Nokia, Nokia Shanghai Bell,Huawei	CR	Agreement	Yes	Yes	agreed	No		S3‑183540
		S3‑183566	NF-SEPP TLS handling	Ericsson India Private Limited	CR	Agreement	Yes	Yes	revised	No	S3‑183647
		S3‑183382	IP protection for SN terminated bearers	Intel Corporation (UK) Ltd	CR		Yes	YesUsed baseline was wrong.	not pursued	No
		S3‑183708	Minutes of SBA Offline Discussion	Deutsche Telekom	report	discussion	No	Yes	withdrawn	Yes
7.1.14	Privacy	S3‑183628	Clarifications to SUPI and SUCI	Qualcomm Incorporated	draftCR	Approval	Yes	YesIDEMIA commented that SUPI type was needed since there were two types. Qualcomm: SUPI type is not needed since in here it is always the IMSI. Some offline discussion on whether the SUPI type was needed or not. This was noted and the agreed content made into a CR.	noted	No
		S3‑183525	Maximum output size of SUPI concealment schemes	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183524	Maximum output size of SUPI concealment scheme	Ericsson	draftCR	Approval	Yes	YesThere were some concerns on mandating the 3000 octets so this had to be taken offline. Vodafone: I don’t want issues when a legacy USIM is in a new UE. Agreed content goes to 692.	noted	No
		S3‑183692	Maximum output size of SUPI concealment scheme	Ericsson	CR	Approval	Yes	Yes	agreed	No
		S3‑183500	Clarification to protection scheme identifier	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑183693
		S3‑183693	Clarification to protection scheme identifier	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑183500
		S3‑183502	Intro of subclauses to clause 6.12.2	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesORANGE commented that the last title should not be about guidance since it was normative. IDEMIA and Qualcomm didn’t find this useful so it was not pursued.	not pursued	No
		S3‑183505	Alignment on Home Network Public Key	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesMCC commented that the clauses in the changes should follow the order in the specification (6.2.2 at the end was wrong).	revised	No	S3‑183694
		S3‑183694	Alignment on Home Network Public Key	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑183505
		S3‑183625	Clarifications to SUPI and SUCI	Qualcomm Incorporated	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑183790	Clarifications to SUPI and SUCI	Qualcomm,Nokia	CR	Agreement	Yes	YesNokia commented some points of confusion coming from their CT4 colleagues.	agreed	No
7.1.15	Incoming and outgoing Lses	S3‑183264	Reply LS on maximum output size of SUPI concealment schemes	C1-186992	LS in		Yes	Yes	replied to	No
		S3‑183265	LS on Scenarios with multiple registrations to the same AMF	C1-186993	LS in		Yes	YesThis information has been taken into account in other documents.	noted	No
		S3‑183266	Reply LS on inclusion of selected PLMN into the complete message	C1-186994	LS in		Yes	Yes	noted	No
		S3‑183267	Reply LS on initial NAS security agreements	R2-1816022	LS in		Yes	Yes	noted	No
		S3‑183268	LS on initial NAS message protection	C1-186995	LS in		Yes	Yes	replied to	No
		S3‑183272	LS on N32 error signalling	C4-187145	LS in		Yes	Yes	noted	No
		S3‑183273	Reply LS on Maximum output size of SUPI concealment schemes	C4-187633	LS in		Yes	Yes	replied to	No
		S3‑183281	LS on security requirements for Integrity protection for DRBs in MR-DC	R2-1816054	LS in		Yes	Yes	replied to	No
		S3‑183283	Reply LS on Secondary Re-Authentication	S2-1811431	LS in		Yes	Yes	noted	No
		S3‑183284	Reply LS on Clarifications on SUPI definition and NAI format	S2-1811525	LS in		Yes	Yes	replied to	No
		S3‑183662	Reply to: Reply LS on Clarifications on SUPI definition and NAI format	Qualcomm	LS out	approval	Yes	Yes	approved	No
		S3‑183287	Reply LS on initial NAS security agreements	S2-1811568	LS in		Yes	Yes	approved	No
		S3‑183659	Reply to:LS on initial NAS security agreements	Intel	LS out	approval	Yes	Yes	approved	No
		S3‑183295	Draft Reply LS to ITU-T SG17 on X.5Gsec-q study	NCSC	LS out	Approval	Yes	YesVodafone preferred this LS to the option presented by China Mobile. The Chair commented that it was agreed in the previous SA3 meeting that a response LS was needed to tell ITU-T that there was an overlap and this needed to be avoided.	revised	No	S3‑183654
		S3‑183654	Reply LS to ITU-T SG17 on X.5Gsec-q study	NCSC	LS out	Approval	No	Yes	approved	No		S3‑183295
		S3‑183363	Reply LS on security requirements for Integrity protection for DRBs in MR-DC	Huawei, Hisilicon	CR	Approval	No	Yes	withdrawn	Yes
		S3‑183375	draft reply LS on security requirements for RRC connection release	Intel Corporation (UK) Ltd	LS out		Yes	YesBT: does this apply to emergency calls? They are an exception. Ericsson: we don’t need the LS since we agree with their LS and there is no action.	noted	No
		S3‑183466	Discussion on LS from SA2 on 2nd Authentication	Huawei, HiSilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183658	Response LS on maximum output size of SUPI concealment schemes	Ericsson	LS out	Approval	Yes	Yes	approved	No
		S3‑183830	Assigning additional FC values to TS 33.501	Qualcomm	CR	Agreement	Yes	Yes	agreed	No
7.1.16	Others	S3‑183298	Corrections to definition of 5G NAS security context	CMCC	CR	Approval	No	Yes	revised	No	S3‑183303, S3‑183304
		S3‑183302	Discussion on one potential way to improve the efficiency of IP	Apple Computer Trading Co. Ltd	discussion	Discussion	Yes	Yes	revised	No	S3‑183632
		S3‑183303	Unify the name of RAN network in 33.501	CMCC	CR	Approval	No	Yes	revised	No	S3‑183324	S3‑183298
		S3‑183304	Replace 5G-RAN with NG-RAN in 33.501	China Mobile	CR	Approval	No	Yes	withdrawn	Yes		S3‑183298
		S3‑183323	Corrections to definition of 5G AS security context for 3GPP access	China Mobile	CR	Approval	Yes	Yes	revised	No	S3‑183695
		S3‑183695	Corrections to definition of 5G AS security context for 3GPP access	China Mobile	CR	Approval	Yes	Yes	agreed	No		S3‑183323
		S3‑183324	Replace 5G-RAN with NG-RAN in TS 33.501	China Mobile	CR	Approval	Yes	YesNokia didn't agree with this. Ericsson: there is no 5G RAN term. We should change this.	agreed	No		S3‑183303
		S3‑183379	Corrections to 5.2 Requirements on the UE	LG Electronics	CR	Agreement	Yes	Yes	agreed	No
		S3‑183380	Corrections to 5.3 Requirements on the gNB	LG Electronics	CR	Agreement	Yes	Yes	agreed	No
		S3‑183401	Editorial corrections on the UP integrity mechanisms	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183438	CR to TS33.501-Registration related text correction	CATT	CR	Agreement	Yes	YesThis had to be checked offline as petitioned by Ericsson.	revised	No	S3‑183738
		S3‑183738	CR to TS33.501-Registration related text correction	CATT	CR	Agreement	Yes	Yes	agreed	No		S3‑183438
		S3‑183632	Discussion on one potential way to improve the efficiency of IP	Apple Computer Trading Co. Ltd	discussion	Discussion	Yes	YesLenovo: this should be studied in one of the current SIDs, better not to agree on these conclusions right now. Qualcomm: there are issues with the randomised IV. Vodafone agreed that this was a good input for some of the Studies brought into this meeting.	noted	No		S3‑183302
7.2	Security Assurance Specification for 5G (SCAS_5G) (Rel-16)
7.2.1	NR Node B (gNB) (TS 33.511)	S3‑183430	UPdate test cases in 33.511	Huawei, Hisilicon	pCR	Approval	Yes	YesDiscussed together with the paper from Ericsson in 608.	revised	No	S3‑183696
		S3‑183696	UPdate test cases in 33.511	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183430
		S3‑183429	Adding Execution Steps to in 4.2.2.1.1, 4.2.2.1.2, and 4.2.2.1.7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑183698
		S3‑183698	Adding Execution Steps to in 4.2.2.1.1, 4.2.2.1.2, and 4.2.2.1.7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183429
		S3‑183406	Add the evidences of the test cases	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑183405	Mapping requirements and test cases from 33.216 to 33.511	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑183699
		S3‑183699	Mapping requirements and test cases from 33.216 to 33.511	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183405
		S3‑183431	New requirements and testcases on UP security policy related	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑183697	Draft TS 33.511	Huawei	draft TS	Approval	Yes	Yes	approved	No
7.2.2	Access and Mobility Management Function (TS 33.512)	S3‑183555	RES* verification failure test case	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑183446	Adding unique names to test cases	Telekom Deutschland GmbH	pCR	Approval	Yes	Yes	approved	No
		S3‑183700	draft TS 33.512	Deutsche Telekom	draft TS	Approval	Yes	Yes	approved	No
7.2.3	User Plane Function (UPF) (TS 33.513)
7.2.4	Unified Data Management (UDM) (TS 33.514)	S3‑183637	PCR to TR33.514 SUCI test case correction	CATT	pCR	Approval	Yes	Yes	revised	No	S3‑183701
		S3‑183701	PCR to TR33.514 SUCI test case correction	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑183637
		S3‑183702	Draft TS 33.514	NEC	draft TS	Approval	Yes	Yes	approved	No
7.2.5	Session Management Function (SMF) (TS 33.515)
7.2.6	Authentication Server Function (AUSF) (TS 33.516)	S3‑183607	draft TS 33.516 (AUSF SCAS)	Ericsson India Private Limited	draft TS	Approval	Yes	Yes	approved	No
7.2.7	Security Edge Protection Proxy (SEPP) (TS 33.517)	S3‑183387	Skeleton of SCAS SEPP TS 33.517	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑183388	Scope of SCAS SEPP TS 33.517	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑183389	Reference of SCAS SEPP TS 33.517	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑183703	Draft TS 33.517	Nokia	draft TS	Approval	Yes	Yes	approved	No
7.2.8	Network Resource Function (NRF) (TS 33.518)	S3‑183390	Skeleton of SCAS NRF TS 33.518	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑183391	Scope of SCAS NRF TS 33.518	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑183392	Reference of SCAS NRF TS 33.518	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑183704	Draft TS 33.518	Nokia	draft TS	Approval	Yes	Yes	approved	No
7.2.9	Network Exposure Function (NEF) (TS 33.519)	S3‑183319	Scope of TS 33.519	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑183320	References of TS 33.519	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑183321	Authentication on application functions	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑183707
		S3‑183707	Authentication on application functions	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑183321
		S3‑183705	Draft TS 33.519	ZTE	draft TS	Approval	Yes	Yes	approved	No
7.3	eMCSec R16 security (MCXSec) (Rel-16)
7.4	Other work areas
7.4.1	SAE/LTE Security	S3‑183343	eNB allowing Unauthenticated UEs in LSM	Huawei, Hisilicon	CR	Approval	Yes	YesNokia: it adds a new requirement for existing eNodeBs. The solution could be a simple configuraton issue. The CR is not necessary. Ericsson: just refer to TS 36.413. NTT-Docomo didn’t understand the need for this. This was taken offline.	not pursued	No
		S3‑183373	Correction on LTE suspend/resume procedure for EDT capable UE	Intel Corporation (UK) Ltd	CR		Yes	YesVodafone was puzzled: we have done integrity protection for LTE without a WID, but for 5G we needed a Work Item. Nokia offered some rewording so the document was revised for this.	revised	No	S3‑183650
		S3‑183650	Correction on LTE suspend/resume procedure for EDT capable UE	Intel Corporation (UK) Ltd	CR	-	Yes	Yes	agreed	No		S3‑183373
		S3‑183593	LTE EDT – integrity protection of uplink EDT data	Ericsson	CR	Agreement	Yes	YesEricsson commented that RAN groups had to be queried whether this change was possible.They wanted to provide integrity protection for the uplink data and keep it 32 bits. An LS would have to be sent during the meeting week. It was pointed out that this CR was for Rel-15. Note from MCC: it is too late to bring cat-B CRs for Rel-15 so this has to be checked.	merged	No	S3‑183651
7.4.2	IP Multimedia Subsystem (IMS) Security
7.4.3	Network Domain Security (NDS)	S3‑183258	CR to 33310 r15 corrections of references and annex	Juniper Networks, Ericsson	CR		Yes	Yes	agreed	No
		S3‑183259	CR to 33310 r16 corrections of references	Juniper Networks, Ericsson	CR		Yes	Yes	agreed	No
7.4.4	UTRAN Network Access Security
7.4.5	GERAN Network Access Security
7.4.6	Generic Authentication Architecture (GAA)
7.4.7	Security Aspects of Home(e)NodeB (H(e)NB)
7.4.8	Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)	S3‑183278	Observations on standards and technical constraints from 2nd MCPTT Plugtests	ETSI CTI	LS in		Yes	Yes	noted	No
		S3‑183263	LS on Observations from 2nd MCPTT Plugtests	C1-186964	LS in		Yes	Yes	noted	No
		S3‑183305	Add symmetric key distribution mechanisms to TS 33.180	Airbus DS SLC	discussion	Approval	Yes	YesEricsson: for what Release do you want this? Airbus: this release if possible. Some companies were agains this in release 16 (Vodafone, NCSC).	noted	No
		S3‑183419	Security solution for temporary group – broadcast group call procedure	Huawei, Hisilicon	CR	Approval	Yes	YesMotorola: not technically possible to do this. The Chair commented that this was a new solution being brought into Release 15, far from cat F.	not pursued	No
7.4.9	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑183383	5G inclusion in TS 33.117	Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH	CR	Approval	Yes	YesMCC commented that this should be Rel-16 work and the WID code should be SCAS_5G.	agreed	No
		S3‑183384	Incorporating general SBA aspects in TS 33.117	Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH	CR	Approval	Yes	YesThe Chair commented that this was a specification under change control and that adding empty clauses was not the right way of doing it. It was agreed to have a living document in the form of a draft CR where content could be added every meeting. Once the whole change is agreed, the last version of the draft CR will become a CR and all changes implemented directly into TS 33.117.	not pursued	No
		S3‑183385	Test Case of transport layer protection for SBI	Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH	CR	Approval	Yes	YesContent will go into the draft CR.	not pursued	No
		S3‑183386	Editorial corrections in TS 33.117	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesMCC commented that the editorial changes should go into the Rel-16 version of the specification.	agreed	No
		S3‑183428	Add EDCE5 realted requirements and testcases to 33.216	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑183710
		S3‑183710	Add EDCE5 realted requirements and testcases to 33.216	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑183428
		S3‑183432	Update requirements in 4.2.3.2.2 in 33.117	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑183452	New test case: No code execution or inclusion of external ressources by JSON parsers	Telekom Deutschland GmbH	CR	Approval	Yes	YesContent is agreed and it will go into the draftCR in 709.	not pursued	No
		S3‑183498	Formatting issue	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S3‑183515	Adding missing references in TS 33.117	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑183608	SCAS discussion	Ericsson India Private Limited	pCR	Discussion	Yes	Yes	noted	No
		S3‑183626	General SCAS API requirements	Ericsson India Private Limited	CR	Approval	Yes	YesNokia wondered if this was a security input. Huawei considered that these kind of test cases were not usually discussed in SA3. This will go into the draft CR in 709.	not pursued	No
		S3‑183709	Draft CR Incorporating general SBA aspects in TS 33.117	Nokia	draftCR	Approval	Yes	Yes	approved	No
7.4.10	Security Aspects of Narrowband IOT (CIoT)	S3‑183409	Discussion on UP Integrity protection for small data in Early Data Transfer	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183410	LS to RAN23 on UP Integrity Protection for Small Data in Early Data Transfer	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑183652
		S3‑183652	LS to RAN23 on UP Integrity Protection for Small Data in Early Data Transfer	Huawei, Hisilicon	LS out	Approval	Yes	Yes	approved	No		S3‑183410
		S3‑183411	User Plane Integrity Protection for EDT	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑183651
		S3‑183651	User Plane Integrity Protection for EDT	Huawei, Hisilicon,Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑183411
		S3‑183832	Reply LS on UP Integrity Protection for Small Data in Early Data Transfer	R3-187230	LS in	discussion	Yes	Yes	noted	No
		S3‑183833	Reply LS on UP Integrity Protection for Small Data in Early Data Transfer	R2-1818666	LS in	discussion	Yes	Yes	noted	No
7.4.11	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)	S3‑183279	Reply LS on " LS on Using same counter in EDCE5"	R2-1816010	LS in		Yes	Yes	noted	No
		S3‑183592	EDCE5 – Fixing contradicting and insecure scg/sk counter handling in 33.401 from 36.331	Ericsson	CR	Agreement	Yes	YesNokia: all these changes complicate the implementation. It was agreed to add a note. Huawei: this is not needed. RAN2 already understands what the counter is about.	revised	No	S3‑183712
		S3‑183712	EDCE5 – Fixing contradicting and insecure scg/sk counter handling in 33.401 from 36.331	Ericsson	CR	Agreement	Yes	Yes	not pursued	No		S3‑183592
7.4.12	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.4.13	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)	S3‑183270	LS on security method negotiation	C3-186335	LS in		Yes	Yes	replied to	No
		S3‑183557	Association of security context	Samsung	CR		Yes	YesNEC didn't see this as a fix.Ericsson agreed. This had to be taken offline, .	not pursued	No
		S3‑183560	[DRAFT] LS on Security method negotiation	Samsung	LS out		Yes	Yes	revised	No	S3‑183795
		S3‑183795	LS on Security method negotiation	Samsung	LS out	-	Yes	Yes	approved	No		S3‑183560
		S3‑183271	LS on API invoker onboarding	C3-186414	LS in		Yes	Yes	noted	No
		S3‑183558	Missing subclause headings	Samsung	CR		Yes	YesNEC doubted that adding sub-clauses would cause less confusion. This is a SA6 issue, no action for SA3. They didn't have a strong opposition for not having these sub-clauses though.	agreed	No
		S3‑183559	[DRAFT] LS on API invoker onboarding	Samsung	LS out		Yes	YesNEC and Ericsson: the original LS was to SA6, not SA3.	noted	No
		S3‑183341	Correction/enhancement in CAPIF TS	NEC Corporation	CR	Agreement	Yes	YesEricsson: change reference to our own TLS profile in 33.310. Revised also to correct errors on the cover page.	revised	No	S3‑183713
		S3‑183713	Correction/enhancement in CAPIF TS	NEC Corporation	CR	Agreement	Yes	Yes	agreed	No		S3‑183341
		S3‑183421	Delete information during API invoker offboarding	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑183716
		S3‑183716	Delete information during API invoker offboarding	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑183421
		S3‑183439	Security requirements on the CAPIF-3e/4e/5e reference points	China Telecommunications	CR	Approval	Yes	YesNEC commented that this was rel-16 work, and this CR was bringing the functionality change in Rel-15 and this was not possible anymore. The CR cover page even mentions the enhancements in Rel-16. It was agreed to wait for SA6 to finish their work and then initiate work in SA3,possibly with a WID.	not pursued	No
7.4.14	PLMN RAT selection (Steering of Roaming) (Rel-15)	S3‑183285	LS Reply on Control Plane Solution for Steering of Roaming in 5GS	GSMA	LS in		Yes	YesSA will respond to this one.	noted	No
		S3‑183274	LS on Control Plane Solution for Steering of Roaming in 5GS	CP-182234	LS in		Yes	Yes	noted	No
		S3‑183260	Reply LS on Control Plane Solution for Steering of Roaming in 5GS	C1-186841	LS in		Yes	YesVodafone wasn’t happy with the security response. Tim also mentioned that the non -security part had also wrong issues (but out of scope for SA3). T-Mobile didn't see the point of concern. They were happy with the CT1 response. Qualcomm didn’t see so many problems with this response. Vodafone: there are two different mechanisms ending in two different points. This is not conveyed in here. T-Mobile commented that CT1 points out that encryption was available for the operator, optional, and it was highlighted why. The Chair didn’t want to restart a discussion on SoR; this had been done in SA3 before; so he proposed to have a quick response. Alex(BT) commented that CT1 had messed up with the LI requirements. The regulatory bits were not correct.	noted	No
		S3‑183553	Draft-Reply LS on Control Plane Solution for Steering of Roaming in 5GS	Samsung	LS out	Approval	Yes	YesVodafone didn’t agree with this response.	noted	No
		S3‑183715	LS on Control Plane Solution for Steering of Roaming in 5GS	Vodafone	LS out	Approval	Yes	Yes	approved	No
7.4.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑183269	LS on EAS-C&U support	C3-186313	LS in		Yes	Yes	postponed	No
		S3‑183714	Reply to: LS on EAS-C&U support	Vodafone	LS out	approval	No	Yes	withdrawn	Yes
7.4.16	Other work items
7.5	New Work Item proposals	S3‑183367	New WID on security aspects of single radio voice continuity from 5G to 3G	China Unicom, Huawei, HiSilicon, ZTE, CATT, OPPO, CATR	WID new		Yes	YesORANGE: no need to put the different scenarios in the justification, just to refer to SA2.Make a better link to SA2 in both justification and objectives. Huawei clarified that SA2 had just approved their WID in their last meeting, so the dates were changed to accommodate this. It was noted that China Unicom was not in the meeting, but Huawei clarified that they would attend in future meetings to take care of this work.	revised	No	S3‑183739
		S3‑183739	New WID on security aspects of single radio voice continuity from 5G to 3G	China Unicom, Huawei, HiSilicon, ZTE, CATT, OPPO, CATR	WID new	-	Yes	Yes	agreed	No		S3‑183367
		S3‑183450	New WID - Updates and enhancements to BEST for 5G	VODAFONE Group Plc	WID new	Agreement	Yes	YesQualcomm: we have already AKMA for Rel-16 and it’s related to this. We could include this work here. Vodafone commented that there was no such relationship. Ericsson: bring a study instead. It’s a new feature in the 5G system and we would need to do some study work before going normative. ORANGE agreed and also preferred to have it separately from AKMA. KPN supported having this in 5G directly as normative work. Vodafone: the study item will generate unnnecessary time and effort that will be later duplicated in the WID. They also had concerns that this WID wouldn’t be approved despite the study work. NEC: just create a WID with a narrow scope, a couple of contributions and we do a one step approval. It was proposed to create TEI16 CRs but that wasn't considered as a proper working method by ORANGE and supported by MCC. It was also pointed out that it was incorrectly shown TR 33.163 instead of TS 33.163. Qualcomm pointed out that there was overlap with the scope of AKMA. This had to be taken offline and it was later postponed.	postponed	No
8	Studies
8.1	Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)	S3‑183565	New option for 33.855 solution #8	Ericsson India Private Limited	pCR	Approval	Yes	Yes	revised	No	S3‑183723
		S3‑183723	New option for 33.855 solution #8	Ericsson India Private Limited	pCR	Approval	Yes	Yes	approved	No		S3‑183565
		S3‑183724	Draft TR 33.855	Deutsche Telekom	draft TR	Approval	Yes	Yes	approved	No
8.2	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)	S3‑183440	New SID on LTKUP Detailed Solutions	VODAFONE Group Plc	SID new	Agreement	Yes	Yes	revised	No	S3‑183755
		S3‑183755	New SID on LTKUP Detailed Solutions	VODAFONE Group Plc	SID new	Agreement	Yes	Yes	agreed	No		S3‑183440
		S3‑183445	pCR to TR 33.834 - Update to LTKUP Conclusions	VODAFONE Group Plc	pCR	Approval	Yes	YesGemalto wanted to add solution 5 together with solution 4b.MCC asked what was the intention of having a TR 900 series.Vodafone replied that a new SID was being brought to create such TR that would take the chosen solutions and describe them in more detail. The 900 series TR could be referenced externally.	revised	No	S3‑183752
		S3‑183752	pCR to TR 33.834 - Update to LTKUP Conclusions	VODAFONE Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑183445
		S3‑183753	Draft TR 33.834	Vodafone	draft TR	Approval	Yes	Yes	approved	No
		S3‑183754	cover sheet TR 33.834	Vodafone	TS or TR cover	discussion	Yes	Yes	approved	No
8.3	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)	S3‑183261	Reply LS on the Impacts of increasing the MAC-I and NAS-MAC size	R2-1816012	LS in		Yes	Yes	noted	No
		S3‑183262	Reply LS on LS on the Impacts of increasing the MAC-I and NAS-MAC size	C1-186961	LS in		Yes	Yes	noted	No
		S3‑183252	pCR to TS 33.841 - restructure of section 4 as agreed in conf call	VODAFONE Group Plc	pCR	Agreement	Yes	YesNCSC: too late to introduce all this information, additonal drivers for 256 bits. AT&T: there will be a period of time required for SAGE to do the anylisis for the appropriate algorithms supporting 256bits. We are likely entering into Rel-17 with this. Rel-16 would serve as analysis of the algorithms. We are favouring this document. Vodafone: there are other reasons why we are doing 256 bits.	noted	No
		S3‑183308	Algorithm Agility	NIST	pCR	Approval	Yes	YesNCSC: no need to add information that we haven’t looked at. NEC: the bullet points look like the objectives of a study. They should be removed.	noted	No
		S3‑183309	pCR Discussing mitigating of risks by using larger keys	NIST	pCR	Approval	Yes	YesNCSC: reluctant to write this down, we disagree with this document. Ericsson supported this. Gemalto and Huawei agreed with the content of the text. Vodafone: the conclusion we agreed on last meeting was that we don’t need to do anything for 4 years. The support/non support was balanced and this was taken offline.	noted	No
		S3‑183507	pCR to 33.841 (256bit) - Update section 4 with new drivers	VODAFONE Group Plc	pCR	Approval	Yes	YesNCSC: this brings a new driver that would need additional analysis and assesment. Qualcomm disagreed with the document as well. Vodafone: if companies are comfortable with the 4 year wait, then we don’t need to discuss theese documents. Huawei didn't agree with waiting for 4 years. Vodafone: if companies agree with not asking SAGE to start the process, then we can withdraw all these documents. CATT: we need 256 bits for classified communications. We support this. NCSC: introducing this now means an additional year of work to assess it. Nokia: our requirements can stand for 4 years. Vodafone: SAGE estimates a year to come back with the algorithms analysis. Vodafone proposed to send an LS to ask SAGE what algorithm would be suitable for 256 integrity and cyphering. NCSC questioned the necessity to do this. Vodafone: there are market drivers for this. Support for sending the LS: AT&T, NEC, Airbus, China Mobile, IDEMIA, Gemplus, CATT,CATR, NIST,Vodafone,Huawei,Qualcomm,T-Mobile, ZTE. Vodafone: happy to withdraw these documents and make the spec more quantum computing directed and not having to justify the time frame with them. This was agreed and a number of documents were noted.	noted	No
		S3‑183451	pCR to TR 33 841 Threat details to symmetric cryptography	CATT	pCR	Approval	Yes	YesNCSC didn’t agree with the first change, not required. "To the best of our knowldege" was removed. Second change should go away too. This was agreed.	revised	No	S3‑183757
		S3‑183757	pCR to TR 33 841 Threat details to symmetric cryptography	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑183451
		S3‑183310	pCR to Include content discussing forward security	NIST	pCR	Approval	Yes	Yes	revised	No	S3‑183759
		S3‑183759	pCR to Include content discussing forward security	NIST	pCR	Approval	Yes	Yes	approved	No		S3‑183310
		S3‑183292	Update to Impacted NextGen Areas - TR 33.841	NCSC	pCR	Approval	Yes	YesBT: not only 5G voice but also media should be included here. NCSC commented that was topic for another study. Ericsson suggested some editorials. 6.2.5 and 6.1.10 were removed.	revised	No	S3‑183760
		S3‑183760	Update to Impacted NextGen Areas - TR 33.841	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑183292
		S3‑183481	pCR to TR 33 841 regarding key derivation function	China Mobile; Vodafone	pCR		Yes	YesNCSC: last sentence is not always true. Last two sentences were removed.	revised	No	S3‑183761
		S3‑183761	pCR to TR 33 841 regarding key derivation function	China Mobile; Vodafone	pCR	-	Yes	Yes	approved	No		S3‑183481
		S3‑183629	TR 33.841: complete clause on OTA mechanism	Gemalto N.V.	pCR	Approval	Yes	Yes	revised	No	S3‑183762
		S3‑183762	TR 33.841: complete clause on OTA mechanism	Gemalto N.V.	pCR	Approval	Yes	Yes	approved	No		S3‑183629
		S3‑183447	pCR to TR 33 841 Performance aspects for the new 256-bit algorithms	CATT	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑183477	pCR to TR 33 841 Study of individual algorithm details	CATT, CAICT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO	pCR	Approval	Yes	Yes	revised	No	S3‑183763
		S3‑183763	pCR to TR 33 841 Study of individual algorithm details	CATT, CAICT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO	pCR	Approval	Yes	Yes	approved	No		S3‑183477
		S3‑183516	Clause 13.1.1: AES modes	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑183764
		S3‑183764	Clause 13.1.1: AES modes	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183516
		S3‑183475	pCR to TR 33 841 Potential requirements	CAICT, CATT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO	pCR	Approval	Yes	YesLast paragraph of 14.3 is not accurate. Vodafone: this needs to be clearly a requirements clause.	merged	No	S3‑183766
		S3‑183290	Potential Requirements for TR 33.841	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑183766
		S3‑183766	Potential Requirements for TR 33.841	NCSC, CAICT, CATT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO	pCR	Approval	Yes	Yes	approved	No		S3‑183290
		S3‑183473	pCR to TR 33.841 draft conclusion	CAICT, CATT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO, Qihoo 360	pCR	Approval	Yes	YesVodafone: not possible to have this in Rel-16, it will be Rel-17 or Rel-18. NIST: this doesn’t reflect the content of the document.	merged	No	S3‑183767
		S3‑183291	Conclusions for TR 33.841	NCSC	pCR	Approval	Yes	YesVodafone and NIST preferred this conclusion to the document 473. It was agreed to revise this including some bits of the CATT document.	revised	No	S3‑183767
		S3‑183767	Conclusions for TR 33.841	NCSC, CAICT, CATT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO, Qihoo 360	pCR	Approval	Yes	Yes	approved	No		S3‑183291
		S3‑183293	Editorials for TR 33.841	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑183768
		S3‑183768	Editorials for TR 33.841	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑183293
		S3‑183294	Modifications and Clarifications for TR 33.841	NCSC	pCR	Approval	Yes	YesGemalto: don’t remove the text in clause 9.1. It introduces some useful background. MCC commented that the use of "must" was not allowed in 3GPP specifications. This was reworded.	revised	No	S3‑183765
		S3‑183765	Modifications and Clarifications for TR 33.841	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑183294
		S3‑183393	pCR to TR 33.841 draft conclusion	CATT	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑183448	pCR to TR 33 841 Potential requirements	CATT	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑183449	pCR to TR 33 841 Study of individual algorithm details	CATT	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑183756	LS to SAGE on 256bit algorithms	Vodafone	LS out	Approval	Yes	Yes	approved	No
		S3‑183758	Draft TR 33.841	Vodafone	draft TR	Approval	No	Yes	approved	No
		S3‑183769	Cover sheet TR 33.841	Vodafone	TS or TR cover	Approval	No	Yes	approved	No
8.4	Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)	S3‑183395	Proposed change to the solution #1.1 of TR 33.856	Huawei, Hisilicon	pCR	Approval	Yes	YesQualcomm wanted to add a sentence in step 2 on using a different FC value that cannot be used in another key derivation. The NOTE in 4 needs to be aligned with the previous statement.	revised	No	S3‑183728
		S3‑183728	Proposed change to the solution #1.1 of TR 33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183395
		S3‑183396	clean up the EN of subclause 6.4.3 in TR 33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑183398	add evaluation to solution #5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑183368	Impacts on existing nodes and functionality for the solution "Return from UTRAN to E-UTRAN or NR"	China Unicom	pCR		Yes	Yes	approved	No
		S3‑183369	Evaluation for the solution "Return from UTRAN to E-UTRAN or NR"	China Unicom	pCR		Yes	YesDocomo commented that the phrase had to be reworded since there was some confusion with the description of the attack.	revised	No	S3‑183730
		S3‑183730	Evaluation for the solution "Return from UTRAN to E-UTRAN or NR"	China Unicom	pCR	-	Yes	Yes	approved	No		S3‑183369
		S3‑183370	Conclusion for the solution "Return from UTRAN to E-UTRAN or NR"	China Unicom	pCR		Yes	YesMCC commented that the second sentence on the normative work expected in 33.501 was not relevant to the TR and more related to plans for a future WID, so this was removed.	revised	No	S3‑183731
		S3‑183731	Conclusion for the solution "Return from UTRAN to E-UTRAN or NR"	China Unicom	pCR	-	Yes	Yes	approved	No		S3‑183370
		S3‑183397	clean up the EN of subclause 7 in TR 33.856	Huawei, Hisilicon	pCR	Approval	Yes	YesRevised to remove the entirety of the editor's note.	revised	No	S3‑183732
		S3‑183732	clean up the EN of subclause 7 in TR 33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183397
		S3‑183617	Addressing the editor’s notes in the conclusions clause of TR 33.856	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑183399	editorial modification on TR 33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑183729	Draft TR 33.856	China Unicom	draft TR	Approval	Yes	Yes	approved	No
		S3‑183733	Cover sheet TR 33.856	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
8.5	Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)	S3‑183394	Protecting SUPI for user privacy	ZTE Corporation	pCR	Approval	Yes	YesZTE: it doesn’t say anything between the UE and the network. Huawei: we don’t need this here. ORANGE: separate both requirements. Adding privacy protection and the purpose of this in the revision, as proposed by Qualcomm and ORANGE.	revised	No	S3‑183734
		S3‑183734	Protecting SUPI for user privacy	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑183394
		S3‑183533	Key Issue on Compliance with Local Rules and Regulations	NEC Corporation	pCR	Approval	Yes	YesMCC commented that the sentence of "AKMA should be made regulations aware.." looked like a requirement. It was pointed out that this wasn't the intention and it was agreed to reword it as "needs to be done.." directly into the spec by the rapporteur.	approved	No
		S3‑183544	New Key Issue: Generic battery efficient end-to-end security	KPN	pCR	Approval	Yes	YesVodafone: battery efficient bit is too narrow.Happy to say "battery effcient" without the i.e. Ericsson: the operator would provide the keys here? It's strange. ORANGE: puzzled by some of the terms, like "simple UE". We are not saying anywhere that AKMA shall support GBA as it is implied here. Huawei: worried about the operator eavesdropping the communications.It was agreed to remove the threat. Ericsson: the point of AKMA is not to protect the UE from the operator. Vodafone: consider lawful interception issues here, LI needs to check this.	revised	No	S3‑183736
		S3‑183736	New Key Issue: Generic battery efficient end-to-end security	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑183544
		S3‑183561	New KI: Key Lifetimes	Ericsson India Private Limited	pCR	Approval	Yes	YesVodafone: what happens when the max lifetime is reached? We need requirements for that too. Nokia: why are we negotiating the keys again in the security threat? Ericsson replied that it is similar to what happens in GBA. Gemalto confirmed that this case was widely studied in the GBA work. This had to be taken offline. The max lifetime was the only non controversial issue.	revised	No	S3‑183737
		S3‑183737	New KI: Key Lifetimes	Ericsson India Private Limited	pCR	Approval	Yes	Yes	approved	No		S3‑183561
		S3‑183563	New KI: API for AKMA keys in UE	Ericsson India Private Limited	pCR	Approval	Yes	YesVodafone, Qualcomm: we don’t standardize this. It was decided to add an editor's note in order to clarify Qualcomm's concerns.	revised	No	S3‑183746
		S3‑183746	New KI: API for AKMA keys in UE	Ericsson India Private Limited	pCR	Approval	Yes	Yes	approved	No		S3‑183563
		S3‑183631	Key Issue on secure communication between ME and UICC	Alibaba (China) group., Ltd., China Mobile	pCR	Approval	Yes	YesORANGE: interface between ME and UICC is in the scope of ETSI SCP, not ours. There was not much support for this contribution, so it was finally noted.	noted	No		S3‑183306
		S3‑183307	AKMA candidate solution for non-3GPP credential download	Alibaba (China) group., Ltd., China Mobile	pCR	Approval	Yes	YesRelated to the previous one. Vodafone: totally out of scope.	noted	No
		S3‑183420	Solution for bootstrapping authentication of AKMA	Huawei, Hisilicon	pCR	Approval	Yes	YesNEC: where do the keys go? What are they bound to? We need a key hierarchy as well. It was agreed to add an editor's note to address this. These and other comments were addressed in the revision.	revised	No	S3‑183747
		S3‑183747	Solution for bootstrapping authentication of AKMA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183420
		S3‑183511	Discussion and pCR of Candidate Solution: Transport independent procedure using existing protocols	China Mobile; Alibaba (China) Group., Ltd.	pCR		Yes	YesFigure changed to grey scale since the colors didn’t mean anything. It was also agreed to add an Editor's note on architecture as proposed by Nokia. Split into solutions as well.	revised	No	S3‑183748
		S3‑183748	Discussion and pCR of Candidate Solution: Transport independent procedure using existing protocols	China Mobile; Alibaba (China) Group., Ltd.	pCR	-	Yes	Yes	approved	No		S3‑183511
		S3‑183513	Discussion and pCR of candidate solution: UE implementation schemes in achieving AKMA procedures	China Mobile; Alibaba (China) Group., Ltd.	pCR		Yes	YesVodafone: colors mean nothing, make the figures editable, also split into different solutions. KPN: what is CP and AT? Please add their definitions.	revised	No	S3‑183749
		S3‑183749	Discussion and pCR of candidate solution: UE implementation schemes in achieving AKMA procedures	China Mobile; Alibaba (China) Group., Ltd.	pCR	-	Yes	Yes	approved	No		S3‑183513
		S3‑183562	New solution: Access independent architecture solution for AKMA	Ericsson India Private Limited	pCR	Approval	Yes	Yes	revised	No	S3‑183750
		S3‑183750	New solution: Access independent architecture solution for AKMA	Ericsson India Private Limited	pCR	Approval	Yes	Yes	approved	No		S3‑183562
		S3‑183564	New solution: Stand-alone architecture solution for AKMA	Ericsson India Private Limited	pCR	Approval	Yes	Yes	revised	No	S3‑183751
		S3‑183751	New solution: Stand-alone architecture solution for AKMA	Ericsson India Private Limited	pCR	Approval	Yes	Yes	approved	No		S3‑183564
		S3‑183306	Key Issue on secure communication between UE and application server	Alibaba (China) group., Ltd., China Mobile	pCR	Approval	Yes	Yes	revised	No	S3‑183631
		S3‑183735	Draft TR 33.835	China Mobile	draft TR	Approval	Yes	Yes	approved	No
8.6	Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)	S3‑183539	Key Issue #4 – Signalling overload due to Malicious Applications on the UE	KPN	pCR	Approval	Yes	YesEricsson: the need for human intervention is something we usually don’t mention in our specs. This was removed.	merged	No	S3‑183772
		S3‑183460	Improvement for key issue on the signalling overload due to malicious applications on the UE	Huawei, HiSilicon	pCR	Approval	Yes	YesVodafone: no difference here between malicious operation and poor programming? T-Mobile: misbehaving should not be in the network to start with. KPN: second requirement should be a temporarily removal, not permanent (too strong). T-Mobile: isolating instead of removing from the network.	revised	No	S3‑183772
		S3‑183772	Improvement for key issue on the signalling overload due to malicious applications on the UE	Huawei, HiSilicon,KPN	pCR	Approval	Yes	Yes	approved	No		S3‑183460
		S3‑183331	Add security requirements to key issue#6	Nokia	pCR	Approval	Yes	YesQualcomm: these are not requirements, they are solutions. KPN supported these requirements. Qualcomm: the application is in another level, it is not possible to evaluate it drom the network point of view. ORANGE agreed.	noted	No
		S3‑183541	New KI: Protection of interface used by NIDD procedures	Ericsson LM	pCR	Approval	Yes	Yes	revised	No	S3‑183773
		S3‑183773	New KI: Protection of interface used by NIDD procedures	Ericsson LM	pCR	Approval	Yes	Yes	approved	No		S3‑183541
		S3‑183538	New Key Issue: Remote (de)provisioning of credentials	KPN	pCR	Approval	Yes	YesORANGE: we decided not to deal with this topic anymore, since SA2 has not concluded on this issue.	noted	No
		S3‑183415	Key Issue on Classification of IoT UE based on Attack Method	Huawei, Hisilicon	pCR	Approval	Yes	YesNEC wanted to rewiord the requirements. Nokia: remove the last requirement. Colin (BT): don’t duplicate the work that other SDOs are doing. E.g. TC CYBER, GSMA. ORANGE supported this. Qualcomm: this is out of scope of 3GPP.	noted	No
		S3‑183332	Adding Key issue for Connectionless service security	Nokia	pCR	Approval	Yes	YesEricsson: some requirements already covered in other key issues, others are too solution specific. ORANGE: don’t refer to solution 29 especifically.Threats are too specific too.	revised	No	S3‑183775
		S3‑183775	Adding Key issue for Connectionless service security	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑183332
		S3‑183545	New KI: Privacy protection of the NIDD API between UPF/NEF and AF	Ericsson LM	pCR	Approval	Yes	YesNEC: reword the security threat. It had to be taken offline to address some concerns from ORANGE. Huawei: remove UPF from the title.	noted	No
		S3‑183776	New KI: Privacy protection of the NIDD API between UPF/NEF and AF	Ericsson LM	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183338	Solution proposal for FS_CIoT_sec_5G	NEC Corporation	pCR	Approval	Yes	YesEricsson: there is an overhead in the network side. It is not clear whether this is needed so it should be captured in an editor's note. Huawei: remove the evaluation and bring one back next meeting. BT: losing security in favour of performance here. Add condition on security policy here.	revised	No	S3‑183777
		S3‑183777	Solution proposal for FS_CIoT_sec_5G	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑183338
		S3‑183537	Security solution for MO SMS in initial NAS message - handling AMF re-allocation	Ericsson LM	pCR	Approval	Yes	Yes	revised	No	S3‑183778
		S3‑183778	Security solution for MO SMS in initial NAS message - handling AMF re-allocation	Ericsson LM	pCR	Approval	Yes	Yes	approved	No		S3‑183537
		S3‑183535	Security solution for small data sent with EDT in RRC Resume Request for E-UTRA connected to 5GC	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑183779
		S3‑183779	Security solution for small data sent with EDT in RRC Resume Request for E-UTRA connected to 5GC	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183535
		S3‑183536	Security solution for small data included in initial NAS to handle AMF reallocation	Ericsson LM	pCR	Approval	Yes	Yes	revised	No	S3‑183780
		S3‑183780	Security solution for small data included in initial NAS to handle AMF reallocation	Ericsson LM	pCR	Approval	Yes	Yes	approved	No		S3‑183536
		S3‑183542	New Solution for Key Issue #4: Use of UE Configuration Update	KPN	pCR	Approval	Yes	YesNokia: vague solution. Huawei: this detection mechanism is out of scope of 3GPP. ORANGE: it is written in the evaluation that it is out of scope of 3GPP. Several editor's notes were agreed to be added in the revision.	revised	No	S3‑183781
		S3‑183781	New Solution for Key Issue #4: Use of UE Configuration Update	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑183542
		S3‑183346	Solution for protecting gNB from RRC re-establishment DDoS attack	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: thresholds are in scope of 3GPP? This is implementation specific and should not go through in normative work.	revised	No	S3‑183782
		S3‑183782	Solution for protecting gNB from RRC re-establishment DDoS attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183346
		S3‑183543	New solution for protection of interface used by NIDD procedures	Ericsson LM	pCR	Approval	Yes	Yes	revised	No	S3‑183783
		S3‑183783	New solution for protection of interface used by NIDD procedures	Ericsson LM	pCR	Approval	Yes	Yes	approved	No		S3‑183543
		S3‑183416	Capture IoT Security Related Requirement in other 3GPP Document	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: the specs can change, and this is hard to maintain. Useful for a discussion document, but not for the TR.	noted	No
		S3‑183352	Solution for protecting gNB from RRC re-establishment DDoS attack	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183774	Draft TR 33.861	Ericsson	draft TR	Approval	Yes	Yes	approved	No
8.7	Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)	S3‑183275	Response to 3GPP SA2 liaison S2-189038 on ‘general status of work’	BBF	LS in		Yes	Yes	postponed	No
		S3‑183280	Reply LS on security requirements for RRC connection release	R2-1816053	LS in		Yes	Yes	noted	No
		S3‑183282	Reply LS on devices behind 5G-RG accessing the 5GC	S2-1810989	LS in		Yes	Yes	noted	No
		S3‑183288	Reply LS on 5WWC status of work and interim agreements	S2-1811575	LS in		Yes	YesPotential response when replying to 275.	noted	No
		S3‑183517	Update of Key Issue #2: FN-RG authentication and authorization	Ericsson	pCR	Approval	Yes	YesNEC: why do we study the authentication and authorization of FN-RG if this is outside the scope of 3GPP? It's BBF stuff. Ericsson: BBF will ask us questions about this. We can have something in our TR or we can communicate with them via LS. Huawei: this is in scope of SA2. It was agreed to send an LS to SA2 to consult them on this topic. The document was finally noted.	noted	No
		S3‑183518	New solution for Key Issue #2: FN-RG authentication and authorization	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑183519	New KI: Authentication of 5G capable UE behind a RG	Ericsson	pCR	Approval	Yes	YesORANGE didn’t find this necessary.This is not different from an WiFi access point.NEC supported this. Nokia and Deutsche Telekom preferred to have this key issue added. ORANGE: what's the added value for having another mechanism for non 3GPP access? It was agreed to add a note where it was stressed that any other authentication rather than 5GC authentication would need a strong reason.	revised	No	S3‑183786
		S3‑183786	New KI: Authentication of 5G capable UE behind a RG	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183519
		S3‑183521	New Solution: 5GC-capable UEs behind 5G-RG/FN-RG using N3GPP-access solutions	Ericsson	pCR	Approval	Yes	YesHuawei: postponed the evaluation part until SA2 has finished with this. Ericsson: we cannot wait for SA2, it would be too late.	revised	No	S3‑183791
		S3‑183791	New Solution: 5GC-capable UEs behind 5G-RG/FN-RG using N3GPP-access solutions	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183521
		S3‑183520	New KI: User plane data handling for 5G capable UE behind a RG	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑183787
		S3‑183787	New KI: User plane data handling for 5G capable UE behind a RG	Ericsson,NEC	pCR	Approval	Yes	Yes	approved	No		S3‑183520
		S3‑183534	Key Issue on Access Independent Security for 5WWC	NEC Corporation	pCR	Agreement	Yes	Yes	revised	No	S3‑183788
		S3‑183788	Key Issue on Access Independent Security for 5WWC	NEC Corporation	pCR	Agreement	Yes	Yes	approved	No		S3‑183534
		S3‑183376	Key Issue: Requirement of Trust mechanism of Non 3GPP UEs	China Telecom Corporation Ltd.	pCR	Approval	Yes	YesORANGE: what is a non-5GC capable UE? Nokia didn’t want to agree with this key issue either. Ericsson: there is no scenario in SA2 that covers this.	noted	No
		S3‑183423	Secure storage of UICC	Huawei, Hisilicon	pCR	Approval	Yes	YesNEC: there is nothing new here, there are solutions for this. There was no support for this document.	noted	No
		S3‑183424	secure boot of 5G-RG	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑183425	Prevent from 5G-RG cheating	Huawei, Hisilicon	pCR	Approval	Yes	YesWhat's the difference in this context between a 5G-RG and an UE? I could use my phone as a WiFi hotspot. Juniper and Nokia supported Ericsson. Huawei: this RG is more exposed than your phone.	noted	No
		S3‑183426	solution on 5G-RG authentication	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑183427	Editoral Change of Solution 1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑183784	Draft TR 33.807	Huawei	draft TR	Approval	Yes	Yes	approved	No
		S3‑183785	LS on FN-RG authentication and related questions	Ericsson	LS out	Approval	Yes	Yes	approved	No
8.8	Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)	S3‑183567	Update of PARLOS solution #1	Motorola Mobility, Lenovo	pCR	Approval	Yes	YesEricsson didn’t agree with removing the editor's note and they proposed to reformulate it. Sprint: these could be unauthenticated devices without an USIM. Things can be handled by an ME without an USIM. The term UE was to be replaced by ME. Sprint added that false base stations atttacks are possible due to the current FCC regulations. The document was revised to address these comments.	revised	No	S3‑183725
		S3‑183725	Update of PARLOS solution #1	Motorola Mobility, Lenovo	pCR	Approval	Yes	Yes	approved	No		S3‑183567
		S3‑183630	P-CR describing current manual roaming in US	Sprint Corporation	pCR	Agreement	Yes	YesVodafone: some other countries different from US have this issue as well. What happens if they try to attach as an VF UK customer and there is no roaming agreement with VF UK? Are you switching to the manual roaming? Sprint replied affirmatively, and Vodafone didn't find it acceptable. This enabling customers to break their agreements. An editor's note on this issue was added. MCC commented that mentioning companies like American Roaming Networks could lead to copyright issues that should be avoided. A reference to a study or paper where the data was found would be more useful. Mirko (MCC) also suggested to add a reference to the SA1 study document. There were several editorial issues that were taken into account as well in the revision.	revised	No	S3‑183727
		S3‑183727	P-CR describing current manual roaming in US	Sprint Corporation	pCR	Agreement	Yes	Yes	approved	No		S3‑183630
		S3‑183726	Draft TR 33.815	Sprint	draft TR	Approval	Yes	Yes	approved	No
8.9	Study on 5G security enhancement against false base stations	S3‑183300	skeleton of TR 33.809-Study on 5G Security Enhancement against False Base Station	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	Yes	approved	No
		S3‑183568	Clause #4 for the upcoming TR on FS_5GFBS	Ericsson	pCR	Approval	Yes	YesNTT-Docomo: Some parts should go to the Introduction of the draft report.	revised	No	S3‑183800
		S3‑183800	Clause #4 for the upcoming TR on FS_5GFBS	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183568
		S3‑183296	Discussion of Potential threats caused by false base station	Apple Computer Trading Co. Ltd	discussion	Agreement	Yes	Yes	noted	No
		S3‑183297	Key issue of authenticating gNB on broadcast and unicast message	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	YesORANGE: requirement looks too solution specific. Ericsson: when you mention PWS you should refer to what SA3 has done on this topic. This overlaps with 580 and 581.	availablem	No	S3‑183801
		S3‑183330	Key issue false base station detection and isolation	Nokia	pCR	Approval	Yes	YesBT: false base stations are already isolated. The requirement was removed.	revised	No	S3‑183802
		S3‑183802	Key issue false base station detection and isolation	Nokia,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183330
		S3‑183347	Key Issue on spoofing system informations	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑183801
		S3‑183349	Key Issue on Spoofing UE paging messages	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑183551	Key issue on AS security during RRC Idle mode	Samsung	pCR	Approval	Yes	Yes	merged	No	S3‑183801
		S3‑183570	Enhancing detection - new KI for the upcoming TR on FS_5GFBS	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑183802
		S3‑183580	SI integrity - new KI for the upcoming TR on FS_5GFB	Ericsson	pCR	Approval	Yes	YesThe Chair commented that a catalog of common possible attacks on the base stations should be avoided in this document. It was enough just to refer to other documents that describe them.	revised	No	S3‑183801
		S3‑183801	SI integrity - new KI for the upcoming TR on FS_5GFB	Ericsson,Samsung,Apple,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑183580
		S3‑183579	SI replay - new KI for the upcoming TR on FS_5GFB	Ericsson	pCR	Approval	Yes	YesThe requirement was removed. MCC commented that it was not possible to refer to TR 33.899 since the draft had been withdrawn.	merged	No	S3‑183801
		S3‑183581	Rogue REJECTS - new KI for the upcoming TR on FS_5GFB	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑183803
		S3‑183569	SON security - new KI for the upcoming TR on FS_5GFBS	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑183804
		S3‑183804	SON security - new KI for the upcoming TR on FS_5GFBS	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183569
		S3‑183470	Key issue on Authentication relay attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑183805
		S3‑183805	Key issue on Authentication relay attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183470
		S3‑183299	Key issue of security protection on the unicast message from the UE before security activation	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	YesIt was agreed to remove the requirements. China Mobile commented that this was not a key issue for the fake base station.	revised	No	S3‑183803
		S3‑183803	Key issue of security protection on the unicast message from the UE before security activation	Apple Computer Trading Co. Ltd,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183299
		S3‑183571	Enhancing untraceability - new KI for the upcoming TR on FS_5GFB	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑183348	Key Issue on HO failure caused by fake base station	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑183804
		S3‑183572	Privacy visibility - new KI for the upcoming TR on FS_5GFB	Ericsson	pCR	Approval	Yes	YesBT,Nokia and Apple objected to this. ORANGE supported this, since the user could react with some action if he receives the data that there is a false base station,	noted	No
		S3‑183576	Service visibility - new KI for the upcoming TR on FS_5GFB	Ericsson	pCR	Approval	Yes	YesApple objected to this.	noted	No
		S3‑183582	Radio jamming - placeholder-only KI for the upcoming TR on FS_5GFB	Ericsson	pCR	Approval	Yes	YesDeutsche Telekom didn’t see the need to include this key issue.	revised	No	S3‑183806
		S3‑183806	Radio jamming - placeholder-only KI for the upcoming TR on FS_5GFB	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183582
		S3‑183301	Key issue of security overhead and complexity	Apple Computer Trading Co. Ltd	pCR	Approval	Yes	YesORANGE: this key issue is based on TR 33.899, which was withdrawn, and I don’t agree with this. Deutsche Telekom and Huawei supported this.	noted	No
		S3‑183350	Protecting UE from connnecting to fake basestation during HO	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: too early for this evaluation, remove it. Ericsson, Qualcomm: too early for the whole document.	noted	No
		S3‑183351	Aoviding unnecessary HO caused by fake base station	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑183552	Solution for AS security during RRC Idle mode	Samsung	pCR	Approval	Yes	YesORANGE: when we bring these solutions from TR 33.899, shouldn’t we use their evaluations as well? We don’t need to re-evaluate. There was no requirement for this solution, so it was noted.	noted	No
		S3‑183353	Key Issue on spoofing system informations	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183354	Key Issue on HO failure caused by fake base station	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183355	Key Issue on Spoofing UE paging messages	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183357	Solution for pretecting UE from HO to fake base station	Huawei, Hisilicon	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑183358	Protecting UE from connnecting to fake basestation during HO	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183359	Aoviding unnecessary HO caused by fake base station	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183365	Solution for pretecting UE from HO to fake base station	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183799	Draft TR 33.809	Apple	draft TR	Approval	Yes	Yes	approved	No
8.10	Study of KDF negotiation for 5G System Security	S3‑183414	Scope for TR 33.808 KDF negotiation	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑183508	Key issue on Need for UE capability based KDF negotiation in 5GS	NEC Corporation	pCR	Approval	Yes	YesEricsson and ORANGE objected to the key issue. ORANGE was not comfortable with having the UE deciding the KDF. Ericsson: we study a need and this key issue assumes there is a need. Docomo, ORANGE and Qualcomm supported that the need should be studied first. Huawei: there are companies who are convinced that this is not needed, so we could just finish with a "this is not needed". It was agreed to have the following process: - Justify the need. - Study the solution.	noted	No
		S3‑183412	Key Issue on KDF negotiation between UE and AMF	Huawei, Hisilicon	pCR	Approval	Yes	YesDocomo: the security threats are not security related.	revised	No	S3‑183796
		S3‑183796	Key Issue on KDF negotiation between UE and AMF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183412
		S3‑183512	Key Issue on Need for Bidding down protection	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑183413	Key Issue on Avoiding Bidding down attack on KDF negotiation	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑183510	Key Issue on Need for Flexible KDF negotiation	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑183792	Draft TR 33.808	Huawei	draft TR	Approval	Yes	Yes	approved	No
8.11	Study on Security aspects of Enhancement of Network Slicing	S3‑183333	Skeleton proposal for TR for Enhanced Network Slicing	Nokia	pCR	Approval	Yes	Yes	approved	No
		S3‑183334	eNet Slice TR content for scope	Nokia	pCR	Approval	Yes	Yes	approved	No
		S3‑183335	pCR to TR 33.813 content for references	Nokia	pCR	Approval	Yes	Yes	approved	No
		S3‑183336	pCR to TR33.813 content for definitions and abbreviations	Nokia	pCR	Approval	Yes	Yes	noted	No
		S3‑183337	pCR to TR 33.813 Adding key issue for Slice specific authentication	Nokia	pCR	Approval	Yes	YesBT: you can have a slice without secondary authentication. Ericsson: key issue details should refer to what SA2 is doing, we cannot ignore them.	revised	No	S3‑183808
		S3‑183808	pCR to TR 33.813 Adding key issue for Slice specific authentication	Nokia,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑183337
		S3‑183463	New KI on slice authentication	Huawei, HiSilicon	pCR	Approval	Yes	Yes	merged	No	S3‑183808
		S3‑183531	A key issue: Security and privacy aspects related to Network Slice specific access authentication and authorization	China Mobile	pCR		Yes	Yes	approved	No
		S3‑183339	Key issue proposal for security aspects of enhanced support of network slices	NEC Corporation	pCR	Approval	Yes	YesHuawei: the two requirements address different key issues. Remove the second requirements. Nokia: what's UE protection? What's being protected? Eventually the requirements were removed. Ericsson: how is this done if the UE is always connected to one AMF? Huawei: there is a study where the UE is connected to multipleAMFs. ORANGE: slices with different security requirements are being mentioned, what does it mean? What are the different requirements you refer to?	noted	No
		S3‑183464	New KI on slice isolation	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: in TR 33.899 we discussed this extensively, what's new in here?	noted	No
		S3‑183583	New key issue on key separation between Network Slices	Ericsson	pCR	Approval	Yes	YesThe requirement was decided to be split.	revised	No	S3‑183809
		S3‑183809	New key issue on key separation between Network Slices	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183583
		S3‑183461	New KI on security features for NSaaS	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: the study is on the SA2 solutions not on SA5.	revised	No	S3‑183810
		S3‑183810	New KI on security features for NSaaS	Huawei, HiSilicon,China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑183461
		S3‑183530	A key issue on Slice-specific security features in NSaaS	China Mobile	pCR		Yes	YesORANGE: not in the scope of the study, not SA2 work.	merged	No	S3‑183810
		S3‑183462	New KI on monitored security features	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE didn't agree with the key issue since a lot of this is happening outside the slice.	noted	No
		S3‑183465	New KI on NSSAI confidentiality	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: not part of the objectives or of the SA2 work. ORANGE: confidential from where to where? Huawei replied that Over The Air.ORANGE said that this is already cover in Rel-15 work. ORANGE: this depends on the Nokia solution that is being discussed in SA2. Intel supported this contribution.	noted	No
		S3‑183807	Draft TR 33.813	Nokia	draft TR	discussion	No	Yes	approved	No
8.12	Study on Security of the enhancement to the 5GC location services	S3‑183433	Draft skeleton for TR 33.814	CATT	pCR	Approval	Yes	YesIt was noted that the template used was wrong, reusing one from another spec.	revised	No	S3‑183811
		S3‑183811	Draft skeleton for TR 33.814	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑183433
		S3‑183434	pCR to TR33.814 - Scope	CATT	pCR	Approval	Yes	Yes	revised	No	S3‑183744
		S3‑183744	pCR to TR33.814 - Scope	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑183434
		S3‑183371	Scope of FS_eLCS_Sec	China Unicom	pCR		Yes	Yes	merged	No	S3‑183744
		S3‑183372	key issue on protect distribution positioning assistance data	China Unicom	pCR		Yes	Yes	merged	No	S3‑183770
		S3‑183403	Key issue for encryption protection of location data	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑183770
		S3‑183770	Key issue for encryption protection of location data	Huawei, Hisilicon	pCR	Approval	No	Yes	noted	No		S3‑183403
		S3‑183404	Key issue for integrity protection of location and assistance data	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑183771
		S3‑183771	Key issue for integrity protection of location and assistance data	Huawei, Hisilicon	pCR	Approval	No	Yes	noted	No		S3‑183404
		S3‑183435	pCR to TR33.814 - Key issue for ciphering key delivery	CATT	pCR	Approval	Yes	YesNokia: Broadcasting is a LTE procedure, not defined for 5G yet.	noted	No
		S3‑183366	Key issue on security protection of Location service exposure for TR33.814	CATR, China Unicom, CATT	pCR		Yes	Yes	merged	No	S3‑183771
		S3‑183526	WLAN positioning - new KI for the upcoming TR on FS_eLCS_Sec	Ericsson	pCR	Approval	Yes	YesNextNav: Combine WLAN, TBS, positioning into one. NEC preferred to have Bluetooth, WLAN separate because of their security aspects. NextNav commented that there were many positioning methods and was wondering why these three were considered. The Chair commented that input was welcome to change this. NextNav insisted that they didn’t agree with being as specific as this, focusing on WLAN instead of going generic.	noted	No
		S3‑183813	WLAN positioning - new KI for the upcoming TR on FS_eLCS_Sec	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑183527	Bluetooth positioning - new KI for the upcoming TR on FS_eLCS_Sec	Ericsson	pCR	Approval	Yes	YesMCC commented that Bluetooth was a trademark, but NextNav commented that in RAN2 a trademark sentence could be added to the cover page of the specification.	approved	No
		S3‑183528	TBS positioning - new KI for the upcoming TR on FS_eLCS_Sec	Ericsson	pCR	Approval	Yes	YesNextNav: make all this generic.ESA agreed. The Chair commented that WLAN/Bluetooth had a specific network type. For this document, it could be made more generic. NextNav: what are the specific privaty concerns for these cases? GPS/satellite, Bluetooth,..can be generalised. Ericsson: privacy issues with the connecting beacons. NEC: collected data on these cases are about people. GPS collected data is different. Ericsson: we cannot commit to generalise all this now. It can be done with a future contribution. NextNav: there are a lot of flavours of TBS. Which one is it referred here? Ericsson: add an editor's note on the need of studying this to generalise it.	revised	No	S3‑183814
		S3‑183814	TBS positioning - new KI for the upcoming TR on FS_eLCS_Sec	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183528
		S3‑183812	Draft TR 33.814	CATT	draft TR	discussion	Yes	Yes	approved	No
8.13	Study on security for 5G URLLC	S3‑183453	Scope for TR33.825 on URLLC security	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑183815
		S3‑183815	Scope for TR33.825 on URLLC security	Huawei, HiSilicon	pCR	Approval	Yes	YesThe scope was reworded to make it more about the document and not about the study.	approved	No		S3‑183453
		S3‑183340	Key issue proposal for security of URLLC for 5GS	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑183817
		S3‑183817	Key issue proposal for security of URLLC for 5GS	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑183340
		S3‑183455	Key issue security for redundant transmissions	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑183818
		S3‑183818	Key issue security for redundant transmissions	Huawei, HiSilicon,Ericsson,LG	pCR	Approval	Yes	Yes	approved	No		S3‑183455
		S3‑183377	URLLC pCR - new key issue on security of redundant transmission in user plane	LG Electronics	pCR	Approval	Yes	YesHuawei: the weaker part is not true.	merged	No	S3‑183818
		S3‑183573	KI for security keys for redundant data	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑183818
		S3‑183456	Key issue security policy for URLLC service	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson:Fourth requirement should go away. NEC: first requirement is very weak. NCSC: change the name of the key issue. An editor's note was agreed regarding this.	revised	No	S3‑183819
		S3‑183819	Key issue security policy for URLLC service	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183456
		S3‑183574	KI for UP security policy handling for redundant data	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑183454	Key issue authentication adaptions	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE; authentication framework that we have is not adapted to URLLC services. The key issue is very weak. NEC supported this.	noted	No
		S3‑183457	Key issue security aspect of low latency handover procedures	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑183820
		S3‑183820	Key issue security aspect of low latency handover procedures	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑183457
		S3‑183577	KI for retaining AS security key	Ericsson	pCR	Approval	Yes	YesQualcomm: you are assuming that there are no threats. Remove the "not applicable". Same as security requirements.	revised	No	S3‑183821
		S3‑183821	KI for retaining AS security key	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183577
		S3‑183458	Key issue QoS monitoring protection	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑183459	Key issue considerations of security algorithms for URLLC	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑183575	Security solution for handling UP security policy for redundant data	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑183822
		S3‑183822	Security solution for handling UP security policy for redundant data	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183575
		S3‑183578	Solution for flexibility to retain or to change AS security keys	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑183823
		S3‑183823	Solution for flexibility to retain or to change AS security keys	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑183578
		S3‑183816	TR 33.825	Huawei	draft TR	Approval	Yes	Yes	approved	No
8.14	Study on SECAM and SCAS for 3GPP virtualized network products	S3‑183484	Discussing ToE of security assurance for 3GPP virtualized network products	China Mobile,CATR,ZTE	discussion		Yes	Yes	noted	No
		S3‑183485	Discussing gaps from applying current SECAM to 3GPP virtualized network products	China Mobile, CATR, ZTE	discussion		Yes	Yes	noted	No
		S3‑183506	Skeleton of TR 33.818	China Mobile, CATR	draft TR		Yes	Yes	approved	No
		S3‑183509	Scope of TR 33.818	China Mobile, CATR	pCR		Yes	Yes	revised	No	S3‑183824
		S3‑183824	Scope of TR 33.818	China Mobile, CATR	pCR	-	Yes	Yes	approved	No		S3‑183509
		S3‑183825	Draft TR 33.818	China Mobile	draft TR	Approval	Yes	Yes	approved	No
8.15	Study on Security for 5GS Enhanced support of Vertical and LAN Services	S3‑183311	VERTICAL_LAN_SEC skeleton	Nokia Germany	draft TR		Yes	Yes	approved	No
		S3‑183488	VERTICAL study - Background to and key issues for VERTICAL_LAN_SEC study	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183487	VERTICAL study - Scope	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE asked to be minuted: we won't double the work from other Study Items. Ericsson: don’t mention WID codes.	revised	No	S3‑183827
		S3‑183827	VERTICAL study - Scope	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑183487
		S3‑183417	Key Issue on Authentication of a UE for Non-public network	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: this confuses the concepts of public and non-public networks.	revised	No	S3‑183831
		S3‑183831	Key Issue on Authentication of a UE for Non-public network	Huawei, Hisilicon,Nokia	pCR	Approval	No	Yes	noted	No		S3‑183417
		S3‑183490	VERTICAL study - KI1 on primary authentication using EAP	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE: what about 5G-AKA' and so on? Nokia: the sensor may not have an UICC. ORANGE asked how the credentials would be protected in this case. We have done this authentication framework already. Gemalto, Vodafone, Telecom Italia, BT supported ORANGE. Nokia: we are doing what SA1 mandated. ORANGE: we cover the requirement in TS 33.501. Sony,NEC supported having this key issue for analysis. Ericsson as well. There were strong issues for and against having this key issue. ORANGE: in TS 33.501 it's an informative annex on the EAP framework, to be able to use different methods. I don’t want to have this as normative. Qualcomm was in favour of the key issue.	merged	No	S3‑183831
		S3‑183491	VERTICAL study - KI2 on primary authentication in NPN using Rel-15 authentication methods	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑183831
		S3‑183492	VERTICAL study - KI3 on authentication framework for NPN	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑183831
		S3‑183312	New Key Issue: Authentication and Authorization for Interworking, Roaming between NPN and PLMN	InterDigital Europe. Ltd.	pCR	Approval	Yes	Yes	revised	No	S3‑183828
		S3‑183828	New Key Issue: Authentication and Authorization for Interworking, Roaming between NPN and PLMN	InterDigital Europe. Ltd.,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑183312
		S3‑183493	VERTICAL study - KI4 on Security implications for accessing PLMN services via NPN and vice versa	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑183828
		S3‑183514	Key issue for authentication and authorization of 5GLAN UE in 5GLAN group communication	NEC Corporation	pCR	Approval	Yes	YesEricsson: remove requirements and let's wait for SA2's conclusions.	revised	No	S3‑183829
		S3‑183829	Key issue for authentication and authorization of 5GLAN UE in 5GLAN group communication	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑183514
		S3‑183529	New key issue for key refreshment in 5GLAN group communication	NEC Corporation	pCR	Approval	Yes	YesEricsson: key issues need to be rewritten. Not clear at all what the security aspects are.	noted	No
		S3‑183532	New key issue for securing the communication between 5GLAN UE and GMF	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑183418	Key Issue on Protection of interfaces that 5GS interact with TSN	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑183494	VERTICAL study - KI5 on verification of the integrity of a message	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE: the requirement is unclear. Is it user plane, control plane? Vodafone supported ORANGE.	noted	No
		S3‑183495	VERTICAL study - KI6 on non-repudiation of the sender of a message	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑183489	VERTICAL study - High-level overview of security aspects	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesVodafone and ORANGE objected to the content. CRs should not be referenced, it's already in the specification.	noted	No
		S3‑183496	VERTICAL study - definitions and abbreviations	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE: already used or found somewhere else.Write the definitions once they are used in the document. Nokia: some of them are used already in approved pCRs for this meeting. Those definitions that were not used were removed.	noted	No
		S3‑183497	VERTICAL study - reference	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	YesORANGE: don’t refer to a CR. The Chair commented that references should be written as they are used. Any pCR which uses a reference should include the change in the pCR and not in a separate document.	noted	No
		S3‑183798	Proposal for key issue structure	Nokia	pCR	Approval	Yes	YesNokia: this is a skeleton structure proposal. Vodafone: there may be more key issue areas. Nokia replied that these are the ones used by SA2. Gemalto wasn't sure about this proposal, since there may be key issues outside these areas and it may be hard to figure out where to put certain key issues.	approved	No
		S3‑183826	Draft TR 33.819	Nokia	draft TR	Approval	No	Yes	approved	No
8.16	Other study areas	S3‑183289	LS on separate HSS and UDM and security credentials storage	S2-1811603	LS in		Yes	Yes	replied to	No
		S3‑183327	Discussion on LS (S3-183289) on separate HSS and UDM credential storage	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑183599	discussion on security credential storage	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑183600	DRAFT Reply LS on Separate HSS and UDM and security credentials storage	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑183640	LS-Reply proposal - Commenting on S3-183599, S3-183600, S3-183327	Nokia, Nokia Shanghai Bell	other	Approval	Yes	Yes	noted	No
		S3‑183834	Reply LS on Separate HSS and UDM and security credentials storage	Nokia	LS out	Approval	Yes	Yes	approved	No
8.17	New study item proposals	S3‑183356	IoT Group Authentication	Huawei, Hisilicon	SID new	Approval	Yes	Yes	revised	No	S3‑183691
		S3‑183691	IoT Group Authentication	Huawei, Hisilicon	SID new	Approval	Yes	YesDocomo: what is a group and what is group authentication? Do we want to go for discussions like group membership? This would mean a huge amount of work. ORANGE: why refer to the SA1 TR that has been terminated and whose work has gone into a TS? Reword the justification and objectives. Vodafone: authentication at what level? This is not clear.Huawei replied that they meant telecom primary authentication. ORANGE had a problem with this. Alex (BT): I'd like the study how the serving network is using the authentication for a group. Huawei: the key issue of the network knowing which device is authenticated as been mentioned already. Huawei: a massive amount of devices trying to authenticate into the network is part of what the study intends to go for. ORANGE: let's ask SA1 what they expect us to do with an LS. The LS was agreed. In the end there was no response from SA1 and this was noted.	noted	No		S3‑183356
		S3‑183364	IoT Group Authentication	Huawei, Hisilicon	SID new	Approval	No	Yes	withdrawn	Yes
		S3‑183378	Discussion about a new SI for 5G V2X security	LG Electronics	discussion	Discussion	Yes	YesQualcomm commented that it made sense having a study item for V2X in Rel-16 in SA3. Nokia was concerned about opening the doors for new use cases and key issues. LG replied that they would stick to SA2's work.	noted	No
		S3‑183436	New SID on User Plane Integrity Protection	VODAFONE Group Plc	SID new	Agreement	Yes	YesDT: pure 5G enhancements are very welcome, we support this. NEC proposed to reword the objectives to explore other solutions, replacing "at" with "up to the" in a couple of sentences. Qualcomm supported this study item. AT&T, Apple, ORANGE, NEC, NCSC and several others were added as well.	revised	No	S3‑183718
		S3‑183718	New SID on User Plane Integrity Protection	VODAFONE Group Plc	SID new	Agreement	Yes	Yes	agreed	No		S3‑183436
		S3‑183471	Study on mitigation of the charging fraud attack	Huawei, Hisilicon	SID new	Approval	Yes	YesDocomo: the problem exists already in LTE. Should we study this for LTE as well? Huawei didn’t have a problem with this. Vodafone: overlapping with GSMA work. They have a group of fraud. Huawei: GSMA will send an LS to SA3 about this issue. They discussed this last week. Vodafone: let's wait for the LS then, or send them an LS about this study item to trigger their response and opinion. Ericsson: does this have to be Rel-16? Is it urgent? It was agreed to attach the Study to the LS to GSMA and note it for this meeting since SA3 needed their response before continuing.	revised	No	S3‑183719
		S3‑183719	Study on mitigation of the charging fraud attack	Huawei, Hisilicon	SID new	Approval	Yes	YesRevised to include LTE in the scope.	noted	No		S3‑183471
		S3‑183483	enhance the security of the authentication procedure	China Mobile	discussion		Yes	Yes	noted	No
		S3‑183486	Security Impacts of Virtualisation	BT plc	SID new	Approval	Yes	YesBT: No overlaps with the hardening requirements in SCAS. It was also agreed to make it internal and then if required, convert it to external. Colin (BT) pointed out hat there might be overlap with SA5 work. Alex replied that they would be consulted.	revised	No	S3‑183722
		S3‑183722	Security Impacts of Virtualisation	BT plc	SID new	Approval	Yes	Yes	agreed	No		S3‑183486
		S3‑183596	Update of EAP-AKA PFS work in progress	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑183597	New SID on authentication enhancements in 5GS	Ericsson	SID new	Discussion	Yes	Yes	revised	No	S3‑183721
		S3‑183721	New SID on authentication enhancements in 5GS	Ericsson	SID new	Discussion	Yes	Yes	revised	No	S3‑183745	S3‑183597
		S3‑183745	New SID on authentication enhancements in 5GS	Ericsson	SID new	Agreement	Yes	Yes	agreed	No		S3‑183721
		S3‑183598	Work on improving perfect forward secrecy in 5G network access	Ericsson	discussion	Discussion	No	Yes	withdrawn	Yes
		S3‑183627	New SID on data rate enhancements for user plane integrity protection	Motorola Mobility, Lenovo	SID new	Approval	Yes	Yes	merged	No	S3‑183718
		S3‑183717	LS on authentication of group of IoT devices	NTT-Docomo	LS out	Approval	Yes	Yes	approved	No
		S3‑183720	LS to GSMA on mitigation of the charging fraud attack	Huawei	LS out	Approval	Yes	Yes	approved	No
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑183202	SA3 Work Plan	MCC	Work Plan		Yes	YesEricsson commented that the study "Study on the Security of the enhancement to the 5GC Location Services" was to be finished in Dec 19 and that was inside Rel-17 timeline. CATT thought that this was a mistake but it could be corrected. BT added that the study FS_15LIS was finished and it should not appear in the Work Plan.	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑183205	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑183837
		S3‑183837	Work Plan input from Rapporteurs	MCC	other	-	No	YesHans (DT) will bring a revised SID for SBA since the scope has changed to include Rel-16.	noted	No		S3‑183205
10	Future Meeting Dates and Venues	S3‑183204	SA3 meeting calendar	MCC	other		Yes	YesEricsson will host a meeting in March (week of 11th). NAF will host the May 2019 meeting.	revised	No	S3‑183838
		S3‑183838	SA3 meeting calendar	MCC	other	-	No	YesSA3#94Ad-Hoc (11th March 2019) will be hosted by Ericsson in Stockholm. The meeting will deal only with studies. NAF will host the May 2019 meeting. Vodafone will host July 2020 meeting.	noted	No		S3‑183204
11	Any Other Business
12	Close