TDoc list

Tdoc List

2017-05-22 10:30

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‑171000	Agenda	WG Chairman	agenda		Yes	Yes	approved	No
3	IPR Reminder
4	Meeting Reports
4.1	Approval of the report from SA3#86 and SA3 ad-hoc	S3‑171001	Report from SA3#86	MCC	report		Yes	Yes	approved	No
		S3‑171002	Report from SA3 Adhoc	MCC	report		Yes	Yes	approved	No
		S3‑171045	Report from emeeting DoNAS	MCC	report	Approval	No	No	withdrawn	Yes
		S3‑171091	Report of 3GPPSA3-Emeeting on DoNAS(NB-IOT)	VODAFONE Group Plc	report	Approval	Yes	YesOfficial report of the emeeting on DoNAS, prepared by Vodafone.	revised	No	S3‑171447
		S3‑171447	Report of 3GPPSA3-Emeeting on DoNAS(NB-IOT)	VODAFONE Group Plc	report	Approval	Yes	YesRevised to correct the table of attendees.	approved	No		S3‑171091
4.2	Report from SA #75	S3‑171004	Report from last SA meeting	WG Chairman	report		Yes	Yes	noted	No
4.3	Report from SA3-LI
5	Items for early consideration	S3‑171012	Reply LS on security aspects of external xMB interface for TV services	C3-171264	LS in		Yes	Yes	replied to	No
		S3‑171440	Draft reply LS to CT3 and SA4 on xMB security	Ericsson	LS out		Yes	Yes	revised	No	S3‑171450
		S3‑171450	Reply LS to CT3 and SA4 on xMB security	Ericsson	LS out	-	Yes	Yes	approved	No		S3‑171440
		S3‑171134	Security aspects of xMB reference point	Ericsson, Qualcomm	CR	Agreement	Yes	YesNokia pointed out that the LS states that there is further cosnideration needed but that we are replying with an answer already.	agreed	No
		S3‑171008	Reply LS on update to key management for application signalling	C1-171654	LS in		Yes	Yes	replied to	No
		S3‑171117	Reply LS on update to key management for application signalling	NCSC	LS out	Approval	Yes	YesEricsson: On point 3, rhere are backward compatibility issues with Rel-13 and we are not addressing CT1 concerns.	revised	No	S3‑171451
		S3‑171451	Reply LS on update to key management for application signalling	NCSC	LS out	Approval	Yes	Yes	approved	No		S3‑171117
		S3‑171119	[MCSEC] Discussion doc on update to MCPTT Multicast signalling	NCSC	discussion	Discussion	Yes	Yes	noted	No
		S3‑171291	Security aspects of xMB reference point	Ericsson, Qualcomm	CR		No	No	withdrawn	Yes
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑171026	LS on eDRX Configuration and IMSI-paging	R3-170908	LS in		Yes	YesNokia: no implication on us, but CT4 and RAN3 need to align. Docomo, DT: some info is being revealed, so this can have repecursions. It was agreed to follow these discussions closely for possible repercusions.	noted	No
		S3‑171014	Reply LS on eDRX Configuration and IMSI-paging	C4-172276	LS in		Yes	Yes	noted	No
		S3‑171031	Reply LS on applicability of WLAN emergency numbers on 3GPP access	S1-171446	LS in		Yes	Yes	noted	No
		S3‑171035	Reply LS to LS on applicability of WLAN emergency numbers on 3GPP access (C1-170513/S2-171630)	S2-172507	LS in		Yes	Yes	noted	No
		S3‑171033	Reply LS on SeDoC related authentication procedure	S2-171615	LS in		Yes	YesNokia found the response satisfactory.	noted	No
		S3‑171038	Reply LS to SA3 on standardization of Northbound SCEF API	S2-172738	LS in		Yes	YesVodafone thought that the response included wrong statements. No architecture changes are required to enable EMDSDP. BT: do we need to change anything to expose capabilities to a higher layer? Vodafone: BEST is just user data, transparent at this point. You can see from the Attach that is a BEST service. This LS had to be taken offline for further consideration from Vodafone. Huawei commented that there was no concerns and no response was needed. Vodafone: we have covered everything and there is nothing else to do. This was agreed.	noted	No
6.2	IETF
6.3	ETSI SAGE	S3‑171050	Support of 256-bit Keys and Algorithms in 5G	AT&T, InterDigital, MITRE	discussion	Decision	Yes	YesDocomo: it makes sense when we want to increase the security of the overall system. The kind of attacks with quantum computers require a large number of resources. This large number of resources could attack anything really. Does this justify the investment for the overall security of the system? AT&T found this justified. Gemalto supported the creation of a WID/SID to have longer keys for the algorithms. Docomo commented that there is more than extending the radio interface to 256 bits. All authentication solutions would need to be reevaluated. There's a lot of additional work. Vodafone: how does this interact with the SAGE work? Interdigital,, Gemalto supported AT&T's proposal for the work item. BT would support depending on the scope. The Chair commented that there are more questions to be answered before starting the work. Starting now would impact the work on the phae one of 5G. Qualcomm: we made a decision to use 128bits for the phase one. This can wait for phase 2. Gemalto: do we need to tell SAGE that we won’t include QSC in phase one? AT&T: I'm ok with not using 256bits in phase one, but SAGE should start the work soon so we have an answer when SA3 tackles this issue. Interdigital: we should tell SAGE when to start. Nokia: we are happy with 128 bits in phase one (specified by mid 2018).We don’t need longer keys algorithms by mid 2018. we might need them after that.	noted	No
		S3‑171425	256-bit algorithms for 5G	ETSI SAGE	LS in		Yes	YesBT doubted whether anything else besides radio should have 256bits.	noted	No
6.4	GSMA
6.5	3GPP2
6.6	OMA
6.7	TCG	S3‑171049	TCG progress report	InterDigital, Inc.	report	Information	Yes	Yes	noted	No
6.8	oneM2M
6.9	TC-CYBER	S3‑171007	Middlebox security protocol	ETSI TC CYBER	LS in		Yes	Yes	replied to	No
		S3‑171062	Reply LS on Middlebox Security Protocol	S3i170166	LS in		Yes	YesBT: keep the commercial network side and the LI side separate, they have different requirements.	noted	No
		S3‑171342	Draft reply to LS from TC CYBER on middlebox security	Home Office, BT, Telefonica	LS out	Approval	Yes	YesDocomo: not sure that TC CYBER is the place to define such protocol but IETF.	revised	No	S3‑171449
		S3‑171449	Reply to LS from TC CYBER on middlebox security	Home Office	LS out	Approval	Yes	Yes	approved	No		S3‑171342
		S3‑171317	Background to proposed SA3 handling of LS from TC CYBER	Home Office, BT, Telefonica	discussion	Discussion	Yes	Yes	noted	No
		S3‑171015	Liaison statement to ETSI 3GPP SA3	ETSI TC CYBER QSC	LS in		Yes	Yes	noted	No
6.10	ETSI NFV security
6.11	Other Groups
7	Work Areas
7.1	Security Assurance (Rel-15)
7.1.1	Security Assurance Specification for 3GPP network product classes (General, TS 33.117) (SCAS-SA3)	S3‑171388	Resolution of editor's notes in 33.116	NTT DOCOMO	other	Agreement	Yes	No	withdrawn	Yes
		S3‑171435	Resolution of editor's notes in 33.116	NTT DOCOMO	CR	Agreement	Yes	Yes	agreed	No
7.1.2	Security Assurance Specification for 3GPP network product classes (MME, TS 33.116) (SCAS-SA3)	S3‑171389	Resolution of editor's notes in 33.117	NTT DOCOMO, KPN	other	Agreement	Yes	No	withdrawn	Yes
		S3‑171436	Resolution of editor's notes in 33.117	NTT DOCOMO, KPN	CR	Agreement	Yes	Yes	agreed	No
7.1.3	Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)	S3‑171366	Adding a requirement within 3GPP TS 33.250 on “Unpredictable GTP TEID”	TELECOM ITALIA S.p.A., KPN	pCR	Approval	Yes	YesEricsson doubted whether this was necessary, as there were other issues. Deutsche Telekom: GTP spoof has been treated since a long time ago and we shouldn’t discuss whether this is a real threat or not. It is correct that there are other solutions but this one is the simplest so far. Docomo: this is a valid threat and we should try to protect agains it.	approved	No
		S3‑171369	Adding test case for the requirement on unpredictable TEID generated by the PGW.	TELECOM ITALIA S.p.A., KPN	pCR	Approval	Yes	Yes	revised	No	S3‑171515
		S3‑171515	Adding test case for the requirement on unpredictable TEID generated by the PGW.	TELECOM ITALIA S.p.A., KPN	pCR	Approval	Yes	Yes	approved	No		S3‑171369
		S3‑171264	Deleting the EN in the section 4.2.6 of TS33.250	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: why removing the configuration? They didn't agree with the changes. Deutsche Telekom only agreed with removing the editor's note.	revised	No	S3‑171516
		S3‑171516	Deleting the EN in the section 4.2.6 of TS33.250	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171264
		S3‑171056	Remove EN of security requirements of user plane traffic differentiation	ZTE, China Unicom	pCR	Approval	Yes	YesEricsson: if we intercept packets we have to describe the presence of a node being simulated, and that doesn't appear here. It was finally approved.	approved	No
		S3‑171172	Resolving technical editor’s notes and adding sections to align with TS33.117	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑171171	Resolving non-technical editor’s notes	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑171517	Draft TS 33.250	China Mobile	draft TS	Approval	Yes	Yes	approved	No
		S3‑171518	Cover sheet TS 33.250	China Mobile	TS or TR cover	Approval	Yes	Yes	approved	No
		S3‑171536	LS on a new requirement on “Unpredictable GTP TEID”	Telecom Italia	LS out	Approval	Yes	Yes	approved	No
7.1.4	Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)	S3‑171217	AS algorithms selection	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: there is no format of evidence. Huawei suggested to remove the term "simulated eNodeB". This was agreed.	revised	No	S3‑171519
		S3‑171519	AS algorithms selection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171217
		S3‑171218	Verify RRC integrity protection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171520
		S3‑171520	Verify RRC integrity protection	Huawei, Hisilicon	pCR	Approval	Yes	YesRemoving the term "simulated eNodeB"	approved	No		S3‑171218
		S3‑171219	Verify the feature of EIA0	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171521
		S3‑171521	Verify the feature of EIA0	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171219
		S3‑171220	Verify key refresh at eNB	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171522
		S3‑171522	Verify key refresh at eNB	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson suggested to add the screeshot of relevant changes. Also removing the simulated eNodeB term.	approved	No		S3‑171220
		S3‑171523	Draft TS 33.216	Huawei	draft TS	Approval	Yes	Yes	approved	No
7.1.5	Other
7.2	Security of the Mission Critical Service (MCSec) (Rel-14)	S3‑171042	Reply LS on addition of KMS URI to configuration parameters	S6-170412	LS in		Yes	Yes	noted	No
		S3‑171118	[MCSEC] Adding MSCCK functionality for back-compatibility	NCSC	pCR	Approval	Yes	YesEricsson: how do you decide between the two procedures, MSCCK and MuSiK? NCSC: it's configured in the server.	revised	No	S3‑171457
		S3‑171457	[MCSEC] Adding MSCCK functionality for back-compatibility	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑171118
		S3‑171393	[MCSec] 33.180 pCR Inter-domain IdM profile corrections	Motorola Solutions Danmark A/S	pCR	Approval	Yes	YesAirbus found confusing the addition of "primary or partner" in B.9. It was agreed to remove it. Some rewording in B.6.4 was also suggested by Airbus and agreed.	revised	No	S3‑171458
		S3‑171458	[MCSec] 33.180 pCR Inter-domain IdM profile corrections	Motorola Solutions Danmark A/S	pCR	Approval	Yes	Yes	approved	No		S3‑171393
		S3‑171116	[MCSEC] Protection of full XML document	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑171123	[MCSEC] Update to MCData security	NCSC	pCR	Approval	Yes	YesAirbus wanted to add a note on the open issues of authenticated payload.This wasn't agreed.	revised	No	S3‑171459
		S3‑171459	[MCSEC] Update to MCData security	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑171123
		S3‑171394	[MCSec] 33180 pCR editorial updates	Motorola Solutions Danmark A/S	pCR	Approval	Yes	Yes	approved	No
		S3‑171433	[MCSEC] Addition of descriptive clauses	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑171395	[MCSec] 33180 pCR requirement updates	Motorola Solutions Danmark A/S	pCR	Approval	Yes	Yes	revised	No	S3‑171460
		S3‑171460	[MCSec] 33180 pCR requirement updates	Motorola Solutions Danmark A/S	pCR	Approval	Yes	Yes	approved	No		S3‑171395
		S3‑171396	WID MSec continuation work	Motorola Solutions Danmark A/S	WID new	Agreement	Yes	YesNCSC commented that there is a strong dependence on SA6, so any delay in their work would delay SA's work as well. They have to finish their work the meeting before december 18.	revised	No	S3‑171465
		S3‑171465	WID MSec enhancements	Motorola Solutions Danmark A/S	WID new	Agreement	Yes	YesAdding new supporters, correcting some issues on name and acronym and impacted existing specs table. Motorola commented that they wished to continue using TR 33.880 and extend the study. MCC commented that the Study item may have to be revised since the justification and objectives may have changed. The original study was intended for Release 14. The Study item had to be checked offline, but in any case this WID was correct and agreed.	agreed	No		S3‑171396
		S3‑171124	[MCSEC] Addition of descriptive clauses	NCSC	pCR	Approval	No	No	withdrawn	Yes
		S3‑171445	Reply LS on addition of KMS URI to configuration parameters	S6-170795	LS in	discussion	Yes	Yes	noted	No
		S3‑171463	Draft TS 33.180	NCSC	draft TS	Approval	Yes	Yes	approved	No
		S3‑171464	Cover sheet TS 33.180	NCSC	TS or TR cover	Approval	Yes	Yes	approved	No
		S3‑171466	Reply LS to SA6 on mission critical communication interworking security issues	NCSC	LS out	Approval	Yes	Yes	approved	No
