TDoc list

Tdoc List

2019-10-22 10:41

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‑193300	Agenda	WG Chair	agenda		Yes	Yes	revised	No	S3‑193681
		S3‑193681	Agenda	WG Chair	agenda	-	Yes	Yes	approved	No		S3‑193300
3	IPR and Anti-Trust Law Reminder
4	Incoming LS	S3‑193432	Discussion on Security of Multi-CU-UP connectivity	CATT	discussion	Decision	Yes	Yes	withdrawn	Yes
		S3‑193433	LS reply to RAN WG3 LS on security for multi-CU-UP connectivity	CATT	LS out	Approval	Yes	Yes	withdrawn	Yes
		S3‑193661	LS on 5GS Enhanced support of OTA mechanism for UICC configuration parameter update	C4-193790	LS in		Yes	YesNokia: no special security required DCM: agree Orange: if OTA keys go into new platform or stay in OTA platform. Put this in reply LS Thales: keys should stay in OTA platform, only authorized NFs should be able to use this interface. Nokia: noone wants to move the keys. Orange: for operators without OTA gateways, where are the keys.	replied to	No
		S3‑193682	Reply to: LS on 5GS Enhanced support of OTA mechanism for UICC configuration parameter update	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑193670	N9HR Regulatory Obligations	S3i190548	LS in		Yes	Yes	postponed	No
		S3‑193680	LS on security consideration of performance measurement function protocol	C1-196940	LS in	discussion	Yes	Yes	postponed	No
		S3‑193683	LS on security consideration of performance measurement function protocol	ZTE Corporation	LS out	Approval	Yes	YesApple: UP IP is required, should be included in LS CMCC: consensus is need integrity protection, does not mention other things, no other security mechanism is needed DCM: no new mechanism is required but including integrity protection is required.	revised	No	S3‑193816
		S3‑193816	LS on security consideration of performance measurement function protocol	ZTE Corporation	LS out	Approval	Yes	YesNo agreement on whether to include that exisiting mecchnaisms are sufficient	noted	No		S3‑193683
		S3‑193628	Discussion Paper for Security of Performance Measurement Function Protocol	Apple Computer Trading Co. Ltd	discussion	Agreement	Yes	YesNokia: all UP is integrity protected between UE and BS, so do we need more protection Apple: UP IP protection is good to have, but discussion is about whether, not how Nokia: protocol needs protection, but no further protectino is required. It is already protected. But no reply is required in this meeting Noamen: this was flagged as urgent QC: no additional security required. disagree with Apple discussion paper Apple: UP IP is optional. CT1 is only asking about problems, not about solution QC: LS should say we don't need additional security Huawei: no additional security is required DCM: respond: UP IP will be sufficitent E//: agree with QC that IP will not address all problems. Apple: PMF protocol needs to be protected	noted	No
5	Studies and Work Areas (Rel-16)
5.1	Security Aspects of the 5G Service Based Architecture
5.1.1	Work Item (SBA_Sec)	S3‑193386	Update to 5G_eSBA WID	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesThere is a related WID in S3-193672 where there is some discussion on splitting of the work items Needs to be re-submitted to Reno meeting.	approved	No
		S3‑193387	Security requirements for SeCoP	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesHuawei: Typo in title of 5.9.2.4 compared to abbreviations It was agreed to use the same name as SA2 but different abbreviations Huawei: What internal interface and why is it mentioned DCM: For service mesh type deployment there will be internal interfaces - could EN be made into normative text. Eri: Prefer to remove EN or re-word it. DCM: Leave EN in now and deal with it at the next meeting Eri: have other comments on the NOTE.	revised	No	S3‑193719
		S3‑193719	Security requirements for SeCoP	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	Yes	approved	No		S3‑193387
		S3‑193428	Security requirements for UP Gateway Function	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesThere were some offline revisions suggested - first line of NOTE moving to the top of the clause Eri: proxy requirement come from SA2 - does SA3 need to say DCM: UPGF acts a a transparent function Huawei: Remove last sentence of NOTE as not security related	revised	No	S3‑193720
		S3‑193720	Security requirements for UP Gateway Function	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	Yes	approved	No		S3‑193428
		S3‑193388	Authentication and authorization between SeCoP and network functions	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesEri: last paragraph could be shortened DCM: Concerned that it sounds like an option in that case Huawei: There is no authorisation aspects in clause yet an EN should capture this	revised	No	S3‑193721
		S3‑193721	Authentication and authorization between SeCoP and network functions	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	Yes	approved	No		S3‑193388
		S3‑193389	Authentication and authorization between SeCoPs	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesEri: formating of bullets Huawei: Authorisation EN is needed	revised	No	S3‑193722
		S3‑193722	Authentication and authorization between SeCoPs	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	Yes	approved	No		S3‑193389
		S3‑193423	Protection of N9 interface in Inter-PLMN scenario	Nokia, Nokia Shanghai Bell, Juniper	draftCR	Endorsement	Yes	YesNokia presents Eri: Concerned that this includes N32 when it does not mean to Agreed does not include N32 and taken offline for formulation.	revised	No	S3‑193723
		S3‑193723	Protection of N9 interface in Inter-PLMN scenario	Nokia, Nokia Shanghai Bell, Juniper	draftCR	Endorsement	Yes	Yes	approved	No		S3‑193423
		S3‑193622	Resource Level Authorization using Access Tokens	Ericsson	draftCR	Approval	Yes	YesHuawei: Concened that there may be SA2 impacts and would like to postpone document. Eri: How is the UDR impacted. Huawei: EN on SA2 impact and UDR study may affect this. Nok: Solution is overloading scope DCM: Not clear on what is being mandated.	noted	No
		S3‑193624	Authorization using Access Tokens based on NF-Subtype	Ericsson	draftCR	Approval	Yes	YesNok: No key issue so should not have a solution until this is agreed Huawei: Concerns raised for S3-193622 apply here.	noted	No
		S3‑193377	Security for Wireline access to 5G - General	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	No	Yes	withdrawn	Yes
		S3‑193378	Authentication for 5G-RG	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	No	Yes	withdrawn	Yes
5.1.2	Study (FS_SBA-Sec)	S3‑193614	LS on token-based authorization for indirect communication with delegated discovery (Scenario D)	Ericsson	LS out	Approval	Yes	YesSome comments given in offline e-mail discussion Nok: Update the question to SA2 and additional questions needed.	revised	No	S3‑193724
		S3‑193724	LS on token-based authorization for indirect communication with delegated discovery (Scenario D)	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑193614
		S3‑193678	Update to conclusion on Key issue #22: Authorization of NF service access in indirect communication	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesWait for SA2 response LS to S3-193724 before progress can be made.	noted	No
		S3‑193616	Update to conclusion on Key issue #22: Authorization of NF service access in indirect communication	Ericsson	pCR	Approval	Yes	YesWait for SA2 response LS to S3-193724 before progress can be made.	noted	No
		S3‑193617	Update to conclusion on Key issue #23: NF to NF authentication and authorization in Indirect communication	Ericsson	pCR	Approval	Yes	YesKept open for offline discussions DCM: authorization may not be so static.	noted	No
		S3‑193619	New solution for Key Issue #25 "Indirect communication in roaming scenarios"	Ericsson	pCR	Approval	Yes	YesNokia: Sentence in intro about 'authentication between NFs in different networks is implicit by ….' Huawei: Telescopic FQDN use requires an EN. DCM: Got confused that SECOP is split across PLMNs - make it clear that SECOP does not span multiple PLMNs by adding a sentence. Huwaei: Clarification needed in roaming scenarion that interface between SECOP and SEPP is a PLMN.	revised	No	S3‑193725
		S3‑193725	New solution for Key Issue #25 "Indirect communication in roaming scenarios"	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193619
		S3‑193620	Conclusion for Key Issue #25 "Indirect communication in roaming scenarios"	Ericsson	pCR	Approval	Yes	YesHuawei: Postpone due to EN on telescopic FQDN Nok: OK to make progress even with that EN DCM: Agree with Nokia and propose EN is added to conclusion - this was agreeable to meeting.	revised	No	S3‑193726
		S3‑193726	Conclusion for Key Issue #25 "Indirect communication in roaming scenarios"	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193620
		S3‑193445	eSBA: add conclusion on KI #24	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: Feel that response from SA2 is needed Huawei: Feel that it can go forward with EN Nok: Can go forward with EN There is a competing conclusion in S3-193618.	noted	No
		S3‑193727	eSBA: add conclusion on KI #24	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑193618	Conclusion of Key Issue #24 Service access authorization within a NF Set or a NF Service Set	Ericsson	pCR	Approval	Yes	YesDCM: support this as a conclusion.	noted	No
		S3‑193313	Resolving EN in TR33.855 6.18 N9 NDS/IP	Juniper Networks, NTT DoCoMo, Ericsson	pCR	Approval	Yes	YesHuawei: Mentions that network slice can have different security requirements - this is not clear Orange: Different security can be applied to different slices DCM: A better formulation is needed Juniper: Trying to resolve EN and it needs to be decided if some normative work needed.	revised	No	S3‑193728
		S3‑193728	Resolving EN in TR33.855 6.18 N9 NDS/IP	Juniper Networks, NTT DoCoMo, Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193313
		S3‑193613	Clarification on delegated subscribe-notify	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑193447	Update on solution#15 in TR 33.855	Huawei, Hisilicon	pCR	Approval	Yes	YesEri: evaluation does not contain disadvantages Hua: Last paragraph contains impact Taken for offline discussion of evaluation clause.	revised	No	S3‑193730
		S3‑193730	Update on solution#15 in TR 33.855	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193447
		S3‑193446	eSBA: add conclusion on KI #28	Huawei, Hisilicon	pCR	Approval	Yes	YesThis is a competing concusion in S3-193621 Hua: There is missing verification of the call-back and hence the solution. Eri: No way that this can be verified.	noted	No
		S3‑193621	Conclusion of Key Issue #28: Service access authorization in the delegated "Subscribe-Notify" scenarios	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑193615	Implementation of agreed change from SA3#96	Ericsson	pCR	Approval	Yes	Yesit is missing implementation from the last meeting.	approved	No
		S3‑193612	Clarification on identities in TLS and token-based authorization	Ericsson	discussion	Endorsement	Yes	YesHuawei: Does not agree with proposal - need to know how to allocate instnace Id and certificate first DCM: How would this work for scenario D? Does SECOP have NF instance IDs that it would use as transport IDs Eri: Do you mean that SECOP case is not covered?	noted	No
		S3‑193626	Evaluation update for Solution #25	Ericsson	pCR	Approval	Yes	YesHuawei: Do not agree with the proposed evaluation	noted	No
		S3‑193444	eSBA: add conclusion on KI #5	Huawei, Hisilicon	pCR	Approval	Yes	YesThere is a competing conclusion in S3-193444.	noted	No
		S3‑193625	Conclusion for Key Issue #5 "NF-NF Authorization"	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑193729	Draft TR 33.855	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
5.2	Authentication and key management for applications based on 3GPP credential in 5G
5.2.1	Work Item (AKMA)	S3‑193582	skeleton of AKMA TS	China Mobile, Nokia, Nokia Shanghai Bell	draft TS	Approval	Yes	YesHuawei: Prefer CMCC version QC: OK to merge but think that there are good sections in Ericsson which should be kept.	revised	No	S3‑193769
		S3‑193769	skeleton of AKMA TS	China Mobile, Nokia, Nokia Shanghai Bell,Ericsson	draft TS	Approval	Yes	Yes	approved	No		S3‑193582
		S3‑193596	Skeleton of clause 4 and selected content for AKMA normative work	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑193769
		S3‑193583	scope of AKMA TS	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesQC: Remove 3GPP and change to subscription credentials. Orange: Reference the subscription credentials in TS 33.501 - align terminology with study. QC: Remove the bullet list paragraph Orange: Remove the 2nd sentence of first paragraph.	revised	No	S3‑193770
		S3‑193770	scope of AKMA TS	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193583
		S3‑193468	Propose AKMA architecture	Huawei, Hisilicon	pCR	Approval	Yes	YesThere are competing proposals in S3-193584 and S3-193599 BT: Like S3-19599 as it looks more service based Orange: We are defining a service that provides keys for use in an application KPN: Why have the UDM in the picture? Huawei: Need to make the high levl descision, e.g. local of anchor function, so issue with Ericsson's text on where a key is derived - prefer S3-193584 as the baseline for merger Orange: No point having non-SBA interfaces as the core network is now servive based Huwaei: Need UDM in picture Orange: Do not see the point of not using a service based representation as that is now the normal CMCC: Both representations are equivalent Orange: Will object to non-service based version Agreed to use UE and AF boxes - also AAnF will be the name of the AKMA anchor function Orange: It is more complicated than the pictures shows as an AF outside 3GPP network may need to use an NEF to access AAnF? Merged into 771.	merged	No	S3‑193771
		S3‑193584	draft CR of AKMA architecture	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193771
		S3‑193771	draft CR of AKMA architecture	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesOrange: disagree with ed note, object to collocation of AAnF with NEF CMCC: was there before QC: remove in parantheses? Orange: no.	revised	No	S3‑193841	S3‑193584
		S3‑193841	draft CR of AKMA architecture	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193771
		S3‑193599	AKMA architecture reference model	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑193771
		S3‑193469	Propose AKMA key hierarchy	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: Name of functions changes to AAnF and other fucntion to AF - key name should also change.	merged	No	S3‑193772
		S3‑193600	AKMA Key hierarchy	Ericsson	pCR	Approval	Yes	YesThere is a competing proposal in S3-193469 Orange: Correct names based on agreements- text in S3-193469 is not correct as it talks about AKMA authentication QC: Just show the derivation of K_AUSF and reference TS 33.401 for the rest of the derivations.	revised	No	S3‑193772
		S3‑193772	AKMA Key hierarchy	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193600
		S3‑193817	Draft TS 33.535	China Mobile	draft TS	Approval	No	Yes	left for email approval	No
