TDoc list

Tdoc List

2019-02-01 16:48

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‑190000	Agenda	WG Chairman	agenda		Yes	Yes	approved	No
3	IPR and Anti-Trust Law Reminder
4	Meeting Reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑190001	Report from last SA3 meeting/s	MCC	report		Yes	Yes	approved	No
4.2	Report from SA Plenary	S3‑190003	Report from last SA meeting	WG Chairman	report		Yes	Yes	noted	No
4.3	Report from SA3-LI
5	Items for early consideration
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑190042	LS on the security aspects of UE Capability ID	S2-1812607	LS in		Yes	Yes373,374 and 129 are docs related to this.	replied to	No
		S3‑190405	Reply to: LS on the security aspects of UE Capability ID	Qualcomm	LS out	approval	Yes	Yes	approved	No
		S3‑190047	Reply LS on Control Plane Solution for Steering of Roaming in 5GS	SP-181244	LS in		Yes	Yes	noted	No
		S3‑190103	Reply LS on Interim conclusions for SA2 study on Radio Capabilities Signalling Optimisations (FS_RACS)	R2-1819206	LS in		Yes	Yes	noted	No
		S3‑190373	Discussion on the incoming SA2 on security aspects of UE Capability ID	Qualcomm Incorporated	discussion	Discussion	Yes	Yes	noted	No
		S3‑190374	Draft response LS on the security aspects of UE Capability ID	Qualcomm Incorporated	LS out	Approval	Yes	YesHuawei: The capbility to be ssent after AES.	revised	No
		S3‑190396	LS on securing warning messages in ePWS	C1-190393	LS in		Yes	YesVodafone considered a serious problem to have a possible mechanism that can shut down IoT devices. Sprint: the focus should be on the broadcast service and not on PWS. Nokia: we did PWS security before and didn’t reach a conclusion given the different regulations in different parts of the World. This kind of mechanism is application specific and I'm not sure what security capbility we can enforce here. NEC: IoT devices need an intelligence to distinguish the PWS message to shut down. What is the use case here? BT: Don’t mix PWS with IoT, shutdown commands would be dangerous. Ericsson: SA3's study had a different scope. We had a user behind the device and in here we have a new use case. Sprint: this use case is not defined as a service. This should come as a SA1 requirement. NTT-Docomo and NCSC agreed with this. Qualcomm: this seems to be more application layer specific. NTT-Docomo: make it very clear that using existing PWS mechanisms without application layer security would not be acceptable.	replied to	No
		S3‑190406	Reply to: LS on securing warning messages in ePWS	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑190418	Reply LS on Interim conclusions for SA2 study on Radio Capabilities Signalling Optimisations (FS_RACS)	S2-1901303	LS in	discussion	Yes	Yes	noted	No
6.2	IETF
6.3	ETSI SAGE	S3‑190403	Expectations and requirements for 256 bit algorithms	ETSI SAGE	LS in	discussion	Yes	Yes	replied to	No
		S3‑190407	Reply to: Expectations and requirements for 256 bit algorithms	Vodafone	LS out	approval	Yes	Yes	approved	No
		S3‑190402	128-EIA3 maximum message size	ETSI SAGE	LS in	discussion	Yes	Yes	noted	No
		S3‑190107	Expectations and requirements for 256 bit algorithms	ETSI SAGE	LS in		Yes	Yes	withdrawn	Yes
6.4	GSMA	S3‑190018	Cooperation on Generic Slice Template definition	GSMA	LS in		Yes	Yes	noted	No
		S3‑190019	User Plane Security for 5GC Roaming	GSMA	LS in		Yes	YesDeutsche Telekom: we have taken into acount in the FBA study already. BT commented that this should be taken care of in Rel-16. Vodafone: make a recommendation in Rel-15 to get around this issue and fix it in Rel-16. BT clarified that SA plenary would take care of a response to GSMA coordinating with SA3.	noted	No
		S3‑190039	GTP Recovery Counter & GSN node behaviou	GSMA	LS in		Yes	YesDirected to CT4.	noted	No
		S3‑190408	User Plane Security for 5GC Roaming	Vodafone	CR	Agreement	Yes	Yes	agreed	No
		S3‑190409	LS on User Plane Security for 5GC Roaming	BT	LS out	Agreement	Yes	Yes	approved	No
6.5	OMA
6.6	TCG	S3‑190048	TCG Progress Report	InterDigital, Inc.	report	Information	Yes	Yes	noted	No
6.7	oneM2M
6.8	TC-CYBER
6.9	ETSI NFV
6.10	CVDs and Research
6.11	Other Groups	S3‑190033	LS to 3GPP TSG-SA WG6 on Use of ITS Dedicated Spectrum within V2X UE	ETSI TC ITS	LS in		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
7.1.2	Key derivation	S3‑190232	Clarification on the Use of the SUPI in the Kamf Derivation	Huawei, Hisilicon,Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	YesEricsson didn’t agree since this would affect Legal Interception requirements. The question is whether to remove the SUPI type part. ZTE didn’t agree with this change. Vodafone: the wording is confusing.	revised	No	S3‑190416
		S3‑190416	Clarification on the Use of the SUPI in the Kamf Derivation	Huawei, Hisilicon,Nokia,Nokia Shanghai Bell,Qualcomm,Vodafone	CR	Agreement	Yes	Yes	agreed	No		S3‑190232
		S3‑190500	LS on naming issues with SUPI	Vodafone	LS out	Approval	No	Yes	withdrawn	Yes
7.1.3	Mobility	S3‑190135	Clarification to the 5G-GUTI change during the NAS procedure.	NEC Europe Ltd	CR	Approval	Yes	Yes	not pursued	No
		S3‑190138	Handling of SUCI de-concealment during registration retry procedure	NEC Europe Ltd	CR	Approval	Yes	YesEricsson: this is done in TS 34.501 already. It's in scope of CT1. Huawei: it doesn’t belong here. Nokia agreed with this. There was a strong support on this being in CT1's scope.	not pursued	No
		S3‑190327	Allocating new 5G-GUTI during the MO service request procedure	NEC Europe Ltd	CR	Approval	Yes	YesHuawei: check with CT1. Qualcomm: we should not mandate it, it's up to the network. Nokia agreed. Ericsson: we discussed this before and decided not to mandate it. Docomo proposed to change NOTE1 to clarify the "more frequently" bit.	revised	No	S3‑190420
		S3‑190420	Allocating new 5G-GUTI during the MO service request procedure	NEC Europe Ltd	CR	Approval	Yes	Yes	agreed	No		S3‑190327
		S3‑190379	CR on clarification on N2 handover	Qualcomm Incorporated	CR	Agreement	Yes	YesEricsson wasn't fully in line with this.It was taken offline.	revised	No	S3‑190421
		S3‑190421	CR on clarification on N2 handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑190379
		S3‑190380	CR - clarification on key handling in handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑190151	Align NAS connection identifier values	ZTE Corporation	CR	Agreement	Yes	YesDiscussed with overlapping documents 365, 378 and 222. Nokia: Huawei's document is proposing to re-use the concept in LTE. Ericsson: in LTE we didn’t have the concept of NAS connection identifier. It was finally decided to go for Qualcomm's point in 378. The last two changes of this document were merged in 422.	merged	No	S3‑190422
		S3‑190378	CR on NAS connection id for NAS MAC calculation	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑190365	Non-3GPP Access: Correcting Connection Identifier	Samsung	CR		Yes	Yes	revised	No	S3‑190422
		S3‑190422	Non-3GPP Access: Correcting Connection Identifier	Samsung,ZTE	CR	-	Yes	Yes	agreed	No		S3‑190365
7.1.4	AS security	S3‑190255	EUTRA connected to 5GC: clause 6.6.2	Ericsson	CR	Agreement	Yes	YesVodafone didn't see the purpose of the note.Just refer to 33.401. Nokia: ng-eNodeB specific topics are specified in 33.501, not 33.401. Vodafone admitted the above but preferred to have the note as a requirement. Ericsson replied that the requirement existed somewhere else. This was taken offline.	revised	No	S3‑190501
		S3‑190501	EUTRA connected to 5GC: clause 6.6.2	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190255
		S3‑190358	Correction on RRC states terminology usage	Samsung	CR		Yes	YesOverlapping with 0072, 258,259.	revised	No	S3‑190423
		S3‑190423	Correction on RRC states terminology usage	Samsung,Huawei	CR	-	Yes	Yes	agreed	No		S3‑190358
		S3‑190256	EUTRA connected to 5GC: clause 6.7.3	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑190427
		S3‑190427	EUTRA connected to 5GC: clause 6.7.3	Ericsson	CR	Agreement	Yes	YesRevised to address issues on the cover.	agreed	No		S3‑190256
		S3‑190257	EUTRA connected to 5GC: clause 6.7.4	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑190428
		S3‑190428	EUTRA connected to 5GC: clause 6.7.4	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190257
		S3‑190258	EUTRA connected to 5GC: clause 6.8.1	Ericsson	CR	Agreement	Yes	YesNokia: There is no consistency with the key names. Don’t use KngRAN.	revised	No	S3‑190424
		S3‑190424	EUTRA connected to 5GC: clause 6.8.1	Ericsson	CR	Agreement	Yes	YesRevised to include all clauses affected in the cover page.	agreed	No		S3‑190258
		S3‑190072	Corrections of messages names etc	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑190423
		S3‑190078	Clarification and correct clause reference for RNAU w/o context relocation	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑190192	Corrections on ng-ran keys	Huawei, HiSilicon	CR	Agreement	Yes	YesNokia didn’t agree with using multiple names for the same keys. KNG-RAN should not be used as this is causing confusion.	revised	No	S3‑190426
		S3‑190426	Corrections on ng-ran keys	Huawei, HiSilicon,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190192
		S3‑190254	Corrections to RRC Inactive procedure.and RAN-based notification area update procedure.	Ericsson	CR	Agreement	Yes	YesHuawei didn’t agree with the new requirement, since this was implementation specific and not needed. NEC supported the Ericsson's view. Nokia: there is an impact on implementation, it has performance implications. They needed to check if this was fine with them.	revised	No	S3‑190429
		S3‑190429	Corrections to RRC Inactive procedure.and RAN-based notification area update procedure.	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190254
		S3‑190259	EUTRA connected to 5GC: clause 6.8.2	Ericsson	CR	Agreement	Yes	YesThe NOTE was removed since it was adressed in other conitrbutions.Also other changes related with message names. Overlaps with 192.	revised	No	S3‑190425
		S3‑190425	EUTRA connected to 5GC: clause 6.8.2	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190259
		S3‑190260	EUTRA connected to 5GC: clause 6.9.2.1	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑190430
		S3‑190430	EUTRA connected to 5GC: clause 6.9.2.1	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190260
		S3‑190193	New clause for intra ng-enb handover	Huawei, HiSilicon	CR	Agreement	Yes	YesNokia: not sure if we need this new clause. Ericsson agreed.	not pursued	No
		S3‑190261	EUTRA connected to 5GC: clauses 6.9.2.3.1 and 6.9.2.3.2	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑190426
		S3‑190262	EUTRA connected to 5GC: clauses 6.9.3 and 6.9.4	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑190431
		S3‑190431	EUTRA connected to 5GC: clauses 6.9.3 and 6.9.4	Ericsson	CR	Agreement	Yes	YesRevised to fix mistakes on the cover page.	agreed	No		S3‑190262
		S3‑190263	EUTRA connected to 5GC: clause 6.9.5	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑190432
		S3‑190432	EUTRA connected to 5GC: clause 6.9.5	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190263
		S3‑190174	Clarification for section 6.10.2.1	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑190433
		S3‑190433	Clarification for section 6.10.2.1	Huawei, Hisilicon	CR	Approval	Yes	YesIncorporating changes suggested by Ericsson.	agreed	No		S3‑190174
		S3‑190175	Clarification for UP security in option4&7	Huawei, Hisilicon	CR	Approval	Yes	YesNokia: delete the "rather than".	revised	No	S3‑190434
		S3‑190434	Clarification for UP security in option4&7	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑190175
		S3‑190264	EUTRA connected to 5GC: clause 6.11	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑190280	EUTRA connected to 5GC: clause 8	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑190435
		S3‑190435	EUTRA connected to 5GC: clause 8	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190280
		S3‑190297	Clarification to idle mode mobility from EPS to 5GS	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑190065	Corrections of messages names etc	HUAWEI TECH. GmbH	CR		No	Yes	withdrawn	Yes