7.3	Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)	S3‑171088	Abbreviations in TS 185	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171309	V2X MB2 interface requirements	Nokia	pCR	Decision	Yes	Yes	approved	No
		S3‑171422	TS 33.185: V2X Entities Secure Environment	Gemalto N.V.	pCR	Approval	Yes	YesVodafone: is this spec applicable to LTE only or 5G as well? The answer was LTE only. Vodafone: then we don’t need it. This has been specified already. Gemalto: this was in the TR. Why is it different now in the TS? KPN supported Vodafone. If this is agreed here, we have to add it to all LTE specs. BT supporting having this. Vodafone:it should be USIM and not UICC. This was agreed.. Telia Sonera supported BT: this is a new use case.	revised	No	S3‑171467
		S3‑171467	TS 33.185: V2X Entities Secure Environment	Gemalto N.V.	pCR	Approval	Yes	Yes	approved	No		S3‑171422
		S3‑171087	Misc Changes to TS 33.185 Sec 6.5	Huawei, HiSilicon	pCR	Decision	Yes	Yes	revised	No	S3‑171468
		S3‑171468	Misc Changes to TS 33.185 Sec 6.5	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No		S3‑171087
		S3‑171320	Clarifying some text on the procedures for the security of V2X data	Qualcomm Incorporated	pCR	Approval	Yes	YesVodafone: it seems that we are enforcing the policy to be the same.	revised	No	S3‑171469
		S3‑171469	Clarifying some text on the procedures for the security of V2X data	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑171320
		S3‑171057	Miscellaneous changes to Chapter 6.6 of TS 33.185	CATR	pCR		Yes	YesNokia and Qualcomm considered that the privacy enhancements should be left open for discussion. Huawei clarified that the "randomize" statement was coming from SA2. Deutsche Telekom disagreed, they were not in favout of having this. Nokia: this is not related to security, let CT take charge of this. ORANGE: V2X application is not specified in 3GPP. Ericsson commented that the tracking issue needed to be considered at the application layer, this was discussed before. Everything was agreed except the statement on privacy enhancements that had to be taken offline. The privacy statement was covered by the note in tdoc 319	revised	No	S3‑171472
		S3‑171472	Miscellaneous changes to Chapter 6.6 of TS 33.185	CATR	pCR	-	Yes	Yes	approved	No		S3‑171057
		S3‑171109	Clarification of ID change for V2X PC5	LG Electronics	pCR	Approval	Yes	Yes	approved	No
		S3‑171310	V2X privacy requirements	Nokia	pCR	Decision	Yes	YesORANGE: what is the UE identity? Nokia: it's the IMSI. ORANGE: this is not defined anywhere. Is the IMSI distributed over the PC5 interface? Ericsson: this is LTE, we don’t try to change the legacy system, it's conflicting with what we already have. This had to be taken offline.	revised	No	S3‑171470
		S3‑171470	V2X privacy requirements	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑171310
		S3‑171170	Discussion and pCR for V2X privacy	China Mobile	pCR	Approval	Yes	YesORANGE: the first requirement looks like a legal requirement on the network. We don’t use the term pseudonomity in 33.401. Vodafone: we have agreed on confidentiality being the same as in LTE. I don’t see why we need this clause at all.It's saying "for the Uu interface we need to use the LTE specs". LG: this is a different case. This document overlapped with tdoc 319 and was merged with it.	merged	No	S3‑171473
		S3‑171311	V2X privacy solution	Nokia	pCR	Decision	Yes	YesEricsson: transmission of broadcast messages over PC5 is confusing. Nokia: we can enhance MBMS to be used here. Ericsson: you cannot use MBMS on PC5. Nokia clarified that the "LTE identity" is the IMSI. BT: have a general section on privacy issues only. Ericsson: we don’t have a privacy solution and we need to make it clear in the TS. Nokia: Resource allocation and how it is dynamically done is not SA3's business and does not need to be here. Vodafone: there is no user interface specified for V2X in 3GPP. We need to make it clear. This had to be taken offline. A sentence on user consent was added to tdoc 319 to address this document.	merged	No	S3‑171473
		S3‑171471	V2X privacy solution	Nokia	pCR	Decision	No	No	withdrawn	Yes
		S3‑171319	Adding information on lack of Uu privacy to the V2X CR	Qualcomm Incorporated, Ericsson, LG	pCR	Approval	Yes	YesORANGE: we have LTE privacy at least. Telia Sonera supported this document. Ericsson: we are not addressing that the operator cannot track users in V2X, as required by SA1. ORANGE: just reference to 33.401. BT,Nokia: not only 33.401. Qualcomm: it's important to note the requirements that we are not addressing. ORANGE: they don't have any requirements for the IMSI privacy. Vodafone suggested to move the text on the technical solution to a note. This was accepted.	revised	No	S3‑171473
		S3‑171473	Adding information on lack of Uu privacy to the V2X CR	Qualcomm Incorporated, Ericsson, LG	pCR	Approval	Yes	Yes	approved	No		S3‑171319
		S3‑171030	LS on the support of Unicast and Groupcast transmission over PC5 for eV2X	RP-170841	LS in		Yes	Yes	noted	No
		S3‑171044	Reply LS to NGMN V2X Task-Force	SP-170278	LS in		Yes	Yes	noted	No
		S3‑171474	Draft TS 33.185	Huawei	draft TS	Approval	Yes	Yes	approved	No
		S3‑171475	Cover sheet TS 33.185	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
7.4	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)	S3‑171414	UP confidentiality and integrity protection in 5G	KPN	pCR	Approval	Yes	YesNokia had an issue with the PDCP layer. This wasn't needed according to them. BT: we need to look closely at what support means. Nokia: support means implemented or not. They proposed to follow 401. The meaning of support wasn't clear in the room.	revised	No	S3‑171491
		S3‑171491	UP confidentiality and integrity protection in 5G	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑171414
		S3‑171353	Requirements for secure storage and processing of subscription credentials	ORANGE	pCR	Approval	Yes	YesGemalto: subscription credentials stored and processed in the UICC, was a solution in the TR.We disagree with this. Sony agreed with Gemalto. ORANGE: is the UICC one of the solutions? Also, we are not excluding other options as the following editor's note is stating. Intel supported Gemalto and preferred to have the UICC solution removed. It was agreed to remove the last sentence and editor's note.	revised	No	S3‑171492
		S3‑171492	Requirements for secure storage and processing of subscription credentials	ORANGE	pCR	Approval	Yes	Yes	approved	No		S3‑171353
		S3‑171132	pCR to 33.501: requirements on gNB	Ericsson	pCR	Approval	Yes	YesInterdigital wondered why the interface is IP-based only in 5.2.5. Ericsson: this is in line with the split architecture that is being discussed in RAN.We agree with removing it if needed. Telia Sonera recommended to have a note on the general clause. Qualcomm: why remove 5.3.2? These requirements also apply to gNodeB. It was commented that SCAS requirements for eNodeB could also apply here. Deutsche Telekom: eNodeB SCAS is not ready yet,a bit premature to refer to it now.	revised	No	S3‑171493
		S3‑171493	pCR to 33.501: requirements on gNB	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171132
		S3‑171347	Detailing of ToC for TS 33.501 wrt authentication	Nokia	pCR		Yes	YesORANGE didn’t agree with the wording in 6.1.1.1. Why referencing to an informative Annex? Discussed with tdoc 285 and 378.	revised	No	S3‑171495
		S3‑171495	Detailing of ToC for TS 33.501 wrt authentication	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171347
		S3‑171328	Generic introductory text for the Authentication clause of TS 33.501	Qualcomm Incorporated	pCR	Approval	Yes	YesDocomo warned about the ambiguous use of mays and shoulds that may or may not be normative language. Ericsson commented that the second paragraph in 6.1.1.1 hasn’t been defined yet and that it should be removed.	revised	No	S3‑171496
		S3‑171496	Generic introductory text for the Authentication clause of TS 33.501	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑171328
		S3‑171362	Initiation of authentication	Nokia	pCR		Yes	YesSome concerns on the editor's note and its links with the privacy work. Nokia: The Home network determines what authentication method to use. Qualcomm: better rename EPS AKA* since we are creating a new protocol and may not have to be related to the one that is in the TR. Ericsson: we discourage MME to handle more than one authentication vector, which is not here. Nokia: it's a recommendation. Some operators would like to have batches of authentication vectors to be used in case of outage of the HPLMN. Docomo: roaming in a malicious network then coming back to the trusted network is a confusing use case. Deutsche Telekom: if we allow this, we have to deal with the consequences. This can lead to greater complexity. Vodafone confirmed that the batches of authentication vectors are a useful tool for operators. An editor's note and some text revisions were done in order to address all comments.	revised	No	S3‑171497
		S3‑171497	Initiation of authentication	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171362
		S3‑171370	Authentication procedure for EAP-AKA’	Nokia	pCR		Yes	YesQualcomm and Ericsson: same key derivation for all EAP methods would be more desireable. Which key to be used should be left for further study: MSK or derived from MSK.	revised	No	S3‑171499
		S3‑171499	Authentication procedure for EAP-AKA’	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171370
		S3‑171314	pCR to TS35.501 - Authentication procedure for EPS AKA* - possible variant	VODAFONE Group Plc	pCR	Agreement	Yes	YesDiscussed together with Nokia's solution in tdoc 373. Main difference is the Resp. No big difference between this and Nokia's solution, Vodafone opted to follow Nokia's option.	noted	No
		S3‑171373	Authentication procedure for EPS AKA*	Nokia	pCR		Yes	YesSolution from the TR.	noted	No
		S3‑171376	Authentication procedure for EPS AKA* - possible variant	Nokia	pCR		Yes	YesThe solutions over the table were in tdocs 314 and 376. This tdoc presents a modified authentication response. Variation of 376. Vodafone didn’t favour the original . Ericsson was in favour of this solution. Gemalto commented that there is no requirement for support of legacy USIM. Nokia: It shall be possible to compute this in the ME. Oberthur: SA1 defines new requirements, if there are not new requirements the old ones are applicable. Keep it as it is. Docomo: we need to make sure that the serving network name is something that we can use. KPN had a slight preference for Vodafone's solution, as Huawei. Vodafone went for this solution eventually. Huawei disagreed with this solution.	revised	No	S3‑171545
		S3‑171545	Authentication procedure for EPS AKA* - possible variant	Nokia,Ericsson	pCR	-	Yes	Yes	approved	No		S3‑171376
		S3‑171377	Linking increased home control to subsequent procedures	Nokia	pCR		Yes	YesDeutsche Telekom: maybe to make 6.1.4.2 normative? Ericsson: There may be other ways to do this. It's not clear for us whether this could become normative so we suggest to postpone for the next meeting. Docomo preferred to have this normative, Vodafone as well. BT was concerned to have this in the normative part of the TS.	revised	No	S3‑171501
		S3‑171501	Linking increased home control to subsequent procedures	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171377
		S3‑171285	Content for clause 7 on security procedures between 5G Network Functions	Ericsson	pCR	Approval	Yes	YesNokia: wrongly deleted editor's note in 7.2 due to a misunderstanding. Ericsson understood and agreed. Deutsche Telekom: Note 1 in 7.1.1 should go away. Also, are we changing the SA acronym of AMF to avoid misunerstanding with our AMF? Nokia: we add a note everytime that this can be confusing. As per comments from BT the note was agreed to be reworded. ORANGE: in TS 33.210 implementation of IPSEC was optional. Is it the same case in 5G core network?Ericsson preferred to keep it optional to implement. Telia Sonera, China Mobile and Deutsche Telekom had the same thought. BT: we have a different concept of implementation. It's about turning it on or off. It was agreed in 7.1.1 to add an editor's note on the management plane as suggested by Deutsche Telekom. ORANGE: mandatory use of IPSEC is FFS. An editor's note was added to that effect. MCC reminded that a better standardization term for "mandatory to implement and optional to use" was "shall be supported".	revised	No	S3‑171502
		S3‑171502	Content for clause 7 on security procedures between 5G Network Functions	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171285
		S3‑171382	Security procedures on N12	Nokia	pCR		Yes	YesQualcomm: reword EAP-AKA' success according to what's being discussed in this meeting. MCC suggested to remove the note in EAP-AKA' Success so as not to name stages or releases in the content of the TS.This was agreed.	revised	No	S3‑171503
		S3‑171503	Security procedures on N12	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171382
		S3‑171016	LS to RIFS and SA3 on Diameter Security	GSMA PACKET	LS in		Yes	YesNokia was in favour of tackling on this work and answer to GSMA. Deutsche Telekom commented that there was no action needed. KPN: we did something in security 10, we can mention in a reply. It was agreed to reply to the LS in 540 about the same topic.	noted	No
		S3‑171540	Liaison Statement to 3GPP SA3: GSMA Activity on Securing Diameter Interfaces	GSMA FASG	LS in	discussion	Yes	Yes	replied to	No
		S3‑171397	Security procedures on N13	Nokia	pCR		Yes	YesDocomo: we didn't try to secure Diameter in security area 10. Nokia:we do some solutions; public keys techniques, or protecting the internal AVP. Docomo: a lot of diameter things happening are not visible in the standards. We would like them to find a security solution. Nokia: CT4 defines AVPs, so we can do it in 3GPP. IETF has draft for the solutions in security. We should come back to them with some joint input with GSMA. We don’t define security end-to-end but we can provide with requirements.	revised	No	S3‑171504
		S3‑171574	Reply to: Liaison Statement to 3GPP SA3: GSMA Activity on Securing Diameter Interfaces	KPN	LS out	approval	Yes	Yes	approved	No
		S3‑171504	Security procedures on N13	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171397
		S3‑171183	Intra NG RAN Handover	NEC EUROPE LTD	pCR	Approval	Yes	YesEricsson: it's too early to include this content. We would have to include all the details: names, keys, etc.. We propose to postpone for next meeting. Nokia agreed with Ericsson. Alignment with RAN2 and RAN3 is needed as well. Docomo agreed with this. Ericsson: I'm not sure we have an agreed solution. NEC: no key issue with the handover. This was agreed in the TR. We can add this and update it later. Ericsson: the question is update it to what. It was agreed to work with this offline and come back for the next meeting.	noted	No
		S3‑171330	Security procedures between UE and external data networks via the 5G network	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑171381	Secondary authentication by an external DN-AAA server	Nokia	pCR	Approval	Yes	YesAlf (Docomo): restrict the shalls to the requirements clauses. Ericsson: make the figure editable. Qualcomm didn’t agree with the editor's note (EAP auth role) being in the TS. Ericsson agreed with removing the editor's note.	revised	No	S3‑171505
		S3‑171505	Secondary authentication by an external DN-AAA server	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑171381
		S3‑171214	Update the skeleton to support security on service based architecture	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171126	Annex on the additional EAP methods	Ericsson, Samsung, Qualcomm Incorporated, Nokia, Intel, Huawei	pCR		Yes	YesIt was argued the use of "can"; MCC commented that in this context it was better to use "can" instead of "may". Revised to address other comments.	revised	No	S3‑171506
		S3‑171506	Annex on the additional EAP methods	Ericsson, Samsung, Qualcomm Incorporated, Nokia, Intel, Huawei	pCR	-	Yes	Yes	approved	No		S3‑171126
		S3‑171252	Example Procedure for non-AKA EAP-based Authentication Method in 5G	Huawei, Hisilicon	pCR	Approval	Yes	YesSome language should be corrected (e.g. use of "we"). Vodafone: this is not an interim agreement so we should not procceed with it. The Chair asked the authors to work on this document and bring an updated version for the next meeting.	noted	No
		S3‑171028	LS on Status of Higher-Layer Functional split between Central and Distributed unit	R3-171306	LS in		Yes	Yes	noted	No
		S3‑171022	Reply LS on SA3 LS in S3-170944 “LS on security termination for the User Plane in 5G”	R2-1703960	LS in		Yes	YesDeutsche Telekom: what does "low" mean exactly? It's ambiguous and I'm not sure how this impacts our security design. Nokia: it refers to the timing part.DU and CU are almost co-located. KPN agreed with this being too ambiguous. Ericsson: it's saying that latency won’t be a problem. Docomo: it says that they asume that there is no latency.	noted	No
		S3‑171507	Reply to: Reply LS on SA3 LS in S3-170944 “LS on security termination for the User Plane in 5G”	Deutsche Telekom	LS out	approval	No	No	withdrawn	Yes
		S3‑171288	Discussion on RAN deployment and interface protection	Ericsson	pCR	Discussion	Yes	YesDiscussed together with 285.	noted	No
		S3‑171051	Quantum Safe Cryptography and Security Choices for 5G	TCG, InterDigital, AT&T, MITRE	discussion	Presentation	Yes	YesNokia: specificying this would be fast but to have it in the UE may take long. Whatever we encrypt today, does it have to be like this in 20 years?Does it still matter? That's the question to answer.Qualcomm agreed; a threat analysis would be needed to know what we would gain with longer keys. NCSC: the current keys are considered until 2050. Nothing regarding 128 bits.	noted	No
		S3‑171337	Agreements related to UE (re)registration and NAS security procedures in 5GS	Qualcomm Incorporated	discussion	Approval	Yes	Yes	noted	No
		S3‑171357	Initiation of authentication	Nokia	pCR		No	No	withdrawn	Yes
		S3‑171363	Authentication procedure for EAP-AKA’	Nokia	pCR		No	No	withdrawn	Yes
		S3‑171371	Authentication procedure for EPS AKA*	Nokia	pCR		No	No	withdrawn	Yes
		S3‑171383	Security procedures on N12	Nokia	pCR		No	No	withdrawn	Yes
		S3‑171384	Security procedures on N12	Nokia	pCR		No	No	withdrawn	Yes
		S3‑171385	Security procedures on N12	Nokia	pCR		No	No	withdrawn	Yes
		S3‑171524	Draft TS 33.501	NTT-Docomo	draft TS	Approval	No	Yes	left for email approval	No
