TDoc list

Tdoc List

2017-08-11 15:40

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‑171700	Agenda	WG Chairman	agenda		Yes	Yes	approved	No
3	IPR Reminder
4	Meeting reports
4.1	Approval of the report from SA3#87	S3‑171701	Report from SA3#87	MCC	report		Yes	YesFirst action item was not done (conference call by Nokia) and it will be carried out after the current meeting. China Mobile had held the conference call for the second action item: two contributions were discussed (by China Mobile and KPN). Some open issues with the NAS security when using the USIM. There were input documents for this meeting dealing with this topic.	approved	No
4.2	Report from SA #76	S3‑171703	Report from last SA meeting	WG Chairman	report		Yes	YesAlf (NTT-Docomo) attended the meeting as vice-chairman since Anand wasn’t available. Verizon asked about the LS from SA2 about emergency calls for Rel-15. Does this apply for specific deployments?This was taken offline. Vodafone thanked Alf for the effort on having the BEST TS approved in the meeting.	noted	No
4.3	Report from SA3-LI
5	Items for early consideration
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑171709	Reply LS on eDRX Configuration and IMSI-paging	C1-172392	LS in		Yes	Yes	noted	No
		S3‑171711	LS on Security for T8 interface	C3-173330	LS in		Yes	YesHuawei had a discussion paper on the subjexct in tdoc 1877, and a Study Item to support it. They were discussed as well and a reply was drafted.	replied to	No
		S3‑172076	Reply to: LS on Security for T8 interface	Huawei	LS out	approval	Yes	Yes	approved	No
		S3‑171712	Reply LS on eDRX Configuration and IMSI-paging	C4-173312	LS in		Yes	Yes	noted	No
		S3‑171757	proposed response LS to RAN2 - LS to SA3 on security keys in EN-DC and actions upon DRB IP check failure	VODAFONE Group Plc	LS out	Approval	No	No	withdrawn	Yes
		S3‑171914	Reply LS on security aspects with FEC and ROHC over MBMS	S6-171105	LS in		Yes	Yes	noted	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA
6.5	3GPP2
6.6	OMA
6.7	TCG	S3‑171768	TCG progress report	InterDigital, Inc.	other	Information	Yes	YesAlec (Interdigital) gave an update on the work of TCG.	noted	No
6.8	oneM2M
6.9	TC-CYBER	S3‑171713	Middlebox Security	ETSI TC CYBER	LS in		Yes	YesNokia commented that IETF is involved as well and that they are not keen on some topics of Middle Box security. Alex (BT) Commented that TC CYBER will respond to IETF in an LS.	postponed	No
6.10	ETSI NFV security
6.11	Other Groups	S3‑171714	LS to NGMN and ISG MEC regarding law enforcement requirements in MEC	ETSI TC LI	LS in		Yes	Yes	noted	No
		S3‑172066	Update on the status of the work on SSP (Smart Secure Platform)	ETSI TC SCP	LS in		Yes	YesVodafone commented that the progress in SCP is very slow and doubted about their ability to finish this on time. ORANGE commented that SCP has been warned that their work will not be included in the 3GPP specs if they don't finish on time.	noted	No
7	Work Areas
7.1	Security Assurance (Rel-15)
7.1.1	Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW)	S3‑171995	CR to TS 33.250_Authentication extension validation	NEC Corporation	CR	Agreement	Yes	Yes	revised	No	S3‑172119
		S3‑172119	CR to TS 33.250_Authentication extension validation	NEC Corporation	CR	Agreement	Yes	Yes	agreed	No		S3‑171995
		S3‑172027	CR to TS 33.250_Emergency PDN Connection Release	NEC Corporation	CR	Agreement	Yes	Yes	revised	No	S3‑172122
		S3‑172122	CR to TS 33.250_Emergency PDN Connection Release	NEC Corporation	CR	Agreement	Yes	Yes	agreed	No		S3‑172027
		S3‑171915	Resolving two editor’s notes about reuse of Charging ID and TEID	China Mobile, Telecom Italia, China Unicom	CR	Approval	Yes	YesEricsson agreed with the content but wasn't sure about placing it here. What is the tester doing with this statement?	revised	No	S3‑172123
		S3‑172123	Resolving two editor’s notes about reuse of Charging ID and TEID	China Mobile, Telecom Italia, China Unicom	CR	Approval	Yes	Yes	agreed	No		S3‑171915
7.1.2	Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB)	S3‑171854	eNB SCAS TS	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171868	AS Security Mode Command Procedurey	Huawei; Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑172126
		S3‑172126	AS Security Mode Command Procedurey	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171868
		S3‑171869	Bidding down prevention in X2-handovers	Huawei; Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑172127
		S3‑172127	Bidding down prevention in X2-handovers	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171869
		S3‑171870	AS Protection algorithm selection in eNB change	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑172028	pCR to TS 33.216_RRC and UP downlink ciphering at the eNB	NEC Corporation	pCR	Approval	Yes	YesEricsson: the precondition needs to be made similar to the rest of preconditions in the document. The UE should be simulated. BT: We need to be very strict to avoid having those keys getting out to the wild.	revised	No	S3‑172128
		S3‑172128	pCR to TS 33.216_RRC and UP downlink ciphering at the eNB	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑172028
		S3‑172124	Draft TS 33.216	Huawei	draft TS	Approval	No	Yes	approved	No
		S3‑172125	Cover sheet 33.216	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
