TDoc list

Tdoc List

2017-12-05 01:21

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‑173000	Agenda	WG Chairman	report		Yes	Yes	approved	No
3	IPR Reminder
4	Meeting Reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑173001	Report from SA3#88	MCC	report		Yes	Yes	approved	No
		S3‑173002	Report from SA3#88Bis Ad-Hoc	MCC	report		Yes	Yes	approved	No
		S3‑173467	Minutes of eMeeting on LTE re-direction	SA3 vice-chairman (Qualcomm)	report	discussion	Yes	Yes	noted	No
4.2	Report from SA Plenary	S3‑173004	Report from last SA meeting	WG Chairman	report		Yes	Yes	noted	No
4.3	Report from SA3-LI
5	Items for early consideration	S3‑173053	Draft LS on inclusion of the SEPP into the 5G architecture (to: SA2; cc: -; contact: Deutsche Telekom)	Deutsche Telekom AG	LS out	Approval	Yes	YesMCC: source is already SA3 Vodafone: mandatory for 5G? would be happy to remove "mandatory" Ericsson: operators cannot have any other connection except this proxy? if they have direct links the proxy would not be needed Nokia: concerned about "other 3rd parties" Deutsche Telekom: worried that other operator could send commands to the network; mandatory for "service based architecture" would be ok for us Orange: SA3 should define it is probably a better expression than mandatory conclusion: offline discussion, intention is to send it early this week to SA2 after offline discussion: Deutsche Telekom: we will drop the mandatory, Huawei wants to cc GSMA DES group Vodafone: what's the intention to cc GSMA? Deutsche Telekom: because they define the attributes Vodafone: suggests to not cc GSMA	revised	No	S3‑173413
		S3‑173413	Draft LS on inclusion of the SEPP into the 5G architecture (to: SA2; cc: -; contact: Deutsche Telekom)	Deutsche Telekom AG	LS out	Approval	Yes	Yes	revised	No	S3‑173431	S3‑173053
		S3‑173431	Draft LS on inclusion of the SEPP into the 5G architecture (to: SA2; cc: -; contact: Deutsche Telekom)	Deutsche Telekom AG	LS out	Approval	Yes	YesOrange: no need to include the architecture figure, why can security function not be defined in SA3? Why do we need to ask SA2? NTT DOCOMO: to indicate that there is something that is breaking their bus; figure was there so that they understand where it should go; Orange: then better remove e.g. text and refer to figure Interdigital: we need bubbles for SEPP Ericsson: no bubbles needed, it is not a service based interface	revised	No	S3‑173437	S3‑173413
		S3‑173437	LS on inclusion of the Security Edge Protection Proxy into the 5G architecture (to: SA2; cc: -; contact: Deutsche Telekom)	SA3	LS out	Approval	Yes	YesSA3 chair: to be sent out as soon as available LS was sent out on Tue noon of SA3 #89	approved	No		S3‑173431
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑173012	Reply LS on LTE call redirection to GERAN	C1-173752	LS in		Yes	YesNokia: no action for SA3 conclusion: no LS answer	not treated	No
		S3‑173497	Reply LS to C1-173752 = S3-173012 on LTE call redirection to GERAN (R2-1714121; to: CT1; cc: SA3, RAN3; contact: Ericsson)	RAN2	LS in		Yes	YesEricsson: it seems RAN2 has misunderstood the mechanism; suggests to postpone an answer and come back at SA3 #90 on this conclusion: LS answer is postponed to next SA3 meeting	postponed	No
		S3‑173016	LS on Certification/License and Identification of Aerial Vehicles	R2-1709973	LS in		Yes	YesNTT DOCOMO: no inputs on this, will discuss offline conclusion: no LS answer (so far)	noted	No
		S3‑173017	Reply LS on Certification/License and Identification of Aerial Vehicles	S2-178175	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173451	Reply LS to S2-178175 = S3-173017 on Certification/License and Identification of Aerial Vehicles (to: SA2, RAN2; cc: RAN3, SA3, GSMA IoT Drone Interest Group; contact: Qualcomm)	SA1	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173020	LS on provisioning of positioning assistance data via LPPa for broadcast	R2-1712030	LS in		Yes	YesEricsson: no action for SA3 conclusion: no LS answer	noted	No
		S3‑173027	LS on the support of Unicast and Groupcast transmission over PC5 for eV2X	S2-178181	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173518	LS on Extension of USAT Application Pairing mechanism (C6-170737; to: SA3; cc: -; contact: Gemalto)	CT6	LS in		Yes	YesNote: Attachment was missing in LS C6-170737. Orange: let's postpone this discussion to the next meeting conclusion: LS answer is postponed	postponed	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA
6.5	3GPP2
6.6	OMA
6.7	TCG	S3‑173036	TCG progress report	InterDigital, Inc.	report	Discussion	Yes	Yes1. TCG – Highlights • New/modified work items o TCG Industrial SG of Embedded Systems WG – chartered February 2017 o Device ID Composition Engine Arch (DICE) – chartered October 2016 • Publication of new or revised deliverables o * TCG Guidance for Securing Network Equipment – to publish December 2017 * o * TCG TNC Architecture 2.0 – published November 2017 * o * TCG TPM 2.0 Library v1.46 – public review November 2017 * o TCG Algorithm Registry r1.27 – public review November 2017 o * TCG Implicit ID Based Device Attestation – public review November 2017 * o TCG Device Identifier Composition Engine – member review November 2017 o TCG Errata v1.3 for TPM 2.0 v1.38 – published September 2017 o TCG Mobile Implementation Guidance – published September 2017 2. Meetings TCG Members Meeting in Portland, OR – 26 February - 1 March 2018 TCG Members Meeting in San Diego, CA – 18-22 June 2018 MPWG meets every Thursday at 10-11 ET TMS WG meets every Monday and Friday at 12-13 ET	noted	No
6.8	oneM2M
6.9	TC-CYBER
6.10	ETSI NFV security
6.11	Other Groups
7	Work Areas
7.1	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)	S3‑173028	Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity	S2-178182	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173469	Reply LS to S2-178182 = S3-173028 on algorithm selection in E-UTRA-NR Dual Connectivity (R2-1714124; to: SA2, CT1, SA3; cc: CT4, RAN3; contact: Intel)	RAN2	LS in		Yes	YesQualcomm: we sort of responded also with our LS on Wed morning (3444) conclusion: no LS answer	noted	No
		S3‑173408	Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity	C4-175349	LS in		Yes	YesHuawei: if no transfer, then there is no impact Nokia: does not agree SA3 chair: it seems the LS can be interpreted in different ways Huawei: thinks LS is clear conclusion: no LS answer	noted	No
		S3‑173113	CR to resolve EDCE5 ENs (revision of S3-172575)	Nokia	CR	Agreement	Yes	YesOrange: is this option1 for the first question of the technical votings? SA3 chair: no	agreed	No		S3‑172575
		S3‑173135	Solution for UP algorithm negotiation and activation for ENDC	Huawei, Hisilicon,	CR	Agreement	Yes	YesMCC: no CR number on CR cover; revision marks are not allowed on CR covers; curly quotes should not be used (use straight quotes instead) Huawei: would like to come back to this CR later	rejected	No	S3‑173414
		S3‑173360	Corrections to deletion of SCG Keys	Samsung	CR	Agreement	Yes	YesEricsson: in conflict with Qualcomm Tdoc Qualcomm: put this one first to not lose changes in the controversial discussions coming later	revised	No	S3‑173480
		S3‑173480	Corrections to deletion of SCG Keys	Samsung	CR	Agreement	Yes	Yes	agreed	No		S3‑173360
		S3‑173394	Emergency call handling in EDCE5	QUALCOMM CDMA Technologies	discussion		Yes	YesHuawei: SA2 should make a decision how to establish the bearer and then SA3 can decide what we do SA3 chair: we just checked whether we can be proactive Huawei: we could send LS to SA2 Ericsson: include RAN2 as well Qualcomm: we could include SA1 as well; SA3 chair: so we can prepare a draft LS to SA1, SA2, RAN2 and come back on it	noted	No
		S3‑173414	LS on Emergency call support for EDCE5 (to: SA1, SA2, RAN2; cc: -; contact: Qualcomm)	SA3	LS out	Approval	Yes	Yes	approved	No
		S3‑173042	Completing the specification of the algorithms to use between UE and SgNB in EDCE5	Qualcomm Incorporated	CR	Agreement	Yes	Yes	rejected	No		S3‑172367
		S3‑173162	Align 5G algorithm Identifiers with 33.501	Huawei; Hisilicon	CR	Agreement	Yes	YesVodafone: UE should never integrity protect RRC? This is confusing Nokia: why shall UE implement NIA0 for integrity protection of RRC signalling, unclear what the benefit is	rejected	No
		S3‑173288	Aligning the algorithm names between EDCE5 and 5G	Qualcomm Incorporated	CR	Agreement	Yes	YesQualcomm: will overlap with previous CRs Ericsson: there are some typos in E.3.10.1	revised	No	S3‑173481
		S3‑173481	Aligning the algorithm names between EDCE5 and 5G	Qualcomm Incorporated	CR	Agreement	No	Yes	agreed	No		S3‑173288
		S3‑173290	Aligning the specification of the key derivation function for key to use in security algorithms between UE and SgNB in EDCE5 with the 5G specification	Qualcomm Incorporated	CR	Agreement	Yes	YesMCC: wrong meeting number #88bis on CR cover SA3 chair: we will do a show of hands about the technical voting questions later on Monday SA3 chair: CR is an example for the removal Huawei: removing UP integrity will create 2 versions of 5G UE? Qualcomm: there is one that supports 5G core and one that does not SA3 chair: show of hands: one company, one hand, multiple NEC companies have just one hand/vote Questions: 1. removal of UP integrity algorithms as in 3042, 3290 supporting: Qualcomm, Ericsson, Nokia., Samsung, Intel => 5 companies 2. keeping UP integrity algorithms as in 3162 supporting: Huawei, Interdigital => 2 companies So majority for removal but we will leave time for further offline discussion Vodafone: we need to see whether MME needs changing SA3 chair: we will come to these questions afterwards	revised	No	S3‑173443	S3‑172576
		S3‑173443	Aligning the specification of the key derivation function for key to use in security algorithms between UE and SgNB in EDCE5 with the 5G specification	Qualcomm Incorporated	CR	Agreement	Yes	Yesas outcome of S3-173438: it is planned to add a note regarding UP integrity as requested by Huawei (details will be discussed offline)	agreed	No		S3‑173290
		S3‑173043	Using AS layer signalling to negotiate the algorithm used between the UE and SgNB	Qualcomm Incorporated	CR	Agreement	Yes	YesSA3 chair: so they are the same as last meeting Vodafone: but we will remove emergency case text? Qualcomm: yes, we were just asked to submit the CR as it was	rejected	No		S3‑172373
		S3‑173044	Using NAS layer signalling to negotiate the algorithm used between the UE and SgNB	Qualcomm Incorporated	CR	Agreement	No	Yes	withdrawn	Yes		S3‑172374
		S3‑173045	Using NAS layer signalling to negotiate the algorithm used between the UE and SgNB	Qualcomm Incorporated	CR	Agreement	Yes	YesSA3 chair: so they are the same as last meeting Vodafone: but we will remove emergency case text? Qualcomm: yes, we were just asked to submit the CR as it was	rejected	No		S3‑172374
		S3‑173103	UE NR capability negotiation for EDCE5 Discussion paper	Nokia	discussion	Agreement	Yes	YesProposal 1: For EDCE5 feature stay with LTE algorithm definitions this meets objectives of the WID, not necessary to introduce new algorithm definitions. Proposal 2: Adding octet9 and octet10 as NR algorithm in UE network capability will not impact a legacy MME, since it is supposed to treat the message in its entirety, but will not interpret the new octets. New added octets will not get dropped during a handover to another legacy MME. Huawei: prop. 2 will not impact legacy MME but we do not agree with proposal 1 and proposal 2 Ericsson: we have similar proposals as Nokia; current system does not work with protected with hash Vodafone: supports Nokia's discussion document Qualcomm: proposal 1 is ok but proposal 2 will need further clarification, as it is not enough as it is; in REL-15 we should specify a complete solution (so that we do not need add signalling later) Huawei: sees 3 solutions to address the bidding down mentioned by Qualcomm Nokia: do we want to change MME for EDCE5 or not is the question	noted	No
		S3‑173133	EDCE5: UE NR Security Capabilities Bidding-down	Huawei, Hisilicon,	discussion	Discussion	Yes	Yesproposal 1: As long as the UE is connected to LTE and all UE security capabilities including LTE security capabilities have been replayed correctly and successfully in the NAS SMC, the UE shall not consider the absence of the UE NR security capabilities in the NAS SMC as a security vulnerability. proposal 2: If the UE NR security capability is sent in a new IE over NAS, the legacy MME will drop the UE NR security capabilities. This will eliminate any potential bidding down attack. In addition, it eliminates changes to S10 interface which is required to inform target MME whether the UE NR security capabilities have been protected against bidding down or not. proposal 3: MeNB can support EDCE5 functionality while connected to a legacy MME. proposal 4: If during the Attach procedure, the MeNB receives the UE ENDC support capability in the UE LTE Radio capabilities, the UE ENDC authorization in the Restrictions list and does not receive the UE NR security capability from the MME, the MeNB shall set an indication “UE NR Capbilities mismatch” in the RRC Connection Reconfiguration message sent to the UE. Vodafone: will we need to change MME Huawei: no Nokia: how is bidding down prevented with the additional information element? Qualcomm: receiving MME will not be informed, with IE it will know whether bidding down happened NTT DOCOMO: are we trying to solve somethng that could be solved also by configuration? Qualcomm: you would have to analyze every case	noted	No
		S3‑173132	EDCE5 Support Legacy MME: UE NR Sec Cap delivery and MME Interworking	Huawei, Hisilicon,	discussion	Discussion	Yes	Yesproposal: UE NR security capabilities shall be added in a new IE over NAS. It is more advantageous and serves the security solution better. SA3 shall communicate the recommendation to CT1 & CT4.	noted	No
		S3‑173131	ENDC5 support legacy MME: Delivery UE NR sec. cap. to MeNB in X2 & S1 HO	Huawei, Hisilicon,	discussion	Discussion	Yes	YesProposed Solution: UE sends its NR security capabilities during X2 & S1 Handover	noted	No
		S3‑173134	Supporting EDCE5 with Legacy MME	Huawei, Hisilicon,	CR	Agreement	Yes	YesMCC: adding Editor's notes in a spec under CR control Huawei: S3-173134 is implementation of S3-173131 conclusion: covered already by S3-173445	rejected	No
		S3‑173265	Discussion document on Algorithm selection in EDCE5	VODAFONE Group Plc	discussion	Approval	Yes	Yes	revised	No	S3‑173393
		S3‑173393	Discussion document on Algorithm selection in EDCE5 (with attachments)	VODAFONE Group Plc	discussion	Approval	Yes	YesVodafone: is a copy of an email that was provided via the reflector	noted	No		S3‑173265
		S3‑173268	CR to 33.401 - Using existing NAS, S1-AP and X2-AP signalling to negotiate the algorithm used by NR-PDCP for EPC controlled dual connectivity between E-UTRAN and NR	VODAFONE Group Plc	CR	Agreement	Yes	YesMCC: no CR number on CR cover; CR clashing with S3-173340; wrong reference [42] for TS 36.413; missing reference text for clause 2 for TS 37.340, TS 38.323, TS 29.274, TS 36.423 conclusion: covered already by S3-173445 Vodafone: is similar to Nokia Discussion paper and also overlapping with Ericsson views so with some merging activities we could progress on this	rejected	No
		S3‑173333	Discussion on the NR algorithm bidding-down attack with legacy MME	Ericsson	discussion		Yes	YesAttack: Observation 1: The bidding-down attack applies only to the NR algorithms that are used in the access stratum. Observation 2: The attack does not apply to NAS security. Observation 3: The attack is successful only with initial, unprotected Attach. Mobility: Observation 4: Even if the falsified NR algorithms were forwarded by the source legacy MME to the target Rel-15 MME, the UE will send the NR algorithms again in integrity protected TAU. Interworking: Observation 5: All earlier generations are forwarding UE network capabilities to the newer generation networks without bidding-down protection.	noted	No
		S3‑173336	Solution using stand-alone TAU	Ericsson	discussion	Approval	Yes	Yesproposal: SA3 chooses the TAU based solution to prevent the bidding-down attack, and to the use of legacy MME with EDCE5 Qualcomm: we have problems with the TAU proposal Nokia: TAU will affect legacy MME and legagcy UE? Ericsson: legacy UEs not impacted Huawei: legacy MME will not understand new information, passing it on to others without any security is not a good solution Qualcomm: stage 2 and stage 3 are not aligned from REL-8 onwards	noted	No
		S3‑173338	Solution using local mapping of NR algorithms at NR RRC layer	Ericsson	discussion	Approval	Yes	Yesproposal: - NR RRC layer in eNB/gNB is allowed to do local mapping of NR algorithms if the UE is known to support EDCE5 but if the NR algorithms are not available from S1/Xn/X2 interfaces. - There are two ways to do the mapping, and we propose that SA3 chooses option 1 below: 1. The mapping is based on the LTE algorithms that the UE supports. In this way, the support of ZUC could be assumed if the UE supports ZUC. 2. The mapping can be based on the standard (33.501) that mandates the UE to implement certain NR algorithms. In this case, ZUC could not be assumed.	noted	No
		S3‑173340	Using NAS layer signalling to negotiate the algorithm used between the UE and SgNB	Ericsson	CR	Agreement	Yes	YesMCC: revision marks and comments not allowed on CR covers; CR clashing with S3-173268; wrong rev - on CR cover instead of rev 3 conclusion: covered already by S3-173445	rejected	No		S3‑172374
		S3‑173291	Handling security algorithms in LTE and NR	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑173292	Making the NAS layer bidding down in EPC automatically cover new security features	Qualcomm Incorporated	CR	Agreement	Yes	Yesconclusion: covered already by S3-173445	rejected	No
		S3‑173194	Allowing UE to accept replayed security capbilities on LTE without UE NR security capabilities	Huawei; Hisilicon, China Mobile	CR	Agreement	Yes	YesMCC: revision marks are not allowed on CR covers; 2 times Note 4; WI code EDCE5 does not fit to AI 5GS_Ph1-SEC Vodafone: some show of hands on remaining questions would be good to know who are the contacts Huawei: we could consider 3 questions: EDCE5 to work with legacy MME?, UE NR security in new IE?, mapping LTE algorithms to NR? Qualcomm: suggests instead of a show of hands we could have a discussion over Monday lunch time SA3 chair: seems the questions are: - solution would work with legacy MME? - solution should be future proof? - having a new IE? Orange: unclear what future proof means; suggests to check regarding legacy MME only and we can then see how to continue Vodafone: support for the existing 3 algorithms or future algorithms, legacy needs to support existing 3 and we should be able to extend in the future NTT DOCOMO: suggests to have lunch break discussion about the questions, there seem to be different views regarding potential upgrades in the future SA3 chair: see 4 discussion topics: legacy MME, future proof, now IE or not, having algorithm mapping or not Vodafone: it seems to be an implementation discussion that we need conclusion: covered already by S3-173445	rejected	No
		S3‑173419	Report of offline discussion EDCE5 security	NTT DOCOMO	report	discussion	Yes	Yesconclusion: further offline discussion will happen on Monday afternoon/evening to converge on one CR and to avoid technical votings on Tue; we will see the CR proposal on Tue morning and then decide on whether the technical voting on Tue 1pm is needed	noted	No
		S3‑173438	Report of Tue evening offline discussion EDCE5 security	Qualcomm	report	discussion	Yes	YesNTT DOCOMO: with this Tdoc no technical votes will be needed; still some open issues Vodafone: CT1 will need to be informed about the outcome Vodafone: CR takes care of all 3 questions Huawei: the UP integrity aspect was not yet covered SA3 chair: we had S3-173290 which was showing if we remove UP integrity Huawei: sees that as a UE issue so would like to hear views from other SA3 chair: we had a show of hands where we ended up with 5 to 2 for removing Orange: motivation for removing UP integrity algorithm? Qualcomm: why supporting a normative algorithm that is never used? NTT DOCOMO: we do not have to worry about HO scenarios where this could be relevant? show of hands: - removal of UP integrity algorithms: Qualcomm, Ericsson, Nokia, NEC, Samsung, Vodafone, Intel - keeping of UP integrity algorithms: Huawei SA3 chair: UP integrity debate will continue in Tue morning coffee break after offline discussion: Huawei: could accept to remove UP integrity but would like to add note in a revision of S3-173290 conclusions: - based on S3-173438 Qualcomm will work on a CR in S3-173445 - note will be added in next revision of S3-173290 in S3-173443, Huawei will make a proposal - Vodafone will draft an LSout in S3-173444 to inform other WGs (which will in the end attach CR S3-173445) - no technical votes will be needed	noted	No
		S3‑173444	LS on EDCE5 algorithm indication (to: CT1, CT4, RAN2, RAN3; cc: SA2; contact: Vodafone)	SA3	LS out	Approval	Yes	Yeswill have S3-173445 attached LS was sent out on Wed morning of SA3 #89	approved	No
		S3‑173445	Handling the algorithms for use between a UE and SgNB for EN-DC	Qualcomm, NEC, Vodafone	CR	Agreement	Yes	Yes	agreed	No