7.5	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)	S3‑171147	EN-DC in option 3a/3x	Ericsson	pCR	Approval	Yes	YesQualcomm disagreed. Ericsson pointed out that solution one was what was given to SA3 and that needed to be the working assumption. Qualcomm: the solution is not being imposed according to the LS from RAN. It's a preference. Huawei supported the Ericsson proposal. Nokia commented that both CT1 and RAN2 feedbacks were slightly different from each other and from there SA3 should study which one to use. Qualcomm: ask CT1 in a LS if they have any issues with SA3 using variant one and wait for the next meeting.	revised	No	S3‑171486
		S3‑171486	EN-DC in option 3a/3x	Ericsson	pCR	Approval	Yes	YesKeeps the interim agreements part and states only "yes".	approved	No		S3‑171147
		S3‑171338	NR algorithm selection in EN-DC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑171184	Update of solution #4.6 on security mechanism for deployment scenario of option 3	NEC EUROPE LTD	pCR	Approval	Yes	YesNEC wanted to send this info in the LS, but it was finally agreed not to do it.	approved	No
		S3‑171216	Security capability handling for EN-DC	Huawei, Hisilicon	discussion	Discussion	Yes	YesEricsson didn’t understand how to handle proposal 3 according to Qualcomm's proposal in 338. It was agreed to send an LS to both RAN2 and CT1 to state that no decision has been made on the three options and that will be done in the next meeting. Huawei reminded that the majority of companies in CT1 didn’t like option one.	noted	No
		S3‑171185	EN-DC (E-UTRAN – New Radio) Dual Connectivity	NEC EUROPE LTD	CR		Yes	YesDiscussed with the related document 324. Parts of this CR were merged with the Qualcomm proposal in 324.	not pursued	No
		S3‑171324	Solution for Dual Connectivity between MeNB and SgNB	Qualcomm Incorporated	CR	Agreement	Yes	YesEricsson preferred to have the content in an annex as Qualcomm proposed.This was agreed. Vodafone pointed out that both Annex A and E needed to be normative. Ericsson commented that the NR capability should be left out when merging with 185, as it is still an open issue. Qualcomm agreed. It was agreed to create a DraftCR (living document) to include agreed content until the next meeting.	not pursued	No
		S3‑171487	Solution for Dual Connectivity between MeNB and SgNB	Qualcomm Incorporated	draftCR	Approval	Yes	YesContains the merge of 324,487 and 148. This will be a living document that eventually will become a CR when the content is agreed.	approved	No
		S3‑171148	Some comments on proposed text for supporting Option 3	Ericsson	pCR	Approval	Yes	YesSome of its content will go into 487	merged	No	S3‑171487
7.6	Other work areas
7.6.1	SAE/LTE Security	S3‑171059	Reference to list of 3GPP vendor specific EAP methods	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑171526
		S3‑171526	Reference to list of 3GPP vendor specific EAP methods	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑171059
		S3‑171060	Alignment of 3GPP-vendor specific EAP method names with TS 24.302	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑171527
		S3‑171527	Alignment of 3GPP-vendor specific EAP method names with TS 24.302	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑171060
		S3‑171017	LS on LTE call redirection to GERAN	R2-169124	LS in		Yes	Yes	noted	No
		S3‑171011	Reply LS on LTE call redirection to GERAN	C1-171945	LS in		Yes	Yes	noted	No
		S3‑171019	LS on LTE call redirection to GERAN	R2-1702388	LS in		Yes	YesDocomo: Mandating user interaction will not work for LTE devices that have no user. Nokia: Initial Attach: UE authenticated, the attack is possible, there is no solution now. This LS refer to Mobile terminated voice call: there are two solutions, in RAN2 and CT1. 360 was concerned about the initial attach scenario. The Chair clarified that this wasn’t addressed in the LS.	replied to	No
		S3‑171129	reply LS on LTE call redirection to GERAN	Ericsson	LS out	Approval	Yes	Yes	revised	No	S3‑171554
		S3‑171554	reply LS on LTE call redirection to GERAN	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑171129
		S3‑171245	Enhanced NAS token solution for LTE redirection attack	Huawei, Hisilicon	CR	Agreement	Yes	YesNokia: Enhancement of the proposal of including a NAS token.I see some problems in the communication between MME and UE. MCC note: this document was reserved as CR but it contains a discussion paper. It was decided to note it since conference calls will deal with this issue before the next meeting.	not pursued	No
		S3‑171408	Discussion paper on RAN2 LS on LTE call redirection ( R2-1702388) to GERAN	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑171409	draft_LS reply to LTE call redirection to GERAN	Nokia	LS out	Approval	Yes	YesDocomo commented that the CS fallback/redirection to 2G wasn't the way. 360 and Huawei supported this. Your first reject it and then redirect it to 2G and registers into the CS fallback. Better to fix the problem of having a call being sent over 3G even if we don’t want it in 2G.CS fallback call that we don’t want to have in 2G. It doesn’t matter if we want the authentication call before or not. Nokia: distinguish between idle mode and terminating call. This attack doesn’t have to be with the CSFB, it's a more general attack. It's not about voice calls but forcing the UE not to go to an available 4G network. Docomo: why is it an issue if we go to 2G? 2G is not so well protected. If there is an incoming call, yoCSFB and any type attack that will force the UE to be in 2G to receive this call will be bad. Ericsson and BT agreed with Docomo. BT commented that a long term solution was needed. Ericsson: why is RAN2 working on this if this a SA3 issue? Nokia: this problem has been lingering since quite a long time. They copied us a few meetings back in a LS asking for feedback that we didn’t provide. It's not a 2G issue. Docomo: the UE needs to be aware that this is something that happens in a 2G network.it should reject unprotected redirections. The Chair commented that there is a bigger problem that we already knew. Can we solve such problem? With offline discussions, are companies aware of a bigger problem or not? Is there hope for a solution for this problem?	noted	No
		S3‑171020	LS on providing WT MAC address to the UE using eNB signalling	R2-1702440	LS in		Yes	Yes	replied to	No
		S3‑171272	Discussion for RAN2 LS regarding WT MAC address for uplink traffic	Intel, Qualcomm, Nokia	discussion	Discussion	Yes	Yes	noted	No
		S3‑171273	Reply LS on on providing WT MAC address to the UE using eNB signalling	Intel	LS out	Approval	Yes	Yes	revised	No	S3‑171528
		S3‑171528	Reply LS on on providing WT MAC address to the UE using eNB signalling	Intel	LS out	Approval	Yes	Yes	approved	No		S3‑171273
		S3‑171271	Changes to Security Key Update	Intel, Qualcomm, Nokia	CR	Approval	Yes	YesEricsson didn’t agree with the change from shall to may. Intel: discussed and agreed in the Sophia meeting. This is done to avoid additional overhead in the handshake. Samsung: agreed only in certain scenarios, not all of them.	revised	No	S3‑171547
		S3‑171547	Changes to Security Key Update	Intel, Qualcomm Incorporated, Nokia, Samsung	CR	Approval	Yes	Yes	agreed	No		S3‑171271
		S3‑171424	Comments on S3-171271: Changes to Security Key Update	Samsung	discussion	Discussion	Yes	Yes	endorsed	No
		S3‑171027	Response LS on Progress on Security for LWIP	R3-171272	LS in		Yes	Yes	noted	No
		S3‑171135	Alignment of LWIP to stage 3	Ericsson	CR	Approval	Yes	YesBT: XW interface is missing from the figure H.1-1. Figure not changed in the CR, to be fixed.	revised	No	S3‑171555
		S3‑171555	Alignment of LWIP to stage 3	Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑171135
		S3‑171323	Tidying up the eNB to eNB dual connectivity	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑171529
		S3‑171529	Tidying up the eNB to eNB dual connectivity	Qualcomm Incorporated	CR	Agreement	Yes	YesChanged the Release since not possible to have Cat-D for Rel-14 (frozen).	agreed	No		S3‑171323
		S3‑171325	Security for the RLFs for UEs doing user plane over control plane using NAS level security	Qualcomm Incorporated	CR	Agreement	Yes	YesIt will come back for the next meeting.	postponed	No
		S3‑171339	Details of the calculation of HASH_MME and HASH_UE	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑171530
		S3‑171530	Details of the calculation of HASH_MME and HASH_UE	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑171339
		S3‑171355	HASH Derivation for NAS security mode command procedure	Huawei, Hisilicon	CR		Yes	Yes	merged	No	S3‑171530
		S3‑171430	Correction of reference	Nokia, Vodafone	CR		Yes	Yes	agreed	No
		S3‑171292	Alignment of LWIP to stage 3	Ericsson	CR		No	No	withdrawn	Yes
7.6.2	IP Multimedia Subsystem (IMS) Security	S3‑171426	Setting the salt value in UE and P-CSCF when using AES-GCM/AES-GMAC in IPSec ESP in IMS access security	Nokia	CR		Yes	Yes	agreed	No
		S3‑171427	Setting the salt value in UE and P-CSCF when using AES-GCM/AES-GMAC in IPSec ESP in IMS access security	Nokia	CR		Yes	Yes	agreed	No
		S3‑171428	Introduction of a new value range for the input value FC for the key derivation function (KDF) for use in TS 33.203	Nokia	CR		Yes	Yes	agreed	No
		S3‑171429	Introduction of a new value range for the input value FC for the key derivation function (KDF) for use in TS 33.203	Nokia	CR		Yes	Yes	agreed	No
7.6.3	Network Domain Security (NDS)
7.6.4	UTRAN Network Access Security
7.6.5	GERAN Network Access Security
7.6.6	Generic Authentication Architecture (GAA)
7.6.7	Multimedia Broadcast/Multicast Service (MBMS)
7.6.8	Security Aspects of Home(e)NodeB (H(e)NB)
7.6.9	Security Aspects related to Machine-Type Communication ((e)MTC)
7.6.10	Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)
7.6.11	Security of MCPTT (MCPTT)
7.6.12	Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)	S3‑171321	Correcting the XML for the UE to PKMF interface	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑171322	Correcting the XML for the UE to PKMF interface	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑171533
		S3‑171533	Correcting the XML for the UE to PKMF interface	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑171322
