TDoc list

Tdoc List

2017-04-04 14:57

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‑170600	Agenda	SA WG3 Chair	agenda		Yes	YesDK Lee from Samsung welcomed the delegates. Chair introduced the agenda. First the chair would like to do the questions for SA2, then open the LS and then taken 5.1.1 to 5.1.4 and followed by 5.1.8. SA2 will prepare questions for joint meeting. Tomorrow morning will look at SA2 questions before Mission Critical. Joint meeting will be 6pm for at most 1.5 hours. Wednesday evening will be an informal session on NB-IoT RLF (with no decision power) chaired by Alf. Thursday output will start with non-5G topics. Chair went through IT courtsey and IPR reminder. There was discussion on the progress of 5G in SA3 and the need to make decision to ensure progress. NSA deadline is December 2017 and March 2018 for SA. The need for a July meeting was discussed with the conclusion that it depends on progress. The general preference would be to not have the meeting. An electronic meeting will be organised for NB-IoT RLF. The chair reminded everyone that he will use informal vote to help make progress and if there is no progress and then there wil need to be a technical vote. There was some agreement that we need to prioritize Option 3 work (the new WID agreed in plenary in SP-17xxxx). Adrian (rapporteur) will prepare a doc order for these documents for discussion later in the week.	approved	No
3	IPR Reminder
4	Work Areas
4.1	Security of the Mission Critical Service (MCSec)	S3‑170606	Temporary Group call – user regroup security	S6-170203	LS in		Yes	YesWaiting for SA6 progress - Noted	noted	No
		S3‑170856	[MCSEC] Clean up of clause 5.2.2 and Annex D in TS 33.180	NCSC	pCR	Approval	Yes	YesOffline comments were given -> 881	revised	No	S3‑170881
		S3‑170881	[MCSEC] Clean up of clause 5.2.2 and Annex D in TS 33.180	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑170856
		S3‑170674	33.180 pCR identity scope	Motorola Solutions Danmark A/S	pCR	Approval	Yes	YesAirbus asked if there was a KMS per service. Motorola answered that this was architecturally possible, so was allowed for - approved	approved	No
		S3‑170675	33.180 pCR Inter-domain IdM	Motorola Solutions Danmark A/S	pCR	Approval	Yes	YesOffline comments were given -> 892	revised	No	S3‑170892
		S3‑170892	33.180 pCR Inter-domain IdM	Motorola Solutions Danmark A/S	pCR	Approval	Yes	YesNokia queried the reference [bb] in C2 step 8a. Motorola thought it was correct but would confirm offline. Once this point is agreed the document will be brought to plenary again to be approved - approved	approved	No		S3‑170675
		S3‑170676	33.180 pCR Inter-domain IdM profile	Motorola Solutions Danmark A/S	pCR	Approval	Yes	YesFormat of two tokens were confimed to be the same - approved	approved	No
		S3‑170857	[MCSEC] Support for multiple security domains within TS 33.180	NCSC	pCR	Approval	Yes	YesOffline comments were given -> 894	revised	No	S3‑170894
		S3‑170894	[MCSEC] Support for multiple security domains within TS 33.180	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑170857
		S3‑170858	LS on addition of KMS URI to configuration parameters	NCSC	LS out	Approval	Yes	Yes	revised	No	S3‑170895
		S3‑170895	LS on addition of KMS URI to configuration parameters	NCSC	LS out	Approval	Yes	YesThis will be revised to include Morpho's suggestion made during discussion on 893. Also the attachment document numbers need to be specified. Approved	approved	No		S3‑170858
		S3‑170860	[MCSEC] Implementation of Solution #1.2 in TS 33.180	NCSC	pCR	Approval	Yes	YesEricsson said he was fine with this in principle but he wanted to discuss offline with NCSC some feedback he'd had on the MBMS case. Vice-chair pointed out that MSK is an abbreviation which is already used in EAP. NCSC (Peter) agreed to come up with a new abbreviation. Airbus was also fine with the document in principle but thought it could be reformatted to split out the Signalling Protection and Floor Control sections. -> 913	revised	No	S3‑170913
		S3‑170913	[MCSEC] Implementation of Solution #1.2 in TS 33.180	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑170860
		S3‑170861	LS on update to key management for application signalling	NCSC	LS out	Approval	Yes	YesRevised based on offline discussions -> 884	revised	No	S3‑170884
		S3‑170884	LS on update to key management for application signalling	NCSC	LS out	Approval	Yes	YesNCSC presents. The major features for MCPTT and MCVideo have been completed, however a feature ‘temporary group call – user regroup’ has not been addressed as we are waiting on information from SA6. Work on MCData is only partially completed. We are waiting on the choice of protocol from CT1 before defining the security mechanism approved	approved	No		S3‑170861
		S3‑170899	[MCSec] 33.180 first to answer call security	Motorola Solutions Danmark A/S	pCR	Approval	Yes	Yes	approved	No
		S3‑170914	Draft TS 33.880	NCSC	draft TS	Approval	No	Yes	approved	No
4.2	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑170725	CR to TS 33.401 adding BEST functionality	VODAFONE Group Plc, KPN, Juniper, Nokia	CR	Agreement	Yes	YesThis is a major re-write of the CR Use of X for a new section and the new Annex will be avoided. LI issues were raised - it was suggested that an LS will be sent if some text gets approved It was questioned whether these would be better as a new TS - this was agreed The changes will be incorporated in a draft TS -> 916	not pursued	No		S3‑170173
		S3‑170869	Comments-on S3-170725 CR to TS 33.401 adding BEST functionality	Juniper Networks, KPN	other	Approval	Yes	YesThis is mostly editoiral corrections and corrceting error names. A more substantial re-ordering of text in X.5 was proposed - >917	revised	No	S3‑170917
		S3‑170917	Comments-on S3-170725 CR to TS 33.401 adding BEST functionality	Juniper Networks, KPN	other	Approval	Yes	Yes	approved	No		S3‑170869
		S3‑170874	Comments on S3-170725 Adding BEST functionality to TS 33.401	Nokia	other	Approval	Yes	YesDuring the discussion the use of the S6a name for HSE to EMKS and EMKS to HSS was raised. It was agreed to add a UP and CP interface between the UE and HSE in Annex X.2.1, it will be claried that there is data over DoNAS and no impact on NAS	approved	No
		S3‑170918	Comment on S3-170874	Ericsson	other	discussion	Yes	YesThe contents of the tdoc will be used to modify the TS after the meeting. Noted	noted	No
		S3‑170670	Allocation of FC values for BEST	KPN, Vodafone	CR	Agreement	Yes	YesThis needs to be updated once there is a TS number for the BEST TS. It was postponed.	postponed	No		S3‑170183
		S3‑170941	WID update for BEST	Vodafone	WID revised	Agreement	Yes	YesVF presents E//: architecture needs to be updated, so remove UTRAN TIM: any other changes to other TS? VF: no Huawei: why is 5G in justification VF: NBIoT is 5G technology Huawei: remove 5G CMCC: also support this WID approved	agreed	No
		S3‑170916	Draft TS BEST	Vodafone	other	discussion	Yes	Yes	approved	No
		S3‑170671	proposed LS to CT4 on extension of the S6a interface for BEST	KPN	LS out	Approval	Yes	YesThis needs to be updated to reflect the decision that the interface will be renamed and not propose the use of the S6a interface. Ericsson: Should CT1 be asked to do the stage 3 protocol specification KPN: Agree New content is inform CT1 and CT4 and cc:SA2 and for CT4 to specifiy the new interface and ask CT1 to take the information into account The LS will also inform SA3-LI about creation of the TS	revised	No	S3‑170956	S3‑170176
		S3‑170956	LS to CT4 on extension of the S6a interface for BEST	KPN	LS out	Approval	Yes	YesVF presents Orange: creation of interface of by SA2 ATT: CT groups own the stage 2 of interfaces, if they don't create a new interface, then SA2 doesn't get involved Nokia: new SA2 action: review interface between HSE and EAS VF: ok	approved	No		S3‑170671
		S3‑170750	BEST: Update on Key synchronization in Solution #10	Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑170756	BEST: Update on key uniqueness per EMSE in Solution #10	Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑170743	BEST: Update on key synchronization in Solution #10	Nokia France	CR	Agreement	No	No	withdrawn	Yes