7.1.3	Other
7.2	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)	S3‑171719	LS to SA3 on Counter Check Procedure and SCG SRB integrity check failure	R2-1706161	LS in		Yes	Yes	replied to	No
		S3‑172077	Reply to: LS to SA3 on Counter Check Procedure and SCG SRB integrity check failure	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑171720	Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity	R2-1707496	LS in		Yes	Yes	replied to	No
		S3‑172078	Reply to: Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑171721	LS reply on NR security input parameters	R2-1707498	LS in		Yes	Yes	replied to	No
		S3‑171722	LS to SA3 on security keys in EN-DC and actions upon DRB IP check failure	R2-1707501	LS in		Yes	Yes	replied to	No
		S3‑172079	Reply to: LS reply on NR security input parameters	Qualcomm	LS out	approval	Yes	Yes	approved	No
		S3‑172080	Reply to: LS to SA3 on security keys in EN-DC and actions upon DRB IP check failure	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑171840	Discussion on the handling of NR security capability	Huawei; Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑171841	Correction to living document of S3-171487	Huawei; Hisilicon	other	Approval	Yes	Yes	merged	No	S3‑172149
		S3‑172052	CR to TS 33.401_Update of CR on EN-DC	NEC Corporation	other	Approval	Yes	Yes	merged	No	S3‑172149
		S3‑172056	Updates to S3-171487 (CR to TS 33.401 for Option 3/3a/3x dual connectivity	VODAFONE Group Plc	draftCR	Approval	Yes	Yes	revised	No	S3‑172067	S3‑171487
		S3‑172067	revision of Updates to S3-171487 (CR to TS 33.401 for Option 3/3a/3x dual connectivity following comments	VODAFONE Group Plc	draftCR	Approval	Yes	YesEricsson didn’t agree with the X2 interface in figure E.1.2-1. Vodafone: RAN3 latest agreements confirm this. This was taken offline. Qualcomm: the eNodeB to support potential inputs to the same core block? This would be a premature decision and we need to discuss it with RAN2.	revised	No	S3‑172149	S3‑172056
		S3‑172149	revision of Updates to S3-171487 (CR to TS 33.401 for Option 3/3a/3x dual connectivity following comments	VODAFONE Group Plc	draftCR	Approval	Yes	Yes	approved	No		S3‑172067
		S3‑171923	Discussion on the signalling and negotiation of the NR security capabilities	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑171925	Mechanism for NR security capabilities signalling and negotiation	Ericsson	other	Approval	Yes	YesNokia: why do we need translation in the eNodeB? Ericsson: we want to avoid SgNB doing some kind of mapping to 5G language. Nokia doubted that a translation would be needed in phase one. Huawei: we need a LTE traditional procedure to support MeNodeB. They supported Nokia. Ericsson:The algorithms in 5G will be different from the ones in 4G, at least they will change in name.	noted	No
		S3‑171998	Adding bidding down security based on AS signalling to the EN-DC draft CR	Qualcomm Incorporated	other	Approval	Yes	YesQualcomm questioned combining LTE/NR in the same signalling as Ericsson proposed. They would support a negotiation where it is indicated the algorithms supported for LTE and for NR. Nokia: maybe we are creating a problem by defining two sets. The Chair clarified that cryptographic algortihms are the same in NR. Qualcomm: inputs to NR are not the same as in LTE since the bearer IDs are different. We should have separate bits to say these algos support LTE and these support NR. Qualcomm: Happy to do the /NAS based solution as long as we have separate bits for the NR capability and for the LTE capability. Ericsson: in the case the issue is that the legacy eNodeB doesn’t understand the new capabilities.All eNodeBs would need to be upgraded. Huawei: the NAS solution is the way to go. How do you transfer the capabilities to the MeNodeB? If you come to the Ericsson: MeNodeB from a legacy eNodeB handover (x2 interface) you will not get this information. Huawei: the legacy issue is not a priority now. The Chair commented that the general feeling is going for an AS based solution, but the Qualcomm proposal needed to be commented offline.	noted	No
		S3‑171924	Reply LS proposal on algorithm selection in E-UTRA-NR Dual Connectivity	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑171999	Proposed response LS on algorithm selection in E-UTRA-NR Dual Connectivity	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑171866	Discussion on the third key used for common PDCP	Huawei; Hisilicon	pCR	Approval	Yes	YesEricsson: the fact that the option one is not secure, or that they plan to use two keys, it's Huawei's interpretation but not what RAN2 implies. Ericsson: SgNodeB does not transfer any key from the MeNodeB.	noted	No
		S3‑172054	Draft Reply LS to R2-1707501	NEC Corporation	LS out	Approval	Yes	Yes	noted	No
		S3‑172032	Security Keys in EN-DC	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑172035	[DRAFT] Response LS on security keys in EN-DC and actions upon DRB IP check failure	Ericsson	LS out	Decision	Yes	YesEricsson: it would be acceptable if the eNodeB didn’t have integrity protection. We haven't agreed to make eNodeB user plane integrity mandatory, but it should be OK for the 5G core, packets are dropped. RAN2 may specify some recovery mechanisms for recovery of the dropped packets.	noted	No
		S3‑171920	[DRAFT] Reply LS to RAN2 on security keys in EN-DC and actions upon DRB IP check failure	China Mobile	LS out		Yes	Yes	noted	No
		S3‑172002	Discussion on the choice of keying method and impact of failed integrity protection check for UP traffic	Qualcomm Incorporated	other	Approval	Yes	Yes	merged	No	S3‑172149
		S3‑171814	Discussion on i/c LS R2-1706151 ENDC Security	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑172069	Further comments to Nokia S3-171814 Discussion on i/c LS R2-1706151 on DC bearers	Nokia	discussion	Endorsement	Yes	YesNokia: option one is pure Rel-13 dual connectivity. Ericsson: it's ok to use the same key as long as you don’t change the termination point; this was agreed in SA3 and in you are contradicting this decision here. Nokia: UE performance is affected when rekeying. Ericsson didn’t understand this issue: There weren't performance issues in the dual connectivity. There is no disruption of the service. Verizon: performance impact is not to be decided in SA3. RAN2 wants a good security solution.We should go for option 3. Qualcomm: option 3 has more complexity from the security perspective. Nokia: the number of keys exchanged is reduced and the performance is improved. Huawei pointed out that RAN2 would like a transparent process. Qualcomm: the transparent exchange cannot be achieved in terms of option 2 and option 3. Ericsson: transparency means that the network indicates the UE when to change the key. We have a different understanding of option one despite that most companies seem to go for this option. China Mobile: different keys for LTE PDCP and NR PDCP? Qualcomm: the algorithm is the same in both LTE and PDCP, it's only the message that changes. Ericsson: all three options are possible, but the principle in option one is the most important from the security point of view. Nokia agreed but leaving the door open for using the other two options in a specific circumstance. Qualcomm didn’t see the security gain for having the possibility of using the other two options. Nokia: we agreed and implemented option 1 in Rel-12. We should also agree at least on option 2. Huawei agreed.	noted	No
		S3‑171867	Draft LS reply R2-1707501	Huawei; Hisilicon	LS out	Approval	Yes	Yes	noted	No
		S3‑172003	Proposed response LS on security keys in EN-DC and actions upon DRB IP check failure	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑171837	Discussion on DRB integrity protection check failure	Huawei; Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑171985	Discussion on i/c LS R2-1706161 on DRB IP failure and counter check	Nokia	discussion	Approval	Yes	Yes	noted	No
		S3‑172000	Discussion on the details of the NR security algorithms	Qualcomm Incorporated	other	Approval	Yes	YesVodafone: SAGE would like to have requests the earlier the better. Conference calls with them, with decision power, would ease the process.	revised	No	S3‑172083
		S3‑172083	Discussion on the details of the NR security algorithms	Qualcomm Incorporated	other	Approval	Yes	Yes	approved	No		S3‑172000
		S3‑172001	Proposed reponse LS on NR security input parameters	Qualcomm Incorporated	LS out	Approval	Yes	YesEricsson: this is still being discussed, not decided in RAN2 yet. If this is changed, we need to know fast, we should tell RAN2. It's a bit early to involve SAGE now. Nokia: it's still OK to let SAGE know about this possible change of the number of bits. The sentence will be reworded to transfer the message to SAGE in any case. The Chair commented that it's better to be proactive and tell SAGE about the implications of RAN2's work given the timing implications. Nokia: there is no drastic change in the algorithms, it’s just a change of the range of a parameter. Don't involve SAGE yet. Ericsson: just put them in copy in the LS. Nokia: SAGE will know about this anyway, they will know through Vodafone about these discussions.	noted	No
		S3‑172055	Clarifications to the user plane integrity requirements in ENDC (option 3)	Ericsson	other	Approval	Yes	YesNTT-Docomo: eNodeBs in the future may need user plane integrity protection. The wording in E.1.2 should be changed. Ericsson agreed.	revised	No	S3‑172085
		S3‑172085	Clarifications to the user plane integrity requirements in ENDC (option 3)	Ericsson	other	Approval	Yes	Yes	approved	No		S3‑172055
		S3‑172084	DraftCR on EN-DC	Qualcomm,NEC,Ericsson,Huawei, HiSilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑172188	Solution for dual connectivity between MeNB and SgNB	Qualcomm,NEC,Ericsson,Huawei, HiSilicon,Nokia, Samsung, NTT-Docomo,Vodafone,BT	CR	Agreement	Yes	Yes	agreed	No
7.3	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)	S3‑171708	LS on Closed Subscriber Group in 5GS	S1-172425	LS in		Yes	Yes	noted	No
		S3‑171723	Reply LS on Closed Subscriber Group in 5GS	RP-171479	LS in		Yes	Yes	noted	No
		S3‑171730	Response LS on Support for fake gNB detection mechanisms	R1-1711997	LS in		Yes	YesNokia: we can’t decide which way to go since RAN2 hasn’t replied, only RAN1. It was decided to wait for RAN2's work.	noted	No
		S3‑171726	Reply to LS on State of SA3 discussions on NG security architecture	S2-174073	LS in		Yes	Yes	noted	No
		S3‑171734	LS reply on NAS SM integrity protection	S2-175289	LS in		Yes	Yes	noted	No
		S3‑171735	Reply LS on 5GS Security aspects seeking resolution	S2-175309	LS in		Yes	YesQualcomm: we need to discuss the second requirement on the inclusion of NSSAI in unprotected RRC signallling. There weren't any agreements on this issue so the LS was postponed. Ericsson commented that SA2 will complete their LS for their next meeting.	postponed	No
		S3‑172089	Reply to: Reply LS on 5GS Security aspects seeking resolution	Qualcomm	LS out	approval	No	No	withdrawn	Yes
		S3‑171728	LS on secure platform requirements	SP-170581	LS in		Yes	YesORANGE saw several problems with the definitions given in the CR for the SA1 TS. Besides, the requirement for 3GPP subscription credential is much wider in SA3. SA3 should send a LS to SA1 pointing out this. Vodafone commented that they had offered this CR, but personally, Tim commented that giving security terms and solutions in a SA1 specification seems to be very strange.Tim preferred that SA1 referred to a SA3 specification or to 21.905. Ericsson: the SA1 TS doesn’t belong to any phase. It's ok to specify these terms, we are going towards that direction anyway. Oberthur: SA1 decided already not to refer to SA3 specs in this case. Vodafone: SA plenary didn’t agree with SA1 and that was the reason why the CR was not accepted. Oberthur: if we do nothing, this will be a maintained working assumption. The plenary asked to finalise the work, so the requirement cannot be removed. If it is removed, the work won’t be complete. ORANGE commented that SA1 and SA3 should coordinate, so the result is to remove this requirement.	replied to	No
		S3‑172086	Reply to: LS on secure platform requirements	ORANGE	LS out	approval	Yes	YesEricsson was concerned that this would re-open long discussions in SA1. The SA1 TS is not phase specific.They have agreed on this topic and they were worried that SA3 would be bringing this phase approach to SA1. Ericsson asked to have minuted that they disagreed with the removal of the definition of subscription credential from the SA1 TS as this LS proposes. Sony had the same objection.	approved	No
		S3‑171729	Reply LS to IEEE 802.11 Requesting Status and Information on WLAN integration in 3GPP NextGen System	SP-170585	LS in		Yes	Yes	noted	No
		S3‑171731	LS on 5G Registration via Untrusted Non-3GPP Access	S2-174887	LS in		Yes	Yes	replied to	No
		S3‑172091	Reply to: LS on 5G Registration via Untrusted Non-3GPP Access	Lenovo	LS out	approval	Yes	Yes	approved	No
		S3‑171732	LS on Impacts of using User Identity confidentiality	S2-175263	LS in		Yes	Yes	replied to	No
		S3‑172090	Reply to: LS on Impacts of using User Identity confidentiality	Qualcomm	LS out	approval	Yes	Yes	approved	No
		S3‑171733	LS on PLMN and RAT selection policies for roaming	S2-175286	LS in		Yes	YesORANGE asked to postpone the LS until an answer is reveiced from CT1. Vodafone: this exists already. SA1 will challenge it. BT: the big issue is how to identify securely identify the beacon that tells us in which network we are in. Vodafone: this is about the network being able to move their subscribers for commercial reasons. Ericsson preferred to wait for the SA2 procedure before making a decision. The LS was postponed.	postponed	No
		S3‑171882	LS on Undetectability of LI Data stored in a UDSF	S3i170259	LS in		Yes	Yes	noted	No
		S3‑171883	Address Mapping Requirements	S3i170260	LS in		Yes	Yes	noted	No
		S3‑171912	LIAISON STATEMENT ON ZUC-256 algorithm	CCSA	LS in		Yes	Yes	noted	No
		S3‑172068	Response to CCSA liaison statement ZUC-256 algorithm (S3-171912)	ETSI SAGE	LS in		Yes	YesAlex (BT): we already have 256 bits, but we are not using them. Interfaces are for 128 bits. Ericsson:the key length is 256 bits but the algorithms need to be specified for 256 bits. There is a proposal from AT&T for a study (1773). It was concluded to check this document before deciding on a reponse. Interdigital: let's limit it to the radio access.	replied to	No
		S3‑172098	Reply LS on 256-bit algorithms for 5G	AT&T	LS out	approval	Yes	Yes	approved	No
		S3‑171796	Algorithm Identifier Values	Huawei, Hisilicon, CATR, CATT	pCR	Approval	Yes	YesKPN didn't agree with the requirements on individual elements like UE and gN ("shall implement.."). NTT-Docomo preferred the original structure like KPN. Nokia: this needs a proper paper to support this discussion. Better to postpone for the next meeting. Qualcomm: include only what's agreed in the TR (remove the requirements after "0011"). NTT-Docomo queried about having bit patterns. Why do we need this? It is stage 3. It was agreed to keep the bit pattern in order to have more control of this, as proposed by BT and Qualcomm.	revised	No	S3‑172092
		S3‑172092	Algorithm Identifier Values	Huawei, Hisilicon, CATR, CATT	pCR	Approval	Yes	Yes	approved	No		S3‑171796
		S3‑171904	pCR to TS33.501 - security requirements on subscription identifiers	CATT	pCR	Approval	Yes	YesVodafone: configurable by whom? CATT: by the operator. It was agreed to add this. Nokia: why should it be configurable? It doesn’t affect any interoperability scenario. NTT-Docomo: the MNO can decide about the refresh frequency. BT: does the first requirement imply integrity protection mandatory? Ericsson: privacy will be optional for the operator. SUPIs are never sent in clear text. Vodafone and China Mobile agreed. Interdigital: is the whole SUPI or the ID part of the SUPI being sent? It was agreed to have that SUPI should not transferred in clear air text over 5G RAN. Second requirement was removed.	revised	No	S3‑172115
		S3‑172115	pCR to TS33.501 - security requirements on subscription identifiers	Ericsson, Telecom Italia,CATT	pCR	Approval	Yes	Yes	revised	No	S3‑172173	S3‑171904
		S3‑172173	pCR to TS33.501 - security requirements on subscription identifiers	Ericsson, Telecom Italia,CATT	pCR	Approval	Yes	Yes	approved	No		S3‑172115
		S3‑171905	pCR to TS33.501 - skeleton and text for slice security clause	CATT	pCR	Approval	Yes	YesThe Chair asked the attendees whether slicing was part of phase two.Huawei said phase one, but Vodafone recalled having it for phase two, ORANGE: SUPI privacy has priority. Vodafone: slicing is being considered in other groups and we have been asked about NSSAI by LS.	noted	No
		S3‑171952	TS - Requirements on privacy management added to clause 5	Nokia	pCR	Decision	Yes	YesVodafone: it looks like we are mandating privacy in 5G. Ericsson: we don’t need to specify databases and interfaces for privacy issues. ORANGE supported this and Vodafone's comment. Ericsson: there are other ways to implement this. We can just put it in a informative annex. Vodafone: not clear what is mandatory and what is optional. ORANGE: some requirements are implementation specific. BT objected to this contribution. Qualcomm as well.	noted	No
		S3‑171777	Privacy: Skeleton proposal for privacy related sub-clauses	Ericsson, Telecom Italia	pCR	Approval	Yes	YesIt was also commented that privacy is also about personal data of a human being, and this wasn't covered here. Ericsson agreed but they mentioned having this in another contribution. They commented that it was better by starting like this and then mentioning the human factor. Huawei: find a better name for privacy key. ORANGE: privacy key is solution specific. Remove the definition. The Chair commented that it's more than just a key. ORANGE: the definition will be fine if we agree on the Ericsson's solution. We have to agree on that firstly. There were long discussions on the terminology to use: e.g. SUCI, SUPI identifier, etc.. This had to be taken offline.	revised	No	S3‑172150
		S3‑172150	Privacy: Skeleton proposal for privacy related sub-clauses	Ericsson, Telecom Italia	pCR	Approval	Yes	Yes	approved	No		S3‑171777
		S3‑171776	Privacy: Storage, processing and provisioning of the HN public key	Ericsson	pCR	Approval	Yes	YesDiscussed with 2087 and 2021. Ericsson: The current agreement is that the public key in the tamper resistant component, processing in the ME. Storage not supported, then there would be no privacy. Legacy Ues would be able to be used in this case.	revised	No	S3‑172151
		S3‑172151	Privacy: Storage, processing and provisioning of the HN public key	Ericsson, Orange, Oberthur Technologies, Morpho, Gemalto, China Mobile, Vodafone	pCR	Approval	Yes	YesQualcomm: we cannot allow the geneation of the SUCI in the tamper resistant component. ORANGE: Mandatory support of the new scheme has been agreed in another document. Nokia disagreed. Vodafone: subscription privacy is optional in 5G. Otherwise 5G won't be deployed in certain countries. Nokia: how often are you going to do this? This is adding complexity to lots of network components. NOTE 1 should be an editor's note. It is FFS. BT agreed with Vodafone: this may cause that 5G won't be deployed in certain parts of the World. China Mobile and BT supported to study further the legacy aspect.It was asked to be minuted the following statement from China Mobile:	approved	No		S3‑171776
		S3‑171787	Privacy: SUCI null-scheme normative Annex	Ericsson, Vodafone	pCR	Approval	Yes	YesDeutsche Telekom: in which cases the SUPI doesn’t need to be encrypted? Ericsson: some regulators could ask this. KPN: It should be optional for operators to deploy this. ORANGE: who is deciding to use the new scheme? BT: the LI requirement does not imply the encryption ON/OFF in the air interface. The VPLM's choice is whether to have it on/off and the HPLMN would act on it (procceed to switch off, or drop the session). Interdigital: this scheme is not required. All the comments were captured in editors' notes.	revised	No	S3‑172105
		S3‑172105	Privacy: SUCI null-scheme normative Annex	Ericsson, Vodafone	pCR	Approval	Yes	Yes	approved	No		S3‑171787
		S3‑171788	Privacy: SUCI ECIES scheme normative Annex	Ericsson	pCR	Approval	Yes	YesBT: is this quantum safe? Vodafone: we discussed before about quantum timescales being an issue. It's not an issue here. It was argued whether this could be optional or mandatory to support. This depended on the conclusions in other contributions. Ericsson: we need feedback from ETSI SAGE. We prpose to send an LS. Nokia: we need feedback from ETSI SAGE before adding this to an annex. Gemalto agreed. It was noted since companies agreed not to include this in the TS until some feedback was received from ETSI SAGE.	noted	No
		S3‑171789	Privacy: [DRAFT] LS on Security aspects of ECIES for concealing IMSI or SUPI	Ericsson	LS out	Approval	Yes	Yes	revised	No	S3‑172106
		S3‑172106	LS on Security aspects of ECIES for concealing IMSI or SUPI	Ericsson	LS out	Approval	Yes	YesGemalto:ask ETSI SAGE to improve the efficiency. What if companies bring a new scheme next meeting? Ericsson: this is open. IT was pointed out that the LS clarifies that this is a possible candidate.	approved	No		S3‑171789
		S3‑171779	Privacy: Text proposal in Clause 5.4 (visibility and configurability)	Ericsson, Telecom Italia	pCR	Approval	Yes	YesIt was agreed to send a LS to SA1 on the privacy aspects of SUPI privacy and 5G-GUTI privacy. Vodafone: the text in 5.4.2 needs rewording. Ericsson: it is taken from 5.4.1. It is existing text. It was agreed to enhance the wording.	revised	No	S3‑172107
		S3‑172107	Privacy: Text proposal in Clause 5.4 (visibility and configurability)	Ericsson, Telecom Italia,Qualcomm,Huawei,LG	pCR	Approval	Yes	YesBT and Vodafone: on what basis are you displaying to the user?	approved	No		S3‑171779
		S3‑172020	pCR : Security visibility and Configurability	Qualcomm Incorporated	pCR	Approval	Yes	YesEricsson didn’t agree with the user plane being negotiated on a per radio bearer basis. This hadn't been agreed by the group.This was removed. Discussed together with 897 from Huawei, that overlapped with the same topic.They were finally merged with 779.	merged	No	S3‑172107
		S3‑171778	Privacy: Requirements related to SUPI and SUCI	Ericsson, Vodafone, Telecom Italia	pCR	Approval	Yes	Yes	revised	No	S3‑172116
		S3‑172116	Privacy: Requirements related to SUPI and SUCI	Ericsson, Vodafone, Telecom Italia	pCR	Approval	Yes	Yes	approved	No		S3‑171778
		S3‑171781	Privacy: proposed changes to authentication procedures (6.1.2, 6.1.3)	Ericsson, Vodafone, Telecom Italia	pCR	Approval	Yes	Yes	revised	No	S3‑172117
		S3‑172117	Privacy: proposed changes to authentication procedures (6.1.2, 6.1.3)	Ericsson, Vodafone, Telecom Italia	pCR	Approval	Yes	Yes	approved	No		S3‑171781
		S3‑172021	pCR : 5GS Subscription Privacy General aspects	Qualcomm Incorporated	pCR	Approval	Yes	YesVodafone: storage of the key in the ME, you are not mentioning any security whatsoever, which is similar to the Ericsson contribution that I objected to. There are no reliable, cheap methods to update the mobile handset. Qualcomm: there are operators who think differently from Vodafone. China Mobile: the public key can be put in the ME. Ericsson: the public key is public by definition, why do we need to protect it?	merged	No	S3‑172151
		S3‑171830	UE sends SEAF Concealed IMSI during Primary Authentication	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: we are encrypting IMSI again, this has been encrypted already. NAS encryption enabled will do it. Huawei: when NAS encryption is disabled, we need to encrypt it. ORANGE: in that case we don’t care about privacy. Ericsson: this annex is too complex. No one agreed with this contribution.	noted	No
		S3‑171782	Privacy: proposed content to 6.8.1 (SUPI)	Ericsson, Vodafone, Telecom Italia	pCR	Approval	Yes	YesORANGE opposed to having the editor's note on Privacy provisioning. Gemalto went for having only the first sentence in the editor's note. This was finally agreed. Huawei commented that the clause was more about the SUCI than the SUPI. It was decided to find an appropiate title for 6.8.1.	revised	No	S3‑172118
		S3‑172118	Privacy: proposed content to 6.8.1 (SUPI)	Ericsson, Vodafone, Telecom Italia	pCR	Approval	Yes	Yes	approved	No		S3‑171782
		S3‑171899	CR to 33.501: Privacy of the Subscriber permanent identifier	Intel Corporation (UK) Ltd	pCR		Yes	No	withdrawn	Yes
		S3‑171783	Privacy: 5G-GUTI related requirements and security procedures (6.8.2, 5.1, 5.3)	Ericsson, Telecom Italia	pCR	Approval	Yes	YesORANGE: the part about the tampering-resistant hardware needs to go away. Gemalto: ECIES, not decided whether it is mandatory or optional. It should go away too. Disagreement on the architecture of AUSF and SIDF in 5.Y.1. This part was removed. Merged with 904.	merged	No	S3‑172115
		S3‑171903	Secure paging using scrambling temporary subscriber identifier	Intel Corporation (UK) Ltd	pCR		Yes	No	withdrawn	Yes
		S3‑171784	Privacy: proposed content to 6.8.3 (identification procedure)	Ericsson, Vodafone, Telecom Italia	pCR	Approval	Yes	YesORANGE: the last note is normative, it shouldn't be a note. Is it a "may" or a "shall"? NTT-Docomo: this may not be required. Qualcomm commented that this is not required and that they had a contribution on this last note. It was an open issue.	noted	No
		S3‑171785	Privacy: [DRAFT] Reply LS on Impacts of using User Identity confidentiality	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑172017	Impacts of IMSI/SUPI privacy on UE Identity handling procedures	Qualcomm Incorporated	other	Approval	Yes	YesEricsson: the procedure doesn't have security concerns. Let SA2 deal with this. Verizon: there are security concerns when sending the SUPI. Nokia: SA2 has defined the registration procedure with the SUPI. They have to adapt their procedure accordingly to what SA3 proposes. We don’t need an extra message as Ericsson proposes since it's already there. Huawei: if the AMF doesn’t need the message with the temporary ID it has to request the identity of the user. Something needs to be done. Qualcomm: in that scenario in 4G it's a reject from the MME. So a new attach is performed. That's what the AMF will do, reject so the process restarts. Nokia: SA2 can use the identity request procedure as well, but they may not want it for non-3GPP networks.	noted	No
		S3‑172018	Proposed Reply LS on Impacts of using User Identity confidentiality	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑171786	Privacy: SUCI format and generation	Ericsson, Vodafone	pCR	Approval	Yes	YesORANGE: we don’t need to mention the privacy key here, the text remains consistent.	revised	No	S3‑172143
		S3‑172143	Privacy: SUCI format and generation	Ericsson, Vodafone	pCR	Approval	Yes	Yes	approved	No		S3‑171786
		S3‑171946	TS - LI compliance when applying subscriber privacy	Nokia	pCR	Decision	Yes	Yes	revised	No	S3‑172082
		S3‑172082	TS - LI compliance when applying subscriber privacy	Nokia	pCR	Decision	No	YesNTT-Docomo wasn't sure whether this worked for the already proposed schemes. An editor's note was proposed to warn about this. Ericsson: it's simpler is to send the SUPI when the NAS security is turned ON. Huawei supported this. Ericsson: Let's not make a decision in this meeting and analyze how to fulfil the LI requirement for the next meeting. NTT-Docomo: keep the headline to have a placeholder. Arguments for a solution should be brought for the next meeting. Nokia: keep the assumption. Some companies disagreed with this.	noted	No		S3‑171946
		S3‑171790	Privacy: Discussion for drafting reply to S2-175309, relates NSSAI privacy	Ericsson	discussion	Agreement	Yes	YesBT commented that the concept of slice is not fully understood in SA3, so this should go for phase 2. ORANGE suppported this. Ericsson, Nokia, Oberthur, Intel,KPN, China Mobile, LG,NEC wanted this for phase 2 as well. Interigital, Qualcomm,CATT, Gemalto and AT&T preferred to treat this in phase one. NTT-Docomo: if we don’t do protection in phase one, can we do it in phase two? ORANGE commented that we needed to know what was being protected, and SA3 didn’t have information about that. Nokia: they are still discussing the business models in SA1. Qualcomm: why are SA1 and SA2 including the NSSAI parameter in phase one then?this is puzzling. AT&T: we are defining the 5G core in phase one. This would mean that we would be having slices without security, and this is not acceptable. Nokia: the registration procedure in slicing becomes a very complicated procedure, this is currently being discussed in SA2.	noted	No
		S3‑172062	NSSAI privacy clarification	LG Electronics	discussion	Endorsement	Yes	YesQualcomm: if some operators wants privacy protection, why should they wait for phase two? CATT supported Qualcomm.	noted	No
		S3‑172004	Discussion on the privacy considerations of NSSAI	Qualcomm Incorporated	pCR	Approval	Yes	YesBT: either encrypt all or encrypt nothing, otherwise you allow to correlate stuff.	noted	No
		S3‑171950	TS - NSSAI privacy	Nokia	pCR	Decision	Yes	YesCATT didn’t agree with this contribution.	noted	No
		S3‑172005	Proposed response LS on 5GS Security aspects seeking resolution	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑171791	Privacy: [DRAFT] Reply to Reply LS on 5GS Security aspects seeking resolution	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑172022	Some corrections and clarification to the authentication text	Qualcomm Incorporated	pCR	Approval	Yes	YesMerged with 970.	revised	No	S3‑172145
		S3‑172145	Some corrections and clarification to the authentication text	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑172022
		S3‑171984	Rename EPS AKA* to 5G AKA	Nokia	pCR		Yes	YesIt was decided to rename it to 5G AKA.	approved	No
		S3‑171857	Clarification on authentication method selection in AUSF	Huawei; Hisilicon	pCR	Approval	Yes	YesNokia: we are having discussions for non-3GPP accesses. It is possible that EPS AKA* will also go for non-3GPP accesses as currentlty discussed in SA2. Add an editor's note about this. Qualcomm: we have an interim agreement, don’t add the editor's note now. NTT-Docomo: why are we having these requirements here instead of in a requirements clause? It was decxided to postpone it.	postponed	No
		S3‑171970	Need for key left at the AUSF	Nokia, Ericsson	pCR		Yes	YesORANGE preferred to remove the feature. Merged with 2022.	merged	No	S3‑172145
		S3‑171972	Computation of key left at the AUSF for EPS AKA*	Nokia	pCR		Yes	Yes	noted	No
		S3‑171973	Computation of key left at the AUSF for EAP-AKA’	Nokia	pCR		Yes	Yes	noted	No
		S3‑172006	Providing details on the calculation of keys for the AUSF and SEAF	Qualcomm Incorporated	pCR	Approval	Yes	YesEricsson supported the changes in the editor's notes. Nokia: you are creating an intermediate layer and move everything to the AUSF. This organization seems dubious.Ericsson supported Nokia. Huawei supported this contribution. Offline discussions were needed to procceed.	noted	No
		S3‑171982	Granularity of anchor key binding	Nokia	pCR		Yes	Yes	revised	No	S3‑172186
		S3‑172186	Granularity of anchor key binding	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171982
		S3‑171958	EPS AKA* to be used over all access network types – clause 6	Nokia	pCR		Yes	Yes	noted	No
		S3‑171967	Clarification on how the authentication method, and the variant is chosen between AUSF and UDM/ARPF	Ericsson	pCR	Approval	Yes	YesORANGE: remove the note on the Annex B. Nokia: first sentence in the removed note should stay.	revised	No	S3‑172146
		S3‑172146	Clarification on how the authentication method, and the variant is chosen between AUSF and UDM/ARPF	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171967
		S3‑171759	Lightweight secure way for protecting anchor key transmitting - EAP-AKA’	ZTE Corporation	pCR	Approval	Yes	YesNokia, NTT-Docomo didn’t agree with the document, especially on the AUSF computing the generated encoding key that is described here. China Mobile agreed with this being a lightweight solution. They have contribution 935 related to this one. Ericsson didn’t see how this worked. Both documents were noted.	noted	No
		S3‑171935	pCR Security enhancement to the EAP-AKA'	China Mobile	pCR		Yes	Yes	noted	No
		S3‑171983	Derivation of anchor key for EAP-AKA’	Nokia	pCR		Yes	Yes	noted	No
		S3‑172037	pCR to TS 33.501_Update to EAP-AKA’	NEC Corporation	pCR	Approval	Yes	YesNokia: this doesn’t work for EAP-AKA'.	noted	No
		S3‑171940	pCR Adding Editor’s note to the EPS-AKA* and EAP-AKA'	China Mobile	pCR		Yes	YesNokia: I'm not convinced that we can do anything about this. Vodafone: I don’t want to leave an editor's note like this in the document but I would rather see solutions directly.	noted	No
		S3‑171802	AKAstar discussion of options 1 and 2	Huawei & Hisilicon	discussion	Discussion	Yes	YesCommented in 2072. BT: this can also apply to 4G. Huawei: The UE not present attack exists in 3G and 4G networks so we should retro fit it to them. Nokia: it doesn’t work given the assumption from the last meeting. KPN: it's only about authentication. The operator drops you to 4G/3G. The attack still happens. It might not be needed. Interdigital: how's the complexity increased? Huawei: compared to EAPS-AKA, the interface between the UE and ASF doesn't change.Compared to EAPS-AKA, no hashes in option 1. Option 2 is comparable, roughly the same as EAPS-AKA. Nokia asked whether some other company felt the need to change the current solution in the TS. Either way seemed to be fine for the rest. Huawei commented that the purpose was to have a working agreement and bring a pCR for the next meeting. The documents were noted; the Chair welcomed more input for the next meetings to continue the discussions. Huawei proposed to have a conference call on this topic in 2072 and 802, chaired by Qualcomm. This was agreed.	noted	No
		S3‑171803	AKAstar pCR for option 1	Huawei & Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171804	AKAstar pCR for option 2	Huawei & Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑172072	Comments on S3-171802, 03, 04 by Huawei on 'EPS AKAstar procedure'	Nokia	discussion		Yes	Yes	noted	No
		S3‑171938	pCR Security enhancement to the EPS-AKA*	China Mobile	pCR		Yes	YesNokia: similar to the previous ones. The anchor is masked, but the mask can be computed by an attacker listening to the air interface. Vodafone recommended to have a more detailed review of the documents dealing with this issue by having a conference call. The document was finally noted.	noted	No
		S3‑171990	More than one authentication vector may be sent to SEAF	Nokia	pCR		Yes	YesMCC commented that the NOTE should be plain text since a recommendation is being given. "It is recommended…" has the same meaning as a "you should.." so this would be normative language contained in an informative note. Nokia commented that this was taken literally from 4G, and MCC replied that it would be better to change it now. The Chair commented that this case has appeared often and that this could be taken offline and considered in a later review.	approved	No
		S3‑171991	Linking increased home control to subsequent procedures	Nokia	pCR		Yes	YesEricsson: this is not urgent. We can postpone a decision given that there are potentially better solutions. BT considered important since it could affect the QoS for the subscribers. Deutsche Telekom: it needs to be somewhere. Let's agree on this and keep it until something else shows up. Otherwise we will stand here suffering from fake location updates with no apparent solution given. ORANGE, KPN, NTT-Docomo supported DT.	approved	No
		S3‑171986	Security messages on N12	Nokia	pCR		Yes	Yes	approved	No
		S3‑171989	Security messages on N13	Nokia	pCR		Yes	Yes	merged	No	S3‑172146
		S3‑171797	Key setting during primary authentication	Huawei & Hisilicon	pCR	Approval	Yes	YesDiscussed with 922.	noted	No
		S3‑171962	Update of clause 8.1.1.1 ‘5G-RAN key setting during primary authentication in TS 33.501	Ericsson	pCR	Approval	Yes	YesNTT-Docomo: Raised the question: Take from 33.401 and do the modifications like Ericsson proposes or we do a fresh start instead in 33.501? Huawei: if there is anything in 33.401 applicable in 501 just bring a contribution. We don’t need to bring everything from 401. Nokia: fresh start is too cumbersome and there is not time, let's bring the 401 approach. NEC supported it. NTT-Docomo pointed out to fix the normative language mistakes that are coming from 401 so as not to make the same errors. The proposal would be to bring things from 33.401, but instead of copying directly into the TS have a running pCR to be able to adjust the language firstly. New language is merged into this running pCR.	noted	No
		S3‑171860	Discussion on non-3GPP solutions	Huawei; Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑171864	Draft LS reply S2-174887	Huawei; Hisilicon	LS out	Approval	Yes	Yes	noted	No
		S3‑171959	EPS AKA* to be used over all access network types – clause 11	Nokia	pCR		Yes	Yes	noted	No
		S3‑172015	Analysis of the solutions proposed in SA2 LS for Registration over untrusted n3gpp	Qualcomm Incorporated	other	Approval	Yes	YesMotorola: Qualcomm's solution was rejected in SA2, let's discuss only the issues agreed in SA2. ORANGE: Qualcomm's solution is in our TR. Why doesn't this work? Motorola commented that they were not involved personally in the discussion and that they would have to check with their colleagues. Qualcomm pointed out that SA2 is waiting for SA3's response, the solution is not rejected. Verizon: Let's send SA2 our security concerns for SA2 solutions and comment what SA2 should do. Nokia: SA2 cannot address the detailed security concerns. Intel commented that SA3 should understand why the Qualcomm solution doesn't work given that it is in our TR. Ericsson: SA2 is asking to assess the security solutions they propose and SA3 should reply to that. Afterwards we can decide whether the existing solution is better. An evening drafting session was created to try to merge all the contributions related to the LS from SA2.	noted	No
		S3‑171957	How to use EPS AKA* for untrusted non-3GPP access	Nokia	discussion		Yes	Yes	noted	No
		S3‑171865	move non-3GPP solution from TR 33.899 to TS 33.501	Huawei; Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑172019	pCR : Security for Non-3GPP access to 5GC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑171846	pCR to 33501_some editoral revisions	Huawei; Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑171942	Adding ENs to clause 11 of TS 33.501	Nokia	pCR		Yes	Yes	noted	No
		S3‑172016	Proposed Reply LS on 5G Registration via Untrusted Non-3GPP Access	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑171922	Overall presentation of skeleton updates for mapping content under clause 7 in TS 33.401 to clause 8 in TS 33.501	Ericsson	discussion	Approval	Yes	YesDiscussed with 931,2038	noted	No
		S3‑171931	Update for skeleton of clause 8 on Security Procedures between UE and 5G Access Network Functions	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑172152
		S3‑172152	Update for skeleton of clause 8 on Security Procedures between UE and 5G Access Network Functions	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171931
		S3‑171861	Discussion on Radio Access network protection	Huawei; Hisilicon	discussion	Discussion	Yes	YesEricsson: can we agree on the integrity activation for this meeting and continue on the next? Algorithms and confidentiality would go for the next meeting. Nokia mentioned the agreed points in the evening sessions: - How to activate integrity confidentiality. - Granularity. - Integrity should be subject to the process, it's open whether the confidentiality too. - Use of algorithms should be flexible? It was proposed to fix these topics into a document that could be agreed as the next step forward: 164	noted	No
		S3‑171862	Initial AS security context establishemt	Huawei; Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171863	Procedures for Radio security	Huawei; Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171888	AS algo. initial context (8.1.2.1.1 )	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑171889	AS algo negotiation during Xn-handover (8.1.2.1.2)	Ericsson	pCR	Approval	Yes	YesAn editor's note was proposed to check with RAN that the procedure on RRC connection reconfiguration detailed here is correct. Huawei commented that it was coming from LTE and that it was reasonable. Another editor's note was added on the mechanism to be verified as well.	revised	No	S3‑172165
		S3‑172165	AS algo negotiation during Xn-handover (8.1.2.1.2)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171889
		S3‑171890	AS algo negotiation during N2-handover (8.1.2.1.3)	Ericsson	pCR	Approval	Yes	YesEPS security context has been replaced by 5GS security context. This will be replaced by 5G security context.	revised	No	S3‑172166
		S3‑172166	AS algo negotiation during N2-handover (8.1.2.1.3)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171890
		S3‑171891	AS algo negotiation during intra-gNB handover (8.1.2.1.4)	Ericsson	pCR	Approval	Yes	YesHuawei: clarfy what is intra-gNB. An editor's note was added for this.	revised	No	S3‑172167
		S3‑172167	AS algo negotiation during intra-gNB handover (8.1.2.1.4)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171891
		S3‑171892	AS security mode command procedure (8.1.2.2)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑172168
		S3‑172168	AS security mode command procedure (8.1.2.2)	Ericsson	pCR	Approval	No	Yes	noted	No		S3‑171892
		S3‑171798	UP security mechanisms	Huawei & Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑172169
		S3‑172169	UP security mechanisms	Huawei & Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171798
		S3‑171833	pCR to 33.501: Security Aspects of SMS over NAS	Huawei; Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑172170
		S3‑172170	pCR to 33.501: Security Aspects of SMS over NAS	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171833
		S3‑171926	Update of clause 6.2 on NAS security	Ericsson	pCR	Approval	Yes	YesDiscussed with 819. NTT-Docomo preferred this version. Both contributions had to be discussed offline.	approved	No
		S3‑171960	Re-ordering of clause 6	Nokia	pCR		Yes	Yes	approved	No
		S3‑171819	Clause 6.2 NAS Security	Nokia	pCR	Approval	Yes	Yes	noted	No
		S3‑172007	Protecting the initial NAS messages	Qualcomm Incorporated	pCR	Approval	Yes	YesNokia: it contains details still being discussed like NSSAI. Ericsson: it maybe disaligned with the SMS protection solution that has been agreed. Two editor's notes were added, some of the language needed to be normative. With this modifications the document was approved.	revised	No	S3‑172171
		S3‑172171	Protecting the initial NAS messages	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑172007
		S3‑171927	Update of content of clause 6.3 on security negotiation	Ericsson	pCR	Approval	Yes	YesOverlapping with 2033, 1834	revised	No	S3‑172172
		S3‑172172	Update of content of clause 6.3 on security negotiation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑171927
		S3‑171930	Update of clause 6.3 skeleton on Security negotiation	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑171795	Requirements of security algorithms selection	Huawei & Hisilicon	pCR	Approval	Yes	YesDiscusssed with 932.	noted	No
		S3‑171964	Update of clause 5.4.1 ‘Requirements for algorithm selection‘ in TS 33.501	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑171834	pCR to 33.501: Initial NAS security algorithm establishment	Huawei; Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑172172
		S3‑171835	pCR to 33.501: NAS algorithm handling when AMF change	Huawei; Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑172172
		S3‑172033	pCR to TS 33.501_NAS SMC procedure	NEC Corporation, AT&T	pCR	Approval	Yes	Yes	merged	No	S3‑172172
		S3‑171836	pCR to 33.501: NAS security mode command procedure	Huawei; Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑172172
		S3‑171858	update the skeleton of TS 33.501	Huawei; Hisilicon	pCR	Approval	Yes	YesThe content depends on the reply from the LS to SA2 on the service architecture.	postponed	No
		S3‑171932	Update of clause 5 skeleton on Security Requirements and Features	Ericsson	pCR	Approval	Yes	YesOverlaps with 795. It is aligned with that contribution so this was noted.	noted	No
		S3‑171992	Requirements on core network interconnection security	Nokia	pCR		Yes	YesEricsson: heavily assumed that we will use Diameter: end-to-end confidentiality and integrity protection requirement. China Mobile: where is the threat? Nokia: we have the TR 33.899 for that, we don't put them in the TS. Ericsson: this is very solution-specific. Deutsche Telekom supported this contribution. Ericsson wasn't convinced to have the requirements for the solutions, given that they may be found by GSMA or with the help of GSMA.	revised	No	S3‑172174
		S3‑172174	Requirements on core network interconnection security	Nokia	pCR	-	Yes	Yes	approved	No		S3‑171992
		S3‑171993	Draft LS on 3GPP Requirements on Core Network Interconnection Security	Nokia	LS out		Yes	Yes	revised	No	S3‑172175
		S3‑172175	LS on 3GPP Requirements on Core Network Interconnection Security	Nokia	LS out	-	No	Yes	approved	No		S3‑171993
		S3‑172013	pCR on adding bidding down protection requirement in Phase 1 for features that may be added later	Qualcomm Incorporated	pCR	Approval	Yes	YesMCC and Ericsson: no mention of future releases or phases in the specification. It was agreed to add an editor's note on the necessity of rephrasing this to accommodate the 3GPP drafting rules. LG: what features? Security features? All features? It was agreed to have "security features".	revised	No	S3‑172176
		S3‑172176	pCR on adding bidding down protection requirement in Phase 1 for features that may be added later	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑172013
		S3‑172051	Clarifications to the user plane integrity requirements in TS 33.501	Ericsson	pCR	Approval	Yes	YesORANGE: I don’t see the intention of the second NOTE. This is not purely informative. I don’t want a guidance of the usage of this for the operator. Qualcomm supported having this note. Huawei: why "..that are not confidentiality protected"? MCC pointed out that the first note was written as a requirement, not an informative statement. Besides, both notes included the word "must" that cannot be used in 3GPP specifications.	revised	No	S3‑172187
		S3‑172187	Clarifications to the user plane integrity requirements in TS 33.501	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑172051
		S3‑171895	UP Security on gNB internal interface	Huawei; Hisilicon	pCR	Approval	Yes	YesConfiguration and authentication of gNBs needed to be clarified according to Nokia. This was added in an editor's note.	revised	No	S3‑172177	S3‑171848
		S3‑172177	UP Security on gNB internal interface	Huawei; Hisilicon	pCR	Approval	No	Yes	approved	No		S3‑171895
		S3‑171823	update gNB security requirement	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑171900	UP Security on gNB internal interface	Huawei; Hisilicon	pCR	Approval	Yes	YesNokia: we are adding requirements to an interface that hasn't been standardized. ORANGE: they haven't decided whether to specify this interface. Ericsson: this interface is being specified in RAN.	revised	No	S3‑172178	S3‑171848
		S3‑172178	UP Security on gNB internal interface	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171900
		S3‑172010	pCR to provide a normative text for the AMF key derivation/refresh	Qualcomm Incorporated	pCR	Approval	Yes	YesThis contribution clashed with 1961, 1968.	noted	No
		S3‑172012	pCR to provide a normative text for AS key hierarchy	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑171961	Key hierarchy	Nokia	pCR		Yes	Yes	not treated	No
		S3‑172030	pCR to TS 33.501_5G Key Hierarchy	NEC Corporation, AT&T	pCR	Approval	Yes	Yes	not treated	No
		S3‑171822	Potential key hierarchy in 5G phase 1	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑171928	Update of clause 6.6 on key hierarchy	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑171820	Annex A on Key derivation	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑171966	Security handling in state transitions	Nokia	pCR		Yes	Yes	not treated	No
		S3‑171929	Update of clause 6.7 on security contexts	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑171963	Handling security contexts within the serving network	Nokia	pCR		Yes	Yes	not treated	No
		S3‑171965	Distribution of security contexts	Nokia	pCR		Yes	Yes	not treated	No
		S3‑171933	Update of clause 8.1.1.2 ‘5G-RAN key identification‘ in TS 33.501	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑171934	Update of clause 8.1.1.3 ‘5G-RAN key lifetimes‘ in TS 33.501	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑171968	Security handling in mobility	Nokia	pCR		Yes	Yes	not treated	No
		S3‑172038	pCR to TS 33.501_Skeleton for security handling in mobility	NEC Corporation	pCR	Approval	Yes	YesOverlaps with 1968. Nokia: the NAS doesn’t see anything about the HO preparation. Huawei: tdoc 1931 is the preferred way for clause 8.3	noted	No
		S3‑172011	pCR to provide a normative text for AS key derivation	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑171824	Updates security handling in mobility	Huawei, Hisilicon, Deutsche Telekom AG	pCR	Approval	Yes	Yes	not treated	No
		S3‑172009	Security handling for interworking between NextGen Core and EPC	Qualcomm Incorporated	other	Approval	Yes	Yes	not treated	No
		S3‑172014	pCR to provide a solution for interworking between NextGen Core and EPC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑172034	Securing the Network Steering Information	Samsung	pCR	Approval	Yes	YesPostponed together with the associated LS. Vodafone noted that they will reject the solution in the next meeting.	postponed	No
		S3‑171806	ID linkage verification in secondary authentication	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑171807	Secondary authentication for multiple PDU sessions	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑171873	pCR to TS 33.501 clause 12: Update text with Service operations used to carry EAP messages	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑171871	pCR to TS 33.501 Clause 12.1.2: Resolve EN on Normative language	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑171872	pCR to TS 33.501 - Resolve 2nd and 3rd ENs in clause 12.1.2 on Secondary authentication	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑171901	CR to 33.501: Secondary Re-Authentication	Intel Corporation (UK) Ltd	pCR		Yes	Yes	not treated	No
		S3‑172008	Identifying a problem with secondary authentication	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑171805	DN authorization grant and revocation	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑171996	Security Procedures with EAP-TLS	Huawei, Hisilicon	pCR		Yes	Yes	not treated	No		S3‑171812
		S3‑171801	Security policy determination	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑171875	A security solution for service based architecture	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑171780	Privacy: [DRAFT] LS on visibility of privacy aspects	Ericsson, Telecom Italia	LS out	Approval	Yes	Yes	not treated	No
		S3‑171897	configuration and visibilityfeatures in TS 33.401 should be reused in 5G.	Huawei; Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑172107	S3‑171849
		S3‑171812	Security procedure for EAP-TLS	Huawei & Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑171996
		S3‑171894	Discussion on 5G Registration via Untrusted Non-3GPP Access	Motorola Mobility, Lenovo, Broadcom, Brocade	discussion	Endorsement	Yes	Yes	noted	No
		S3‑171943	Observations on the solution for untrusted non-3GPP access in S2-174885	Nokia	discussion		Yes	Yes	noted	No
		S3‑171944	Observations on the solution for untrusted non-3GPP access in S2-174886	Nokia	discussion		Yes	Yes	noted	No
		S3‑171954	TS - Privacy requirement for gNB	Nokia	pCR	Decision	Yes	YesHuawei queried what triggered the requirements in 5.2.8. They didn't think it was necessary. Qualcomm supported this. Alf (NTT-Docomo): this is not a requirement,although I agree with the principles.	noted	No
		S3‑171956	Draft reply LS on 5G Registration via Untrusted Non-3GPP Access	Nokia	LS out		Yes	Yes	noted	No
		S3‑172065	pCR to 33501_some editoral revisions	Huawei; Hisilicon	pCR	Approval	No	No	withdrawn	Yes
		S3‑172071	comments to S3-171776 on HN public key	Gemalto N.V.	pCR		Yes	Yes	revised	No	S3‑172087
		S3‑172087	comments to S3-171776 on HN public key	Gemalto N.V.,ORANGE, Oberthur Technologies, Morpho	pCR	-	Yes	YesBT: if the operator is the only one allowed to provide the handsets this works, but when they are out of their of their control we agree with Vodafone. Qualcomm: there will be operators who will choose to store in the UICC, and there will be operators who will have control over the handset distribution model and they can choose to store in the ME. Why do we standardise to avoid operators having this option? Vodafone: the disagreement on the ME part relies on the provisioning, not the security. Let's add an editor's note on this.	merged	No	S3‑172151	S3‑172071
		S3‑171884	LS on Impacts of using User Identity confidentiality	S2-175263	LS in		Yes	No	withdrawn	Yes
		S3‑171885	Reply LS on 5GS Security aspects seeking resolution	S2-175309	LS in		Yes	No	withdrawn	Yes
		S3‑172097	LS on service based architecture	ORANGE	LS out	Approval	No	Yes	approved	No
		S3‑172147	Draft TS 33.501	NTT-Docomo	draft TS	Approval	No	Yes	left for email approval	No
		S3‑172164	Agreements and open issues on Radio Access network protection	NTT-Docomo	discussion	Endorsement	Yes	Yes	endorsed	No
7.4	Security of the Mission Critical Service (MCSec) (Rel-14)	S3‑171760	[MCSec] 33180 CR Ambient listening and viewing	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
		S3‑171761	[MCSec] 33180 CR Broadcast and emergency security	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	revised	No	S3‑172113
		S3‑172113	[MCSec] 33180 CR Broadcast and emergency security	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No		S3‑171761
		S3‑171762	[MCSec] 33180 CR Group Regroup fix	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	merged	No	S3‑172108
		S3‑171763	[MCSec] 33180 CR IdM token exchange fix	Motorola Solutions Danmark A/S	CR	Agreement	Yes	No	withdrawn	Yes
		S3‑171764	[MCSec] 33180 CR IdM token response fix	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
		S3‑171765	[MCSec] 33180 CR token revocation	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
		S3‑171766	[MCSec] 33180 CR User location security	Motorola Solutions Danmark A/S	CR	Agreement	Yes	No	withdrawn	Yes
		S3‑171767	[MCSec] 33180 CR Video push and pull	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
		S3‑172046	Corrections to MCData security procedures	Samsung, NCSC	CR	Approval	Yes	Yes	revised	No	S3‑172130
		S3‑172130	Corrections to MCData security procedures	Samsung, NCSC	CR	Approval	Yes	Yes	agreed	No		S3‑172046
		S3‑172058	[MCSEC] General corrections to TS 33.180	NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑172108
		S3‑172108	General Corrections to TS 33.180	NCSC,Motorola Solutions,NCSC	CR	Agreement	Yes	Yes	agreed	No		S3‑172058
		S3‑172060	[MCSEC] MCData payload authentication correction	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑171919	Clarification of key period calculation	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑171921	Clarification of security domain parameters and UK-ID	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑171936	Clarifications and editorial corrections related to SRTCP protection	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑172114
		S3‑172114	Clarifications and editorial corrections related to SRTCP protection	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑171936
		S3‑171937	Encryption parameter clarification for group call	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑172109
		S3‑172109	Correction of parameters for use of MIKEY-SAKKE	Motorola Solutions UK Ltd.,NCSC	CR	Agreement	Yes	Yes	agreed	No		S3‑171937
		S3‑171939	Encryption parameters clarification for private call	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	merged	No	S3‑172109
7.5	Mission Critical Security Enhancements (eMCSec) (Rel-15)	S3‑171710	Reply LS on FEC and ROHC for mission critical services over MBMS	C3-173315	LS in		Yes	Yes	noted	No
		S3‑172057	LS on ‘Temporary group call – user regroup’ security	NCSC	LS out	Approval	Yes	Yes	revised	No	S3‑172110
		S3‑172110	LS on ‘Temporary group call – user regroup’ security	NCSC	LS out	Approval	Yes	Yes	approved	No		S3‑172057
		S3‑172059	LS on configuration data for protection of signalling	NCSC	LS out	Approval	Yes	YesMotorola: is this for Rel-14? NCSC: it is for Rel-15 only.	revised	No	S3‑172131
		S3‑172131	LS on configuration data for protection of signalling	NCSC	LS out	Approval	Yes	Yes	approved	No		S3‑172059
7.6	Other work areas
7.6.1	SAE/LTE Security	S3‑171717	LS reply to CT1 on GERAN redirection	R2-1706149	LS in		Yes	YesSuresh (Nokia) commented that LTE call redirection could be discussed in the conference call. Ericsson commented that in 7.6.1 there were two documents dealing with this issue for the current meeting, so this would be discussed later.	noted	No
		S3‑171718	LS on encrypting broadcasted positioning data	R2-1706150	LS in		Yes	YesNokia commented that this work is scheduled for March 2018 and that could be treated in SA3's next meeting. There are documents in 7.6.1 dealing with this issue.	replied to	No
		S3‑172134	Reply to: LS on encrypting broadcasted positioning data	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑171774	Discussion paper on redirection to GERAN	Qihoo 360	discussion	Discussion	No	No	withdrawn	Yes
		S3‑171775	Discussion paper on redirection to GERAN	Qihoo 360	discussion	Discussion	Yes	YesEricsson: why is this warning message added to current Ues? Qi360: changing the software of the UE. BT: a warning message won’t be enough. An emeeting will be created in order to agree on a LS about this issue.	noted	No
		S3‑171813	Discussion on LS R2-1706150 encrypting positioning data	Nokia	discussion	Discussion	Yes	Yes	noted	No
		S3‑171874	CR to 33.402: Clarification on Unauthenticated Emergency services over untrusted WLAN	Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑171987	Discussion on LTE redirection to GERAN	Ericsson	discussion	Endorsement	Yes	YesNokia proposed a conference call after the meeting to discuss this issue.Huawei agreed. Ericsson: we need the solution discussed in RAN2/CT1. Nokia: what's a legacy UE? Ericsson: the one that is in the field right now.	noted	No
		S3‑172024	Proposed reply LS on encrypting broadcasted positioning data	Qualcomm Incorporated	LS out	Approval	Yes	YesErisson: we should not tell them which method to use. E-SMLC is not more secure than cyphering by an eNB. Ask for more information. The LS was replied in 134.	noted	No
		S3‑172025	Ciphering of Broadcast Assistance Data	Qualcomm Incorporated	discussion	Decision	Yes	Yes	noted	No
		S3‑172053	Encryption of positioning broadcast information	Ericsson Inc.	discussion	Endorsement	Yes	Yes	noted	No
7.6.2	IP Multimedia Subsystem (IMS) Security
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)	S3‑171727	Reply LS on external interface for TV services	S4-170725	LS in		Yes	YesThere are some contributions dealing with this in 7.6.7.	replied to	No
		S3‑172135	Reply to: Reply LS on external interface for TV services	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑172023	Corrections to xMB security aspects	Qualcomm Incorporated	CR	Agreement	Yes	Yes	not pursued	No
7.6.8	Security Aspects of Home(e)NodeB (H(e)NB)
7.6.9	Security Aspects related to Machine-Type Communication ((e)MTC)	S3‑171877	Discussion on security of SCEF Northbound API interfaces	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑171878	New WID for Northbound APIs Security for SCEF - SCSAS Interworking (NAPS_Sec)	Huawei, Hisilicon	WID new	Agreement	Yes	YesEricsson pointed out that the discussion proposes a study but this is a work item proposal. Huawei commented that this is a short WID and that’s the intention. Ericsson supported this. BT commented that the scope misses security functions that pass on the interface. Not clear whether this is for Rel-15/ 5G. Status of the underliying 3GPP access network to be inclluded in the scope in order to support this WID. Nokia commented that the dates proposed were wrong (they don’t show SA dates and what it shows in SA3 dates is very unrealistic). Vodafone commented that the entities to be secured need to be identified: what do they mean with "users" here? The scope needs to be more specific. MCC commented that the output should be CRs impacting TS 33.187. The wrong table was filled up. MCC commented that in section 8 no 3GPP working groups should be added since the will not be involved in the SA3 WID work.	revised	No	S3‑172075
		S3‑172075	New WID for Northbound APIs Security for SCEF - SCSAS Interworking (NAPS_Sec)	Huawei, Hisilicon	WID new	Agreement	Yes	YesVodafone,BT: restrict the scope to securing the interface (they wanted the bullet points in the objective back). If the scope is too wide make it a study item. ORANGE preferred a wider scope (removing the bullet points in the objective), also a study item instead of a work item. Nokia: the WID is progressing in SA2, we received an LS and we replied to them. This is beyond a study item. This was taken offline and an agreement was made.	agreed	No		S3‑171878
7.6.10	Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)	S3‑171725	LS on Security Aspects Related to IOPS network with Limited Backhaul	S2-174071	LS in		Yes	YesVodafone: do we need a WID for this? The Chair commented that it depended on the amount of work. If they are small changes, no need for it. ORANGE: the macro network HSS wasn't covered by the study in SA3. The LS was postponed for the next meeting.	postponed	No
7.6.11	Security of MCPTT (MCPTT)
7.6.12	Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)
7.6.13	Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)
7.6.14	Security Aspects of Narrowband IOT (CIoT)	S3‑171997	Security for the RLFs for UEs doing user plane over control plane using NAS level security	Qualcomm Incorporated	CR	Agreement	Yes	YesNokia: UL/XDL_NAS_MAC are defined anywhere? Qualcomm implied that was not necessary, it's well explained in the clause.	revised	No	S3‑172137	S3‑171325
		S3‑172137	Security for the RLFs for UEs doing user plane over control plane using NAS level security	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑171997
		S3‑172026	KeNB calculation at initisation of S1-U DRBs for UEs using control plane optimisations	Qualcomm Incorporated	CR	Agreement	Yes	YesNokia had a problem with the note. It was decided to remove it. Vodafone: the first paragraph is a very long sentence. It was agreed to reword the first paragraph to make it simpler to read and understand.	revised	No	S3‑172138
		S3‑172138	KeNB calculation at initisation of S1-U DRBs for UEs using control plane optimisations	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑172026