7.2	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)	S3‑173523	TS 33.501 v0.5.0 collecting agreements of SA3 #89	NTT DOCOMO	draft TS	Agreement	No	Yessending out before Thu 7.12.17 eob CET comments before Mon 11.12.17 eob CET agreed version sent out before Wed 13.12.17 eob CET	for email discussion	No	S3‑173524
		S3‑173524	TS 33.501 v0.6.0 doing a restructuring	NTT DOCOMO	draft TS	Agreement	No	Yessending out before Tue 19.12.17 eob CET comments before Thu 21.12.17 eob CET agreed version sent out before Fri 22.12.17 eob CET Ericsson: some sections will have to be merged NTT DOCOMO: put the text in the same sections and if the text needs to be modified this can be done in pCRs next time SA3 chair: all pCRs to next SA3 meeting have to be based on this new TS version v0.6.0	for email discussion	No		S3‑173523
		S3‑173530	Draft agenda related to 5GS_Ph1-SEC for SA3 #90	NTT DOCOMO	discussion	discussion	No	Yesinputs should be sent by Monday 4.12. rapporteur will provide draft version on Tue 5.12. via the SA3 reflector On Thu 7.12. rapporteur will send out the endorsed S3-173530 via the SA3 email reflector	for email discussion	No
7.2.1	Key hierarchy	S3‑173144	Update key hierarchy by adding Kseaf and Kausf	Huawei & Hisilicon	pCR	Approval	Yes	Yesthere are related Tdocs: Huawei: 3145, 3146, 3147, 3149 Qualcomm: 3294 Ericsson: 3343 Nokia: has a similar proposal in 3129 but fine to go with Ericsson proposal in S3-173343 SA3 chair: so let's see 3149, 3294 and 3343 as well conclusion: S3-173144 is merged in S3-173514	merged	No
		S3‑173332	Security for multiple NAS connections	NEC EUROPE LTD	pCR	Approval	Yes	YesNEC: dependent on other topic SA3 chair: so we will not treat it now	not treated	No
7.2.2	Key derivation	S3‑173127	Preventing bidding down between 5G releases - discussion - was 2401	Nokia, Qualcomm Incorporated	discussion	Decision	Yes	YesMCC: Tdoc type corrected from pCR to discussion	noted	No
		S3‑173345	Using NAS SMC to protect the FeatureSet in phase 2	Ericsson	discussion	Approval	Yes	Yesproposal: SA3 should conclude that the potential bidding down problem between 5G phases can be solved by NAS SMC. There is no need to solve the problem in phase 1. We would also like to remind that there is no agreement in 3GPP that there will be standalone SEAF in phase 2 Interdigital: has problems to understand the proposal, picture in S3-173345 is insecure Orange: supports Ericsson NTT DOCOMO: supports the Nokia proposal (S3-173127) as it is straightforward Ericsson: no need to negotiate releases over air interface NTT DOCOMO: limits operator deployment on AMF and will be complicated Huawei: when it comes in phase 2 we will address it SA3 chair: some people say "do it in phase 1" while others say "do it in phase 2" Qualcomm: you may get 2 sets of AMFs Orange: we are reopening agreements we had for phase 1 conclusion: no consensus	noted	No
		S3‑173128	Preventing bidding down between 5G releases - was 2403	Nokia, Qualcomm Incorporated	pCR	Approval	Yes	Yes	postponed	No
		S3‑173327	Updates to clause 6.2.2 Key Derivation and distribution scheme and Annex A.7	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑173129	Computation of Key in AUSF for 5G AKA - was 2416	Nokia	pCR	Approval	Yes	Yesconclusion: merged in S3-173514	merged	No
		S3‑173149	Discussion on Kausf in 5G AKA and EAP-AKA'	Huawei & Hisilicon	discussion		Yes	YesMCC: type corrected from pCR to discussion	noted	No
		S3‑173145	Kausf in EAP-AKA‘	Huawei & Hisilicon	pCR	Approval	Yes	Yesconclusion: merged in S3-173514	merged	No
		S3‑173146	key derivation for Kseaf in Annex	Huawei & Hisilicon	pCR	Approval	Yes	Yesconclusion: merged in S3-173514	merged	No
		S3‑173147	key derivation for Kseaf for 5G AKA	Huawei & Hisilicon	pCR	Approval	Yes	Yesconclusion: merged in S3-173514	merged	No
		S3‑173148	key derivation (Kgnb, NH, Kn3iwf)	Huawei & Hisilicon	pCR	Approval	Yes	YesEricsson: error on 2nd change and can be merged with Ericsson document Interdigital: first and fourth change same? Qualcomm: editor's note to align KgNB and KN3IWF derivation conclusion: ... => Kamf, editor's note will be added	revised	No	S3‑173517
		S3‑173517	key derivation (Kgnb, NH, Kn3iwf)	Huawei & Hisilicon, Ericsson	pCR	Approval	Yes	Yesincludes also aspects of S3-173082 and S3-173083	approved	No		S3‑173148
		S3‑173082	Annex A.X (* derivation function)	Ericsson	pCR	Approval	Yes	Yesconclusion: merged into S3-173517	merged	No
		S3‑173083	Annex A.X (KgNB* derivation function)	Ericsson	pCR	Approval	Yes	Yesconclusion: merged into S3-173517	merged	No
		S3‑173289	Providing details of the key derivation for the security algorithm keys	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑172370
7.2.3	Mobility	S3‑173143	Intra-gNB retaining AS keys exception	Huawei, Hisilicon	pCR	Approval	No	Yes	revised	No	S3‑173212
		S3‑173212	Intra-gNB retaining AS keys exception	Huawei, Hisilicon,China Mobile	pCR	Approval	Yes	Yes	not treated	No		S3‑173143
		S3‑173326	Reordering clause 6.5	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑173096	Clause 8.3.1.3.3 (horizontal key derivation of K_AMF at N2-Handover)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173238	Kamf Derivation when AMF set changes	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173386	Idle mode mobility with horizontal key derivation	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173137	Flexible retaining AS keys solution	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	rejected	No
		S3‑173150	Modifications of Clause 8.3.1.1	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