5	Studies
5.1	Study on Architecture and Security for Next Generation System (FS_NSA) (Rel-14)
5.1.1	Security architecture	S3‑170865	ToC for 5G TS	NTT DOCOMO INC.	draft TS		Yes	YesDoCoMo presented the tdoc. It provides a first pass at the table of content for the 5G security architcture. Vdf raised issue of 402 in 501 (it was clarified that 33.402-like text will be in 33.501), where does BEST go. Huwaei raised the issue of sliicng. Its location would depend on whether there was slicing specific securiy or if it was NAS or otherwise. Option 3 was agreed to be specified initially in TS 33.401, but with the NR part to be moved to TS 33.501 later. Service based security was questioned. It was proposed to moved the security visibility to clause 5.3. It was agreed to move it to 5.3 and rephrase the headings to 'Security Indicators' and 'Security configurability'. Elements were changed to Functions. It was questioned why security requirment and features are kept together. In LTE, it was kept together to avoid repitition. Tim: interworking with 4G, should that go into 501, the non-interworking IDCC: network elements -> functions Nokia: in 23.501 there is talk about network function services, so document security for services Orange: in SA2, these are empty for now, so wait Oberthur: non standalone aspects in this spec? QC: should be in 401 in the beginning, then potentially ported to 501 agreement: putting ENDC in 401 at the start, implications on gNB and UE in 501 QC: 6 as subsection of 5 Huawei: add network slicing security IDCC: agree Orange: add when content is there Nokia: agree QC: remove 6.2 Nokia: change titles (agreed) TIM: not lump together requirement and features Nokia: put together because requirements and features because requirements give rise to features agreement: network element -> network functions agreement: move clause 6 under 5 agreement: 6.1 security indicators, 6.2 security configurability -> 903 approved	revised	No	S3‑170903
		S3‑170903	ToC for 5G TS	NTT DOCOMO INC.	draft TS	-	Yes	Yes	approved	No		S3‑170865
		S3‑170866	Scope for TS33.501	NTT DOCOMO INC.	pCR		Yes	YesVF: change next gen to 5G ok VF: 4G radio to 4G core in this document? QC: in the beginning, put everything of ENDC to 401, then move to 501 when 501 is stable, turn into reference Dragan: 5G NR or only NR? Agreement: replace next generation by 5G -> approved as 904	revised	No	S3‑170904
		S3‑170904	Scope for TS33.501	NTT DOCOMO INC.	pCR	-	Yes	Yes	approved	No		S3‑170866
		S3‑170723	Adding EN to declar the ambiguity of AMF in TR33.899	Huawei, Hisilicon	pCR		Yes	YesHuawei presented.This is a typo in editor's note and it should be acronym not defintion. SA2 have already responded that they will not change. Add other AMF and a 'Note: Acronym is used with both different meanings but it is clear from the contxet which one is meant' It was proposed in 33.501 to use acmf instead of SA2-type amf -> approved as 905	revised	No	S3‑170905
		S3‑170905	Adding EN to declar the ambiguity of AMF in TR33.899	Huawei, Hisilicon	pCR	-	Yes	Yes	approved	No		S3‑170723
		S3‑170811	Discussion of denial of service requirements in 5G	KPN	discussion		Yes	YesSeveral points were raised and many of those were agreed by KPN. Some of these comments will make changes to later documents It was taken with 872	noted	No
		S3‑170872	Comments to S3-170811_Denial_of_Service_in_FS_NSA-2	China Mobile Com. Corporation	other	Agreement	Yes	YesCMCC presents TNO: comments valid, solution would work against random attach requests, implications on later documents	noted	No
		S3‑170822	Late: Adding detection and reaction layer to 5G	KPN	pCR		Yes	YesNokia: how can this be prevented; should this be protection layer KPN responded: A UE is deliberately attacking the network - will it go away - yes if application is the problem with working basedband, but not if baseband is compromised. Maybe easier to compromise application then baseband. KPN keen to hear what vendors think can be done, e..g new layers. IDCC: Back-off messages are DoS attacks in their own right. Jamming attacks are not generally delat with and this is only a jamming attack. Compared to 2.11, this is a generic approach. BT like the paper, but what happens if the malware is faking an emergnecy call which can not be blocked. Proposal is block a specific UE and not a general group of UEs. QC: should tell the UE to detach VF: reword: nextgen not 5G E//: agree with QC, more like an implementation Huawei: same like 2.11, make it more generic, get the network to block QC: add editor's note, check whether this is also the case if the baseband is compromised agreement: add editor's note, -> 906	revised	No	S3‑170906
		S3‑170906	Late: Adding detection and reaction layer to 5G	KPN	pCR	-	Yes	Yes	approved	No		S3‑170822
		S3‑170816	Adding interim question on NAS integrity protection without security context	KPN	pCR	Approval	Yes	YesNokia: the question seems contradictory: integrity protection without security context TNO: sounds strange, so can be noted Intel: overlap with fake eNB threat TNO: note it	noted	No
		S3‑170820	Evaluation of solution 2.5, 2.11, 7.9 and 7.10	KPN	pCR		Yes	YesTNO: will be revised based on CMCC comments ->907	revised	No	S3‑170907
		S3‑170907	Evaluation of solution 2.5, 2.11, 7.9 and 7.10	KPN	pCR	-	Yes	YesKPN presents Huawei: were comments on 2.11 captured KPN: will be done approved	approved	No		S3‑170820
		S3‑170873	Comments to S3-170820_evaluation of solutions 25 211 79 710-2	China Mobile Com. Corporation	pCR	Agreement	Yes	YesSome comments from this contribution will be taken into account in a revision of S3-170820.	noted	No
		S3‑170634	Overview of proposed interim agreements on security architecture for 5G phase	Nokia	discussion		Yes	YesThis provides an overview of the proposed conclusions. Nokia presents TIM: 1.16-1.18 do they have companion CR Nokia: not from Nokia VF: does security in RAN include separated out RAN noted Nokia: yes DCM: does this mean: non- treated areas should be in phase 2 Nokia: only prioritization	noted	No
		S3‑170688	pCR for adding details for key issue #1.1 Overview of NextGen security architecture	Huawei & Hisilicon	pCR	Approval	Yes	YesHuawei presents E//: this is a solution to key issue, some things are not generic Nokia: deprioritize for now, is this still the right picture? Huawei: currently the decisions can't be reflected in image, useful to visualize TIM: some numbers are not visisble in picture: e.g 7, what are the security features shouldn't be mentioned Huawei: even in LTE 7 is not visible Orange: do this later noted	noted	No
		S3‑170635	Proposed interim agreements on co-locating SEAF-AMF for 5G phase 1	Nokia	pCR		Yes	YesNokia presents together with 636	revised	No	S3‑170908
		S3‑170908	Proposed interim agreements on co-locating SEAF-AMF for 5G phase 1	Nokia	pCR	-	Yes	YesNokia presents approved	approved	No		S3‑170635
		S3‑170636	Evolution scenario for AMF and SEAF from 5G phase 1 to later phases	Nokia	discussion		Yes	YesGünther presents potentially to be turned into pCR TIM: in 3.1, not talk about KUPenc in AN keys Nokia: if decision is made, then it is more like in figure 3. TIM: almost everything is in phase 1 Orange: massive IoT is in phase 2 VF: on 635: argument about about secure AMF/SEAF location needs to be captured, add to first agreement Nokia: add to second agreement DCM: common one for all access networks? Nokia: yes QC: different in roaming scenario, one in serving network and one in home network Nokia: single security anchor per PLMN, used for all kinds of access networks. Huawei: in case of un-trusted 3GPP access, in same PLMN does authentication go to same security anchor Nokia: yes QC: if anchor key is thrown away, there is no way of reusing it for authentication Nokia: all accesses are below the AMF key ?: access keys should be derived from anchor key Nokia: this is like a standalone SEAF, with separate interfaces agreed with interim agreement: e.1.2.1.2 modified as "single security anchore per PLMN used for all kinds of…" explanation ---- for non 3gpp the untrusted access is in different plmn then there is different security anchor if they go to same core network then they have same anchor e.1.2.2.2	noted	No
		S3‑170843	Proposed conclusion for standalone SEAF	Qualcomm Incorporated	pCR	Approval	Yes	YesAdrian presents E//: first two paras of rationale seem to point at only advantage with 3GPP in visited network, non-3GPP in home QC: architecture would allow future enhancement Nokia: also have a discussion paper on having home SEAF E//: home SEAF not required, as connection to home is with home AMF QC: Nokia: how to handle connection to two different network connections QC: yes, could have E//: security termination in home network not used DCM: BEST E//: not in phase 1 DCM: take long term view Orange: AMF would become slice specific QC: a paper submitted to this SA2 to do this Nokia: allowed is wrong word, seems like not trusted QC: could be, or not trusted Nokia: what is our trust model for phase 1, NOkias view is all tennants trust the operator, Orange: not talking about slices not operated by operators. QC: all slices could still be managed by operator, but comprimises should be contained E//: could we keep EPS-AKA with this agreement Orange: this is only about H-SEAF Nokia: so for this role, the H-SEAF is not needed (agreed) Nokia: E2.1.4.2 overlaps with Nokia 649 taken with 649 agreement: E.2.0.1.2 first sentence keep and 2nd sentence for this role home seaf is not needed (Nokia) after this use 649 on last interim agreement e.1.2.2.2 stays open with 908 e.2.0.1.2 2nd para is open for discussion: In addition if UE to UPF security is supported, then this will likely require an H-SEAF as the key from the home network may be used for this security, e.g., terminating UP security at HPLMN.	revised	No	S3‑170910
		S3‑170910	Proposed conclusion for standalone SEAF	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑170843
		S3‑170773	Trust model and key hierarchy discussion for Next Generation systems	Ericsson LM	discussion	Approval	Yes	YesNoamen presents QC: consequence of horizontal key derivation is running a SMC to refresh NAS security E//: yes, same with SEAF key noted	noted	No
		S3‑170778	Update of solution #1.36 for SEAF realization via AMF	Ericsson LM	pCR	Approval	Yes	Yes	not treated	No
		S3‑170839	pCR to provide an update to the solution #1.6 to specify the interface between SEAF and AMF	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑170685	A security solution for SMS over NAS	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170805	pCR to TR 33.899: Update of Solution #1.31	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170807	pCR to TR 33.899: Update of Solution #1.32	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170821	pCR to TR 33.899: Update of solution #1.30	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170637	Proposed interim agreement on integrity and confidentiality between UE and network for 5G phase 1	Nokia	pCR		Yes	Yeshis level of granularity of the negotiation was challenged, as the full impact of the decision on the ability of RAN to handle traffic. It was also questioned whether confidentiality shudl be applied across all bearers uniformally. There was also a discussion ion whether it makes sense for EN-DC UEs that support only option 3. QC: can't PDU sessions involve different types of data? E//: should be one PDU session for one type of flow, so it should be per flow Broadcom: should be on level per IP flow, so using granularity per PDU session doesn't make sense. E//: doesn't want to limit RAN in their decision DT: granularity not required to that extend, there is not sufficient gain Huawei: also has proposals Broadcom: UPF needs to support multiple access, do you assume buffer reordering in the UE side? Nokia: this is in RAN only E//: granularity for normative phase Samsung: open 792 on 792: E//: support integrity, consider Juniper: support integrity DCM: support TIM: support 792 is noted back to 637 agreement: DRB granularity goes away Huawei: related to 678 on 678 Nokia: already covered in 1.3 678 noted back to 637 Huawei: related to 700 on 700 E//: what is extendability VF: same problem Huawei: extend to the core E//: why is this brought up here, should be in different location TIM: not clear enough for wording 700 noted back to 637 Huawei: related to 679 on 679 Nokia: agree with that some CP messages need to be integrity protected VF: agree with Günther, change to next gen take 679, modify sentence except for a well defined list of procedures, remove Note merge into update of 637 back to 637 Huawei: related to 681 DCM: which places do not permit confidentiality on CP? VF: lots of places 681 noted back to 637 agreement e1412 not agreed e1312 optional for scenario 3 and mandatory for other --> offline Adrian, Alf, Guenther e1322 last sentence goes away e1512 take from 679 e1612 ok -- except for well defined exceptions	revised	No	S3‑170911
		S3‑170911	Proposed interim agreement on integrity and confidentiality between UE and network for 5G phase 1	Nokia	pCR	-	Yes	YesThis level of granularity of the negotiation was challenged, as the full impact of the decision on the ability of RAN to handle traffic. It was also questioned whether confidentiality should be applied across all bearers uniformally. There was also a discussion on whether it makes sense for EN-DC UEs that support only option 3.	approved	No		S3‑170637
		S3‑170677	Interim agreement for support of user plane integrity between UE and network	Huawei & Hisilicon	pCR		Yes	YesHuawei presents QC: could be useful for option 3 DCM: key hierarchy might not be ready in time, so key might not be ready E//: UE will NR anyways Nokia: difference should be minimized, maintain option to integrity protect DCM: mandate implementation QC: eNB doesn't have the information Nokia: UE will not be confused QC: why implement for option 3 Nokia: will there be option 3 only gNB and UEs, mandate except for option 3 only E//: for option 3 LTE doesn't support, so can be disabled DCM: mandate implementation from day 1	noted	No
		S3‑170792	Updates to Questions and Interim Agreements on Key Issue # 1.3: Support of User plane integrity between UE and network	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑170658	Update to KI on UP Integrity and requirements	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑170659	Solution for per DRB UP integrity	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑170678	Interim agreement for Support of UP confidentiality protection in the UE and the Network	Huawei & Hisilicon	pCR		Yes	YesThere was no support for this. It was noted.	noted	No
		S3‑170700	pCR for questions and interim agreement for UP confidentiality of Key issue 1.4	Huawei & Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑170638	Single NAS security termination - resolution of Editor’s Notes	Nokia	pCR		Yes	YesThe trust model that the SMF fully trusts the AMF was questioned. In particular whether the home operators would fully trust the serving operator. The issue of a lack of understanding of how a premuim rate slice may be used for fraud was raised. It was agreed to raise some questions of SA2 to try to understand the model. Gemalto: who has agreed to the trust model that all tenants shall trust the operator Nokia: SA2 has said there is only one AMF DCM: does this mean it is trusting the operator Nokia: it is only about session management, what is confidential there? QC: is it also when roaming? there is also integrity to be considered E//: support Nokia DCM: integrity is important, especially in case of premium rate sessions Nokia: will there be home SMF with visited AMF DCM: yes, via visited SMF	noted	No
		S3‑170639	Proposed interim agreements on NAS security termination for 5G phase 1	Nokia	pCR		Yes	YesNokia presents QC: at least for integrity, that should be separated E//: is there scenario where NAS messages are sent to home? QC: protect all the way to the home network TIM: is the termination in the RAN? Nokia: this is NAS Orange: why hop by hop is not enough QC: if premium session is negotiated, and then charge more for billing Orange: but there is trust due to roaming agreement DT: there is interoperator fraud existing Orange: involve GMSA fraud group DCM: yes, but what is response timein GSMA Nokia: ask SA2 DCM: business relationship questions NEC: support slice interim agreement discussion with SA2 Nokia: communication to home SMF should be discussed with SA2 QC: send LS to SA1 DT: approve this one wait for response to LS Huawei: is this for single slice or multiple slice case QC: both Huawei: in case of multiple slices, then don't agree with this Orange: what is use case Huawei: one slice compromise can't affect other slice DT: attack not applicable Huawei: compare to forward security in eNB handovers DCM: for phase 1, do single termination point, but prepare key hierarchy and a transparent container so there is no bidding down attack possible in phase 2 Huawei: depending on slicing issue Gemalto: need to take slicing into consideration for this QC: 2 separate issues: slicing isolation and integrity protection Gemalto: what is the definition of single termination point Nokia: AMF removes the protection, then hop by hop QC: other interpretation: do all UEs use the AMF? Huawei: issues themselves are independent QC: treat them separately, see if they converge Orange: DT proposal was to have a prelimary agreement, come back with threat analysis Huawei: if only for single slice, then ok back to agreement DCM: be clear: agreement can be changed if threats are shown agreement: agreed in principle, send LS to SA1, SA2, SA5, but keep open until network slicing LS: 912 Anand Ensure that the key hierarchy has the necessary hooks to potentially add keys for separate NAS security points in Phase 2 if needed so. Based on the response to LS S3-170XXX, SA3 may need to consider additional mitigations. These potential mitigations shall not modify the agreement in 639.	approved	No
		S3‑170912	LS on fraud potential in NAS to SMF	Qualcomm	LS out	Approval	Yes	YesQC presents Nokia: more difficult case is local breakout, so also include this BT: need to make choice: trust roaming partner, do we need to worry about fraud in general? E//: not related to NAS messages QC: correct, NAS terminates in visited SMF, so NAS can be removed DCM: integrity to home could entail changes in key hierarchy Nokia: signalling to home SMF (NAS or not) is undecided QC: acknowledge scenario by Nokia DCM: deal with fraud as it is important BT: ask GSMA about inter operator fraud scenarios Nokia: what is the braoder picture, how much is being lost E//: LS should help to agree if single termination for NAS or not? QC: agree, but need to check if this should be done QC: fraud is important, could be handled separately BT: threat predicated on assumption that roaming partners defraud each other offline QC presents approved	approved	No
		S3‑170679	Interim agreement for CP integrity protection	Huawei & Hisilicon	pCR		Yes	YesThis proposes an answer to CP integrity. It was agreed to make it clear that integirty is not applied in some document cases. Merged into S3-170911.	merged	No	S3‑170911
		S3‑170681	Interim agreement for CP confidentiality protection	Huawei & Hisilicon	pCR		Yes	Yes	noted	No
		S3‑170684	Clarification for solution #1.13	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170834	pCR: Solution for UE-UPF security setup	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑170840	pCR to provide an update to the Key Issue #1.5 to add NAS SM signalling protection	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑170698	pCR for question and interim agreement on key hierarchy	Huawei & Hisilicon	pCR	Approval	Yes	YesHuawei presents E//: too early to agree on key hierarchy, e.g. CK/IK not always there Huawei: but that applies to all type of agreements Nokia: this is very solution dependent Huawei: still some open issues DCM: don't understand the question, is the hierarchy or what kind of keys are required VF: question is what is the key hierarchy? DCM: or what are the required leaf keys? Nokia: prefer VF question agreement: agreements don't go in? VF: introduce question on how the keys are related, how do the keys translate to other 3GPP technology Nokia: E.1.7.0 related is incomplete, prefer to note document VF: prefer to note, because question is obvious noted	noted	No
		S3‑170699	pCR for updating the solution1.9	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170775	New key hierarchy proposal for Next Generation systems	Ericsson LM	pCR	Approval	Yes	YesEricsson presents Nokia: new key hierarchy proposals could wait. Stays open	noted	No
		S3‑170788	pCR to justify the need to extend the usage scope of PKI in 5G	China Mobile Com. Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑170640	Proposed interim agreement on integrity and confidentiality between AN and CN for 5G phase 1	Nokia	pCR		Yes	YesNokia presents TIM: finalize UP plane discussion first DCM: make it independent: when termination point is not in secure location and N3 is not physically secured agreement: sentence massaging taken together with 680 E1.9.1.2 agreed with wording update Nokia: how is it implemented, refer to 401? TIM: wait for the decision on UP termination point ->922 approved	revised	No	S3‑170922
		S3‑170922	Proposed interim agreement on integrity and confidentiality between AN and CN for 5G phase 1	Nokia	pCR	-	Yes	Yes	approved	No		S3‑170640
		S3‑170680	Interim agreement for AN-CN control plane	Huawei & Hisilicon	pCR		Yes	YesHuawei presents E//: formulation is confusing Huawei: this is related to RAN architecture Nokia: protocol split is confusing Huawei: change protocol split to N2 interface Chair: on separate level DCM: first agreement: change is used to supported, refer to NDS/IP instead TIM: make sentences consistent Nokia: other two agreements: split is still being discussed, so not do this for now Nokia: use implies support DT: not refer to 401, because it implies IPsec gateways DCM: certificate enrolment is independent of protocol split, Nokia: agree agreement: it is mandatory to support cert enrolment merged in 922	merged	No	S3‑170922
		S3‑170786	Resolution of ENs in solutions 1.23 and 1.24	Nokia	pCR		Yes	Yes	not treated	No
		S3‑170831	Proposed target architecture for 5G	Qualcomm Incorporated	other	Approval	Yes	YesQC presents VF: what are the two green lines QC: two different options for U-plane security Nokia: does this have to be added in phase 1? SA2 doesn't yet have a target architecture. noted QC: it is only the target security architecture. TIM: uplane security termination in UPF for phase 2 is not a good idea, some use cases would not be secure enough in phase 1, termination in RAN is not acceptable in phase 1 E//: service mobility why is this a security problem QC: UE may be allocated to different AMFs depending on requested NSSAIs Nokia: risk of putting too much complication on the security architecture Nokia: possible evolution scenario in 636	noted	No
		S3‑170641	Proposed interim agreement on integrity and confidentiality between CN and CN for 5G phase 1	Nokia	pCR		Yes	YesNokia presents E1.11 ok E1.12 TIM: does this also apply to N9 Nokia: yes TIM: maybe for N9 standardization is needed DCM: why would that be in issue TIM: just asking DCM on 1.11: would that preclude diameter security Nokia: no, could still be done in sec area 10 approved	approved	No
		S3‑170642	Proposed interim agreements on security implications of low latency	Nokia	pCR		Yes	YesNokia presents TIM: so in practice, SA3 is not doing anything to reduce latency Nokia: nothing dedicated to achieve lower latency, there have been no contributions TIM: should document why we don't do it Nokia: agree, there was no contribution from anyone Samsung: RAN considering 0ms latency handover VF: not aware of any requirements in phase 1 TIM: no feature has been studied E//: some RAN key issues on low latency have been studied, but nothing extra has been done BT: other issue: attacks that would relate to timing, by introducing higher latency E//: modify name of key issue agreement: change title E1.13.1.1 agreement: add sentence on use cases ->923 approved	revised	No	S3‑170923
		S3‑170923	Proposed interim agreements on security implications of low latency	Nokia	pCR	-	Yes	Yes	approved	No		S3‑170642
		S3‑170643	Proposed interim agreements on serving functions in a less secure location	Nokia	pCR		Yes	YesNokia presents TIM: wait for what SA2 will say IDCC: in virtualized environment, there is no perimeter and no secure location Nokia: operator should have the assurance of physical accessibility Huawei: SA2 considers local breakout, where UPF is in RAN BT: support partly both Nokia and IDCC QC: operator will control information ATT: danger of putting security requirements to service providers, not all service providers are trustworthy BT: state, in relation to NFV, the claim is based on current technology TIM: regardless of NFV, how is this in relation to local breakout DCM: control plane serving network functions Nokia: yes, and add BT's statement TIM: separate control and user plane? Gemalto: operator should be asked for security, so we should have requirement DT: BTs proposal would be good, this agreement is whether we will do something, in essence, we won#t do anything in phase 1 TIM: different from saying, in phase 1, local breakout doesn't exist, we need to start from the given scenario, or we have to say we don'T want it in phase 1 NTSC: in 23.502, SA2 is dealing with edge computing, e.g. mobility manamement, agreement: it is assumed, that in 5G phase 1, serving core control plane functions reside in a secure location based oncurrent technology.	revised	No	S3‑170924
		S3‑170924	Proposed interim agreements on serving functions in a less secure location	Nokia	pCR	-	Yes	YesNokia presents TIM: consider separately for control and user plane DT: don't limit to control plane Orange: agree TIM: not good, because of local breakout TIM: add sentence agreement for user plane function needs to be added DT: remove less in "less secure location" approved	approved	No		S3‑170643
		S3‑170644	Proposed interim agreement on user plane security termination for 5G phase 1	Nokia, Ericsson, Orange, AT&T, Broadcom, Samsung, Intel	pCR		Yes	YesNokia presents KPN: only acceptable if VF solution is selected in RAN VF: VF solution narrows down the solution DT: support KPN, RAN needs to define delay tolerant solution for CU-DU split VF same TNO: this is for PDCP-U TIM: not support this proposal to terminate BT: support KPN position, make note in TR that there is no security reason not to terminate in the RAN, therefore going for less secure decision for performance reasons Nokia: not fair summary, because CN function would sit in the same datacenter DCM: need to make sure this is predicated on RAN decision Huawei: agreements need to speak about phase 1 Nokia: ok offline discussion Nokia: propsoal 1.15.1.2 add sentence This assumes having a gNB split such that the CU resides in a physically secure location. TIM: in case of flexibility that is not true Nokia, agreed, but still sentence is ok QC: clarify that PDCP terminates security DCM: support this DT: make the dependency clear Orange keep reference to solution QC: yes, keep dependency DCM: remove the only TIM: add sentence what will happen if this approach is not confirmed by RAN Orange: then the whole interim agreement is gone DT: don't just say we assume, send LS to say we are ok with PDCP termination only if it terminates in secure location Orange: agree Nokia: wording QC: ensure PDCP is a termination point TIM: all of the interim agreement should be dependent on split being possible Nokia: prefer QC proposal, TIM: remove the reference to phase1 ATT: disagree on with TIM: keep phase 1 in Intel: agree with ATT KPN: if the agreement of E.1.15.1.2 is falls, then both the agreements of E.1.15.2.2 is revised agreed, TIM asks for this statement to be minuted if the precondition (i.e. CU-DU split can work) of E.1.15.1.2 is untrue, then both the agreements of E.1.15.1.2 and E.1.15.2.2 is revised Nokia: proposed a second sentence: solution should not preclude a second termination point in 5G phase 2 NEC: agreement TIM: what are the additional measures in phase 1 if RAN doesn't agree Nokia: formulation from QC, agreed by ATT and Intel TIM: the complete solution should be reconsidered DCM: PDCP security has to be there for EN-DC case ->943 approved LS to RAN2/3 -> 944, DT	revised	No	S3‑170943
		S3‑170943	Proposed interim agreement on user plane security termination for 5G phase 1	Nokia, Ericsson, Orange, AT&T, Broadcom, Samsung, Intel	pCR	-	Yes	Yes	approved	No		S3‑170644
		S3‑170825	Proposed conclusions on the termination points of user plane security in the 5G network	Qualcomm Incorporated	pCR	Approval	Yes	YesQC presents DCM: this decision needs to be made in phase 1 VF: what is the solution above PDCP QC: needs to be implemented directly above PDCP Nokia: why does this layer have to be put in in phase 1 if not used DCM: deployment would always require IPsec if there are UEs not supporting from the beginning, so decision is necessary for phase 1 Nokia: moving to CU DU will provide the benefit later QC: discussion needs to be on where is PDCP placed, do we need additional security layer Nokia: if the IPsec is deployed in phase 1, additional UEs wouldn't use the already deployed IPsec DT: this solution would work for any access network, even non-3GPP networks, e.g. fixed mobile convergence VF: need to convince SA2 QC: inline with SA2, keep PDCP security Orange: does this mean double encryption QC: select only one Orange: who selects QC: network selects Orange: problem with low latency QC: user selection Nokia: in phase 1 there will be untrusted non-3GPP access VF: does the new sec layer get skipped for low latency Noamen: new layer terminate in home in case of home routed KPN: there shouldn't be any change of latency VF: argument was about how traffic to be routed Orange: is this conflicting with RAN? QC: no, because PDCP encryption is there, this is only in addition to add flexibility Nokia: but there wouldn't be visibility QC: flow id is still visisble Orange: low latency use would force to disable E//: RAN said fine with proposal 1, so not argue about this QC: proposal 4 wouldn't be conflicting DCM: could be implemented on top CU DU, even if doesn't make sense, this is an alternative to CU DU on per flow basis Orange: what are the security benefits besides not requiring backhaul IPsec KPN: not trusting RAN, firewall it off, therefore CU-DU split wouldn't allow femtocells Nokia: so we have untrusted 3GPP access Chair: have PDCP TIM: postpone to RAN meeting, ATT: postponing got us where SA2 was delivering 6 months behind	noted	No
		S3‑170787	Flexible UP security termination	TELECOM ITALIA S.p.A., KPN, Telia Sonera	pCR	Approval	Yes	YesTIM presents VF: UP-STF in visited or home KPN: in visited Orange: additional scenarios, factory deployment would be completely separate from network deployment E//: ok with the solution going in, but not addressing RAN concerns, DCM: similar to VF proposal, UP sec layer moving to gNB and UPF like PDCP terminiation QC: more like QC solution, in QC this is implemented in two different layers TIM: statically configured DCM: per flow configuration? TIM: per flow Nokia: contradiction between TIM and QC solution, is there an additional layer in gNB required QC: in QC solution not required Nokia: on proposal Orange: first req: reword, second requirement remove RAN and UPF, 3 and 4 should go away E//: ok with Orange proposals Nokia: remove also second proposal TIM: statically was to avoid negotiation DCM: then defined by network operator Orange: threat: first: LTE RAN, remove second TIM: second is true Orange: deployment option, so not a threat Orange: 3rd should go out DCM: valid threat, CU-DU split could be considered as hardening Orange: what is fourth TIM: assume user is not using ott security DCM: change sentence, to say assume, delete first part ->942 approved	revised	No	S3‑170942
		S3‑170942	Flexible UP security termination	TELECOM ITALIA S.p.A., KPN, Telia Sonera	pCR	Approval	Yes	Yes	approved	No		S3‑170787
		S3‑170867	discussion on flexible UP termination point	VODAFONE Group Plc	discussion	Information	Yes	YesDT: what is the state of discussion in RAN on this proposal VF: PDCP split still unclear E//: VF is still in line with RAN terminating security noted	noted	No
		S3‑170610	Key hierarchy when using UPSF	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑170697
		S3‑170697	Key hierarchy when using UP security function	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No		S3‑170610
		S3‑170785	pCR to 33.899 - Addition of solution to KI#1.15 UP Termination Point	VODAFONE Group Plc	pCR	Approval	Yes	YesVF presents Nokia: 785 is only about dual connecitvity with core network as EPC, so no general solution VF: correct, but can be applied to 5G core Nokia: not visible from tdoc Nokia: still allows CU-DU split Juniper: will it be generalized no approved	approved	No
		S3‑170779	Discussion on the feasibility of the support and negotiation of a PDU Session-specific security features	Ericsson LM	discussion	Approval	Yes	Yes	not treated	No
		S3‑170780	Questions and interim agreements on the granularity of the UP protection negotiation	Ericsson LM	pCR	Approval	Yes	YesE// propose to note	noted	No
		S3‑170781	Solution for a PDU session-specific security negotiation	Ericsson LM	pCR	Approval	Yes	Yes	not treated	No
		S3‑170701	pCR for questions and interim agreement for key issue 1.17	Huawei & Hisilicon	pCR	Approval	Yes	YesHuawei presents VF: what is on demand security Huawei: key issue 1.17, sometimes certain security mechanisms are required, sometimes not, eg secondary auth Orange: what is meant by secondary authentication VF: not clear where policies are coming from Huawei: control plane: auth methods Orange: should be about user plane according to key issue Huawei: if are there problems with key issue the bring papers to fix those VF: ??? Orange: this is on security to UPF, which is ruled out DCM: against on demand for control plane BT: is phase 1, rewording is required with it is suggested QC: do we need a separate interface if there is an interface already agreed Orange: not ready to agree on this, visitor control needs to stay TIM: why is control plane there Huawei: control plane can be deleted offline	noted	No
		S3‑170683	Clarification for KDF negotiation	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170645	Proposed interim agreements on untrusted and trusted non-3GPP access	Nokia	pCR		Yes	YesNokia presents DCM: numbering needs fixing, agree all but E.1.19.1.2 right now VF: agree with DCM QC: agree that solution will based on these 5 contributions TIM: see final document to close Nokia: 663 is the solution, others are giving call flows Broadcom: agree with what is currently proposed, but there may be an LS from SA2, some proposals send the NAS directly, some have N3IWF construct it. VF: approve without interim agreement, chair: try to combine at this meeting 663, 665, 682, 835 ->945	revised	No	S3‑170945
		S3‑170945	Proposed interim agreements on untrusted and trusted non-3GPP access	Nokia	pCR	-	Yes	YesNokia presents Nokia: merger has not yet happened, so refer to tdocs, put in EN that this will be fixed in the next meeting TIM: then don't put anything in the agreement DCM: put agreement into minutes chair: should be in TR ok approved with EN	approved	No		S3‑170645
		S3‑170663	Updates to n3gpp solution detail	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑170664	n3gpp initial attach and authentication	Nokia, Intel, Broadcom, Motorola Mobility, Lenova	pCR	Approval	Yes	Yes	not treated	No
		S3‑170665	Subsequent access over untrusted n3gpp	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑170682	Reuse anchor key for fasting untrusted non-3GPP access	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170835	pCR to update solution #1.26 to include a call flow for untrusted non-3GPP access	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑170626	Background to proposed handling of LS on middlebox security from ETSI TC CYBER	Home Office	discussion	Discussion	Yes	Yes	not treated	No
		S3‑170627	Introduction of new Key Issue in response to work in ETSI TC CYBER on middlebox security	Home Office	pCR	Approval	Yes	Yes	not treated	No
		S3‑170628	Introduction of new Solution in response to LS IN from ETSI TC CYBER	Home Office	pCR	Approval	Yes	Yes	not treated	No
		S3‑170630	Draft reply to LS from TC CYBER on middlebox security	Home Office	LS out	Approval	Yes	Yes	not treated	No
		S3‑170944	LS on security termination for the User Plane in 5G	Deutsche Telekom	LS out	Approval	Yes	Yes	approved	No
		S3‑170901	Questions for SA2 joint meeting	WG Chair	discussion	Endorsement	Yes	YesQuestions are discussed. The questions(that were sent on the e-mail) were modified slightly to improve the phrasing, but kept esssentially the same meaning, except the last one which was deleted. It was approved.	endorsed	No