7.6.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)	S3‑171715	LS on LI requirements for CIOT services including BEST services	ETSI TC LI	LS in		Yes	YesVodafone: They have confused using BEST in a roaming scenario. It was postponed together with the SA3-LI LS.	postponed	No
		S3‑171716	Reply LS on security for RLF for DoNAS Ues	R2-1705939	LS in		Yes	Yes	noted	No
		S3‑171881	Reply LS on LI Requirements for CIoT services including BEST services	S3i170239	LS in		Yes	YesBT: End-to-end media IMS could apply here. Verizon: just have integrity protection in this situation. KPN: we would be happy to transport data for Vodafone. No need to change the service. The regulation in Netherlands is going towards device manipulation. If the UE is moving towards end-to-end encryption we don’t need to act further. Everything can be solved in the roaming agreement. Vodafone: Location of the customer is ON. No impact in LI if running only integrity protection. ORANGE: the LI requirement in the VPLMN needs to be fulfilled without the help of the HPLMN. Vodafone: the VPLMN needs to ask HPLMN not to allow cyphering. We tell the customer that the traffic will not be encrypted in certain countries. We have the tools to know where the customer is and act on it. This is all covered in the TR. ORANGE: TC LI and SA3-LI are not proposing what needs to be done. SA3 doesn’t have the right skills to understand the LI requirements. BT: SA3-LI should not act on the service architecture either. SA3 should give feedback on the way the think it should be done with the minimum impact. Confidentiality is fine enough. Vodafone proposed to have conference calls to discuss the response LS. ORANGE: SA3-LI is meeting before Reno, we need to respond before.	postponed	No
		S3‑171747	Collection of changes to BEST TS as a result of implementations	VODAFONE Group Plc	CR	Agreement	Yes	Yes	revised	No	S3‑172139
		S3‑172139	Collection of changes to BEST TS as a result of implementations	VODAFONE Group Plc	CR	Agreement	No	Yes	agreed	No		S3‑171747
		S3‑171748	Disscussion on issues found during implementation of BEST and their fixes	VODAFONE Group Plc	discussion	Information	Yes	Yes	noted	No
		S3‑171746	Discussion document on the LS from TC CYBER regarding BEST	VODAFONE Group Plc	discussion	Information	No	No	withdrawn	Yes
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)
7.6.18	Security Assurance Specification for 3GPP network product classes (General, TS 33.117) (SCAS-SA3)
7.6.19	Security Assurance Specification for 3GPP network product classes (MME, TS 33.116) (SCAS-SA3)
7.6.20	Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14)	S3‑171724	Reply LS on the support of Unicast and Groupcast transmission over PC5 for eV2X	S2-173610	LS in		Yes	Yes	noted	No
		S3‑171853	GBA use in LTE V2X	Huawei; Hisilicon	draftCR	Approval	Yes	YesThis should have been a CR, so a new tdoc was given to include this content.	noted	No
		S3‑172142	GBA use in LTE V2X	Huawei	CR	Agreement	Yes	Yes	agreed	No