5.2.2	Study (FS_AKMA)	S3‑193441	AKMA: Resolving the EN in AKMA push	Huawei, Hisilicon	pCR	Approval	Yes	YesEri: need to go the UDM and not clear on what is meant by security context Huawei: Will chck on UDR or UDM and change security context to K_AUSF.	revised	No	S3‑193761
		S3‑193761	AKMA: Resolving the EN in AKMA push	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193441
		S3‑193442	AKMA: adding the evaluation of solution #24	Huawei, Hisilicon	pCR	Approval	Yes	YesEri: Evaluation not in template QC: When you have a K_AUSF then UE can connnect so need evaluation on why need to use PUSH for this case - also why do we need AKMA PUSH when GBA PUSH already exists Huawei: AKMA is a new feature and needs its own PUSH CMCC: Do we need an editor's note for the second point? Huawei: Confirmed that the scope of GBA PUSH enhancements is network interfaces QC: Important that understand if we need more than PUSH solution QC: Don't want to have two solutions for PUSH?.	revised	No	S3‑193763
		S3‑193763	AKMA: adding the evaluation of solution #24	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193442
		S3‑193443	AKMA: add conclusion on KI #17	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193473	Evaluation for solution4	Huawei, Hisilicon	pCR	Approval	Yes	YesThis was missed for earlier implementation of the TR.	approved	No
		S3‑193475	Implicite AKMA authenticaiton procedure	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: this solution changes primary authentication and not sure if this is acceptable QC: Do not understand why we are having an new solution. Huawei: Can it derive the K_AKMA? Eri: Changes the Registrations Accept QC: do not understand why a different solution is needed when we have agreed solution.	noted	No
		S3‑193597	Solution #15 evaluation removal of EN	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193474	Evaluation for solution22	Huawei, Hisilicon	pCR	Approval	Yes	YesEri: Does not fit the template for evaluations QC: Think first sentence should go away.	revised	No	S3‑193764
		S3‑193764	Evaluation for solution22	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: don't agree with last two sentences QC: conclusions made, doesn't matter agreed as it is.	approved	No		S3‑193474
		S3‑193595	Solution Key lifetimes	Ericsson	pCR	Approval	Yes	YesQC: OK with proposal and analysis. Normative text on requirements in evaluation should go away.	revised	No	S3‑193765
		S3‑193765	Solution Key lifetimes	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193595
		S3‑193591	Evaluation of solution#1	China Mobile	pCR	Approval	Yes	YesEricsson: Solution addresses a problem that is not actually for AKMA.	approved	No
		S3‑193587	Conclusion on key issue #6	China Mobile, KPN	pCR	Approval	Yes	YesEri: Do not agree with conclusion as this could be left applications QC: Agree with ericsson comment BT: Conclude on this issue now but either need it done properly or not at all CMMC: This is a customer requirement QC: This is in the scope of the application ZTE: Think that this is an important requirement.	noted	No
		S3‑193340	Update of key issue #6	KPN	pCR	Approval	Yes	YesEri: Similar to the previous document - application can derive the keys QC: Add a EN to capture the issue on whether the requirement can be left to application.	revised	No	S3‑193766
		S3‑193766	Update of key issue #6	KPN	pCR	Approval	No	Yes	approved	No		S3‑193340
		S3‑193598	Conclusions on Key management	Ericsson	pCR	Approval	Yes	YesBT: This is important that application key outlives the root anchor. Supports the evaluation.	approved	No
		S3‑193590	Individual Evaluation of solution #6	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑193470	Conclusion on 7.3	Huawei, Hisilicon	pCR	Approval	Yes	YesEri: maybe not possibel to conclude on this CMCC: No been decided whether anchor function is standalone KPN: Come a bit of out of the blue and not related to a solution - not ready to conclude.	noted	No
		S3‑193585	conclusion on key issue #2	China Mobile	pCR	Approval	Yes	YesEri: Key issue does not security theats or requirements - which messages are used CMCC: To use NAS procedures between UE and 5GC QC: Also struggle to see what the conclusion means.	revised	No	S3‑193767
		S3‑193767	conclusion on key issue #2	China Mobile	pCR	Approval	Yes	YesOrange: AKMA application functino will be named to application function E//: not consistent in the TR? Orange: Note: AKMA application function is now application function in normative work.	revised	No	S3‑193842	S3‑193585
		S3‑193842	conclusion on key issue #2	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑193767
		S3‑193471	Conclusion on 7.4	Huawei, Hisilicon	pCR	Approval	Yes	YesThere is an alternative conclusion in S3-193586 QC: not ready to make this conclusion as there are alternatives - hence need more analysis on how this should be done.	merged	No	S3‑193768
		S3‑193586	Conclusion on key issue #5	China Mobile	pCR	Approval	Yes	YesHuawei: Two conclusions are not competing QC: Can make a conclusion on deriving identifier for K_AUSF Huawei: In the TR there is a temporary identifier.	revised	No	S3‑193768
		S3‑193768	Conclusion on key issue #5	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑193586
		S3‑193592	Evaluations of solution #7- #12	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑193588	Conclusion on key issue #13	China Mobile	pCR	Approval	Yes	YesQC: OK but do you expect changes to UE/UICC or keep it open CMCC: keep it open.	approved	No
		S3‑193472	Propose new conlusion section	Huawei, Hisilicon	pCR	Approval	Yes	YesEri: there is already a place for this conclusion CMCC: Agree with ericsson.	noted	No
		S3‑193513	User identity privacy for GBA in 5GC	ZTE Corporation	pCR	Approval	Yes	YesCMCC: Don't have the GBA content in the TR Eri: Maybe in scope of the other SID Orange: Agree that could be treated in 5G GBA SID.	noted	No
		S3‑193589	Editorial Changes to TR 33.835	China Mobile	pCR	Approval	Yes	YesQC: Editorial - think that the Voids can be removed as not under change control.	approved	No
		S3‑193762	draft TR 33.835	China Mobile	draft TR	Approval	No	Yes	left for email approval	No
5.3	Evolution of Cellular IoT security for the 5G System
5.3.1	Work Item (CIoT_sec_5G)	S3‑193660	LS on short MAC-I and ngKSI for 5G-CIoT	C1-195199	LS in		Yes	Yes	replied to	No
		S3‑193715	Reply to: LS on short MAC-I and ngKSI for 5G-CIoT	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑193658	Nokia comments on CT1 LS C1-195199	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑193668	Reply LS on LTE-M identification in 5GC	R3-194748	LS in		Yes	Yes	noted	No
		S3‑193435	Discussion on security context handling in fast RRC release	LG Electronics	discussion		Yes	YesIntel: SA2 have not agreed to fast release, so should we discuss this here QC: Not clear what the securiyt issue is LG: Possible NCC mismatch Nok: Agree with Intel that fast release is not yet standardiszed Eri: Not clear that observation 1 is correct so maybe no security issue.	noted	No
		S3‑193569	CIOT: Discussion paper on ngKSI for NB-IoT in 5G-CIoT.	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑193570	CIOT: Discussion paper on short MAC-I for NB-IoT in 5G-CIoT.	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑193571	Draft LS reply on LS on short MAC-I and ngKSI for 5G-CIoT	Ericsson	LS out	Approval	Yes	YesQC: first answer: make it shorter, not a security issue DCM: if inteintegrity protection fails, then there is possibility of mismatch and of attack QC: there can't be a mismatch on CPSR message offline QC: second question: shorter, simply say no. agree to not reduce reduced size MAC.	revised	No	S3‑193715
		S3‑193562	DraftCR - Proposed skeleton for supporting 5G CIoT [Living Document]	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑193716
		S3‑193716	DraftCR - Proposed skeleton for supporting 5G CIoT [Living Document]	Ericsson	other	Approval	Yes	Yes	approved	No		S3‑193562
		S3‑193392	CIoT_ Modifications to draft CR	Nokia, Nokia Shanghai Bell, Ericsson	other	Approval	Yes	YesHuawei: will provide definition next time Nokia: slightly different title in 6.x.1 DCM: give different title to 6.x.1.	revised	No	S3‑193717
		S3‑193717	CIoT_ Modifications to draft CR	Nokia, Nokia Shanghai Bell, Ericsson	other	Approval	Yes	Yes	approved	No		S3‑193392
		S3‑193484	Security handling for RRCConnectionRe-establishment Procedure for Control Plane Optimization for 5GS CIoT	Huawei, Hisilicon	draftCR	Approval	Yes	YesAwaiting SA2 descion on truncating S-TMSI.	noted	No
		S3‑193559	DraftCR – RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC	Ericsson	other	Approval	Yes	YesAwaiting SA2 descion on truncating S-TMSI.	noted	No
		S3‑193558	DraftCR – Control Plane optimized solution	Ericsson	other	Approval	Yes	YesEditor's note from this document should be merged into S3-193818 (update of S3-193485).	merged	No	S3‑193818
		S3‑193560	DraftCR – Control Plane optimized solution	Ericsson	other	Approval	No	Yes	withdrawn	Yes
		S3‑193485	Security handling in Control Plane User Datafor Control Plane Optimization for 5GS CIoT	Huawei, Hisilicon	draftCR	Approval	Yes	YesSpelling corrections and addition of EN from S3-193558 Nokia: An EN on FFS to clarify the encoding on CP optimisated messages.	revised	No	S3‑193818
		S3‑193818	Security handling in Control Plane User Datafor Control Plane Optimization for 5GS CIoT	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑193485
		S3‑193483	CR for DDoS mitigation caused by misbehaving CIoT UEs	Huawei, Hisilicon	draftCR	Approval	Yes	YesNok: don't need this QC: agree with Nokia.	noted	No
		S3‑193561	DraftCR – NAS based redirection between 5GS and EPC	Ericsson	other	Approval	Yes	Yes	approved	No
5.3.2	Study (FS_CIoT_sec_5G)	S3‑193367	LS on GUTI re-allocation	Qualcomm Incorporated	LS out	Discussion	Yes	YesNokia: Agree an important principle to maintain 5G-GUTI re-allocation Eri: Agree but want to delay response as incoming LS is out of scope There was general agreement on the principle that GUTI re-allocation should be supported. Chair: There will be an LS out of the meeting but will need discussion on the process to follow due to original LS not being part of meeting Result of discussion: send LS as new LS, not as reply.	noted	No
		S3‑193542	CIOT: Title correction solution 13	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193366	Key Issue on UE capability protection for CP optimization only CIoT UE	Qualcomm Incorporated	pCR	Approval	Yes	Yes	merged	No	S3‑193704
		S3‑193437	Protection of UE capability transfer for UEs without AS security	Intel	pCR		Yes	YesNo comments on the key issue and threats part of the documents.	revised	No	S3‑193704
		S3‑193704	Protection of UE capability transfer for UEs without AS security	Intel	pCR	-	Yes	YesE//: disagree with security requirements QC: what is the proposal E//: more about persistance of capabilities QC: then it is a security problem Nokia: agree with E//, so security is not as strong as other devices.	revised	No	S3‑193843	S3‑193437
		S3‑193843	Protection of UE capability transfer for UEs without AS security	Intel	pCR	-	Yes	Yes	approved	No		S3‑193704
		S3‑193497	New KI: Preventing mismatch for EDT with fast release	LG Electronics France	discussion		Yes	YesNok: Need to wait for SA2 work Eri: Agree to wait for SA2 but still a key issue open on this topic DCM: Concern that we need to wait for SA2 in all cases.	noted	No
		S3‑193545	CIOT: Proposed clarifications to KI#6	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193536	CIOT: Update of KI#12 description	Ericsson	pCR	Approval	Yes	YesQC: Why key issue needed as initial NAS Security covers them? BT: Thought we had agreement on protecting IEs by default Nok: don’t feel they are a privacy threat QC: don't need a key issue There was general agreement that initial NAS security should be used to protect these IEs but it was not clear in the meeting that the tex in TS 33.401 covered this.	noted	No
		S3‑193548	CIOT: Update of Solution #14	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑193493	Address EN in solution 23	Huawei, Hisilicon	pCR	Approval	Yes	YesNok: It seems strange to add the load to the surrounding base stations Huawei: by sending mis-behaving UE ID to other base stations so the other base stations know about mis-behaving Ues Eri: Update is OK but concerned about the use of the list in general Nok: Making the update optional would improve the situation DCM: RAN should be made to eNB/gNBs probably throughout the whole solution.	noted	No
		S3‑193537	CIOT: update to the evaluation of solution #24	Ericsson, Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑193438	Security solution for UE Capability Transfer for UE with no AS security.	Intel	pCR		Yes	YesE//: key issue not approved yet.	noted	No
		S3‑193391	AMF verification of the UE radio capabilities for CP optimization only CIoT UE	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑193390	Hash based UE capability protection for CP optimization only CIoT UE	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑193541	CIOT: Discussion on DDoS solutions for KI#4 and KI#5	Ericsson, Qualcomm Incorporated, Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑193539	CIOT: Conclusion on KI #4	Ericsson, Nokia, Nokia Shanghai Bell, Qualcomm Incorporated, Samsung	pCR	Approval	Yes	YesSupport: cosigners Object: KPN, Huawei DCM: same as KPN conclusion, except for SA2 part, send LS to SA2 instead. Approved as LS has been sent	approved	No
		S3‑193482	Conclusion for Key Issue #4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193341	Conclusion to Key Issue #4	KPN	pCR	Approval	Yes	YesSupport: cosigners Object: KPN, Huawei DCM: same as KPN conclusion, except for SA2 part, send LS to SA2 instead. Approved as LS has been sent.	noted	No
		S3‑193494	Conclusion of KI#5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193540	CIOT: Conclusion on KI #5	Ericsson Nokia, Nokia Shanghai Bell, Qualcomm Incorporated, Samsung	pCR	Approval	Yes	YesNokia: solution 23 spreads load to other base stations Huawei: NWDAF to gNB interface is missing Huawei: remove first paragraph DCM: if NWDAF doesnt provide the information, then this needs to be added to LS Huawei: delete the sentence,	revised	No	S3‑193711
		S3‑193711	CIOT: Conclusion on KI #5	Ericsson Nokia, Nokia Shanghai Bell, Qualcomm Incorporated, Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑193540
		S3‑193547	CIOT: Proposed_conclusion_KI_6	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193552	Conclusion on Key Issue#7	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesNokia: explain "missing freedom of key derivation" Lenovo: because there is only NCC in key derivation, the attacker can assume that NCC is incremented each time.	merged	No	S3‑193712
		S3‑193544	CIOT: Proposed conclusion to KI#7	Ericsson	pCR	Approval	Yes	YesLenovo: add that stationary UE need more attention DCM: don't understand that limitation, keep E// contribution offline what to add for this.	revised	No	S3‑193712
		S3‑193712	CIOT: Proposed conclusion to KI#7	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193544
		S3‑193546	CIOT: Proposed_conclusion_KI_8	Ericsson	pCR	Approval	Yes	YesDCM: delete last sentence.	revised	No	S3‑193713
		S3‑193713	CIOT: Proposed_conclusion_KI_8	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193546
		S3‑193543	CIOT: Proposed conclusion to KI#10	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193538	CIOT: recommendation to support solution #24 to solve KI #11	Ericsson, Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑193549	CIOT: Conclusion for KI#12	Ericsson	pCR	Approval	Yes	YesE// presents, propose to say: no normative work is required.	revised	No	S3‑193714
		S3‑193714	CIOT: Conclusion for KI#12	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193549
		S3‑193838	LS on GUTI re-allocation	Qualcomm	LS out	Approval	Yes	Yes	approved	No
		S3‑193710	LS on Signalling overload due to malicious Applications on UE	KPN	LS out	Approval	Yes	YesBT: include security concerns and tracking E//: no reference to the solutions in our TR QC: remove the reference about normative texts Huawei: it is no normative work in SA3.	revised	No	S3‑193844
		S3‑193844	LS on Signalling overload due to malicious Applications on UE	KPN	LS out	Approval	Yes	Yes	approved	No		S3‑193710
		S3‑193703	draft TR 33.861	Ericsson	draft TR	Approval	Yes	Yes	left for email approval	No