5.1.2	Authentication	S3‑170646	Overview of proposed interim agreements on authentication for 5G phase 1	Nokia	pCR		Yes	YesNokia presented the document which is an overview of the Nokia proposed conclusions for the authentication security area. It was noted.	noted	No
		S3‑170686	pCR Update question E2.1.1 for key issue 2.1 Authentication Framework	Huawei & Hisilicon	pCR		Yes	Yes	merged	No	S3‑170947
		S3‑170651	Proposed interim agreement on SEAF in the home network for 5G phase 1	Nokia	pCR		Yes	YesNokia presents QC: is this not already agreed in 843? Nokia: first sentence not covered VF: unbalancing of visited and home network Nokia: mention roaming explicitly? QC: outstanding issue: RAN reply for UP security termination, protection of SM messages Orange: no agreement for User plane security termination in home QC: depending on RAN CU-DU split, DCM: keep in mind key hierarchy aspects Nokia: no need for security to home network, e.g. for LI purpose E//: support Nokia BT: agree with Nokia Orange: support Nokia DCM: ok with phase 1, BEST like key comes automatic with h-SEAF, but consider bidding down for future phases Nokia: solution should not preclude a h-SEAF in phase 2 QC: also consider RAN result VF: apllies to everything, they are interim agreements, not put into the TS QC: so if a functionality proposal comes which requires a h-SEAF, this shouldn't be ruled out -> 946	revised	No	S3‑170946
		S3‑170946	Proposed interim agreement on SEAF in the home network for 5G phase 1	Nokia	pCR	-	Yes	Yes	approved	No		S3‑170651
		S3‑170622	pCR to Question No. 1 Key issue 2.1	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170623	MASA primary authentication	Huawei & Hisilicon	pCR		Yes	Yes	noted	No
		S3‑170648	Proposed interim agreement on support for AKA variants for 5G phase 1	Nokia, Verizon UK Ltd	pCR		Yes	YesNokia presents VF: not have shall support for network Nokia: at least one needs to be supported by network, requirement is on AUSF ZTE: too early to only consider these two AKA variations, consider also other solutions, disagree second sentence, first is ok Nokia: this is an at least, so doesn't rule out others ZTE: these seem to have more priority, so add e.g. Nokia: mandate support, especailly for this auth. method E//: have contribution with different wording for same thing, need to decide at this meeting E//: on second sentence on choice of optimization: should be based on EAP, not support EPS AKA Huawei: comments in 927, with this proposal there are two AKA based variants, good: agree all methods at once, Huawei is proposing EAP MASA. VF: not only use EAP, also use 4G protocols Nokia: comment is not on EAP method, but on use of EAP in general (a different paper) Nokia: EAP AKA', then choose an optimization QC: EAP AKA' doesn't rule IMSI privacy solution Nokia: correct QC: how can EAP AKA* over untrusted non 3GPP access? Nokia: no, can't be fix formulation Broadcom: EAP solves the roundtrip problem by FILS VF: change question: where the EAP protocol is supported, ... taken together with ...,623, 813, VF: not ready to go to EAP completely Orange: prefer to keep some EPS, structure discussion DCM: would EAP over the air be a problem Nokia: EAP over NAS shouldn't be a problem VF: EAP as transport over the air Orange: EPS AKA and EAP AKA'/* CMCC: same DCM: is it about transport or method being used Orange: both DT: for NR with 4G core, then EPS, for 5G core different discussion VF: don't want to be trapped in EAP only Nokia: how to carry EPS AKA over NR, transport question goes away, and vice versa, so more can't be concluded from transport question. Operator question Orange: prefer to have the option to do both, home network needs to choose DCM: if home network chooses one, visited chooses the other, then can there be compatibility issues Nokia: vendors need to support both anyways Broadcom: there might be an issue with fixed operators KPN: settling on EAP only, so what is the problem? Orange: EPS AKA created and maintained by 3GPP E//: vendor specific EAP methods are allowed, so no problem Huawei: EPS AKA* has problem QC: ok with supporting EPS AKA* and EAP AKA' DT: ok with EAP only as well as with both VF: in line with Orange TIM: EPS AKA* would only be applicable to 3GPP access, EAP AKA' is applicable to both? E//: yes TIM: what is the benefit of supporting both, if one could be applied to both accesses Orange: to give operators choice Gemalto: if an operator implements EPS version in the 5G core, he will also need to implement the other version? E//: serving network will need to support both, but home only needs one TIM: because all networks can be visited, then all networks need to implement both Nokia: but only AMF/SEAF would be impacted in visited DCM: what is the impact on home network VF: there will be some translation in the visited network, and should stay with existing UICC Gemalto: new UICC could be mandated TIM: that is unrealistic Huawei: there is an open issue in EPS AKA*, so that needs to be looked at, iterim agreement	revised	No	S3‑170947
		S3‑170947	Proposed interim agreement on support for AKA variants for 5G phase 1	Nokia, Verizon UK Ltd	pCR	-	Yes	YesNokia presents Huawei: 686 adds EAP-MASA in the list, support EAP-AKA', not EPS-AKA* Huawei object to EPS-AKA, for primary authentication over 5G NR acceess for the reasons described in S3-170927 E//: Ericsson doesn't support EPS AKA merge 686 with this Orange: 5G UE and the serving network shall support EPS AKA DCM: new discussion TIM: include note EPS AKA support for backward compatibility Huawei: why the home network doesn't have to support EPS AKA* Orange: would is supporting VF also supporting QC: the agreement shouldn't preclude to support anchor keys QC: should still comply with all other interim agreements Nokia: this is a general requirement for all the agreements QC: This agreement should not conflict with other requirements, especially the key hierarchy	approved	No		S3‑170648
		S3‑170871	Comments on Nokia “Proposed interim agreement on support for AKA variants for 5G”	Huawei, Hisilicon	pCR		Yes	YesHuawei presents Nokia: MASA doesn't do the optimization of EPS AKA* / EAP AKA* Huawei: MASA only has one round trip Orange: delivery of serving network public key is part of solution Huawei: doesn't have to be done Orange: do we need the public key? Huawei: not necessary Nokia: MASA is not just a variant of EPS AKA, because different infrastructure is required DT: where is the added benefit if MASA is only used in initial authentication	noted	No
		S3‑170927	Comments on Nokia “Proposed interim agreement on support for AKA variants for 5G”	Huawei,HiSilicon	other	Agreement	Yes	YesNoted without presentation because submitted too late, instead 871 was treated	noted	No
		S3‑170813	Proposed agreement for support of EAP-AKA for primary authentication	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑170947
		S3‑170647	Proposed interim agreement on EAP framework for 5G phase 1	Nokia	pCR		Yes	YesNokia presents treated together with 687 and 844 on 647 Orange: should say EPA AKA' only Nokia: that was not agreed so far Huawei: agree with Nokia VF: word the sentence positively, not double negatively DT: the previous decision allowed for the home network to only support EPS VF: the quesiton doesn't differentiate the serving and the home part Huawei: no reason to mention EPS AKA* QC: first sentence is agreeable, second sentence is a problem Orange: had DT comment on first sentence QC: EPS AKA' is the only non-EAP method to be supported in 5G Nokia: is always possible that the operator only buys part of the features DT: problem with non-standard always exists DCM: problem especially on roaming interface Nokia: it is all under home network control Orange: decision is taken already, so this can be deleted Heiko: agree Tim: separate out the serving and home network Orange: only serving network part needs to be in Nokia: add in 647 5G UE and 5G serving network DCM: this makes home network control serving network ATT: seems weird Nokia: ottherwise there is no serving network EAP method control 647->948 approved on 687 Huawei spelling taken care of in 891 noted on 844 noted	revised	No	S3‑170948
		S3‑170948	Proposed interim agreement on EAP framework for 5G phase 1	Nokia	pCR	-	Yes	YesNokia presents VF: not have shall support for network Nokia: at least one needs to be supported by network, requirement is on AUSF ZTE: too early to only consider these two AKA variations, consider also other solutions, disagree second sentence, first is ok Nokia: this is an at least, so doesn't rule out others ZTE: these seem to have more priority, so add e.g. Nokia: mandate support, especailly for this auth. method E//: have contribution with different wording for same thing, need to decide at this meeting E//: on second sentence on choice of optimization: should be based on EAP, not support EPS AKA Huawei: comments in 927, with this proposal there are two AKA based variants, good: agree all methods at once, Huawei is proposing EAP MASA. VF: not only use EAP, also use 4G protocols Nokia: comment is not on EAP method, but on use of EAP in general (a different paper) Nokia: EAP AKA', then choose an optimization QC: EAP AKA' doesn't rule IMSI privacy solution Nokia: correct QC: how can EAP AKA* over untrusted non 3GPP access? Nokia: no, can't be fix formulation Broadcom: EAP solves the roundtrip problem by FILS VF: change question: where the EAP protocol is supported, ... taken together with ...,623, 813, VF: not ready to go to EAP completely Orange: prefer to keep some EPS, structure discussion DCM: would EAP over the air be a problem Nokia: EAP over NAS shouldn't be a problem VF: EAP as transport over the air Orange: EPS AKA and EAP AKA'/* CMCC: same DCM: is it about transport or method being used Orange: both DT: for NR with 4G core, then EPS, for 5G core different discussion VF: don't want to be trapped in EAP only Nokia: how to carry EPS AKA over NR, transport question goes away, and vice versa, so more can't be concluded from transport question. Operator question Orange: prefer to have the option to do both, home network needs to choose DCM: if home network chooses one, visited chooses the other, then can there be compatibility issues Nokia: vendors need to support both anyways Broadcom: there might be an issue with fixed operators KPN: settling on EAP only, so what is the problem? Orange: EPS AKA created and maintained by 3GPP E//: vendor specific EAP methods are allowed, so no problem Huawei: EPS AKA* has problem QC: ok with supporting EPS AKA* and EAP AKA' DT: ok with EAP only as well as with both VF: in line with Orange TIM: EPS AKA* would only be applicable to 3GPP access, EAP AKA' is applicable to both? E//: yes TIM: what is the benefit of supporting both, if one could be applied to both accesses Orange: to give operators choice Gemalto: if an operator implements EPS version in the 5G core, he will also need to implement the other version? E//: serving network will need to support both, but home only needs one TIM: because all networks can be visited, then all networks need to implement both Nokia: but only AMF/SEAF would be impacted in visited DCM: what is the impact on home network VF: there will be some translation in the visited network, and should stay with existing UICC Gemalto: new UICC could be mandated TIM: that is unrealistic Huawei: there is an open issue in EPS AKA*, so that needs to be looked at, iterim agreement	approved	No		S3‑170647
		S3‑170687	Interim agreement for EAP framework for primary authentication	Huawei & Hisilicon	pCR		Yes	Yeskept open and then noted - see discussion of 813	noted	No
		S3‑170844	Proposed conclusion for EAP support in 5G System	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑170709	Interim Agreement for non-AKA Authentication-for-Primary-Authentication-EAP-TLS	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yestreated together with 719, 864 Huawei presents Orange: does SA1 explicitely request an alternative to AKA? TIM: does this speak about primary authentication? E//: 891 deals with this as well on 891 (revision of 864) E// presents on 925 (revision of 719) Huawei presents Orange: support should stay optional, needs to be stated this is for private networks E//: not completely agrees, also for isolated networks VF: requirement is IoT only, prefer not to have standardized methods Oberthur: intensively discussed in SA1, result: only IoT in isolated private network, no PLMN interaction KPN: agree with VF, prefer to exclude a list of options E//: benefit of standardizing at least one method to avoid market fragmentation Orange: to support all possible industries, with their different credentials and protocols, don't specify anything here Broadcom: no need to limit use cases, make it optional Gemalto: not limited for type of authentication, so not specify Huawei: also useful for operator use cases, but optional to use and implement TIM: SA1 requirements are restricted, but this isn't CMCC: support standardization psk and tls QC: shouldn't be madatory, benefit in standardizing one method DCM: what needs to be standardized E//: privacy and network binding as examples DT: just describe one method like TLS VF: can this be pushed to phase 2? Orange: what should we select Nokia: understand the problems of DT and Orange, but wants to have annex how IMSI privacy and SN authentication is addressed Huawei: worries are unneccessary Orange: put this in phase 2 Huawei: object BT: put informative annex in the back of TS Orange: capture this agreement: there will be an informative annex outlining how one of the methods can be implemented, with informative example, and also information what will be the use cases TIM: cases restricted to specific use cases, primary auth, private networks CMCC: also IoT use case BT: it is only informative TIM: content of informative annex has one sentence on use cases Gemalto: for the reader, such a rationale is required 891 is revised as draft. to capture agrement and EAP AKA'	revised	No	S3‑170900
		S3‑170900	Interim Agreement for non-AKA Authentication-for-Primary-Authentication-EAP-TLS	Huawei, Hisilicon, China Mobile	pCR	Approval	No	Yes	noted	No		S3‑170709
		S3‑170719	Interim Agreement for non-AKA Authentication-for-Primary-Authentication-EAP-PSK	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	revised	No	S3‑170925
		S3‑170925	Interim Agreement for non-AKA Authentication-for-Primary-Authentication-EAP-PSK	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	noted	No		S3‑170719
		S3‑170864	Proposed agreement for the choice of EAP methods	Ericsson, Nokia, Samsung	pCR	Approval	Yes	Yes	revised	No	S3‑170891
		S3‑170891	Proposed agreement for the choice of EAP methods	Ericsson, Nokia, Samsung	pCR	Approval	Yes	YesE// presents VF: remove example Orange: describe only EAP TLS in rest of paragraph, add for isolated deployment Huawei: IoT devices for factory automation, described in SA1 Orange: put like in SA1 requirement Oberthur: for network without interaction with public network BT: an additional method was described in an informative annex, but which one is up for companies to decide Orange: put explicit reference to SA1 TIM: the informative annex is in the TS? BT: it is suggested the companies interested in specifying the additional method agree in advance to the meeting which method will be proposed agreed: the companies interested in specifying the additional method agree in advance to the meeting which method will be proposed	approved	No		S3‑170864
		S3‑170649	Proposed interim agreement on anchor key for 5G phase 1	Nokia	pCR		Yes	YesNokia presents QC: is this also covering roaming in non-3GPP network with home N3IWF Nokia: yes, serving network is identical with home network. QC: not obvious from text Nokia: Note on that QC: Note: serving network can also be the home network agreement: Note certain cases serving netwokr can be home network discussed offline	revised	No	S3‑170909
		S3‑170909	Proposed interim agreement on anchor key for 5G phase 1	Nokia	pCR	-	Yes	Yes	approved	No		S3‑170649
		S3‑170650	Proposed interim agreement on secondary authentication for 5G phase 1	Nokia	pCR		Yes	YesNokia presents Nokia: fix typo, refer to solution in 745 QC: normative work will be based on the solution in 745 agreement: add sentence: the normative work will be based on the solution in S3-170745 -> 921 approved	revised	No	S3‑170921
		S3‑170921	Proposed interim agreement on secondary authentication for 5G phase 1	Nokia	pCR	-	Yes	Yes	approved	No		S3‑170650
		S3‑170702	pCR for question and interim agreement on secondary authentication	Huawei & Hisilicon	pCR	Approval	Yes	YesHuawei presents DT: shall to might is a big change, why do binding? Nokia: only external data network needs to be supported, reject the document DT: reject the shall - might change Nokia: same view Huawei: doesn't see why shall be transparent to 3GPP operator Orange: stay with what we have in LTE BT: delete the bit about the transparency, shall be run independent of primary auth Nokia: against slice access auth E//: because shall stays, so no binding is possible TIM: same understanding, so note contribution noted	noted	No
		S3‑170608	EPS Authentication with hiding keys assisted by UE - EPS AKA+	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No		S3‑170074
		S3‑170744	Removing ENs in Section 2.26 - EAP based secondary authentication	Nokia France	pCR	Approval	Yes	Yes	not treated	No
		S3‑170745	Merge of EAP based Secondary authentication proposals	Nokia, Ericsson, Qualcomm	pCR	Approval	Yes	Yes	approved	No
		S3‑170749	EAP based secondary authentication with an external authenticator	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑170612	MASA handling Privacy & LI requirements in all scenarios	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170613	MASA Update	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170614	MASA support 4G USIM Update	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170615	MASA handling out of sequence scenario	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170616	MASA Modular Approach	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170617	MASA response to Evaluation#2	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170621	MASA crypto analysis conclusion	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170689	A question for KI #2.2	Huawei & Hisilicon	pCR		Yes	YesHuawei presents DCM: usage is unclear, unclear where it is supposed to be used Nokia: should be in KI 2.2. and 3.1, unclear where exactly this is used, propose to rule out DH for every connection and keep the rest open Orange: leave open VF: strong supporter of DH to HSS, not so strong about to other cases CMCC: support this contribution, DH to visited network DCM: decision needs to be done early Nokia: DH to RAN needs early decision, to HSS can be modularized Huawei: two different problems Orange: be very specific Huawei: should be general question first Orange: but not if people understand different issues offline E//: there are other solutions with DH IDCC: question is too specific to solution, break down to two, first: whether to support secret key leakage, second how to support, solution shouldn't be solution specifc Nokia: prefer to spell out the trade off by including the solution Orange: does this have to be in phase 1 VF: support this strongly, even possible backport to LTE and 3G, 2G QC: ??? Orange: prefer a new study item, not include this is 5G VF willing to bring a WID Nokia: with WID, this is only necessary for interaction with serving network, too costly for interaction with visited network Orange: support Nokia DT: not put this away so quickly DCM: also not make this decision now QC: agree on question now Orange: be specific Nokia: see VF WID, then formulate question DT: WID will be about key update, so discuss the serving network question Nokia: WID or SID? Orange: SID more appropriate focus on the question in 949, no agreement in this meeting -> 949	revised	No	S3‑170949
		S3‑170949	A question for KI #2.2	Huawei & Hisilicon	pCR	-	Yes	Yes	approved	No		S3‑170689
		S3‑170842	Further details on bidding down attack risk for EIAuth Key Issue	Qualcomm Incorporated	other	Approval	Yes	YesQC presents DCM: doesn't seem to be a bidding down issue, what is the security risk QC: then it is not possible to netork operator can't enforce device authentication across all Ues Orange: maybe considered a missing feature, no security rik, so not necessary in phase 1 Nokia: also doesn't see problem, no bidding down risk when UE lies about its phase, lying UE simply would be reclassed as lower phase, not necessary for phase 1, not required for eMBB use case QC: MFF LS said they wanted this feature VF: IMEI cloning was an issue, for system on chip UICC identity is device identity, how is IMEI privacy related to authentication QC: acknowledge IMEI cloning, can be addressed with non-removable UICC, but for eMBB UICC is removable, IMEI privacy issue is not clear VF: if IMEI is encrypted, then authentication is implicit DT: not necessary in phase 1 Nokia: not required in phase 1 because bidding down argument is not required Orange: support DT not for phase 1 noted	noted	No
		S3‑170708	Add evaluation for solution non-AKA Authentication-basedon IBS	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170704	pCR for question and Interim agreement for securing the interface between NextGen network and 3rd party service provider for key issue #2.9	Huawei & Hisilicon	pCR	Approval	Yes	YesHuawei presents Nokia: disagree with slice seocndary auth, security on interface already in CN-CN control plane agreement Orange: secondary slice authentication not relevant Huawei: would make this more important E//: wait for SA2 to decide on existence of this interface Nokia: what is the interface Huawei: to UPF or SMF Nokia: no difference to UPF, there is no interface between SMF and data network TIM: title and text are relating to other clauses are not aligned E.2.9.0 not acceptable E.2.9.1.1 Nokia: replace authentication related function be UPF Huawei: ok Nokia: it is EAP messages which are self securing, except for EAP CHAP/PAP Orange: don't want to secure just because external network is weak, disagree with question TIM: why do we care about secondary authentication QC: authentication is required kept open	revised	No	S3‑170965
		S3‑170965	pCR for question and Interim agreement for securing the interface between NextGen network and 3rd party service provider for key issue #2.9	Huawei & Hisilicon	pCR	Approval	Yes	YesE//: includes new threats Orange: remove content of 2.9.0, for authentication to external DN Nokia: this is on key issue 2.10 is only related to secondary authentication to network slice access, but that doesn't apply any more, the problem needs to be addressed, but at next meeting 965 noted	noted	No		S3‑170704
		S3‑170690	pCR for adding an alternative option in solution2.13	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170703	pCR for Editorial update of solution 2.13	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170618	MASA IMSI Privacy solution	Huawei & Hisilicon	pCR		No	No	withdrawn	Yes