7.6.21	Other work items	S3‑171773	Support of 256-bit Keys and Algorithms in 5G	AT&T, US Dept. of Commerce, Interdigital, MITRE	discussion	Decision	Yes	YesORANGE: Do we move completely to the new lengths or we will have coexistence of them? Interdigital: there will be coexistence. Gemalto: which release is this heading to? AT&T: Rel-15 for the study and normative in Rel-16. Gemalto: the result of the study will be for phase two then. Vodafone: the study item should be extended to Rel-16, given the load of work. Both study and normative can be done in parallel. CCSA supported the study. Vodafone commented that the work can be sped up with conference calls in order to involve SAGE as soon as possible. NTT-Docomo: 48 bytes for the PDU in PDCP seems to be quite a lot of overhead. AT&T commented that this needed to be studied. The companies welcomed the initiative and encouraged to bring a Study Item for the next meeting to be agreed. BT pointed out that the admininistrative procedures in the French government could delay the inclusion of this work in Rel-16. AT&T: the intention is to bring this into the next meeting in Singapore.	noted	No
		S3‑171792	Proposal for Disabling Legacy Radio Access	MITRE, AT&T, Interdigital	discussion	Discussion	Yes	YesChina Mobile: thye objected to the contribution. This is not work for SA3, it's RAN specific. Vodafone: ability to select RANs is in a SA1 spec. It is right to make statements so other groups can take action. Current phones cannot restrict access to 2G/3G. BT agreed with this. The user should be aware about this. Emergency calls that can be made only in 2G, what happens? Sprint: SA1 will deal with this. It’s related to regulatory aspects. Vodafone: action should be taken in SA1. AT&T was happy with this feedback. Sending an LS to SA1 was agreed.	noted	No
		S3‑171896	CR for modify the text format of X5.2 in TS 33.203 - R14	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑172141
		S3‑172141	CR for modify the text format of X5.2 in TS 33.203 - R14	Huawei, Hisilicon	CR	Approval	Yes	YesMCC noted that editorial changes are only allowed in Rel-15, so the CR was changed to this Release.	agreed	No		S3‑171896
		S3‑171898	CR for modify the text format of X5.2 in TS 33.203 - R13	Huawei, Hisilicon	CR	Approval	Yes	Yes	not pursued	No
		S3‑171969	xMB interface security	Ericsson	discussion		Yes	Yes	noted	No
		S3‑171971	User-based authorization for xMB	Ericsson LM	CR		Yes	Yes	revised	No	S3‑172136
		S3‑172136	User-based authorization for xMB	Ericsson LM	CR	-	Yes	Yes	agreed	No		S3‑171971
		S3‑172144	LS to SA1 on selective disabling of Legacy Radio Access	AT&T	LS out	Approval	Yes	Yes	approved	No