5.4	Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)	S3‑193663	PEI for FN-RG Recommendation	BBF	LS in		Yes	Yes	noted	No
		S3‑193664	General Status of Work	BBF	LS in		Yes	Yes	noted	No
		S3‑193479	living doc for 5WWC	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	revised	No	S3‑193684
		S3‑193684	living doc for 5WWC	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑193479
		S3‑193384	Security for trusted non-3GPP access – General	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesLenovo: overlaps with 3550, merge general clause QC: clarify that sentence 2 is about EAP 5G Orange: nothing on 5G AKA in Lenovo contribution. E//: last paragraph of Nokia is not needed, it is a comparison. Call flow is copied, so put ed note on step 8 that this needs more work (authentication) ed note: stating details of key hierarchy are FFS. Huawei: second ed note not needed now.	merged	No	S3‑193685
		S3‑193385	Security procedure for trusted non-3GPP access	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesOrange: remove text from living document, remove stuff from Living document, iti is pCR to living document.	merged	No	S3‑193685
		S3‑193550	Solution for trusted non-3GPP access	Lenovo, Motorola Mobility	draftCR	Approval	Yes	Yes	revised	No	S3‑193685
		S3‑193685	Solution for trusted non-3GPP access	Lenovo, Motorola Mobility	draftCR	Approval	Yes	YesEN added for figure to be changed next time	approved	No		S3‑193550
		S3‑193631	Trusted access key hierarchy	Ericsson	draftCR	Approval	Yes	YesHuawei: this is not the agreement in TR, additional argument is required why is this required. E//: makes mobility easier Lenovo: what kind of mobility E//: between TNAPs. BT: What are TNAP keys for: different devices, or different versions (updates) of keys in the same ME.	noted	No
		S3‑193632	Trusted access key derivation	Ericsson	draftCR	Approval	Yes	YesHuawei: related to 631 offline discussions, to be taken back next time.	noted	No
		S3‑193379	Security for Wireline access to 5G - General	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesOrange: no roaming, put in as Note. BT: GW owner and connected operator are same, for R17 something more practical is required. Orange: use note from TR, which is useful Nokia: should be covered in SA2 architecture Huawei: sentence is needed here. QC: Last sentence: remove "potential" Hauwei: remove last paragraph E//: remove reference to 33.501 E//: clarify FN-RG in third paragraph QC: reference in first paragraph is xx, add TS 23.whatever.	revised	No	S3‑193686
		S3‑193686	Security for Wireline access to 5G - General	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	Yes	approved	No		S3‑193379
		S3‑193380	Authentication for 5G-RG	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesThales: add concealing the SUPI.	merged	No	S3‑193687
		S3‑193480	Authentication for 5G-RG	Huawei, Hisilicon	draftCR	Approval	Yes	YesBT: equipped with UICC, prevent removal and replacement Huawei: not part of study, need requirement in study for next meeting E//: remove Ipsec in step 12.	revised	No	S3‑193687
		S3‑193687	Authentication for 5G-RG	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑193480
		S3‑193381	Authentication for FN-RG	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	Yes	merged	No	S3‑193688
		S3‑193481	Authentication for FN-RG	Huawei, Hisilicon	draftCR	Approval	Yes	YesQC: duplicate steps 6 in call flow E//: AUSF skips authentication - doesn't perform auth DCM: lack of shalls E//: clarify that FN-RG is legacy Huawei: this is already in general clause QC: title should be about security procedures, because this is more general.	revised	No	S3‑193688
		S3‑193688	Authentication for FN-RG	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑193481
		S3‑193382	Authentication for the UE behind the RG	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	Yes	approved	No
		S3‑193383	Security of the interface between W-5GAN and 5GC	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	YesEri: list formatting Eri: clarify of the N2 interface.	revised	No	S3‑193689
		S3‑193689	Security of the interface between W-5GAN and 5GC	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	Yes	approved	No		S3‑193383
		S3‑193633	Subscriber privacy for wireline access	Ericsson	draftCR	Approval	Yes	Yes	approved	No
		S3‑193551	Solution on 5GC access from WLAN UEs that do not support NAS	Lenovo, Motorola Mobility	draftCR	Approval	Yes	YesOrange: questions whether the text is needed as they don't support authentication Len: There are some inter-working functions Orange: would like to see text that shows what is different to general authentication Len: will work offline to produce that text Thales: do not understand why use the term 'devices' Len: usage follows 23.502.	revised	No	S3‑193690
		S3‑193690	Solution on 5GC access from WLAN UEs that do not support NAS	Lenovo, Motorola Mobility	draftCR	Approval	Yes	Yes	approved	No		S3‑193551
5.5	5G security enhancement against false base stations (FS_5GFBS)	S3‑193602	Correction of conclusion for Key Issue #1	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193334	Address EN in solution #1	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193486	Merged Solution for RRC Reject Protection	Huawei, Hisilicon, Samsung	pCR	Approval	Yes	YesEri: Have concerns with the solution QC: Also have concerns with this solution.	noted	No
		S3‑193487	Conclusion for Key Issue #1 for RRC Reject	Huawei, Hisilicon, Samsung	pCR	Approval	Yes	YesEri: no normative work needed QC: Agree with Ericsson.	noted	No
		S3‑193488	Update on Protection of RRC Resume Request message	Huawei, Hisilicon	pCR	Approval	Yes	YesEri: Simpler solution is available as needs to be updated as message content changes Apple: This could be merged with Ericsson solution.	approved	No
		S3‑193574	Solution for Resumecause protection	Samsung	pCR		Yes	YesEri: Solution is not needed Sam: In case of conjestion, then short-MAC-I may not be checked Huawei: Disagree with this solution.	noted	No
		S3‑193603	New Solution: Protection of the whole RRCResumeRequest message	Ericsson	pCR	Approval	Yes	YesApple: support this solution Huawei: missing disadvantage, like increase in length, or processing E//: put in a ednote? Huawei: straight forward: disadvantage: increase of processing timei DCM: make this an ed note, because it is not clear that copying IEs adn running hash over a shorter message has overhead of copying QC: mixed deployments between R15 and R16 in network and with UEs. Ed Note: the impact of working with legacy UEs and base stations are ffs Orange: not have evaluation this time, because of ed notes. remove evaluation, add ed note in solution details.	revised	No	S3‑193753
		S3‑193753	New Solution: Protection of the whole RRCResumeRequest message	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193603
		S3‑193489	Conclusion for Key Issue #1 for RRC Resume Request Protection	Huawei, Hisilicon	pCR	Approval	Yes	YesE//: competing solution Huawei, then postpone.	noted	No
		S3‑193604	Way forward for KI#1 against tampering of RRCResumeRequest messages	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑193502	Protection of UeapabilityInformation	Apple	pCR	Approval	Yes	YesOrange: this is concluded already? Huawei: agree with Orange.	noted	No
		S3‑193360	Evaluation of the shared key based MIB/SIB protection solution	Qualcomm Incorporated	pCR	Approval	Yes	YesApple: only agree with first two bullets Huawei: support QC, ed note: how to protect MIB and SIB if AS security is not active is FFS E//: not accept first statement, ecause requirement says should detect in all states QC: first two paragraphs need to be read together E//: disagree with last para QC: add that verifiaction of hash by gNB? Add ed note, remove last two paragraphs.	revised	No	S3‑193754	S3‑192938
		S3‑193754	Evaluation of the shared key based MIB/SIB protection solution	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193360
		S3‑193500	Evaluation for solution#14	Apple	pCR	Approval	Yes	YesQC: disagree E//: support apple Huawei: support QC.	noted	No
		S3‑193575	Evaluation of solution#14 in TR 33.809	Samsung	pCR		Yes	YesQC: disagree, first statement is false, because step 1 is only after AS security set up, it is to protect SIB messages, not against fake base stations Apple: support Samsung E//: same comment Huawei: support QC Orange: support QC.	noted	No
		S3‑193361	Shared key based MIB/SIBs integrity information provided by gNB	Qualcomm Incorporated	pCR	Approval	Yes	YesSamsung: what happens if message 8 is not received, what is UE behaviour? QC: not described, UE knows this. Samsung how does Ue know that? QC: UE identifies mismatch, in step 7, then if message 8 does not arrive, Samsung: without message 8, what does the UE do? incomplete solution QC add ed note: UE behaviour when message 8 is not received is FFS E//: disagree, doesn't cover UE in idle mode. Huawei: support QC Apple: note, because similar solution exists already QC: differnt place of verification	noted	No		S3‑192936
		S3‑193363	Evaluation on UE behavior on detection of false signature	Qualcomm Incorporated	pCR	Approval	Yes	YesE//: not agreeing with bit flip attack. In second paragraph, alter attack is in controlled environment, using different PCI and frequency, with signature that could be avoided. Apple: first para should be moved into ky issue, second para is DoS, true for all MACs, disagree with third and fourth para as well QC: not move to key issue description.	noted	No
		S3‑193364	Evaluation on signing key management	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: stronly support last paragraph, because when moving to new TA, the UE can suffer from MiTM attack. E//: UE could get new keys before moving to new TA Samsung: disagree with second evaluation, first also doesn't hold Apple: also similar to Samsung QC: agree that all signing solutions will not be pursued further, as no evaluations are going in. Apple: problems where of technical nature.	noted	No
		S3‑193576	Updates to Solution#7 on obtaining accurate clock information	Samsung	pCR		Yes	Yes	approved	No
		S3‑193577	Deletion of EN on Location update reject in Solution#7	Samsung	pCR		Yes	YesHuawei: whem UE sends reg req message, this is not integrity protected. Add ed note or note this Samsung: not part of solution, QC: keep ed note and note this, as it doesn't explain E//: support, but ok to note to make progress	noted	No
		S3‑193499	Update for Solution#7	Apple	pCR	Approval	Yes	YesQC: disagree, should be noted. Huawei: support QC, when UE moves to new area, it is possible to connect to FBS wthout the UE noticing, that is a technical problem	noted	No
		S3‑193501	Update of Solution#11	Apple	pCR	Approval	Yes	YesOrange: major problem is provisioning, therefore it is not viable orange: not linking the SUCI scheme DCM: provisioning is essential BT: not link to SUCI scheme to not make it more difficult to SUCI off the ground	noted	No
		S3‑193514	Assessment and evaluation of solution #9	ZTE Corporation	pCR	Approval	Yes	YesE//: SIB/MIB is matter of serving network, so shouldn't involve home network. Orange: agree. BT: support that, not using home public key.	noted	No
		S3‑193461	A solution to protect MIB/SIBs	Huawei, Hisilicon	pCR	Approval	Yes	YesE//: incomplete, doesn't support UE in Idle mode, disagree Huawei: if NAS security is available, then use NAS security in IDLE QC: E// comment is about evaluation Apple, similar to previous, solution not needed. Samsung: hash 2 details are missing Huawei: key issue is not concluded, this is only for TR.	noted	No
		S3‑193610	New solution (SERSI – SERving network controlled SI signatures).	Ericsson	pCR	Approval	Yes	YesQC: this is just duplicating existing solution, so note Apple: support solution Samsung: key difference is including PCI and freq in signature, therefore merge into exisiting solution QC: fine in principle, but bring this to next meeting chaiir: try to avoid in next meeting QC: ok make into pCR of solution 7, figure and explanation Orange: what changes in the evalution QC: keep evaluation out. E//. then agree on somtething for next meeting DCM: make pcr adding PCI and DLfreq are input to signature in solution details of solution 7, add ed note to evaluation that impact of new inputs is ffs. this is agreed.	revised	No	S3‑193755
		S3‑193755	New solution (SERSI – SERving network controlled SI signatures).	Ericsson	pCR	Approval	Yes	YesQC: add ed note that evaluation for soultion is FFS or move evaluation ed note to clause above Orange: add FFS to evaluation	revised	No	S3‑193845	S3‑193610
		S3‑193845	New solution (SERSI – SERving network controlled SI signatures).	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193755
		S3‑193490	Conclusion for Key Issue #2	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: disagree to have different soultions for NPN and for public network.	noted	No
		S3‑193498	Conclusin of key issue#2	Apple	pCR	Approval	Yes	YesQC: disagree, provide evaluation for each of the options, first evaluations need to be completed. Orange: there are still some open security issues, type of paper is like discussion paper. E// support Apple DCM: not conclude this before provisioning is defined Huawei: same comment.	noted	No
		S3‑193335	Enabling UE to detect FBS	Huawei, HiSilicon	pCR	Approval	Yes	YesE//: several problems: during handover, measurement is fast, but now SIB information needs to be collected, so introduces delay for handover, no problems are in connected mode, because no handover to FBS. Huawei: this verification is not before handover, this is after E//: how do you verify Huawei: collection is in preparation phase E//: still disagree.	noted	No
		S3‑193439	Security solution for UE to avoid connecting to the false base station during a handover procedure	Intel	pCR		Yes	YesQC: contention free RA is already supported, then why not use that rather than new solution intel: first time handover still succeeds is step 6. E//: attacker can play number 5 preambel as well Intel: This is in evaluation.	noted	No
		S3‑193331	Solution#4: resolving EN network verification of hashes of MIB/SIBs	Huawei, HiSilicon	pCR	Approval	Yes	YesQC: is thisi new solution? Huawei: existing, QC: sounds like different solution Huawei: not different, using OAM for sending additional information QC: not additional information Huawei: resolves ed notes E//: support this.	approved	No
		S3‑193332	Solution#4: Resolving EN Impact on UE power consumption	Huawei, HiSilicon	pCR	Approval	Yes	YesQC: disagree, not only creating hash, wait for RAN reply E//: supoprt this contribution QC: evaluation not true, impact on poser consumption may be larger.	noted	No
		S3‑193333	Solution #4: Details on hash algorithm used for MIB/SIB hashes.	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑193679
		S3‑193679	Solution #4: Details on hash algorithm used for MIB/SIB hashes.	Huawei, HiSilicon	pCR	Approval	Yes	YesQC: why use HMAC when not using key DCM: use SHA 256 E//: ok rewrite to use SHA256.	revised	No	S3‑193756	S3‑193333
		S3‑193756	Solution #4: Details on hash algorithm used for MIB/SIB hashes.	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193679
		S3‑193365	Evaluation on Enriched MR	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: disagree with evaluation, too subjective, limit to postmortem is not true, E//: disagree to many paragraphs, some ok with changes QC: discuss this offline.	noted	No
		S3‑193329	Resolve EN on signaling details of how UE hands over to FBS	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: if FBS operates in same frequency, will it detect it? Huawei: this is not about solution, this is only background information Nokia: ok E//: disagree with solution, but this is ok.	approved	No
		S3‑193330	Resolve second and third EN in Solution #6	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: there is ed note on RAN2 feedback, Huawei: the LS was sent sone time ago Nokia: keep ed note until response is there. QC: same comment bring back 2nd ed note	revised	No	S3‑193757
		S3‑193757	Resolve second and third EN in Solution #6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193330
		S3‑193336	preventing UE from reselecting to FBS	Huawei, HiSilicon	pCR	Approval	Yes	YesE//: no actions should be standarduzed, detection may not be 100% accurate, blacklisting creates new DoS, problems are with idle mode, not connected Ues. Huawei: remove actions or ed note E/: remove blacklisting QC: add several ed notes: Nokia: blacklisting in central, so nothing is left over	noted	No
		S3‑193758	preventing UE from reselecting to FBS	Huawei, HiSilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑193337	Avoiding UE from Suffering More MitM Attacks by Handover	Huawei, HiSilicon	pCR	Approval	Yes	YesE//: does this use blacklisting? Huawei: yes, gNB collects and then informs UE Nokia: how does network know the neighbors Huawei: is that the assumption QC: so what is different from normal handover? Huawei: nothing Nokia: what to do about man in the middle.	noted	No
		S3‑193338	Evaluation of solution #6	Huawei, HiSilicon	pCR	Approval	Yes	YesE//: add that this solution does not mitigate against radio repeater attacks QC: agree with E// add sentence QC add ed note further evaluation is ffs based on RAN2 feedback DCM: repeater is not only an attack., there are also operator deployed repeaters Nokia: but there could be a malicious repeater QC: not may require signalling overhead, make "requires".	revised	No	S3‑193759
		S3‑193759	Evaluation of solution #6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193338
		S3‑193491	Solution for Avoiding UE connecting to False Base Station during Conditional Handover	Huawei, Hisilicon	pCR	Approval	Yes	YesE//: same comments as previous, overhead, malicious radio repeater, sentence in evaluation DCM: does it make sense to document when we know we are not doing anything about it? E//: evaluation is there already, so doesn't need to be touched again QC: same things from previous contribution DCM: there is sentence about neww signalling overhead QC: copy sentence from previous contribution Huawei: change sentence to ivnolves overhead sentence: about radio repeaters, include ed note, say requires overhead.	revised	No	S3‑193760
		S3‑193760	Solution for Avoiding UE connecting to False Base Station during Conditional Handover	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193491
		S3‑193492	LS to RAN1 on Clarification for parameters used to avoid UE connecting to the FBS	Huawei, Hisilicon	LS out	Approval	Yes	Yes	withdrawn	Yes
		S3‑193605	Way forward for KI#3 with respect to handover to a False basestation	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑193339	Conclustion for Key issue #3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193440	Conclusions on Key Issue #3	Intel	pCR		Yes	YesE//: ok with detection, but not for handover Huawei: ok, decide the rest after RAN2 feedback QC: wait for RAN2 feedback and further evaluation ZTE: wait for RAN2 feedback for all DCM: wait for RAN2 feedback for detection, handover, no normative work QC: support DCM Orange: support DCM Huawei: too early. DCM: what are waiting for on handover, what would be the best outcome to supprt handover to FBS prevention E//: LS is only about detection.	noted	No
		S3‑193606	Way forward for KI#4 on protection against SON poisoning	Ericsson	discussion	Endorsement	Yes	YesApple: support this way forward E//: could send an LS to SA5 that measurements could be untrustworthy Orange: not from this meeting, need to discuss internally QC: we previously discussed about measurements reports, make it generic, not only false base station Futurewei: what do we expect SA5 to do with this E//: take this into account Futurewei: how should they know that the report was falsified Orange: it may be more generic than false base station, look more closely before deciding on what and whether to send QC: keep LS generic if sent from next meeting, the 2nd proposal in presentation was to have no normative work E//: not put in that proposal because of what SA5 could respond Apple: can there be an agreement to send an LS, so bring LS directly, so we can focus on content.	noted	No
		S3‑193362	Evaluation against MitM false base station attacks	Qualcomm Incorporated	other	Endorsement	Yes	YesDCM: is there a clear definition of counts as MitM attack QC: stupid relay is not a relay, it s described in key issue 7 Apple: no requirements in key issue 7	noted	No		S3‑192937
		S3‑193448	Resolving the ENs in solution #5	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	YesE//: not sure this attack works, as it is possible to mimic the environment DCM: should be part of evaluation E//: ed note: how the solution is resilient against GPS spoofing and falsifying location related radio environment is FFS QC: second ed note was not addressed Orange: prefer not to have last paragraph of evaluation Apple: in 6.5.2 location granularity whould be as accurate as possible, add ed ntoe what kind of granularity is sufficient. Huawei: location using here is TAI, no other granularity is required, regarding second ed note: solved in first para, because procedure will fail. DCM: unclear how consent is solved.	revised	No	S3‑193835
		S3‑193835	Resolving the ENs in solution #5	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	YesDCM bring back privacy ed note Orange ed note: further evaluation is needed.	revised	No	S3‑193846	S3‑193448
		S3‑193846	Resolving the ENs in solution #5	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑193835
		S3‑193555	Update of Solution #15	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesE//: how is this working reagrding NAS keys and serving network name E//: NAS SMC integrity failure could be because of radio failure Lenovo: that can't happen on NAS, maybe in PDCP E//: ed note: whether NAS layer integrity protection could fail due to radio conditions E//: ed note: are NAS SMC failures only due to causes mentioned in this solution are FFS QC: similar comment, second ed note has not been addressed Lenovo: ok QC:add ed note further evaluation is FFS 1 ed note: NAS failures, bring back ed note on error handling, ednote in evaluation further evaluation is ffs.	revised	No	S3‑193836
		S3‑193836	Update of Solution #15	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑193555
		S3‑193449	Conclusion on KI#5 of TR 33.809	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	noted	No
		S3‑193607	Way forward for KI#5 mitigation against authentication relay.	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑193608	Way forward for KI#6 about the resistance to radio jamming	Ericsson	pCR	Approval	Yes	YesQC: add because it can't be addressed by SA3, include reason no objections to the conclusion, just add the reason.	revised	No	S3‑193837
		S3‑193837	Way forward for KI#6 about the resistance to radio jamming	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193608
		S3‑193609	Way forward for KI#7 about the protection against Man-in-the-Middle false basestation attacks	Ericsson	pCR	Approval	Yes	YesQC: need to evaluate solutions for this one	noted	No
		S3‑193503	5G paging security issue caused by false base station	Apple	pCR	Approval	Yes	YesOrange: is this DoS or ID request attack? Not required a new threat not clear what is leaked QC: paging identifiers are realloceted every time, so not needed Apple: attacker could guess the 5GS TMSI Nokia: all 5G S-TMSI can be discovered after 45h, DCM: bigger problem are cross layer attacks, this is too small a problem to solve.	noted	No
		S3‑193504	solution for new key issue of 5G paging security issue caused by false base station	Apple	pCR	Approval	Yes	Yes	noted	No
		S3‑193506	Meeting minutes of 5GFBS July conference call on July 18th	Apple	discussion	Information	Yes	Yes	noted	No
		S3‑193507	Meeting minutes of 5GFBS August conference call on August 8th	Apple	discussion	Information	Yes	Yes	noted	No
		S3‑193752	Draft TR 33.809	Apple	draft TR	Approval	No	Yes	left for email approval	No