7.2.4	AS security	S3‑173084	Clause 8 (open issues in AS security)	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑173366	Discussion on user plane integrity protection for DRB	Samsung	pCR	Approval	Yes	YesProposal 1: AS SMC procedure is used to select the UP integrity algorithm. Proposal 2: 5QI value indicates whether to enable the UP integrity protection for a particular DRB or not. Using the 5QI value, the UE and gNB determines whether to apply UP integrity protection and establish the DRB accordingly. Ericsson: supports proposal 1, proposal 2 is up to RAN people Qualcomm: same view as Ericsson Huawei: does not support proposal 1 & 2 Nokia: supports proposal 2 Huawei: Let's keep this Tdoc open and see other Tdocs first conclusion: merged into S3-173516	merged	No
		S3‑173087	Clause 8 and Annex D.1 (user plane security – null-integrity and non-activation of integrity protection)	Ericsson	pCR	Approval	Yes	YesHuawei: does not agree with editor's note conclusion: further offline discussion about editor's note needed conclusion: merged into S3-173516	merged	No
		S3‑173088	Clause 8 (user plane security - integrity protection)	Ericsson	pCR	Approval	Yes	Yesconclusion: merged into S3-173516	merged	No
		S3‑173402	Nokia comments on S3-173088	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑173307	Use of integrity protection of user data in 5GS	Qualcomm Incorporated	pCR	Approval	Yes	YesEricsson: is reopening a discussion	rejected	No
		S3‑173201	Support No integrity for UP	Huawei; Hisilicon	pCR	Approval	Yes	YesEricsson: does not agree with last change Huawei: same view, change not needed NTT DOCOMO: we do not have NIA0 in LTE, they can easily compress it Ericsson: we have NIA0 SA3 chair: we could just have an editor's note and clarify this	revised	No	S3‑173493
		S3‑173493	Support No integrity for UP	Huawei; Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑173201
		S3‑173494	Draft LS on over the air overhead of the use of integrity protection algorithm	Huawei	LS out	Approval	No	YesEricsson: we do not need to send this LS acc. to latest RAN news	withdrawn	Yes
		S3‑173089	Clause 8 (user plane security - confidentiality)	Ericsson	pCR	Approval	Yes	YesHuawei: would like to keep this open conclusion: merged into S3-173516	merged	No
		S3‑173111	Cluase 8.4 UP Security	Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑173495
		S3‑173495	Cluase 8.4 UP Security	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑173111
		S3‑173197	UP security policy determination	Huawei; Hisilicon	pCR	Approval	Yes	YesNokia: too much signalling	postponed	No
		S3‑173198	Discussion on granularity of UP seucirty	Huawei; Hisilicon,ZTE	discussion	Approval	Yes	YesMCC: tyoe corrected from pCR to discussion Proposal 1: Option a) is endorsed by SA3. Proposal 2: Send a LS to SA2 and RAN2 to inform the AS security mechanism. Ericsson: requires more offline discussion Nokia: Tdoc is linked to granularity discussion	noted	No
		S3‑173199	pCR on UP protection granulairty	Huawei; Hisilicon	pCR	Approval	Yes	Yesconclusion: merged into S3-173516	merged	No
		S3‑173090	Clause 8 (relation between RRC and user plane security algorithms)	Ericsson	pCR	Approval	Yes	Yesconclusion: merged into S3-173516	merged	No
		S3‑173091	Clause 8 (conflict between RAN and CN)	Ericsson	pCR	Approval	Yes	YesHuawei: is an overload issue, does not agree to editor's note Qualcomm: if this is a problem, then we need to address it conclusion: merged into S3-173516	merged	No
		S3‑173112	Clause 5.2.9 Requirements for gNB DU-CU interface	Nokia, Telecom Italia	pCR	Approval	Yes	YesHuawei: wants to add a note Ericsson: supports to go with Nokia proposal	revised	No	S3‑173496
		S3‑173496	Clause 5.2.9 Requirements for gNB DU-CU interface	Nokia, Telecom Italia	pCR	Approval	Yes	Yes	approved	No		S3‑173112
		S3‑173395	pCR to 33.501 to 5.2.9 - Requirements for F1 interface revisited	DOCOMO Communications Lab.	pCR	Approval	Yes	Yessee S3-173496 instead	rejected	No
		S3‑173023	LS on security during Resume reject in INACTIVE state in NR	R2-1712052	LS in		Yes	YesQuestions from the LS: Q.1: Does SA3 have any security concern with the above RAN2 agreement? For example, there can be DoS attack by a fake gNB sending one or more successive response messages with Wait timer. Further RAN2 would like to ask if SA3 has any comments regarding the Wait timer values. Q.2: Does SA3 sees any risk of replay attacks, from re-using the same I-RNTI and same key to derive the (short) MAC-I for the subsequent resume request message after a rejection? Nokia: we need to reply on this conclusion: LS answer postponed	postponed	No
		S3‑173072	Security aspects of RESUME REJECT in INACTIVE state in NR	ZTE Corporation	discussion	Approval	Yes	Yes	not treated	No
		S3‑173211	Discussion on Security Issues with RRC Reject for INACTIVE Mode	Intel Corporation (UK) Ltd	discussion	Decision	Yes	Yes	not treated	No
		S3‑173086	Clause 8.1.2.2 (AS security mode command procedure) for RRC	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173186	pCR to TS 33.501 Security handling in for RRC Connection Re-establishment	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173195	Security-algoritms-negotiation-for-Initial-AS-security-context	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yesconclusion: merged into S3-173516	merged	No
		S3‑173085	Clause 8.1.2.1.1 (AS algo. initial context) for RRC	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173196	AS Security Negotiation and Activation	Huawei; Hisilicon	pCR	Approval	Yes	Yesconclusion: merged into S3-173516	merged	No
		S3‑173187	pCR to TS 33.501 5G-RAN key identification	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173188	pCR to TS 33.501 5G-RAN key lifetimes	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173180	Adding context on Establishment of keys for cryptographically protected radio bearers (subclause 8.2.1.2.2)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173142	Security Procedures between 5G Network Functions	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173136	Address EN in requirements for gNB setup and configuration	Huawei, Hisilicon,	pCR	Approval	Yes	Yes	not treated	No
		S3‑173202	Requirements for UP and CP for the gNB	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑173203	Replay protection	Huawei; Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173204	Integrity clause	Huawei; Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173205	Confidentiality clause	Huawei; Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173141	Adding Forward & Backward Security definition to TS33.501	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173190	Draft reply LS to R2-1712052 = S3-173023 on security during Resume reject in INACTIVE state in NR (to: RAN2; cc: -; contact: Huawei)	Huawei, Hisilicon	LS out	Approval	Yes	YesMCC: compare to S3-173213 and S3-173389	not treated	No
		S3‑173200	Draft LS on AS security (to: SA2, RAN2; cc: -; contact: Huawei)	Huawei; Hisilicon	LS out	Approval	Yes	Yesconclusion: LS will not be sent	rejected	No
		S3‑173389	Draft reply LS to R2-1712052 = S3-173023 on security during Resume reject in INACTIVE state in NR (to: RAN2; cc: -; contact: Ericsson)	Ericsson	LS out	Approval	Yes	YesMCC: Tdoc is not an LSout as it does not use the LSout template; compare S3-173213 and S3-173190	not treated	No
		S3‑173094	Clause 8.2.2.1 (key handling – RRC INACTIVE/CONNECTED state transition)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173179	Adding context on Transition from CM-IDLE to CM-CONNECTED (subclause 8.2.1.2.1)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173181	Adding context on Transition from CM-CONNECTED to CM-IDLE (subclause 8.2.1.2.3)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173213	Draft reply LS to R2-1712052 = S3-173023 on security during Resume reject in INACTIVE state in NR (to: RAN2; cc: -; contact: Intel)	Intel Corporation (UK) Ltd	LS out	Approval	Yes	YesMCC: LS does not indicate draft in the title and has source: SA3; compare S3-173389 and S3-173190	not treated	No
		S3‑173189	Discussion on security during Resume reject in INACTIVE state in NR	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	not treated	No
		S3‑173095	Clause 8.2.2.2 (key handling – RRC INACTIVE mobility)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173092	UE-assisted network-based detection of false-cell-camping - disc	Ericsson, AT&T, China Mobile, T-Mobile USA	discussion	Endorsement	Yes	Yes	not treated	No
		S3‑173035	Support of PKI for NodeB Authentication	AT&T, MITRE, Interdigital, TCG	discussion	Decision	Yes	Yestreated in connection with S3-173064; BT: how do we get emergency calls to work? is unncessary for commercial networks at the moment, you could do this proprietary if you really need it Ericsson: we see a value of a SI but not now; Orange: SI about the support of a solution is not appropriate, it should be about requirements; BT: limited system for special customers; SA3 chair: due to current time pressure bringing the WI/SI proposal at a later stage (after completion of phase 1) would be better; Qualcomm: also suggests to look at the TR in which we collected the threats Orange: sees that the proposed WI/SI has also RAN and SA2 impact Ericsson: suggests to look also at S3-173093	noted	No
		S3‑173093	UE-assisted network-based detection of false-cell-camping - pCR	Ericsson, AT&T, China Mobile, T-Mobile USA	pCR	Approval	Yes	YesEricsson: also Telecom Italia is supporting this Nokia: supports the Tdoc but suggests to add something to 8.2.3 SA3 chair: someone against the proposal? KPN: some worries Qualcomm: no changes needed ? Ericsson: not in phase 1 Qualcomm: why not putting it in the informative annex? there is no change of the normative part Huawei: same view as Qualcomm and KPN Orange: agrees with Huawei, this may also have impact on RAN	revised	No	S3‑173499
		S3‑173499	UE-assisted network-based detection of false-cell-camping - pCR	Ericsson, AT&T, China Mobile, T-Mobile USA	pCR	Approval	Yes	YesEricsson: only Annex remained	approved	No		S3‑173093
		S3‑173365	pCR on signalling procedure for periodic local authentication	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑173510	Draft LS on UP security policy (to: SA2, RAN3; cc:-; contact: Huawei)	Huawei	LS out	Approval	No	YesEricsson: not sure about algorithms in bullet list Huawei: would be fine for phase 1 Nokia: why is RAN2 in the to: list? Ericsson: which group defines policy control function? Huawei: then we include also CT3 on cc:	withdrawn	Yes	S3‑173520
		S3‑173520	LS on User Plane Security Policy (to: SA2, RAN3; cc: CT3; contact: Huawei)	SA3	LS out	Approval	Yes	Yes	approved	No		S3‑173510
		S3‑173511	Report from offline session about UP security granularity	NTT DOCOMO	report	discussion	Yes	Yesoffline discussion was held during Thu lunch break SA3 chair: so points 7 and 10 are still under discussion NTT DOCOMO: 1. was the basis	noted	No
		S3‑173516	Agreements on UP security	Ericsson, Huawei, Samsung, Qualcomm, Nokia, HiSilicon	pCR	Approval	Yes	Yesthis pCR is merging aspects of the following pCRs: Ericsson: 3087, 3088, 3089, 3090, 3091 Huawei: 3195, 3196, 3199 after the results of the offline discussion in S3-173511	approved	No