8	Studies
8.1	Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)	S3‑172041	[eMCSEC]: Key Issue on Edge Security for TR 33.880	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑172042	[eMCSEC]: Solution for Signalling Proxy for TR 33.880	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑172133
		S3‑172133	[eMCSEC]: Solution for Signalling Proxy for TR 33.880	NCSC	pCR	Approval	No	Yes	approved	No		S3‑172042
		S3‑172043	[eMCSEC]: Modification of Key Issue #1.4 TR 33.880	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑172044	[eMCSEC]: Solution for Signalling Authentication for TR 33.880	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑172111
		S3‑172111	[eMCSEC]: Solution for Signalling Authentication for TR 33.880	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑172044
		S3‑172045	[eMCSEC]: Modification of Solution #1.1 in TR 33.880	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑172112
		S3‑172112	[eMCSEC]: Modification of Solution #1.1 in TR 33.880	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑172045
		S3‑172132	Draft TR 33.880	NCSC	draft TR	Approval	Yes	Yes	approved	No
8.2	Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)	S3‑171706	Reply LS on UE-to-NW relaying	S2-170398	LS in		Yes	Yes	replied to	No
		S3‑171707	LS on PC5 Secure Communication	S2-171621	LS in		Yes	Yes	replied to	No
		S3‑172153	Reply to: LS on PC5 Secure Communication and UE-to-NW relaying	Intel	LS out	approval	Yes	Yes	approved	No
		S3‑171988	Reply LS on connection establishment over PC5	Huawei; Hisilicon	LS out	Approval	Yes	YesKPN: we can use the reply to the other LS in here too.	noted	No
		S3‑171908	Discussion for PC5 Security between Remote UE and Relay UE	Intel Corporation (UK) Ltd	discussion		Yes	Yes	noted	No
		S3‑171909	Reply LS on PC5 Secure Communication	Intel Corporation (UK) Ltd	LS out		Yes	Yes	noted	No
		S3‑171994	Reply LS on PC5 Secure Communication	Huawei; Hisilicon	LS out	Approval	Yes	YesIntel: too soon to say that we shall provide integrity and confidentiality protection, we need to study these attacks. KPN, ORANGE: let's study the attacks in our TR and come back later with some conclusions. Ericsson: these attacks could be relevant, at least answer SA2 with the attacks we find relevant to study.	noted	No
		S3‑171975	Title Modification for Key Issue #5	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171976	Overview of REAR	Huawei; Hisilicon	pCR	Approval	Yes	YesKPN: some text in the architecture clause doesn't belong there. They should be moved to the scope clause. MCC: "use "this document" instead of "this study". ORANGE: simply refer to the architecture in SA2. This was agreed. ORANGE: the introduction is giving a solution already.Remove the second paragraph. MCC: reword the "shall"s in there.	revised	No	S3‑172155
		S3‑172155	Overview of REAR	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171976
		S3‑171736	Modification and resolution of Editor's Note of Key Issue #1	KPN,Huawei,HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171737	Modification and resolution of Editor's Note of Key Issue #2	KPN	pCR	Approval	Yes	Yes	revised	No	S3‑172156
		S3‑172156	Modification and resolution of Editor's Note of Key Issue #2	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑171737
		S3‑171738	Clarification of Key Issue #3	KPN,Huawei,HiSilicon	pCR	Approval	Yes	YesIt was agreed to add an editor's note on permanent identities and authorization as proposed by NCSC. They were worried about the possibility of the creation of a chain where the eremote UE is another relay.	revised	No	S3‑172157
		S3‑172157	Clarification of Key Issue #3	KPN,Huawei,HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171738
		S3‑171739	New Key Issue on Service Continuity	KPN	pCR	Approval	Yes	YesNokia: add an editor's note on these service continuity scenarios being considered in RAN2 and SA2. Ericsson agreed.	revised	No	S3‑172158
		S3‑172158	New Key Issue on Service Continuity	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑171739
		S3‑171974	Key Issue on Authentication of eRemote UE during one-to-one Communication Establishement	Huawei; Hisilicon	pCR	Approval	Yes	YesORANGE: the real requirement is the authentication of the remote UE and the network. Huawei: the key issue is the authentication of the remote UE and UE before the remote UE authenticates in the network. Nokia agreed with ORANGE and found the requirement too ambiguous. It was decided to remove the requirements and add an editor's note stating the need of clarifying the key issue.	revised	No	S3‑172181
		S3‑172181	Key Issue on Authentication of eRemote UE during one-to-one Communication Establishement	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171974
		S3‑171741	New key issue on authentication of eRelay-UE	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑171742	New key issue on protection of UP between eRemote-UE and eNB	KPN,Huawei,HiSilicon	pCR	Approval	Yes	YesNokia: If the PC5 is protected since Rel-12, do these threats apply? KPN: this only applies between UE and eNB.	approved	No
		S3‑171743	New solution on authentication of eRemote-UE via eRelay-UE	KPN,Huawei,HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171911	eRemote-UE Authentication with MITM detection	Intel Corporation (UK) Ltd	pCR		Yes	YesSony: this is protection for the control plane only, not the user plane. This was agreed. Huawei: the first step in the figure does not correspond to the text. This was agreed to be fixed. Nokia: secure channel in step d? Is it IPSec? An editor's note was added. ORANGE: this is a LTE study item, and you are mentioning gNB. This was agreed to be fixed. ORANGE doubted that this solution was solving the introduced the issue. ORANGE asked to add the assumption that the channel eRemoteUE and eRelay UE is encrypted.	revised	No	S3‑172180
		S3‑172180	eRemote-UE Authentication with MITM detection	Intel Corporation (UK) Ltd	pCR	-	Yes	Yes	approved	No		S3‑171911
		S3‑171744	New solution on authentication of eRelay-UE	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑171981	Enhancement of Setting up Connection between eRemote UE and eRelay UE	Huawei; Hisilicon	pCR	Approval	Yes	YesORANGE didn’t get the key issue.Besides, there's a lot of exchange before securing PC5 and during that the attack is still possible. Ericsson: this is using basically Prose? Huawei: the deviation from ProSe is in step 3 and 4. According to ORANGE, the key issue in 1974 wasn't clear enough to justify this solution. Huawei was encouraged to clarify the key issue for the next meeting.	noted	No
		S3‑171977	Solution of Authorization for Indirect 3GPP Communication	Huawei; Hisilicon	pCR	Approval	Yes	YesEricsson: not sure that this is part of SA3 scope, since the authorization is discussed in SA2. Nokia: a security solution is neeeded here, not entirely in the scope of SA2. Editor's notes were added to address Nokia's and Ericsson's issues.	revised	No	S3‑172182
		S3‑172182	Solution of Authorization for Indirect 3GPP Communication	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171977
		S3‑171745	New solution on protection of UP between eRemote-UE and eNB	KPN,Huawei,HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171980	Solution for Protection of CP between eRemote UE and Network	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171978	Solution of IMSI privacy for Attach via eRelay UE	Huawei; Hisilicon	pCR	Approval	Yes	YesORANGE: we should go back to the requirement and modify it a little bit.	revised	No	S3‑172183
		S3‑172183	Solution of IMSI privacy for Attach via eRelay UE	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171978
		S3‑171979	eRelay Discovery Enhancement	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171740	New Solutions for Security Service Continuity	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑172154	Draft TR 33.843	Huawei	draft TR	Approval	No	Yes	left for email approval	No