7.1.5	NAS security	S3‑190136	Clarification to the 5G-GUTI allocation during the Notification procedure.	NEC Europe Ltd	CR	Approval	Yes	Yes	not pursued	No
		S3‑190153	Handling of AMF redirection	ZTE Corporation	CR	Agreement	Yes	YesEricsson: Why restrict the AMF from performing re-authentication procedure?It is not clear why this is needed. Nokia agreed with Ericsson. Proposal 2 and 3 were related to one.	not pursued	No
		S3‑190177	key update in multi-NAS scenario	Huawei, Hisilicon	CR	Approval	Yes	YesNokia: why are we bringing these changes based on access type? Overlapping with tdoc 282 and 372.	revised	No	S3‑190556
		S3‑190556	key update in multi-NAS scenario	Huawei, Hisilicon,Qualcomm,Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑190177
		S3‑190222	Modificaiton on the NAS connection identifier for backward compatibility with LTE	Huawei, Hisilicon	CR		Yes	Yes	not pursued	No
		S3‑190281	Clarification to AKA parameter derivation	Ericsson	CR	Approval	Yes	YesNokia missed some text covering RES* and XRES*.It was proposed to add this during the next meeting.	agreed	No
		S3‑190282	Multiple NAS connecions: mobility with horizontal KAMF derivation	Ericsson	CR	Approval	Yes	Yes	merged	No	S3‑190556
		S3‑190283	Multiple active NAS connections in the same PLMN's serving network: common algorithm identifiers	Ericsson	CR	Approval	Yes	YesQualcomm: how do you achieve this requirement? They didn't agree with the wording. It was revised to reword the sentence.	revised	No	S3‑190436
		S3‑190436	Multiple active NAS connections in the same PLMN's serving network: common algorithm identifiers	Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑190283
		S3‑190372	Handling the non-3GPP security context at mobility on the 3GPP access	Qualcomm Incorporated	CR	Agreement	Yes	YesEricsson was fine with this proposal.	merged	No	S3‑190556
7.1.6	Security context
7.1.7	Visibility and Configurability
7.1.8	Primary authentication	S3‑190083	Alignment with TS 23.502: Optimization of UDM selection in AUSF	Ericsson	CR	Agreement	Yes	YesVodafone: Compatibility issue with the networks that are rolled out today. It's too late to change this. Ericsson replied that this was alignment with SA2. Huawei disagreed. This had to be taken offline.	not pursued	No
		S3‑190084	Correction to authentication step	Ericsson	CR	Agreement	Yes	YesCableLabs: good requirement. Does the AUSF do the same validation? ZTE: this depends on the discussion about the SUPI type and the AMF. Nokia: the MNC is part of the SUPI value. Why does it depend on the SUPI type? The current procedure already addresses this. What kind of attack are we facing here? Huawei agreed with Nokia. Ericsson: there is no attack, there is a weakness. Lenovo didn’t understand how this could ever happen.	not pursued	No
		S3‑190124	CR Add UE trace to UE Authentication Get Service	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesVodafone: what data is Trace Data? NEC agreed, there was no security reasoning behind this. Nokia: This is described in SA2 and CT4. Huawei: limit to authentication related parameters. Nokia: it doesn't impact the security directly. This particular definition does only exist in 33.401, that’s why it's here. Ericsson: we need to know what is done in SA2 but at the moment there is no mentioning of this, the clause is empty. Nokia commented that this was aligned with results from the SA2 meeting held the previous week, not available at that time. Vodafone: we might be giving away data that is covered by the GDPR. It was agreed to send an LS to SA2 and attach this CR. The agreement on this CR would depend on the response from SA2. After discussions on the LS, it was decided to note the LS.	not pursued	No
		S3‑190502	LS on clarification on UE trace definition	Nokia	LS out	Approval	Yes	Yes	approved	No
7.1.9	Secondary authentication
7.1.10	Interworking	S3‑190137	Clarification on Establishment of a mapped security context during intersystem handover(S1 to N1)	Intel Deutschland GmbH	CR		Yes	YesZTE didn’t agree with the scenarios. Ericsson: the clause is misplaced.	not pursued	No
		S3‑190152	Clarification on Registration procedure for mobility from EPS to 5GS over N26	ZTE Corporation	CR	Agreement	Yes	YesEricsson: we don’t need this clarification, nothing new here. Vodafone: this is not an essential correction, cat-F.Nokia supported Vodafone.	not pursued	No
		S3‑190140	Clarification on Handover message in Interworking	Intel Deutschland GmbH	CR		Yes	YesQualcomm disagreed with this.	not pursued	No
		S3‑190176	claification on interworking case	Huawei, Hisilicon	CR	Approval	Yes	YesVodafone: not happy with the use of "done" in these sentences. Qualcomm: changes are not needed, they are obvious. MCC: replace 4G with LTE.	revised	No	S3‑190437
		S3‑190437	claification on interworking case	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑190176
		S3‑190224	NAS counter clarification on interworking	Huawei, Hisilicon	CR	Agreement	Yes	YesEricsson: first set of changes are legacy behaviour. Not needed. Qualcomm didn’t agree with this contribution at all.	revised	No	S3‑190438
		S3‑190438	NAS counter clarification on interworking	Huawei, Hisilicon	CR	Agreement	Yes	YesFirst change is gone.	agreed	No		S3‑190224
		S3‑190134	Clarification on Establishment of a mapped security context during intersystem handover(N1 to S1)	Intel Deutschland GmbH	CR		Yes	YesQualcomm and Ericsson didn’t agree with this.	not pursued	No
		S3‑190231	Clarification on securing the procedure of idle mode mobility from 5GS to EPS over N26 interface	Huawei, Hisilicon	CR	Agreement	Yes	YesWe don’t need this change. Initial attach procedure is done where there is no N26. Ericsson commented that it didn't matter whether there was N26 or not.	not pursued	No
7.1.11	non-3GPP access
7.1.12	NDS	S3‑190284	Clarification to the implementation requirement for the protectaion of the backhaul and sidehaul interfaces	Ericsson	CR	Agreement	Yes	Yes	agreed	No
7.1.13	Service based architecture
7.1.13.1	Interconnect (SEPP related)	S3‑190090	Editorials and minor clarifications for clause 13.2	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑190439
		S3‑190439	Editorials and minor clarifications for clause 13.2	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190090
		S3‑190118	On the handling of invalid JSON patches in N32-f messages	Telekom Deutschland GmbH	discussion	Discussion	Yes	Yes	noted	No
		S3‑190559	LS on PLMN-ID verification	Deutsche Telekom	LS out	Approval	No	YesA conference call was setup to discuss the LS. This was sent for email approval: Friday 8th available,Tuesday 12th ,Wednesday 13th final version available.	left for email approval	No
7.1.13.2	Other	S3‑190089	Editorials and minor clarifications for clause 13.1	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑190227	Update on the token verification	Huawei, Hisilicon,Nokia	CR	Agreement	Yes	YesNokia: not OK with removing the verification part, agree to remove where the verification is done. This was taken offline and then agreed.	agreed	No
		S3‑190229	Clarification on service authorization and token verification	Huawei, Hisilicon	CR	Agreement	Yes	Yes	revised	No	S3‑190440
		S3‑190440	Clarification on service authorization and token verification	Huawei, Hisilicon, Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑190229
		S3‑190354	Updating Access Token Response to include token expiration time and scope	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	merged	No	S3‑190440
7.1.14	Privacy	S3‑190116	Subscriber privacy: test data for SUCI computation	Gemalto N.V.	CR	Approval	Yes	YesIDEMIA: some coding is wrong, nt compliying with CT4's decisions. Qualcomm: good idea to have testers' data, but there are things missing here. We can come back next meeting with a better look at this.	not pursued	No
		S3‑190398	Comment on S3-190116	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑190383	SUPI Type clarification	Qualcomm Incorporated	CR	Approval	Yes	YesGemalto: what happens if there are two files in the UICC? Which one do you compute? Qualcomm: question for CT1. I don’t know if there is a scenario with two files. We may have more types of SUPI. CT hasn’t decided to remove this yet. There was no agreement with this contribution.	not pursued	No
		S3‑190384	Input encoding for ECIES protection schemes	Qualcomm Incorporated	CR	Approval	Yes	YesVodafone: does this protect types? Qualcomm: no, just the subscription identifier part. IDEMIA: why isnt the CT4 referenced here? Qualcomm: it doesn’t apply to transport. This was taken offline. IDEMIA objected since this meant additional processing in the UICC.	revised	No	S3‑190557
		S3‑190557	Input encoding for ECIES protection schemes	Qualcomm Incorporated,IDEMIA,Gemalto	CR	Approval	Yes	Yes	agreed	No		S3‑190384
		S3‑190397	Clarification on the allocation of 5G-GUTI	Huawei, Hisilicon	CR	Agreement	Yes	YesQualcomm didn’t agree with this CR.A rewording was then proposed and for that reason the CR was revised. NEC: remove the last line and let CT1, CT4 decide.	revised	No	S3‑190415	S3‑190234
		S3‑190415	Clarification on the allocation of 5G-GUTI	Huawei, Hisilicon,Nokia,Interdigital	CR	Agreement	Yes	Yes	agreed	No		S3‑190397
		S3‑190234	Clarification on the allocation of 5G-GUTI	Huawei, Hisilicon	CR	Agreement	Yes	Yes	revised	No	S3‑190397
7.1.15	Incoming and outgoing Lses	S3‑190020	LS on new 5G-GUTI allocation	C1-188921	LS in		Yes	YesAddressed in tdoc 106.	replied to	No
		S3‑190410	Reply to: LS on new 5G-GUTI allocation	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑190021	LS on protection of initial NAS messages	C1-188925	LS in		Yes	Yes	noted	No
		S3‑190022	Reply LS on Routing ID	S2-1813178	LS in		Yes	YesNEC had a discussion document about this in tdoc 401.	noted	No
		S3‑190023	Reply LS on Routing ID	C1-188979	LS in		Yes	Yes	noted	No
		S3‑190026	LS on Nudr Sensitive Data Protection	C4-188524	LS in		Yes	YesVodafone commented that this shouldn’t be done at all. BT: this is trying to structure unenstrucutred data.	replied to	No
		S3‑190411	Reply to: LS on Nudr Sensitive Data Protection	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑190027	Clarification request on NF authorization in UE Reachability Notification Request procedure	C4-188603	LS in		Yes	YesVodafone pointed out that the second question was relevant for SA3. Docomo commented that this point was about reachability, not security related.	noted	No
		S3‑190034	LS on DRB Integrity Protection	R2-1819080	LS in		Yes	Yes	noted	No
		S3‑190036	Reply LS on inclusion of selected PLMN into the complete message	R3-187235	LS in		Yes	Yes	noted	No
		S3‑190037	LS on Security Result Exchange Between NG-RAN and SMF in DC	R3-187244	LS in		Yes	YesNokia: there is no security issue here. Ericsson: the SMF should be informed.This was taken offline.	replied to	No
		S3‑190412	Reply to: LS on Security Result Exchange Between NG-RAN and SMF in DC	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑190038	Enforcement of maximum supported data rate for integrity protection	R3-187267	LS in		Yes	YesThis had to be taken offline since Docomo doubted about the necessity of doing this.	noted	No
		S3‑190085	Reply LS on Nudr Sensitive Data Protection	Ericsson	LS out	Approval	Yes	Yes	revised	No	S3‑190411
		S3‑190106	Reply LS on new 5G-GUTI allocation	Ericsson	LS out	Approval	Yes	YesQualcomm agreed with this except in the case of non-3GPP networks.	revised	No	S3‑190410
		S3‑190126	Discussion on C1-188921 LS on GUTI Re-assignment	Nokia, Nokia Shangahi Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑190129	Discussion on Radio Capability indication LS S2-1812607	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	YesVodafone was in line with Nokia's comments: It could be a problem given that it wouldn't be sent after authentication. Ericsson also agreed with sending the capbilities encrypted.	noted	No
		S3‑190394	LS on the need to update home network public key and key ID during Routing indicator update	C1-190377	LS in		Yes	YesQualcomm had tdoc 400 related to this.	replied to	No
		S3‑190413	Reply to: LS on the need to update home network public key and key ID during Routing indicator update	Vodafone	LS out	approval	Yes	Yes	approved	No
		S3‑190400	Discussion on incoming CT1 LS on update of Routing Indicator (S3-190394)	Qualcomm Incorporated	discussion	Endorsement	Yes	YesVodafone: the mechanism of the public key update is out of standardization scope and it should be kept this way.BT, IDEMIA, CableLabs and ORANGE supported this.	noted	No
		S3‑190395	LS on mandating 5G-GUTI allocation after network triggered service request	C1-190380	LS in		Yes	YesHuawei proposed a CR in 397. Qualcomm proposed to respond afirmatively to this LS but didn't agree with the CR. Nokia: on the GUTI realocation we should be flexible.	replied to	No
		S3‑190414	Reply to: LS on mandating 5G-GUTI allocation after network triggered service request	Huawei	LS out	approval	Yes	Yes	approved	No
		S3‑190401	[Late contribution] Discussion on dealing with Routing ID update Lses	NEC Corporation	discussion	discussion	Yes	YesQualcomm and Gemalto commented that there was an existing mechanism for what SA2 was proposing. NEC replied that they were not arguing that but wanted to put it down in words and send it to them. IDEMIA: the proof of receipt needs to go through the UDM but I'm not sure that this is the case in our spec. Vodafone: OTA is transport independent protocol. In steering of roaming, OTA was one of the possible protocols to be used there. Ericsson: we don’t need to send an LS saying that OTA is fine from the security point of view. At&T considered that the LS wasn’t necessary since they wouldn't do anything with it. Vodafone: the attached CR contains OTA as a path to and from.	noted	No
		S3‑190404	Interception of voice services over new radio in a 5GS environment	S3i190057	LS in	discussion	Yes	YesVodafone asked if a study could cover this work. BT replied that a study could be done. The Chair commented that a study would be easier to manage. Vodafone, AT&T, Deutsche Telekom and others supported having a study item, so BT would bring it for the next meeting in May.	postponed	No
		S3‑190417	LS Response on Enforcement of maximum supported data rate for integrity protection	S2-1812600	LS in	discussion	Yes	Yes	noted	No
		S3‑190419	LS Response on Security Result Exchange Between NG-RAN and SMF in DC	S2-1901386	LS in	discussion	Yes	Yes	noted	No