7.2.5	NAS security	S3‑173108	Clause 6.6.2.2 Multiple active NAS connections	Nokia	pCR	Approval	Yes	YesSA3 chair: we will discuss S3-173108, S3-173371, S3-173300, S3-173331, S3-173234, S3-173193 together	not treated	No
		S3‑173371	Multiple active NAS connections in the same PLMN’s serving network	Ericsson	pCR	Approval	Yes	YesEricsson: similar to Nokia's proposal, Nokia assumes dynamic handling	not treated	No
		S3‑173300	Discussion on the NAS security contexts when registered on both 3GPP and non-3GPP access in the same PLMN	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑173331	Threat model without multiple NAS keys	NEC EUROPE LTD	pCR	Approval	Yes	Yes	rejected	No
		S3‑173234	Adding content to NAS security	Huawei, Hisilicon	pCR	Approval	Yes	Yes	rejected	No
		S3‑173193	Add new requirements for multiple registrations in the same PLMN	Huawei, Hisilicon, China Unicom	pCR	Approval	Yes	YesSA3 chair: we will discuss S3-173108, S3-173371, S3-173300, S3-173331, S3-173234, S3-173193 together Ericsson: all proposals are rather close together apart from NEC proposal Intel: does it work for reauthentication? Nokia: reauthentication is simple (only when 2 it's complex), dispute is within one PLMN Intel: fine if same for all access technologies conclusion: further offline discussion needed	rejected	No
		S3‑173107	Clause 6.6.5 Handling of NAS counts -multiple NAS links	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173109	Clause 6.3.4.2 Multiple registrations in same PLMN	Nokia	pCR	Approval	Yes	Yesnot treated after S3-173330	not treated	No
		S3‑173106	Changes for Multiple NAS links Annex D	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173359	Multiple registrations in different PLMNs serving networks	Ericsson	pCR	Approval	Yes	Yes	postponed	No
		S3‑173177	Adding context on Transition from RM-REGISTERED to RM-DEREGISTERED (subclause 8.2.1.1.1)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173178	Adding context on Transition from RM-DEREGISTERED to RM-REGISTERED (subclause 8.2.1.1.2)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173383	Connection state transitions in TS 33.501	Ericsson, Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑173489
		S3‑173489	Connection state transitions in TS 33.501	Ericsson, Huawei, Hisilicon	pCR	Approval	No	Nomerges also S3-173179, S3-173180, S3-173181	withdrawn	Yes		S3‑173383
		S3‑173382	Registration state transitions in TS 33.501	Ericsson, Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑173488
		S3‑173488	Registration state transitions in TS 33.501	Ericsson	pCR	Approval	No	Nomerges also S3-173177, S3-173178	withdrawn	Yes		S3‑173382
		S3‑173184	pCR to TS 33.501 KDF negotiation	Huawei, Hisilicon	pCR	Approval	Yes	Yestreated in connection with S3-173328/3329	rejected	No
		S3‑173403	Nokia comments on KDF negotiation contributions 3184,3328,3329	Nokia	discussion	Endorsement	Yes	Yestreated in connection with S3-173328/3329	noted	No
		S3‑173362	New requirements for algorithm selection in TS 33.501	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173097	Clause 6.6.6 (rectifying partial protection aspects)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173293	Aligning the protection of initial NAS messages and the NAS Security Mode procedure subclauses	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No		S3‑172383
		S3‑173404	Commenting contribution on S3-173293 for protection of initial NAS message	Huawei Tech.(UK) Co., Ltd	discussion	Discussion	Yes	Yes	not treated	No
		S3‑173405	Companion pCR to S3-173304	Huawei Tech.(UK) Co., Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑173110	Clause 6.7.2 NAS SMC procedure (over any NAS connection)	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173176	Corrections on NAS security mode command procedure (subclause 6.7.2)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173185	Delete allowed NSSAI in NAS SMC	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173361	Exception lists of NAS and RRC message to be integrity protected and encrypted	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173156	Enforcement of Session Key with DH Procedure in Serving Networks	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173262	pCR to 33.501 - DH procedure with AMF for protection against passive eavesdropping	VODAFONE Group Plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑173275	pCR- Updating NAS security mode command procedure	China Mobile	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑173276	pCR- Updating NAS security mode command procedure	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑173277	Adding Security Mode of the Session key to the SMC procedure	China Mobile	discussion		Yes	Yes	not treated	No
7.2.6	Security context management	S3‑173175	Adding the requirement of NEA0 and NIA0	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑173173	Fixing the definition of NEA and NIA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑173308	Multiple Registrations in different PLMNs using K_AUSF	Qualcomm Incorporated	pCR	Approval	Yes	YesDeutsche Telekom: is this optimisation really needed Qualcomm: is optional feature for UE and network Ericsson: not really needed in phase 1 Orange: key derivation should be discussed first Nokia: we have a number of comments and this proposal cannot work Ericsson: has a different solution in S3-173359	postponed	No
		S3‑173330	Multiple registrations in the same PLMN	NEC EUROPE LTD	pCR	Approval	Yes	YesEricsson: belongs to same set of documents that were postponed Nokia: S3-173109 clashes with this pCR Huawei: S3-173192 also clashes with this pCR	postponed	No
		S3‑173364	New UE requirement to store two 5G security contexts in TS 33.501	Ericsson	pCR	Approval	Yes	YesQualcomm: is in wrong place Ericsson: would like to postpone this	postponed	No
		S3‑173328	Discussion on UE 5G Security Capability with KDF identifiers	NEC EUROPE LTD	discussion	Discussion	Yes	YesMCC: Tdoc type corrected from pCR to discussion	noted	No
		S3‑173329	KDF ID to be included as a part of UE Security capabilities	NEC EUROPE LTD	pCR	Approval	Yes	YesHuawei: has a related Tdoc in S3-173184 (AI 7.2.5) Nokia: has S3-173403 (AI 7.2.5)	rejected	No
		S3‑173105	Handling security contexts within the serving network	Nokia, Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: also Ericsson is supporting this Tdoc Qualcomm: why should subscriber identity in the clear Orange: should be replaced by SUPI Ericsson: under 6.3.3.4 in 2nd paragraph: wondering about "upgraded"	revised	No	S3‑173519
		S3‑173519	Handling security contexts within the serving network	Nokia, Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑173105
7.2.7	Visibility & configurability	S3‑173218	Security visibility	China Unicom	pCR	Approval	Yes	Yes	not treated	No
		S3‑173396	pCR to 33.501 5.4.1 - Clarification of security indication	NTT DOCOMO, Department of Commerce, KPN	pCR	Approval	Yes	Yes	not treated	No
		S3‑173227	Clarification of security indication for UE (subclause 5.4.1)	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑173126	Visibility and configurability supporting serving network authorization	Nokia, LG	pCR	Approval	Yes	Yes	not treated	No
		S3‑173219	Security configurability	China Unicom	pCR	Approval	Yes	Yes	not treated	No
7.2.8	Primary authentication	S3‑173104	Clause 6 5G AKA over non-3gpp access	Nokia, Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	not treated	No
		S3‑173294	Specifying the key derivation when using 5G AKA	Qualcomm Incorporated	pCR	Approval	Yes	Yestreated in connection with S3-173144 (AI 7.2.1) conclusion: merged in S3-173514	merged	No		S3‑172382
		S3‑173343	Unified handling of Kausf with 5G AKA and EAP-AKA’	Ericsson	pCR	Approval	Yes	Yestreated in connection with S3-173144 (AI 7.2.1)	revised	No	S3‑173514
		S3‑173514	Unified handling of Kausf with 5G AKA and EAP-AKA’	Ericsson, Qualcomm, Nokia, Huawei, Hisilicon	pCR	Approval	Yes	Yesis a revision of S3-173343 and will include also changes from merged Tdocs 3144, 3145, 3146, 3147, 3294, 3129	approved	No		S3‑173343
		S3‑173312	Adding numbered figure for EAP-AKA'	KPN	pCR	Approval	Yes	Yes	not treated	No
		S3‑173313	Adding numbered figure for 5G AKA.	KPN	pCR	Approval	Yes	Yes	not treated	No
		S3‑173270	Resolve Editor’s Note in clause 6.1.3.2 of TS 33.501	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173273	Adding 5G Authentication Confirmation Answer for 5G-AKA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173269	Removal of the number of AVs requested in Authentication Information Request message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173397	pCR to 33.501 6.1.2, 6.1.3.2 – only one authentication vector at a time	DOCOMO Communications Lab.	pCR	Approval	Yes	Yes	not treated	No
		S3‑173400	Discussion on multiple authentication vectors in response to S3-173397and other docs	VODAFONE Group Plc	discussion	Information	Yes	Yes	not treated	No
		S3‑173344	Construction of serving network name with 5G AKA and EAP-AKA’	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173125	Authorization of SN by UE	Nokia, LG	pCR	Approval	Yes	Yes	not treated	No
		S3‑173391	Information about new I-D related to EAP-AKA	Ericsson	discussion	Information	Yes	YesMCC: type corrected from pCR to discussion	not treated	No
		S3‑173263	pCR to 33.501 - DH procedure with SEAF for protection against passive eavesdropping	VODAFONE Group Plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑173155	Security Procedures for EAP-TLS	Huawei, Hisilicon, Ericsson, Qualcomm Incorporated, China Mobile	pCR	Approval	Yes	Yes	not treated	No
7.2.9	Secondary authentication	S3‑173342	Alignment with SA2 procedure and general cleanup	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173341	Resolve ENs on use of Normative language	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173228	Clarification on network slice access authentication and authorization	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑173163	Binding Primary and Secondary authentication	Intel Corporation (UK) Ltd	discussion	Discussion	Yes	Yes	not treated	No
		S3‑173401	Comments to S3-173163	China Mobile	discussion		Yes	Yes	not treated	No
		S3‑173301	Identifying a problem with secondary authentication	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No		S3‑172380
		S3‑173164	Secure binding of primary and secondary authentication	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑173165	Secure Data Port for Secondary Authentication	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑173302	pCR to update the secondary authentication procedure to include the authentication/authorization confirmation between UE and SMF when a key generating EAP method is used	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑173157	ID linkage verification in secondary authentication	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173303	pCR to update the secondary EAP authentication clause to take into account the roaming scenario	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑173152	Secondary authentication via NEF	Huawei & Hisilicon	discussion		Yes	YesMCC: type corrected from pCR to discussion Proposal1: The SMF may use the NEF for DN authentication/authorization according to DN policy, local configuration, and/or the application identifier provided by the UE considering the impact to the AF. Proposal2: The DN authentication/authorization function may authenticate/authorize the PDU session establishment and return the authentication/authorization result to the SMF via the NEF. Nokia: is an architecture change, not in line with SA2 Orange: too late to modify SA3 chair: there is no support for the proposals, also related pCR 3151 is not agreed	noted	No
		S3‑173151	Discussion on secondary authentication	Huawei & Hisilicon	pCR	Approval	Yes	Yes	rejected	No
		S3‑173158	DN authorization grant and revocation	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173166	Secondary Re-Authentication	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑173159	Secondary Authentication for multiple PDU sessions	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
7.2.10	Interworking	S3‑173170	Discussion on security of interworking with N26	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	revised	No	S3‑173232
		S3‑173232	Discussion on security of interworking with N26	Huawei, Hisilicon	discussion	Discussion	Yes	YesProposal 1: MMEs are mandatory to upgrade for interworking if the above observations are taken into consideration. Proposal 2: Native security context takes precedence over mapped security context in the target system, but the source system is always required to verify the UE with its native security context when it receives the context request message. Proposal 3: The anchor key shall never be sent to the other system during the interworking procedure. Nokia: does not agree to proposal 1 Qualcomm: disagrees with proposal 1 Ericsson: should we say "no MME impact"? Qualcomm: it shall be possible to have interworking with legacy MMEs, so no upgrading should be needed for 4G-5G interworking Huawei: if no change how would MME find out that coming in UE is 5G capable? Ericsson: we do not yet need to agree to proposal 3 Orange: if SA2 is deciding to modify MME, then there is no problem for us to change but if they do not change, then we should follow SA3 chair: so you want to check with SA2? Orange: yes conclusion: proposal 1 and 3 not agreed; instead of proposal 1 the following was agreed: support for legacy MME is mandatory; instead of proposal 2 the following is agreed: "Native security context takes precedence over mapped security context in the UE"	noted	No		S3‑173170
		S3‑173346	Discussion on the security for interworking between EPC and 5GC	Ericsson	discussion	Approval	Yes	YesProposal 1: The security mechanisms for interworking shall minimize, if not possible to avoid, impact on 4G. Proposal 2: The security mechanisms for interworking shall maintain at least the same level of security compared to 4G. This does not overrule the introduction of improvements. Proposal 3: The security mechanisms for interworking shall not prevent the independent evolution of 5G security. Proposal 4: The system shall provide mechanisms to protect the confidentiality and the integrity protection of the transferred UE context data for interworking. Proposal 5: The system shall provide a mechanism to authenticate the trigger message before transfer of the UE context for interworking. Proposal 6: The system shall provide backward security from 5G to 4G. Proposal 7: The system shall provide integrity protection of the initial NAS message for idle mode mobility both from 5G to 4G and from 4G to 5G. Huawei: as we said MME shall not be changed, proposal 1 is not ok Nokia: proposal 2 is unclear Ericsson: it means: we have 4G security in 5G we may want more Vodafone: should proposal 4 not say "5G system"? Qualcomm: proposal 4 should clarify: transfer between core network nodes Qualcomm: is proposal 5 just for idle mode mobility (it makes no sense in other cases)? Ericsson: yes, most interesting in idle mode Nokia: not really sure what proposal 5 wants to say Qualcomm: proposal 7 is not related to interworking, we will do it anyway conclusions: proposal 1 not agreed; instead of proposal 2 only first part is agreed: "The security mechanisms for interworking shall maintain at least the same level of security compared to 4G."; proposal 3 is agreed; instead of proposal 4 it is agreed: The system shall provide mechanisms to protect the confidentiality and integrity of the UE context data when transferred between network nodes for interworking; proposal 5 needs further offline discussion; proposal 6 is agreed; proposal 7 is not agreed	revised	No	S3‑173457
		S3‑173457	Discussion on the security for interworking between EPC and 5GC	Ericsson	discussion	Approval	No	Yes	withdrawn	Yes		S3‑173346
		S3‑173304	Security handling for interworking between NextGen Core and EPC	Qualcomm Incorporated	discussion	Endorsement	Yes	YesProposal #1: To support 5GC to EPC mobility, AMF shall be able to derive a key from KAMF that would be used by the MME to create a security context. Proposal #2: AMF shall be able to derive a native EPS security context. Proposal #3: To support EPC to 5GC mobility, MME shall be able to derive a key from KAMSE which would be used create a security context at SEAF. Proposal #4: To support interworking with a legacy MME, AMF shall be able to create a 5G security context using the EPS security context received from MME. Furthermore, AMF shall be able to set a key usage information (e.g., native or mapped) to the 5G security context. Proposal #5: AMF shall be able to retrieve a native 5G security context if available. Nokia: proposals 1, 2 and 5 are ok for us conclusion: proposal 1 is agreed instead of proposal 2 it is agreed: AMF shall be able to retrieve a native 5G security context if available. proposal 3 is not agreed proposal 4 is agreed instead of proposal 5 it is agreed: AMF shall be use the native 5G security context if available.	noted	No		S3‑172385
		S3‑173073	Discussion paper on retaining security context in Interworking	Nokia	discussion	Approval	Yes	YesProposal 1: To support integrity protection of the idle mode moblity management (MM) message to the target network, the UE shall store the current security context (mapped or native) for the previously visited network for a limited period. Proposal 2: To support integrity check of the idle mode MM message, the source network shall store the security context for the UE for a limited period. Proposal 3: The target network shall verify the integrity of the idle mode MM message if it has the current security context for the UE. Proposal 4: If the target network successfully verified the integrity of the idle mode MM message, it shall not consider the mapped security context from the source network. In this case, the target network shall continue to use the stored current security context for the UE. Proposal 5: The target network shall use the existing parameter “MS validated” to indicate to the source network in the Context Request message that it has successfully validated the UE. The source network shall skip integrity check if “MS validated” is TRUE. Proposal 6: Send an LS to SA2, inform them of the above proposals – if agreed by SA3 – and ask them to add corresponding functionality to their specs, in particular for proposal 2. Ericsson, Huawei: we do not need proposals 1/2/3 Ericsson: for proposal 6 we have already an LS for this conclusion: proposals 1, 2, 3 are not agreed proposals 4, 5, 6 are agreed	noted	No
		S3‑173334	Skeleton proposal for clause 9 - Security of interworking	NEC EUROPE LTD	pCR	Approval	Yes	YesEricsson: should we not do Ericsson's restructuring first? conclusion: NEC's input can be addressed under Ericsson's restructuring in S3-173392	merged	No
		S3‑173233	Interworking with EPC without N26 interface	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: has a lot of text from SA2 text, so not supporting to include this part in the SA3 spec SA3 chair:yes, we need avoid duplication	postponed	No
		S3‑173347	Proposal for a new subclause 9.X on the registration mode and the applicability of the security mechanisms for interworking between 4G and 5G	Ericsson	pCR	Approval	Yes	YesNokia: prefers S3-173347 over S3-173233	revised	No	S3‑173466
		S3‑173466	Proposal for a new subclause 9.X on the registration mode and the applicability of the security mechanisms for interworking between 4G and 5G	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑173347
		S3‑173305	pCR to provide a general text for interworking between 5GC and EPC	Qualcomm Incorporated	pCR	Approval	Yes	Yesconclusion: section 9.1 will be merged into S3-173466	merged	No		S3‑172386
		S3‑173075	Integrity protection of idle mobility message during Interworking	Nokia	discussion	Approval	Yes	Yes	not treated	No
		S3‑173074	Discussion paper on Interworking with a legacy MME	Nokia	discussion	Approval	Yes	Yes	not treated	No
		S3‑173172	handover procedures between 5GC and EPC with N26	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173078	Handover from 4G to 5G	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173079	Handover from 5G to 4G	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173337	Handover procedure from EPS to 5GS	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑173335	Handover procedure from 5GS to EPS	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑173379	Proposal for a new subclause 9.Z.X on interworking security in handover from 4G to 5G	Ericsson LM	pCR	Approval	Yes	Yes	not treated	No
		S3‑173380	Proposal for a new subclause 9.Z.X on interworking security in handover from 5G to 4G	Ericsson LM	pCR	Approval	Yes	Yes	not treated	No
		S3‑173171	Idle mode mobility between EPC and 5GC with N26	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173076	Idle mode mobility from 4G to 5G	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173077	Idle mode mobility from 5G to 4G	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173350	Proposal for a new subclause 9.Y.X on interworking security in idle mode from 4G to 5G	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173351	Proposal for a new subclause 9.Y.X on interworking security in idle mode from 5G to 4G	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173348	Proposal for a new subclause 9.X on mapping of security contexts during interworking between 4G and 5G	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173349	Draft reply LS to S2-178210 = S3-173030 on security handling for EPC-5GC interworking (to: SA2; cc: -; contact: Ericsson)	Ericsson	LS out	Approval	Yes	YesMCC: source is already SA3	revised	No	S3‑173508
		S3‑173508	Reply LS to S2-178210 = S3-173030 on security handling for EPC-5GC interworking (to: SA2; cc: -; contact: Nokia)	SA3	LS out	Approval	Yes	YesEricsson: worried about overhead where you have trust in 4G system LS was sent out on Thu evening of SA3 #89	approved	No		S3‑173349
		S3‑173048	Security for idle mobility between 4G and 5G	ZTE Corporation	discussion	Approval	Yes	Yes	not treated	No
		S3‑173521	Agreements on interworking	Nokia	discussion	discussion	Yes	Yes	endorsed	No
7.2.11	Non-3gpp access	S3‑173182	multiple NAS keys at AMF when UE connectes to the AMF belonging to different Operators	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173183	signal NAS keys at AMF when UE connects to the AMF belonging to the same Operaotr	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173192	Add a new requirement in scenario when UE has multiple registration in different PLMNs	Huawei, Hisilicon, China Unicom	pCR	Approval	Yes	Yesnot treated after S3-173330	not treated	No
		S3‑173251	Authentication for Untrusted Non-3GPP Access using EAP	Motorola Mobility, Lenovo, LG Electronics, Nokia, KPN, Broadcom, Brocade	pCR	Approval	Yes	Yes	not treated	No
7.2.12	NDS	S3‑173046	Protecting sensitive information transmitted between operators - reference point presentation	ZTE Corporation, China Unicom	pCR	Approval	Yes	Yes	not treated	No		S3‑172203
		S3‑173206	Add Management Plane Protection	Huawei; Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173207	Add management reference to gNB setup and configuration	Huawei; Hisilicon	pCR	Approval	Yes	Yes	not treated	No
7.2.13	Service based architecture	S3‑173246	Security requirements for service based architecture	Neul Limited	pCR	Approval	No	Yes	revised	No	S3‑173255
		S3‑173250	Authentication in the service registration procedure	Neul Limited	pCR	Approval	No	Yes	revised	No	S3‑173256
		S3‑173253	Authorization of NF service discovery	Neul Limited	pCR	Approval	No	Yes	revised	No	S3‑173258
		S3‑173258	Authorization of NF service discovery	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No		S3‑173253
		S3‑173255	Security requirements for service based architecture	Huawei, Hisilicon	pCR	Approval	Yes	YesDeutsche Telekom: has a problem with the language used here, "should" means no guarantee, we need "shall" Intel: has related Tdocs in S3-173209 and S3-173210 conclusion: authorization aspect will be merged into S3-173483	merged	No		S3‑173246
		S3‑173209	Security requirements for Service Based Architecture Discovery	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yesconclusion: title will be changed, shall support, authorization will be added (merged with Huawei text)	merged	No
		S3‑173210	Security requirements for Service Based Architectur Registration	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesDeutsche Telekom: authorization request should be added conclusion: title will be changed, shall support, authorization will be added (merged with Huawei text)	revised	No	S3‑173483
		S3‑173483	Security requirements for Service Based Architectur Registration	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yeswill include aspects of S3-173255 and S3-173209	approved	No		S3‑173210
		S3‑173153	Adding KI of Service authorization to living doc	Huawei & Hisilicon	pCR	Approval	Yes	Yesconclusion: will be added into living Tdoc S3-173484	endorsed	No
		S3‑173484	Living document for service based architecture	Nokia	discussion	discussion	Yes	Yesincludes also aspects of S3-173486, S3-173490	endorsed	No
		S3‑173208	NRF Requirements	Huawei; Hisilicon	pCR	Approval	Yes	YesEricsson: first requirement is unclear NTT DOCOMO: not shared conclusion: req. 1 will be split into 2 (rest of req. 1 will be removed), req. 2 and editor's notes at the end will be removed; "NRF shall" will be integrated in requirements; req.3 will be removed	revised	No	S3‑173485
		S3‑173485	NRF Requirements	Huawei; Hisilicon	pCR	Approval	Yes	YesDeutsche Telekom raised concerns about the word „may“ in the second NRF requirement, citing the agreed SBA security goal goal #4.	approved	No		S3‑173208
		S3‑173220	Security for Service Based Interconnect interfaces	Nokia, Deutsche Telecom	discussion	Approval	Yes	YesProposal 1: Add in the 5G architecture a network element at the edge of the service provder network that allows for interconnect security to be implemented, in addition to other security policies such topology hiding etc. Proposal 2: Implement e2e application layer security in the network element at the edge of the network. Proposal 3: Add in the 5G architecture the possibility for active intermediate security end-nodes that may manipulate application layer information as it traverses through it. Proposal 4: Delegation of e2e application layer security to another service provider must be allowed in 5G Proposal 5: Delegation of e2e application layer security to roaming hubs must be allowed in 5G. Proposal 6: Take FS.19 – Diameter Interconnect Security, as the basis to identify Information elements (IEs) that need e2e protection in 5G SBA Proposal 7: Map identified IEs into one of the protection categories identified in clause 4.1.5 above. NTT DOCOMO: Ericsson is against security at edge proxy? Ericsson: no, but not all Ericsson: for proposals 4 & 5 we need an extra discussion document conclusion: proposal 1 is agreed, instead of proposal 2 it is agreed: Consider implementation of application layer security in SEPP proposal 3 is agreed (end has to be removed), proposals 4 and 5 not agreed proposals 6 and 7 agreed	revised	No	S3‑173486
		S3‑173486	Security for Service Based Interconnect interfaces	Nokia, Deutsche Telecom	discussion	Approval	Yes	Yesconclusion: will be included into living Tdoc S3-173484	endorsed	No		S3‑173220
		S3‑173221	Security architecture for Service Based Interconnect Interfaces	Nokia, Deutsche Telecom	discussion	Approval	Yes	YesEricsson: we have LS we sent to SA2 on Wed	noted	No
		S3‑173222	pCR on Requirement for e2e core network interconnection security	Nokia, Deutsche Telecom	pCR	Approval	Yes	YesDeutsche Telekom: it's not a proxy function but just a proxy conclusion: "function" in "proxy function" will be removed	revised	No	S3‑173487
		S3‑173487	pCR on Requirement for e2e core network interconnection security	Nokia, Deutsche Telecom	pCR	Approval	Yes	Yes	approved	No		S3‑173222
		S3‑173261	Protection of the communication between NFs	Huawei, Hisilicon	pCR	Approval	Yes	YesDeutsche Telekom, Orange: do not accept this proposal	rejected	No
		S3‑173047	Protecting sensitive information transmitted between operators - SBA	ZTE Corporation, China Unicom	pCR	Approval	Yes	YesEricsson: visited network is never authenticated Deutsche Telekom: per user basis is not acceptable to us	rejected	No
		S3‑173314	Discussion on adopting GSMA recommendations for IPX Security.	KPN	discussion	Endorsement	Yes	Yesproposals: • SA3 agrees to adopt the integrity protection mechanism proposed by GSMA; • SA3 agrees to adopt the confidentiality protection mechanism proposed by the GSMA; • SA3 agrees to the overall structure of the messages with a message-content part and a signature part as proposed in the GSMA document; • SA3 agrees to use the mechanisms in either [2] or [3] for the encrypted containers and the signature-part of the messages. KPN: proposals are for email discussion	noted	No
		S3‑173223	Application layer security based on JOSE framework	Nokia, Deutsche Telecom	discussion	Approval	Yes	Yes	noted	No
		S3‑173224	pCR on Application layer security	Nokia, Deutsche Telecom	pCR	Approval	Yes	YesNTT DOCOMO: you must explain what is the basis of the pCR; suggests and editor's note (regarding CT4 and 2 parallel https)	revised	No	S3‑173490
		S3‑173490	pCR on Application layer security	Nokia, Deutsche Telecom	pCR	Approval	Yes	Yesconclusion: merged into S3-173484	merged	No		S3‑173224
		S3‑173154	Merge two procedures of SBA authorization	Huawei, Hisilicon, InterDigital	pCR	Approval	Yes	Yes	not treated	No
		S3‑173259	Authorization of NF service access	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173225	OAuth 2.0 based service authorization for SBA	Nokia	discussion	Decision	Yes	Yes	not treated	No
		S3‑173226	pCR on OAuth based service authorization for SBA	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173257	Discussion and pCR about NF authentication for SBA	China Mobile	other		Yes	Yes	not treated	No
		S3‑173376	Including authentication into authorization aspects	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173377	Add section for authentication between network functions	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑173256	Authentication in the service registration procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No		S3‑173250
		S3‑173526	[Draft] LS on security across inter-operator interconnect (to: CT4; cc: -; contact: Deutsche Telekom)	Deutsche Telekom, NTT DOCOMO	LS out	Approval	Yes	Yes	revised	No	S3‑173527
		S3‑173527	LS on security across inter-operator interconnect (to: CT4; cc: -; contact: Deutsche Telekom)	SA3	LS out	Approval	Yes	Yes	approved	No		S3‑173526
7.2.14	Privacy (not covered by other headings)	S3‑173070	Solution for meeting LI and privacy requirements	CATT	pCR	Approval	Yes	YesOrange: can we treat all proposals together SA3 chair: ok, so after S3-173070 also S3-173098, S3-173124, S3-173138, S3-173398 will be presented	postponed	No
		S3‑173098	Clauses 6.1.3 and 6.7.2 (auth procedures and NAS SMC, SUPI from UE for LI)	Ericsson	pCR	Approval	Yes	Yes	postponed	No
		S3‑173124	LI conformity when privacy is used - was 2506	Nokia, Orange	pCR	Approval	Yes	YesOrange if mismatch between what UE and core network is sending, then our proposal is handling this at an early stage NTT DOCOMO: not clear how random R is passed around	postponed	No
		S3‑173138	Meeting SUPI privacy and LI Requirements	Huawei, Hisilicon, Intel	pCR	Approval	Yes	Yes	postponed	No
		S3‑173398	pCR to 33.501 6.1.3.1, 6.1.3.2, Annex A – SUPI assurance in SEAF	DOCOMO Communications Lab.	pCR	Approval	Yes	YesT-Mobile: supports Nokia proposal, NTT DOCOMO proposal can be attacked KPN: after discussion with regulators: IMSI needs to be got first Vodafone: LI can be done after authentication without problems SA3 LI chair: we discussed in LI group: do we trust anything before authentication is completed? the answer is no; timing: only relevant for first authentication so not a big issue; if encryption is off there is no need to transfer IMSI (no need to support the extras in this) NTT DOCOMO: SUPI will be public and could be misused Qualcomm: agrees with NTT to send NAS security mode complete; has preference to binding to some key; privacy is maintained and controled by home operator Ericsson: what happens if SUPI is send wrongly? Huawei: we heard from SA3 LI that all operator have NAS security enabled Nokia: we are worried how NAS is handled and so in our proposal we avoid sending the SUPI SA3 LI chair: no requirement for sending SUPI over unencrypted that why we assume encryption; proving that a SUPI was received (for court cases) would make a difference in the proposals; Vodafone: our S3-173272 belongs to this set as well SA3 chair: so please present S3-173272	postponed	No
		S3‑173272	Discussion on provision of SUPI from home to visited network	VODAFONE Group Plc	discussion	Discussion	Yes	YesOrange: worries that we mix now 2 topics KPN: would support variant 1 Orange: it seems we have 3 proposals supi in NAS SMC (Ericsson/Huawei ...) , hash function (Nokia ...) and binding keys (NTT DOCOMO), can we have a show of hands NTT DOCOMO: still unclear how Nokia proposal works SA3 LI: operator cannot select their own hash algorithm? show of hands: NAS/IMSI complete: ZTE, home office, NCSC, MTECH, BT, Ericsson, Intel, CMCC, CATT, KPN, Samsung, Huawei => 12 hash based: Minsiter eco, Oberthur, Nokia, T-Mobile, Orange, Gemalto => 6 binding: DOCOMO, LG, Qualcomm =>3 NTT DOCOMO: first proposal must make sure that SUPI is never sent unencrypted SA3 LI chair: IMEI more imprtant than IMSI Orange: heard the opposite SA3 LI chair: both are needed but IMEI allows to do things you cannot do with IMSI Huawei: if NAS encryption could be turned off, we need to find a solution T-Mobile: NAS encryption can be turned off Orange: yes, this is part of our spec that optionally NAS encryption can be switched off; so we cannot make at another part of the spec the assumption that it is encrypted Orange: we could think about a vote and/or check the SA3 LI view NTT DOCOMO: a way where we do not send SUPI in the clear would be acceptable for us (then we would drop our binding proposal) SA3 LI chair: response from SA3 LI could only be accepted by March 18	noted	No		S3‑172225
		S3‑173099	Clause 6.8.3 (5G-GUTI refresh at periodic registration update)	Ericsson, Telecom Italia	pCR	Approval	Yes	Yes	approved	No
		S3‑173100	Clause 6.8.3 (5G-GUTI refresh at network triggered service request)	Ericsson, Telecom Italia	pCR	Approval	Yes	Yes	approved	No
		S3‑173114	Privacy requirements on the UE - was 2509	Nokia	pCR	Approval	Yes	YesVodafone: does not support the proposal, proposal would need to standardize algorithms Orange: should say "The UE" not "A UE"	revised	No	S3‑173435
		S3‑173435	Privacy requirements on the UE - was 2509	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑173114
		S3‑173278	pCR- Updating 5.1.5 Subscriber privacy	China Mobile	pCR	Approval	Yes	YesOrange: compromise: The calculation of SUCI shall be done in ME and USIM (and USIM takes precedence). BT: precedence may not be good if this is the weaker implementation Nokia: what about precedence by operator policy? Orange: mandatory in ME, possible in USIM and if in USIM we need to define a precedence Oberthur: wrong and unfair analysis provided in rational by China Mobile: - the ECDH computation delay on M0 was assumed without any optimization enabled however when optimization is enabled performance gain is significant as shown in the referenced paper on performance investigations. - not true that the network will reject the UE after 6s but instead after 30s as the timer of 6s is repeated 5 times before the procedure is aborted.	revised	No	S3‑173436
		S3‑173436	pCR- Updating 5.1.5 Subscriber privacy	Orange, Gemalto, Oberthur Technologies, Morpho, CATT, KPN, Vodafone, Deutsche Telekom AG	pCR	Approval	Yes	Yes	approved	No		S3‑173278
		S3‑173306	pCR: Calculation of SUCI	Qualcomm Incorporated	pCR	Approval	Yes	Yes	withdrawn	Yes		S3‑172503
		S3‑173384	5G privacy: SUCI calculation	Gemalto, G&D, Morpho, Oberthur, Vodafone	pCR	Approval	Yes	Yesconclusion: merged into S3-173436	merged	No
		S3‑173230	Discussion on the use of home network public key	LG Electronics	discussion	Endorsement	Yes	Yes	noted	No
		S3‑173231	Inputs of SUCI construction in annex C	LG Electronics	pCR	Approval	Yes	YesGemalto: overlap with Ericsson contribution? Ericsson: extra separator on input here in this proposal NT DOCOMO: fixed string not useful	rejected	No
		S3‑173069	Remove editor note related to SIDF location	CATT	pCR	Approval	Yes	Yesconclusion: will be merged into S3-173446	merged	No
		S3‑173229	SIDF location clarification in subclause 6.1.2	LG Electronics	pCR	Approval	Yes	Yesconclusion: will be merged into S3-173446	merged	No
		S3‑173117	SIDF purpose in initiation of authentication - 2355	Nokia	pCR	Approval	Yes	YesHuawei: do we need to indicate which protection scheme was used?	revised	No	S3‑173446
		S3‑173446	SIDF purpose in initiation of authentication - 2355	Nokia, LG, CATT	pCR	Approval	Yes	Yes	approved	No		S3‑173117
		S3‑173118	SIDF functionality - was 2356	Nokia	pCR	Approval	Yes	YesInterdigital: unclear why to standardize because it is a deployment issue whether co-location KPN: authentication center is normally the place, you would not like to put it anywhere in the cloud Ericsson: we do not need editor's note Interdigital, Ericsson: we are fine with UDM SA3 chair: what about the proposed changes? Ericsson: "Functionality" would be a new term, normally we talk about function Nokia: SA2 is using "function" in a different way than SA3 Huawei: editor's note should not be in definitions Orange: has problem with note 2 unde 6.8.x SA3 chair: we had several comments to 6.8x and even the question whether this clause is needed at all conclusion: - first definition: use "Function" instead of Functionality, use "This service" instead of "This functionality" - 2nd definition: first part kept until e.g., MSIN), rest will be removed - editors' note under definitions will be removed - change in abbreviations will be cancelled	revised	No	S3‑173447
		S3‑173447	SIDF functionality - was 2356	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑173118
		S3‑173102	Annex C.3 (SUCI, ECIES scheme normative Annex)	Ericsson	pCR	Approval	Yes	YesBT: do we have these profile names like top secret ?	revised	No	S3‑173450
		S3‑173450	Annex C.3 (SUCI, ECIES scheme normative Annex)	Ericsson	pCR	Approval	Yes	YesVodafone: editor's notes should not be used as blocking technique	approved	No		S3‑173102
		S3‑173260	pCR to 33.501 - SUPI Encryption Protocol: issues identified by ETSI SAGE	VODAFONE Group Plc	pCR	Approval	Yes	YesVodafone: we defined 6 curves while Ericsson defined 2, this is the main difference; advantage: people can at least find 2 curves that they are happy with; suggests to merge part with the curves in the Ericsson Tdoc? Qualcomm: we could not have so many curves Orange: would not agree to only NIST curves, so supporting Vodafone conclusion: curve list will be taken over into S3-173450, other parts can be discussed until next SA3 meeting	merged	No
		S3‑173065	Privacy requirement about who define SUPI protection schemes	CATT	pCR	Approval	Yes	YesVodafone: we do not support, it's up to the home operator to design so we want the opposite (MME and user are different); also wondering whether you can restrict SA3 chair: anyone supporting this Tdoc? seems there is no support	rejected	No
		S3‑173066	Remove editor note about choosing null-scheme	CATT	pCR	Approval	Yes	YesEricsson: fine with the Tdoc except first change Vodafone: it's assuming a solution of public key, you might not have public key because you do SUPI calculation in USIM BT: any validity for public key? SA3 chair: seems this can not be agreed	rejected	No
		S3‑173068	Remove editor note about visited network require null-scheme	CATT	pCR	Approval	Yes	YesEricsson: there are more Tdocs on the scheme (S3-173101, S3-173139, S3-173119)	rejected	No
		S3‑173101	Clauses 5.1.5/6.8.1 and Annex C.2 (SUCI - selection of null-scheme)	Ericsson	pCR	Approval	Yes	YesSA3 chair: discuss this further offline and see whether some editor's notes can be removed conclusion: merged into S3-173453	merged	No
		S3‑173139	Subscriber Privacy under Home network control	Huawei, Hisilicon	pCR	Approval	Yes	YesNTT DOCOMO: first 2 requirements of 6.8.2 could be kept BT: 2nd one could be changed SA3 chair: can discuss further offline	revised	No	S3‑173453
		S3‑173453	Subscriber Privacy under Home network control	Huawei, Hisilicon, Ericsson, CATT	pCR	Approval	Yes	Yes	approved	No		S3‑173139
		S3‑173119	Discussion paper on null-scheme SUCI request by VN	Nokia	pCR	Approval	Yes	YesNTT DOCOMO: before we implement the feature we need to figure out which countries would really have a problem BT: is it about countries or is there a finer granularity NCSC: we will not be able to ask all countries' regulators Ericsson: if a country does not allow it, they can handover to 4G NTT DOCOMO: home control on visited network could be retrofit in newer UEs later SA3 chair: we have higher priority topics and this topic seems to need more discussion	rejected	No
		S3‑173115	Requirement on AMF - was 2354	Nokia	pCR	Approval	Yes	Yes	rejected	No
		S3‑173311	Procedure for mandating null-scheme SUCI	KPN, Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173310	Adding Null scheme mandatory messages	KPN, Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173174	Adding the content on Subscription identification procedure(6.8.4)	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑173123	Resolving editors note on null-SUCI or SUPI for emergency call handling -v1.doc	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173140	Moving UE handling SUCI to SUCI clause	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑173116	SUCI introductionary text merging 6.8.1 and 6.8.2 - merge 2362 and 2354	Nokia, KPN	pCR	Approval	Yes	Yes	not treated	No
		S3‑173121	UDM requirements - key management and privacy - was 2358	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173120	Privacy related functions in UDM	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173122	Privacy data UDR - split from 2356	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑173067	Remove editor note about how to connect to 5G network	CATT	pCR	Approval	Yes	Yes	not treated	No
		S3‑173071	Solution for raw public key provisioning	CATT	pCR	Approval	Yes	Yes	not treated	No