8.3	Study on Architecture and Security for Next Generation System (FS_NSA) (Rel-15)
8.3.1	Security architecture	S3‑171832	Interim Agreement to Key Issue #1.5 and #1.6	Huawei; Hisilicon	pCR	Approval	Yes	YesQualcomm: SMS over NAS will be integrity and confidentiality protected by default. Is this before you activate NAS security? Huawei: yes, this is the case. Qualcomm agreed but proposed to reword the questions. Ericsson: There are cases with security context where there is only integrity protection.This needs to be mentioned. Nokia: already defined in 33.502, this is not needed. Vodafone: not clear how far the integrity protection is going, between the UE and the NAS. It was agreed to refine the wording to address these comments.	revised	No	S3‑172093
		S3‑172093	Interim Agreement to Key Issue #1.5 and #1.6	Huawei; Hisilicon	pCR	Approval	No	Yes	approved	No		S3‑171832
		S3‑171815	pCR to 33.899 Security solution for SMS over NAS	Nokia	pCR	Approval	Yes	YesIt was proposed to carry on without the evaluation due to the lack of time for discussions.	revised	No	S3‑172184
		S3‑172184	pCR to 33.899 Security solution for SMS over NAS	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑171815
		S3‑171831	Interim agreements for forward security during handover	Huawei; Hisilicon	pCR	Approval	Yes	YesVodafone: forward security mechanism is ambiguous. Nokia: add a reference to the LTE document where this is defined.	revised	No	S3‑172094
		S3‑172094	Interim agreements for forward security during handover	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171831
		S3‑171847	interim agreement for E.1.7.2	Huawei; Hisilicon	pCR	Approval	Yes	YesNokia: the forward security part will bring significant changes. You can always do re-authentication, so it is not needed. I'm fine with backward security. Ericsson and China Mobile supported Nokia with this. Qualcomm objected to having only backwards security. This was left open depending on decisions made in the normative part.	noted	No
		S3‑171843	interim agreement for KI#1.8	Huawei; Hisilicon	pCR	Approval	Yes	YesORANGE: this is already existing. Huawei: no agreement whether the public key is needed. Vodafone: No need to have interim agreements that are in the TS already, this increases the number of documents.	noted	No
		S3‑171842	update solutrion #1.40	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171793	Interim agreement on UP security	Huawei & Hisilicon	pCR	Approval	Yes	YesVodafone:if you re-authenticate during a session you are changing the protection. Nokia: the granularity comes down to the radio bearer, cannot apply the policy to all the bearers; it would not be optimal. Ericsson: just put Yes in the interim agreement. ORANGE: this doesn’t help at all,we will have the same discussion in the normative part. Qualcomm supported this. The Chair proposed to not to duplicate topics from the interim agreements in the TR and the TS at the same time. This was agreed.	noted	No
		S3‑171818	Interim agreements on key issue#4.17 UP integrity	Nokia	pCR	Approval	Yes	Yes	noted	No
		S3‑171859	Update intrim agreement for section E.4.17	Huawei; Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171794	UP integrity protection policy determination solution	Huawei & Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171876	Soltuion for 5G initial NAS message protection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑172040	pCR to TR 33.899_Discussion on inputs for key derivation	NEC Corporation	pCR	Discussion	Yes	Yes	noted	No
		S3‑172047	pCR to TR 33.899_IA on inputs for key derivation	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑172039	pCR to TR 33.899_Update IA KI_1.18_Flexible security policies negotiation in control plane	NEC Corporation	pCR	Approval	Yes	YesChina Mobile: why more than one KDF? Nokia: in case there is a risk of bidding down attacks, there may be more than one needed. Huawei: what kind of risk,high or low? This is undetermined.	revised	No	S3‑172096
		S3‑172096	pCR to TR 33.899_Update IA KI_1.18_Flexible security policies negotiation in control plane	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑172039
		S3‑171941	AMF vs SEAF in solution 1.49 fo TR 33.899	Nokia	pCR		Yes	Yes	approved	No
		S3‑171855	Update interim agreement in section E.1.11	Huawei; Hisilicon	pCR	Approval	Yes	YesORANGE: it's confusing what is happening in SA2 in this topic. Deciding to go for the service based architecture will have an impact on the timeline of the work. Ericsson: they are already considering REST based protocols, and Diameter. We may need to do something more, as Huawei proposes. China Mobile supported Huawei. We may face different security problems in this case. ORANGE wasn't sure about how the work with SA2 was going to be carried out. Maybe an LS is needed. Huawei: maybe a study would be more appropiate.	approved	No
		S3‑171907	Security Architecture developed by 5G-ENSURE project	Ericsson, Telecom Italia, Thales, NEC	pCR	Approval	Yes	YesORANGE objected to this. Huawei: it’s not a solution, it’s an annex. Ericsson: this is coming from an EU project, 5G-Ensure, it’s not a solution but information about their work. ORANGE: this is unrelated to our work, no point to have this in our TR. BT agreed with ORANGE.	noted	No
		S3‑171848	UP Security on gNB internal interface	Huawei; Hisilicon	pCR	Approval	No	Yes	revised	No	S3‑171895, S3‑171900
		S3‑171850	gNB shall support certificate enrolment in TS 33.310	Huawei; Hisilicon	pCR	Approval	No	No	withdrawn	Yes