5.1.3	Security context and key management	S3‑170841	NAS security contexts for N1	Qualcomm Incorporated	other	Approval	Yes	Yes	not treated	No
		S3‑170717	Question and Interim Agreement for Key Sharing Among Different Access Technology	Huawei & Hisilicon	pCR	Approval	Yes	YesThe term key sharing was not clear - it should say something like using the anchor key to derive keys for 3GPP and non-3GPP access. It was challenged whether the agreement in S3-170909 covered this text. QC: key sharing is that only anchor key, or sharing access network key? Huawei: yes QC: then it is agreed already VF: will there be similar level of security Nokia: this is not needed any more E//: related to EAP re-authentication QC: not necessarily EAP E//: anchor concept is sufficient VF: shared keys need to be in secure locations, otherwise they have to be derived DCM: what is the difference to anchor key concept Huawei: can anchor key be used for re-auth? DCM: yes. Noted	noted	No
		S3‑170720	Key Issue Update #3.4 Security Context Sharing	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170710	Add Evaluation to Solution #3.3	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170718	Solution Update #3.2 Security Context Sharing	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170692	Add Security threats of key issue #3.3	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170611	Hiding keys exchanged between serving network nodes	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑170711	Add Evaluation to Solution #3.1	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170691	Update Solution 3.8 and resolve ENs	Huawei & Hisilicon	pCR		Yes	No	withdrawn	Yes