7.2.15	Others	S3‑173029	Reply LS on applicability of service based interface for legacy core network elements	S2-178205	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173007	LS on secure storage and processing of subscription credentials	S1-173475	LS in		Yes	YesLS was seen in the previous ad hoc, we will come back to it later this week conclusion: LS answer iss postponed	postponed	No
		S3‑173008	Update on the status of the work on SSP (Smart Secure Platform)	ETSI TC SCP	LS in		Yes	YesVodafone: LS is out-of-date, we need the latest status conclusion: no LS answer	noted	No
		S3‑173009	NGMN Paper on 5G End-to-end Architecture Framework	NGMN	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173013	Reply LS on PLMN and RAT selection policies for roaming	C1-174589	LS in		Yes	YesVodafone: they ignored a part of our LS; is creating a secure channel to MME which is not secure BT: also undear which system is considered Deutsche Telekom: supports Vodafone SA3 chair: so we need to send them an answer that we do not want this as this is wrong; do we have a related discussion Tdoc or LS reply? Orange: we clarified that their previous LS was not clear and as answer they just send us references to these Tdocs Samsung: if they come with the solution then we need to secure it Ericsson: suggests to wait a bit with our LS answer Orange: first question was not answered, so we need to send a reply LS to ask for clarification on 2 points Huawei: we could wait a bit with the answer KPN: we have not yet seen requirements from SA1 (answer to S2-175286) Orange: we need to avoid that CT1 starts to work with wrong assumptions Qualcomm: acc. to the WI code, CT1 is working here on 5G phase 1 conclusion: SA3 chair: we will come back later this week on this after offline discussion: Orange: will write an LS answer (termination in the UE, why OTS does not work, no SA3 agreement to agree this for REL-15), create a living document	replied to	No
		S3‑173426	Reply LS to C1-174589 = S3-173013 on PLMN and RAT selection policies for roaming (to: CT1; cc: CT6, SA3-LI, SA2, CT3; contact: Orange)	SA3	LS out	Approval	Yes	YesLS was sent out on Thu afternoon of SA3 #89	approved	No
		S3‑173509	Reply LS to C1-174589 = S3-173013 on PLMN and RAT selection policies for roaming (C4-176362; to: CT1, SA3; cc: CT3, SA2; contact: Huawei)	CT4	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173515	Reply LS to C1-174589 = S3-173013 on PLMN and RAT selection policies for roaming (C3-176332; to: CT1; cc: SA2, SA3, CT4; contact: Huawei)	CT3	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173235	Discussion paper for steering of roaming	Huawei, Hisilicon	discussion	Discussion	Yes	Yesproposal: to choose one of the two solutions as baseline to provide end to end security for the delivery of the list of PLMN/access technology combinations, and approve the corresponding companion pCR (S3-173236/S3-173237) Vodafone: this is the 3rd meeting where we see that they based the document on the same mistake Orange: does not agree on observation 2 and 3 Qualcomm: we had papers in the past supporting go in the direction of solution 2 (using K_AUSF) Vodafone: we should have a study on this Gemalto: does not support solution 2, MME or UICC needs to be discussed first	noted	No
		S3‑173427	PLMN and RAT selection policies for roaming	Orange	discussion	discussion	Yes	Yesendorsed skeleton for the living document Vodafone: concerned about having too many living documents (difficult to trace) MCC: you could have a TR under the 5G WI (revised WI) and use this to store topics of related living documents SA3 chair: let's keep living document for the moment and think about the possibility to create a TR	revised	No	S3‑173482
		S3‑173482	Living document on PLMN and RAT selection policies for roaming	Orange	discussion	Endorsement	Yes	Yeswill include agreements of SA3 #89 in a lving document	endorsed	No		S3‑173427
		S3‑173309	Security for Network Steering of UE in 5GS	Qualcomm Incorporated	pCR	Approval	Yes	Yesproposals: 1) Agree to the following proposals 1 to 3 as the SA3 working assumption for securing the network steering information. Proposal #1: Key(s) derived from KAUSF shall be used to protect the network steering information. Proposal #2: Security procedures required at the AUSF to support steering of the UE using the control plane solution after the UE has registered shall be optional for implementation. Proposal #3: The NAS message that carries the steering information shall always include the integrity protected steering information. 2) Approve the below pCR to draft TS 33.501. Vodafone: pCR does not say that this is an addition to what exists already Qualcomm: we could a sentence about this BT: proposal seems to assume 5G as basis so this will not work on 2G/3G etc. Qualcomm: yes, the proposal is just for 5G Vodafone: we can do all this already Qualcomm: using NAS message is new Orange: Vodafone means you need to replace UE by MME; but we do not agree to such a change Qualcomm: we tried to keep it generic Orange: 2nd paragraph of pCR should be removed ("The Ntwork ...") Vodafone: last sentence is not future proof Nokia: has a proposal to rephrase last sentence and proposal 2 is not reflected in pCR Qualcomm: CT1 is looking at solution where update can happen at any time NTT DOCOMO: section 5 is requirement section and not section 6 SA3 chair: we got the information that other groups have not yet developed specs on this Orange: happy to add text in requirements section Ericsson: CT1 has only TR Qualcomm: all agreements that we go in TS are currently in a TR Oberthur: CT is still working on a SI, WI will come in Dec.17 SA3 chair: further offline discussion needed (should we work on this at all?, CT1 work going to spec?, how to document SA3 work?)	revised	No	S3‑173428
		S3‑173428	Security for Network Steering of UE in 5GS	Qualcomm Incorporated	pCR	Approval	Yes	Yesconclusion: merged into living Tdoc S3-173482	merged	No		S3‑173309
		S3‑173236	Protecting network selection list by UDM&ARPF	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: USIM does not keep IK CK KPN: does not want to see a solution that influences authentication SA3 chair: so this is related to solution1 of S3-173235	rejected	No
		S3‑173237	Protecting network selection list by AUSF	Huawei, Hisilicon	pCR	Approval	Yes	YesSA3 chair: so this is related to solution2 of S3-173235 Vodafone: up to VPLMN when to do the authentication	rejected	No
		S3‑173022	LS on usage of user plane integrity protection for DRB	R2-1712051	LS in		Yes	YesDeutsche Telekom: why would integrity protection be a big problem? Qualcomm: due to the way their interface is working Huawei: was a performance issue (not limited to IOT) Nokia: we need to send an LS answer NTT DOCOMO: we must indicate that we need integrity protection, at what level can be discussed further SA3 chair: so we need to indicate that we need integrity protection and the solution has to be found Qualcomm: we have a reply proposal in SA2 Nokia: SA3 has an action here, and we should not limit it to low rate NTT: for all use cases we need to support integrity protection	replied to	No
		S3‑173420	Reply LS to R2-1712051 = S3-173022 and R2-1714125 = S3-173470 on maximum data rate of user plane integrity protected data (to: RAN2; cc: SA2, RAN3; contact: Qualcomm)	SA3	LS out	Approval	Yes	YesDeutsche Telekom: we will need IPSec on CU-DU anyway Ericsson: UP integrity is currently optional, the core network can decide whether to use it LS was sent out on Thu afternoon of SA3 #89 (note: wrong Tdoc number on the Tdoc)	approved	No
		S3‑173470	LS on maximum data rate of user plane integrity protected data (R2-1714125; to: SA3; cc: SA2; contact: Qualcomm)	RAN2	LS in		Yes	YesQualcomm: could reply to this also in S3-173420 (which is a reply to LSin S3-173022) NTT DOCOMO: also use case need to be taken into account Nokia: first agreement: interprets it as minimum 64kbps are offered Ericsson: this is UE side Qualcomm: UE will make an indication and network will make decision on UP integrity SA3 chair: it seems the LS is not clear KPN: seems it is the lowest maximum data rate up to which UP integrity is supported Qualcomm (RAN2): RAN2 will introduce a maximum value, once a new use case is coming up we can bring CRs to RAN2 to allow UP integrity up to a higher data rate NTT DOCOMO: why is this not aligned with QCI values? Qualcomm (RAN2): is a hardware related requirement and granularity is not enough Nokia: we should ask whether/how is the mechanism to increase the data rate that limits UP integrity protection conclusion:: further offline discussion needed	replied to	No
		S3‑173024	LS reply on Support for fake gNB detection mechanisms	R4-1711318	LS in		Yes	YesNokia: LS says this is not for REL-15 but there is a pCR related to REL-15? conclusion: no LS answer	noted	No
		S3‑173030	LS on security handling for EPC-5GC interworking	S2-178210	LS in		Yes	Yesthere is a draft reply LS to S3-173030 in S3-173349	replied to	No
		S3‑173040	Reply LS from 802.11 to NGMN LS on E2E Architectural Framework	IEEE 802.11	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173406	128-EIA3 for jumbo frames	ETSI SAGE	LS in		Yes	YesVodafone: originally RAN2 asked about usage of jumbo frames and it seems we could reply now that everything is fine Ericsson: we indicated already that this is ok SA3 chair: so then we do not need to send another one to RAN2 conclusion: no LS answer to ETSI SAGE	noted	No
		S3‑173041	Liaison Statement on 5G Identity and Access Management Requirements	NGMN	LS in		Yes	YesKPN: was discussed in SA1 NTT DOCOMO: Why is NGMN sending us GSMA LSs? SA3 chair: is the same S3-173409, we will come to this one later conclusion: see S3-173430 instead	withdrawn	Yes
		S3‑173409	Liaison Statement on 5G Identity and Access Management Requirements	GSMA	LS in		Yes	Yessee S3-173430 instead	withdrawn	Yes
		S3‑173430	Liaison Statement on 5G Identity and Access Management Requirements	GSMA	LS in		Yes	YesOrange: is this for phase 2? GSMA: SA1 SI will finish by end of REL-16 Orange: is it linked to IMSI? GSMA: has to be linked with subscription Orange: moving of credentials between devices? GSMA: we will leave this to the experts to see what is achievable NTT DOCOMO: is a nice wish list but not realistic to have it by the end of next year BT: would have impact on privacy work conclusion: no LS answer to GSMA	noted	No
		S3‑173407	Liaison Statement reply to 3GPP S3-172175: DESS Update and Requirements for Securing Inter-PLMN Signalling Interfaces in 5G	GSMA	LS in		Yes	YesEricsson: it seems GSMA wants to have everything they have in 4G without checking impacts KPN: there should be a mechanism to protect fields SA3 chair: do we need to reply to it? KPN: we can also respond when we have done it; there are related papers from Nokia and Deutsche Telekom NTT DOCOMO: we should not break existing business models	replied to	No
		S3‑173433	Reply LS to DESS 11_02 = S3-173407 on DESS Update and Requirements for Securing Inter-PLMN Signalling Interfaces in 5G (to: GSMA FASG DESS; cc: -; contact: KPN)	SA3	LS out	Approval	Yes	Yes	approved	No
		S3‑173050	LS on LI relation to TS 33.501	S3i170462	LS in		Yes	Yesproposal: To be included in TS 33.501 section 5.8: "The security and privacy features specified in the present document shall not preclude or inhibit the operation of LI as specified in TS 33.126." KPN: has a problem with this as it is not possible to see whether requirement is met Vodafone: should be written in positive way SA3 LI chair: formulating it in a positive way would mean to check the 33.501 features KPN: "subject to national regulations" would be acceptable for us SA3 LI chair: not all LI and all privacy requirements can be met at the same time NTT DOCOMO: "up to national regulations" could be added in a similar way as for encryption BT: LI specs were one REL behind, do we get a problem with this? SA3 LI chair: 33.126 is written in a service agnostic way so does not see a problem conclusion: BT will draft a pCR to TS 33.501 in S3-173429, BT will draft an LS reply in S3-173512	replied to	No
		S3‑173512	Reply to: LI relation to TS 33.501 (to: SA3 LI; cc: -; contact: BT)	SA3	LS out	Approval	Yes	Yesconclusion: source field still shows company name, therefore revised	revised	No	S3‑173531
		S3‑173531	Reply to S3i170462 = S3-173050 on LI relation to TS 33.501 (to: SA3 LI; cc: -; contact: BT)	SA3	LS out	Approval	Yes	Yes	approved	No		S3‑173512
		S3‑173429	LI requirement	BT	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173392	Proposals to restructure TS 33.501	Ericsson	discussion		Yes	YesNokia: there is some overlap in clause 6 and 8 NEC: would not like to have the changes NTT DOCOMO: we should get rid of the overlap, but some reasons why the overall structure was done as it is SA3 chair: would like to take a restructuring discussion offline to see how this can be done	revised	No	S3‑173528
		S3‑173528	Proposals to restructure TS 33.501	Ericsson	discussion	-	Yes	Yesconclusion: endorsed unseen	endorsed	No		S3‑173392