7.6.13	Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)	S3‑171127	Adding references to GIA4, GEA5/GIA5 and stage 3 GMM specifications, and removing corresponding editor's notes.	Ericsson	CR	Approval	Yes	Yes	revised	No	S3‑171534
		S3‑171534	Adding references to GIA4, GEA5/GIA5 and stage 3 GMM specifications, and removing corresponding editor's notes.	Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑171127
		S3‑171128	Adding references to GIA4, GEA5/GIA5 and stage 3 GMM specifications, and removing corresponding editor's notes.	Ericsson	CR	Approval	Yes	Yes	revised	No	S3‑171535
		S3‑171535	Adding references to GIA4, GEA5/GIA5 and stage 3 GMM specifications, and removing corresponding editor's notes.	Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑171128
7.6.14	Security Aspects of Narrowband IOT (CIoT)	S3‑171018	LS on mobility enhancements for NB-IoT	R2-1702290	LS in		Yes	Yes	noted	No
		S3‑171025	Reply LS on mobility enhancements for NB-IoT UEs	R3-170896	LS in		Yes	Yes	noted	No
		S3‑171090	report from 3GPPSA3-Emeeting on DoNAS(NB-IOT)	VODAFONE Group Plc	report	Information	Yes	Yes	noted	No
7.6.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)	S3‑171061	LS on LI requirements for CIOT services including BEST services	S3i170163	LS in		Yes	YesORANGE: Why the HPLMN needs to have LI capabilities? Home Office: it doesn’t matter if you are roaming or not.	replied to	No
		S3‑171537	Reply to: LS on LI requirements for CIOT services including BEST services	Vodafone	LS out	approval	Yes	Yes	approved	No
		S3‑171092	draft TSxx.xxx BEST TS v0.0.1 (status following SA3#86bis)	VODAFONE Group Plc	other	Information	Yes	Yes	noted	No
		S3‑171093	pCR to BEST TS xx.xxx v 0.0.1 - changes agreed at BEST adhocs since Busan	VODAFONE Group Plc	other	Agreement	Yes	Yes	approved	No
		S3‑171094	draft TSxx.xxx BEST v0.0.2 - BEST TS including S3-171093 as agreed in conf calls	VODAFONE Group Plc	other	Agreement	Yes	Yes	revised	No	S3‑171538
		S3‑171538	draft TSxx.xxx BEST v0.0.2 - BEST TS including S3-171093 as agreed in conf calls	VODAFONE Group Plc	other	Agreement	Yes	Yes	approved	No		S3‑171094
		S3‑171360	BEST TS33.xyz Section 3-4 - Editorial and interface Corrections	Juniper Networks	other	Approval	Yes	YesAll these type of documents will be implemented in the draft spec in tdoc 538.	approved	No
		S3‑171343	BEST TS33.xyz Section 6.2.1 - IP EMSDP PDU	Juniper Networks	other	Agreement	Yes	Yes	approved	No
		S3‑171345	BEST TS33.xyz Section 6.2.2 - EMSDP Payload Format	Juniper Networks	other	Agreement	Yes	Yes	approved	No
		S3‑171358	BEST TS 33.xyz Section 4.4.2 - EAS Registration	Nokia	other		Yes	Yes	approved	No
		S3‑171356	pCR to S3-170916 - Change to Key Hierarchy	KPN, Nokia	other	Approval	Yes	Yes	revised	No	S3‑171539
		S3‑171539	pCR to S3-170916 - Change to Key Hierarchy	KPN, Nokia	other	Approval	Yes	Yes	approved	No		S3‑171356
		S3‑171410	Editorial changes to align key names	KPN, Nokia	other	Approval	Yes	Yes	approved	No
		S3‑171365	BEST TS 33.xyz Section 4.4.3 - Key Request	Nokia	other		Yes	Yes	approved	No
		S3‑171348	Key Managemat Procedure between the HSE and EAS	China Mobile Com. Corporation	other		Yes	YesVodafone asked for more time to work with China Mobile for the next meeting. There was agreement on the work needing to be done.	noted	No
		S3‑171359	BEST TS 33.xyz Section 4.4.4 - Key Refresh	Nokia	other		Yes	Yes	revised	No	S3‑171442
		S3‑171442	BEST TS 33.xyz Section 4.4.4 - Key Refresh	Nokia	other	-	Yes	Yes	revised	No	S3‑171541	S3‑171359
		S3‑171541	BEST TS 33.xyz Section 4.4.4 - Key Refresh	Nokia,China Mobile	other	-	Yes	Yes	approved	No		S3‑171442
		S3‑171432	Allocation of FC values for BEST	KPN, Vodafone	CR	Agreement	Yes	Yes	revised	No	S3‑171542	S3‑170670
		S3‑171542	Allocation of FC values for BEST	KPN, Vodafone	CR	Agreement	Yes	YesThe CR will be revised during the SA plenary to introduce the TS number once the BEST WID is approved.	agreed	No		S3‑171432
		S3‑171095	pCR to BEST TS xx.xxx v0.0.2 - Addition of error codes	VODAFONE Group Plc	other	Agreement	No	No	withdrawn	Yes
		S3‑171391	pCR to S3-170916 - Editorial changes to align terminology on key names	KPN, Nokia	other		No	No	withdrawn	Yes
		S3‑171543	Cover sheet TS BEST specification	Vodafone	TS or TR cover	Approval	Yes	YesIt will be revised during the SA plenary to introduce the TS number once the BEST WID is approved.	approved	No
7.6.16	New GPRS algorithms for EASE (EASE_ALGOs_SA3) (Rel-13)
7.6.17	Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)	S3‑171013	LS on Support of Explicit Bootstrapping in ERP	C4-172269	LS in		Yes	Yes	replied to	No	S3‑171379
		S3‑171379	Reply LS on Support of Explicit Bootstrapping in ERP	ORANGE	LS out	Approval	Yes	Yes	revised	No	S3‑171532
		S3‑171532	Reply LS on Support of Explicit Bootstrapping in ERP	ORANGE	LS out	Approval	Yes	Yes	approved	No		S3‑171379
		S3‑171380	Remove support of ERP Explicit Boostrapping	ORANGE	other	Approval	Yes	No	withdrawn	Yes
		S3‑171434	Remove support of ERP Explicit Boostrapping	ORANGE	CR	Agreement	Yes	Yes	revised	No	S3‑171531
		S3‑171531	Remove support of ERP Explicit Boostrapping	ORANGE	CR	Agreement	Yes	YesAdding the reference to the RFC in clause 2. Removing "in this release" in the NOTE, as commented by MCC.	agreed	No		S3‑171434
7.6.18	Other work items	S3‑171350	Alignment according to withdrawal of I-WLAN - Rel-13	Gemalto N.V.	CR	Agreement	Yes	YesQualcomm: this feature is not in 402, so it would be considered as a new feature. Is there a use case to have such scenario in 402? I don’t think we need to move this to 402. Gemalto: for EAP AKA in 4G we think it should be available in the 33.402 document. Qualcomm: I-WLAN features will be discontinued from Rel-13. This is a I-WLAN specific feature and we have no requirements for this in 402. BT: this scenario has no use cases. Deutsche Telekom and ORANGE agreed.	not pursued	No
		S3‑171419	TS 33.402 - Align with CT1 TS 24.302 for obtaining IMEI using Mobile Equipment Identity signalling	Nokia	other	Agreement	Yes	No	withdrawn	Yes
		S3‑171423	Alignment according to withdrawal of I-WLAN feature - Rel-14	Gemalto N.V.	CR	Agreement	Yes	Yes	not pursued	No
		S3‑171439	TS 33.402 - Align with CT1 TS 24.302 for obtaining IMEI using Mobile Equipment Identity signalling	Nokia	CR	Agreement	Yes	Yes	agreed	No
8	Studies
8.1	Study on IMS Enhanced Spoofed Call Prevention and Detection (FS_ESCAPADES) (Rel-14)
8.2	Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)	S3‑171064	TR 33.885 EN Cleanup Sec 3.1	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171065	TR 33.885 EN Cleanup Sec 4	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171066	TR 33.885 EN Cleanup Sec 5	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171067	TR 33.885 EN Cleanup Sec 5.3	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171068	TR 33.885 EN Cleanup Sec 5.5	Huawei, HiSilicon	pCR	Decision	Yes	YesNokia suggested a rewording of the note. Vodafone: it is strange that the TR has different solutions depending on the region. The text should say that some countries have strong requirements some have not.	revised	No	S3‑171476
		S3‑171476	TR 33.885 EN Cleanup Sec 5.5	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171068
		S3‑171069	TR 33.885 EN Cleanup Sec 5.7	Huawei, HiSilicon	pCR	Decision	Yes	Yes	merged	No	S3‑171476
		S3‑171070	TR 33.885 EN Cleanup Sec 5.8	Huawei, HiSilicon	pCR	Decision	Yes	YesChange from "requirements" to "potential requirements".	approved	No
		S3‑171071	TR 33.885 EN Cleanup Sec 5.9	Huawei, HiSilicon	pCR	Decision	Yes	YesVodafone had issues with the sentence above the note. Huawei: we assume that the V2X service is the LTE service. Authentication of V2X enabled UE is ambiguous. Vodafone: there are many inaccurate issues here, we shouldn’t send the TR for approval. What’s the purpose if the TR is not accurate enough? The Chair commented that we can send the TR for approval and stop the work anyway. Alf (Docomo): are we going to use this TR for further work? We have the TS already. Marcus (Huawei): bad idea to withdraw the TR.	revised	No	S3‑171477
		S3‑171477	TR 33.885 EN Cleanup Sec 5.9	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No		S3‑171071
		S3‑171072	TR 33.885 EN Cleanup Sec 5.11	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171073	TR 33.885 EN Cleanup Sec 5.16	Huawei, HiSilicon	pCR	Decision	Yes	Yes	merged	No	S3‑171478
		S3‑171312	V2X key issue enhanced	Nokia	pCR	Decision	Yes	YesVodafone: to have the means for trust/confidence would be a better rewording.	revised	No	S3‑171478
		S3‑171478	V2X key issue enhanced	Nokia	pCR	Decision	Yes	Yes	approved	No		S3‑171312
		S3‑171074	TR 33.885 EN Cleanup Sec 6	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171075	TR 33.885 EN Cleanup Sec 6.1.1	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171076	TR 33.885 EN Cleanup Sec 6.3	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171110	Update of V2X UE privacy solution with LI support	LG Electronics	pCR	Approval	Yes	Yes	approved	No
		S3‑171077	TR 33.885 EN Cleanup Sec 6.5	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171078	TR 33.885 EN Cleanup Sec 6.6	Huawei, HiSilicon	pCR	Decision	Yes	Yes	revised	No	S3‑171479
		S3‑171479	TR 33.885 EN Cleanup Sec 6.6	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No		S3‑171078
		S3‑171079	TR 33.885 EN Cleanup Sec 6.8	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171080	TR 33.885 EN Cleanup Sec 6.9	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171081	TR 33.885 EN Cleanup Sec 6.12.2	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171082	TR 33.885 EN Cleanup Sec 6.13	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171083	TR 33.885 EN Cleanup Sec 6.14.2	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171084	TR 33.885 EN Cleanup Sec 6.15	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171421	TR 33.885: conclusion on V2X Entities Secure Environment	Gemalto N.V.	pCR	Approval	Yes	Yes	revised	No	S3‑171480
		S3‑171480	TR 33.885: conclusion on V2X Entities Secure Environment	Gemalto N.V.	pCR	Approval	No	YesORANGE: subscription credentials resides in the USIM in the 3GPP, but for non 3GPP where do they reside? UICC is a better term than USIM. Gemalto agreed. This would be consistent with TS 33.402. ORANGE agreed as well. Vodafone: What entity in the UICC has these credentials? This was taken offline and finally approved.	approved	No		S3‑171421
		S3‑171085	TR 33.885 EN Cleanup Sec Annex D	Huawei, HiSilicon	pCR	Decision	Yes	YesMCC commented that the link should be added to the references clause of the document.	revised	No	S3‑171481
		S3‑171481	TR 33.885 EN Cleanup Sec Annex D	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No		S3‑171085
		S3‑171086	TR 33.885 EN Cleanup Sec Sec Annex X	Huawei, HiSilicon	pCR	Decision	Yes	Yes	approved	No
		S3‑171482	Draft TR 33.885	Huawei	draft TR	Approval	Yes	YesVodafone commented that they preferred to have this specification withdrawn and not to be sent for approval.	approved	No
		S3‑171483	Cover sheet TR 33.885	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