7.1.16	Others	S3‑190178	Clarification on the UE selecting the 4G or 5G security protection method	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm: already specified in CT1, not needed here. Huawei: this is not done in CT1. Ericsson: why is NAS not mentioned here and only AS SMC procedure? Is the AS SMC part an example? This had to be taken offline.	revised	No	S3‑190478
		S3‑190478	Clarification on the UE selecting the 4G or 5G security protection method	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑190178
		S3‑190219	Clarification on UE Parameters Update Data used for MAC computation	Huawei, HiSilicon	CR	Agreement	Yes	YesQualcomm: it is already clear, no need to clarify. IDEMIA and Gemalto didn't support this either.	not pursued	No
		S3‑190345	Correction to clause 14.2.1	NEC Corporation	CR	Approval	Yes	Yes	agreed	No
		S3‑190355	SN Id and SNN clarification	Ericsson India Private Limited	discussion	Discussion	Yes	YesIt was agreed to do a CR for this (tdoc 441).	noted	No
		S3‑190375	Modifying AKA to provide freshness for the protection of SQN in the case of re-synchronisations	Qualcomm Incorporated	discussion	Discussion	Yes	Yes	noted	No
		S3‑190376	Adding MACS as an input parameter to the calculation of AK* to provide freshness	Qualcomm Incorporated	CR	Agreement	Yes	YesAT&T supported this change. Apple:we should first investigate whether it is feasible in 5G, and then evaluate the effect and make corresponding enhancement. It was left open to verify what GSMA was doing on this topic.	not pursued	No
		S3‑190441	SN Id and SNN clarification	Ericsson	CR	discussion	Yes	Yes	agreed	No
7.2	Security Assurance Specification for 5G (SCAS_5G) (Rel-16)
7.2.1	NR Node B (gNB) (TS 33.511)	S3‑190225	Test Case: Authorization of NF Serive Access	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	noted	No
		S3‑190307	Security Assurance Requirement and Test for authorization handling in the NF	Huawei, HiSilicon	draftCR	Agreement	Yes	Yes	revised	No	S3‑190540
		S3‑190540	Security Assurance Requirement and Test for authorization handling in the NF	Huawei, HiSilicon	draftCR	Agreement	Yes	Yes	approved	No		S3‑190307
		S3‑190487	Output of SCAS offline session	Deutsche Telekom	report	Information	Yes	Yes	noted	No
		S3‑190561	draftCR General aspects in TS 33.117	Nokia	draftCR	Approval	Yes	Yes	approved	No
7.2.2	Access and Mobility Management Function (TS 33.512)	S3‑190311	SCAS: AMF-specific adaptations of security functional requirements and related test cases	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: interoperability testing is out of scope of SCAS. NEC pointed out that tdoc 099 was related to this discussion. 099 was discussed and then this document gone through. Test case one was scrapped out, related to interoperability. Test case two: the vice Chair commented that failure of integrity protection would fit in here. There didn’t seem to be a discussion so the vice chair proposed to take this document offline.	noted	No
		S3‑190312	Security Assurance Requirements and Tests for the Security Functionalities Provided by UPF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
7.2.3	User Plane Function (UPF) (TS 33.513)
7.2.4	Unified Data Management (UDM) (TS 33.514)	S3‑190310	SCAS: UDM-specific adaptations of security functional requirements and related test cases	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑190508
		S3‑190508	SCAS: UDM-specific adaptations of security functional requirements and related test cases	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190310
		S3‑190509	Draft TS 33.514	NEC	draft TS	Approval	Yes	Yes	approved	No
7.2.5	Session Management Function (SMF) (TS 33.515)	S3‑190317	Requirement and test cases for SMF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
7.2.6	Authentication Server Function (AUSF) (TS 33.516)	S3‑190099	Analysis of requirements on the AUSF in TS 33.501	Ericsson	discussion	Endorsement	Yes	YesHuawei: the failure should be also tested and that does not belong to any category. Alf (Vice chair) commented that the confusion focused on whether interoperability and failure authentication were in or out of scope of SCAS. Huawei: very few requirements deal with failure test cases: what happens if a particular test fails. The Vice Chair asked the delegates if the requirements in the table were considered category one. NEC replied that number 3 wasn’t category one. Ericsson: check these requirements and see what could go wrong and come back next meeting with the test cases? Huawei: refer to CT group standard as well. Deutsche Telekom: agree with Ericsson that these test cases are out of scope of SCAS. The way forward would be to agree on this. NEC: at least 1,2 and 4 are category one and this is agreed by the group. Huawei: failure test case included in the category one or not?	noted	No
		S3‑190315	Removing the test case on Kseaf handling	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑190510	Draft TS 33.512	Deutsche Telekom	draft TS	Approval	Yes	Yes	approved	No
7.2.7	Security Edge Protection Proxy (SEPP) (TS 33.517)	S3‑190233	SCAS SEPP: Introduction and general approach	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑190512
		S3‑190512	SCAS SEPP: Introduction and general approach	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑190233
		S3‑190240	Test Case: Mutual Authentication	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑190120	New Test Case: Separation of cryptographic storage within the SEPP	Telekom Deutschland GmbH	pCR	Approval	Yes	Yes	revised	No	S3‑190511
		S3‑190511	New Test Case: Separation of cryptographic storage within the SEPP	Telekom Deutschland GmbH	pCR	Approval	Yes	Yes	approved	No		S3‑190120
		S3‑190121	New Test Case: Connection-specific scope of cryptographic material by IPX-providers	Telekom Deutschland GmbH	pCR	Approval	Yes	Yes	noted	No
		S3‑190122	New Test Case: Precendence of preconfigured protection policies	Telekom Deutschland GmbH	pCR	Approval	Yes	Yes	noted	No
		S3‑190123	New Test Case: Validating the common message formatting	Telekom Deutschland GmbH	pCR	Approval	Yes	Yes	noted	No
		S3‑190515	Draft 33.517	Nokia	draft TS	Approval	Yes	Yes	approved	No
7.2.8	Network Resource Function (NRF) (TS 33.518)	S3‑190235	SCAS NRF: Introduction and general approach	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑190244	Test Case: NF Discovery Service Authorization	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑190313	Security Assurance Requirement and Test for NRF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑190513	Draft TS 33.518	Nokia	draft TS	Approval	Yes	Yes	approved	No
7.2.9	Network Exposure Function (NEF) (TS 33.519)	S3‑190154	Authorization on northbound APIs	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑190514
		S3‑190514	Authorization on northbound APIs	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑190154
		S3‑190516	Draft TS 33.519	ZTE	draft TS	Approval	Yes	Yes	approved	No
7.3	eMCSec R16 security (MCXSec) (Rel-16)
7.4	Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)	S3‑190167	a skeleton of security aspects of 5G SRVCC to UTRAN	Huawei, Hisilicon, China Unicom	draftCR	Approval	Yes	Yes	revised	No	S3‑190443
		S3‑190443	a skeleton of security aspects of 5G SRVCC to UTRAN	Huawei, Hisilicon, China Unicom	draftCR	Approval	Yes	YesThe annex was retitled.	approved	No		S3‑190167