8.3.2	Authentication	S3‑171917	Q&IA related to the Usability of legacy USIM in key issue #2.1	China mobile, KPN	pCR		Yes	YesVodafone: there may be problems when introducing the 5G core. It is up to us to say whether it will be secure to access 5G services with a legacy SIM, not whether the legacy SIM can be used for 5G services. Vodafone: Rel-8 to Rel-14 would be legacy. Qualcomm: what is the difference between Rel-8 and Rel-99? They are the same.Vodafone disagreed. Splitting security between the handset and the SIM should not be done. Qualcomm objected to distinguishing from Releases since they didn’t understand why Rel-99 couldn’t be used. NTT-Docomo: first question you can use the term LTE USIM. Ericsson commented that they had contributions for the TS that addressed this question.	revised	No	S3‑172099
		S3‑172099	Q&IA related to the Usability of legacy USIM in key issue #2.1	China mobile, KPN	pCR	-	No	Yes	noted	No		S3‑171917
		S3‑172073	Comments on S3-17917 Q&IA related to the Usability of legacy USIM in key issue #2.1	OBERTHUR TECHNOLOGIES	pCR	Decision	Yes	Yes	noted	No
		S3‑171826	Deleting EN on MASA handling OUT of Sequence	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171845	interim agreement for KI#2.4	Huawei; Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑172100
		S3‑172100	interim agreement for KI#2.4	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171845
		S3‑171816	Question and Interim Agreement on authentication of the user	Alibaba (China) Group., Ltd.	pCR	Approval	Yes	YesORANGE: who's the user? How does it impact the core network? I don’t agree with the biometric authentication. Alibaba: the original conclusion was TBD. Vodafone: we already have authentication of the user. The question should have been about additional authentication mechanisms in phase one. The asnwer was TBD. The origiinal question is wrong, misleading. Vodafone didn't agree with the document and admitted that the original agreed question was poor. BT: this implies creating a database for biometric data and it implies a higher seccurity risk. Locally is fine, but trying to centralise it would be risky. Alibaba: there are solutions available to solve the high security risk of having a centralised database. Vodafone: we might consider it for phase two, but we don’t have a SID for phase two yet.	revised	No	S3‑172101
		S3‑172101	Question and Interim Agreement on authentication of the user	Alibaba (China) Group., Ltd.	pCR	Approval	Yes	Yes	approved	No		S3‑171816
		S3‑171817	Updating security threats, requirements and solutions on key issue #2.8	Alibaba (China) Group., Ltd.	pCR	Approval	Yes	YesNokia: totally new authentication framework. We can have it for the phase two study, but not here. Alibaba: we can remove the solution part. ORANGE: if we have the key issue only, I don’t agree.	noted	No
		S3‑171828	Update solution 2.11 for KI 1.21	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: it is not solving the issue that is being raised. Qualcomm agreed.	noted	No
		S3‑171821	Adding a solution on key issue #2.8	Alibaba (China) Group., Ltd.	pCR	Approval	No	No	withdrawn	Yes
8.3.3	Security context and key management	S3‑171758	Interim agreement for protecting anchor key for primary authentication	ZTE Corporation	pCR	Approval	Yes	YesORANGE: integrity protected instead of "tampering". BT argeed. It was agreed to modify the question to use "confidentiallity and integrity protected".	revised	No	S3‑172102
		S3‑172102	Interim agreement for protecting anchor key for primary authentication	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑171758
8.3.4	RAN security	S3‑171893	Discussion on rogue gNB detection	Motorola Mobility, Lenovo	pCR	Approval	Yes	YesEricsson: the introduction reads as an evaluation.	noted	No
		S3‑172036	Interim Agreements on Key Issue # 4.1: AS security during RRC idle mode	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑172049	pCR to TR 33.899_IA on Key refresh during handover with AMF change	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑171902	flexible retain key solution	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑171825	Update Interim Agreements for RAN KI # 4.11 & 4.15	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: On the third change, this is overlapping with an agreement that we had earlier. HO will follow the LTE procedure. We didn’t agree with pushing it forward.We can improve it during the normative phase. Fourth change: the response should be TBD as it was before.	revised	No	S3‑172103
		S3‑172103	Update Interim Agreements for RAN KI # 4.11 & 4.15	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171825
		S3‑171829	Conclusion and Comparison of Xn handover solutions	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171838	Discussion on flexibility of retaining or changing AS security key	Huawei; Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑171839	Draft LS on Discussion on flexibility of retaining or changing AS security key	Huawei; Hisilicon	LS out	Approval	Yes	Yes	noted	No
		S3‑171856	Update interim agreement in section E.4.6.12	Huawei; Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑172050	pCR to TR 33.899_Verifying gNB	NEC Corporation	pCR	Approval	Yes	Yes	approved	No