7.3	Mission Critical Security Enhancements (eMCSec) (Rel-15)	S3‑173032	LS on signalling plane security for MC system interconnection	S6-171458	LS in		Yes	Yes	replied to	No
		S3‑173432	Reply LS to S6-171458 = S3-173032 on signalling plane security for MC system interconnection (to: SA6; cc: -; contact: Motorola Solutions)	SA3	LS out	Approval	Yes	YesNCSC: some filtering may be needed	approved	No
		S3‑173033	LS on providing SIP identities to access a partner MC system	S6-171490	LS in		Yes	Yes	replied to	No
		S3‑173411	Reply LS to S6-171490 = S3-173033 on LS on providing SIP identities to access a partner MC system (SCP(17)000190; to: SA6; cc: SA3, CT6, SA1; contact: Orange)	ETSI TC SCP	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173452	Reply LS to S6-171490 = S3-173033 on providing SIP identities to access a partner MC system (to: SA6; cc: SA3, ETSI SCP, CT6; contact: Blackberry)	SA1	LS in		Yes	Yesconclusion: no LS answer to SA1	noted	No
		S3‑173468	Reply LS to S6-171490 = S3-173033 on providing SIP identities to access a partner MC system (C6-170676; to: SA6; cc: SA3, ETSI SCP, SA1; contact: Blackberry)	CT6	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173434	Reply to S6-171490 = S3-173033 on providing SIP identities to access a partner MC system (to: SA6; cc: SA1; contact: NCSC)	SA3	LS out	Approval	Yes	YesOrange: having multiple ISIMs may be problematic and 5. will need some rewording; SA3 chair: it may be good to discuss this draft LS first offline Motorola Solutions: some numbering needs to fixed Oberthur: SA1 and CT4 action needed Orange: no they replied already	approved	No
		S3‑173282	[eMCSEC] Addition of Element for Authenticating Requests (EAR) to TS 33.180.	NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑173448
		S3‑173448	[eMCSEC] Addition of Element for Authenticating Requests (EAR) to TS 33.180.	NCSC	CR	Agreement	Yes	YesNCSC: 4 group messages: some correction was needed compared previous revision NCSC: since S3-173287 is not yet accepted we still need to have some offline discussion on this Huawei: no boxes ticked? NCSC: it is just affecting application	agreed	No		S3‑173282
		S3‑173283	[eMCSEC] Addition of KMS Requests to TS 33.180 to support KMS Discovery	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑173390	[eMCSEC] Addition of Security Gateway to TS 33.180	NCSC	CR	Agreement	Yes	YesMCC: CR includes no change (all changes must be visible with rev marks!)	revised	No	S3‑173449
		S3‑173449	[eMCSEC] Addition of Security Gateway to TS 33.180	NCSC	CR	Agreement	Yes	YesNCSC: there are still some comments from Motorola Solutions to be solved	agreed	No		S3‑173390
		S3‑173456	Exception request sheet for REL-15 WI eMCSec stage 2	NCSC, Motorola Solutions	WI exception request	Agreement	Yes	Yesextension of 1 quarter needed as there are still SA6 parts open NCSC: intention is to report 80% to SA #78	agreed	No
		S3‑173352	Update of clause 6.6 on key hierarchy	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173353	Update of clause 6.7 on security contexts	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173354	Update of clause 6.3 skeleton on Security negotiation	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173355	Update for skeleton of clause 8 on Security Procedures between UE and 5G Access Network Functions	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173356	Update of clause 5 skeleton on Security Requirements and Features	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173357	Update of clause 8.1.1.2 ‘5G-RAN key identification‘ in TS 33.501	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173358	Update of clause 8.1.1.3 ‘5G-RAN key lifetimes‘ in TS 33.501	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
7.4	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑173031	Reply LS on LI Requirements for CIoT services including BEST services	S3i170239	LS in		Yes	YesVodafone: there are mutually exclusive requirements; we are turning off ciphering and integrity protection is not a problem KPN: we do not switch off encryption over the air conclusion: no LS answer and no action planned	noted	No
		S3‑173051	Collection of editorial changes to BEST TS 33.163	Juniper Networks	CR	Agreement	Yes	YesMCC: no CR number on CR cover Vodafone: NULL is missing an L Juniper: also a reference needs correction/addition	revised	No	S3‑173459
		S3‑173459	Collection of editorial changes to BEST TS 33.163	Juniper Networks	CR	Agreement	Yes	YesVodafone: we are still waiting for some CT4 work (confirmation on S6 interface needed), should we have an exception sheet and an LS? We need subset of S6a commands, with separate interface we would not have interaction	agreed	No		S3‑173051
		S3‑173460	Exception request sheet for WI BEST_MTC_Sec	Vodafone	WI exception request	Agreement	Yes	Yesprovided as target has to be extended Vodafone: CT4 will probably reply "S6a interface is fine" and so we will not need the exception sheet SA3 chair: will you do a CR for SA3 #89 then? Vodafone: editor's note could be removed but Annex will need until next meeting SA3 chair: ok, we can do both next time conclusion: Tdoc was agreed first and then after S3-173522 it was withdrawn	withdrawn	Yes
		S3‑173461	LS on extension of S6x interface for BEST (to: CT4; cc: -; contact: Vodafone)	SA3	LS out	Approval	Yes	YesLS was sent out on Thu afternoon of SA3 #89	approved	No
		S3‑173522	Reply LS to S3-173461 on extension of S6x interface for BEST (C4-176388; to: SA3; cc: -; contact: Vodafone)	CT4	LS in		Yes	YesVodafone: so exception request sheet in S3-173460 can be withdrawn and we will bring final SA3 CR next time conclusion: no LS answer	noted	No