7.5	Other work areas
7.5.1	SAE/LTE Security	S3‑190066	LS to RAN2/3 on EDT data integrity protection	HUAWEI TECH. GmbH	LS out		No	Yes	withdrawn	Yes
7.5.2	IP Multimedia Subsystem (IMS) Security
7.5.3	Network Domain Security (NDS)	S3‑190016	Correcting TLS crypto profiles	Juniper Networks, Ericsson	CR		Yes	Yes	agreed	No
7.5.4	UTRAN Network Access Security
7.5.5	GERAN Network Access Security
7.5.6	Generic Authentication Architecture (GAA)
7.5.7	Security Aspects of Home(e)NodeB (H(e)NB)
7.5.8	Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)	S3‑190049	[33.179] R13 Annex D.3.4.2 XSD correction	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No
		S3‑190050	[33.180] R14 Annex D.3.5.2 XSD correction (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑190444
		S3‑190444	[33.180] R14 Annex D.3.5.2 XSD correction (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	YesFixng issues on the cover page.	agreed	No		S3‑190050
		S3‑190051	[33.180] R15 Annex D.3.5.2 XSD correction (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑190445
		S3‑190445	[33.180] R15 Annex D.3.5.2 XSD correction (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑190051
		S3‑190052	[33.179] R13 IdMS interface security	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No
		S3‑190053	[33.180] R14 IdMS interface security (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	YesCableLAbs	revised	No	S3‑190446
		S3‑190446	[33.180] R14 IdMS interface security (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑190053
		S3‑190054	[33.180] R15 IdMS interface security (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	YesJuniper: the TLS profile has been moved to 33.210. It was commented that there was a note in 33.310 pointing to 33.210 anyway and this could be fixed later.	revised	No	S3‑190447
		S3‑190447	[33.180] R15 IdMS interface security (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑190054
		S3‑190055	[33.179] R13 user service authorisation	Motorola Solutions Germany	CR	Agreement	Yes	YesSamsung: we cannot delete a feature from Release 13 for this reason. We can wait for stage 3 before deleting this. Tim (Motorola): leave it in Rel-13? It's ok, but even beyond stage 3 problems there is an interoperability problem. We should remove it from Rel-15, Rel-16. Nokia: plugtest results should be evaluated by Samsung and bring a paper with their conclusions. Samsung agreed to do that.	not pursued	No
		S3‑190056	[33.180] R14 user service authorisation (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	not pursued	No
		S3‑190057	[33.180] R15 user service authorisation (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	not pursued	No
		S3‑190058	[33.180] R14 InK clarifications	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑190448
		S3‑190448	[33.180] R14 InK clarifications	Motorola Solutions Germany	CR	Agreement	Yes	YesRevised to address issues on the cover page.	agreed	No		S3‑190058
		S3‑190059	[33.180] R15 InK clarifications (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑190449
		S3‑190449	[33.180] R15 InK clarifications (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	YesIssues on the cover page.	agreed	No		S3‑190059
		S3‑190060	[33.180] R14 MCX identity clarifications	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑190450
		S3‑190450	[33.180] R14 MCX identity clarifications	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑190060
		S3‑190061	[33.180] R15 MCX identity clarifications (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑190451
		S3‑190451	[33.180] R15 MCX identity clarifications (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑190061
7.5.9	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑190091	Minimized kernel functions	Ericsson	CR	Agreement	Yes	YesIf agreed, this should become a mirror and we would need a new CR for Rel-14.	not pursued	No
		S3‑190092	Minimized kernel functions	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑190093	Protection from buffer overflows	Ericsson	CR	Agreement	Yes	YesMCC commented that the error should be corrected in the earliest release of this spec,Rel-14. Huawei: the test case is not impacted, only the examples. NTT-Docomo agreed with removing the examples to keep the spec more aligned with the reality.	revised	No	S3‑190456
		S3‑190456	Protection from buffer overflows	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190093
		S3‑190094	Protection from buffer overflows	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑190095	Uunused software	Ericsson	CR	Agreement	Yes	YesDeutsche Telekom didn't agree with this change. The test was important to maintain. Ericsson wasn't clear on how to test this. NEC supported Deutsche Telekom, BT as well.	not pursued	No
		S3‑190096	Uunused software	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑190097	No unsupported components	Ericsson	CR	Agreement	Yes	YesDeutsche Telekom didn't agree with removing this test case. NEC and BT supported this.	not pursued	No
		S3‑190098	No unsupported components	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑190191	Editorial corrections in TS 33.117 R15	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesIt was agreed in order to see if Rel-14 had the same issue to be corrected.	revised	No	S3‑190458
		S3‑190458	Editorial corrections in TS 33.117 R15	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑190191
		S3‑190220	Test Case: Mutual Authentication between Network Functions	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	noted	No
		S3‑190393	New proposal on the length of password and other clarifications	Huawei, Hisilicon	CR	Approval	Yes	YesDT didn’t agree with the last note (third change). NEC supported this change. NTT-Docomo: Anti-spoofing in internal networks is necessary.Huawei commented that SA3 didn’t do this for every network element. CableLabs didn't agree with the first change. NCSC suggested having longer simpler passwords was a better solution. BT wasn’t in favour of this change either. It was decided to drop the first change. BT: there are use cases in certain interfaces where we may want to allow this, for the note in the third change. BT was in favour of maintaing this. DT didn’t agree with the second change either.There were arguments on the 100 accounts so this was taken offline. BT wasn’t comfortable with having SA3 imposing limitations on the products.	revised	No	S3‑190503
		S3‑190503	New proposal on the length of password and other clarifications	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑190393
		S3‑190457	Protection from buffer overflows	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑190459	Editorial corrections	Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑190504	New proposal on the length of password and other clarification	Huawei	CR	Agreement	Yes	Yes	agreed	No
		S3‑190505	New proposal on the length of password and other clarification	Huawei	CR	Agreement	Yes	Yes	agreed	No
7.5.10	Security Aspects of Narrowband IOT (CIoT)	S3‑190035	Reply LS on UP Integrity Protection for Small Data in Early Data Transfer	R3-187230	LS in		Yes	Yes	withdrawn	Yes
		S3‑190073	EDT UP IP handling of multiple PDCP PDUs	Huawei, Hisilicon	CR	Approval	Yes	YesIntel: RAN2 hasn’t discussed the LS that we sent to them, so we don’t need to pursue this CR during this meeting. Besides this solution doesn’t cover a particular scenario and we don’t agree with this solution. This was left open.	not pursued	No
		S3‑190465	EDT UP IP handling of multiple PDCP PDUs	Huawei, Hisilicon	CR	Approval	No	Yes	withdrawn	Yes
		S3‑190076	LS to RAN2/3 on EDT data integrity protection	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑190454
		S3‑190454	LS to RAN2/3 on EDT data integrity protection	Huawei, Hisilicon	LS out	Approval	Yes	Yes	approved	No		S3‑190076
		S3‑190298	EDT correction – input "S" to calculation of HASHUE-data and HASHeNB-data	Ericsson	CR	Agreement	Yes	YesEricsson considered that RAN2 had the responsibility for a solution and not SA3. Huawei disagreed. Ericsson: we don’t need to take a stand on how RAN will solve the issue. We can wait for them. Huawei replied that SA3 knew what RAN solution would be about, but it didn’t work when having multiple PDCP PDUs. Nokia: calculation at the MAC layer feasibility should be pondered by RAN2, not SA3. Let's ask them about this in an LS. Qualcomm supported involving RAN2. Docomo commented that SA3 may reconsider the requirement for having it at the MAC layer and make it application dependent. It was agreed to send an LS to RAN2 with several questions involving potential solutions to the multiple PDU issue.	not pursued	No
		S3‑190299	EDT correction – length of HASHUE-data and HASHeNB-data	Ericsson	CR	Agreement	Yes	YesQualcomm: solution dependent? We may have to revisit this based on the solution we settle down on. Ericsson clarified that this was sent through the RAN nodes, not transferred over the air. The sentence needed rewording so it was taken offline.	revised	No	S3‑190455
		S3‑190455	EDT correction – length of HASHUE-data and HASHeNB-data	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑190299
		S3‑190300	EDT correction – input to calculation of shortResumeMAC-I	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑190301	EDT correction – clarification of NOTE about no-integrity protection for non-EDT data	Ericsson	CR	Agreement	Yes	YesHuawei didn’t agree with the CR.Ericsson could come back once the solution was defined.	not pursued	No
		S3‑190302	LS on EDT security	Ericsson	LS out	Approval	Yes	Yes	noted	No
7.5.11	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)
7.5.12	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.5.13	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)	S3‑190025	LS on OAuth authorization flows supported for Northbound APIs	C3-187660	LS in		Yes	Yes	replied to	No
		S3‑190452	Reply to: LS on OAuth authorization flows supported for Northbound APIs	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑190046	LS response on API invoker onboarding	S6-181848	LS in		Yes	Yes	noted	No
		S3‑190321	Editorial corrections in CAPIF TS	Ericsson	CR	Approval	Yes	Yes	agreed	No
7.5.14	PLMN RAT selection (Steering of Roaming) (Rel-15)	S3‑190100	Name correction of the Nudm_SDM_Notification service operation	Ericsson	CR	Agreement	Yes	Yes	agreed	No
7.5.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑190009	Discussion document on the changes required to BEST for the authentication available on the 5G options	Vodafone GmbH	discussion	Discussion	Yes	YesDeutsche Telekom: we support option one. Nokia: we are having a similar issue in the AKMA work item. We prefer to analyze both before making a decision. NEC supported Nokia. Option 2 could be studied in the scope of AKMA and option one was fine too. BT: we are losing the focus on the battery efficiency and going for key sharing instead. Vodafone proposed to reword the option 2 and include in the scope of the AKMA study with contributions. Option one would be the way to go.	noted	No
		S3‑190010	CR to 33.163 - Addition of HSE to NR core authentication interface	Vodafone GmbH	CR	Endorsement	No	Yes	withdrawn	Yes
		S3‑190024	LS on EAS-C&U support	C3-186313	LS in		Yes	YesVodafone rejected CT3's last comment on the protocol details. ORANGE: we have already an annex with these protocols and CT3 is going to talk about the same protocols with differences. We should avoid that. Vodafone: there is no requirement for the work they are doing. We need to point them out that.	replied to	No
		S3‑190453	Reply to: LS on EAS-C&U support	Vodafone	LS out	approval	Yes	Yes	approved	No
7.5.16	Other work items
7.6	New Work Item proposals	S3‑190011	draft WID for Addition of HSE to 5G core interface for authentication (if required)	Vodafone GmbH	WID new	Endorsement	No	Yes	withdrawn	Yes		S3‑183450
		S3‑190125	Discussion on providing AS security during RRC connection establishment to protect NSSAI	NEC Europe Ltd	discussion	Agreement	Yes	Yes	withdrawn	Yes
		S3‑190128	New WID on providing the encryption of slice identity at the AS layer during RRC connection establishment procedure	NEC Europe Ltd	WID new	Approval	Yes	YesNokia: SA3 and SA2 have agreed on a solution already. If a new solution is needed, it should be triggered in SA2 and not here. Ericsson agreed with this. NEC clarified that this was presented in SA2 and that they directed the discussions to SA3. Deustche Telekom supported this study. Vodafone: this is a study item, not a Work Item. NEC: it's a TR and CRs for the TS. Vodafone replied that wasn't the way of working. Supporting the study in Rel-16: NEC, Huawei,NIST,BT,KPN,Docomo,Intel,ARICC,T-Mobile. Not in Rel-16: Nokia. Qualcomm: key issue in the key authentication study that we already have. Huawei agreed with this. NTT-Docomo preferred to have a separate study. The Chair recommended to decrease the number of study items, for the sake of progress.	noted	No
		S3‑190343	Vertical - Discussion of WID for 5GS Vertical_LAN_SEC	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	YesNokia clarified that the document referred to Rel-16. Ericsson pointed out that if this was going for Rel-16 there was no such rush. Huawei, ORANGE commented that there was still time and the rush was not justified. Vodafone commented that the WID proposed was too general.	noted	No
		S3‑190344	WID proposal for 5GS Vertical_LAN_SEC	Nokia, Nokia Shanghai Bell	WID new	Agreement	Yes	Yes	noted	No
		S3‑190356	New WID on Security for NR Integrated Access and Backhaul	Samsung	WID new	Approval	Yes	Yes	revised	No	S3‑190442
		S3‑190442	New WID on Security for NR Integrated Access and Backhaul	Samsung	WID new	Agreement	Yes	YesIt was agreed to reformulate this as a SID.	revised	No	S3‑190460	S3‑190356
		S3‑190460	New SID on Security for NR Integrated Access and Backhaul	Samsung	SID new	Agreement	Yes	YesQualcomm proposed to start working on pCRs in the ad-hoc before the study was approved in SA.	agreed	No		S3‑190442
		S3‑190357	Security framework for the NR integrated access backhaul	Samsung	discussion	Decision	Yes	YesSamsung clarified that the work in RAN was in normative phase. The purpose was to create a draftCR that would eventually become a CR to 33.501. Vodafone didn’t agree with this style of work and preferred to have a Study Item. Samsung commented that the time scales were too limited to have both SID and WID. The Chair proposed to have a Study that could last for two meetings and then a Work Item to be sent for approval to SA together with the necessary CRs in one go. This was accepted.	noted	No
		S3‑190363	New WID on Enhancements for Security aspects of Common API Framework	Samsung, China Telecom, China Unicom, Nokia	WID new		Yes	YesSamsung clarified that SA6 had finished their work and that this WID would only need a single CR to be brought in the next meeting. Vodafone: there is a clear single solution for this? No other solutions to be studied? NTT-Docomo: we don’t need studies for all the CRs we make.	revised	No	S3‑190461
		S3‑190461	New WID on Enhancements for Security aspects of Common API Framework	Samsung, China Telecom, China Unicom, Nokia	WID new	-	Yes	Yes	agreed	No		S3‑190363
		S3‑190399	Discussion on providing AS security during RRC connection establishment to protect slice identity	NEC Corporation	discussion	Agreement	Yes	Yes	noted	No
8	Studies
8.1	Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)	S3‑190117	Update to Study Item Description FS_SBA_Sec: Enhanced-SBA aspects	Telekom Deutschland GmbH	SID revised	Approval	Yes	YesMCC commented that taking the Rel-15 study and expanding it for a study in Rel-16 looked a bit unusual. It was agreed to do it like this since the TR hadn’t been approved. MCC added that the document should take the original SID and add revision marks for the changes. Any discussion should be part of a different document.	revised	No	S3‑190464
		S3‑190464	Update to Study Item Description FS_SBA_Sec: Enhanced-SBA aspects	Telekom Deutschland GmbH	SID revised	Agreement	Yes	Yes	agreed	No		S3‑190117
		S3‑190105	Update to Study Item Description FS_SBA_Sec: Security for inter-PLMN user plane traffic (N9 reference point)	Ericsson, Juniper Networks, Deutsche Telekom AG	SID revised		Yes	Yes	merged	No	S3‑190464
		S3‑190367	Discussion paper on N9 firewall for inter-PLMN GTP-U filtering	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑190114	New Key Issue: Basic security requirements on SFSF message transport	Telekom Deutschland GmbH	pCR	Approval	Yes	Yes	noted	No
		S3‑190115	New Key Issue: Protection of SFSF interfaces	Telekom Deutschland GmbH	pCR	Approval	Yes	Yes	noted	No
		S3‑190119	Inter-PLMN N9 Security	Telekom Deutschland GmbH	discussion	Endorsement	Yes	YesBT: it's up to the study to decide whether this is to be performed by a "box". Ericsson: let's study this as a key issue. TIM: SBA architecture is for control plane interfaces. N9 is a user plane interface. How is N9 security related to SBA architecture and why is it treated inside this SID? NTT-Docomo replied that SBA architecture should be in one study and the N9 part in a new study,	noted	No
		S3‑190102	Update to Study Item Description FS_SBA_Sec: Security for inter-PLMN user plane traffic (N9 reference point)	Ericsson	SID revised	Approval	No	Yes	withdrawn	Yes
8.2	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)	S3‑190012	CR to 33.834 - implementation of changes requested by edithelp	Vodafone GmbH	CR	Endorsement	No	Yes	left for email approval	No
8.3	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)	S3‑190013	CR to 33.841 - implementation of requested by edithelp	Vodafone GmbH	CR	Endorsement	No	Yes	left for email approval	No
		S3‑190216	CR to TR 33.841 regarding key derivation function	China Mobile	CR		Yes	YesEricsson: the note is not clear. NCSC commented that this wasn’t necessary for the study, which is finished.	not pursued	No
8.4	Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
8.5	Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)	S3‑190166	Solution on privacy protection of SUPI	ZTE Corporation	pCR	Approval	Yes	YesVodafone: This assumes that we are only using GPM whereas AKMA's scope will be wider. BT: no distribution of private key here. Qualcomm: this solution adds nothing, it should be noted. Vodafone: the solution doesn’t meet the criteria.	noted	No
		S3‑190168	Resovle Editor's note in Solution for bootstrapping authentication of AKMA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑190169	Solution for Key freshness in AKMA	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone, ORANGE: the document is badly structured.You have a solution in mind, write the key issues properly. There was no support for this document.	noted	No
		S3‑190196	Roaming key issue for AKMA	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: why is the proxy needed? Huawei: it’s for the roaming. Qualcomm, Gemalto didn’t see the point for having a proxy either. Qualcomm: roaming needs to be supported, but we only need a description of the key issue to start with. Remove everything else and come back for the next meeting with the rest.	noted	No
		S3‑190527	Roaming key issue for AKMA	Huawei, HiSilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑190197	architecture solution for AKMA with non-standalone function	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: why mandating a specific authentication for the network in AKMA? Huawei: we want to reuse primary authentication.It's a general authentication procedure. ORANGE: this authentication is not needed. Vodafone: missing how the enterprise interacts with the system. Qualcomm: if you don’t want to use primary authentication describe it somewhere else. This is mixing primary authentication with Kusf authenticaiton. Vodafone: this is two different solutions mixed.	noted	No
		S3‑190213	New Key Issue on use of established keys for AKMA	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑190214	Solution for using established keys for AKMA	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑190558
		S3‑190558	Solution for using established keys for AKMA	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑190214
		S3‑190228	Proposed revision of solution 6	China Mobile,ZTE Corporation	pCR		Yes	YesORANGE: this is mixing two authentication procedures. ZTE agreed to separate them. ORANGE then commented that the authentication procedure looked strange. ORANGE didn’t see it clear that there were two procedures after all and couldn’t agree with the contribution. ZTE wanted to add an editor's note on the need for separating both procedures but this was rejected by ORANGE. It had to be taken offline.	noted	No
		S3‑190248	New key issue: Key revocation	Ericsson	pCR	Approval	Yes	YesVodafone: more requirements and definitions are needed.For example, who rebokes the application keys. ORANGE repplied that it was the network who revoked the keys. Qualcomm proposed to add an editor's note to procceed with the work during the next meeting.	revised	No	S3‑190528
		S3‑190528	New key issue: Key revocation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190248
		S3‑190249	Protocol clarifications to solution 2	Ericsson	pCR	Approval	Yes	YesVodafone: the third party application doesn’t seem represented. Ericsson: this is about the authentication procedure, bootstrapping, not about how the keys are used. Ericsson: this is purely used plane based. A copy of GBA making sure that it works in 5G. ORANGE: revocation of the keys in the UE needs to be clarified. It was agreed to add an editor's note stating the above.	revised	No	S3‑190529
		S3‑190529	Protocol clarifications to solution 2	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190249
		S3‑190250	Evaluation of solution 2	Ericsson	pCR	Approval	Yes	YesORANGE: key issues are still coming, having the evaluation is a bit premature. Qualcomm agreed.	noted	No
		S3‑190251	New solution:Key revocation	Ericsson	pCR	Approval	Yes	YesORANGE: remove the evaluation. Vodafone: consequences are not described in detail.	revised	No	S3‑190530
		S3‑190530	New solution:Key revocation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190251
		S3‑190252	New solution: Implicit Bootstrapping	Ericsson	pCR	Approval	Yes	YesNEC proposed to alter the order of some clauses. Ericsson: too early to decide the solution since there are still revocation aspects that need to be considered.	revised	No	S3‑190531
		S3‑190531	New solution: Implicit Bootstrapping	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190252
		S3‑190253	New solution: AKMA authentication via the control plane	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑190316	New solution - Battery efficient AKMA	KPN	pCR	Approval	Yes	Yes	not treated	No
		S3‑190326	New KI: Interworking between AKMA and GBA	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190350	Solution to KI#9 Key separation for AKMA AFs	NEC Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑190385	pCR: Reusing KAUSF for AKMA	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑190526	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‑190268	Proposal for content to introduction clause	Ericsson	pCR	Approval	Yes	YesHuawei: refer to SA2 with regards to architecture. References are wrong.Clash with 194. Vodafone: no clash with 194, really. Vodafone and TIM agreed to have this in the introduction.	revised	No	S3‑190470
		S3‑190470	Proposal for content to introduction clause	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190268
		S3‑190194	Clarifications CIOT security assumptions	Huawei, HiSilicon	pCR	Approval	Yes	YesVodafone: it's clearer to have the introducion of 268 instead of having it in here. ORANGE: why comparing it with EPS? Staet that the Ues shall follow 5G requirements. Huawei: we may miss solutions for IoT Ues that have EPS solutions (e.g. if they are redirected to EPS). ORANGE: if they are connected to 5G the Ues shall have security as strong as 5G.	revised	No	S3‑190473
		S3‑190473	Clarifications CIOT security assumptions	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190194
		S3‑190269	Proposal for content to clause 4	Ericsson	pCR	Approval	Yes	YesHuawei: reference SA2; it is also referring to things that SA2 hasn’t decided yet. Ericsson: SA2 concluded.	revised	No	S3‑190472
		S3‑190472	Proposal for content to clause 4	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190269
		S3‑190172	Address EN in Key Issue 4 of Definition of Misbehaving UE	Huawei, Hisilicon	pCR	Approval	Yes	YesNEC: the clause 8.8.1 in 23.791 does have nothing to do with the misbehaving UE. Vodafone preffered to have this moved to the Definitions clause. Qualcomm: we need to understand the definition of misbehaving UE in the context of CIoT. Huawei: we don’t want to define anything, just to use an existing definition.	revised	No	S3‑190474
		S3‑190474	Address EN in Key Issue 4 of Definition of Misbehaving UE	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190172
		S3‑190173	New Key Issue for NAS based Redirection between Core Networks	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: the key issue is the bidding attack. The anti-bidding down is the solution. NEC: this problem is not specific for IoT. NEC supported this. CableLabs supported having this threat. NTT-Docomo: What happens if there is no key negotiated, key wrong, etc? What’s there it is a solution specific requirement. Vodafone: there is nothing that says here what protection we have in the current system. Then explain why it could be unprotected.	revised	No	S3‑190475
		S3‑190475	New Key Issue for NAS based Redirection between Core Networks	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190173
		S3‑190270	A new key issue for privacy protection of new parameters for CIoT included in NAS messages	Ericsson	pCR	Approval	Yes	YesHuawei: wait for SA2 to have the parameters that need to be privacy protected. ORANGE: remove requirements, keep the key issue, analyze parameters as they come.	revised	No	S3‑190476
		S3‑190476	A new key issue for privacy protection of new parameters for CIoT included in NAS messages	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190270
		S3‑190314	New Key Issue: Subscription identifier exposure outside 3GPP network	Ericsson India Private Limited	pCR	Approval	Yes	YesZTE: the requirement is not clear, it's also a generic one not related to cIoT. There is a requirement in 33.501 for the AMF already. Vodafone supported this. Ericsson: there is no requirement with the NIDD API involved.	noted	No
		S3‑190208	Evaluation text for solution #2	NEC Corporation	pCR	Approval	Yes	YesVodafone: we are still adding key issues. Will you update this when new key issues will be added? NEC: this is the evaluation for a specific solution from last meeting. KPN: this looks like an evaluation for all key issues, this is very generic. Vodafone: editor's note on adding an evaluation for future key issues.	revised	No	S3‑190479
		S3‑190479	Evaluation text for solution #2	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑190208
		S3‑190265	Updates to Solution #3: Security solution for MO SMS at AMF re-allocation	Ericsson	pCR	Approval	Yes	YesHuawei: add an editor's note on why this assumption is made in the solution. Qualcomm supported this. Ericsson: this is an editor's note on existing text. Bring it with a contribution. Huawei commented that it was impacted by the new text.	revised	No	S3‑190480
		S3‑190480	Updates to Solution #3: Security solution for MO SMS at AMF re-allocation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190265
		S3‑190077	Update Solution #4 to use HASHUE-data as in TS33.401	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑190266	Updates to Solution #5: Security solution for small data included in initial NAS signalling at mobility	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑190481
		S3‑190481	Updates to Solution #5: Security solution for small data included in initial NAS signalling at mobility	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190266
		S3‑190195	CIOT solution 6 improvement	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑190074	Details of protecting gNB from RRC DoS attack	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: no drawbacks at all in the evaluation, impacts and no sales pitch. Not clear which key issue is being evaluated.	revised	No	S3‑190482
		S3‑190482	Details of protecting gNB from RRC DoS attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190074
		S3‑190075	Resolving Editor’s Note for solution #7 (clause 6.7)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑190382	Solution for small data at idle mode mobility	Qualcomm Incorporated	pCR	Approval	Yes	YesVodafone: solution details are not really detailed. It was agreed to add an editor's note to add more details in the future.	revised	No	S3‑190483
		S3‑190483	Solution for small data at idle mode mobility	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑190382
		S3‑190368	Protecting small data at idle mobility using the Registration Complete message	Qualcomm Incorporated	pCR	Approval	Yes	YesEricsson: not aligned with SA2 procedure on data delivery. Qualcomm: SA2 is consulting CT1 on this issue. NEC: this issue needs to be discussed in SA2. Vodafone: this is a study. No point to discuss with SA2 until it is selected. The comment should be part of the evaluation of the solution. Huawei agreed, since this was part of the usual process performed in SA3. It was agreed to add an editor's note.	revised	No	S3‑190484
		S3‑190484	Protecting small data at idle mobility using the Registration Complete message	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑190368
		S3‑190171	New Solution Security-Property-Group-based Mitigation for DDoS Attack Triggered by Malicious Applications on the UE	Huawei, Hisilicon	pCR	Approval	Yes	YesJuniper: this is an operational issue for operators. It should be treated outside security.Qualcomm agreed with Juniper; it's application level. Alf (NTT-Docomo): not advisable to have standardised these kind of mechanisms since it would be too exposed to the public. It was agreed to add two editor's notes. Qualcomm suggested the need for discussion papers justifying why these kind of solutions should be justified. ORANGE: editor's note on investigating whether this solutions brings new DoS attacks.	revised	No	S3‑190485
		S3‑190485	New Solution Security-Property-Group-based Mitigation for DDoS Attack Triggered by Malicious Applications on the UE	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190171
		S3‑190187	Solution for DDoS attack mitigation in CIoT	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: editor's note on how this filter is determined. This was agreed.	revised	No	S3‑190486
		S3‑190486	Solution for DDoS attack mitigation in CIoT	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190187
		S3‑190308	Solution for Key Issue #7: Key refreshing for protection of small data	Lenovo, Motorla Mobility	pCR	Approval	Yes	Yes	revised	No	S3‑190488
		S3‑190488	Solution for Key Issue #7: Key refreshing for protection of small data	Lenovo, Motorla Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑190308
		S3‑190271	Solution for privacy protection of new parameters for CIoT included in NAS messages	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑190170	New Conclusion for Small Data Transfer via NAS Signaling	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: too premature for having conclusions. We still have lot of new key issues. Nokia supported Huawei in order to make progress and not delay anything. Ericsson: we should have a conclusion for each key issue as SA2 is doing.	revised	No	S3‑190489
		S3‑190489	New Conclusion for Small Data Transfer via NAS Signaling	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190170
		S3‑190330	Conclusion for Key Issue #9	Ericsson	pCR		Yes	YesVodafone: we changed some of the aspects related to this. We should finish the key issues before concluding the study. Huawei: SA2 also concluded this topic.	revised	No	S3‑190490
		S3‑190490	Conclusion for Key Issue #9	Ericsson	pCR	-	Yes	Yes	approved	No		S3‑190330
		S3‑190267	Potential new security impact in Rel-16 for the selected CIoT solutions in SA2 TR 23.724	Ericsson	pCR	Approval	Yes	YesHuawei didn’t see the need for having this in the TR. ORANGE agreed with Huawei.	noted	No
		S3‑190064	Details of protecting gNB from RRC DoS attack	HUAWEI TECH. GmbH	pCR		No	Yes	withdrawn	Yes
		S3‑190111	Evaluation text for solution #2	NEC Corporation	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑190471	Draft TR 33.861	Ericsson	draft TR	Approval	Yes	Yes	approved	No
		S3‑190491	Cover sheet TR 33.861	Ericsson	TS or TR cover	Approval	Yes	YesThe TR will be sent for information.	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‑190030	Response to 3GPP SA2 liaison S2-1810989 on ‘Reply LS on devices behind 5G-RG accessing the 5GC’	BBF	LS in		Yes	Yes	noted	No
		S3‑190028	Response to 3GPP SA2 liaison S2-189038 on ‘general status of work’	BBF	LS in		Yes	Yes	noted	No
		S3‑190029	Response to 3GPP SA2 liaison S2-1811575 on ‘general status of work’	BBF	LS in		Yes	Yes	noted	No
		S3‑190043	Reply LS on FS_5WWC conclusion of study work	S2-1812643	LS in		Yes	Yes	noted	No
		S3‑190031	Response to 3GPP SA2 liaison S2-1812643	BBF	LS in		Yes	Yes	noted	No
		S3‑190032	Response to 3GPP SA2 on FN-RG authentication	BBF	LS in		Yes	Yes	replied to	No
		S3‑190041	Reply LS on FN-RG authentication and related questions	S2-1812601	LS in		Yes	Yes	replied to	No
		S3‑190081	Reply-LS on FN-RG authentication and related questions	Ericsson	LS out	Approval	Yes	Yes	revised	No	S3‑190518
		S3‑190518	Reply-LS on FN-RG authentication and related questions	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑190081
		S3‑190082	Reply-LS on FN-RG authentication and related questions	Ericsson	LS out	Approval	Yes	YesORANGE: SA2 should not assume solutions before consulting SA3 on the security feasibility of these solutions. Huawei: we agree on roaming scenarios but we don’t have solutions yet. Ericsson: progress is easier by answering LS.	merged	No	S3‑190518
		S3‑190040	LS on Authentication for UEs not Supporting NAS	S2-1812600	LS in		Yes	YesVodafone: non-5G-capable over WLAN UE has nothing to do with us. ORANGE didn't agree with the solutions shown here. Vodafone: why they talk about primary authentication if we have settled on having secondary authentication here? Lenovo: we have LTE over WLAN case when you could access the core network without USIM. In this case you are a subscriber of the core network, no roaming scenarios considered. We don’t see any issue if this is under control of the network operator. ORANGE: there is an LI issue. Who's liable? The owner of the UE or the WLAN owner? There is no point in asking for anything different from EAP' . Vodafone: You must have the USIM if you want to do the primary authentication. Gemalto supported Vodafone and ORANGE. The proposal by ORANGE was to tell SA2 to reuse the procedure in TS 33.501 for EAP' for primary authentication, and credential storage as detailed in the same spec. Samsung: ask SA2 about what kind of UE they are talking about.	replied to	No
		S3‑190305	Response LS on Authentication for UEs not Supporting NAS	Lenovo (Beijing) Ltd	LS out		Yes	Yes	revised	No	S3‑190519
		S3‑190519	Response LS on Authentication for UEs not Supporting NAS	Lenovo (Beijing) Ltd	LS out	-	Yes	Yes	approved	No		S3‑190305
		S3‑190328	Key Issue on security of the Tn interface between TNGFs	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesNokia: the scope of thi study is the Tn interface. ORANGE: generalise this since it refers to a SA2 key issue. SA2 conclusions needed to be checked offline.	noted	No
		S3‑190320	Key Issue on NAS termination in TWIF	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson: no need to use NAS security here, you can rely on transport security. Add it to existing key issue 6. Nokia: we can just remove the requirements. This was agreed. ORANGE: generalise this since it refers to a key issue from the SA2 TR.	revised	No	S3‑190520
		S3‑190520	Key Issue on NAS termination in TWIF	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑190320
		S3‑190324	Key Issue on security of TNGF mobility using EAP Reauthentication Protocol (ERP)	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑190080	New key issue: TNAP mobility for trusted non-3GPP access	Ericsson	pCR	Approval	Yes	YesORANGE: less key issues and more solutions.	noted	No
		S3‑190329	Key Issue on access to 5GC from non-3GPP device over Trusted WLAN	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE: this has been considered in our LS to SA2. Huawei: non-3GPP device and non 5G capable device; What's the difference? We need to be consistent with the terminology in the future.	noted	No
		S3‑190331	pCR to Solution #1 to include child SA creation for user plane data protection	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑190306	Solution for 5GC access from WLAN UEs that do not support NAS	Motorola Mobility, Lenovo	pCR	Approval	Yes	YesDeutsche Telekom: we need to modify this according to our LS reply to SA2. ORANGE: SUCI is enough for 3GPP credentials.	merged	No	S3‑190507
		S3‑190333	Access to 5GC via Trusted WLAN for UEs w/o NAS support	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesTIM: this is pointing wrongly to annex B of 33.501. This type of networks are not mentioned in there. It was agreed to remove the reference to annex B.	revised	No	S3‑190507
		S3‑190507	Solution for 5GC access from WLAN UEs that do not support NAS	Nokia, Lenovo	pCR	Approval	Yes	Yes	approved	No		S3‑190333
		S3‑190179	Add requirement to KI#2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑190079	New key issue: Protection of Line ID	Ericsson	pCR	Approval	Yes	YesThreats and requirements go out, key issues are merged.	merged	No
		S3‑190322	Key Issue on SUCI format for legacy FN-RG devices that access 5G over wireline network	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑190522
		S3‑190522	Key Issue on SUCI format for legacy FN-RG devices that access 5G over wireline network	Nokia, Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190322
		S3‑190325	Key Issue on NAS termination for registered FN-RGs	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesHuawei: solution specific requirement.ORANGE proposed to keep it solution specific since it was the base for normative work.	revised	No	S3‑190523
		S3‑190523	Key Issue on NAS termination for registered FN-RGs	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑190325
		S3‑190323	Key Issue on Authorization of IPTV subsystem	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson: this is already addressed in 33.501 in clause 12. There is no normative work needed for this, note it.	noted	No
		S3‑190319	Key Issue on access to 5GC from a non-3GPP device over Wireline 5G Cable Access Network	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑190180	A new KI on the trust of W-5GAN	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson, ORANGE: this is not needed.	noted	No
		S3‑190332	FN-RG registration to 5GC	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑190506
		S3‑190506	FN-RG registration to 5GC	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesAdding an editor's note.	approved	No		S3‑190332
		S3‑190334	5G-RG connecting to 5GC via Wireline Access (W-5GAN)	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑190524
		S3‑190524	5G-RG connecting to 5GC via Wireline Access (W-5GAN)	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑190334
		S3‑190335	5G-RG connecting to 5GC via NG-RAN	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑190525
		S3‑190525	5G-RG connecting to 5GC via NG-RAN	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑190335
		S3‑190181	Add evaulation to sloutlion 3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑190182	add conclusion clauses	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: we don’t have conclusions yet. Huawei: but we will. ORANGE: just keep the Key Issue X.	approved	No
		S3‑190183	Add conclusion to KI#1	Huawei,Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑190521	Draft TR 33.807	Huawei	draft TR	Approval	Yes	Yes	approved	No
8.8	Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)	S3‑190130	Security Requirement for Key issue 2	Intel Deutschland GmbH	pCR		Yes	YesBT: EPC instead of EPS. Ericsson: impact on ME is considerable. Qualcomm: this is driving to a solution.	noted	No
		S3‑190131	EPC solution for RLOS access	Intel Deutschland GmbH	pCR		Yes	YesVodafone: does PARLOS work for roaming customers? Sprint replied that it was an accepted option. Nobody seemed to agree on this contribution so it was noted.	noted	No
		S3‑190145	Editorial pCR for PARLOS TR 33.815	LG Electronics	pCR	Approval	Yes	Yes	revised	No	S3‑190466
		S3‑190466	Editorial pCR for PARLOS TR 33.815	LG Electronics	pCR	Approval	Yes	Yes	approved	No		S3‑190145
		S3‑190364	P-CR for PARLOS evaluation clause	SPRINT Corporation	pCR	Agreement	Yes	Yes	noted	No
		S3‑190469	P-CR for PARLOS evaluation clause	SPRINT Corporation	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑190377	Solution for PARLOS based on emergency call procedures	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑190468
		S3‑190468	Solution for PARLOS based on emergency call procedures	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑190377
		S3‑190389	P-CR for editors note in PARLOS manual roaming clause	SPRINT Corporation	pCR	Agreement	Yes	Yes	approved	No
		S3‑190390	PARLOS TR cover sheet for plenary presentation	SPRINT Corporation	TS or TR cover	Agreement	Yes	YesVodafone: it seems to be really early-on for sending it for information. There are missing key issues. ORANGE: no evaluations, key issues without requirements,..this not ready for presentation for information. Sprint: we can mention these open key issues as outstanding issues. ORANGE: this is not 60% ready. BT: one region's regulatory issue should not affect all the handsets in the rest of the countries. I would like to see that in the evaluation.	noted	No
		S3‑190391	Removal of editor’s note in solution #1	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesEricsson didn't agree with the changes.No one agreed with the change so the document was noted.	noted	No
		S3‑190467	Draft TR 33.815	Sprint	draft TR	Approval	Yes	Yes	approved	No
8.9	Study on 5G security enhancement against false base stations	S3‑190067	Adding Security Protection Requirement of Unicast RRC Messges	Huawei, Hisilicon	pCR	Approval	Yes	YesCompared with 275.	noted	No
		S3‑190141	requirement of protection of unicast messages	Apple (UK) Limited	pCR	Approval	Yes	Yes	noted	No
		S3‑190359	Requirement on security of unprotected unicast messages	Samsung	pCR		Yes	Yes	revised	No	S3‑190553
		S3‑190553	Requirement on security of unprotected unicast messages	Samsung	pCR	-	Yes	Yes	approved	No		S3‑190359
		S3‑190274	KI#1 in TR 33.809 – a new NOTE for requirements	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑190275	KI#1 in TR 33.809 – new requirement and solution for UECapabilityInformation RRC message	Ericsson	pCR	Approval	Yes	YesThe requirement was agreed.The solution had to be discussed separately.	revised	No	S3‑190554
		S3‑190554	KI#1 in TR 33.809 – new requirement and solution for UECapabilityInformation RRC message	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190275
		S3‑190276	KI#1 in TR 33.809 – new requirement and solution for RRC Reject message	Ericsson	pCR	Approval	Yes	YesDocomo preferred 359. The requirement was removed.	noted	No
		S3‑190068	Security Solution for RRC UE capability transfer	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑190360	Solution on security of RRC Reject messages	Samsung	pCR		Yes	Yes	revised	No	S3‑190555
		S3‑190555	Solution on security of RRC Reject messages	Samsung	pCR	-	Yes	Yes	approved	No		S3‑190360
		S3‑190069	Security Requirement for Paging Messges	Huawei, Hisilicon	pCR	Approval	Yes	YesApple: requirement should be more general. Ericsson: protection of paging in a separate key issue should be in a separate key issue.	noted	No
		S3‑190139	requirement of protection of broadcast messages	Apple (UK) Limited	pCR	Approval	Yes	Yes	noted	No
		S3‑190273	KI#2 in TR 33.809 – new requirement and solution for non-public networks	Ericsson	pCR	Approval	Yes	YesQualcomm was against this contribution. No other support was found.	noted	No
		S3‑190361	Requirement on security of unprotected unicast messages	Samsung	pCR		Yes	Yes	approved	No
		S3‑190070	Protection for Incoming Paging Message Based on Stored Security Context	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑190146	ID-based solution in 5GFBS	Apple (UK) Limited	pCR	Approval	Yes	Yes	noted	No
		S3‑190147	Credential-based solution in 5GFBS	Apple (UK) Limited	pCR	Approval	Yes	YesORANGE was against these solutions. Qualcomm: we studied those kind of solutions in PWS. Ericsson: it's important to capture this and the scalability issues. ORANGE: don’t repeat the same evaluations from other TRs. Apple: why are we doing a study if we are killing all solutions?	noted	No
		S3‑190155	Anti fake base station based on symmetric algorithm	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑190353	New solution for protecting the System Information Block	NEC Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑190362	Solution for AS security during RRC Idle mode	Samsung	pCR		Yes	Yes	noted	No
		S3‑190351	Updating key issue#3 for network detection of nearby fake base station	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑190532
		S3‑190532	Updating key issue#3 for network detection of nearby fake base station	NEC Corporation	pCR	Approval	Yes	Yes	not treated	No		S3‑190351
		S3‑190277	KI#3 in TR 33.809 – updates to requriements and editorials	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190279	KI#3 in TR 33.809 – conclusion on second requirement (reactive action)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190071	Avoiding UE connecting to fake base station during HO	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑190278	KI#3 in TR 33.809 – new solution for enriched measurement reports	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190352	New solution for preventing UE from attaching to a false base station	NEC Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑190245	New requirment for Authentication relay attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑190127	Key Issue for Fake Base Station	Intel Deutschland GmbH	pCR		Yes	Yes	not treated	No
		S3‑190381	Key Issue MITM attacks	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑190062	Adding Security Protection Requirement of Unicast RRC Messges	HUAWEI TECH. GmbH	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑190063	Security Solution for RRC UE capability transfer	HUAWEI TECH. GmbH	pCR		No	Yes	withdrawn	Yes
		S3‑190148	Key issue of network credential revocation consideration	Apple (UK) Limited	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑190552	Draft TR 33.809	Apple	draft TR	Agreement	Yes	Yes	approved	No
8.10	Study of KDF negotiation for 5G System Security	S3‑190211	Discussion on Requirement for KDF Negotiation	NEC Corporation, Huawei, Hisilicon	discussion	Discussion	Yes	YesORANGE: premature to have this proposal. It was noted that the document was sent for discussion and not for endorsement.	noted	No
		S3‑190212	Update to clause 4 to add KDF negotiation rationale	NEC Corporation, Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: geopolitics and cost issues are not true.They didn’t agree with the preferences of UE vendors either. Qualcomm: we cannot agree with this document. Too premature. KDF negotiation is needed in 5G. That's the only point we need now. ORANGE supported Ericsson and Qualcomm. ORANGE didn’t agree with anything in this contribution. NEC: this is just a rational clause for the study item, not a key issue. Colin (BT): Where are the KDFs and what's the impact on the operators? Vodafone: can only accept he paragraph on the future proofness. It looked like companies preferred a much shorter rational. This was taken offline.	revised	No	S3‑190517
		S3‑190517	Update to clause 4 to add KDF negotiation rationale	NEC Corporation, Huawei, Hisilicon	pCR	Approval	Yes	YesThe purpose of the study was argued. The Chair proposed to have conference calls before the next meeting given the disagreement between the companies. Huawei proposed to close the study and move forward. NTT-Docomo commented that this was an old topic and to avoid having it coming back at least a rational should be written.	noted	No		S3‑190212
8.11	Study on Security aspects of Enhancement of Network Slicing	S3‑190045	LS On Slice-Specific Secondary Authentication	S2-1813359	LS in		Yes	YesHuawei: not urgent to send it during this meeting. Timer is defined in CT1 and would rather wait for CT1's reply. Not sure that there are security issues. Ericsson: We don’t support the SA2 solution, let's wait and analize this. CableLabs: timer can be manipulated, let's discuss this and wait for CT1's reply. Interdigital: SA3 doesn’t see any security issues, we can reply with that. Nokia: ask CT1 if they can manage a flexible timer. It was decided to postpone it for the next meeting.	postponed	No
		S3‑190132	Discussion on SA2 LS on Slice Specific Authentication S2-1813359	Nokia, Nokia Shanghai-Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑190133	Solution for Slice Specific secondary authentication	Nokia, Nokia Shangahi Bell	pCR	Approval	Yes	YesORANGE wanted to question the SA2 solution (dependency of primary and secondary authentication) from SA3 perspective, by adding an editor's note. TIM commented that secondary authentication was not related to the slice concept. The slice is inside the core network and does have nothing to do with the secondary authentication as SA3 had agreed. We need to agree on the correct terminology. Slice secondary authentication would be the terminology to follow instead of secondary authentication. Interdigital: nested authentication is an open issue between SA2 and CT1. Add an editor's note about this. ORANGE: remove the evaluation, too early.	revised	No	S3‑190533
		S3‑190533	Solution for Slice Specific secondary authentication	Nokia, Nokia Shangahi Bell	pCR	Approval	Yes	Yes	approved	No		S3‑190133
		S3‑190202	A solution to slice authentication	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: step 5 is slice registration complete. Add step 6.An editor's note was agreed, step one revised as well. Interdigital: this is still a nested approach and it needs waiting for SA2 and CT1's discussions.	revised	No	S3‑190534
		S3‑190534	A solution to slice authentication	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190202
		S3‑190156	Solution on registration for mutual exclusive slices	ZTE Corporation	pCR	Approval	Yes	YesORANGE, TIM didn’t understand the contrbution. BT didn’t see the requirement forthis. For this reason the document was noted.	noted	No
		S3‑190272	Solution for key separation based on slice authentication keys	Ericsson	pCR	Approval	Yes	YesOverlapping with 204.	noted	No
		S3‑190206	Security threats and requirement for KI #4	Huawei, HiSilicon	pCR	Approval	Yes	YesDeutsche Telekom: privacy doesn’t leak, but user sensitive information. NTT-Docomo, NEC: against whom are we protecting? Editor's note was added to that effect.	revised	No	S3‑190535
		S3‑190535	Security threats and requirement for KI #4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190206
		S3‑190477	A new KI on NSSAI protection	Huawei, HiSilicon,NEC,Interdigital	pCR	Approval	Yes	YesNokia: there are implications on the study item if we procceed with this. ORANGE clarified that NEC had a study item on this (tdoc 128) and we had agreed on adding the objectives into a key issue here. ORANGE wasn't fine with the requirements since they were out of scope of the study item. MCC commented that it seemed a bit strange to enumerate objectives and open issues for Rel-16 in the key issue details.The format of these key issue details was to be revised. Qualcomm: last requirement doesn't make sense. It was agreed to remove it.	revised	No	S3‑190536	S3‑190203
		S3‑190536	A new KI on NSSAI protection	Huawei, HiSilicon,NEC,Interdigital	pCR	Approval	Yes	Yes	approved	No		S3‑190477
		S3‑190204	Solutions to AMF key separation	Huawei, HiSilicon	pCR	Approval	Yes	YesOrange: second solution is not related to this study item. NCSC didn't support this either as it was introducing a new solution that should be assesed agains quantum computing. Nokia didn't support it either.	noted	No
		S3‑190205	A solution to security features for NSaaS	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE: why defining these security features at all here? I don’t want his table. BT, CableLabs: network slices hould have their own invocable security features according to policy. ORANGE: we only introduce secondary authentication in TS33.501, there is no other security feature added for them. TIM: how is the secondary authentication intended here? ORANGE clarified that it referred to the slice authentication.	revised	No	S3‑190537
		S3‑190537	A solution to security features for NSaaS	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190205
		S3‑190230	A key issue: Slice-specific Security in roaming	China Mobile	pCR		Yes	YesBT: What is the difference with the non-slicing scenario? This is not slice specific. ORANGE: have this as a key issue in the SBA study.	noted	No
		S3‑190237	New KI: SUPI privacy protection across different security domains	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: why sending the SUPI to the slice? Huawei: according to SA2 several network functions can be deployed in the slice, so it is necessary in some cases to send the SUPI. Nokia: additional protection for SUPI? They are already protected. DT: we need a new mechanism to send the SUPI to third parties. ORANGE wasn't sure that SA2 could see the SUPI, and if that was the case SA3 should tell them not to do that. Alf (NTT-Docomo: SUPI shall not be available outside the operator's network. BT: struggling to see this slice specific.	noted	No
		S3‑190318	New KI: Access token handling between network slices	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑190538	S3‑190239
		S3‑190538	New KI: Access token handling between network slices	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190318
		S3‑190203	A new KI on NSSAI protection	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑190477
		S3‑190239	New KI: Access token handling between network slices	Huawei Technologies Sweden AB	pCR	Approval	Yes	Yes	revised	No	S3‑190318
		S3‑190539	Draft TR 33.813	Nokia	draft TR	Approval	Yes	Yes	approved	No
8.12	Study on Security of the enhancement to the 5GC location services	S3‑190088	Resubmission of S3-183526 “WLAN positioning - new KI for the upcoming TR on FS_eLCS_Sec”	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑190236	pCR to TR33.814 - Key issue for end-to-end LCS data security	CATT	pCR	Approval	Yes	Yes	not treated	No
		S3‑190242	pCR to TR33.814 - Key issue for broadcast assistance data security	CATT	pCR	Approval	Yes	Yes	not treated	No
		S3‑190184	Key Issue for encryption and integrity protection of assistance data	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑190185	Key Issue for encryption and integrity protection of location data	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑190186	Key Issue for integrity protection of privacy setting between UE and home network	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑190246	pCR to TR33.814 - Solution of provisioning keys for broadcast assistant data protection	CATT	pCR	Approval	Yes	Yes	not treated	No
		S3‑190247	pCR to TR33.814 - Solution of ciphering algorithms	CATT	pCR	Approval	Yes	Yes	not treated	No
		S3‑190086	New solution: WLAN measurements from UEs	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190087	New solution: Bluetooth measurements from UEs	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190188	Solution for integrity protection of privacy setting between UE and UDM	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑190562	Draft TR 33.814	CATT	draft TR	Approval	Yes	Yes	approved	No
8.13	Study on security for 5G URLLC	S3‑190157	Key issue for acceleration of AKA procedure for low latency	ZTE Corporation	pCR	Approval	Yes	YesVodafone: this is more a solution. ORANGE didn’t agree with the requirement. New editor's note added.	revised	No	S3‑190541
		S3‑190541	Key issue for acceleration of AKA procedure for low latency	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑190157
		S3‑190349	New KI on Supporting low latency during Re-attach procedure	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑190542
		S3‑190542	New KI on Supporting low latency during Re-attach procedure	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑190349
		S3‑190158	Solution on enhancement of handover with direct Xn tunnel for single user plan path	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑190286	Update to KI#3 or KI#4 taking Dual Connectivity into considerations	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑190543
		S3‑190543	Update to KI#3 or KI#4 taking Dual Connectivity into considerations	Ericsson	pCR	Approval	Yes	YesLast paragraph removed as proposed by Huawei.	approved	No		S3‑190286
		S3‑190348	New Solution for Redundant data protection	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑190545
		S3‑190545	New Solution for Redundant data protection	NEC Corporation,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑190348
		S3‑190199	URLLC solution for Key Issue 1	Huawei, HiSilicon	pCR	Approval	Yes	YesOption 2 is merged into 545.	merged	No	S3‑190545
		S3‑190200	URLLC solution for Key Issue 3	Huawei, HiSilicon	pCR	Approval	Yes	YesVodafone: how do they satisfy LI requirements? Ericsson: there are no LI issues.	revised	No	S3‑190546
		S3‑190546	URLLC solution for Key Issue 3	Huawei, HiSilicon	pCR	Approval	Yes	YesAdding two editor's notes.	approved	No		S3‑190200
		S3‑190238	Dynamic UP security policy control solution for URLLC	Huawei, HiSilicon	pCR		Yes	YesVodafone: solution details need rewriting. Ericsson: PCF issue is not clear here.	noted	No
		S3‑190287	Evaluation to solution #1 and conclusion to key issue #3	Ericsson	pCR	Approval	Yes	YesHuawei: remove the conclusion.This was agreed.	revised	No	S3‑190547
		S3‑190547	Evaluation to solution #1 and conclusion to key issue #3	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190287
		S3‑190288	Evaluation on solution #2 and conclusion to key issue #3	Ericsson	pCR	Approval	Yes	YesSame as the one above.	revised	No	S3‑190548
		S3‑190548	Evaluation on solution #2 and conclusion to key issue #3	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190288
		S3‑190198	URLLC solution for N3 tunnel redundancy	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson: Redundace of N9 tunnel needs more clarification. Ericsson: there is no key issue for the backhaul interface, which is being addressed here in the N3 interface.	revised	No	S3‑190549
		S3‑190549	URLLC solution for N3 tunnel redundancy	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190198
		S3‑190544	Draft TR 33.825	Huawei	draft TR	Approval	Yes	Yes	approved	No
8.14	Study on SECAM and SCAS for 3GPP virtualized network products	S3‑190207	Considerations on network product class when using NFV technology	China Mobile, ZTE Corporation, Nokia, Nokia Shanghai Bell	pCR		Yes	Yes	not treated	No
		S3‑190215	Considerations on SECAM of the virtualized network products	China Mobile, ZTE Corporation, Nokia, Nokia Shanghai Bell	pCR		Yes	Yes	not treated	No
8.15	Study on Security for 5GS Enhanced support of Vertical and LAN Services	S3‑190104	Update to KI#2.1 in TR 33.819	InterDigital Europe. Ltd.	pCR	Approval	Yes	Yes	noted	No
		S3‑190304	Update on Key issue #2.1	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: is this the right conclusion in sA2? This was confirmed.	approved	No
		S3‑190241	Solution for NPN network access via PLMN	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: why not use SA2's conclusion on this? There is no security problem here.	revised	No	S3‑190493
		S3‑190493	Solution for NPN network access via PLMN	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑190241
		S3‑190291	TR 33.819: new key issue on security and privacy aspects of service continuity and session continuity	Ericsson	pCR	Approval	Yes	YesNokia: session and service continuity are requirements in SA2. This is a very vague requirement. Key issue is valid. NTT-Docomo: security threats need to be more concrete.	revised	No	S3‑190494
		S3‑190494	TR 33.819: new key issue on security and privacy aspects of service continuity and session continuity	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190291
		S3‑190366	Key issue on Multiple and Separate credentials for PLMN and NPN network	Samsung	pCR		Yes	Yes	revised	No	S3‑190495
		S3‑190495	Key issue on Multiple and Separate credentials for PLMN and NPN network	Samsung	pCR	-	Yes	Yes	approved	No		S3‑190366
		S3‑190346	New KI on Privacy aspects for NPN	NEC Corporation	pCR	Approval	Yes	YesORANGE: last requirement not in the scope of SA3. First requirement covered by the previous contribution. Nokia: second requirement is too strong formulated. The operator can decide whether they can apply privacy or not (e.g. depending on regulator rules). It was also commented that the second requirement was already covered in 33.501. The general agreement was that all requirements covered in TS 33.501 will not be covered here as well. No repetition of work.	noted	No
		S3‑190347	New Solution on Privacy aspects for NPN	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑190243	New KI: Isolation of multiple NAS connections	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE objected to this document.	noted	No
		S3‑190189	Key Issue for protection against DDoS attack	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: why mandate the NPN to support anything? The first requirement needs rewording anyway. Nokia: does the Denial of Service a key issue need to be addressed at all? Qualcomm: this key issue is not needed.	noted	No
		S3‑190190	Security Solution for DDoS attack mitigation in the roaming scenarios between NPN and PLMN	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑190370	Proposed key issue on key hierarchy for non-public networks	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑190496
		S3‑190496	Proposed key issue on key hierarchy for non-public networks	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑190370
		S3‑190336	Vertical - Key Issue on Authentication of a UE for Non-public network	Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, CableLabs	pCR	Approval	Yes	YesORANGE: how is this different from Rel-15? There is no issue here. IDEMIA: How to protect non-3GPP credentials is not available for us. Huawei: there is no SA1 requirement for non-public networks having to use UICC. IDEMIA: it's up to us to decide. Vodafone: UICC are irrelevant, we talk about USIM in our specs. ORANGE: NPN are 5G networks, hence the UICC is needed. NEC was fine with this contribution. DT,ORANGE, TIM and Vodafone didn’t support this contribution. Qualcomm: NPN operators may or may not USIMs. ORANGE replied that this wasn’t part of the contribution and should be brought separately. Vodafone: with no USIM we will have problems to connect to the network. Nokia: we have a SA1 requirement that cannot be fulfilled by 33.501.	noted	No
		S3‑190338	Vertical - Requirements to Key Issue on Authentication of a UE for Non-public network	Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, CableLabs	pCR	Approval	Yes	YesORANGE: no need to have these definitions in the potential security requirements clause. Gemalto also disagreed with this contributions. Vodafone wanted to remove note 1. Gemalto also disagreed since it implied that the the credentials were stored in the device. The Chair saw very strong support towards removing note one and very little possibility of having a compromise for this note. DT: closed access groups should strongly and properly authenticated, not as it appears in note 2. Nokia argued that the disagreement of this contribution endangered the future normative work, but ORANGE replied that the study didn’t depend entirely on this issue.	noted	No
		S3‑190339	Vertical - solution on EAP authentication framework	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE didn’t agree with this contribution. Gemalto,TIM and IDEMIA supported ORANGE. It’s already covered in TS 33.501 in an informative annex. Nokia: then we should reword it in TS 33.501. Contribution supported by Samsung. Vodafone: the solution is not described well.	noted	No
		S3‑190340	Vertical - solution on EAP-TLS	Nokia, Nokia Shanghai Bell, CableLabs	pCR	Approval	Yes	YesVodafone: solution is not described well enough. ORANGE: this is more a requirement, not a solution. Why are we mandating TLS? No other options?	noted	No
		S3‑190341	Vertical - solution on EAP-TTLS	Nokia, Nokia Shanghai Bell, CableLabs	pCR	Approval	Yes	YesThe Chair argued that this study needed more offline discussions, probably conference calls. ORANGE replied that the study was not based on authentication only. Vodafone: we don’t need to specify the methods used.	noted	No
		S3‑190337	Vertical - Key Issue on credential storage for Non-public network	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑190369	Proposed key issue on binding key to network identity for standalone non-public networks	Qualcomm Incorporated	pCR	Approval	Yes	YesORANGE: the security threat is not clear enough. Remove it with the requirements.	revised	No	S3‑190497
		S3‑190497	Proposed key issue on binding key to network identity for standalone non-public networks	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑190369
		S3‑190371	Proposed solution on binding key to network identity for standalone non-public networks	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑190342	Vertical - Conclusion on authentication	Nokia, Nokia Shanghai Bell, CableLabs	pCR	Approval	Yes	Yes	noted	No
		S3‑190289	New key issue on UP security policy for the 5GLAN Group	Ericsson	pCR	Approval	Yes	YesHuawei didn't agree with the example. The requirement was reworded to state "a" 5GLAN group instead of "the".	revised	No	S3‑190498
		S3‑190498	New key issue on UP security policy for the 5GLAN Group	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190289
		S3‑190290	New security solution for handling UP security policy for a 5GLAN Group	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑190499
		S3‑190499	New security solution for handling UP security policy for a 5GLAN Group	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190290
		S3‑190492	Draft TR 33.819	Nokia	draft TR	Approval	Yes	Yes	approved	No
8.16	Study on LTKUP Detailed solutions	S3‑190008	draft skeleton document TR 33.935 - v001 - Detailed Long term key solutions	Vodafone GmbH	other	Agreement	Yes	Yes	not treated	No
		S3‑190017	LTKUP: addition of solution 5 in TR 33.935	Gemalto N.V.	pCR	Approval	Yes	Yes	not treated	No
8.17	Study on User Plane Integrity Protection	S3‑190006	Draft TR 33.xxx - Skeleton TR on User Plane Integrity Protection	Vodafone Group	other	Agreement	Yes	Yes	revised	No	S3‑190014
		S3‑190007	pCR to TR 33.853 - addition of scope	Vodafone GmbH	pCR	Agreement	Yes	Yes	revised	No	S3‑190015
		S3‑190014	Draft TR 33.853 - Skeleton TR on User Plane Integrity Protection (updated after conf call)	Vodafone Group	draft TR	Agreement	Yes	Yes	approved	No		S3‑190006
		S3‑190015	pCR to TR 33.853 - addition of scope (updated following conf call)	Vodafone GmbH	pCR	Agreement	Yes	Yes	approved	No		S3‑190007
		S3‑190101	New Key Issue: UP integrity activation in EPS	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑190112	New key issue on user plane integrity protection in MR-DC scenarios	NEC Corporation	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑190113	New key issue on data rate limitation of integrity protection in UP DRB	NEC Corporation	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑190149	Key issue of UP IP performance	Apple (UK) Limited	pCR	Approval	Yes	YesHuawei: performance is not a security issue. ORANGE: consider bidding down attack.	noted	No
		S3‑190150	Solution of improving efficiency of UP IP	Apple (UK) Limited	pCR	Approval	Yes	Yes	noted	No
		S3‑190209	New key issue on user plane integrity protection in MR-DC scenarios	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑190210	New key issue on data rate limitation of integrity protection in UP DRB	NEC Corporation	pCR	Approval	Yes	YesQualcomm: max data rate is full data rate, minimum is 64Kbps. The key issue is wrong. There was a different understanding on this and had to be discussed offline.	noted	No
		S3‑190218	Key issue to ensure the correct routing of the data packets in the user plane	China Mobile	pCR		Yes	YesDeutsche Telekom: same key issue as the NEC contribution.	noted	No
		S3‑190285	New key issue on the secure negotiation of the user plane integrity protection feature	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑190551
		S3‑190551	New key issue on the secure negotiation of the user plane integrity protection feature	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑190285
		S3‑190309	Solution for partial UP IP considering UE limitations	Motorola Mobility, Lenovo	pCR	Approval	Yes	YesDeutsche Telekom: This is not the solution SA3 should go for.	noted	No
		S3‑190386	pCR: New KI: Efficient handling of PDCP discardTimer expiry on the UE Uplink	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: not security related. Apple agreed.	noted	No
		S3‑190387	pCR: New KI: Ability to prioritize certain PDCP packets on the UE uplink	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: not related to security, this should go to RAN2. NTT-Docomo disagreed, this could lead to DoS attacks. Ericsson, Apple: more solution than key issue.	noted	No
		S3‑190388	pCR: New KI: Integrity Algorithm independence	Qualcomm Incorporated	pCR	Approval	Yes	YesApple: evaluation of solutions that we don’t have. Vodafone: this is putting the framework of the solution into plan. NEC: this is not a key issue. NCSC agreed with NEC and Apple. Vodafone proposed to have conference calls in order to discuss how to progress with the key issues.	noted	No
		S3‑190550	draft TR 33.853	Vodafone	draft TR	Approval	Yes	Yes	approved	No
8.18	Study on Security Impacts of Virtualisation	S3‑190108	TR33848 Study on Virtualisation Skeleton	BT plc	draft TR	Agreement	Yes	Yes	approved	No
		S3‑190109	TR33848 Introduction and Scope	BT plc	other	Agreement	No	Yes	withdrawn	Yes
		S3‑190110	TR33848 Section 4 Background	BT plc	other	Agreement	No	Yes	withdrawn	Yes
8.19	Study on authentication enhancements in 5GS	S3‑190292	Skeleton for TR 33.846 on authentication enhancements	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190293	Scope for the study on authentication enhancements (FS_AUTH_ENH)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190221	Key issue to ensure the security of session anchor keys	China Mobile	pCR		Yes	Yes	not treated	No
		S3‑190201	A key issue on the long-term key and its related anchor key leakage	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑190294	New KI: Leakage of long-term key	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190217	Key issue regarding minimal computational cost when generating session anchor keys	China Mobile	pCR		Yes	Yes	not treated	No
		S3‑190160	Key issue for linkability when AUTN verification fails	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑190303	Key issue on linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑190226	Key issue to resist the linkability attacks	China Mobile	pCR		Yes	Yes	not treated	No
		S3‑190159	Key issue for SUPI concealment	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑190223	Key issue to mitigate the DDoS attacks on the UDM	China Mobile	pCR		Yes	Yes	not treated	No
		S3‑190295	New solution: EAP-AKA´ PFS	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑190296	Update on EAP-AKA´ PFS	Ericsson	pCR	Information	Yes	Yes	not treated	No
		S3‑190162	Solution for linkability issue	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑190161	Solution on mitigation of large SUCI attack	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
8.20	Other study areas
8.21	New study item proposals	S3‑190044	LS on PC5 unicast and groupcast security protection	S2-1812896	LS in		Yes	YesORANGE: do we answer SA2 before or after the study? LG: we reply that we will investigate it with a study. ORANGE: study all possible solutions or those two proposed by SA2? LG commented that only the two from sA2.	replied to	No
		S3‑190142	Discussion about a new study on eV2X security	LG Electronics	discussion	Discussion	Yes	Yes	noted	No
		S3‑190143	New SID on Security Aspects of 3GPP support for Advanced V2X Services	LG Electronics	SID new	Approval	Yes	YesORANGE: conclusions should be based on the TR conclusions from sA2. LG clarified that the solutions will go for the normative work that is being carried out in SA2.	revised	No	S3‑190462
		S3‑190462	New SID on Security Aspects of 3GPP support for Advanced V2X Services	LG Electronics	SID new	Agreement	Yes	Yes	agreed	No		S3‑190143
		S3‑190144	Reply LS on PC5 unicast and groupcast security protection	LG Electronics	LS out	Approval	Yes	Yes	revised	No	S3‑190463
		S3‑190463	Reply LS on PC5 unicast and groupcast security protection	LG Electronics	LS out	Approval	Yes	Yes	approved	No		S3‑190144
		S3‑190163	New SID on 5G forward security	ZTE Corporation	SID new	Approval	Yes	YesNokia: there is a forward secrecy study item. Ericsson: this is not very urgent for Rel-16. There is no clear threat, it's more of an enhancement. ORANGE preferred to have a security paper for the next meeting describing the security issue. This was also recommended by the Chair.	noted	No
		S3‑190164	New SID on IPsec enhancement to meet 5G data rate requirements	ZTE Corporation	SID new	Approval	Yes	Yes	noted	No
		S3‑190165	Discussion on improving the efficiency of IPsec to meet 5G data rate requirements	ZTE Corporation	discussion	Discussion	Yes	YesZTE clarified that the results were coming from testing. BT: 20Gbps? What was the experimental setup? 3GPP deployment? ZTE answered that a 3GPP deployment. IPSec is an IETF standard, and the issue should be considered there. NEC: this is about performance and implementation, not a standard issue.	noted	No
		S3‑190392	draft SID for User Identities and Authentication	Vodafone GmbH	SID new	Agreement	No	Yes	withdrawn	Yes
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑190002	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑190005	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑190563
		S3‑190563	Work Plan input from Rapporteurs	MCC	other	-	Yes	Yes	noted	No		S3‑190005
10	Future Meeting Dates and Venues	S3‑190004	SA3 meeting calendar	MCC	other		Yes	Yes	noted	No
11	Any Other Business	S3‑190560	Draft agenda SA3_94 AdHoc	WG Vice Chair (Qualcomm)	discussion	Endorsement	Yes	Yes	endorsed	No
12	Close