5.1.4	RAN security	S3‑170827	Proposed inputs to the security algorithms at PDCP layer	Qualcomm Incorporated	pCR	Approval	Yes	YesQC presents Nokia: agre only for option 3, could change for option 4 and 4a QC: send to RAN2 Nokia: are proposing different key derivations for different DRBs QC: can still have different keys, then bearer ID will be redundant Nokia: can be made more clear Nokia: integrity takes the integrity key QC: yes, change the text accordingly E//: message needs to be included when doing integrity, reference to time is strange, QC: copy from 401, but ok Huawei: is this only for enB and gNB QC: for option 3 only, not much time, no new algorithms need to be defined QC: include this part of question to RAN2 in LS 951 to RAN2, focus the question to RAN2 ok QC: can this be taken as working assumption ok Nokia: this needs to be clarified that this is for option 3 only, Nokia: check with RAN if this could also be applied to cases beyond option 3 ->954	revised	No	S3‑170954
		S3‑170954	Proposed inputs to the security algorithms at PDCP layer	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑170827
		S3‑170662	Avoid IMSI Paging	Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑170741	Resolving Editors Notes in Security requirements on gNB Potential security requirements	Huawei, Hisilicon	pCR		Yes	Yes	noted	No
		S3‑170926	Resolving Editors Notes in Security requirements on gNB Potential security requirements	Huawei, Hisilicon	pCR	-	No	No	withdrawn	Yes
		S3‑170732	Conclusion and interim agreements for KI #4.1	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑170885
		S3‑170885	Conclusion and interim agreements for KI #4.1	Ericsson	pCR	Approval	Yes	YesE// presents 885 VF: is this related to IMSI catching with WIFI Nokia: key issue is different Intel: first paragraph refers 4.8, this doesn't support idle mode QC: E.x.a.1.2: is that relating to other 3GPP working groups Nokia: 3GPP QC: add this Nokia: ok QC: if proven useful is not an agreement Nokia: Ue should log measurements, and how it can be derived QC: would it be better not to have an interim agreement? Nokia: propose to send an LS to RAN2/RAN4 asking for details, no agreement on that yet Huawei: agree with waiting for another cycle DCM: privacy implication like in MDT E//: not valid concern DCM: without agreement contribution is ok E//: there is a mechanism for detection -> remove agreements in 885	approved	No		S3‑170732
		S3‑170876	Nokia comments on S3-170732-conclusion and agreements_RAN_#4.1	Nokia	pCR	Approval	Yes	Yes	noted	No
		S3‑170795	Questions and Interim Agreements on Key Issue # 4.1: AS security during RRC idle mode	Samsung	pCR	Approval	Yes	Yes	merged	No	S3‑170885
		S3‑170818	Adding question on RRC integrity protection in RRC idle	KPN	pCR		Yes	Yes	noted	No
		S3‑170633	Comparison of Solution proposals to determine authenticity of the cell in idle mode	Intel Corporation (UK) Ltd	discussion		Yes	Yes	not treated	No
		S3‑170875	Nokia comments on S3-170633 fakegnb-comp-04	Nokia	discussion	Discussion	Yes	Yes	not treated	No
		S3‑170793	Resolving Editor’s notes in Solution #4.2	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑170794	Evaluation of Solution #4.2	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑170729	Requirements on gNB	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170660	Discussion on R2 LS on NR Dual Connectivity	Nokia	discussion		Yes	YesNokia presents QC: has contribution along 830 those line, conclusion should be different on NR security algorithms E//: introducing RRC might introduce new threats, needs to be studied Huawei: support E//, need to figure out what RRC is needed for QC: in case of LS back, ask for what RRC procedures are supported by SgNB agreement: that should be asked open	noted	No
		S3‑170694	Questions for security of EN-DC	Huawei & Hisilicon	pCR		Yes	YesQC: general process, take results on draft CR not in interim agreements Chair: where to put those decisions with 5G core impact QC: capture those in the TR as well Nokia: CR against what? QC: CR against 33.401 Huawei: first capture EN-DC in TR QC: already have conclusions on some questions, may have to be revised DCM: prefer to move to draft CR, but is it ready for this meeting chair: capture in TR if agreement is on ENDC or 5G in general, put those into draft CR to see how it would look like, draft CR is living document Huawei: can be noted	noted	No
		S3‑170830	Updates to solution 4.12 and the related conclusions	Qualcomm Incorporated	pCR	Approval	Yes	YesQC presents Nokia: why can EN be deleted QC: EN can be deleted, as all options in RAN impact in eNB E//: ok, but keep two aspects open and ask RAN2: is it ok to assume to derive the keys from the S_KNB, get a list of procedures to be supported by these bearers, try to investigate to not use these bearers to request the UE capabilities; in line with Huawei interim agreement QC: ok to ask procedures, othe question fine as well, important: avoid impact on MME agreement: LS to RAN2, include CT1 to ask about MME impact Nokia: if RRC is only for control of DRBs to SgNB, how is that impacting MME? E//: sending NR UE capabilities should not have impact to MME, ask this to CT1 Nokia: ok E//: also introducing a new variant, could be merged chair: any specific comments on solution Nokia: should the key be called differently QC: using the same derivation, so could be called the same Nokia: preference to call SGNB key offline chair: conclusions: what is agreed E//: merge offlne, ed note comes back with CT1 in it -> 950	revised	No	S3‑170950
		S3‑170950	Updates to solution 4.12 and the related conclusions	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑170830
		S3‑170661	Update to DC solution based on offload counter	Nokia	pCR	Approval	Yes	YesNokia presents E//: EN to say it is ffs whether to add RRC functions will introduce new security problems QC: this applies to other options, e.g. 7, as well ->952 approved	revised	No	S3‑170952
		S3‑170952	Update to DC solution based on offload counter	Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑170661
		S3‑170693	Security capability negotiation for SCG bearer and SCG split bearer in EN-DC	Huawei & Hisilicon	pCR		Yes	YesHuawei presents QC: if the eNB is a legacy eNB, then it may not understand the new IE, and if then there is subsequent handovers between eNBs, would the context be available in eNB that does ENDC Nokia: split figure DCM: problem is between 5 and 6 QC: EN between 5 and 6 Huawei: this is another solution Nokia: NR context shouldn't be lost on handovers E//: QC/DCM scenario is valid, this is EN, then ask in LS Nokia: ok agreement: EN between 5 and 6 -> merge with 950	merged	No	S3‑170950
		S3‑170731	Solution on Dual Connectivity	Ericsson	pCR	Approval	Yes	YesE// presents -> merge with 950	merged	No	S3‑170950
		S3‑170951	Reply LS on security in E-UTRA-NR Dual Connectivit	Ericsson	LS out	Approval	Yes	Yesresponse in 951 based on EN DC discussion To RAN2 and CT1 E// presents Nokia: want set of RRC procedures, rather than control functions, in order to understand the threat model QC: need to revise second paragraph, didn't agree on variant 2 E//: change sentence accordingly DCM: be more clear which kind of feedback E//: list of RRC procedures Nokia: refer to 950 QC: add in phase 1, make clear there are 2 variants, feedback from CT 1 is only on variant 2 QC: should we ask for teh PDCP algorithm inputs? ok approved	approved	No
		S3‑170829	Some proposed text for supporting Option 3	Qualcomm Incorporated	other	Discussion	Yes	Yes	noted	No
		S3‑170695	Add a NOTE to KI4.4 and KI4.7	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170739	Mobility in RRC_inactive state	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170738	Key handling in RRC inactive to connected	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170740	Backward security for RRC inactive state to RRC active state	Huawei, Hisilicone	pCR		Yes	Yes	not treated	No
		S3‑170733	Questions and interim agreements for KI #4.10	Ericsson	pCR	Approval	Yes	YesE// should be presented QC: does this include user plane? E//: yes DCM: this also for option 3, so rapporteur of ENDC should remember approved	approved	No
		S3‑170734	Conclusion and interim agreements for KI #4.11	Ericsson	pCR	Approval	Yes	YesE// presents agreement stay at yes only Huawei: have no conclusion section E//: come back next meeting with conclusions ->958 approved	revised	No	S3‑170958
		S3‑170958	Conclusion and interim agreements for KI #4.11	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑170734
		S3‑170728	Flexibile mechanism for AS key-change	Ericsson	pCR	Approval	Yes	YesE// presents DCM: how do we avoid reuse of bearers, more details missing E//: applies to all solutions DT: does this mean we don't have forward key derivation E//: only when there are intra eNB handovers QC: why change the key when PDCP stays E//: it is not changed Nokia: does the UE decide on the security E//: unclear at this moment if step 7 is required, keep flexibility Nokia: there is a key issue on UE requesting key refresh Samsung: Huawei: key issue is 4.7 with forward security? delay interim agreement DCM: with CU-DU split as in VF proposal with RRC in DU, this could become difficult. keep only high level agreement NEC: support DCM Huawei: applicable to option 3 editor's notes will be added with specific issues to be solved ->957	revised	No	S3‑170957
		S3‑170957	Flexibile mechanism for AS key-change	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑170728
		S3‑170735	Conclusion and interim agreements for KI #4.13	Ericsson	pCR	Approval	Yes	YesHuawei: not SA3 scope Nokia: agree DCM: need to document our decision IDCC: normally not adressed DCM: document the decision, change agreement to no E//: ok Huawei: not for SA3 in phase I -> 959 approved	revised	No	S3‑170959
		S3‑170959	Conclusion and interim agreements for KI #4.13	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑170735
		S3‑170730	Detecting radio jamming	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170736	Questions and interim agreements for KI #4.14	Ericsson	pCR	Approval	Yes	YesE// presents additional proposal: no need to address privacy concerns with RAN level identifiers IDCC: there was some work arguing that there is an issue E//: not valid claims IDCC: tracking of P-TMSI is clear QC: we are not working on this in phase 1 Nokia: is this referring to identifiers being not linkable E//: it is agreed that this issue is not addressed in phase 1 -> 960 approved	revised	No	S3‑170960
		S3‑170960	Questions and interim agreements for KI #4.14	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑170736
		S3‑170737	Minor clarification on KI #4.14 regarding constant RAN level identifiers	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170808	pCR to TR 33.899: Inter NG (R)AN handover with Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170812	pCR to TR 33.899: Intra AMF, Intra SMF, Inter NG RAN handover without Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170815	pCR to TR 33.899: Intra AMF, Inter SMF, Inter NG RAN handover without Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170817	pCR to TR 33.899: Inter AMF, Intra SMF, Inter NG RAN handover without Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170819	pCR to TR 33.899: Inter AMF, Inter SMF, Inter NG RAN handover without Xn interface	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