7.5	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)	S3‑173264	Security requirements of T8 interface	Huawei, Hisilicon	CR	Agreement	Yes	YesMCC: "TS" should not be in spec number field; Tdoc number and CR number missing on CR cover; wrong WI code or agenda item NEC: we have a related Tdoc in S3-173325 conclusion: will be merged into S3-173463	merged	No
		S3‑173325	Security requirement for T8 reference point	NEC EUROPE LTD	CR	Agreement	Yes	YesMCC: adding empty sections is not ideal; file name inside zip file does not show Tdoc number Nokia: what is the privacy part? Orange: 2 different requirements; example should be another bullet point/requirement SA3 chair: NEC document is covering Huawei requirements? NEC: yes conclusion: S3-173325 will be revised in S3-173463 (merging into this one also the S3-173264 aspects)	revised	No	S3‑173463
		S3‑173463	Security requirement for T8 reference point	NEC EUROPE LTD	CR	Endorsement	Yes	Yesconclusion: endorsed and CR will not be sent to SA #78 but will be included in draft CR for next SA3 meeting	endorsed	No		S3‑173325
		S3‑173266	Authentication and transmission protection for T8 interface	Huawei, Hisilicon	CR	Agreement	Yes	YesMCC: "TS" should not be in spec number field; Tdoc number and CR number missing on CR cover; wrong WI code or agenda item Samsung: we have a related Tdoc in S3-173363 conclusion: discuss offline what can be merged from S3-173266 into S3-173464	merged	No
		S3‑173363	Security Mechanism for T8 interface	Samsung	CR	Agreement	Yes	YesHuawei: we could also merge S3-173266 and S3-173363 SA3 chair: as the Tdocs are different a merging will not be easy Samsung: one big difference is that credentials are very much open which we do not want Nokia: supports Samsung proposal Ericsson: an agreed CR from NEC added an empty section, it would be better that the former CR is not adding the empty section BT: reference need to be checked	revised	No	S3‑173464
		S3‑173464	Security Mechanism for T8 interface	Samsung	CR	Endorsement	Yes	Yesconclusion: CR is just endorsed and will not be provided to SA #78 but it will be included in the draft CR S3-173465	endorsed	No		S3‑173363
		S3‑173267	Authorization of SCS/AS to send requests for the 3GPP Network Entity	Huawei, Hisilicon	CR	Agreement	Yes	YesMCC: "TS" should not be in spec number field; Tdoc number and CR number missing on CR cover; wrong WI code or agenda item Ercisson: adding title twice Nokia: cridentials to be corrected Samsung: "preconfigured" unclear conclusion: 5.5.2 headline and "After the authentication, SCEF determines whether the SCS / AS is authorized to send requests for the 3GPP Network Entity." will be merged into S3-173464	merged	No
		S3‑173465	Northbound APIs Security for SCEF - SCS/AS Interworking	Huiawei, Hisilicon, NEC, Samsung	draftCR	Agreement	Yes	YesThis will be a working draft CR	endorsed	No
7.6	Other work areas
7.6.1	SAE/LTE Security	S3‑173021	LS on encrypting broadcasted positioning data	R2-1712031	LS in		Yes	YesSA3 VC: we plan to reply to this? seems we have 2 LSout on this (S3-173297 and S3-173374)	replied to	No
		S3‑173439	Reply to R2-1712031 = S3-173021 on encrypting broadcasted positioning data (to: RAN2; cc: RAN3, SA2; contact: Ericsson)	SA3	LS out	Approval	Yes	Yesboth proposals (from Ericsson & Qualcomm) will be attached to this LS	approved	No
		S3‑173296	Ciphering of Broadcast Assistance Data	Qualcomm Incorporated	discussion	Endorsement	Yes	YesEricsson: shouldn't we use different keys? Qualcomm: is it worth the extra complexity Ericsson: worried about limiting IV SA3 VC: let's see the alternative in S3-173373 and then discuss them together	noted	No
		S3‑173373	Discussion on details for encryption of LTE Positioning broadcast	Ericsson	discussion	Discussion	Yes	YesEricsson: suggests to send the Qualcomm and Ericsson proposals to RAN2 and let RAN2 decide as this is not really an SA3 issue SA3 VC: is this acceptable to send an LS to RAN2? Qualcomm: we should explain the MAC issue Nokia: why should RAN2 chose and not SA3? Ericsson: no security considerations anymore, RAN2 could decide (e.g. looking at aspects on quick calculation, large data) Nokia: we should do an evaluation in SA3 SA3 VC: so from SA3 point of view both proposals are acceptable; what is the RAN2 timeline for this? Ericsson: not much work ongoing at the moment Qualcomm: would be good to get feedback whether counter-mode is acceptable for RAN2	noted	No
		S3‑173297	Draft reply LS to R2-1712031 = S3-173021 on encrypting broadcasted positioning data (to: RAN2; cc: SA2; contact: Qualcomm)	Qualcomm Incorporated	LS out	Approval	Yes	YesMCC: source is already indicated as SA3; compare S3-173374 See instead S3-173439	withdrawn	Yes
		S3‑173374	Draft reply LS to R2-1712031 = S3-173021 on encrypting broadcasted positioning data (to: RAN2, SA2; cc: RAN3; contact: Ericsson)	Ericsson	LS out	Approval	Yes	YesMCC: source says already SA3; compare S3-173297 See instead S3-173439	withdrawn	Yes
		S3‑173375	Living document for ciphering of LTE positioning broadcast	Ericsson	discussion	Approval	Yes	Yes	noted	No
		S3‑173080	Clause 7.2.4.4 (rectifying use of HASH_MME at NAS_SMC in Rel-14)	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑173081	Clause 7.2.4.4 (Rectifying use of HASH_MME at NAS_SMC in Rel-15)	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑173191	Address EN for the RLFs for UEs doing user plane over control plane using NAS level security	Huawei, Hisilicon	CR	Agreement	Yes	YesSA3 VC: ME and Core Network boxes need to be ticked	revised	No	S3‑173440
		S3‑173440	Address EN for the RLFs for UEs doing user plane over control plane using NAS level security	Huawei, Hisilicon	CR	Agreement	Yes	YesQualcomm: we had the same CR S3-173298 under different AI SA3 VC: S3-173298 can be withdrawn then and S3-173440 is agreed unseen	agreed	No		S3‑173191
		S3‑173321	Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-14)	NEC EUROPE LTD	CR	Agreement	Yes	YesMCC: WI code missing on CR cover	revised	No	S3‑173415
		S3‑173415	Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-14)	NEC EUROPE LTD	CR	Agreement	Yes	YesQualcomm: Note 1 text needs correction (*the Attach Request and the TAU Request" needs to be replaced in first sentence) SA3 VC: change "may" into "could" in Note 2 two times; in Note 1: remove rest "menaing that the .."	revised	No	S3‑173441	S3‑173321
		S3‑173441	Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-14)	NEC EUROPE LTD	CR	Agreement	Yes	Yesconclusion: agreed unseen	agreed	No		S3‑173415
		S3‑173322	Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-15)	NEC EUROPE LTD	CR	Agreement	Yes	YesMCC: WI code missing on CR cover	revised	No	S3‑173416
		S3‑173416	Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-15)	NEC EUROPE LTD	CR	Agreement	Yes	Yessame changes needed as for S3-173415	revised	No	S3‑173442	S3‑173322
		S3‑173442	Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-15)	NEC EUROPE LTD	CR	Agreement	Yes	Yesconclusion: agreed unseen	agreed	No		S3‑173416
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)
7.6.8	Security Aspects of Home(e)NodeB (H(e)NB)
7.6.9	Security Aspects related to Machine-Type Communication ((e)MTC)
7.6.10	Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)
7.6.11	Security of MCPTT (MCPTT)	S3‑173458	Correction to MIKEY Key parameters	NCSC, Motorola, Airwave	CR	Agreement	Yes	Yes	agreed	No
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‑173010	LS/o on Security Requirements and Framework of Using Identity-Based Cryptography Mechanisms in Internet of Things	ITU-T	LS in		Yes	YesVodafone: SA1 should have this LS also in copy conclusion: no LS answer	noted	No
		S3‑173011	LS on “Security Requirements and Framework for Narrow Band Internet of Things”	ITU-T	LS in		Yes	YesSA3 chair: so we could send them a reply informing them about what we have done	replied to	No
		S3‑173471	Reply to ITU-T SG17-LS66 = S3-173011 on Security Requirements and Framework for Narrow Band Internet of Things (to: ITU-T SG17; cc: SA; contact: China Unicom)	SA3	LS out	Approval	Yes	Yes	approved	No
		S3‑173019	LS on Early Data Transmission	R2-1711978	LS in		Yes	Yes	replied to	No
		S3‑173014	Reply LS on Early Data Transmission	C1-174595	LS in		Yes	Yesconclsuion: no LS answer	noted	No
		S3‑173015	Reply LS on Early Data Transmission	S2-178180	LS in		Yes	Yesconclsuion: no LS answer	noted	No
		S3‑173169	Discussion on Security Issues with Early Data Transmission	Intel Corporation (UK) Ltd	discussion	Discussion	Yes	YesIntel: there are Qualcomm (3295) and Ericsson (3387)	noted	No
		S3‑173168	Draft reply LS to R2-1711978 = S3-173019 on Early Data Transmission (to: RAN2; cc: SA2, CT1; contact: Intel)	Intel Corporation (UK) Ltd	LS out	Approval	Yes	YesMCC: source is already SA3; compare S3-173387 conclusion: will be covered in S3-173472	merged	No
		S3‑173295	Discussion on a response to S3-173019/R2-1711978 on Early data transmission	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑173387	Draft reply LS to R2-1711978 = S3-173019 on Early Data Transmission (to: RAN2; cc: -; contact: Ericsson)	Ericsson LM	LS out	Approval	Yes	YesMCC: Tdoc is not an LSout as it does not use the LSout template; compare S3-173168 Ericsson: Q1 and Q2 are resolved (no security issue), for Q3 Intel does not agree Intel: we are in line from security perspective but we ask why Ericsson: for Q5 we of course prefer Ericsson solution but would like to hear others Qualcomm: on Q5 we would like to see some authorization to the UE Ericsson: does not agree with this Huawei: does not support to send NCC, is not necessary Ericsson: RAN2 is asking whether there is a security issue	revised	No	S3‑173472
		S3‑173472	Reply LS to R2-1711978 = S3-173019 on Early Data Transmission (to: RAN2; cc: RAN3, SA2, CT1; contact: Ericsson)	SA3	LS out	Approval	Yes	Yes	approved	No		S3‑173387
		S3‑173298	Removing editor’s note on calculation of UL_NAS_MAC and DL_NAS_MAC	Qualcomm Incorporated	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑173299	Security for the RLFs for UEs doing user plane over control plane using NAS level security for Rel-15 specification	Qualcomm Incorporated	CR	Agreement	Yes	YesMCC: wrong rev 2 on CR cover (which should be rev -) Qualcomm: this is actually a mirror CR that was forgotten in a previous meeting (Dali)	revised	No	S3‑173473
		S3‑173473	Security for the RLFs for UEs doing user plane over control plane using NAS level security for Rel-15 specification	Qualcomm Incorporated	CR	Agreement	No	Yes	agreed	No		S3‑173299
		S3‑173410	Reply LS on Early Data Transmission	S2-178180	LS in		Yes	Yes	withdrawn	Yes
7.6.15	New GPRS algorithms for EASE (EASE_ALGOs_SA3) (Rel-13)
7.6.16	Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)
7.6.17	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑173049	Summary for WI SCAS	NTT DOCOMO	WI summary	Endorsement	Yes	YesSA3 delegates are requested to review and to provide comments to the Tdoc author	noted	No
		S3‑173399	WI Summary of SCAS	DOCOMO Communications Lab.	WI summary	Endorsement	No	Yes	withdrawn	Yes
7.6.18	Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec)
7.6.19	Security of the Mission Critical Service (MCSec)	S3‑173054	Fix inter-domain IdM token exchange procedure	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑173417
		S3‑173417	Fix inter-domain IdM token exchange procedure	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑173054
		S3‑173059	Fix client check during GMK provisioning	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑173421
		S3‑173421	Fix client check during GMK provisioning	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑173059
		S3‑173284	[MCSEC] Clarification on validating GMS URI on receipt of GMK	NCSC	CR	Agreement	Yes	Yesconclusion: merged into S3-173421	merged	No
		S3‑173060	Alignment with MuSiK Stage 3 in CT1 specs 24.379 and 24.481	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑173424
		S3‑173424	Alignment with MuSiK Stage 3 in CT1 specs 24.379 and 24.481	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑173060
		S3‑173055	Group config I_MESSAGE clarification	Motorola Solutions Germany	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑173056	GMK over SIP and HTTP	Motorola Solutions Germany	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑173058	Fix media security for private call	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No
		S3‑173057	Fix reference to 33.179	Motorola Solutions Germany	CR	Agreement	Yes	YesMotorola: 33.179 ended in REL-13, in REL-14 we have 33.180	agreed	No
		S3‑173130	Group key distribution enhancement	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑173422
		S3‑173422	Group key distribution enhancement	Motorola Solutions Germany	CR	Agreement	Yes	YesNCSC: this is a correction in REL-14 (to allow the REL-15 feature, see S3-173130 under AI 7.3), we also have this error in REL-13 and will need to do a REL-13 33.179 CR (see S3-173458 under AI 7.6.11)	agreed	No		S3‑173130
7.6.20	Other work items	S3‑173034	LS on CAPIF security aspects	S6a170383	LS in		Yes	YesSA3 chair: there is a corresponding WID proposal in S3-173367 conclusion: no LS answer	noted	No
		S3‑173367	New WID on Security Aspects of Common API Framework	Samsung	WID new	Agreement	Yes	YesMotorola Solutions and Interdigital support the WI Huawei: fears that we may duplicate and not end up with a TS Nokia: harmonization should be understood as an attempt Huawei: we should not end up with 2 different mechanisms for the same SA3 chair: yes, 2 WGs working on this requires that we take this into account CMCC: wants to cosign Intel, LG: also support the WI conclusion: revised to add more supporters	revised	No	S3‑173498
		S3‑173498	New WID on Security Aspects of Common API Framework	Samsung	WID new	Agreement	Yes	Yes	agreed	No		S3‑173367
		S3‑173064	Proof of Concept PKI Implementation for NodeB Authentication	AT&T, MITRE, Interdigital	discussion	Decision	Yes	Yesproposal: A Study Item Description (SID) or Work Item Description (WID) should be created for the addition of functionality to support the use of PKI in special use cases to protect certain AS/NAS messages in 5G. Interdigital: this is for an isolated system, this is to lock out rogue systems completely Ericsson: thought that we were mitigating this issue already NTT DOCOMO: this is for LTE? At the moment we are very busy and so coming with this at a different time would be better; not sure that there is a business case Vodafone: same view on timing and a SI would be more appropriate than a WI MITRE: has related Tdoc in S3-173035 conclusion: can bring a proposal in the future again	noted	No
		S3‑173271	IoT botnet detection and dismantling	China Mobile	discussion		Yes	Yesproposal: to discuss and study the IoT botnets, and provide efficient solutions to stop IoT devices services when large scale devices are compromised. KPN: supports a later SI Vodafone: agrees with KPN but not before mid 2018 BT: worried about (1) Ericsson: not clear what SA3 could standardize for this SA3 chair: people are positive to study this in the future but not now	noted	No
		S3‑173274	Malicious Internet Voice Systems detection	China Mobile	discussion		Yes	YesNokia: we had a couple of SIs and WIs on this so suggests to look into the corresponding documentation BT: suggests to be a bit more careful with the language	noted	No
		S3‑173324	Editorial in TS 33.187	NEC EUROPE LTD	CR	Agreement	Yes	YesMCC: Tdoc number missing in file name inside zip file	revised	No	S3‑173474
		S3‑173474	Editorial in TS 33.187	NEC EUROPE LTD	CR	Agreement	Yes	Yes	agreed	No		S3‑173324
		S3‑173368	Security Aspects of Common API Framework for 3GPP Northbound APIs	Samsung	other		Yes	Yesis actually a draft TS skeleton related to new WI S3-173498	endorsed	No
		S3‑173369	pCR on CAPIF Security requirements	Samsung	other		Yes	Yes	postponed	No
		S3‑173370	pCR on CAPIF security within PLMN Trust Domain	Samsung	other		Yes	Yes	postponed	No
		S3‑173372	pCR on CAPIF Security mechanism for CAPIF-1e	Samsung	other		Yes	Yes	postponed	No
		S3‑173532	WI summary ERP	Orange	WI summary	Endorsement	Yes	YesSA3 delegates are requested to review and to provide comments to the Tdoc author	noted	No