8.3.5	Security within NG-UE
8.3.6	Authorization
8.3.7	Subscription privacy	S3‑171951	TR - agreement - privacy indication	Nokia	pCR	Decision	Yes	Yes	noted	No
		S3‑171947	TR - KI - Avoiding IMSI Paging	Nokia	pCR	Decision	Yes	YesORANGE: no point of having new key issues in the TR. Nokia: we had agreed on this.	approved	No
		S3‑171953	TS - Privacy management service	Nokia	pCR	Decision	Yes	YesIt was decided to move it to the TR instead of the TS. Ericsson: this is following the TS format, it’s normative.	noted	No
		S3‑172070	Comments to S3-171947 pCR New KI - Avoiding IMSI SUPI Paging	China Mobile	discussion		Yes	Yes	noted	No
		S3‑171948	TR - Privacy Agreement - IMSI Paging	Nokia	pCR	Decision	Yes	YesEricsson: SA2 is already taking care of this. They agreed on not having an IMSI based paging. Ericsson supported this contribution. China Mobile: they don't have a document with the official agreement about this. A note was added on the need of syncronizing with SA2.	revised	No	S3‑172104
		S3‑172104	TR - Privacy Agreement - IMSI Paging	Nokia	pCR	Decision	No	Yes	approved	No		S3‑171948
		S3‑171844	interim agreement for KI#7.2	Huawei; Hisilicon	pCR	Approval	Yes	YesVodafone: it shall be stored in one or the other. TBD if stored in the ME. ORANGE: we don't know how to provision the ME with the public key yet. China Mobile: storing in the ME is fine with us. BT: do we want to rule out legacy from this feature? Vodafone: there are no standards for provisioning handsets. The ones proposed in OMA are not used. Ericsson: there are contributions about this in the TS.	noted	No
		S3‑172031	Interim agreements for key issue #7.2	Gemalto N.V.	pCR	Approval	Yes	Yes	revised	No	S3‑172088
		S3‑172088	Interim agreements for key issue #7.2	Gemalto N.V., ORANGE, Oberthur Technologies, Morpho	pCR	Approval	Yes	Yes	noted	No		S3‑172031
		S3‑171918	pCR Security enhancement to the attach procedure relying on the public key of the home network	China Mobile	pCR		Yes	YesThe evaluation part was removed. It was reminded that contributions that introduce new parts should have revision marks. ORANGE:we are seeing solutions that don’t solve the problems. Nokia also had many issues with this contribution.	noted	No
		S3‑171945	TR - LI compliance	Nokia	pCR	Decision	Yes	Yes	revised	No	S3‑172081
		S3‑172081	TR - LI compliance	Nokia	pCR	Decision	Yes	Yes	approved	No		S3‑171945
		S3‑171799	Interim agreement for PDCP SN refreshment	Huawei & Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171827	Conclusion for generation effective temporary or short-term subscription identifiers	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	noted	No
		S3‑171800	PDCP SN refereshment solution	Huawei & Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171906	Evaluation for Securing and refreshing the temporary subscriber identifiers.	Intel Corporation (UK) Ltd	pCR		Yes	Yes	noted	No
		S3‑171910	Update diagrams for Securing and refreshing the temporary subscriber identifiers.	Intel Corporation (UK) Ltd	pCR		Yes	Yes	approved	No
		S3‑171913	pCR to 33.899: Updates to Solution #7.2	Intel Corporation (UK) Ltd	pCR		Yes	Yes	revised	No	S3‑172185
		S3‑172185	pCR to 33.899: Updates to Solution #7.2	Intel Corporation (UK) Ltd	pCR	-	Yes	YesRemoving the evaluation part.	approved	No		S3‑171913
		S3‑171949	TR - discussion and agreement - NSSAI	Nokia	pCR	Decision	Yes	Yes	noted	No
8.3.8	Network slicing security	S3‑171769	Questions and interim agreements for KI #8.3-Slice Authentication	CATT	pCR	Approval	Yes	YesORANGE: no slice authentication in phase one.	noted	No
		S3‑171770	Questions and interim agreements for KI #8.3-NSSAI Security	CATT	pCR	Approval	Yes	Yes	noted	No
		S3‑171771	Questions and interim agreements for KI #8.2-Security Differentiation	CATT	pCR	Approval	Yes	YesSupported by ORANGE.	approved	No
		S3‑171772	Evaluation for Network Slicing Security Solution #8.14	CATT	pCR	Approval	Yes	Yes	noted	No
		S3‑171808	Discussion paper on slice authentication	Huawei & Hisilicon	discussion	Approval	Yes	YesORANGE: no phases in SA1, so slice authentication doesn’t fit right now in phase one of the SA3 work. Huawei: secondary authentication is mandatory. ORANGE: this is specific to some use cases. Huawei: we haven't agreed on anything about this topic yet. We need authentication after primary authentication. ORANGE: this is not needed and it has been discussed several times. Gemalto: other groups are working in slicing, we cannot skip them. ORANGE: slice specific authentication is not being considered in the other groups. Gemalto and China Mobile supported the proposal of having the slice authentication. Ericsson didn’t see that this fit anywhere. Who will be doing this authentication on behalf of the operator? The operator itself to access their own slices after the primary authentication? ORANGE: there is no assumption in SA2 for phase one in the slice authentication topic. The Chair commented that he wasn't sure about having slice authentication for SA3's phase one.	noted	No
		S3‑171809	Interim agreements for KI8.3	Huawei & Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑171810	Interim agreement for KI8.2	Huawei & Hisilicon	pCR	Approval	Yes	YesVodafone: waste of time since this is phase two material.	noted	No
		S3‑171916	Questions and interim agreements for KI #8.3	China Mobile, China Unicom	pCR		Yes	Yes	noted	No
8.3.9	Relay security
8.3.10	Network domain security
8.3.11	Security visibility and configurability	S3‑171849	configuration and visibility features in TS 33.401 should be reused in 5G.	Huawei; Hisilicon	pCR	Approval	No	Yes	revised	No	S3‑171897
		S3‑171886	Key Issue #11.3: User control of security	China Unicom	pCR		Yes	YesLG didn’t support this. Ericsson: we should have a proper discussion on this. Vodafone agreed.	noted	No
		S3‑171887	Key Issue #11.2: User awareness of security	China Unicom	pCR		Yes	Yes	noted	No
		S3‑172063	Questions for security area #11	LG Electronics	pCR	Approval	Yes	YesVodafone: an application should not be able to drop a call based on its own privacy requirements.	noted	No
		S3‑172064	Conclusion of security area #11	LG Electronics	pCR	Approval	Yes	YesORANGE didn’t agree with this. Ericsson supported it.	noted	No
8.3.12	Credential provisioning
8.3.13	Interworking and migration	S3‑172048	pCR to TR 33.899_Solution to KI #13.1	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑172148
		S3‑172148	pCR to TR 33.899_Solution to KI #13.1	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑172048
8.3.14	Small data
8.3.15	Broadcast/Multicast security
8.3.16	Management Security
8.3.17	Cryptographic algorithms
8.3.18	Other	S3‑172095	Draft TR 33.899	Ericsson	draft TR	Approval	No	YesThe Chair commented that the plan was not to present this TR for approval. A note will be added to state that there are no evaluations in the specification. MCC clarified that the Study Item would be stopped, the latest draft approved by the WG but the specification would not be approved at SA level. The interim agreements in this TR will be followed by the group in the normative work.	left for email approval	No
8.4	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)	S3‑171749	Draft skeleton document for TR on Long Term Key Update (LTKUP) following conf calls	VODAFONE Group Plc	draft TR	Approval	Yes	YesORANGE: adding key issues without content? I'd rather treat the content before having a skeleton advancing empty clauses that haven't been approved yet. Vodafone: there is content in the following documents. This was approved conditionally. The next version will introduced the agreed modifications.	approved	No
		S3‑171750	pCR TR33.XXX LTKUP - update to sections 4 5 and 6 as discussed on conf calls	VODAFONE Group Plc	pCR	Approval	Yes	Yes	revised	No	S3‑172160
		S3‑172160	pCR TR33.XXX LTKUP - update to sections 4 5 and 6 as discussed on conf calls	VODAFONE Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑171750
		S3‑171751	pCR to TR 33.xxx - LTKUP - re-organisation of Key issues section into Key Issues and evaluation criteria	VODAFONE Group Plc	pCR	Approval	Yes	Yes	revised	No	S3‑172161
		S3‑172161	pCR to TR 33.xxx - LTKUP - re-organisation of Key issues section into Key Issues and evaluation criteria	VODAFONE Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑171751
		S3‑171752	pCR to TR 33.xxx - LTKUP - addition of key issue content	VODAFONE Group Plc	pCR	Approval	Yes	YesGemalto: Don’t use the term SIM, use the term UICC. Gemalto: remove key issue on OTA Keys exposed. ORANGE supported this and it was agreed.	revised	No	S3‑172162
		S3‑172162	pCR to TR 33.xxx - LTKUP - addition of key issue content	VODAFONE Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑171752
		S3‑171879	GSMA eUICC based solution for LTKUP	Huawei; Hisilicon	pCR	Approval	Yes	YesORANGE: confirm the descriptions with GSMA (SGP.22). Add an editor's note about this. Vodafone: is it OK to reference to a GSMA document? Copyright issues and so on. It was confirmed that SGP.22 was a GSMA public document so it was correct to reference to it. MCC commented that the paragraph "In the latest version of SGP.22 when drafting this TR,.." should be removed as no mentioning of the time when the spec was drafted should be put into a specification. Vodafone agreed to replace it with a reference to SGP.22 as Rapporteur's work.	revised	No	S3‑172163
		S3‑172163	GSMA eUICC based solution for LTKUP	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑171879
		S3‑171880	Revised eUICC solution for LTKUP	Huawei; Hisilicon	pCR	Approval	Yes	YesORANGE and BT objected to this document. Vodafone: it is described as a GSMA solution that doesn't exist. Nokia: isn’t it correct in a 3GPP study to take a GSMA solution and propose a modification? Vodafone disagreed with this. KPN agreed with Vodafone. MCC commented that they felt uncomfortable with taking a solution from GSMA and modifying it.Mirko would check this internally. Vodafone: create a solution and don’t mention GSMA. NTT-Docomo: outcome of the study could go to GSMA and propose a modification. There was no agreement and the document had to be noted.	noted	No
		S3‑172159	Draft TR 33.834	Vodafone	draft TR	Approval	Yes	Yes	approved	No
8.5	Other study areas
8.5.1	Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)	S3‑172029	pCR to TR 33.926_Inactive Emergency PDN Connection Release	NEC Corporation	draftCR	Approval	Yes	Yes	revised	No	S3‑172121
		S3‑172121	pCR to TR 33.926_Inactive Emergency PDN Connection Release	NEC Corporation	draftCR	Approval	Yes	Yes	approved	No		S3‑172029
		S3‑171852	draft CR TR 33.926 PGW Annex	Huawei; Hisilicon	draftCR	Approval	Yes	YesEricsson: P-GW app and P-GW software difference? MCC queried about referencing to Rel-8 TS 24.401. BT also had their doubts on having to reference to Rel-8 only.	approved	No
		S3‑171851	draft CR TR 33.926 eNB Annex	Huawei; Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑172120	Adding P-GW annex	Huawei	CR	Agreement	Yes	Yes	agreed	No
		S3‑172129	Adding eNB Annex to support SCAS_eNB	Huawei	CR	Agreement	No	Yes	agreed	No
8.5.2	Study on Battery Efficient Security for very low Throughput Machine Type Communication Devices (FS_BEST_MTC_Sec)
8.5.3	Study on Security for Proximity-based Services (FS_ProSe_Sec)
8.5.4	TR on Security Assurance scheme for 3GPP network products (33.916) (SCAS-SA3TR)
8.5.5	Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14)	S3‑171955	Discussion of open issues in TR 33.885	Nokia	discussion	Discussion	Yes	Yes	noted	No
		S3‑172140	V2X TR correction	Nokia	CR	Agreement	Yes	Yes	agreed	No
8.5.6	Other study items	S3‑171753	pCR to 33.xxx - LTKUP - addition of evaluation criteria	VODAFONE Group Plc	other	Approval	No	No	withdrawn	Yes
		S3‑171754	pCR to TR33.xxx - LTKUP - addition of soultion - multiple long term keys	VODAFONE Group Plc	other	Approval	No	No	withdrawn	Yes
		S3‑171755	pCR to 33.xxx - LTKUP - addition of solution - Diffe-helman key negotiation	VODAFONE Group Plc	other	Approval	No	No	withdrawn	Yes
		S3‑171756	pCR to 33.xxx - LTKUP - addition of a solution - eSIM	VODAFONE Group Plc	other	Approval	No	No	withdrawn	Yes
		S3‑171811	New SID on security aspect of 5G network slicing provisioning	Huawei, Hisilicon, ZTE, CATR, CATT,China Mobile,China Unicom	SID new	Agreement	Yes	YesNokia: we approved a WID in 2075 about this on Northbound API security. Huawei: that is not an interface in the management plane. Huawei: the list of participants in this document is not correct. ORANGE: exposure to third parties is not clear. Huawei agreed to refine this. ORANGE added that external work can be added in the objectives without mentioning the other 3GPP groups. The Chair commented that December 2017 was too ambitious given the current workload. Besides, ORANGE mentioned that there was no meeting before September 2017 so presenting this for information was impossible. ORANGE: we are bound to other work items, we may have to wait for their results and delay the work.	revised	No	S3‑172179
		S3‑172179	New SID on security aspect of 5G network slicing provisioning	Huawei, Hisilicon, ZTE, CATR, CATT,China Mobile,China Unicom	SID new	Agreement	Yes	Yes	agreed	No		S3‑171811
		S3‑172061	New SID for eV2X security	LG Electronics	SID new	Agreement	Yes	YesNokia: last time we had asked for an analysis for the security relevance of this topic. CATT: this is too early. LG: this is only for LTE, not 5G. ORANGE: we don’t have an architecture as a basis for this work. There was no support for this. The Chair recommended LG to discuss this offline since it was not clear to people what needed to be done. Since the dates are for late 2018, the study can be made to be more concrete. The Chair warned that the 5G work may limit the work on other study items during the physical meetings.	noted	No
9	Review and Update of Work Plan	S3‑171702	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
		S3‑171705	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑172074
		S3‑172074	Work Plan input from Rapporteurs	MCC	other	-	Yes	Yes	noted	No		S3‑171705
10	Future Meeting Dates and Venues	S3‑171704	SA3 meeting calendar	MCC	other		Yes	YesDates 2019: Vodafone commented that co-locating with SA2,SA1 would make it more inefficient since it was better to meet after them. The Chair commented that the dates were not fine with SA3 and that more discussions would be needed. This will be the answer sent to the SA Chair. February 2018 location will be San Diego (hosted by Qualcomm).	noted	No
11	Any Other Business