5.1.5	Security within NG-UE	S3‑170803	Device security interim agreement	Gemalto N.V.	pCR	Approval	Yes	YesVF: not CT6 responsibility to determine that sec requirement are met Oberthur: seems to give work to CT6 before the requirements are started Orange: there is an LS to CT6, SA1 informing of our requirements, so CT6 is involved E//: this is about storage, not about application, Orange: add note CT6 needs to be involved QC: CT6 is defining the network access application Gemalto: at the moment CT6 work is being bypassed Orange: ok with this note Oberthur: use 3GPP term, such as next gen USIM Gemalto: what does it mean to say on the UICC and the SSP Orange: both are possibilities E//: this interim agreement is late, so propose to postpone, because there are other interesting proposals as well. E//: is against this proposal Orange: HW is difficult, so this agrement is for phase 1 only, no alternative will be available for phase 1 E//: only include question Orange: will there be another solution until may Morpho: CT6 is stalling work already VF: none of any of the other solutions will be agreed E// formal request not to treat this document becaus it was late offline discussion with interested companies E// withdrew the formal request 803 merged into 883 Orange: added phase 1, Note 2, Note 3 Morpho: currently study item deals with non-security issue E//: Note 3 is not necessary Orange: come from Gemalto E//: sentence only up to USIM Gemalto: needs to be included E//: CT6 only does non-security requirements Samsung: what is SSP Orange: smart secure platform, add full form here approved	merged	No	S3‑170883
		S3‑170809	Interim Agreement on Key Issue 5.1	ORANGE	pCR	Approval	Yes	Yes	revised	No	S3‑170882
		S3‑170882	Interim Agreement on Key Issue 5.1	ORANGE	pCR	Approval	Yes	YesOrange presents Gemalto: cosigns E//: access -> authenticate Orange: ok, authenticate between UE and 5G network Huawei: what means processing, they are only stored Orange: agreement from last time Huawei: interim agreement different to 809 Orange: repeated the question approved	approved	No		S3‑170809
		S3‑170814	Interim Agreement on Key Issue 5.1 - Solution	ORANGE	pCR	Approval	Yes	Yes	revised	No	S3‑170883
		S3‑170883	Interim Agreement on Key Issue 5.1 - Solution	ORANGE	pCR	Approval	Yes	YesOrange presents Orange: same change about access ok here as well Gemalto: ovelap with Gemalto proposal in 803 E//: this contribution was late submission taken with 803	approved	No		S3‑170814
		S3‑170789	Device security solution and conclusion	Gemalto N.V.	pCR	Approval	Yes	Yes	not treated	No
		S3‑170806	LS on secure storage and processing of subscription credentials within the NG UE	ORANGE	LS out	Approval	Yes	YesOrange presents Orange: add that requirements are also for the normative phase E//: already sent LS to one of the groups on this topic, we requested them to keep us updated, keep request to keep us updated Orange: not required E//: ETSI SCP solution is referred without seeing it, DCM: need to have more information on ETSI SCP SSP requirements E//: text proposal for title Orange: key issue title E// not necessary to send to SA1 Orange: was discussed E//: action repeat request to update us including timeline for TC SCP SSP Nokia: SA1 in CC Orange: not ok, they have an action Nokia: need to attach 883 Orange: attach 882, 883 DCM: include ETSI SCP TEC and REQ in To field ->963 approved	revised	No	S3‑170963
		S3‑170963	LS on secure storage and processing of subscription credentials within the NG UE	ORANGE	LS out	Approval	Yes	Yes	approved	No		S3‑170806