8.3	Study on Architecture and Security for Next Generation System (FS_NSA) (Rel-14)
8.3.1	Security architecture	S3‑171248	Annex for 5G security architecture	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171263	Question and interim agreement for AUSF in visited network	Huawei, Hisilicon	pCR	Approval	Yes	No	withdrawn	Yes
		S3‑171262	Question and interim agreement for co-location of the SCMF and the SEAF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171415
		S3‑171415	Question and interim agreement for co-location of the SCMF and the SEAF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171560	S3‑171262
		S3‑171560	Question and interim agreement for co-location of the SCMF and the SEAF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171415
		S3‑171230	a solution of key isolation in inter-AMF mobility	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171283	Update of solution #1.36 for SEAF realization via AMF (KI #1.2)	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171098	pCR to align interim agreement on KI#1.3 and KI#1.4	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑171211	Interim agreement for UP integrity	Huawei, Hisilicon	pCR	Approval	Yes	YesVodafone: it's not clear where the application resides. TIM commented that the group should try to make fundamental questions instead of making 1000 questions. Vodafone: I said that before, we should go and put content in the TS instead. Nokia: we don’t need in phase one, it should be left to the operator. Ericsson pointed out that it overlapped with 279.	noted	No
		S3‑171316	Question and Interim Agreements on Key Issue # 1.3: User plane integrity between UE and network	Samsung	pCR		Yes	Yes	revised	No	S3‑171561
		S3‑171561	Question and Interim Agreements on Key Issue # 1.3: User plane integrity between UE and network	Samsung	pCR	-	Yes	Yes	approved	No		S3‑171316
		S3‑171349	UP Integrity KI and requirements	Nokia	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171210	solution for UP security negotiationV3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171352	UP Integrity solution	Nokia	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171243	Interim Agreement for KI1.5 on integrity for uplink NAS signalling	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171244	Interim Agreement for KI1.5 and KI1 6	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171331	pCR to provide an update to the Key Issue #1.5 to add a PDU session authorization token in the NAS SM signalling	Qualcomm Incorporated	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171431	Comments on S3-171331 as well as 1329, 1330 pCR to provide an update to the Key Issue #1.5 to add a PDU session authorization token in the NAS SM signalling	Nokia	response	Agreement	Yes	YesQualcomm disagreed with the paragraph where the Nokia states that the UE is happy with the 3GPP network is talking to an ext DN the UE is associated with. Orange supported Nokia. ORANGE: Relationship between external DN and operator. The same as EAPS AKA*. Qualcomm: only some of the allowed roaming networks have a relation with the DN AAA.	left for email approval	No
		S3‑171232	interim agreement for KI#1.7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑171556
		S3‑171276	Trust model and key hierarchy discussion for Next Generation systems (KI #1.7)	Ericsson	pCR	Discussion	Yes	Yes	left for email approval	No
		S3‑171277	New key hierarchy proposal for Next Generation systems (KI #1.7)	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171274	Discussion on security for multiple NAS connections (KI #1.7)	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑171275	New solution for the protection of multiple NAS connections (KI #1.7)	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171286	Questions and agreements for key issue #1.7 on key hierarchy related to NAS security	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑171558
		S3‑171558	Questions and agreements for key issue #1.7 on key hierarchy related to NAS security	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171286
		S3‑171287	Questions and interim agreement for key issue #1.7 on key hierarchy related to core network keys	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑171556
		S3‑171556	Questions and interim agreement for key issue #1.7 on key hierarchy related to core network keys	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171287
		S3‑171289	Questions and agreements for key issue #1.7 on key hierarchy related to the access network and air interface protection keys	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑171559
		S3‑171559	Questions and agreements for key issue #1.7 on key hierarchy related to the access network and air interface protection keys	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171289
		S3‑171290	Overall presentation of contributions proposing questions and interim agreements for key issue #1.7 on key hierarchy	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑171251	Solution for key hierarchy in 5G phase1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171249	Interim agreement for the key hierarchy	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171054	Key hierarchy when using UP security function	ZTE, China Unicom	pCR	Approval	Yes	Yes	left for email approval	No		S3‑170697
		S3‑171313	Resolution of ENs in solutions 1.23 and 1.24	Nokia	pCR		Yes	Yes	left for email approval	No
		S3‑171215	Interim agreement for support security on service based architecture in 5G phase 1	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: what is a service based architecture? Huawei: covered in SA2, it should be studied. ORANGE: I prefer to have a contribution where it is explained how the security is impacted. Vodafone: which requirements and key issues is this question related to? Huawei: we will update with the key issue associated. Ericsson: we need to address it if it is in the SA2 TS. Vodafone: this refers to something that doesn’t belong to phase one,as we defined in a table in December. Huawei replied that this is not in that table. China Mobile: we need to answer whether we need security for the service architecture.	noted	No
		S3‑171247	5G security architecture discussion	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171261	Soltuion for service based architecture	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171278	Discussion on the feasibility of the support and negotiation of a PDU Session specific-security features (KI #1.16)	Ericsson	pCR	Discussion	Yes	Yes	left for email approval	No
		S3‑171279	Questions and interim agreements on the granularity of the UP protection (KI #1.16)	Ericsson	pCR	Approval	Yes	YesORANGE didn’t agree with having E1X22 in phase one. Ericsson agreed with delaying this in phase one but pointed out it was coming from the TR.	revised	No	S3‑171562
		S3‑171562	Questions and interim agreements on the granularity of the UP protection (KI #1.16)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171279
		S3‑171280	Solution for a PDU session-specific security negotiation (KI #1.16)	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171242	Interim Agreement for KI1.18	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171563
		S3‑171563	Interim Agreement for KI1.18	Huawei, Hisilicon	pCR	Approval	Yes	YesRemoving any reference of the solution for KDF negotiation as proposed by ORANGE. Agreement is TBD.	approved	No		S3‑171242
		S3‑171239	Clarification for KDF negotiation	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171240	Clarification for solution #1.13	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171344	N3GPP access key issue and agreement	Nokia, Qualcomm, Intel, Huawei, Broadcom	pCR	Approval	Yes	YesDependant of tdoc 341.	revised	No	S3‑171566
		S3‑171566	N3GPP access key issue and agreement	Nokia, Qualcomm, Intel, Huawei, Broadcom	pCR	Approval	Yes	Yes	approved	No		S3‑171344
		S3‑171346	draft_reply to SA2 on S2-172523 n3gpp authentication for re-registration	Nokia	LS out	Approval	Yes	YesQualcomm commented that option 2 is better, in order to minimise the impact on the UE. The NAS message should be kept the same. Vodafone: option 2 protects the identities more than option 1.This should be added in the response to the LS. Ericsson: the privacy solution is handled separately and it will be similar for both options. We support option one, achieving an architecture that is agnostic to the access. Nokia: privacy concerns are the same for both options, the parameters are the same. We agree with Ericsson. BT preferred option one because it was simpler for them. Huawei and Intel went for option one.Intel commented that the first option was simpler to implement for CT1. Huawei: if we have a privacy solution for option one equal to what we have in LTE, it's fine. 3GPP and non-3GPP accesses should have the same privacy protection.	revised	No	S3‑171488
		S3‑171488	Reply to SA2 on S2-172523 n3gpp authentication for re-registration	Nokia	LS out	Approval	Yes	Yes	approved	No		S3‑171346
		S3‑171341	N3gpp access merged Call flow	Nokia, Qualcomm, Intel, Huawei, Broadcom	pCR	Approval	Yes	YesT-Mobile: Update the call flow to address the privacy of the user identity (reflect what is encrypted and so on).	revised	No	S3‑171565
		S3‑171565	N3gpp access merged Call flow	Nokia, Qualcomm, Intel, Huawei, Broadcom	pCR	Approval	Yes	Yes	approved	No		S3‑171341
		S3‑171318	New Key Issue in response to in ETSI TC CYBER on middlebox security	Home Office, BT, Telefonica	pCR	Approval	Yes	YesVodafone supported this contribution. BT suggested the change of some requirements to adjust to this. Qualcomm: it’s more appropiate to look at this from the access and core network point of view, a separate study item would be required. Nokia: is this relevant to the other 5G work we are doing? I think it isn't. Nokia: it's about inter operator links. Sprint disagreed. Docomo: Who authorizes the middleboxes to be there? It's premature before seeing protocols that can support this. NCSC: hop by hop doesn’t have an issue. Security across domains is the key issue here and needs to be recorded. Vodafone: at application level, is the middle box for them as well? Home Office: the intention is that it is transparent for them.	noted	No
		S3‑171340	New Solution response to work in ETSI TC CYBER on middlebox security	Home Office, BT, Telefonica	pCR	Approval	Yes	Yes	noted	No
		S3‑171175	Key Issue on Handover within 5G Systems	NEC EUROPE LTD	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171174	Questions and Interim Agreements on Security for Handover within 5GS	NEC EUROPE LTD	pCR	Approval	Yes	YesNokia: we don’t need a question for this. Ericsson doubted whether the first question was needed. Handover will be studied but this contribution depends on other contributions that need to be agreed as well. They depend on the strcuture of the TR. Qualcomm: why do we need this question for the study?Of course we need to study it in phase one,it's obvious.	noted	No
		S3‑171207	Interim Agreement for KI#1.21	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: Anti-DoS atack? Huawei: solutions in phase one for DoS attack to the core network. ORANGE proposed some rewording: should antiDoS attack protection be addressed? Huawei agreed. Qualcomm: UP or CP attacks? KPN: we have a key issue referring to the signalling. Ericsson: already discussed but not agreed. Not appropiate to have a mechanism to detect bad behaving User Equipments. Juniper Networks: DoS attacks is a huge topic. We need to narrow it down. KPN: we have tdoc 386 with a more detailed approach on DoS attacks.	merged	No	S3‑171564
		S3‑171374	Protecting EAP messages between 3GPP Network and external DN-AAA server	Nokia	pCR	Approval	No	No	withdrawn	Yes
		S3‑171375	Protecting EAP messages between 3GPP Network and external DN-AAA server	Nokia	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171386	Interim agreement on DoS	KPN	pCR	Approval	Yes	YesEricsson: it is not realistic to have mechanisms like this at the core network. T-Mobile commented that it is not sufficient to solve such problems from the UE side. ORANGE supported this question. Nokia disagreed with the question, Qualcomm needed some rewording.	revised	No	S3‑171564
		S3‑171564	Interim agreement on DoS	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑171386
		S3‑171241	A security solution for SMS over NAS	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171176	Update of Solution #1.31	NEC EUROPE LTD	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171177	Update of Solution #1.32	NEC EUROPE LTD	pCR	Approval	Yes	Yes	left for email approval	No
8.3.2	Authentication	S3‑171125	Interim Agreements: How to implement increased home control in EPS AKA*	Ericsson	pCR	Approval	Yes	YesEricsson: This shows that the solution from Nokia in 373 is not valid. Nokia: in this case remove Note 1. Docomo:How does the UE know when to do what? Nokia: When it does the 5G authentication. NAS protocol between the UE and the 5G core must be different from the 4G core so the UE knows it's in the 5G network. It was suggested to add an editor's note on the need of deciding between the solution in 376 and 314.	revised	No	S3‑171500
		S3‑171500	Interim Agreements: How to implement increased home control in EPS AKA*	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171125
		S3‑171166	Questions related to Termination of EAP method in key issue #2.1	China Mobile	pCR	Approval	Yes	YesQualcomm: we have this already in the TS.	noted	No
		S3‑171167	Questions related to the Usability of legacy USIM in key issue #2.1	China Mobile	pCR	Approval	No	Yes	revised	No	S3‑171351
		S3‑171195	Interim Agreement Analysis and Impact of Primary Authentication	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171197	Interim Agreement for 5G NR Primary Authentication Alternative	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171250	Interim agreement for the anchor key	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171326	Proposed questions and agreements on the derivation of the anchor key	Qualcomm Incorporated	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171351	Questions related to the Usability of legacy USIM in key issue #2.1	China Mobile, KPN	pCR	Approval	Yes	YesQualcomm: why not Rel-99 USIM? Nokia: Rel-99 USIMs can be used for LTE access. This is not correct. Docomo: From Rel-99 to Rel-8, there is a new separation bit, so the USIMs are different. Oberthur: there are other non security features that differ Rel-99 and Rel-8 SIMs. The first question doesn't work, you need to update the card.It will never attach to 5G. Deutsche Telekom: then ,the answer is no. Oberthur: 5G authentication will never happen. KPN: so we all get rid of all SIM cards in the World? What happens to my customers? Oberthur: you can send new SIMs or update them. TIM: operators will not throw milllions of SIMs away because of 5G. This wasn't defined in SA1. Vodafone agreed with the question one. ORANGE: this is valid for legacy SIMs. TIM: this is a generic issue, not privacy. TIM: if we have any doubt these requirements, we need to ask SA1. ORANGE: we need to study technically this, not for business reasons. SA1 cannot decide that. Gemalto supported ORANGE. This is a security group, we need to study if there is a security issue and we don’t know the conclusions yet. G&D supported ORANGE's position. We need to consider the USIM evolution. Deutsche Telekom and Telia Sonera supported ORANGE's proposal as well. Gemalto: if we answer no to the questions, it doesn’t mean that we have to replace all USIMs. Qualcomm supported ORANGE. TIM objected to this contribution. The Chair asked if this question blocked the work. It didn’t seem to be the case. He also pointed out that the question needed some clarification. Nokia suggested to discuss this in a conference call. BT commented that the impact on the UICC appears on the CR cover, so this can be discussed further depending on the technical issue. The Chair commented that there is no restric rule for that and that it was better to reach an agreement beforehand in a conference call. It was decided to have a conference call to clarify this contribution: questions on the use of legacy USIMs.	noted	No		S3‑171167
		S3‑171400	pCR to TR 33.899 on granularity of anchor key binding to serving network	Nokia	pCR		Yes	Yes	left for email approval	No
		S3‑171187	Solution2.12 handling Privacy and Meeting LI Requirements in all Scenarios	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171189	MASA Response to Evaluation# 2.	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171191	MASA handling OUT of Sequence Scenario	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171192	MASA Modular Approach	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171193	MASA Update	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171194	MASA crypto analysis conclusion	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171204	MASA support 4G USIM and clarification.	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171198	EPS-AKAi: A primary authentication solution for 5G NR access	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171212	update interim agreement on reducing the impact of secert key lekage	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171233	interim agreement for KI#2.4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171231	add evaluation of solution #2.29	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171234	interim agreement for KI#2.8	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171368	Question and interim agreement on support for secondary authentication by an authenticator in the Data network	Nokia	pCR		No	No	withdrawn	Yes
		S3‑171372	Question and interim agreement on support for secondary authentication by an authenticator in the Data network	Nokia	pCR	Approval	Yes	Yes	noted	No
		S3‑171329	EAP based secondary authentication with PDU session authorization information	Qualcomm Incorporated	pCR	Approval	Yes	YesDiscussed with 1331, and 1431.	noted	No
		S3‑171387	EAP based Secondary authentication with an external Authenticator	Nokia	pCR	Approval	Yes	YesQualcomm: the justification is very weak for the EAP authentication by an external authenticator. Ericsson didn’t suppor this either. Deutsche Telekom: it looks similar to 329. where we didn’t want to overload the authentication with additional features.	noted	No		S3‑170749
		S3‑171378	Question and Interim Agreement on linking increased home control to subsequent procedures	Nokia	pCR		Yes	YesHuawei: is this going to an informative annex? Ericsson: what do we have to decide now that this is going to be informative? Docomo: it can only be informative. Remove the "informative". Ericsson: we don’t need to agree now that this is going to be a guidance.	revised	No	S3‑171494
		S3‑171494	Question and Interim Agreement on linking increased home control to subsequent procedures	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171378
		S3‑171398	Question and agreement on granularity of anchor key binding to serving network	Nokia	pCR		Yes	Yes	left for email approval	No
		S3‑171052	EPS Authentication with hiding keys assisted by UE - EPS AKA+	ZTE, China Unicom	pCR	Approval	Yes	Yes	left for email approval	No		S3‑170608
		S3‑171206	Update solution 2.11 for KI 1.21 interim agreement	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171213	agreement on support ERP	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: we don’t need this in 5G. Qualcomm and Ericsson commented that the answer should be "no in phase one". This was agreed.	revised	No	S3‑171567
		S3‑171567	agreement on support ERP	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171213
8.3.3	Security context and key management	S3‑171055	Hiding keys exchanged between serving network nodes	ZTE	pCR	Approval	Yes	Yes	left for email approval	No		S3‑170611
		S3‑171209	Security threats of key issue #3.3 “Principles of security negotiation”	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
8.3.4	RAN security	S3‑171407	drfat_LS On Clarifications on false eNB detection to RAN groups	Nokia	LS out	Approval	Yes	YesDeutsche Telekom: is this for the eNodeB or for the gNodeB? Nokia: will change for gNodeB.	revised	No	S3‑171568
		S3‑171568	LS On Clarifications on false eNB detection to RAN groups	Nokia	LS out	Approval	Yes	Yes	approved	No		S3‑171407
		S3‑171315	Interim Agreements on Key Issue # 4.1: AS security during RRC idle mode	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑171151	Clarifications on solution #4.10 (detection type solution)	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171131	Questions and agreements on key issue #4.2 Security requirements on the gNB	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑171130	Update of Key issue #4.2 Security requirements on gNB	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171199	Resolving Editors Notes in Security requirements on gNB Potential security requirements V3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171146	Update of KI #4.4 and questions and agreements on KI #4.4	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑171571
		S3‑171571	Update of KI #4.4 and questions and agreements on KI #4.4	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171146
		S3‑171253	Editor’s Note for Key Issue #4.4	Huawei, Hisilicon	pCR	Approval	Yes	YesOverlaps with 146. China Mobile supported this.	left for email approval	No
		S3‑171145	Key issue update, questions and agreements for key handling in state transition from RRC_INACTIVE state to RRC_CONNECTED state	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑171573
		S3‑171573	Key issue update, questions and agreements for key handling in state transition from RRC_INACTIVE state to RRC_CONNECTED state	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171145
		S3‑171160	Conclusion and interim agreements for KI# 4.4 and KI #4.7	China Mobile	pCR	Approval	Yes	YesThe first part overlaps with 1146. Huawei supported the Interim agreement in E.4.7..Both were agreed.	revised	No	S3‑171572
		S3‑171572	Conclusion and interim agreements for KI# 4.4 and KI #4.7	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑171160
		S3‑171150	Security solution on mobility in RRC_INACTIVE state	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171161	Update of Key Issue #4.7	China Mobile	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171200	backward security for RRC inactive state to RRC active state	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171201	Anti-DDOS for RRC inactive state to RRC active state	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171149	Security solution for key handling in state transition from RRC inactive state to RRC connected state	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171246	Solution for key Handling in RRC Inactive state to RRC active state transition	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171157	Question for NG2 handover	China Mobile, Huawei	pCR	Approval	Yes	YesOverlaps with 1153. It was agreed to merge the question with E.4.9 in 1153.	merged	No	S3‑171569
		S3‑171205	Questions and interim agreement for NG2 handover procedure	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	No	withdrawn	Yes
		S3‑171179	Intra AMF, Intra SMF, Inter NG RAN handover without Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171180	Intra AMF, Inter SMF, Inter NG RAN handover without Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171181	Inter AMF, Intra SMF, Inter NG RAN handover without Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171182	Inter AMF, Inter SMF, Inter NG RAN handover without Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171266	pCR to 33.899: Updates to Key agreements to key issue #4.14	Intel	pCR	Approval	Yes	Yes	approved	No
		S3‑171152	Minor clarification on KI #4.14 regarding constant RAN level identifiers	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171158	Questions for security of Xn handover	China Mobile	pCR	Approval	Yes	Yes	merged	No	S3‑171569
		S3‑171188	Conclusion and interim agreements for KI # 4.11 & 4.15	Huawei, Hisilicon	pCR	Approval	Yes	YesIt overlaps with 1153. Ericsson: too early for E4.15.	revised	No	S3‑171570
		S3‑171570	Conclusion and interim agreements for KI # 4.11 & 4.15	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171188
		S3‑171159	Questions for Security algorithm negotiation between UE and RAN	China Mobile	pCR	Approval	Yes	YesOverlaps with 1153. Ericsson: it’s the same as our document so we can merge. Huawei didn’t agree that they were the same. Qualcomm: how to define the negotiation? Leave the Interim agreement TBD. It was decided to merge with 1153.	merged	No	S3‑171569
		S3‑171178	Inter NG RAN Handover with Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171186	Solution for forward and backward security of Xn handover	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171153	Questions and interim agreements for KI #4.5, KI #4.6, KI #4.9, KI #4.12, KI #4.15, KI #4.16, KI #4.17	Ericsson	pCR	Approval	Yes	YesQualcomm: E4.17, do we need this level of detail in the questions? Huawei liked the questions as they were.It was agreed to leave it as it was.	revised	No	S3‑171569
		S3‑171569	Questions and interim agreements for KI #4.5, KI #4.6, KI #4.9, KI #4.12, KI #4.15, KI #4.16, KI #4.17	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No		S3‑171153
8.3.5	Security within NG-UE
8.3.6	Authorization	S3‑171048	Section 5.6.3.3.1, Key Issue Details	InterDigital, Inc.	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171046	Section 5.6.4.2.2 - Resolution of Editor’s Notes	InterDigital, Inc.	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171047	Section 5.6.4.3.2 - Resolution of Editor’s Notes.	InterDigital, Inc.	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171284	Resolution of the editor’s notes in solution #6.4	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
8.3.7	Subscription privacy	S3‑171101	Evaluations and conclusions in clause 7	TELECOM ITALIA S.p.A.	pCR	Approval	Yes	Yesmerged in 508 for evaluation and 509 for the conclusions.	merged	No	S3‑171508
		S3‑171141	Conclusion_bidding_down_aspects_privacy_(was_S3-170879)	Ericsson, Nokia, Vodafone	pCR	Approval	Yes	Yes	merged	No	S3‑171509
		S3‑171208	IMSI privacy solutions evaluation & Discussion	Huawei, Hisilicon	pCR	Approval	Yes	YesDeutsche Telekom:LI requirements need to be Yes, as we have seen in their LS during this meeting. Huawei agreed, as an outcome of this meeting it will be updated. Nokia: "it increases the number of times" we don’t know how many times MCC+MNC is sent. Vodafone: it isn't clear how to integrate this document into the TR. Huawei: evaluation parts can be merged into the evaluation. The Chair replied that the best option give the lack of time would be to add an additional section for this document. Ericsson wasn't happy with the table and with the overall document. They commented that in some parts it seems that they are promoting their own solutions. Due to these and other concerns the document was noted.	noted	No
		S3‑171335	pCR to provide an evaluation on the solutions for identity privacy	Qualcomm Incorporated	pCR	Approval	Yes	YesEricsson didn’t agree with a big part of this document,es pecially the second section. Vodafone proposed to add computation at the UE China Mobile: the conclusion is not complete because other solutions are not considered. It's not valid either cause it uses different situations for the comparisons. Ericsson: there are some agreements in this conclusion. China Mobile: why there are no issues with the UE having incorrect symmetric key? Ericsson agreed that this wasn’t mentioned. Revised to address comments from Ericsson, Nokia and Interdigital.	merged	No	S3‑171509	S3‑170838
		S3‑171136	KI#7.2_question_agreement_imsi_priv_privay_in_phase1	Ericsson, Nokia, Vodafone, Intel, KPN, LGE, China Mobile, CATT, NEC, Juniper Networks, T-Mobile, Telenor, Deutsche Telekom, Morpho, IPCom, Telecom Italia	pCR	Approval	Yes	YesHuawei queried about the emergency calls. Vodafone: Protected identity will impact emergency calls? This is an open issue. BT: Non-3GPP accesses are in scope? E.g. using MAC addresses. Vodafone: it’s still the IMSI for these kind of accesses. BT: in WLAN there is a solution proposed by Apple, for example. Interdigital: what are we trying to protect here? The IMSI? Nokia: Subscription permanent identifier is what we try to protect here. Huawei: it's allowed without subscriptions. Vodafone: most countries forbid this, without subscription. ORANGE: format of the subscription identifier is not defined in SA3. Interdigital: in the TR we have a subscription identifier definition. It's not clear what we want to protect here. ORANGE: the definition is for us alone, not for the overall 3GPP. SA2 is working on the subsucription identifier. Ericsson: is the complete identifier protected? That's an issue as well. On the emergency call part, Vodafone preferred "long term" over "permanent subscription identifier".Nokia replied that that would be a different key issue. A note was added for this.	revised	No	S3‑171511
		S3‑171511	KI#7.2_question_agreement_imsi_priv_privay_in_phase1	Ericsson, Nokia, Vodafone, Intel, KPN, LGE, China Mobile, CATT, NEC, Juniper Networks, T-Mobile, Telenor, Deutsche Telekom, Morpho, IPCom, Telecom Italia	pCR	Approval	Yes	Yes	approved	No		S3‑171136
		S3‑171137	KI#7.2_quesions_imsi_priv_solution_types	Ericsson, Nokia, Vodafone, Intel, KPN, LGE, China Mobile, CATT, NEC, Juniper Networks, TeliaSonera, Deutsche Telekom, T-Mobile, Morpho, IPCom, Telecom Italia	pCR	Approval	Yes	Yes	approved	No
		S3‑171138	KI#7.2_agreements_imsi_priv_solution_types	Ericsson, Nokia, Vodafone, Intel, LGE, China Mobile, CATT, NEC, Juniper Networks, Deutsche Telekom, T-Mobile, Morpho, IPCom	pCR	Approval	Yes	YesVodafone: wording is not correct ("significant hassles, last resort"). Second and third bullets were decided to be removed. AT&T: according to SA plenary, there is a phase going to an existing EPC core whereas a "1.5" phase it goes to the 5G core. The Chair confirmed that the understanding of "phase one" for SA3 is the one with 5G core. Interidigital: hard to answer the question when we don’t know what to protect. ORANGE: there are no contributions that address this issue. Qualcomm wanted to have HN pseudonym as possible solution in E72A2. ORANGE agreed with the answer no for that question. This was conceded by Qualcomm. Huawei disagreed with E72C2, but as it was the same discussion as the show of hands, the group procceeded with the "no". For E72D2, Huawei also disagreed. They proposed to have options for the privacy solution but ORANGE rejected this categorically. It was decided to agree with this one as well. AT&T: PKI management; there automated procedures for millions of them. There's no such complexity of PKIs.	revised	No	S3‑171513
		S3‑171513	KI#7.2_agreements_imsi_priv_solution_types	Ericsson, Nokia, Vodafone, Intel, LGE, China Mobile, CATT, NEC, Juniper Networks, Deutsche Telekom, T-Mobile, Morpho, IPCom,ORANGE	pCR	Approval	Yes	Yes	approved	No		S3‑171138
		S3‑171196	Interim Agreement Proposal for IMSI privacy	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171544
		S3‑171544	Interim Agreement Proposal for IMSI privacy	Huawei, Hisilicon	pCR	Approval	No	Yes	left for email approval	No		S3‑171196
		S3‑171297	Question to concealment of identifiers OTA - was 763-455	Nokia	pCR	Decision	Yes	Yes	noted	No
		S3‑171303	Question on synchronization and recovery - was 764	Nokia	pCR	Decision	Yes	YesDocomo: questions are too specific. Deutsche Telekom proposed to have a question on real identity, can an attacket force the UE to reveal the real identity? ORANGE supported it with some rewording (is it acceptable..?) KPN: the response would be NO. The rest of the questions were not generally supported so they were removed.	revised	No	S3‑171548
		S3‑171548	Question on synchronization and recovery - was 764	Nokia	pCR	Decision	Yes	YesContaining the agreed question	approved	No		S3‑171303
		S3‑171306	Proposed answers to questions on synchronization and recovery	Nokia	pCR	Decision	Yes	YesORANGE: no solutions for Over The Top for the 3GPP network.	noted	No
		S3‑171133	Questions for Key issue #7.2: Storage and configuration of key related to encryption of permanent identifiers	Ericsson	pCR	Approval	Yes	YesORANGE: we are not trying to specify 3GPP specific methods for the question "By which methods shall it be allowed to configure the keys related to concealing the permanent subscription identifier?". This was asked to be in the minutes. Suggested a third question: If mulitple entities are allowed which is their priority?This was agreed.	revised	No	S3‑171549
		S3‑171549	Questions for Key issue #7.2: Storage and configuration of key related to encryption of permanent identifiers	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171133
		S3‑171099	pCR to 33.899 to extend solution #7.7 on revealing long-term identity	KPN	pCR	Approval	Yes	Yes	noted	No
		S3‑171100	Updating solution #7.14 “Privacy protection of permanent or long-term subscription identifier using ABE”	TELECOM ITALIA S.p.A.	pCR	Approval	Yes	YesNokia: why deleting the first editor's note? It's still valid. Telecom Italia: One publick key is easier to trust than multiple keys. It is a question of simplicity. There are a lot of certification authorities, certificates and so on. This was agreed by Nokia. Vodafone: the issue is the management of the master key. What happens if it is compromised, how fast we can change it?That's our concern.	approved	No
		S3‑171143	Update_solution_#7.15_addressing_LI_aspects_(was_S3-170896)	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171163	pCR remove the editor’s note in solution #7.10	China Mobile	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171164	pCR update the solution #7.10	China Mobile	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171190	Solution for IMSI Privacy while meeting LI Requirements	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: evaluation for 2.12 should be taken into account. A note was added to address this. Nokia: as a general statement, we are not in favour of this kind of solution.	revised	No	S3‑171510
		S3‑171510	Solution for IMSI Privacy while meeting LI Requirements	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171190
		S3‑171259	Use of legacy USIM and NextGen ME in solution #7.12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171265	pCR to 33.899: Updates to Solution #7.2	Intel	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171295	Solution - Research Paper - Using pools of IMSIs and indicate in RAND - was 759-452	Nokia	pCR	Decision	Yes	Yes	left for email approval	No
		S3‑171296	Solution - Research Paper - Encrypted pseudonym transported in RAND - was 760-453	Nokia	pCR	Decision	Yes	Yes	left for email approval	No
		S3‑171142	Evaluations_two_pseudonym_solutions_(was_S3-170746)	Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171304	Solution on synchronisation and recovery	Nokia	pCR	Decision	Yes	Yes	left for email approval	No
		S3‑171305	Solution variant to 7.3 based on encrypted IMSI only - was 757	Nokia	pCR	Decision	Yes	Yes	revised	No	S3‑171553
		S3‑171553	Solution variant to 7.3 based on encrypted IMSI only - was 757	Nokia	pCR	Decision	Yes	Yes	approved	No		S3‑171305
		S3‑171308	Solution on efficient handling of privacy protected AV requests by HSS-AUSF or SLF	Nokia	pCR	Decision	Yes	Yes	left for email approval	No
		S3‑171327	Simplified symmetric key privacy solution that enable routing to multiple AUSFs	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑171332	PMSI usage in EAP-AKA'	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No		S3‑170833
		S3‑171333	pCR to update solution #7.4: Privacy enhanced Mobile Subscriber Identifier (PMSI) to clarify the PMSI synchronization	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No		S3‑170836
		S3‑171334	pCR to provide an evaluation on the solution #7.4 Privacy enhanced Mobile Subscription Identifier (PMSI)	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No		S3‑170837
		S3‑171336	pCR to provide an evaluation on the solutions for identity privacy	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No		S3‑170832
		S3‑171140	KI#7.3_KI#7.5_KI#7.7_KI#7.8_KI#7.9_questions_agreements	Ericsson, Intel	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171270	pCR to TR 33.899: Securing the permanent device identifiers.	Intel	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171267	pCR to 33.899: Updates to Key Issue #7.1	Intel	pCR	Approval	Yes	Yes	revised	No	S3‑171546
		S3‑171546	pCR to 33.899: Updates to Key Issue #7.1	Intel	pCR	Approval	No	Yes	left for email approval	No		S3‑171267
		S3‑171269	Discussion for Securing and refreshing the temporary subscriber identifiers.	Intel	discussion	Discussion	Yes	Yes	left for email approval	No
		S3‑171298	Question to concealment of temporary identifiers - was 765-456	Nokia	pCR	Decision	Yes	YesVodafone: define the frequencies at which the refresh occur. This should be included in the questions (standardise triggers for refresh). No agreement has been made for that.	revised	No	S3‑171550
		S3‑171550	Question to concealment of temporary identifiers - was 765-456	Nokia	pCR	Decision	Yes	YesEricsson disagreed with the way that their question from 7.4 was integrated here. Ericsson will bring a contribution for the next meeting to address their concerns for question (1).	approved	No		S3‑171298
		S3‑171165	Questions related to concealing permanent subscription identifier in key issue #7.1	China Mobile	pCR	Approval	Yes	Yes	noted	No
		S3‑171235	interim agreement for KI#7.1	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE didn’t agree with the UE being able to trigger a temp id refresh procedure.	merged	No	S3‑171550
		S3‑171139	KI#7.1_KI#7.4_questions_agreements_GUTI	Ericsson, Intel	pCR	Approval	Yes	Yes	merged	No	S3‑171550
		S3‑171203	Interim Agreement for Using effective temporary or short-term subscription identifiers	Huawei, Hisilicon	pCR	Approval	Yes	Yes	postponed	No
		S3‑171236	interim agreement for KI#7.4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	postponed	No
		S3‑171097	pCR to TR33.899 - corrections to solution 7.2	VODAFONE Group Plc	pCR	Agreement	Yes	Yes	left for email approval	No
		S3‑171202	Generate Temporary or short-term subscription identifiers by Random Number Generator	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171268	pCR to TR 33.899: Securing and refreshing the temporary subscriber identifiers.	Intel	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171361	Dynamic pseudonyms as short-term subscription identifiers	TELECOM ITALIA S.p.A.	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171301	Question to slice identifier protection - was 767-204	Nokia	pCR	Decision	Yes	YesORANGE: the key issue is not about correlation of the slice id and the subscription id. Qualcomm agreed. Nokia: the question is here because there was a discussion in the Busan adhoc and this is still an open issue. Vodafone: No difference with the situation of having two base statiion with two network ids. Vodafone: Why the extra protection of the NSSAI if we have privacy protection for the subscriber already? Interidigital: we don’t need it. It all was reduced to the question of the need of the extra protection for NSSAI. It was commented that the issue was more about confidentiality protection. Vodafone: It's purely about slicing, not the privacy. BT: you can identify the customer by the slice he's using, so Vodafone is wrong.	revised	No	S3‑171551
		S3‑171551	Question to slice identifier protection - was 767-204	Nokia	pCR	Decision	Yes	Yes	approved	No		S3‑171301
		S3‑171302	Agreement to slice identifier protection	Nokia	pCR	Decision	Yes	YesQualcomm: it shall be supported (optional to use). Vodafone: we need for phase one a clear statement of what needs to be protected. T-Mobile: this means no confidentiality protection in phase one. ORANGE: not crutial for phase one. Vodafone: capability yes. Ericsson: not in phase one. BT: not on phase one. NEC: wait for SA2 procedures to finish this discussion. Nokia: they are waiting for us. Huawei: not for phase one. Docomo: not for the initial registration but for the subsequent use of the slice. ORANGE and NEC were fine with this. ORANGE: we need an answer for this meeting. ORANGE: we say no and we work more on this when discuss the solution. Ericsson agreed, but some companies disagreed. The Chair proposed as suggested by ORANGE: NSSAI shall be confidentiality protected whenever NAS confidentiality protection is enabled. This was agreed. Vodafone objected to the answer of this question being agreed in this meeting as many issues have been identified that need further thought before concluding on this interim agreement	revised	No	S3‑171552
		S3‑171552	Agreement to slice identifier protection	Nokia	pCR	Decision	Yes	Yes	approved	No		S3‑171302
		S3‑171144	Update_KI_#7.9_privacy_aspects_of_MCC_MNC_(was_S3-170748)	Ericsson	pCR	Approval	Yes	YesVodafone: it doesn't addess the case of miultiple subscriptions for the same user.	noted	No
		S3‑171367	Comments on S3-171144, Privacy aspects of MCC/MNC in IMSI	InterDigital, Inc., AT&T	discussion	Decision	Yes	YesVodafone: even if I give you a random number I can guess your identity by identifying other factos like the time you turn on, or the places you appear, etc.. There's no such thing as real privacy. Ericsson: Encrypting MSIDN it will be more complex to track someone. T-Mobile: IMSI catcher needs close proximity and knowledge of the user. Interdigital: hability to know the information by catching ovber the air is the real issue. Deutsche Telekom: don’t forget that these are options for the operators and that in some countries they will not be allowed to use it. If we raise the bar too high and design an overly complex solution, we take the risk that it will not be used at all. Docomo supported this; it needs to be taken into consideration. No apparent agreement between companies since their positions were quite fixed.	noted	No
		S3‑171299	Question to full protection of permanent identifier - was 766-203	Nokia	pCR	Decision	Yes	Yes	revised	No	S3‑171512
		S3‑171512	Question to full protection of permanent identifier - was 766-203	Nokia	pCR	Decision	Yes	Yes	approved	No		S3‑171299
		S3‑171300	Agreement to full protection of permanent identifier	Nokia, Ericsson, Intel, Qualcomm, Morpho, KPN, TNO	pCR	Decision	Yes	YesQualcomm: there may be other subscription identifiers rather than the IMSI, according to SA2. The Chair asked: shall the routing information be hidden at the air interface (question in 299)? Interidigital: preserving network policy should be optional (yes/maybe for the above question). The Chair proposed a show of hands: Show of hands per company for question in 299; who supports the response "no" (privacy protected)? Vodafone,KPN,ORANGE,Oberthur,Juniper,Intel,Ericsson,Nokia,LG,Deutsche Telekom, Docomo,IPCom,NEC,Qualcomm,UK government, US department of commerce, China Mobile. Same question, yes privacy protection: AT&T, TIM, Interdigital, BT,360,Huawei, Neul Limited Motorola Solutions abstained. The Chair commented that this could go to a technical vote for the next meeting if there was no agreement. AT&T proposed to go on with the "no" response so as not to waste time, Interdigital agreed. The Chair asked the group if it was OK to procceed with "no" as the response to 299. There was no opposition and the document was approved.	approved	No
		S3‑171162	pCR to adding new key issue: User location confidentiality	China Mobile	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171416	Key issue on location information protection	China Unicom, CATR	pCR		Yes	Yes	left for email approval	No
		S3‑171294	Key issues on identity probing - was 758-458	Nokia	pCR	Decision	Yes	Yes	left for email approval	No
		S3‑171354	New Key issue avoiding IMSI paging	Nokia	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171364	New key issue avoiding IMSI paging	Nokia	pCR	Approval	No	No	withdrawn	Yes
		S3‑171417	Key issue on subscribed service information protection	China Unicom, CATR	pCR		Yes	Yes	left for email approval	No
		S3‑171293	Discussion on resubmission of S3-170758-759-760-763-765-766-767	Nokia	pCR	Decision	Yes	Yes	noted	No
		S3‑171498	Evaluations and conclusions in clause 7 updated as a result of FS_NSA conference calls	Vodafone	pCR	Approval	Yes	YesIssues in 5.7.4.4.4 for Qualcomm. Telecom Italia commented that they had comments since the Tenerife meeting for the evaluation of 7.14. Nokia commented that there were some other conclusions for 5.7.5 from other companies that could be added here. It was seen that a better solution would be to have a separate document for this. AT&T: What part of the IMSI needs to be protected must be very clear.	revised	No	S3‑171508
		S3‑171508	Evaluations and conclusions in clause 7 updated as a result of FS_NSA conference calls	Vodafone	pCR	Approval	Yes	Yes	approved	No		S3‑171498
		S3‑171509	Conclusions in clause 7	Vodafone	pCR	Approval	Yes	YesContains the conclusions of S3-171101 as well.	approved	No
8.3.8	Network slicing security	S3‑171281	Discussion on network slice isolation (KI #8.1)	Ericsson, Nokia	pCR	Discussion	Yes	Yes	left for email approval	No
		S3‑171282	Questions and interim agreements on Network Slice-sepcific keys (KI #8.1)	Ericsson, Nokia	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171399	Network Slice Corrections to clause 5.8.3.1	Nokia,Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171155	Evaluation for Network Slicing Security Solution #8.7	CATT	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171156	Network Slicing Security Architecture and General Procedure	CATT	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171154	Questions and interim agreements for KI #8.3	CATT	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171168	Questions and agreement for KI #8.2	China Mobile	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171169	Questions and agreement for KI #8.3	China Mobile	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171254	Questions and agreement for KI8.2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171255	Questions and agreement for KI8.3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171402	Network Slice Corrections to clause 5.8.3.2	Nokia,Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171053	Update of solution 8.5	ZTE	pCR	Approval	Yes	Yes	left for email approval	No		S3‑170609
		S3‑171256	Interim Agreement for KI8.4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171403	Network Slice Correction to clause 5.8.3.4	Nokia,Ericsson	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171257	Interim Agreement for KI8.5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171258	Interim Agreement for KI8.7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
8.3.9	Relay security
8.3.10	Network domain security	S3‑171401	Key issue details for clause 5.10.3.2.1	Nokia	pCR		Yes	Yes	left for email approval	No
		S3‑171404	Threats alignment between 5.10.3.2.2 and 5.3.3.1.2	Nokia	pCR		Yes	Yes	left for email approval	No
		S3‑171405	Addition of requirements for 5.10.3.2.3	Nokia	pCR		Yes	Yes	left for email approval	No
		S3‑171406	Enhancing solution 10.1	Nokia	pCR		Yes	Yes	left for email approval	No
8.3.11	Security visibility and configurability	S3‑171307	Additional privacy related questions for security visibility and configurability - related to S3-170852	Nokia	pCR	Decision	Yes	Yes	revised	No	S3‑171557
		S3‑171557	Additional privacy related questions for security visibility and configurability - related to S3-170852	Nokia	pCR	Decision	No	Yes	left for email approval	No		S3‑171307
		S3‑171108	Questions and agreement for Security area #11: Security visibility and configurability	LG Electronics	pCR	Approval	Yes	Yes	merged	No	S3‑171557
		S3‑171237	interim agreement for KI#11.1 and #11.2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171238	interim agreement for KI#11.3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171102	Update of key issues of security area #11 Security visibility and configurability	LG Electronics	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171107	Conclusion for Security area #11: Security visibility and configurability	LG Electronics	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171103	Update of solution #11.2 Security visibility solution	LG Electronics	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171104	Update of solution #11.3 Security configurability solution	LG Electronics	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171105	Update of solution #11.4 UE trigger of key and ID refresh	LG Electronics	pCR	Approval	Yes	Yes	left for email approval	No
		S3‑171106	Procedure for UE security indication and configuration	LG Electronics	pCR	Approval	Yes	Yes	left for email approval	No
8.3.12	Credential provisioning
8.3.13	Interworking and migration
8.3.14	Small data
8.3.15	Broadcast/Multicast security
8.3.16	Management Security	S3‑171260	Network slice life-cycle security update	Huawei, Hisilicon	pCR	Approval	Yes	Yes	left for email approval	No
8.3.17	Cryptographic algorithms
8.3.18	Other	S3‑171441	Reply LS on secure storage and processing of subscription credentials within the NG UE	ETSI TC SCP	LS in		Yes	Yes	noted	No
		S3‑171023	Reply LS on security in E-UTRA-NR Dual Connectivity	R2-1703961	LS in		Yes	Yes	replied to	No
		S3‑171485	Reply to: Reply LS on security in E-UTRA-NR Dual Connectivity	Qualcomm	LS out	approval	Yes	YesSA3 is still analyzing the three options, so no final decision has been made in SA3 during this meeting.	approved	No
		S3‑171010	Reply LS on security in E-UTRA-NR Dual Connectivity	C1-171941	LS in		Yes	Yes	noted	No
		S3‑171021	LS to SA3 on actions for integrity check failure on SgNB	R2-1703959	LS in		Yes	Yes	replied to	No
		S3‑171484	Reply to: LS to SA3 on actions for integrity check failure on SgNB	Huawei	LS out	approval	Yes	Yes	approved	No
		S3‑171029	Reply LS on N2 and N3 reference points for 5G system	R3-171401	LS in		Yes	Yes	noted	No
		S3‑171036	LS on Security Aspects Related to Non-3GPP authentication for (re)registration	S2-172523	LS in		Yes	Yestdoc 346 addresses this issue.	replied to	No
		S3‑171037	LS on E-UTRA in NG-RAN (5G System)	S2-172730	LS in		Yes	Yes	noted	No
		S3‑171039	Reply LS to LS on state of SA3 discussions on NG security architecture	S2-172861	LS in		Yes	YesVodafone: Combining two different PLMNs, two different accesses, two different technologies? Having two different Home Networks? This is what the LS implies. Orange supported Vodafone. Qualcomm: it's not about having two HPLMNs.	noted	No
		S3‑171040	LS on 5GS Security aspects seeking resolution	S2-172862	LS in		Yes	Yes	replied to	No
		S3‑171489	Reply to: LS on 5GS Security aspects seeking resolution	Nokia	LS out	approval	Yes	YesVodafone strongly disagreed with "the NSSAI shall be confidentiality protected whenever a NAS security context is available (as far as regulation allows)". They also suggested to remove explanation on the rule about interim agrements going to the TS. Nokia commented that this was coming from interim agreements already approved. This is a SA3 working procedure. ORANGE also expressed their concerns on questioning such working procedures.	approved	No
		S3‑171058	LS on Use of the long-term identities for Charging in the VPLMN for 5G	S3i170148	LS in		Yes	Yes	noted	No
		S3‑171041	LS on Use of the long-term identities for Charging in the VPLMN for 5G	S5-171890	LS in		Yes	Yes	noted	No
		S3‑171063	LS on IMSI availability in the VPLMN	S3i170167	LS in		Yes	YesVodafone: Multiple subscriptions with different IMSIs has never been discussed in 5G. Deutsche Telekom: if this hasn't been addressed in SA1 or SA2, let's not worry about it. Nokia: we assume that the UE hasn't been tampered with and the mechanism is to stop the home network relying from the visited network in the three approaches. Home Office: in SA3-Li we are happy without multiple subscriptions if this is the assumption. T-Mobile: Solution one is preferred.	replied to	No
		S3‑171490	Reply to: LS on IMSI availability in the VPLMN	T-Mobile	LS out	approval	Yes	Yes	approved	No
		S3‑171089	Liaison Statement on 5G Identity and Access Management	GSMA	LS in		Yes	YesBT: their concern here is the identities in IoT.We would duplicate work that is being done. Vodafone: we will get requirements from SA1, not from here.	noted	No
		S3‑171443	Reply LS on NAS SM integrity protection	S1-172226	LS in	discussion	Yes	Yes	noted	No
		S3‑171444	LS on Closed Subscriber Group in 5GS	S1-172425	LS in	discussion	Yes	YesQualcomm: wait for SA2 and RAN to see if the CSGs are the same as in LTE. Oberthur: there are no specific requirements from SA1 for this. Vodafone: they want to use this in phase one, although there is no use case. It was decided to postpone since the next SA3 meeting would before SA1's.	postponed	No
		S3‑171583	draft TR 33.899	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
8.4	Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)	S3‑171043	LS on mission critical communication interworking security issues	S6-170463	LS in		Yes	Yes	replied to	No
		S3‑171121	[FS_MC_SEC] Adding MSCCK functionality for back-compatibility into evaluation clause	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑171452
		S3‑171452	[FS_MC_SEC] Adding MSCCK functionality for back-compatibility into evaluation clause	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑171121
		S3‑171009	LS on MCData protocol and choice of media plane protocol	C1-171820	LS in		Yes	Yes	replied to	No
		S3‑171453	Reply to: LS on MCData protocol and choice of media plane protocol	NCSC	LS out	approval	Yes	Yes	approved	No
		S3‑171113	[FS_MC_SEC] MCData Payload security	NCSC	pCR	Approval	Yes	YesAirbus: no mechanisms for OTA distribution? NCSC: not defined yet, this is done for alignment.	approved	No
		S3‑171114	[FS_MC_SEC] MCData Key Management	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑171454
		S3‑171454	[FS_MC_SEC] MCData Key Management	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑171114
		S3‑171115	[FS_MC_SEC] MCData Key Distribution	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑171455
		S3‑171455	[FS_MC_SEC] MCData Key Distribution	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑171115
		S3‑171122	[FS_MC_SEC] MCData Evaluation	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑171120	[FS_MC_SEC] Evaluation of Application Signalling Protection (Sol #1.4)	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑171392	[FS_MC_Sec] 33880 pCR editorial updates	Motorola Solutions Danmark A/S	pCR	Approval	Yes	Yes	revised	No	S3‑171456
		S3‑171456	[FS_MC_Sec] 33880 pCR editorial updates	Motorola Solutions Danmark A/S	pCR	Approval	Yes	Yes	approved	No		S3‑171392
		S3‑171461	Draft TR 33.880	NCSC	draft TR	Approval	Yes	Yes	approved	No
		S3‑171462	Cover sheet TR 33.880	NCSC	TS or TR cover	Approval	No	No	withdrawn	Yes
		S3‑171525	Revised SID MCPTT	NCSC	SID revised	Agreement	Yes	YesThe SID was revised to keep working in TR 33.880 introducing the new activity in Rel-15.	agreed	No
8.5	Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)	S3‑171024	LS on paging remote UEs over relays	R2-1703967	LS in		Yes	Yes	noted	No
		S3‑171032	Reply LS on UE-to-NW relaying	S2-170398	LS in		Yes	Yes	postponed	No
		S3‑171034	LS on PC5 Secure Communication	S2-171621	LS in		Yes	Yes	postponed	No
		S3‑171221	The skeleton of TR 33843	Huawei, Hisilicon	pCR	Approval	Yes	YesMCC pointed out that the template was wrong. ORANGE asked what this had to do with REAR, but it was pointed out that it was in the approved study.	revised	No	S3‑171575
		S3‑171575	The skeleton of TR 33843	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171221
		S3‑171222	The reference of TR 33843	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171223	The scope of TR 33843	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171577
		S3‑171577	The scope of TR 33843	Huawei, Hisilicon	pCR	Approval	No	Yes	left for email approval	No		S3‑171223
		S3‑171224	key issue authentication and authorization	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	revised	No	S3‑171578
		S3‑171578	key issue authentication and authorization	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	YesMCC pointed out that better than mentioning SA1,SA2 and Rel-13 Prose, Rel-15 Prose and so on, there should be references to the referred documents and avoid mentioning working groups or Releases. Added an editor's note for alignment with TS 33.303.	approved	No		S3‑171224
		S3‑171411	New Key Issue on AKA via eRelay	KPN	pCR	Approval	Yes	Yes	revised	No	S3‑171579
		S3‑171579	New Key Issue on AKA via eRelay	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑171411
		S3‑171412	New Key Issue on attach via eRelay	KPN	pCR	Approval	Yes	Yes	revised	No	S3‑171580
		S3‑171580	New Key Issue on attach via eRelay	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑171412
		S3‑171413	New Key issue on Managing handovers of eRemote UE	KPN	pCR	Approval	Yes	Yes	noted	No
		S3‑171225	key issue security on service continuity	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171226	key issue security on discovery	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: alignment with 33.303 in an editor's note. MCC: avoid mentioning Releases, reference other specifications.	revised	No	S3‑171581
		S3‑171581	key issue security on discovery	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171226
		S3‑171227	key issue security of UP between eRemote UE and network	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171582
		S3‑171582	key issue security of UP between eRemote UE and network	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171227
		S3‑171228	key issue security of CP between eRemote UE and network	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑171229	discussion-authentication and authorization of eRemote UE	Huawei, Hisilicon	discussion	Discussion	No	No	withdrawn	Yes
		S3‑171576	Draft TR 33.843	Huawei	draft TR	Approval	No	Yes	left for email approval	No
8.6	Other study areas
8.6.1	Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)	S3‑171418	CR to TR33.926 on Adding a generic threat on “User Session Tampering”	TELECOM ITALIA S.p.A., KPN	other	Approval	Yes	No	withdrawn	Yes
		S3‑171438	CR to TR33.926 on Adding a generic threat on “User Session Tampering”	TELECOM ITALIA S.p.A., KPN	CR	Agreement	Yes	YesEricsson doubted whether this was required at all.	revised	No	S3‑171514
		S3‑171514	CR to TR33.926 on Adding a generic threat on “User Session Tampering”	TELECOM ITALIA S.p.A., KPN	CR	Agreement	Yes	Yes	agreed	No		S3‑171438
8.6.2	Study on Battery Efficient Security for very low Throughput Machine Type Communication Devices (FS_BEST_MTC_Sec)
8.6.3	Study on Security for Proximity-based Services (FS_ProSe_Sec)
8.6.4	TR on Security Assurance scheme for 3GPP network products (33.916) (SCAS-SA3TR)	S3‑171390	Resolution of editor's notes in 33.916	NTT DOCOMO	other	Agreement	Yes	No	withdrawn	Yes
		S3‑171420	Update of references to GSMA NESAS documents in TR 33.916	Deutsche Telekom AG	CR	Agreement	Yes	Yes	agreed	No
		S3‑171437	Resolution of editor's notes in 33.916	NTT DOCOMO	CR	Agreement	Yes	Yes	agreed	No
8.6.5	Other study items	S3‑171096	New WID on Study on Long Term Key Update Procedures	VODAFONE Group Plc	WID new	Agreement	Yes	YesBT: a lot of work will be done somewhere else.We will support the SID. TIM: the attacker will be able to find the new key after being compromised with the first one. What's the point? Vodafone: it's a way of better protecting yourself. Intel: remote SIM provisioning would be a solution for this? Vodafone: remote SIM provision is heavy and costly. It is not the only solution. Telia Sonera: it seems that you are ignoring the GSMA work. Vodafone: GSMA work may find different solutions that fit different use cases from us. Deutsche Telekom supported this SID. Vodafone commented that they have some potential solutions in mind and some examples can be found in TR 33.899. KPN supported this SID. Ericsson: is this related to 5G? Vodafone: it's applicable to 5G, but potentially to LTE, UMTS and so on. ORANGE: remove everything solution specific from the justification. We don’t need to say that we need something between the UE and the HSS, or that we will have a potential standard for that. This is coming from a solution in the TR 33.899 from 5G. China Mobile supported this SID. Gemalto: impacts of the algorithms.BT supported this. ORANGE: out of scope of 3GPP, it doesn't have to be part of the objectives. G&D: support of no algorithms in here. Other supporters were added (e.g. 360.) ORANGE: why changing the identifiers? We need a justification for this. Vodafone: it's part of the study.It's not a study about changing profiles between operators.ORANGE commented that they wanted this into the justification. G&D: identifiers can still be an output of the study, we can remove this statement to avoid confusion.	revised	No	S3‑171448
		S3‑171448	New WID on Study on Long Term Key Update Procedures	VODAFONE Group Plc	WID new	Agreement	Yes	Yes	agreed	No		S3‑171096
		S3‑171111	New SID on security aspects of 3GPP support of advanced V2X services	LG Electronics	SID new	Approval	Yes	Yes	noted	No
		S3‑171112	Updated SID on architecture enhancements for 3GPP support of advanced V2X services	LG Electronics	SID new	Approval	Yes	YesThe Chair commented that SA3 should do their own SID document and not integrate it wit the SA2 WID. BT commented that the low latency issue hasn't been dealt with and it is not included in the objectives. Huawei: this is way too early for us. I don’t believe that there is anything to look for us at this early stage. Qualcomm supported but better to wait for a couple of meetings until SA3 gets more material from SA2. ORANGE agreed. The number of companies agreeing to delaying were the same as the number of companies who wanted to start. The Chair commented that LG could bring the SID with contributions to have the work started if the progress in SA2 allowed to do that. The SID was noted.	noted	No
		S3‑171173	Discussion for User-to-User DDoS Attack Prevention	China Mobile	discussion	Endorsement	Yes	YesDocomo: have you seen this happening to the network? Do you think that standards can define interfaces to fix this? China Mobile confirmed that they have seen this happening. They don’t propose any solutions but they would like to address this. ORANGE: are you proposing a DoS from the user to the network? China Mobile: the attack comes from software, not the UE. ORANGE: do you foresee something that needs to be done in 3GPP? Does GSMA know this problem?It's more appropiate to raise this issue in there.	noted	No
9	Review and Update of Work Plan	S3‑171003	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
		S3‑171006	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑171446
		S3‑171446	Work Plan input from Rapporteurs	MCC	other	-	No	No	reserved	No		S3‑171006
10	Future Meeting Dates and Venues	S3‑171005	SA3 meeting calendar	MCC	other		Yes	Yes	noted	No
11	Any Other Business
12	Close