5.6	Security aspects of Enhancement of Network Slicing
5.6.1	Work Item (eNS_SEC)	S3‑193394	draft CR for Security procedures for Network Slices	Nokia, Nokia Shanghai Bell	other	Agreement	Yes	YesBT: is there going to be confusion if there is slice specific secondary authentication E//: there is no such thing Huawei: comments on structure and have own proposal, x.x.1 and x.x.2 are confusing, together with 401 discussion captured under 401	revised	No	S3‑193738
		S3‑193738	draft CR for Security procedures for Network Slices	Nokia, Nokia Shanghai Bell	other	Agreement	Yes	YesIDCC: the steps added in 12 and 13 in 673 are copied from SA2 Nokia: start with the non-conditional cases, there is no disagreement on 673 yet Huawei: only keep first sentence of ed note. BT: authorization should be removed from x.x.3 QC: baseline needs a lot of improvement, not agree this as working baseline, not endorse as living CR, agree on the skeleton Nokia keep baseline up to ed note QC: make clear that this is just a living document.	revised	No	S3‑193857	S3‑193394
		S3‑193857	draft CR for Security procedures for Network Slices	Nokia, Nokia Shanghai Bell	other	Agreement	Yes	Yesthe group agrees that all text in clause x.x.3 may need to be revised.	approved	No		S3‑193738
		S3‑193673	Comments to Draft for ‘proposed structure for network slice security procedures’ in S3-193394	InterDigital Communications	other	Approval	Yes	Yespart of offline discussion Nokia: is anybody objecting these clarification E//: prefers to start with normal flow before looking at optimization for offline discussion Nokia: only up to step 5 has been discussed, see 738, so no decision on the steps in this doc.	noted	No
		S3‑193401	Skeloton for eNS	Huawei, HiSilicon	draftCR	Agreement	Yes	YesNokia: needs an overall clause before coming to slice specific authenticaiton E//: prefer Nokia skeleton IDCC: prefer Nokia BT: agree to general topic heading. QC: agree DCM: are there all three types of authentication possible Nokia: no QC: in principle, it is possible, but secondary auth is orthogonal Nokia: remove authentication from title of x.x.2 TIM: if there is authorization in both, what is the difference? QC: agree, remove authorization from x.x.3, make it security procedures for... discussion on general clause captured under 402. discussion on x.x.2 Huawei: problem with content, very confusing orange: wording needs to be fixed, because it is on authorization. QC: need to have prerequisite to access network, information coming down from UDM, some slices are automaticly authorized Nokia: make this editor's note QC: try in this meeting to get this done. Chair: prefer to close QC: ok, add editor's note: the content of this clause is to be reformulated to capture 3 aspects -> taken offline.	noted	No
		S3‑193402	Introduction to slice-specific authentication	Huawei, HiSilicon	draftCR	Agreement	Yes	YesNokia: merge this, not all is valid DCM: reproduce text given by QC. Nokia: this tdoc is for third para of 3394, so unrelated QC: make this ed note, remove second sentence Huawei: remove third sentence as well Nokia: what is problem with second sentence Thales: it is unclear which authenticatino is meant, so delete for now. QC: ed note: relationship netween teh different types of authentication procedures need to be provided comments on text of 402 E//: align terminology, mention AAA proxy, baseline ok, room for improvement Nokia: specific updates to individual sentences Nokia: not as separate subclause, but in beginning of x.x.3, remove last two sentences, reformulate last sentence of second paragraph: multiple methods are possible.	merged	No	S3‑193738
		S3‑193403	EAP based slice-specific authentication procedure	Huawei, HiSilicon	draftCR	Agreement	Yes	YesNokia: each step descriptiion is different so merge is difficult E//: even call flow is different IDCC: missing the multiplie access, which has been added by SA2 Nokia: Nokia contribution is more correct Huawei: multiple access is in text Nokia: merge in offlien session Huawei: in pleanry, how to handle AUSF: Nokia: that depends on SA reply -> use call flow of Nokia contribution as baseline, work offline E//: step 13, and 14 don't work in 394 Huawei: last two paragraphs of 394 should go away	merged	No	S3‑193738
		S3‑193415	Discussion for EAP method negotiation	Huawei, HiSilicon	discussion	Endorsement	Yes	YesQC: why is this needed, identity defines EAP method Nokia: agree with QC E//: agree with Nokia Huawei: reference is required Nokia: in primary it is known, so similar	noted	No
		S3‑193404	EAP method negotiation	Huawei, HiSilicon	draftCR	Agreement	Yes	YesNokia: disagree, UE says what it can and will do	noted	No
		S3‑193407	Security features for NSaaS	Huawei, HiSilicon	draftCR	Agreement	Yes	Yes	noted	No
		S3‑193648	draft LS to SA2 on the procedure of Secondary authentication	China Mobile Com. Corporation	LS out		Yes	Yes	withdrawn	Yes
5.6.2	Study (FS_eNS_SEC)	S3‑193405	Add Evaluation to solution 3	Huawei, HiSilicon	pCR	Approval	Yes	YesNok: revise the sentence for clarity	revised	No	S3‑193731
		S3‑193731	Add Evaluation to solution 3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193405
		S3‑193406	Conclusion to KI#3	Huawei, HiSilicon	pCR	Approval	Yes	YesNok: Not clear that this require normative work Hua: Needs to be started that this data can be configured Eri: Agree with Nokia that there is no need for normative work QC: Leaning to agree with Nokia Huawei: Should write an LS to SA5 to get feedback on the inclusion.	noted	No
		S3‑193408	Addressing EN in solution 6	Huawei, HiSilicon	pCR	Approval	Yes	YesQC: replace new text by: "if user ID privacy is required, it is protected by the EAP method" Huawei: this solution assumes privacy is required Orange: the requirement is not there, yet.	revised	No	S3‑193734
		S3‑193734	Addressing EN in solution 6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193408
		S3‑193409	Evaluating solution 6	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: needs to be reworded to capture what is said in previous tdoc. Reformulate middle sentence: This solution relies on ID privacy protection by EAP framework. Delete third sentence Huawei: third sentence is correct, just evaluation QC: should be EAP method, not framework.	revised	No	S3‑193735
		S3‑193735	Evaluating solution 6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193409
		S3‑193416	Overall evaluation of solutions addressing KI#4	Huawei, HiSilicon	pCR	Approval	Yes	YesOrange: good discussion, but not include in TR. Huawei: what is the problem, to show what the rationale was QC: adds no value, go straight to conclusion.	noted	No
		S3‑193410	Concluding KI#4	Huawei, HiSilicon	pCR	Approval	Yes	YesQC: not ready to accept yet, but say that EAP method should provide privacy Nokia: none of the solutions requires normative work, so that should be the conclusion Huawei: because some EAP methods don't provide privacy Nokia: then it is a deployment issue Orange: agree, it is a deployment issue, non ormative work is needed. QC: need to make point that slice owner needs to pick the right EAP method. Huawei: yes, specify note, activate NAS and AS security Orange: is this just a Note Huawei: but where to put note It was agreed: There will be a Note in 33.501 adressing the user ID privacy for the slice specific authentication procedure. Orange: change conclusion to "no normative work is needed".	revised	No	S3‑193736
		S3‑193736	Concluding KI#4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193410
		S3‑193411	On service request in solution 8	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: four solutions in the next documents, a lot of overhead in all of them , all are complicated, maybe have an offline for those four documents Huawei: agree DCM: make the proposed text as real text and not NOTE Nok: Need to add EN on idle mode mobility Huawei: This is not ralted to resolution of EN.	revised	No	S3‑193819
		S3‑193819	On service request in solution 8	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193411
		S3‑193412	On Ng-RAN node change in solution 8	Huawei, HiSilicon	pCR	Approval	Yes	YesID: Isn't it a burden to have to give the whole set of UE specific T-S-NSSAIs Huawei: There are different options It was agreed to take the first EN from S3-193675 in the revision of this document.	revised	No	S3‑193820
		S3‑193820	On Ng-RAN node change in solution 8	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193412
		S3‑193675	Nokia comments on S3-193412	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesHuawei does not agree with proposed Ens Eri: OK with solution update and ENs going forward Agreed to take only the first EN.	noted	No
		S3‑193354	Resolving editor’s note on refreshing the parameter in solution #10	Qualcomm Incorporated	pCR	Approval	Yes	YesNokia: feels ed note is only partly addressed, but ok	approved	No
		S3‑193355	Resolving editor’s note on relationship between S-NSSAI and the S-NSSAI identifiers in solution #10	Qualcomm Incorporated	pCR	Approval	Yes	YesIDCC: this is beoming more confusing, encrypted identifier is pseudonym that is shorter, so more elaboration on what is the pseudonym, ed note relationship between S-NSSAI and S-NSSAI identifier needs elaboration E//: are S-NSSAI idnetifier encrypted? QC: yes, that is what is described add ed note.	revised	No	S3‑193821
		S3‑193821	Resolving editor’s note on relationship between S-NSSAI and the S-NSSAI identifiers in solution #10	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193355
		S3‑193395	eNS_Addition to evaluation of solution 10	Nokia, Nokia Shanghai Bell, Ericsson	pCR	Approval	Yes	YesQC: don't need to maintain the all this context, only maintain NSSAI identifier to NSSAI mapping, disagree DCM: state that the NSSAI space is then reduced IDCC: problem to understand the solution E//: share Nokias concerns.	revised	No	S3‑193822
		S3‑193822	eNS_Addition to evaluation of solution 10	Nokia, Nokia Shanghai Bell, Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193395
		S3‑193301	TR 33.813 - update for solution #11	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑193309	TR 33.813 - update for the evaluation for solution #11	InterDigital Communications	pCR	Approval	Yes	YesNokia: 3396 is related together with 3396 Nokia: remove word fully from evaluation in 309 QC: solution doesn't work well, so discuss this offline.	revised	No	S3‑193823
		S3‑193823	TR 33.813 - update for the evaluation for solution #11	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193309
		S3‑193396	eNS_Addition of evaluation to solution 11	Nokia, Nokia Shanghai Bell, Ericsson	pCR	Approval	Yes	YesIDCC: on ed note: based on existing NGAP procedure, so should be clear enough. No per UE context required in RAN. All other parts of ed note also to be refuted E//: support Nokia's ed note Nokia: UE identity in AS layer, how is it learned IDCC: from S-TMSI	revised	No	S3‑193824
		S3‑193824	eNS_Addition of evaluation to solution 11	Nokia, Nokia Shanghai Bell, Ericsson	pCR	Approval	No	Yes	approved	No		S3‑193396
		S3‑193674	Comments to Evaluation for Solution 11 in S3-193396	InterDigital Communications	other	Approval	Yes	Yes	noted	No
		S3‑193517	Resolving ENs of solution #12	ZTE Corporation	pCR	Approval	Yes	YesE//: keep first editor's note Nokia: 676 is comments together with 676 ZTE: this solution has similar to Huawei solution, why not only one ed note Nokia: more ed notes are more helpful, but also ok to say solve idle mode mobillity bring back first ed note, ed note on idle mode mobility to be added	revised	No	S3‑193825
		S3‑193825	Resolving ENs of solution #12	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑193517
		S3‑193676	Nokia comments on S3-193517	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑193518	Evaluation of solution #12	ZTE Corporation	pCR	Approval	Yes	YesNokia: to early to add evaluation without idle mode mobility.	noted	No
		S3‑193317	TR 33.813 – review and comparative evaluation of solution for NSSAI privacy	InterDigital Communications	pCR	Approval	Yes	Yes	noted	No
		S3‑193417	Overall evaluation of solutions addressing KI#6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193677	Nokia comments on S3-193417	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesNokia: prefer 417 Huawei: no time to work on this offline at this meeting, but agree with nokias comments IDCC: some solutions need more details to be evaluated	noted	No
		S3‑193413	Conclusions to KI #6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193496	Conclusion on KI#6	Ericsson, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesNokia: propose to have call before next meeting on NSSAI privacy.	noted	No
		S3‑193553	Clarification on cancellation of rejected S-NSSAIs	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesNokia: next tdoc, on same clauses.	revised	No	S3‑193737
		S3‑193737	Clarification on cancellation of rejected S-NSSAIs	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesNokia disagree with this interpretation of key issue, should be dynamic subscription re-enablement, so beyond the study item. Lenovo: CT1 already added ed note. Huawei: Nokia proposal seems agreeable	noted	No		S3‑193553
		S3‑193397	KI#7 Revocation of rejected NSSAI	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesLenovo: cannot leave it to OAM Huawei: this would be too restrictive Nokia: there is no restriction on the mechanism E//: in overload situation it is marked as pending, not as failed Nokia: if a fraction of NSSAI attaches failes, then it should be possible to reauthenticate without primary auth Lenovo: problem is only external AAA knows when to retry. IDCC: Agree that problem is possible, but not for this group DCM: how does the UE know the reason, load or OAM? Nokia: error code QC: agree with IDCC	merged	No	S3‑193737
		S3‑193554	Solution on Cancellation of rejected S-NSSAIs	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	noted	No
		S3‑193398	Solution for KI#7 revocation of rejected NSSAI	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑193732	draft TR 33.813	Nokia	draft TR	Approval	No	Yes	left for email approval	No
		S3‑193733	LS on configuaration of security policy for NSaaS	Huawei	LS out	Approval	Yes	YesOrange: no reason to send it. Nokia: in SA2, there are many policy configuration mechanisms, let's not include yet another mechanism.	noted	No
		S3‑193809	Notes from evening session on eNSI	Qualcomm	report	Information	Yes	Yes	noted	No