8	Studies
8.1	Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)	S3‑173285	[FS_MC_SEC] Update to EAR (Solution #1.6) in TS 33.880	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑173286	[FS_MC_SEC] TR 33.880 EAR Authorisation solution	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑173287	[FS_MC_SEC] Evaluation of EAR solution in TS 33.880	NCSC	pCR	Approval	Yes	YesMotorola Solutions: there is a related CR as well and we have not yet achieved agreement on this NCSC: suggests to leave some more time for offline discussion conclusion: further offline discussion and we will come back to it later this week	approved	No
		S3‑173061	Interworking key management KI	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑173418
		S3‑173418	Interworking security data transfer	Motorola Solutions Germany	pCR	Approval	Yes	Yestitle was corrected	approved	No		S3‑173061
		S3‑173062	Interworking key management SIP MESSAGE solution	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑173425
		S3‑173425	Interworking security data MESSAGE solution	Motorola Solutions Germany	pCR	Approval	Yes	Yestitle was corrected NCSC: still some KMM to be corrected (to be replaced)	approved	No		S3‑173062
		S3‑173063	Interworking key management MCData solution	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑173423
		S3‑173423	Interworking security data MCData solution	Motorola Solutions Germany	pCR	Approval	Yes	Yestitle was corrected Motorola Solutions: still some KMM to be replaced	approved	No		S3‑173063
		S3‑173388	[eMCSEC] Evaluation of Security Gateways (SeGy)	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑173454	TR 33.880 v1.6.0 including agreements from SA3 #89	NCSC	draft TR	Agreement	Yes	YesNCSC: TR should go to SA #78 for approval	agreed	No
		S3‑173455	Cover for TR 33.880	NCSC	TS or TR cover	Agreement	Yes	YesNCSC: FS_MC_Sec is 90% complete (as SA6 is still working on it) Note: Presentation to SA #78 will have to be done with v2.0.0 so change of version on S3-173455 is needed before submission to SA #78.	approved	No
8.2	Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)	S3‑173025	LS on FS_REAR study outcome	S2-176446	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173018	Reply LS on FS_REAR study outcome	R2-1711861	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173026	LS on FS_REAR SI conclusion	S2-177943	LS in		Yes	Yesconclusion: no LS answer	noted	No
		S3‑173240	Clarification of key issue #7	Huawei, Hisilicon	pCR	Approval	Yes	YesSA3 VC: more authorization than authentication Ericsson: unclear what the key issue is	revised	No	S3‑173475
		S3‑173475	Clarification of key issue #7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑173240
		S3‑173241	Authentication of eRemote UE during one-to-one communication setup	Huawei, Hisilicon	pCR	Approval	Yes	YesKPN: proposal does more than expected, e.g. also sets up secure connection LG: agrees with KPN that topic was authorization by network Ericsson: would be happy to put it in as it is, there is already an editor's note so no need to add another one conclusion: key isssue 7 will be added in introductory text	revised	No	S3‑173476
		S3‑173476	Authentication of eRemote UE during one-to-one communication setup	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑173241
		S3‑173242	Remove Editor's Note in subclause 5.4.3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑173243	Remove Editor's Note in subclause 6.7.2 of Solution #7	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑173244	Remove Editor‘s Note in Solution of Discovery	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑173245	Solution of discovery parameters configuration for eRemote UE when dynamic trust relationship establishment is supported	Huawei, Hisilicon	pCR	Approval	Yes	YesKPN: structure of the pCR needs a cleanup, also key issue has to be listed; we should solve it in line with SA2 Huawei: will do the cleanup and agrees on the last point	revised	No	S3‑173478
		S3‑173478	Solution of discovery parameters configuration for eRemote UE when dynamic trust relationship establishment is supported	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑173245
		S3‑173315	Structure of Conclusions Clause	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑173316	Conclusions for KI #2	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑173317	Resolving editor's Notes for KI #3	KPN	pCR	Approval	Yes	YesHuawei: suggest to keep first editor's note in 5.3.4 KPN: ok, if Huawei intends to remove it next time conclusion: first editor's note under 5.3.4 will not be deleted and 5.x will not be added	revised	No	S3‑173479
		S3‑173479	Resolving editor's Notes for KI #3	KPN	pCR	Approval	Yes	Yes	approved	No		S3‑173317
		S3‑173318	Conclusions for KI #3	KPN	pCR	Approval	Yes	YesHuawei: does not agree to the change KPN: we can work on this until next meeting	postponed	No
		S3‑173319	Conclusions for KI #8	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑173320	Conclusions for KI #9	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑173339	Conclusions for KI 6	KPN N.V.	pCR	Approval	Yes	Yes	approved	No
		S3‑173477	TR 33.843 v0.3.0 on Study on security aspect of architecture enhancements to Proximity Services (ProSe) User Equipment (UE)-to-network relay	Huawei	draft TR	Agreement	Yes	Yescapturing all agreements of SA #89 Nokia: SI has been concluded in other WGs but not in SA3? Huawei: correct, intention is to complete the SI in March 18; 79% complete will be reported to SA #78; intention is to bring the TR for 1-step approval to SA #79	agreed	No
8.3	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)	S3‑173037	Threats against LTK and limitations of existing approaches	InterDigital, Inc.	discussion	Decision	Yes	YesVodafone: last bullet of Recommendations: only if we select GSMA based solutions Interdigital: related pCR in S3-173039	noted	No
		S3‑173038	Threats against LTK and limitations of existing approaches	InterDigital, Inc.	discussion	Decision	No	Yes	withdrawn	Yes
		S3‑173039	LTK Derivation – Key Issue 7.x	InterDigital, Inc.	pCR	Approval	Yes	YesOrange: so main threat: key transported between SIM maker and operator; requirement is suggesting a specific solution BT: there should be just one communication link; longterm key should be generated in the system that minimized the number of links Vodafone: we intend to not tie this TR to 5G, it should be applicable to other technologies as well BT: not happy about "while being stored" under 1. in 7.X.1 esp. the (e)UICC should not be there so better remove the text in ( ) Orange: wants an editor's note under requirement: which longterm keys is ffs Vodafone: we could do this next time Gemalto: maybe we can remove the e.g. MCC: general request to respect drafting rules (e.g. no automatic numbering is allowed) otherwise the rapporteur will have to do a lot of reformatting conclusion: first e.g. and ( ) at the end of 1. in 7.x.1 will be removed; 5G will be avoided, editor's note will be added	revised	No	S3‑173500
		S3‑173500	LTK Derivation – Key Issue 7.x	InterDigital, Inc.	pCR	Approval	Yes	Yes	approved	No		S3‑173039
		S3‑173239	pCR to TR33.834 Update long term keys based on PKI	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: is not addressing key issue we have; you are introducing a new long term key SA3 VC: it seems there is a proposal to remove evaluation or to add an editor's note BT: does not agree that it will become a new longterm key Gemalto: would like to add text under evaluation Vodafone: evaluations needs to be extended conclusion: remove 1st sentence of evaluation and discuss other parts of evaluation offline (if no consensus then evaluation will be removed)	revised	No	S3‑173501
		S3‑173501	pCR to TR33.834 Update long term keys based on PKI	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑173239
		S3‑173249	pCR to TR33.834 - Updates as agreed at LTKUP conf call	VODAFONE Group Plc	pCR	Approval	Yes	YesVodafone: was output of conference call BT: may be in conflict with previously agreed pCR Vodafone: it is not ruling out Gemalto: editor's note for AMF based solution under 9.x.3.1 preferred Orange: 7.1.3: protect instead of change (change is already the solution) and make requirement conditional Vodafone: does not agree to "protect" SA3 VC: discuss this further offline Orange: 8.5: add "(if any)" conclusion: editor's note in 9.x.3.1, (if any) in 8.5, further discussion about 7.1.3 text	revised	No	S3‑173502
		S3‑173502	pCR to TR33.834 - Updates as agreed at LTKUP conf call	VODAFONE Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑173249
		S3‑173252	pCR to TR 33.834 - addition of DH trnsport options	VODAFONE Group Plc	pCR	Approval	Yes	Yes	approved	No
		S3‑173254	pCR to TR33.834 - addition of Public Key, Extended USIM OTA and inline with authentication solutions	VODAFONE Group Plc	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑173323	LTKUP: solution proposal	Gemalto N.V.	pCR	Approval	Yes	YesOberthur:several keys for one IMSI? Gemalto: only one is active, same as Vodafone Vodafone: conclusions should only be put in when all solutions are in Oberthur: if card is broken all sets will be compromised so we should add "assessment if card is broken" under 9.x.3.6 Oberthur: 2nd bullet under 1. in 9.x.2 is complex and unclear how it is secured Vodafone: can add editor's note under 9.x.3.6 Vodafone: would be happy to provide SI TR for information to SA Orange: we can wait one more cycle Gemalto: agrees that it is too early to bring TR for information BT: would be ok to send the TR to SA Vodafone: anyone planning to bring more solutions? conclusion: 3 editor's notes under 9.x.3.6 about additional risks, removal of conclusion; further offline discussion whether to send TR for information to SA #78	revised	No	S3‑173503
		S3‑173503	LTKUP: solution proposal	Gemalto N.V.	pCR	Approval	Yes	Yes	approved	No		S3‑173323
		S3‑173504	TR 33.834 v0.3.0 collecting agreements of SA3 #89	Vodafone	draft TR	Agreement	No	Yessending out before Thu 7.12.17 eob CET comments before Mon 11.12.17 eob CET agreed version sent out before Wed 13.12.17 eob CET	for email discussion	No
8.4	Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)	S3‑173161	Threats and requirement to KI#1	Huawei & Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑173492
		S3‑173492	Threats and requirement to KI#1	Huawei & Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑173505	S3‑173161
		S3‑173505	Threats and requirement to KI#1	Huawei & Hisilicon, CATR, China Unicom	pCR	Approval	Yes	Yes	approved	No		S3‑173492
		S3‑173167	Adding security threat and requirement for TR 33.811 clause 5.1	CATR	pCR	Approval	Yes	YesTdoc is already included in S3-173492	merged	No
		S3‑173214	Security requirements for Key issue #1: Unauthorized access to Management Exposure Interface	China Unicom	pCR	Approval	Yes	YesTdoc is already included in S3-173492	merged	No
		S3‑173160	A key issue proposal on security capability for TR33.811	Huawei & Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑173491
		S3‑173491	A key issue proposal on security capability for TR33.811	Huawei & Hisilicon	pCR	Approval	Yes	YesHuawei: changes compared to S3-173160: 5.x.1 was rephrased, 5.x.2 if statements, 5.x.3 requirements rewritten Orange: not related to roaming, change HPLMN to MNO Orange: bullets 2-6 under 5.X.3 should be removed and security in first bullet should be removed, is this then in the scope of SA3? BT: "customer" in bullet 4 needs clarification Interdigital: is supporting the Tdoc SA3 VC: it seems at the moment there is no consensus conclusion: talk further offline	revised	No	S3‑173513	S3‑173160
		S3‑173513	A key issue proposal on security capability for TR33.811	Huawei & Hisilicon	pCR	Approval	No	YesOrange: talked with SA5 delegate that this is beyond SA3 SI	rejected	No		S3‑173491
		S3‑173215	Key issue on network slice instance commissioning	China Unicom	pCR	Approval	Yes	Yes	not treated	No
		S3‑173216	Key issue on network slice instance creation conflict detection	China Unicom	pCR	Approval	Yes	Yes	not treated	No
		S3‑173217	Key issue on network slice instance decommissioning	China Unicom	pCR	Approval	Yes	Yes	not treated	No
		S3‑173279	Key issue on protecting the integrity of results of NSI supervision/reporting	China Mobile	pCR	Approval	Yes	YesBT: 5.x.3 needs rewording and remove "in transmitting" conclusion: improve 5.x.3 wording	revised	No	S3‑173506
		S3‑173506	Key issue on protecting the integrity of results of NSI supervision/reporting	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑173279
		S3‑173280	Key issue on protecting Network Slice Subnet Template	China Mobile Group	pCR	Approval	Yes	YesBT: network slice subnet reference to be added SA3 VC: language can be improved; if definition/reference is not available, then we cannot agree the pCR	revised	No	S3‑173507
		S3‑173507	Key issue on protecting Network Slice Subnet Template	China Mobile Group	pCR	-	Yes	Yes	approved	No		S3‑173280
		S3‑173525	TR 33.811 v0.3.0 collecting agreements of SA3 #89	Huawei	draft TR	Agreement	No	Yessending out before Thu 7.12.17 eob CET comments before Mon 11.12.17 eob CET agreed version sent out before Wed 13.12.17 eob CET	for email discussion	No
8.5	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)	S3‑173247	initial TR33.xxx - Study on the support of 256-bit Algorithms for 5G	VODAFONE Group Plc	other		Yes	YesNCSC: threats for quantum cryptography? Home Office: is not about cryptography but about quantum computing Ericsson: why are points of SID used as headings but last parts are missing? Should we have editor's notes for this Vodafone: we can have it in the scope SA3 chair: you may want to have editor's notes under the section headings Qualcomm: Proposed requirements should be changed to Potential requirements Vodafone: ok Orange: we should also have a conclusion section Vodafone: this is a study of the threats but will add it	revised	No	S3‑173462
		S3‑173462	initial TR33.xxx - Study on the support of 256-bit Algorithms for 5G	VODAFONE Group Plc	other	Endorsement	No	Yesnote: The SID for this SI was agreed in the last SA3 meeting in S3-172556 but it is not yet approved by SA and therefore the SID will be submitted to SA #78 for approval. Once the SID is approved a corresponding TR number can be allocated. sending out before Thu 7.12.17 eob CET comments before Mon 11.12.17 eob CET agreed version sent out before Wed 13.12.17 eob CET	for email discussion	No		S3‑173247
		S3‑173248	pCR to TR33.xxx - 256 bit keys: Co-existence of different size keys and number and types of algorithms	VODAFONE Group Plc	other		Yes	YesVodafone: in the phone call different companies offered to fill different sections, this is our input Ericsson: suggests to remove 10.1 Ericsson: type is rather symmetric/asymmetric and not algorithms BT: we seem to fill out the back of the TR without doing the first part (the threats) so section 4 should be filled out first or at least have editor's notes in the later sections that they will checked against the earlier sections Vodafone: we can add editor's note "will be reviewed" conclusion: 10.1 and 10.2 will be removed; add editor's notes and capture all in S3-173462	noted	No
		S3‑173281	pCR to TR 33.xxx - Addition of Quantum threats and countermeasures	VODAFONE Group Plc, NIST	other		Yes	YesEricsson: some instead of many scientists Vodafone: ok Orange: change "security community" NCSC: add "theoretical" for speedup conclusions: changes will be captured in S3-173462	noted	No
		S3‑173378	Overview of existing GSMA/3GPP symmetric algorithms	Ericsson	discussion	Approval	Yes	YesEricsson: text could be added to living document Vodafone: in section 10? BT: correct table colours BT: maybe we should add that not all algorithms are covered Vodafone: not needed conclusion: text will be merged into section 10 of S3-173462	noted	No
		S3‑173381	Overview of NIST Post-Quantum Standardization	Ericsson	discussion	Approval	Yes	YesNCSC: do we need all this information? Orange: wonders why we need all this text NIST: we support to include the text conclusion: no consensus to include this in the living document	noted	No
		S3‑173385	Additional Benefit of 256 bit keys	U.S. Department of Commerce	other		Yes	Yesconclusion: will be included in S3-173462	noted	No
		S3‑173052	Draft LS on the Impacts of increasing the MAC-I (to: RAN2, RAN3; cc: ETSI SAGE; contact: AT&T)	InterDigital, AT&T	LS out	Approval	Yes	YesMCC: LS has already source: SA3 Vodafone: as the SI is not yet officially approved, we should better wait with it Qualcomm: answering RAN2/RAN3 to analyze before we did our work is strange so we would be even worried to send the LS next time	postponed	No
8.6	Other study areas
9	Review and Update of Work Plan	S3‑173003	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
		S3‑173006	Work Plan input from Rapporteurs	MCC	discussion		Yes	Yes	revised	No	S3‑173412
		S3‑173412	Work Plan input from Rapporteurs	MCC	discussion	-	Yes	Yes	not treated	No		S3‑173006
10	Future Meeting Dates and Venues	S3‑173005	SA3 meeting calendar	MCC	discussion		Yes	YesQualcomm: may be we do not need the March 19 ad hoc SA3 chair: fine, then we remove the ad hoc in week 8 2019 NTT DOCOMO: so SA3 #94 can be moved 1 week later SA3 chair: ok, SA3 #94 will then be in week 4 conclusion: weeks 4, 18, 25, 34, 41, 46	revised	No	S3‑173529
		S3‑173529	SA3 meeting calendar	SA3 chairman (NEC)	discussion	-	Yes	YesOrange: suggest to cancel the July 2018 ad hoc NTT DOCOMO: would be happy to remove it but we may need to have an ad hoc to complete our work Vodafone: removal may have impact on the travel budget from companies SA3 chair: also the Sep. 18 is optional conclusion: July 18 and Sep.18 meetings are currently kept in the meeting calendar, SA3 will discuss in the future whether these 2 meetings will be really take place or not (hosts will be warned that these 2 meetings are not yet confirmed)	agreed	No		S3‑173005
11	Any Other Business
12	Closing of the meeting