5.1.6	Authorization	S3‑170603	Section 5.6.3.3.1, Key Issue Details.	InterDigital Communications	pCR	Approval	Yes	Yes	not treated	No
		S3‑170601	Section 5.6.4.2.2 - Resolution of Editor’s Notes.	InterDigital Communications	pCR	Approval	Yes	Yes	not treated	No
		S3‑170602	Section 5.6.4.3.2 - Resolution of Editor’s Notes.	InterDigital Communications	pCR	Approval	Yes	Yes	not treated	No
		S3‑170783	Resolution of the editor’s notes in solution #6.4	Ericsson LM	pCR	Approval	Yes	Yes	not treated	No		S3‑170281
5.1.7	Subscription privacy	S3‑170625	pCR to TR 33.899 – evaluations and conclusions in clause 7 (Revision of S3-170437, which was in turn a revision of A3-170076)	VODAFONE Group Plc	pCR	Agreement	Yes	Yes	not treated	No		S3c0001
		S3‑170877	Comments to “pCR to TR 33.899 – evaluations and conclusions in clause 7”	TELECOM ITALIA S.p.A.	pCR	Approval	Yes	Yes	not treated	No
		S3‑170878	Commenting contribution to S3-170625 – conclusions of security area 7	Nokia Germany	pCR		Yes	Yes	not treated	No
		S3‑170879	Commenting S3-170878 (Comment on comment)	Ericsson AB	pCR	Approval	Yes	Yes	not treated	No
		S3‑170838	pCR to provide an evaluation on the solutions for identity privacy	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No		S3‑170295
		S3‑170742	Key issue on location information protection	China Unicom	pCR		Yes	Yes	not treated	No
		S3‑170748	Privacy aspects of MCC and MNC	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170758	was 458 Key issues on identity probing	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170458
		S3‑170774	pCR to adding new key issue User location confidentiality	China Mobile Com. Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑170761	was 454 Questions related to PKI	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170454
		S3‑170762	was 198 Questions related to asym vs sym crypto	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170198
		S3‑170763	was 455 Question to concealment of identifiers OTA	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170455
		S3‑170764	was 498 Question on synchronization and recovery	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170498
		S3‑170765	was 456 Question to concealment of temporary identifiers	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170456
		S3‑170766	was 203 Question to full protection of permanent identifier	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170203
		S3‑170767	was 204 Question to slice identifier protection	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170204
		S3‑170721	pCR_Solution Upate #7.11 Resolve the editor note and add evaluation	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170757	Solution variant to 7.3 based on encrypted IMSI only	Nokia	pCR	Decision	Yes	Yes	not treated	No
		S3‑170771	Remove the editor's note in solution #7.10	China Mobile Com. Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑170772	Update the solution #7.10	China Mobile Com. Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑170776	Updating solution #7.3	Vodafone, Telecom Italia, Ericsson	pCR	Agreement	Yes	Yes	not treated	No		S3‑170080
		S3‑170784	Updating solution #7.14 “Privacy protection of permanent or long-term subscription identifier using ABE”	TELECOM ITALIA S.p.A.	pCR	Approval	Yes	Yes	not treated	No
		S3‑170832	pCR to update solution #7.4: Privacy enhanced Mobile Subscriber Identifier (PMSI)	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No		S3‑170293
		S3‑170833	PMSI usage in EAP-AKA’	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No		S3‑170294
		S3‑170836	pCR to update solution #7.4: Privacy enhanced Mobile Subscriber Identifier (PMSI) to clarify the PMSI synchronization	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑170837	pCR to provide an evaluation on the solution #7.4 Privacy enhanced Mobile Subscription Identifier (PMSI)	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑170629	pCR to TR 33.899 – UE sends IMSI to serving network	VODAFONE Group Plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑170672	Adding sol 7-7C: Using IMSI in calculation of VPLMN RES	KPN	pCR		Yes	Yes	not treated	No
		S3‑170747	Addressing LI aspects	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑170896
		S3‑170896	Addressing LI aspects	Ericsson	pCR	Approval	Yes	Yes	not treated	No		S3‑170747
		S3‑170619	MASA IMSI Privacy solution	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170620	MASA IMEI Privacy solution	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170632	pCR to TR 33.899: Securing and refreshing the temporary subscriber identifiers.	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑170759	was 452 Solution - Research Paper - Using pools of IMSIs and indicate in RAND	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170452
		S3‑170760	was 453 Solution - Research Paper - Encrypted pseudonym transported in RAND	Nokia	pCR	Decision	Yes	Yes	not treated	No		S3‑170453
		S3‑170746	Evaluations of two new privacy solutions	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170824	pCR to TR 33.899 – DoS protection when IMSI is encrypted to home network	VODAFONE Group Plc	pCR	Approval	Yes	Yes	not treated	No
5.1.8	Network slicing security	S3‑170666	Discussion paper on Network Slice isolation	Nokia, Ericsson	discussion	Discussion	Yes	Yes	not treated	No
		S3‑170706	Slice Isolation discussion	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170777	Discussion on network slice isolation	Ericsson LM, Nokia	discussion	Approval	Yes	Yes	not treated	No
		S3‑170810	Additional slice isolation requirements	Gemalto N.V., Huawei	pCR	Approval	Yes	Yes	not treated	No
		S3‑170667	Corrections to Network Slice 5.8.3.1	Nokia, Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170705	Conclusion for slice specific NAS keys	Huawei & Hisilicon	pCR	Approval	Yes	YesHuawei presents Nokia: there is only one NAS termination Huawei: ? E//: what are we trying to protect against Huawei: there are three discussion papers, requirement is slice isolation, one compromised slice would not affect other slices Nokia: 0639 is agreed Huawei: not agreed Gemalto: 639 open until presentation of this document DT: threat is similar described by QC, so similar consideration: separate keys wouldn't help Huawei: trust between tenants, main issue if one slice is compromised, how to conatin the issue without affecting the other slice E//: slice compromise is not a problem, as there is no access to other NG11 DT: slice isolation doesn't require UE specific keys, so compromis inside the UE is not an issue Huawei: per slice IPsec wouldn't be good a solution, IPsec tunnel inside the slices Nokia: look at threat documents by Huawei and commenting contributions E//: what is the solution Orange: assumptions are more relevant to protection done by infrastructure Huawei: open the threat documents Orange: if the infrastructure of operator is subverted, then all keys are visisble Huawei: open the threat paper Nokia: would be deviating from general principle, why would one SMF be able to attack another one Huawei: confidentiality not guaranteed Nokia: use IPsec Huawei: one possibility, one IP tunnel per slice, Nokia: or physical security Gemalto: have also a paper, if there are different slices, instantiated, security enclave, different keys DCM: UE side? Gemalto: both sides Orange: what is the relationship to this paper IDCC: look at NGMN requirement on isolation Orange: isolation based on infrastructure Nokia: there will be NDS between the machine DCM: NDS is not always possible, confidentiality and integrity need to be looked at separately KPN: if one SMF is hacked, then the other one as well E//: doesn't justify NAS slice specific keys Gemalto: there are multiple tenants Orange: this is not relevant for phase 1 Orange: deployment model not aligend with SA2 Huawei: security issue should be determined in SA3 IDCC: also saying this is to be handled Nokia: attack model is dubious DT: separating keys could be one way of instances IDCC: one function of one slice instance is in one cirtual machine Nokia: solution is not complete, even if the threat were valid KPN: attack not clear DCM: threat not relevant for phase 1, maybe in phase 2, but then only look at potential bidding down attack Nokia: agree with KPN; the attack is not clear Huawei: agree no slice specific keys available in phase 1, but may revisit in phase 2	noted	No
		S3‑170707	Definition of Security isolation of slices	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170712	Questions for KI8.1	Huawei & Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑170782	Questions and interim agreements on Network Slice-sepcific keys	Ericsson LM, Nokia	pCR	Approval	Yes	Yes	not treated	No
		S3‑170668	Corrections to Network slice 5.8.3.2	Nokia, Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170713	Questions for KI8.2	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170716	Removal of ENs in KI 8 3	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170714	Questions for KI8.3	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑170669	Corrections to network slice clause 5.8.3.3	Nokia, Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170609	Update of solution 8.5	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No		S3‑170073
		S3‑170768	Network Slicing Security Architecture and General Procedure	CATT	pCR		Yes	Yes	not treated	No
		S3‑170770	Evaluation for Network Slicing Security Solution	CATT	pCR		Yes	Yes	not treated	No
		S3‑170863	pCR to TR 33.899: Removal of Editor’s Notes of Solution 8.1	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170769	Evaluation for Network Slicing Security Solution	CATT	pCR		No	No	withdrawn	Yes
5.1.9	Relay security
5.1.10	Network domain security	S3‑170652	Key issue details for clause 5.10.3.2.1	Nokia	pCR		Yes	Yes	not treated	No
		S3‑170653	Threats alignment between 5.10.3.2.2 and 5.3.3.1.2	Nokia	pCR		Yes	Yes	not treated	No
		S3‑170654	Addition of requirements for 5.10.3.2.3	Nokia	pCR		Yes	Yes	not treated	No
		S3‑170655	Enhancing solution 10.1	Nokia	pCR		Yes	Yes	not treated	No
5.1.11	Security visibility and configurability	S3‑170846	Update of key issues of security area #11 Security visibility and configurability	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑170847	Update of solution #11.2 Security visibility solution	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑170848	Update of solution #11.3 Security configurability solution	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑170849	Update of solution #11.4 UE trigger of key and ID refresh	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑170850	Procedure for UE security indication and configuration	LG Electronics	pCR	Approval	Yes	Yes	revised	No	S3‑170868
		S3‑170868	Procedure for UE security indication and configuration	LG Electronics	pCR	Approval	Yes	Yes	not treated	No		S3‑170850
		S3‑170851	Conclusion for Security area #11: Security visibility and configurability	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑170852	Questions for Security area #11: Security visibility and configurability	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
5.1.12	Credential provisioning	S3‑170753	Evaluation of solutions and conclusion for credentials provisioning	Ericsson	pCR	Approval	Yes	YesE// presents VF: credential provisioning out of scope of 3GPP Orange: agree with VF E//: proposal is to have process outside of 3GPP, but network access is in scope VF: unauthenticated access not required, opposes unauth access to the network Samsung: there are requirements, highlighted in 802 Orange: that requirement is not that there is no 3GPP credential, SA1 req completely fulfilled by GSMA spec Samsung: based on operator policy, build on demand sec policy Intel: agree with Samsung, same interpretation of SA1 document, may not have default provisioning profile Oberthur: SA1 requirement changed when moving to TS phase Orange: IoT aspect is out of phase 1 Samsung: only massive IoT aspects are out of scope E//: only the radio aspect is out of scope Orange: requirement came out of mIoT use case Samsung: MBB use case, thus included in phase 1 KPN: stay with requirement in the TS, but KPN won't put in phase 1 DCM: not in phase 1 E//: there needs to be some things in phase 1, becuse policy decisisons need to be done VF: no non-authenticated bearer is acceptable, can also be done with an authenticated bearer Samsung: 5G system should support IP-connectivity Orange: provisioning profile provides IP connectivity Heiko: direct connectivity is only with 3GPP subscription in SA1 TS Gemalto: ok with being in phase 2 conclusions go away, keep open VF: all access is by USIM for phase 1 E//: could keep possible way forward, Orange disagree VF: credential provisioning not in phase 1 at all samsung: 802 for agreements	noted	No
		S3‑170802	Questions and Interim Agreements on Key Issue # 12.1 and 12.2: Credentials provisioning	Samsung, Ericsson	pCR	Approval	Yes	YesSamsung presents Orange: first part of interim agreement is not answering the question VF: disagree with question, SA1 only considered push provisioning, pleased with authentcated, but disagree because not narrowed down enough. Oberthur: Samsung is trying to push here what wasn't agreed in SA1, agree on Note VF: clarification required: credential is a USIM DT: not essential for phase 1, minute this for phase 2 VF: discuss in phase 2, not automatically agree in phase 2 Orange: agree with VF Chair: what happens with these documents Gemalto: should be treated because weren't treated Nokia: treat only if time is there in this meeting, then have conf call Orange: only solutions to be discussed agreement: credential provisioning is for phase 2 E//: record in table in annex of 33.899 Orange: phase 2 in first column, "credential provisioning will be discussed in phase 2" in comment column noted	noted	No
		S3‑170631	pCR to TR 33.899: Remote credential provisioning – using Attach Procedure	Intel Corporation (UK) Ltd	pCR	Approval	Yes	No	withdrawn	Yes
		S3‑170724	pCR to TR 33.899: Remote credential provisioning – using Attach Procedure	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑170751	Authorisation of network access for credentials provisioning	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170752	Solution: Network access for credentials provisioning using external AUSF/ARPF	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170797	Updates to Solution#12.4	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑170798	Support for Provisioning Profile for credential provisioning	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑170799	Updates to Solution#12.4 to support eUICC-ID privacy	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑170801	Evaluation of Solution #12.4	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑170804	Initial attach for remote provisioning	Gemalto N.V.	pCR	Approval	Yes	Yes	not treated	No
		S3‑170870	Initial attach for remote provisioning	Gemalto N.V.	pCR	Approval	Yes	Yes	not treated	No
		S3‑170853	pCR to 33.899 - Addition of new credential provisioning solutions	VODAFONE Group Plc	pCR	Approval	No	No	withdrawn	Yes