5.7	Security of the enhancement to the 5GC location services (eLCS_Sec)	S3‑193434	Draft CR-living doucment for 5G_eLCS	CATT	draftCR	Approval	Yes	YesMerged into S3-193702 Nok: Is feature optional to use by network or UE	merged	No	S3‑193702
		S3‑193563	Draft CR as a living baseline for 5GS LCS normative work	Ericsson LM	draftCR	Approval	Yes	YesHuawei: Prefer S3-193563 over S3-193434 - add an EN about bluetooth public name and public address is FFS and one about connection to false access point is FFS BT: EN should be about corrupting data collection DCM: Need an EN on linking names to network Interdigital: If the data is collected without vefirication, then it has no value as it could be be faked to provide an attack. QC: Text should be a new Annex.	revised	No	S3‑193702
		S3‑193702	Draft CR as a living baseline for 5GS LCS normative work	Ericsson LM	draftCR	Approval	Yes	YesDCM: copy last two ed notes inito WLAN as well.	revised	No	S3‑193847	S3‑193563
		S3‑193847	Draft CR as a living baseline for 5GS LCS normative work	Ericsson LM	draftCR	Approval	Yes	Yes	approved	No		S3‑193702
5.8	Security for 5G URLLC (5G_URLLC_SEC)	S3‑193476	draftCR for URLLC	Huawei, Hisilicon	draftCR	Approval	Yes	YesLiving document from last time	revised	No	S3‑193699
		S3‑193699	draftCR for URLLC	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑193476
		S3‑193477	change introduction to align with URLLC architect	Huawei, Hisilicon	draftCR	Approval	Yes	YesEri: Propose that could move text out of dual connectivity Huawei: Only one line on redundant bearer in SA2 QC: typo in wording Nokia: Is two path mandatory? Huwaei: It is not manadatory DCM: Language should not be normative where it is SA2 described procedures.	revised	No	S3‑193700
		S3‑193700	change introduction to align with URLLC architect	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑193477
		S3‑193478	clarification on security policy handling	Huawei, Hisilicon	draftCR	Approval	Yes	YesQC: Baseline text is wrong - first sentence of third paragraph is not needed Eri: Have a similar concern	merged	No	S3‑193701
		S3‑193627	Draft CR: UP security policy for URLLC	Ericsson	draftCR	Approval	Yes	YesHuawei: OK with 2nd modification - 1st modification adds redundant text Nok: Agree with Huawei DCM: consider the normative language in the document	revised	No	S3‑193701
		S3‑193701	Draft CR: UP security policy for URLLC	Ericsson	draftCR	Approval	Yes	YesNokia: disagree with preconfiguration, nonode should be preconfigured Huawei: not agree with first change, this has a new comment by Nokia, prefer to note this time Nokia: align with SA2, no point in putting some random statement, policy comes from SMF E//: ed note to check with RAN2 internaly revert back to plenary agreements	revised	No	S3‑193848	S3‑193627
		S3‑193848	Draft CR: UP security policy for URLLC	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑193701
5.9	Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)	S3‑193645	Meeting minutes of VNP_SECAM_SCAS conference call on 25th September	China Mobile	discussion	Information	Yes	Yes	noted	No
		S3‑193649	Add Clarifications to the Scope of Accreditation for 3GPP VNPs	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesCMCC: About EN, do we need to send an LS to the GSMA - maybe from next meeting Eri: Why accreditation process does not need to be used Nok: If consenus, then not needed as previously agreed Huawei: Can remove accreditatio process part Nok: Sentence the same in current SECAM specifications Eri: GSMA is saying that ISO accreditation in needed Taken offline to discuss that part only. Nokia: ok to delete the added sentence in Scope Sentence is to be removed "The same applies ... Desires".	revised	No	S3‑193849
		S3‑193849	Add Clarifications to the Scope of Accreditation for 3GPP VNPs	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193649
		S3‑193650	Add Clarifications to Ultimate Output of SECAM Evaluation	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesCMCC: Concerned specifications not known Hua: Agree with concern Hua: Believe the evidence is required and sentence on no evidence should not be added BT: Thought that the idea was for vendor to get their equipment checked CMCC: There are two ways that SECAM can work two ways DCM: Agree that sentence should not be added	revised	No	S3‑193780
		S3‑193780	Add Clarifications to Ultimate Output of SECAM Evaluation	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193650
		S3‑193651	Add Clarifications to 3GPP virtualized network product evaluation process	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesBT: May want to consider this as a certification scheme due to Cybersecurity act - propose to change the sentence on 'out of scope of SECAM'. Hua: first change change to may makes it optional which not sure is correct	revised	No	S3‑193782
		S3‑193782	Add Clarifications to 3GPP virtualized network product evaluation process	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193651
		S3‑193652	Add Clarifications to Roles in SECAM for 3GPP virtualized network products	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesHuawei: oshould say other SDO than applicable in diagram Nokia: discussion with CMCC: leave out other SDO DCM: why remove other SDOs? CMCC: other SDOs will provide requirements to 3GPP to integrate into SCAS agreement: only change diagram. E//: why is the half sentence added. Nokia: complete sentence, GSMA is curerntly SECAM accreditation body.	revised	No	S3‑193783
		S3‑193783	Add Clarifications to Roles in SECAM for 3GPP virtualized network products	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193652
		S3‑193653	Add Clarifications to SECAM Assurance Level for 3GPP VNPs	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesNokia: offline discussion with CMCC: SECAM assutance level completely differnt from ETSI NFV levels. Remove sentence in ed note. BT: decide on a mapping, rather than on which level. BT: the editor's note needs to be deleted or braought back. mapping is not possible, because NFV assumes starting from bottom (hardware), but SECAM doesn't do that. so delete references to NFV assurance levels. second paragraph on clause 4.8.1 removed, delete editor's note in 4.8.2	revised	No	S3‑193784
		S3‑193784	Add Clarifications to SECAM Assurance Level for 3GPP VNPs	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193653
		S3‑193655	Add Clarifications to Security Baseline for 3GPP VNPs	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑193656	Add Clarifications to SCAS documents structure and content	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesBT: if the direction is to reduce the testing to teh virtual product, then this decision is too early. Huawei: currently prefer to work directly in 33.926. Nokia: the decision is not made BT: but then they are identical for teh NFs to the self contained products. DCM: note document? CMCC: remove the contentious paragraph in 5.1 remove added paragraph in 5.1	revised	No	S3‑193785
		S3‑193785	Add Clarifications to SCAS documents structure and content	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193656
		S3‑193638	Clarifying GVNP model of type 2	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑193639	Adding description for Generic virtualized network product model of type 3	China Mobile	pCR	Approval	Yes	YesBT: in hardware sectino, hardware is not necessarily COTS, maybe in telecoms it is remove that sentence E//: add the same editors note as on type 1 and 2., add ed note which ETSI specifications are being referred to Nokia: on hardware change description of picture: "hardware layer in addition to 3GPP", following sentence:VNF -> VNFC, add word "layer" in hardware. Remove last sentence in clause x.4, ed note under teh diagram, and ed note for reference, + Nokia changes. Nokia: more comments offline.	revised	No	S3‑193786
		S3‑193786	Adding description for Generic virtualized network product model of type 3	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑193639
		S3‑193640	Adding Generic assets and threats of GVNP for type 1 into clause 5.2.3.b	China Mobile	pCR	Approval	Yes	YesNokia: ed ntoe about moving this to 900 series TR CMCC: need to finalize this first, then move over Nokia: ok BT: .b.2.3: say that there are two "relevant" interfaces, because more are defined; b.2.10, list identical to no virtual system, virtualization layer threats need to added, add editor's note keep open for offline	revised	No	S3‑193787
		S3‑193787	Adding Generic assets and threats of GVNP for type 1 into clause 5.2.3.b	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑193640
		S3‑193641	Adding Generic assets and threats of GVNP for type 2 into clause 5.2.3.c	China Mobile	pCR	Approval	Yes	YesBT: this needs more work to defferentiate from nomral scas, but ok to put in. E//: reference etc. as for 640 goes offline	revised	No	S3‑193831
		S3‑193831	Adding Generic assets and threats of GVNP for type 2 into clause 5.2.3.c	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑193641
		S3‑193642	Adding Generic assets and threats of GVNP for type 3 into clause 5.2.3.d	China Mobile	pCR	Approval	Yes	Yes	revised	No	S3‑193832
		S3‑193832	Adding Generic assets and threats of GVNP for type 3 into clause 5.2.3.d	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑193642
		S3‑193643	Adding security requirements into clause 5.2.4	China Mobile	pCR	Approval	Yes	YesNokia: in diagram, ETSI defines GR, GS not TR, TS; in 5.2.4.2. not define a new catalogue, but have it as extension CMCC: can't change figure now, ed ntoe instead BT: replace specified in 5.2.4.2 for identified, as TR doesn't specify ed note to revise figure to change TR and TS to GR and GS for; rephrase first para of 5.2.4.2 to make it into extension instead of addition	revised	No	S3‑193833
		S3‑193833	Adding security requirements into clause 5.2.4	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑193643
		S3‑193657	Add Clarifications to generic virtualized network product model description	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesCMCC: what is the reference [x]? Nokia: will include missing reference CMCC: name of local logical interface, change to execution interface Nokia: maybe rename to execution environment interface DCM: please provide definitino for next time	revised	No	S3‑193834
		S3‑193834	Add Clarifications to generic virtualized network product model description	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193657
		S3‑193644	applying TR33.818 with new 3GPP_TS-TR_Template	China Mobile	draft TR	Approval	Yes	Yes	approved	No
		S3‑193781	Draft TR 33.818	China Mobile	draft TR	Approval	Yes	Yes	left for email approval	No
5.10	Security for 5GS Enhanced support of Vertical and LAN Services
5.10.1	Work Item (Vertical_LAN_SEC)	S3‑193662	LS on SUCI computation from an NSI	CP-192262	LS in		Yes	Yes	postponed	No
		S3‑193368	Reply LS on SUCI computation from an NSI	Qualcomm Incorporated	LS out	Approval	Yes	YesDCM doesn't answer the question QC: there are features that don't work Thales: disagree with QC, currently nothing prevents the two identities Orange: agree with LS, but need to add whether there are security concerns, Orange doesn't see any, respond from next meeting, but should be only one key. Nokia: two identifiers for UE is ok? Orange: yes, but need more time to study.	noted	No
		S3‑193353	Some corrections/clarification for non-public networks annex	Qualcomm Incorporated	draftCR	Endorsement	Yes	Yes	merged	No	S3‑193705
		S3‑193512	CAG ID Privacy for non-public networks	ZTE Corporation	draftCR	Approval	Yes	YesNokia: depends on study item.	noted	No
		S3‑193527	CR CAG ID privacy	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	Yesit depends on study item.	noted	No
		S3‑193528	Removal of ed.note on conformance tests	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	Yes	approved	No
		S3‑193529	Editorial correction of format	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	Yes	revised	No	S3‑193705
		S3‑193705	Editorial correction of format	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	Yes	approved	No		S3‑193529
		S3‑193531	CR Interworking between NPN and PLMN	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	YesE//: depends on result of study Nokia: document in Annex, in SA2, or subclause somewhere else QC: document separate fromm NPN DCM: not in SA2 QC: clarify this is about secondary authentication tdoc name of revision had to be changed to reflect content	revised	No	S3‑193706
		S3‑193706	CR Interworking between NPN and PLMN	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	Yes	approved	No		S3‑193531
		S3‑193532	CR Annex 5GLAN	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	Yes	revised	No	S3‑193707
		S3‑193707	CR Annex 5GLAN	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	YesHuawei: what is the authentication mechanisms DCM: shall be used, not are Huawei: formatting, should this be under same Annex Nokia: no, same study: different topic Huawei: ed note: which authentication mechanism QC: not only auth mechanism, but also SMC, etc.ed note about all security procedures. Nokia: delete second paragraph, DCM: acronyms need to be added, refernce to IEEE TSN to be added tdoc name of revision had to be changed to reflect content	approved	No		S3‑193532
		S3‑193533	CR Annex TSC	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	YesOrange: nothing required in our TS. Huawei: change NPN to SNPN Thales: prefer not to add anything now. Orange: also nothing is required for integrated NPNs. Title should be(to reflect content of contribution): CR Interworking between NPN and PLMN	noted	No
5.10.2	Study (FS_Vertical_LAN_SEC)	S3‑193302	TR 33.819 – update of DH based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑193303	TR 33.819 – update of Hash based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	YesHuawei: what is sufficient length ofCAG ID, where is it defined IDCC: this is a suggested length Huawei: length of CAG needsd to be defined ed note. Nokia: fine as part of solution, because it says e.g. QC: text against FBS is not making claims against active attacks. IDCC: correct	approved	No
		S3‑193308	TR 33.819 – review and comparative evaluation of solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	Yesneed to wait for SA2 IDCC: propose to note all of the CAG conclusions.	noted	No
		S3‑193310	TR 33.819 – evaluation of DH based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	YesQC: after a FBS runs DH, it can run passive attacks, IDCC that was not claimed E//: mention explicitly that it doesn't address active attacks QC: move that to first line IDCC: requirements don't say both QC: remove fully, add "against passive attacks..." to first sentence, combining last and first sentence agreed on last QC comment	revised	No	S3‑193826
		S3‑193826	TR 33.819 – evaluation of DH based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193310
		S3‑193311	TR 33.819 – evaluation of Hash based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	YesQC: does this against a passive attack from a UE in the same CAG IDCC: insider attack QC: not insider, include comment from 310 DCM: this solution does not protect against passive attacks by members of the CAG QC changes and DCM comment agreed	revised	No	S3‑193827
		S3‑193827	TR 33.819 – evaluation of Hash based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193311
		S3‑193456	Adding the evaluation of solution #15	Huawei, Hisilicon	pCR	Approval	Yes	YesE//: support this Nokia: it is modifying the message on the radio interface Huawei: wait for RAN2 response on that Nokia: this comment can come back next time	approved	No
		S3‑193457	Adding conclusion on KI #6.2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193465	Solution for protection of time synchronization	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: need more details, ed note details in line with SA2 specs is FFS	revised	No	S3‑193709
		S3‑193709	Solution for protection of time synchronization	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193465
		S3‑193466	Conclusion on protection of time synchronization	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: postpone to next meeting.	noted	No
		S3‑193467	Remove the EN and add evaluation to solution 6	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193511	Conclusion of CAG ID Privacy	ZTE Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑193322	Editorial corrections for TR 33.819	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193325	Evaluation of solutions addressing Key Issue #6.2	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193523	TR 33.819 update	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesIDCC: don't waste time on CAG ID privacy, wait for SA2 progress.	approved	No
		S3‑193524	Status of TR	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	Yes	noted	No
		S3‑193525	CAG ID privacy solution considering RAN optimization	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑193526	CAG ID privacy conclusion -v1	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑193530	Conclusion to key issue 2.3	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesOrange: no conclusion for this one, noted BT is this related to multiple subscriptions	noted	No
		S3‑193593	Udpate to Solution #3	Samsung	pCR		Yes	YesNokia: what are various factors? Samsung remove "based on various factors", add ed note that factors should be listed Nokia: better come back next time. Samsung: give a few factors in this meeting BT: concerned about dynamic factors in UDM.	noted	No
		S3‑193594	Key Issue #6.1 conclusion	Samsung	pCR		Yes	Yes	noted	No
		S3‑193708	draft TR 33.819	Nokia	draft TR	Approval	Yes	Yes	approved	No
5.11	Study on LTKUP Detailed solutions (FS_LTKUP_Detail)
5.12	Study on User Plane Integrity Protection (FS_UP_IP_Sec)	S3‑193666	Reply to LS on Impersonation Attacks in 4G Networks	R2-1911819	LS in		Yes	YesNok: should full rate by supported from Rel-16 QC: Full-rate can be supported for Rel-15 UEs Samsung: Need non-full rate in Rel-16 for some Ues QC: It is a product and not a standards issue Orange: Need to specify full rate	noted	No
		S3‑193320	Proposal to solve ED notes in solution#4: Zero-overhead user plane integrity protection on the link layer	Philips International B.V.	pCR	Approval	Yes	YesNok and DCM: Not clear what truncated encryption means - explanation would be good in the text Nok: First EN needs to be retained Philips: Explained in new text DCM: Replace EN1 as there is an impact by replacing hardware CRC with cryptgraphic function CMCC: Add sentence on the length of MAC compared to 32 bits QC: Security implications of just protecting the CRC needs to be further study needed	revised	No	S3‑193691
		S3‑193691	Proposal to solve ED notes in solution#4: Zero-overhead user plane integrity protection on the link layer	Philips International B.V.	pCR	Approval	Yes	Yes	approved	No		S3‑193320
		S3‑193369	Proposed conclusion for 5G RAN connected to 5GC	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: Concern that there is a EN in solution so remove reference QC: Ok CMCC: Concern about the performance issues, e.g. some bearers may not require UP IP as performance is more important QC: Proposal is as for solution 2 that UP IP is optional to use CMCC: Propose to add a sentence on the performance QC: Does this mean re-evaulation of existing Rel-15 Apple: Propose to remove the note - this was agreed. DCM: Concerned about the impact on ng-eNB on this conclusion	revised	No	S3‑193698
		S3‑193698	Proposed conclusion for 5G RAN connected to 5GC	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193369
		S3‑193393	Proposed Solution for key issue #6	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: Why only affects only ng-eNB QC: Clarify that this is only for 5G core and not EPC - change the title to make this clear Apple: 2nd paragraph in solution descirprion is not clear QC: OK to remove that paragraph	revised	No	S3‑193692
		S3‑193692	Proposed Solution for key issue #6	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193393
		S3‑193508	Evaluation for Solution#5 in UP IP	Apple	pCR	Approval	Yes	YesCMMC: Do not agree with the figures given in evaluation Apple: Point is that this solution cannot protect all the data packets when limited to 64 kbps	merged	No	S3‑193696
		S3‑193509	Solution to key issue#5 in UP IP	Apple	pCR	Approval	Yes	YesQC: Does not address attack - issue raised at the last meeting not resolved DCM: Not sure that this works well as padding is at the end Apple: Padding is not only at the end but also at the start CMCC: Solution does not work without encryption DCM: needs to adding padding to both beginning and end Nok: Agree with the weaknesses of this proposal and the gain is too small Taken offline for discussion	revised	No	S3‑193694
		S3‑193694	Solution to key issue#5 in UP IP	Apple	pCR	Approval	Yes	Yes	approved	No		S3‑193509
		S3‑193578	Delete the Evaluation for Solution 5 in TR 33.853	China Mobile	pCR	Approval	Yes	YesQC: PDCP is not aware whether traffic is IP or not IP but agree the sentence is not correct	approved	No
		S3‑193579	Resolving Editor’s Note in Solution #1	Samsung	pCR		Yes	YesQC: Do not agree to delete EN as there are other attacks and also SIP signalling not a good example as this has its own protection BT: Needs to consider all control plane protections and other sensitive traffic not just the listed ones DCM: Need to clarify that all the protected data is less than 64Kbits QC: OK if we note other data not protected Nok: is this new capability Samsung: exisiting capability	revised	No	S3‑193695
		S3‑193695	Resolving Editor’s Note in Solution #1	Samsung	pCR	-	Yes	Yes	approved	No		S3‑193579
		S3‑193580	Add the Evaluation to Solution 5 in TR 33.853	China Mobile	pCR		Yes	YesQC: All the parts of the evaluation need to be re-written Nok: Need to detremoine if just header or the whole packets needs to be protected QC: Agree with this but that there are many other issues as well	revised	No	S3‑193696
		S3‑193696	Add the Evaluation to Solution 5 in TR 33.853	China Mobile	pCR	-	Yes	Yes	approved	No		S3‑193580
		S3‑193581	Conclusion to Key Issue #5	Samsung	pCR		Yes	YesQC: does not agree with the conclusion.	noted	No
		S3‑193646	UPIP: update of solution #7 and addition of evaluation	Ericsson	pCR		Yes	YesQC: Please the impacted elements to the evaluation and also an EN on consideration of mixed deployments where some elements are upgraded Nok: Why do we need an indication if this mandatory for Rel-16 Ues QC: There are multiple ways of indicating this capability of which this is one	revised	No	S3‑193697
		S3‑193697	UPIP: update of solution #7 and addition of evaluation	Ericsson	pCR	-	Yes	Yes	approved	No		S3‑193646
		S3‑193659	pCR to TR33.853 on Migration paths for network deployment	NTT DOCOMO INC.	pCR	Approval	Yes	YesApple: Don't believe the key issue is in scope of the TR DCM: Ignoring this will mean that we will end up with something that will not be deployed Nokia: Second point in particular had architectural impacts DCM: Proposed text is an 'or' as there are multiple ways to do this Huawei: Requirements are very solution specific - is it possible to reword them BT: Supportive of this contribution as it covers the network constraints Orange: Also supportive of this proposal Apple: Are these really criteria for evaluation of each solution DCM: The threats are raising security concerns QC: Don't understand the requirements Chair asked for who objects to the key issue: Phillips, Ericsson, Nokia & Huawei Chair asked for who supports the key issue: Orange, BT, DCM & KPN.	noted	No
		S3‑193693	Draft TR 33.853	NTT DOCOMO INC.	draft TR	Approval	Yes	Yes	approved	No
5.13	Study on Security Impacts of Virtualisation (FS_SIV)	S3‑193318	FS_SIV TR 33.848 v030c	BT plc	pCR	Agreement	Yes	YesThales: Why is there a reference to SCASS BT: Could be done by reference to specs inside 3GPP, specs outside 3GPP or by restricting the text cases Thales: But where are the solutions? BT: It is contribution driven and up to people to bring the solution for issue. Where it says 'inside SCASS' , it means that a text case in 3GPP is proposed outcome. Thales: Concerned about the terms used - DSE DCM: Propose reverting DSE chnage in 5.8.1 and adding an EN on generalising TPM/HSM and remove definition of DSE	revised	No	S3‑193749
		S3‑193749	FS_SIV TR 33.848 v030c	BT plc	pCR	Agreement	Yes	Yes	approved	No		S3‑193318
		S3‑193328	TR 33.848 Scope Update	BT plc	pCR	Agreement	Yes	YesDCM: Expand CNI abbreviation	revised	No	S3‑193751
		S3‑193751	TR 33.848 Scope Update	BT plc	pCR	Agreement	Yes	Yes	approved	No		S3‑193328
		S3‑193371	TR 33.848 Security Requirements for Key Issue 17 (resubmission of S3-192559)	NCSC	pCR	Approval	Yes	Yes	merged	No	S3‑193741
		S3‑193372	TR 33.848 Security Threats and Requirements for Key Issue 16 (resubmission of S3-192558)	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑193742
		S3‑193742	TR 33.848 Security Threats and Requirements for Key Issue 16 (resubmission of S3-192558)	NCSC	pCR	Approval	No	Yes	approved	No		S3‑193372
		S3‑193373	TR 33.848: Security Requirements for Key Issue 18 (resubmission of S3-192560)	NCSC	pCR	Approval	Yes	Yes	noted	No
		S3‑193374	TR 33.848 Security Requirements for Key Issue 19 (resubmission of S3-192561)	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑193773
		S3‑193773	TR 33.848 Security Requirements for Key Issue 19 (resubmission of S3-192561)	NCSC	pCR	Approval	Yes	Yes	noted	No		S3‑193374
		S3‑193375	TR 33.848 Security Threats and Requirements for Key Issue 21 (resubmission of S3-192562)	NCSC	pCR	Approval	Yes	Yes	merged	No	S3‑193775
		S3‑193376	TR 33.848 Annex – Virtualisation Security Questions (resubmission of S3-193089)	NCSC	pCR	Approval	Yes	YesThales. Should not be a guideline that SA3 provides. Should be out of scope DCM: make this in format of evidence to a requirement BT: put this into document Orange: some are SCAS related, others are more NESAS related, prefer not to put this into TC cyber DCM: prefer to keep this here Orange: should ask GSMA if they will deal with virtualization, send LS Thales: ok to have this content, but this informative annex is the wrong way	noted	No
		S3‑193399	Threats and Requirements for Key Issue #8	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193739
		S3‑193739	Threats and Requirements for Key Issue #8	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193399
		S3‑193400	Threats and Requirements for Key Issue #13	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193740
		S3‑193740	Threats and Requirements for Key Issue #13	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193400
		S3‑193418	Threats and Requirements for Key Issue #17	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193741
		S3‑193741	Threats and Requirements for Key Issue #17	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesOrange: avoid requirements on actor's, requirements on parts of infrastructure BT: replace by 3GPP network Orange: ok DCM: still unclear BT: then delete first requirement, remove "by the operator" from third requirement Nokia: add catalogue to third requirement remove fist req, add catalogue to third, remove by the operator.	revised	No	S3‑193828	S3‑193418
		S3‑193828	Threats and Requirements for Key Issue #17	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193741
		S3‑193419	Threats and Requirements for Key Issue #18	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193743
		S3‑193743	Threats and Requirements for Key Issue #18	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193419
		S3‑193420	Threats and Requirements for Key Issue #20	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193774
		S3‑193774	Threats and Requirements for Key Issue #20	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesDCM: protected by operators doesn't work Orange: remove "by operator's" in requirement, no requirement on actors update requirement	revised	No	S3‑193829	S3‑193420
		S3‑193829	Threats and Requirements for Key Issue #20	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193774
		S3‑193421	Threats and Requirements for Key Issue #21	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193775
		S3‑193775	Threats and Requirements for Key Issue #21	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193421
		S3‑193422	Threats and Requirements for Key Issue #22	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑193424	Threats and Requirements for Key Issue #23	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193776
		S3‑193776	Threats and Requirements for Key Issue #23	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193424
		S3‑193425	Threats and Requirements for Key Issue #24	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193777
		S3‑193777	Threats and Requirements for Key Issue #24	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑193425
		S3‑193427	Discussion on Categorization of the Key Issues	Nokia, Nokia Shanghai Bell	pCR	Endorsement	Yes	Yes	noted	No
		S3‑193750	Draft TR 33.848	BT	draft TR	Approval	Yes	Yes	approved	No
		S3‑193830	LS on virtualization security assurance	Orange	LS out	Approval	Yes	Yes	approved	No