5.1.13	Interworking and migration	S3‑170754	Update of introduction to Security area #13 Security for Interworking and Migration	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170790	KI for HO between 5GC and EPC	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170791	Solution for HO between 5GC and EPC	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑170823	pCR to TR 33.899: Solution for key issue #13.1	NEC EUROPE LTD	pCR	Approval	Yes	Yes	not treated	No
		S3‑170755	Update of Key issue #13.2 Security for Idle Mode Mobility	Ericsson	pCR	Approval	Yes	Yes	not treated	No
5.1.14	Small data
5.1.15	Broadcast/Multicast security	S3‑170624	CR to TS 33.401 for BEST	VODAFONE Group Plc	CR	Agreement	No	Yes	withdrawn	Yes		S3‑170173
5.1.16	Management Security	S3‑170696	Automatic certificate enrolment for the gNB	Huawei & Hisilicon	pCR		Yes	Yes	not treated	No
		S3‑170722	Network slice life-cycle security	Huawei & Hisilicon	pCR	Approval	Yes	Yes	not treated	No
5.1.17	Cryptographic algorithms	S3‑170826	Starting the discussion on security algorithms support for 5G	Qualcomm Incorporated	discussion	Decision	Yes	YesQC presents Orange: for option 3 and 5G? QC: yes ATT: ok with proposal, but what is later for effective key length, phase 2 would be preferable QC: it is copy from 401 DCM: this relates to over the algorithms, later they can become 256 EEA/EIA Nokia: put this in TR as well CATT: has contribution 727 endorsing the contribution QC: LS to SAGE as heads up Nokia: not much to tell to SAGE, we don't know about the inputs to algorithms kept open -> merged into 953	merged	No	S3‑170953
		S3‑170657	Support of 256-bit Keys and Algorithms	AT&T	discussion	Approval	Yes	YesDCM: TUAK already supports 256, does 256 bit keys for RAN security provide sufficient benefit? IDCC: part of layered approach Orange: 4G or 5G ATT: this for phase 2 QC: consider 256 bit algorithms in phase 2? ATT: yes DCM: MAC is too short, LI is everywhere, so may give a false sense of security DT: agree, who will pay for this DCM: can endorse this Nokia: proposals are too vague, second proposal is done already agreement: further details on the proposals and implications of the changes are requested noted	noted	No
		S3‑170726	Questions and Interim agreements for 256-bit cryptographic algorithms	CATR, CATT, China Mobile, China Unicom, Huawei, Hisilicon, ZTE Corporation	pCR		Yes	YesCATT presents DCM: is it realistic to get feedback on the algorithms in that time frame Orange: differs from ATT, as ATT is talking about phase 2 Gemalto: same objective, for Qantum safe crypto it is required Nokia: for quantum safe, doubling of keys not required Gemalto: not clear when quantum crypto becomes available, so asymmetric schemes currently are weaker, start studying now Nokia: necessity doubling of key length or not is still under discussion BT: TC cyber says quantum safe is not required for another 20 years, in phase 1 extendability Orange: Quantum safe is only for asymmetric, so is this proposal for symmetric or asymmetric crypto DCM: only integrity protection would be interesting for phase 1 due to integrity protection BT: 20 years in research lab Nokia: time window for breaking key in bidding down attack is only a few seconds NCSC: convenor or ETSI quantum safe group, no hurry for now Morpho: already agreed to support 256 bits in protocols noted	noted	No
		S3‑170727	Questions and Interim agreements for 128-bit cryptographic algorithms	CATR, CATT, China Mobile, China Unicom, Huawei, Hisilicon, ZTE Corporation	pCR		Yes	YesCATT presents Orange: fine with proposal, keeping the same optionality and mandatory algorithms as in 33.401 Orange: make more precise: these algorithms are decided for NG, with the same text as in 33.401 Nokia: merge with QC contribution (826) QC: ok -> 953	revised	No	S3‑170953
		S3‑170953	Questions and Interim agreements for 128-bit cryptographic algorithms	CATR, CATT, China Mobile, China Unicom, Huawei, Hisilicon, ZTE Corporation	pCR	-	Yes	YesCATT presents E//: there might be new names for the 5G algorithms QC: Note on that Nokia: no support for 256bit algorithms for phase 1 Morpho: agreement was not to define 256 bit algorithms in phase 1 Nokia: text proposal … E//: LS to ETSI SAGE, agree this from meeting? Nokia: VF will take an action to talk SAGE chair about the algorithms agreed Action on VF agreed	revised	No	S3‑170886	S3‑170727
		S3‑170886	Questions and Interim agreements for 128-bit cryptographic algorithms	CATR, CATT, China Mobile, China Unicom, Huawei, Hisilicon, ZTE Corporation	pCR	-	Yes	Yes	approved	No		S3‑170953
		S3‑170828	Proposed inputs to the key derivation of ciphering and integrity keys	Qualcomm Incorporated	pCR	Approval	Yes	YesQC presents Nokia: add EN: it is FFS if it required to have a different parameter to distinguish whether Nokia: add EN: master key definition is FFS -> 955	revised	No	S3‑170955
		S3‑170955	Proposed inputs to the key derivation of ciphering and integrity keys	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑170828
5.1.18	Other	S3‑170604	LS to SA WG3 on privacy of registration and slice selection information	S2-170687	LS in		Yes	YesQualcomm presented the LS. SA2 is asking SA3 on the privacy implications of including slice specific information in the clear in either RRC or NAS signalling. VF: in 4G, integrity protetion is mandatory for NAS, so this needs to stay for 5G taken together with 845	replied to	No
		S3‑170902	Reply to: LS to SA WG3 on privacy of registration and slice selection information	Qualcomm	LS out	approval	Yes	YesQC presents Nokia: if NSSAI is not included, this is an indication that it is to be concealed QC: agree, what is alternative proposal Nokia: no optimal solution QC: only alternative never to include this is RRC Nokia: how could the NSSAI be selected QC: after NAS security setup this is protected Huawei: what are the information in setup, why this "e.g." in second paragraph, in MASA this could be protected - the wording is indicating there is no solution QC: UE identifier can be sent with protection even without security context setup Huawei: make this clear. more details QC: no solution chosen yet, so can't give more details Huawei: add sentence to note that UE identifier may be privacy protected on Nokia Comment: Nokia: no solution is there Orange: who decides that a slice is privacy sensitive Huawei: some solutions in SA2 say that home network does that BT: home network needs a strong control, but if home network is in low privacy state, then in roaming scenario this may compromise the roaming country's view IDCC: may be illegal when roaming in the other direction Nokia: shouldn't be an issue in either way, because one way privacy is simply not protected, in other way the idnetifier is and NSSAI is not encrypted Nokia: resolved by adding sentence in the end to point this out Nokia: GUTI may include slice type information QC: point out that GUTI shouldn't include such type of information DCM: UE identifier -> subscription identifier Nokia: UE identifier used in SA2 Orange: use subscribtion identifier DCM: make clearer that bit about GUTI QC: ok, copy that sentence into action Orange: change UE temp identifier to temp subscription identifier DCM: no, here it is UE temp identifier approved	approved	No
		S3‑170845	Privacy & security of registration and slice selection information	Qualcomm Incorporated	other	Approval	Yes	YesAnand (Qualcomm) presented the document. The document proposed a solution for carrying NSSAIs in NAS messages and comments on the privacy implications of including this in the RAN. Nokia commented that SA2 seem to want to include the NSSAI information in the temporay identity. QC: ask if they can include temp ID without such information VF: shouldn't the slice information be protected by the control slice, only what is needed for auth in unprotected messages QC: performance optimization, so no AMF relocation is required Nokia: message 4 would reveal QC: that is protected VF: LS is not clear this is only sent confidetniality protected, limit message 1 to protected messges E//: keep response generic DCM: If privacy is not an issue, NSSAI could be sent Tim: not integrity protected QC: can be protected in SMC response in 902	noted	No
		S3‑170605	LS on N2 and N3 reference points for 5G system	S2-171611	LS in		Yes	YesNokia presented the LS. It informs many groups about the status on N2 and N3. It was noted.	noted	No
		S3‑170607	Reply to LS on user plane security termination	R2-1702368	LS in		Yes	YesNokia presented the LS. It responds to the SA3 questions on UP security termination points. It was kept open to be part of the discusison on UP security termination. Noted	noted	No
		S3‑170796	LS on security in E-UTRA-NR Dual Connectivity	R2-1702442	LS in		Yes	YesEricsson presented the LS. It informs SA3 of the status of the dual connectivity. It was noted.	noted	No
		S3‑170800	Middlebox security protocol	ETSI TC CYBER	LS in		Yes	YesAlex (BT) presented the LS. It asks SA3 and SA3-LI about the implications of using middleboxes in 3GPP. Diego Lopez is working on a draft of MCTLS in the IRTF. The relationship between this work and 5G, as it seems to discuss oer the top applications, was questioned. The response was that it could be a base cyber/fraud mechanism that can be called from the application layer. It was kept open.	postponed	No
		S3‑170656	Support of PKI for NodeB Authentication	AT&T, MITRE, Interdigital	other	Decision	Yes	Yes	not treated	No
		S3‑170715	New SID on security aspect of Management and Orchestration of Network Slicing	Huawei, Hisilicon, Gemalto	SID new	Approval	Yes	Yes	not treated	No
		S3‑170919	5GS Security aspects seeking resolution	SA2	other	discussion	Yes	YesSA3 discussed the response and came to the conclusion that are shown in S3-170920 SA2 later informed, that the incoming document was not an approved SA2 document.	noted	No
		S3‑170920	Responses to S3-170919	WG Chair	discussion	discussion	Yes	Yes	endorsed	No
		S3‑170962	Draft TR 33.899	Ericsson	draft TR	Approval	No	Nofor email approval timeline: available 7 April comments 11 April approved 13 April	reserved	No
		S3‑170964	Draft TR 33.501	NCSC	draft TR	Approval	Yes	Yes	approved	No
5.2	Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14)	S3‑170859	[MCSEC] Update to Solution #1.2 in TR 33.880	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑170862	[MCSEC] Solution to protect entire XML signalling content	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑170880
		S3‑170854	[MCSEC] Solution adding of KMS URI information to configuration parameters	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑170893
		S3‑170893	[MCSEC] Solution adding of KMS URI information to configuration parameters	NCSC	pCR	Approval	Yes	YesMorpho queried whether there could be a separate list of KMSUris which could be linked to for efficiency reasons. Motorola said this would only be needed for the partner domain. NCSC said this idea could be included in the LS to SA6 (895). Nokia asked how the solution would work with dynamic groups. NCSC said that there isn't a solution yet for dynamic groups, but SA6 have been asked and had responded in 606. Approved	approved	No		S3‑170854
		S3‑170855	[MCSEC] Evaluation of solutions for supporting multiple security domains.	NCSC	pCR	Approval	Yes	Yes	approved	No
		S3‑170673	33.880 pCR Inter-domain IdM eval	Motorola Solutions Danmark A/S	pCR	Agreement	Yes	Yes	approved	No
		S3‑170880	[MCSEC] Clean-up of S3-170862: Solution to protect entire XML signalling content	NCSC	pCR	Approval	Yes	YesNokia asked about the rationale for encrypting the entire payload. NCSC explained it was to reduce the overheadApproved	approved	No		S3‑170862
		S3‑170898	[FS_MC_SEC] 33.880 first to answer evaluation	Motorola Solutions	pCR	Approval	Yes	Yes	approved	No
		S3‑170915	Draft TR 33.880	NCSC	draft TR	Approval	Yes	YesNCSC presents new acronym for MSK (multicast signalling key) is MUSIK Motorola: new documents: 0898, 0899, request to review on 898 Motorola presents 898 approved on 899 Motorola presents 899 approved 915 approved	approved	No
6	Any other business
7	Close