5.14	Study on authentication enhancements in 5GS (FS_AUTH_ENH)	S3‑193414	New key issue on PFS	Huawei, HiSilicon	pCR	Approval	Yes	YesE//: similar proposal in 601 together with 601	noted	No
		S3‑193601	Existing authentication procedure lacking PFS property	Ericsson	pCR	Approval	Yes	YesOrange: what is the problem E//: PFS is the problem CMCC: agree with E//, enhance the authentication, solve the issue if long term key is leaked, could revise auth protocol, or do something else to prevent long term key leakage BT: balance between prevention, detection and response Huawei: support E// paper, in security requirerment remove "if", or say provide forward security DCM: need to see whether this is worth it considering the data is only protected over the air Thales: decision already some meetings ago not to study BT: need to document whether or not it is worth it. Show of hands who supports this key issue: CMCC, BT, Aple, E//, Huawei, ZTE, Nokia; objects: Thales, Orange	noted	No
		S3‑193451	Resolving the ENs in KI#3.1	Huawei, Hisilicon	pCR	Approval	Yes	YesE//: still not aligned with the study Huawei: explained in the paper E//: this is not part of the objectives Huawei: then keep first ed note E//: ok DCM: needs editorial rewrite Nokia: when UE is deregistered, UE context is not cleaned up, is this the problem. Huawei: could be a problem Nokia : clean up on next deregistration, when there is error, there should be clean up in error case QC: similar to Nokia, are we trying to route NAS traffic through teh home network E//: more details on attack, bring back ed note QC: couldn't the AMF not launch the same attack by overbilling Nokia: add editor's note TIM: too many additional editor's note being added, bring another proposal	noted	No
		S3‑193636	Discussion on the SUPI guessing attack	China Mobile	discussion	Discussion	Yes	Yes	noted	No
		S3‑193637	Key issue to mitigate the SUCI guessing attacks in TR 33.846	China Mobile	pCR	Approval	Yes	YesDCM: how to deal with threats that we decided to be not relevant Orange: agree, maybe remove threats and requirements E//: same problem, keep threat, add editor's note Nokia: can'T determine on individual SUPI DCM: ed note: impact of threat is FFS Orange: have threat: the attacker is able to determine whether a SUPI belongs to a given network, + ed note ed note, Orange's sentence on threat, remove requirements - FFS	revised	No	S3‑193810
		S3‑193810	Key issue to mitigate the SUCI guessing attacks in TR 33.846	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑193637
		S3‑193319	33:846: mitigation against linkability attack	THALES	pCR	Approval	Yes	YesBT: does this need a new USIM, or can this be done with OTA Thales: not OTA BT: document that this means change of USIM Orange: this solution requires change of the USIM Nokia: step 5, and step 7 are authentication procedures, how is the USIM to know that ti needs to resynch failure Thales: in case synch error, it will respond with a random, then the network wills start resynch procedure, USIM will know that is required Nokia: there may be new threats Thales: ok to add ed note Nokia: ed note threat analysis for authentication resynch will need to be done. Huawei: step 3 need a unified failure cause Thales: UICC will see different causes, but for network and ME it will not be detected Huawei: ed note: whether unified failure cause is FFS QC: if SUPI is known, this doesn't work against active attack. now this requires two passes for sync, after 3 failures the UE will block the network sentence in evaluation, ed note on threat, on unified failure cause, offline for QC attack	revised	No	S3‑193811
		S3‑193811	33:846: mitigation against linkability attack	THALES	pCR	Approval	Yes	Yes	approved	No		S3‑193319
		S3‑193356	Using MACS to provide freshness for the protection of SQN during a re-synchronisation procedure in AKA	Qualcomm Incorporated	pCR	Approval	Yes	YesOrange: add to evaluation that USIM needs to be changed, no impact of visited network Huawei:have to assume that MAC-S is trusted? QC: just one extra input to AK Thales: think solution is correct ZTE: there may be problem of performance Orange: no issue Nokia: how feasible is algorithm update over OTA Orange: added this sentence in eval eval: this solution requires changing the USIM	revised	No	S3‑193812	S3‑192921
		S3‑193812	Using MACS to provide freshness for the protection of SQN during a re-synchronisation procedure in AKA	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193356
		S3‑193450	New solution for linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: add two sentences: visited network is impacted, and not R15 compatible to evaluation E//: needs public key, another UE could impersonate the response, so not clear where failure message is coming from, unclear whether ME or USIM do calculation, impact of MAC failure message size is FFS: add ed note regarding this BT: if SUCI protection is not there, then there is dependency Thales: solution relies on availability of key for SUCI, add ed note. sentence in evaluation, (Orange, Thales), 3 ed notes (E//)	revised	No	S3‑193813
		S3‑193813	New solution for linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193450
		S3‑193515	Structure RAND for authentication	ZTE Corporation	pCR	Approval	Yes	YesE//: as instances come and go in virtual environment start-up time is FFS Orange: don't understand what are threats and requirements to be covered, so not include the solution DCM: how does home network know that ME is capable of this solution ZTE: doesn't know.	noted	No
		S3‑193635	Clarification to the usage of Kausf for solution #2.2 in TR 33.846	China Mobile	pCR	Approval	Yes	YesNokia: how can KAUSF work on the failed procedure. Orange: if there is no previous KAUSF, then there is no protection, add ed note: security of using KAUSF=0 is FFS	noted	No
		S3‑193460	Address the EN and add evaluation in solution 2.3	Huawei, Hisilicon	pCR	Approval	Yes	YesE//: ed note in evalution: NAS procedure impact is FFS Orange: statement: this solution impact the visisted network ed note on NAS preocedure, sentence on visited network impact	revised	No	S3‑193814
		S3‑193814	Address the EN and add evaluation in solution 2.3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193460
		S3‑193452	New solution for removing the authentication result from the UDM	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑193459	solution on AUTS derivation to protect SQN	Huawei, Hisilicon	pCR	Approval	Yes	YesQC: there is no non-malleable block cipher for 48 bit, Orange: impact on Milenage and TUAK TIM: also new UICCs needs to be written QC: no arrow down form AK in diagram replace eval text, solution requires a major change of auth algorithms, and the examples defined in 3GPP (Milenage and TUAK), solution requires change of USIM	revised	No	S3‑193815
		S3‑193815	solution on AUTS derivation to protect SQN	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193459
		S3‑193516	Conclusion on linkability issues	ZTE Corporation	pCR	Approval	Yes	YesThales: too early for conclusions	noted	No
		S3‑193850	draft TR 33.846	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
5.15	Security for NR Integrated Access and Backhaul
5.15.1	Work Item (NR_IAB_Sec)	S3‑193669	LS on the IAB-indication to core network	R3-194787	LS in		Yes	Yes	noted	No
		S3‑193564	[Draft CR]Solution for IAB Architecture	Samsung	draftCR		Yes	YesBT: the IAB node needs to be protected like a gNB Samsung: add in next meeting together with 611	revised	No	S3‑193808
		S3‑193808	[Draft CR]Solution for IAB Architecture	Samsung	draftCR	-	Yes	Yeswill be living document for next meeting Orange: needs to remain as skeleton only	approved	No		S3‑193564
		S3‑193611	DraftCR –Security handling for IAB	Ericsson	draftCR	Approval	Yes	YesQC: prefer Samsung proposal Nokia: need some merger, start with Samsung proposal Nokia: there is no IAB network, it is an IAB node QC: diagram shows IAB architecture, not security architecture QC: approach is model after SNPN, disagree with that approach, prefer the main clauses of 501 and 401 offline, merge into 808 Todor: no coontent from was taken from 611 Samsung: correct	merged	No	S3‑193808
5.15.2	Study (FS_NR_IAB_Sec)	S3‑193565	Updates to Solution #2.1 on MT functionality	Samsung	pCR		Yes	YesE//: is this copy paste from SA2 Samsung: yes Huawei: Note how the IAB node… within UICC is not used, Thales: why is the note there at all Nokia: in 23.501, IoB node has gNB functionality, could be many platforms QC: comment on paragraph above node, bacuse with EPC, there is no EAP support. should be treated as UE in 33.501. prefer the defined primary authentication methods. Samsung: may be true for one kind of implementation DCM: stick to existing authentication mechanisms Nokia: need to be flexible, Huawei: maybe treat IAB as NPN UE Samsung: restrict option for EPC.	revised	No	S3‑193788
		S3‑193788	Updates to Solution #2.1 on MT functionality	Samsung	pCR	-	Yes	YesThales: remove the note, sentence above should be removed, if it is a PLMN, it should AKA Samsung ok with removing note E//: but keep EAP TLS above Orange: against supporting the note and para above: Nokia, E//, Huawei, Samsung; objecting: BT, Thales, Orange Orange: removed text also related to teh discussion	revised	No	S3‑193851	S3‑193565
		S3‑193851	Updates to Solution #2.1 on MT functionality	Samsung	pCR	-	Yes	YesBT: without Note, it is ok QC: ok with this, but add subscription credential in yellow marked text.	revised	No	S3‑193855	S3‑193788
		S3‑193855	Updates to Solution #2.1 on MT functionality	Samsung	pCR	-	Yes	Yes	noted	No		S3‑193851
		S3‑193567	Evaluation of solution #2.1	Samsung	pCR		Yes	YesDCM: ok, problem is only whether we restrict further	revised	No	S3‑193789
		S3‑193789	Evaluation of solution #2.1	Samsung	pCR	-	Yes	Yes	noted	No		S3‑193567
		S3‑193464	Evaluation of solution#2.1	Huawei, Hisilicon	pCR	Approval	Yes	YesE//: ast sentence should go, looks like solution.	merged	No	S3‑193789
		S3‑193568	Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (MT)	Samsung	pCR		Yes	YesQC: solution 2.1 is open DCM: be more specific what will be normative Nokia: fine with the contribution as is Chair only Note and para above is open of 2.1 Thales: same problem, keep open	revised	No	S3‑193790
		S3‑193790	Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (MT)	Samsung	pCR	-	Yes	Yes	noted	No		S3‑193568
		S3‑193357	F1 security establishment	Qualcomm Incorporated	pCR	Approval	Yes	YesNokia: DU setup is basically is a wireline interface. Defined solution may not scale DCM: VPN is used in many corporates at scale QC: this is a solution proposal, so what is the problem Huawei: ed note what is the difference between wireless and wireline. Nokia: solution can go in, but need to capture in evaluation	approved	No
		S3‑193358	Evaluation on Solution #3.1: F1 security context establishment	Qualcomm Incorporated, Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑193791	Evaluation on Solution #3.1: F1 security context establishment	Qualcomm Incorporated, Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑193572	Evaluation of solution #3.1	Samsung	pCR		Yes	YesQC: unclear where the requirement comes from. E//: support QC, interface security should look the same for wireless and wireline Nokia: prefer 572 QC: why one credential, how do you attach to management server.	noted	No
		S3‑193359	Conclusion on KI #4.1: F1 interface security	Qualcomm Incorporated, Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑193792
		S3‑193573	Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (gNB-DU)	Samsung	pCR		Yes	YesDCM: think about platform security keys Samsung: IAB has gNB requirements, so no platform security	revised	No	S3‑193792
		S3‑193792	Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (gNB-DU)	Samsung	pCR	-	Yes	Yesorange: from where to where IPsec is established QC: delete last three sentences	revised	No	S3‑193856	S3‑193573
		S3‑193856	Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (gNB-DU)	Samsung	pCR	-	Yes	YesE//: not ok	noted	No		S3‑193792
		S3‑193462	Discussion on binding between USIM/UICC and IAB-node	Huawei, Hisilicon	pCR	Discussion	Yes	Yes	noted	No
		S3‑193463	Key issue on removal of UICC card in IAB node	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: agree with first requirement, but second requirement assumes removable UICC, should go away BT: support second requirement staying, to remove Huawei: competing 654 together with 654	revised	No	S3‑193793
		S3‑193793	Key issue on removal of UICC card in IAB node	Huawei, Hisilicon	pCR	Approval	Yes	YesBT: agrees Orange: don't include primary authenticaiton	revised	No	S3‑193852	S3‑193463
		S3‑193852	Key issue on removal of UICC card in IAB node	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No		S3‑193793
		S3‑193654	UICC removal from IAB-node	THALES	pCR	Approval	Yes	YesDCM: a bit like a solution, but threats are valid QC: question whether threats exist in case same key is used E//: first sentence sounds like IAB always conatins UICC DCM: if no UICC is used, then key could be stolen in a different way offline try to merge into 793	merged	No	S3‑193793
		S3‑193519	New key issue on protection against Man-in-the-Middle false IAB node attacks	ZTE Corporation	pCR	Approval	Yes	YesHuawei: merge with 793 E//: not related, one has to break F1 security Nokia: disagree with tdoc QC: disagree with tdoc	noted	No
		S3‑193521	Editorial correction to TR 33.824	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑193807	draft TR 33.824	Samsung	draft TR	Approval	No	Yes	left for email approval	No
5.16	Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)	S3‑193667	Reply LS on protection of PC5-RRC messages for sidelink unicast communication	R2-1911863	LS in		Yes	Yes	noted	No
		S3‑193665	LS on NR V2X Security for user plane data and PDCP SN size	R2-1911681	LS in		Yes	Yes	replied to	No
		S3‑193854	Reply to: LS on NR V2X Security for user plane data and PDCP SN size	LG	LS out	approval	Yes	Yes	approved	No
		S3‑193350	Discussion for a response LS on NR V2X Security for user plane data and PDCP SN size	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑193426	[draft] reply LS on NR V2X Security for user plane data and PDCP SN size	LG Electronics France	LS out		Yes	Yes	revised	No	S3‑193778
		S3‑193778	[draft] reply LS on NR V2X Security for user plane data and PDCP SN size	LG Electronics France	LS out	-	Yes	YesQC: include key ID, confirm LCID are input to keystreams, in Q2, add key ID, 12 bit requires faster rekeying.	revised	No	S3‑193854	S3‑193426
		S3‑193304	33.836 - solution #1 update	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑193312	33.836 – evaluation for the Solution #1	InterDigital Communications	pCR	Approval	Yes	YesQC: SA2 link layer is two roundtrip, this is 3 roundtrips, analysis needs to be done IDCC: ed note how to address mismatch with SA?2 QC: ed note: securtiy comparison with SA2 solution for link layer update is FFS DCM: remove and/or ed note and and/or	revised	No	S3‑193795
		S3‑193795	33.836 – evaluation for the Solution #1	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193312
		S3‑193307	TR 33.836 solution #4 update	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑193316	TR 33.836 – evaluation of the solution #4	InterDigital Communications	pCR	Approval	Yes	YesQC: this requires partial ciphering to direct SMC command, adds complexity: add editors note: compleity of adding partial ciphering to the direct security mode command compared to the benefit of the simultaneous updates is FFS. Ed note	revised	No	S3‑193796
		S3‑193796	TR 33.836 – evaluation of the solution #4	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193316
		S3‑193345	Providing some analysis to solution #9 in TR 33.836	Qualcomm Incorporated	pCR	Approval	Yes	YesIntel: disagree with all of the evaluation: no regulatory requirements, credential provsioning KMS is responsible, there are options available, what has privacy to do with credentials, can be achieved by changing session keys, credentials are never exposed.	noted	No
		S3‑193429	Resolution of Editors notes for Key issue 1 and 8	LG Electronics France	pCR		Yes	Yes	approved	No
		S3‑193305	TR 33.836 - update for solution #2	InterDigital Communications	pCR	Approval	Yes	YesLG: this doesn't adhere to SA2 TS, There only initiating UE sends TCR, here the responding also sends TCR QC: agree, but part of the solution, so put this into the evaluation. Add ed note don't add note	revised	No	S3‑193797
		S3‑193797	TR 33.836 - update for solution #2	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193305
		S3‑193314	TR 33.836 - evaluation for the solution #2	InterDigital Communications	pCR	Approval	Yes	YesQC: ed note, similar to other IDCC contribition. "Justification for the difference to SA2 call flow is FFS" QC: remove last sentence ed note, remove last sentence	revised	No	S3‑193798
		S3‑193798	TR 33.836 - evaluation for the solution #2	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑193314
		S3‑193306	TR 33.836 - solution #3 update	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑193315	TR 33.836 - evaluation for the solution #3	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑193347	Resolving the editor’s note on RRC security establishment in solution #8	Qualcomm Incorporated	pCR	Approval	Yes	YesIDCC: Why does PC5 use the same algorithms QC: because it has the same termination point IDCC: make this clear DCM: make note to shall QC: ok IDCC want reasoning QC: part of evaluation IDCC: keep as is. No changes	approved	No
		S3‑193348	Resolving the editor’s note on operator knowledge of keys in solution #8	Qualcomm Incorporated	pCR	Approval	Yes	YesIntel: doesn't resolve teh issue QC: if no confidentiality is provided, then LI is solved. No changes	approved	No
		S3‑193346	Providing some analysis to solution #8 in TR 33.836	Qualcomm Incorporated	pCR	Approval	Yes	YesIntel: new key issue related to this DCM: ed note (conditional: on accepting new key issue) evaluation regarding new key issue is FFS IDCC: simiultaneous changes are needed, so this is against SA2 QC: this can only happen when you change the certificate when trying to change ID, so disagree with this statement IDCC: editors note:conformance to SA2 TS23.287 clause 5.6.1.1 is FFS LG: no relationship. QC is correct IDCC: shouldn't be decoupled DCM add ed note, QC: privacy on two levels, application and on link. try to work offline on this as alternative to ed note conditional ed note, resolution or ed note, clause heading 6.8.3 conditional ed note not necessary based on outcome of 520	revised	No	S3‑193799
		S3‑193799	Providing some analysis to solution #8 in TR 33.836	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193346
		S3‑193349	Proposed solution for protecting the V2X PC5 traffic at the PDCP	Qualcomm Incorporated	pCR	Approval	Yes	YesLG: this is unicast, so is key ID required? QC: in Uu, handover is used, do break then make, here you can whange key in active communication no changes	approved	No
		S3‑193351	Solution for the activation of user plane security in NR PC5 unicast	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: reuse activation, why define a different policy for UP ini PC5? QC: add editor's note: details on the user plane activation policy is FFS ed note	revised	No	S3‑193800
		S3‑193800	Solution for the activation of user plane security in NR PC5 unicast	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193351
		S3‑193454	New solution for PC5 layer key derivation using the 5G network keys	Huawei, Hisilicon	pCR	Approval	Yes	YesQC: how does the application derive the PC5 link key? Huawei: several assumptions: UE is connected to network, has key to derive, not out of coverage Intel: agree wirth QC QC: accept the limitiation, why do this if there is a solution for out of coverage.Ed note: what happens on UE out of coverage? Huawei: 6.8.2 gives this.limitation, and also the benefit af allowing the operator QC: ed note: how the UE establishes PC5 security when out of coverage is FFS, what happens when the UEs are on different PLMNs Huawei: described in step 2 QC, only one ed note is ok, then QC: step 7, how is senidng the PC5 key securedin case of different PLMNs ed note on out of coverage	revised	No	S3‑193801
		S3‑193801	New solution for PC5 layer key derivation using the 5G network keys	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193454
		S3‑193352	Discussion on protection of messages for V2X PC5 unicast	Qualcomm Incorporated	discussion	Endorsement	Yes	YesIDCC: support LS QC one or two LSs. Send LS based on the discussion paper	noted	No
		S3‑193342	Solution for privacy of link layer IDs in broadcast and groupcast	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑193522	A solution against V2X UE tracking based on PC5 identifiers	Ericsson LM	pCR	Approval	Yes	YesLenovo: this is about L2 destiantion Ids? QC: source Ids QC: ok to approve this, and note 342 IDCC: what about privacy of groupcast? Put ed note, privacy of gorupcast is FFS QC: that is attempted to solve in Lenovo contribution IDCC: but that doesn't change the group ID Lenovo: it does no changes	approved	No
		S3‑193343	Conclusion on privacy for groupcast and broadcast	Qualcomm Incorporated	pCR	Approval	Yes	YesQC update to point to 522 soltuion Huawei: is privacy only based on source id only, make this specific add "for source layer 2 id"	revised	No	S3‑193803
		S3‑193803	Conclusion on privacy for groupcast and broadcast	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193343
		S3‑193557	Identifier conversion in groupcast communication	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesHuawei: second last sentence first para, why in oder not to signal Lenovo: so in order not to update Huawei: so interval dT is fixed.problem with time synchronization QC: remove evaluation line, basically application layer manages time interval IDCC: use time for synchronization, use unprotected SIB or unprotected time source. add ed note on how to deal with spoofed time source is ffs DCM: changing of group id may identify group members BT: how to deal with impact on availability is ffs remove evaluation, ednote from IDCC and BT	revised	No	S3‑193804
		S3‑193804	Identifier conversion in groupcast communication	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑193557
		S3‑193556	Update of solution #6	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	noted	No
		S3‑193344	Proposed conclusion of security for groupcast	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: if there is a key issue groupcast, then there should also be a key issue for broadcast Lenovo: agree for broadcast, disagree with groupcast conclusion QC: who supports work on groupcast. Supporting no normative work for groupcast: QC, ZTE, LG, Huawei; objecting, Lenovo, IDCC conclusion only about broadcast, include rationale	revised	No	S3‑193805
		S3‑193805	Proposed conclusion of security for groupcast	Qualcomm Incorporated	pCR	Approval	Yes	YesQC: keep both group and broadcast., there is a new split key issue on groupcast and broadcast Huawei: no normative work for groupcast for R16 Huawei: change title to include broadcast	revised	No	S3‑193853	S3‑193344
		S3‑193853	Proposed conclusion of security for groupcast	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑193805
		S3‑193430	Resolution of Editors notes for Key issue 6	LG Electronics France	pCR		Yes	Yes	approved	No
		S3‑193321	Adding evaluation to solution #7	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193323	Conclsion to Key Issue #7	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193327	New solution to minimize the impact on the application layer communication	Huawei, HiSilicon	pCR	Approval	Yes	YesE//: how does it work while maintaining unicast connections Huawei: see figure no changes	approved	No
		S3‑193431	Conclusion for Key issue 10	LG Electronics France	pCR		Yes	Yes	revised	No	S3‑193779
		S3‑193779	Conclusion for Key issue 10	LG Electronics France	pCR	-	Yes	YesHuawei: postpone to next meeting, SA still has some concern, also procedure defined in SA6	noted	No		S3‑193431
		S3‑193453	New solution for UP security policy handling for PC5 and Uu interface	Huawei, Hisilicon	pCR	Approval	Yes	YesQC: policy for PC5 and Uu should be sufficient, local policy should be enough. Huawei: SA6 has defined a procedure for switching. IDCC: path switching is part of 5G ProSe, wait for 5G ProSe Huawei: TR is just study, so put it here as key issue, and study next meeting LG: include ed note to say we wait for SA2 Nokia: prefer to postpone this and wait for SA2 to define this. Huawei: ok with ed note.	noted	No
		S3‑193324	New Key Issue on Security of broadcast eV2X messages over PC5	Huawei, HiSilicon	pCR	Approval	Yes	YesE//: don't support this key issue LG: also doesn'T support this DCM: give reasoning, ok with no requirement BT: problem with not including it, integrity is important QC: on unicast the bearer may also be malicious QC: inlcude rationale from discussion document in conclusion offline whether required,	revised	No	S3‑193806
		S3‑193806	New Key Issue on Security of broadcast eV2X messages over PC5	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑193324
		S3‑193436	Minimizing dependency on application layer security	Intel	pCR		Yes	YesQC: privacy requirements will be driven by application E//: supporting QC	noted	No
		S3‑193520	New key issue on security for multi-USIM communication over UU and PC5	ZTE Corporation	pCR	Approval	Yes	YesIDCC: there is no security component, not SA3 issue, threats missing Nokia: this is not scope in our group QC: not in scope here	noted	No
		S3‑193326	Editorial corrections for eV2X TR 33.836	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: sentence on broadcast is not editorial QC: agree to this sentence no changes	approved	No
		S3‑193495	New solution on KI #9 minimizing the impact of privacy protection mechanism in the application layer communication	Huawei, Hisilicon	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑193794	new draft TR 33.836	LG	draft TR	Approval	No	Yes	left for email approval	No
		S3‑193802	LS on PC5S and PC5 RRC unicast message protection	Qualcomm	LS out	Approval	Yes	Yes	approved	No
5.17	Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)	S3‑193534	KI on Protection of authentication subscription data stored in UDR	Nokia, Nokia Shanghai Bell	other	Approval	Yes	YesKPN: Key issue is above transport and storage - better to split this into two key issues as only last sentence is about transfer Thales: modifcation of data need to authorised as well DCM: Needs security threat on confidentiality of data and also a threat on copying data to another subcription plus associated requirement TI: Need to understand what is the sensitive data and subscription authentication data KPN: Mention of transfer should also be deleted Vdf: Support DCM new threat	noted	No
		S3‑193535	KI on Separation of authentication subscription data from subscription data	Nokia, Nokia Shanghai Bell	other	Approval	Yes	YesCMCC: More of an implementation issue rather than a security issue as too difficult to separate them KPN: Support this key issue BT: support this key issue - modify to make it "stored and managed" separately CMMC: Feel that separtion is a soluiton and not a requirement BT: Biggest threat is people who are runnung the the network should not get access to the more sensitive data ID: Separate treatment of data is common DCM: Reformulate the requirement to compartmentalize the the data rather than store it separately TI: Propose EN that the used terms need to be defined Hua: Support CMCC comments	revised	No	S3‑193747
		S3‑193747	KI on Separation of authentication subscription data from subscription data	Nokia, Nokia Shanghai Bell	other	Approval	Yes	Yes	approved	No		S3‑193535
		S3‑193746	KI on Protection of authentication subscription data stored in UDR	Nokia, Nokia Shanghai Bell	other	Approval	No	Yes	withdrawn	Yes
		S3‑193566	Draft TR 33.845 Storage of sensitive credentials in 5G systems v0.0.0	VODAFONE Group Plc	draft TR	Approval	Yes	YesIntroduction removed Duplicate clauses removed	revised	No	S3‑193744
		S3‑193744	Draft TR 33.845 Storage of sensitive credentials in 5G systems v0.0.0	VODAFONE Group Plc	draft TR	Approval	Yes	Yes	approved	No		S3‑193566
		S3‑193630	ARPF Deployment models	Ericsson	pCR	Approval	Yes	YesNok: Do not think that the level of detail is needed for this TR BT: Think it is useful so suggets putting in an Annex KPN: Agree that is should go there TI: Some content should go in but does not fit with skeleton	noted	No
		S3‑193634	Security Parameter Storage	Ericsson	pCR	Approval	Yes	YesKPN: Confused about the limiting the storage in this contribution - move text in scenario C to model B and remove text about model A as out of scope TI: realtionship between the various parameters need to be clarified Nok: Clause 4.2.1 should not be included as it is the wrong part of TR DCM: Part of 4.2.1 is wrong	noted	No
		S3‑193647	Privacy Aspects of ARPF deployment	Ericsson	pCR	Approval	Yes	YesNok: remove last paragraph and shift 3rd paragraph to become 2nd paragraph	revised	No	S3‑193748
		S3‑193748	Privacy Aspects of ARPF deployment	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑193647
6	Any Other Business	S3‑193370	Security aspects of RLOS	Qualcomm Incorporated	draftCR	Endorsement	Yes	YesQC: should be for information DCM: out of scope	noted	No
		S3‑193455	New SID: Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC	China Unicom, CAICT, China Telecom, Huawei, Hisilicon, ZTE	SID new	Approval	Yes	YesOrange: simplify objective by pointing to SA2 work, Samsung: split this into two Thales: don't know for UICC QC: this is release 17, so not really for endorsement CMCC: are there objections QC: process needs to be adhered Nokia: too early to start on this, wait more for SA2 progress QC: have similar comment feedback given, to be noted	noted	No
		S3‑193458	Discussion on potential solutions to security handling of AMF reallocation	Huawei, Hisilicon	discussion	Endorsement	Yes	YesDCM: not in scope Nokia: waitinig for reply LS from SA2 Huawei: decision is to do nothing in SA2	noted	No
		S3‑193505	Discussion on 5G UE privacy when connecting to EPC	Apple	discussion	Agreement	Yes	YesDCM: if this is proposal for a new study item, the in scope, technically it will be very difficult Nokia: will be very difficult to do this in all networks QC: in 5G study, we looked at this in detail, but didn't get a working solution Huawei: agree	noted	No
		S3‑193510	EAP-AKA privacy enhancement in non-3GPP access to EPS	Apple	SID new	Approval	No	Yes	revised	No	S3‑193629
		S3‑193623	TLS certificates for SBA: profile and provisioning	Ericsson	discussion	Endorsement	Yes	YesCMCC: not to include provisioning in study Huawei: without provisioning, the solution is already in eSBA QC: is this also for RAN, or only core? E//: this is core netowrk only QC: useful to include gNB in scope for certificate enrolment Nokia: profile needs to be defined, especially in virtual environment, profile in R16, provisioning in R17 BT: revocation and deprovisioning needs to included	noted	No
		S3‑193629	New SID on EPS AKA and EAP-AKA privacy enhancement in EPS	Apple, Google, AT&T, Verizon UK Ltd, Accuris Networks, Charter Communications, Cablelabs, Article19, Sprint, Comcast, Broadcom	SID new	Approval	Yes	YesCMCC: does not support this QC: is for R17, was already studied in R15, so why should be possible now Nokia: shouldn't be started because it would waste time BT: explicitly look at migration strategy and bid down prevention Orange: in places talking about authentication method, talk about the access, from where to where should the IMSI be concealed.	noted	No		S3‑193510
		S3‑193671	New WID: Security Aspects of PARLOS	SPRINT Corporation	WID new	Discussion	Yes	Yesorange: normative or informative Sprint: no decision in the WID, but in TR agreement: whether this is captured in an informative or normative annex is FFS. E//: also wants to support, comment acronym Supporting: E//; Samsung, T-Mobile	endorsed	No
		S3‑193672	New WID for User Plane Gateway Function for the Inter-PLMN Security	Juniper Networks	WID new	Agreement	Yes	YesThere was discussion on the location of the UPF, i.e whether it is co-located etc. DCM: had discussion previously and concluded that it was different function as it doe not terminate the interface - coloaction is then a deployment option Chair: ask if anyone is against the split BT: would rather keep them together Chair: explained that it was due to part of the work following SA2 and UP gateway part being standalone Juniper: It is a clean separation of the work item It is generally agreed that should be a split Taken offline for discussion of an objective	revised	No	S3‑193718
		S3‑193718	New WID for User Plane Gateway Function for the Inter-PLMN Security	Juniper Networks	WID new	Agreement	Yes	YesNeeds to be re-submitted fro agreement in Reno meeting	endorsed	No		S3‑193672
		S3‑193839	SA3 meeting calendar	WG Chair	other	Information	Yes	YesIDCC: SA#100 cadjacent to independence day weekend	noted	No
		S3‑193840	draft agenda SA3#97	WG Chair	other	Information	Yes	Yes	noted	No
7	Close