TDoc list

Tdoc List

2018-08-27 15:16

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‑182100	Agenda	WG Chairman	agenda		Yes	Yes	approved	No
3	IPR and Anti-Trust Law Reminder
4	Meeting reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑182101	Report from last SA3 meeting/s	MCC	report		Yes	Yes	withdrawn	Yes
		S3‑182196	Report from last SA3 meeting/s	MCC	report		Yes	YesNCSC's action item stays open.	approved	No
4.2	Report from SA Plenary	S3‑182103	Report from last SA meeting	WG Chairman	report		Yes	Yes	noted	No
4.3	Report from SA3-LI
5	Items for early consideration
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑182140	Reply LS to RAN2 on Bluetooth/WLAN measurement collection in MDT	S5-183626	LS in		Yes	Yes	noted	No
		S3‑182141	Reply LS on Bluetooth/WLAN measurement collection in MDT	R2-1808793	LS in		Yes	YesChina Mobile had a contribution related to this: tdoc 450.	replied to	No
		S3‑182161	LS on use of ITS dedicated spectrum within V2X UE	S6-181288	LS in		Yes	Yes	noted	No
		S3‑182163	LS on application layer support for V2X services	S6-181291	LS in		Yes	Yes	noted	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA	S3‑182121	Question on 5G network slices	GSMA SIM	LS in		Yes	Yes	replied to	No
		S3‑182122	Reply LS on GSMA question on 5G network slices	S2-187599	LS in		Yes	Yes	noted	No
		S3‑182123	LS Out for 5G slices roaming	S3i180376	LS in		Yes	Yes	noted	No
		S3‑182124	Statement on urgency of alignment of ETSI SSP with 3GPP release 15	GSMA	LS in		Yes	Yes	noted	No
		S3‑182268	Draft LS to GSMA on slicing	Huawei, HiSilicon	LS out	Approval	Yes	YesQualcomm: we don’t need to ask them whether we need a slice specific authentication. ORANGE: there's no link between the DN and the slice. The secondary authentication is not linked to the NSSAI. Ericsson: keep it simple by confirming SA2's reply.	revised	No	S3‑182530
		S3‑182530	LS to GSMA on slicing	Huawei, HiSilicon	LS out	Approval	Yes	Yes	approved	No		S3‑182268
6.5	OMA
6.6	TCG	S3‑182106	TCG progress report	InterDigital, Inc.	report	Information	Yes	Yes1. TCG – Highlights • New/modified work working group CyRes – Cyber Resistance WG. This workgroup intends to develop new technologies, promote existing best-practices, and coordinate efforts in other groups inside and outside TCG, to improve the cyber-resiliency of future platforms. The CyRes WG will focus on: 1. Protection for code and configuration information that determine the platform capabilities. 2. Detection mechanisms for malware and deprecated or corrupted configuration data or code. 3. Recovery capabilities that can reliably patch both code and configuration in a selected device, and hence recover the device. • Publication of new or revised deliverables (incremental changes from the status reported at SA3#91) o TCG TMS Use Cases v2 – delayed due to GDPR compliance review, to be published September 2018 o TCG SNMP MIB for TPM-based Attestation – public review July 2018 o TCG PC Client Platform Firmware Profile – public review July 2018 o TCG Storage Interface Interactions (SIIS) – public review May 2018 o TCG SNMP MIB for TPM-based Attestation – public review May 2018 o TCG Device Identifier Composition Engine – published March 2018 2. Meetings TCG Members Meeting in Lisbon, PT – 15-18 October 2018 TCG Members Meeting in TBD location – February 2019 MPWG meets every Thursday at 10-11 ET TMS WG meets every Monday and Friday at 12-13 ET CyRes WG meets every Wednesday at 11-12:30 ET	noted	No
6.7	oneM2M
6.8	TC-CYBER	S3‑182138	Reply-LS on new work item "X.5Gsec-q"	ETSI TC CYBER	LS in		Yes	YesColin (BT): if they mention 5G we shouldn't duplicate work that is being done in 3GPP as well.	replied to	No
		S3‑182531	Reply to:LS on new work item "X.5Gsec-q"	Vodafone	LS out	approval	Yes	Yes	approved	No
6.9	ETSI NFV security	S3‑182139	LSout to various organisations on usage of NFV Specifications	ETSI ISG NFV	LS in		Yes	Yes	noted	No
6.10	Other Groups	S3‑182155	Reply LS to “5G for Industrial Communication”	SP-180608	LS in		Yes	Yes	noted	No
		S3‑182159	LS/r on revised Recommendation ITU-T Q.850 (reply to 3GPP TSG SA3 - C3-183507)	ITU-T SG11	LS in		Yes	YesThis LS was intended for CT3.	noted	No
7	Work Areas
7.1	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
7.1.1	Key hierarchy	S3‑182414	Editorial correction to figure 6.2.1-1 Key hierarchy generation in 5GS	NEC Corporation	CR	Approval	Yes	Yes	merged	No	S3‑182573
		S3‑182437	Clarification to key hierarchy	Nokia, Nokia Shanghai Bell	CR		Yes	YesIt was unclear the term "shall be prepared to support 256-bit keys". Ericsson commented that all interfaces support already 256 bits. This sentence was reworded in the revision.	revised	No	S3‑182573
		S3‑182573	Clarification to key hierarchy	Nokia, Nokia Shanghai Bell	CR	-	Yes	Yes	agreed	No		S3‑182437
7.1.2	Key derivation	S3‑182199	CR to clarify username in Annex C	Nokia,Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑182583
		S3‑182583	CR to clarify username in Annex C	Nokia,Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑182199
7.1.3	Mobility	S3‑182181	Clause 6.7.3.2 - Modification on algorithm selection during N2 handover	ZTE Corporation	CR	Approval	Yes	Yes	revised	No	S3‑182584
		S3‑182584	Clause 6.7.3.2 - Modification on algorithm selection during N2 handover	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑182181
		S3‑182182	Clause 6.7.3.5 - Correct reference for RNA update procedure	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No
		S3‑182183	Clause 6.8.2.1.3 - Modification on State transition from RRC-INACTIVE to RRC-CONNECTED	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑182184	Clause 6.9.2 - Modification on security handling during handover	ZTE Corporation	CR	Approval	Yes	YesEricsson: Note1 in 6.2.9.3.3 is important to be kept here, not removed as proposed by ZTE. Docomo: if it's important it should be normative and not an informative note.	revised	No	S3‑182585
		S3‑182585	Clause 6.9.2 - Modification on security handling during handover	ZTE Corporation,Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑182184
		S3‑182364	Mobility – Correcting AS re-keying and NAS re-keying in N2-handover	Ericsson	CR	Agreement	Yes	YesZTE: this will make CT4 to change terminology. Ericsson: we are not introducing a new flag, this was existing already.	merged	No	S3‑182585
		S3‑182368	Mobility – Rectification of NAS MAC calculation for NAS Container	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182586
		S3‑182586	Mobility – Rectification of NAS MAC calculation for NAS Container	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182368
		S3‑182369	Mobility – Rectification of how DL NAS COUNT is transferred in NAS Container	Ericsson	CR	Agreement	Yes	YesQualcomm: CT1 has chosen 8 LSB already. Ericsson: this just brings clarification. This had to be checked offline. Since an LS to CT1 was agreed to be sent, Ericsson decided to drop this revision.	not pursued	No
		S3‑182587	Mobility – Rectification of how DL NAS COUNT is transferred in NAS Container	Ericsson	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑182489	CR on N2 based HO	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑182588
		S3‑182588	CR on N2 based HO	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑182489
		S3‑182370	Mobility – Correction of NAS COUNTs in N2-handover	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑182372	Mobility – Rectification of UE security capabilities in NAS Container	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑182365	Mobility – Correcting to UE handling clause	Ericsson	CR	Agreement	Yes	YesDiscussed together with 483.	merged	No	S3‑182590
		S3‑182185	Clause 6.9.2.1.2, 6.9.2.2 - Editorial modification on NAS during handover	ZTE Corporation	CR	Approval	Yes	YesEricsson commented that removing 6.9.2.2 was not possible since it is a stand alone procedure.They didn’t agree with the other changes either, since they were removing details that were important.	not pursued	No
		S3‑182366	Mobility – Resolving EN and corrections in AS re-keying	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182591
		S3‑182591	Mobility – Resolving EN and corrections in AS re-keying	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182366
		S3‑182363	Mobility – Clarification in intra-gNB-CU handover	Ericsson	CR	Agreement	Yes	YesHuawei: Meaning of intra gNB handover is not to be explained by SA3. It had to be check offline whether the Intra gNB CU Handover existed in other groups specifications. Ericsson: we don’t need to distinguish between intra gNB and CU handover. We need to generalise it for just Intra gNB.	revised	No	S3‑182666
		S3‑182666	Mobility – Clarification in intra-gNB-CU handover	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182363
		S3‑182371	Mobility – Removing an EN in Xn-handover	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑182186	Clause 6.9.3 - Editorial modification on mobile registration update – AMF handling	ZTE Corporation	CR	Approval	Yes	YesEricsson: leave out any aspect on Multi NAS until we have finished discussions.	merged	No	S3‑182636
		S3‑182203	Clause 6.9.3 typo corrections	Nokia, Nokia shanghai Bell	CR	Approval	Yes	Yes	merged	No	S3‑182636
		S3‑182367	Mobility – Corrections for usage of local policy at AMF	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182636
		S3‑182636	Mobility – Corrections for usage of local policy at AMF	Ericsson,ZTE,Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑182367
		S3‑182187	Discussion on mobile registration update	ZTE Corporation	discussion	Endorsement	Yes	YesNokia didn’t see a problem. The agreements in Belgrade were enough for them. Ericsson (tdoc 419) and Qualcomm (tdoc 482) agreed on the existence of an issue and they had contributions with possible solutions.	noted	No
		S3‑182188	Clause 6.9.3 - Add multi-NAS connections consideration for mobile registration update – AMF handling	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑182189	Clause 6.9.3, 6.3.2.2 - Modification on mobile registration update – UE handling	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑182373	Mobility – Rectification of how UL NAS COUNT is transferred in NAS SMC	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑182638
		S3‑182190	Discussion on key change indication on N14 (AMF-AMF)	ZTE Corporation	discussion	Endorsement	Yes	YesEricsson: AKSI is the wrong terminology. They didn't agree with the proposals as it has fundamental errors.	noted	No
		S3‑182191	Clause 6.9.2.3.3 - Correct indication on N14 during N2 HO	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑182585
		S3‑182201	CR to Clause 6.9.3 Removal of KSEAF storage restriction	Nokia, Verizon, TMO-USA,Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑182548
		S3‑182548	CR to Clause 6.9.3 Removal of KSEAF storage restriction	Nokia, Verizon, TMO-USA,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑182201
		S3‑182202	CR for Addition of security requirements for external storage	Nokia, Nokia Shanghai bell, Verizon, TMO-USA	CR		Yes	YesDocomo: relying on an unespecified interface is a bit messy.Replace with a "shall" and reword to make the requirement clearer. This clause was controversial and Nokia preferred to withdraw it. Docomo wanted to at least approve a few sentences and work from there from the next meeting. Docomo proposed to postpone the decision to the next meeting, bringing the same CR for discussion. MCC clarified that if postponed, no revisions of the content would be possible.	revised	No	S3‑182549
		S3‑182549	CR for Addition of security requirements for external storage	Nokia, Nokia Shanghai bell, Verizon, TMO-USA	CR	-	Yes	Yes	postponed	No		S3‑182202
		S3‑182668	LS on inidication for keys syncronization	ZTE	LS out	Approval	Yes	Yes	approved	No
7.1.4	AS security	S3‑182499	[Draft] Reply LS on connection re-establishment security	Samsung	LS out		Yes	YesZTE: RAN2's proposal will cause an signalling overload. LTE's mechanisms could be reused here.	noted	No
		S3‑182195	Discussion on RRC Reestablishment security	ZTE Corporation	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182242	Discussion on RRC Re-establishment Security	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182241	DRAFT Reply LS on RRC Re-establishment security	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑182541
		S3‑182541	Reply LS on RRC Re-establishment security	Huawei, Hisilicon	LS out	Approval	Yes	Yes	approved	No		S3‑182241
		S3‑182355	Reply LS on connection re-establishment security	Ericsson	LS out	Approval	Yes	YesSamsung: if we go for the LTE solution the message is not encrypted. Huawei: RAN2 is fine with the first message not being encrypted. Nokia: introducing this new complexity does not bring a noticeable benefit. The Chair noted that there was a big support for keeping the LTE mechanism. Huawei advocated for the existing solution in TS 33.501 and communicate it to RAN2.	merged	No	S3‑182541
		S3‑182358	Reply LS on BL/WLAN measurement collection in MDT	Ericsson	LS out	Approval	Yes	YesInterdigital: spoofing of the SSID should be addressed as well.	revised	No	S3‑182529
		S3‑182529	Reply LS on BL/WLAN measurement collection in MDT	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑182358
		S3‑182359	Reply LS on UE identity for PO calculation	Ericsson	LS out	Approval	Yes	Yes	revised	No	S3‑182539
		S3‑182539	Reply LS on UE identity for PO calculation	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑182359
		S3‑182243	DRAFT Reply LS on security requirements for RRC connection release	Huawei, Hisilicon, China Mobile	LS out	Approval	Yes	YesEricsson didn’t want to remove this feature and leave it up to RAN2 whether they want t use it. Nokia: we have established in the LTE TS that all redirection shall be protected. We don’t need another network policy for this case. Docomo: how do we know if there's an impact on the service from the UE side?	revised	No	S3‑182542
		S3‑182542	Reply LS on security requirements for RRC connection release	Huawei, Hisilicon, China Mobile	LS out	Approval	Yes	Yes	approved	No		S3‑182243
		S3‑182360	Reply LS on security requirements for RRC connection release	Ericsson	LS out	Approval	Yes	Yes	merged	No	S3‑182542
		S3‑182490	LS reply on security for E-UTRA connected to 5GC	Qualcomm Incorporated	LS out	Approval	Yes	Yes	merged	No	S3‑182538
		S3‑182361	Reply LS on Security aspects of supporting LTE connected to 5GC	Ericsson	LS out	Approval	Yes	Yes	revised	No	S3‑182538
		S3‑182538	Reply LS on Security aspects of supporting LTE connected to 5GC	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑182361
		S3‑182484	discussion on RRC Inactive security	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182485	CR on RRC Inactive	Qualcomm Incorporated	CR	Agreement	Yes	YesHuawei: we cannot revert decisions and come back to something that RAN2 has decided. Adapt option A and forget about option B.	not pursued	No
		S3‑182238	Update Key handling at RRC-INACTIVE state transitions	Huawei, HiSilicon, Intel, China Mobile	CR	Approval	Yes	Yes	merged	No	S3‑182639
		S3‑182295	Security Algorithms Negotiation for INACTIVE related procedures	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: this was brought earlier and it wasn’t agreed.	not pursued	No
		S3‑182294	LS on INACTIVE Security Algorithms Negotiation	Huawei, Hisilicon	LS out	Approval	Yes	Yes	noted	No
		S3‑182377	Use the old KRRCint for calculation of the security token in MSG3	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182639
		S3‑182639	Use the old KRRCint for calculation of the security token in MSG3	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182377
		S3‑182354	Reply LS on inactive security	Ericsson	LS out	Approval	Yes	Yes	revised	No	S3‑182640
		S3‑182640	Reply LS on inactive security	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑182354
		S3‑182500	Update on InactiveMAC-I calculation	Samsung	CR		Yes	YesEricsson: this has been here since LTE, so if we want to remove we need to prove that there is a problem. We need a proper justification. Huawei wanted this change enhanced. Nokia: we can address the scenarios in the next meeting. Huawei proposed to bring a discussion paper about this. Ericsson asked to be minuted: calculation of soft resume MAC-I and resume constant input needs to be revisited. It was agreed to send an LS in 667 to CT1 as well.	agreed	No
		S3‑182297	Discussion on input for InactiveMAC-I to avoid replay attack	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑182296	Involve Fresh Parameters to Input of InactiveMAC-I to Avoid Replay Attack	Huawei, Hisilicon	CR	Approval	Yes	Yes	noted	No
		S3‑182501	Mechanism to mitigate replay attack in RRC-Inactive state	Samsung	CR		Yes	YesIt was pointed out that the Issue was identified. Ericsson thought that this issue should be addressed but they didn’t agree with the solutions from Samsung and Huawei. They commented that they would bring a contribution for the next meeting. Huawei would also come back with their solution.	noted	No
		S3‑182237	Algorithm Negotiation for Unauthenticated UEs in LSM	Huawei, HiSilicon, China Mobile	CR	Approval	Yes	Yes	revised	No	S3‑182646
		S3‑182646	Algorithm Negotiation for Unauthenticated UEs in LSM	Huawei, HiSilicon, China Mobile.Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑182237
		S3‑182398	Missing procedure for AS algorithm negotiation for unauthenticated emergency sessions	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑182646
		S3‑182204	Make DTLS optional on F1, E1, N2, Xn interfaces	Nokia, Nokia Shanghai Bell, Huawei, HiSilicon	CR	Approval	Yes	YesBT: This is making IPSec optional as well in 9.8.3. Ericsson didn't agree with making it optional.Huawei supported Ericsson. ORANGE: we had long discussions to make this mandatory. No point to reverse this. Huawei: there are technical arguments behind this. Docomo: A "may" be supported complicates inter operability for operators. Ericsson: DTLS is for the protection of the applications that are using SCTP. This is what is stated in the RFC.	not pursued	No
		S3‑182516	Supporting DTLS on gNB internal and external SCTP Interfaces	Huawei, Hisilicon, Nokia	discussion	Endorsement	Yes	Yes	not pursued	No		S3‑182239
		S3‑182179	Clause 6.6.1 - Modification on UP security policy	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑182644
		S3‑182180	Clause 6.6.2 - Modification on UP security activation mechanism	ZTE Corporation	CR	Approval	Yes	YesHuawei supported this change. Nokia had some reservations since they considered it a rare case.They dropped their objection since everybody else could live with the change.	revised	No	S3‑182645
		S3‑182645	Clause 6.6.2 - Modification on UP security activation mechanism	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑182180
		S3‑182229	Clarification on UP security policy verification	CATT	CR	Agreement	Yes	Yes	merged	No	S3‑182644
		S3‑182488	UP policy check	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑182644
		S3‑182644	UP policy check	Qualcomm Incorporated,ZTE,CATT	CR	Agreement	Yes	Yes	agreed	No		S3‑182488
		S3‑182233	Reference corrections in clause 6.10	CATT	CR	Agreement	Yes	Yes	agreed	No
		S3‑182350	DC - definition corrections	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182648
		S3‑182648	DC - definition corrections	Ericsson,CATT	CR	Agreement	Yes	YesIncludes the definition part of tdoc 2231.	agreed	No		S3‑182350
		S3‑182352	DC - integrity protection of traffic between UE and SN	Ericsson	CR	Agreement	Yes	YesHuawei and Qualcomm didn’t agree with this change. Ericsson: Removing this assumes that the ng-eNB is not supporting integrity protection. Vodafone supported this change. Docomo: all dual connectivity types have no integrity protection supported? It was answered yes. It was also clarified that in pure 5G gNB-gNB there is integrity protection. DT also supported the notion of this change, but they commented that thing should be normative and not go into a note. Qualcomm: dual connectivity where one RAN is LTE and the other is NR, we don’t support integrity protection. This was the agreement during the last meeting. Ericsson eventually dropped this proposal and commented that they would come back with a modified proposal based on this.	not pursued	No
		S3‑182260	Other Security Procedures for Dual Connectivity	Huawei, HiSilicon	CR	Agreement	Yes	Yes	revised	No	S3‑182649
		S3‑182649	Other Security Procedures for Dual Connectivity	Huawei, HiSilicon,Ericsson,CATT	CR	Agreement	Yes	Yes	agreed	No		S3‑182260
		S3‑182231	Clarifications on handover handling for Dual Connectivity	CATT	CR	Agreement	Yes	YesDefinition part will go into S3-182648.The rest goes to 649.	merged	No	S3‑182649
		S3‑182353	DC - adding missing details	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑182649
		S3‑182302	Hanldling UP security policy in MRDC	Huawei, Hisilicon	CR	Approval	Yes	Yes	not pursued	No
		S3‑182351	Handling of maximum supported data rate per UE for integrity protection of DRBs	Ericsson	CR	Agreement	Yes	YesHuawei: policing the rate is causing an unnecessary burden on the gNB.(on the sentence "if the UE indicates 64 kbps as its maximum data rate, then the network turns on the integrity protection for user plane data only for total data rates equal to or lower than 64 kbps. "). Nokia: nothing new here, SA2 has captured it already. It was decided to drop this given that it was captured already in SA2.	not pursued	No
		S3‑182356	DC - Handling of UP security policy in SN	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑182357	DC - Selection of SN	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑182362	DC – correcting reference	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑182240	AS SMC Handling Update	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑182301	Align AS SMC procedure with SA2 and RAN3	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm, Ericsson: content is OK but the location is not correct. It was agreed to change this in order to just show a reference to the relevant TS. Nokia didn’t agree with the last paragraph of the change.	revised	No	S3‑182650
		S3‑182650	Align AS SMC procedure with SA2 and RAN3	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182301
		S3‑182205	CR to delete ENs in clause 5.3 gNB Requirements	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑182651
		S3‑182651	CR to delete ENs in clause 5.3 gNB Requirements	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑182205
		S3‑182234	Resolving Editor’s Notes for requirements on the gNB	CATT	CR	Agreement	Yes	Yes	merged	No	S3‑182651
		S3‑182415	Correction to Clause 5.11.2 Requirements for algorithm selection	NEC Corporation	CR	Approval	Yes	Yes	agreed	No
		S3‑182376	Update of definition of 5G AS security context for 3GPP access	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182652
		S3‑182652	Update of definition of 5G AS security context for 3GPP access	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182376
		S3‑182483	Simplification of the UE handling of keys at handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑182590
		S3‑182590	Simplification of the UE handling of keys at handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑182483
		S3‑182667	LS on calculation of inactive MAC-I token	Samsung	LS out	Approval	Yes	Yes	approved	No
7.1.5	NAS security	S3‑182209	Define and clarify ABBA parameter	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑182653
		S3‑182653	Define and clarify ABBA parameter	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑182209
		S3‑182523	Comments on S3-182209	Qualcomm Incorporated	discussion		Yes	Yes	noted	No
		S3‑182409	Multiple NAS connections: mobility with horizontal KAMF derivation	Ericsson	CR	Agreement	Yes	YesNEC: we don’t reestablish IPSec as described in step 3. Ericsson: we have to keep this if it is not described somewhere else. Qualcomm: handover over 4G, and other cases should also be described here. It was agreed to send an LS to CT1 to know their opinion on the results of the agreements in SA3.	not pursued	No
		S3‑182480	Adding to note about ABBA to Annex A.7 that was missed in implementation of CR 0155r2	Qualcomm Incorporated	CR	Agreement	Yes	Yes	not pursued	No
		S3‑182482	Discussion on security context handling issues when the UE is multiple registered in the same PLMN	Qualcomm Incorporated	discussion	Endorsement	Yes	YesThe LS to cT1 in tdoc 637 is based on this document.	noted	No
		S3‑182487	K_AMF change indication in NAS SMC	Qualcomm Incorporated	CR	Agreement	Yes	YesNokia and Huawei agreed with Qualcomm.	revised	No	S3‑182638
		S3‑182638	K_AMF change indication in NAS SMC	Qualcomm Incorporated,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182487
		S3‑182176	Discussion on AMF sending NAS SMC over both access types	ZTE Corporation	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182177	Clause 6.4.2.2 - Clarification on AMF sending NAS SMC over both access types	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑182411	Multiple NAS connections: taking a new security context into use on non-3GPP access	Ericsson	CR	Agreement	Yes	YesNokia: the existing IPSec would have to be deleted and then created again. Revised to add this clarification.	revised	No	S3‑182654
		S3‑182654	Multiple NAS connections: taking a new security context into use on non-3GPP access	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182411
		S3‑182292	Discussion on initial NAS message Protection Solution	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑182192	Clause 6.9.3 - Add description for mobile registration update when NAS SMC has been performed – AMF handling	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑182475	Initial NAS security discussion	Qualcomm Incorporated, DT, Vodafone, KPN	discussion	Endorsement	Yes	YesDT: this is not only protecting the message in its current form but also it is safe for the future. Nokia: too late to change the cal flow, impact on current implementations.I don’t see the threat of the UE being traceable, nothing to protect here. Vodafone supported Qualcomm's assesment on reverse engineering. Interidigital: GUTI carries AMF identifier and it is enough to identify a number of UEs that work with an AMF. Intel: ProSe is not supported in Rel-15, there is no clear threat analysis done and we propose to postpone this for Rel-16. Ericsson agreed with Intel: it is too late and we are concerned with the impact on stage 2. Postpone to Rel-16. Vodafone: we had agreed on a change on this. We would need a CR to revert this and it's not postponing: it's taking an action. Qualcomm agreed with Vodafone. SA3 has rejected this CR twice already. AT&T: if we don't do it now, we may not do it at all. Docomo agreed. Nokia: is this an essential feature? Ericsson: it's fine to introduce this in later Releases. Docomo: Why is CT1 worried about the delay? Partial cyphering was present in LTE already. The Chair requested a show of hands on 292 and 475. Tdoc 292: Nokia, LG,Intel,Huawei,Ericsson, ZTE. Tdoc 475: Vodafone, Qualcomm, IDEMIA,Docomo, DT,ORANGE,Interdigital,BT,NIST,China Mobile,AT&T,Vodafone, Airbus,Gemalto.	noted	No
		S3‑182293	Delete initial NAS message protection solution	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm didn't agree wih the removal.	not pursued	No
		S3‑182477	Moving the HASHAMF behaviour from subclause 6.7.2 to subclause 6.4.6	Qualcomm Incorporated	CR	Agreement	Yes	Yes	not pursued	No
		S3‑182396	Reply LS on Initial NAS Message Protection	Intel Corporation (UK) Ltd	LS out		Yes	Yes	noted	No
		S3‑182476	Reply LS on initial NAS message protection	Qualcomm Incorporated	LS out	Approval	Yes	YesEricsson: it is important to analyze impacts on stage 2. DT: security by default should be the solution we should aim for. The Chair suggested that in SA3 a trade-off would be needed in this case if SA3 couldn’t get to the full security solution and let another group decide. Huawei commented that there seemed to be two sides on this issue: vendors (who saw a huge impact with little gain) and the operators/ handset manufacturers. Ericsson: we never justified why we needed to protect all the parameters. Qualcomm: you can link all this to the IMSI. Docomo agreed with Qualcomm. Alf also wondered where the impact was happening exactly. Ericsson replied that SA2 needed to revise the flow and it was too late to do this stage 2 change now. Docomo: the impact or cost is in standard development then. The Chair commented that not sending LS would mean that what is in the TS would remain.He suggested to send an LS stating the disagreement in SA3 on the justification. Huawei agreed to send such LS and suggested to let SA plenary decide. It was agreed to create an LS to express the lack of consensus (S3-182632). Alex (BT) warned about the danger of the operators not being GDPR compliant. He also added that we are required by the regulators to support LI but as operators we cannot justify creating more "holes" than the ones that LI requires.LI "holes" are protected, but here we would have "holes" open to the public.	noted	No
		S3‑182206	CR to align NAS Connection value and access type	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑182193	Clause 6.9.5.1 - Add rule for concurrent running of security procedures	ZTE Corporation	CR	Approval	Yes	YesEricsson: rule three is not needed.It was agreed to be removed. There was an overlap with rule 6 with the contribution 478 from Qualcomm. It was agreed to integrate it here.	revised	No	S3‑182655
		S3‑182655	Clause 6.9.5.1 - Add rule for concurrent running of security procedures	ZTE Corporation,Qualcomm	CR	Approval	Yes	Yes	agreed	No		S3‑182193
		S3‑182194	Clause 6.9.5.2 - Modify rule for concurrent running of security procedures	ZTE Corporation	CR	Approval	Yes	YesOverlap with 410 and 479, that simply remove bullet 4.	revised	No	S3‑182656
		S3‑182656	Clause 6.9.5.2 - Modify rule for concurrent running of security procedures	ZTE Corporation,Ericsson,Qualcomm	CR	Approval	Yes	Yes	agreed	No		S3‑182194
		S3‑182479	Correction to the concurrency rules for parallel NAS connections	Qualcomm Incorporated	CR	Agreement	Yes	Yes	merged	No	S3‑182656
		S3‑182478	Concurrency issues with N2 and 5G to EPS handovers	Qualcomm Incorporated	CR	Agreement	Yes	Yes	merged	No	S3‑182655
		S3‑182207	Correct confidentiality key in confidentiality clause.	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑182208	Delete EN in Annex D for parameters	Nokia, Nokia Shanghai bell	CR	Approval	Yes	Yes	agreed	No
		S3‑182213	Delete EN in Clause 10.2.1 Authenticated IMS Emergency Sessions	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑182178	Clause 6.4.5 - Editorial modification on NAS COUNT handling	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No
		S3‑182410	Correction to clause 6.9.5.2	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑182656
		S3‑182637	LS on security issues on Multi NAS scenarios	Qualcomm	LS out	Approval	Yes	Yes	approved	No
7.1.6	Security context	S3‑182175	Clause 6.3.1 - Modification on security context handling	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑182540
		S3‑182287	Dicussion on security handling when deploying UDSF	Huawei, Hisilicon	discussion	Endorsement	Yes	YesIntel:we should not be implementation specific. Docomo: Is it necessary to have KSEAF stored anywhere in Rel-15? It's not clear to me why they need to store it. Ericsson proposed to remove the requirement on the storage. It was confusing for SA2.	noted	No
		S3‑182540	Corrections to references related to handling of security contexts in mobility procedures	Nokia, Nokia Shanghai Bell,ZTE	CR	-	Yes	Yes	agreed	No		S3‑182442
7.1.7	Visibility and Configurability
7.1.8	Primary authentication	S3‑182394	Discussion on ngKSI	Intel Corporation (UK) Ltd	discussion		Yes	Yes	noted	No
		S3‑182434	Discussion on provision of ngKSI to UE in EAP-Request/AKA'-Challenge message	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182481	Discussion on the response to the CT1 LS on provision of ngKSI to UE at EAP-Request/AKA'-Challenge	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182392	Clarification of ngKSI and ABBA parameter in 5G-AKA	Intel Corporation (UK) Ltd	CR	Approval	Yes	Yes	revised	No	S3‑182533
		S3‑182533	Clarification of ngKSI and ABBA parameter in 5G-AKA	Intel Corporation (UK) Ltd	CR	Approval	Yes	Yes	agreed	No		S3‑182392
		S3‑182393	Clarification for ngksi and ABBA parameter for EAP-AKA’	Intel Corporation (UK) Ltd	CR		Yes	Yes	revised	No	S3‑182534
		S3‑182534	Clarification for ngksi and ABBA parameter for EAP-AKA’	Intel Corporation (UK) Ltd,Huawei,Nokia, Nokia Shanghai Bell	CR	-	Yes	Yes	agreed	No		S3‑182393
		S3‑182446	Provision of ngKSI to UE at EAP-Request/ AKA'-Challenge	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑182534
		S3‑182448	[DRAFT] Reply LS to LS on provision of ngKSI to UE at EAP-Request/AKA'-Challenge	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑182532
		S3‑182532	Reply LS to LS on provision of ngKSI to UE at EAP-Request/AKA'-Challenge	Huawei, Hisilicon	LS out	Approval	Yes	Yes	approved	No		S3‑182448
		S3‑182200	Deletion of Requester ID from ‘Nausf_UEAuthentication_authenticate’	Nokia,Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No
		S3‑182279	Editorial corrections to TS 33.501	Huawei, Hisilicon	CR	Approval	Yes	YesORANGE: do we need Note 9 in the definition? Vodafone disagreed with the note as well. NOTE 2 was brought back as the change was argued by NEC.	revised	No	S3‑182657
		S3‑182657	Editorial corrections to TS 33.501	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182279
		S3‑182284	Corrections on primary authentication	Huawei, Hisilicon	CR	Approval	Yes	YesThe addition in bullet 5 wasn't fully understood.	revised	No	S3‑182658
		S3‑182658	Corrections on primary authentication	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182284
		S3‑182285	Delay the transmission of kseaf after home network verifies the RES_star	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑182417	Removal of Note 2a on Kausf use case restriction	NEC Corporation	CR	Approval	Yes	Yes	revised	No	S3‑182659
		S3‑182659	Removal of Note 2a on Kausf use case restriction	NEC Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑182417
		S3‑182418	Clarification on Storage of SUPI at SEAF	NEC Corporation	CR	Approval	Yes	YesVodafone: store "securely". This was agreed. ORANGE, DT, BT: don’t delete the SUPI, just store it.	not pursued	No
		S3‑182660	Clarification on Storage of SUPI at SEAF	NEC Corporation	CR	Approval	No	Yes	withdrawn	Yes
		S3‑182440	Update on SEAF requirements	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	revised	No	S3‑182589	S3‑181894
		S3‑182589	Update on SEAF requirements	Nokia, Nokia Shanghai Bell	CR	-	Yes	Yes	agreed	No		S3‑182440
		S3‑182443	Clarification to support of authentication methods	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	revised	No	S3‑182680
		S3‑182680	Clarification to support of authentication methods	Nokia, Nokia Shanghai Bell	CR	-	Yes	YesORANGE didn’t support the added note. It's confusing and it's not adding anything. Nokia commented that they got questions from operators on how they had to choose. IDEMIA didn’t see the need for this note. Ericsson commented that this was just a note, no wrong technical issue here. Qualcomm: if we are having this confusion here, this needs to be clarified to the outside world.	not pursued	No		S3‑182443
		S3‑182174	Clause 6.1.2 - Modification on figure of initiation of authentication	ZTE Corporation	CR	Approval	Yes	YesEricsson didn’t see the need to have a split in the fgure.	not pursued	No
7.1.9	Secondary authentication	S3‑182269	Amendment to Re-authentication procedure in Secondary Authentication	Huawei, HiSilicon	CR	Agreement	Yes	YesORANGE: not consistent with what SA2 has in their specification. Huawei commented that was the reason why they were proposing an LS to SA2 where they should add this change.The procedure was broken according to them. ORANGE commented that SA3 was not the right place to discuss this but in SA2. Ericsson: let's ask SA2 with an LS if there is a problem.	not pursued	No
		S3‑182270	Draft-LS-out-to-SA2-on secondary re-authentication	Huawei, HiSilicon	LS out	Approval	Yes	Yes	revised	No	S3‑182661
		S3‑182661	LS-out-to-SA2-on secondary re-authentication	Huawei, HiSilicon	LS out	Approval	Yes	Yes	approved	No		S3‑182270
7.1.10	Interworking	S3‑182486	CR on reigstration procedure for mobility from 4G to 5G	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑182574
		S3‑182574	CR on reigstration procedure for mobility from 4G to 5G	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑182486
		S3‑182401	Clarifications related to the NAS Container calculation during inter system handover	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182575
		S3‑182575	Clarifications related to the NAS Container calculation during inter system handover	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182401
		S3‑182400	Removal of editor’s note on harmonization between inter and intra system handovers	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182576
		S3‑182576	Removal of editor’s note on harmonization between inter and intra system handovers	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182400
		S3‑182491	CR on corrections on the 5GS to EPS handover procedure	Qualcomm Incorporated	CR	Agreement	Yes	YesNTT-Docomo: is there any reason to specify 4 or 8 bytes? It's irrelevant from the security point of view. Ericsson: CT1 usually asks us about the size.	revised	No	S3‑182579
		S3‑182579	CR on corrections on the 5GS to EPS handover procedure	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑182491
		S3‑182492	LS on NAS parameter for 5GS to EPS HO	Qualcomm Incorporated	LS out	Approval	Yes	Yes	revised	No	S3‑182580
		S3‑182580	LS on NAS parameter for 5GS to EPS HO	Qualcomm Incorporated	LS out	Approval	Yes	Yes	approved	No		S3‑182492
		S3‑182399	Corrections and clarifications to interworking clauses	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182581
		S3‑182581	Corrections and clarifications to interworking clauses	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182399
		S3‑182442	Corrections to references related to handling of security contexts in mobility procedures	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	revised	No	S3‑182540
7.1.11	non-3GPP access	S3‑182230	Clarifications on AS key update for non-3GPP access	CATT	CR	Agreement	Yes	YesQualcomm: we don’t want to do reauthentication in this scenario, no security reasons.	not pursued	No
		S3‑182232	Clarifications on the key lifetime for non-3GPP access	CATT	CR	Agreement	Yes	YesNokia,Qualcomm: the new text is confusing.	not pursued	No
7.1.12	NDS	S3‑182402	Addition of missing reference to RFC on DTLS over SCTP	Ericsson	CR	Agreement	Yes	YesHuawei: add a note on the limitation during implementation. ORANGE: this is implementing the agreement from last meeting. Ericsson: we only minuted last meeting that we needed to fix the reference.	agreed	No
		S3‑182403	Correction of Note on physical protection for NDS/IP use	Ericsson	CR	Agreement	Yes	YesDT: say "if" and not "In case". BT: the specs are control plane only, why remove these words? It was agreed to remove the note.	revised	No	S3‑182662
		S3‑182662	Correction of Note on physical protection for NDS/IP use	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182403
		S3‑182164	Protection of the N4 Interface	Juniper Networks, Deutsche Telecom AG	CR		Yes	YesEricsson: Do we need to specify separately the security for every core network/RAN interface? We should do it in a more generic way. ORANGE: this is in line with what SA2 is doing. It was agreed to create a new CR to do such generalization.	not pursued	No
		S3‑182663	Protection of non SBA interfaces internal to 5G core.	Deutsche Telecom AG	CR	-	Yes	Yes	agreed	No
		S3‑182165	Protection of the N9 Interface	Juniper Networks, Deutsche Telecom AG	CR		Yes	Yes	not pursued	No
		S3‑182245	DRAFT LS on SCTP Restrictions when supporting DTLS over SCTP	Huawei, Hisilicon	LS out	Approval	Yes	Yes	noted	No
		S3‑182239	Supporting DTLS on gNB internal and external SCTP Interfaces	Huawei, Hisilicon, Nokia	discussion	Endorsement	Yes	Yes	revised	No	S3‑182516
7.1.13	Service based architecture
7.1.13.1	Interconnect (SEPP related)	S3‑182335	On the alignment of N32 terminology	Deutsche Telekom AG, Juniper Networks Inc.	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182272	CR to add N32 definitions	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑182550
		S3‑182550	N32 solution details	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑182272
		S3‑182387	N32 terminology and restructuring	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑182551
		S3‑182551	N32 terminology and restructuring	Ericsson	other	Approval	Yes	Yes	merged	No	S3‑182673	S3‑182387
		S3‑182258	Remove EN in 13.2 – Application layer security	Nokia,Nokia Shanghai Bell	other	Approval	Yes	Yes	merged	No	S3‑182673
		S3‑182271	Presentation on N32 connections and N32-f context	Nokia, Juniper,Nokia Shanghai Bell	other	Presentation	Yes	Yes	noted	No
		S3‑182341	N32-f context	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑182552
		S3‑182552	N32-f context	Ericsson	other	Approval	Yes	Yes	merged	No	S3‑182673	S3‑182341
		S3‑182259	Exchange of N32-f context id during Initial Handshake	Nokia,Nokia Shanghai Bell	other	Approval	Yes	Yes	merged	No	S3‑182673
		S3‑182325	Session Key Derivation for N32-f Application Layer Security	NCSC	other	Approval	Yes	Yes	merged	No	S3‑182553
		S3‑182380	N32 session key derivation and key hierarchy	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑182553
		S3‑182553	N32 session key derivation and key hierarchy	Ericsson	other	Approval	Yes	Yes	merged	No	S3‑182550	S3‑182380
		S3‑182386	TLS export	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑182554
		S3‑182554	TLS export	Ericsson	other	Approval	Yes	Yes	merged	No	S3‑182673	S3‑182386
		S3‑182321	pCR to DraftCR - Protection Policies	KPN N.V.	other	Approval	Yes	YesDocomo: "Which IPX providers are authorized to perform modifications" not required if we don’t have a next hop. Delete this line.If we have a next hop identifier this is not required. It was commented that KPN was not present in the meeting to agree on the changes. DT proposed to take this over.	revised	No	S3‑182555
		S3‑182555	pCR to DraftCR - Protection Policies	Deutsche Telekom	other	Approval	Yes	Yes	merged	No	S3‑182552	S3‑182321
		S3‑182433	Revision of the modification policy in draft CR S3-181937	China Mobile	other	Approval	Yes	Yes	revised	No	S3‑182558
		S3‑182558	Revision of the modification policy in draft CR S3-181937	China Mobile	other	Approval	Yes	Yes	merged	No	S3‑182673	S3‑182433
		S3‑182507	Clarifications to protection policies	Deutsche Telekom AG	CR	Approval	Yes	Yes	revised	No	S3‑182559
		S3‑182559	Clarifications to protection policies	Deutsche Telekom AG	CR	Approval	Yes	Yes	merged	No	S3‑182673	S3‑182507
		S3‑182390	Message Routing in N32	Ericsson	discussion	Discussion	Yes	YesHuawei didn’t agree with these proposals. It was agreed to send an LS to CT4.	noted	No
		S3‑182257	JOSE based protection of messages over N32-f	Nokia, NCSC,Nokia Shanghai Bell	other	Approval	Yes	Yes	revised	No	S3‑182560
		S3‑182560	JOSE based protection of messages over N32-f	Nokia, NCSC,Nokia Shanghai Bell	other	Approval	Yes	Yes	merged	No	S3‑182673	S3‑182257
		S3‑182521	Commenting contribution on JOSE based protection of HTTP messages over N32-f (S3-182257)	Deutsche Telekom AG	other	Approval	Yes	Yes	noted	No
		S3‑182527	Comment on: JOSE based protection of HTTP messages over N32-f (S3-182257)	Ericsson-LG Co., LTD	discussion	Approval	Yes	Yes	noted	No
		S3‑182340	References to encrypted IEs in the rewritten HTTP message	Ericsson	other	Approval	Yes	Yes	noted	No
		S3‑182413	On the need for error signalling in inter-PLMN communication	Deutsche Telekom AG	discussion	Endorsement	Yes	Yes	revised	No	S3‑182561
		S3‑182561	On the need for error signalling in inter-PLMN communication	Deutsche Telekom AG	discussion	Endorsement	Yes	Yes	endorsed	No		S3‑182413
		S3‑182435	Discussion of error handling for SBA	China Mobile	discussion	Discussion	Yes	Yes	noted	No
		S3‑182447	Error handling for SBA authentication and authorization in service layer	China Mobile	CR		Yes	YesDT: what's the benefit of silently discarding here? Also, there is normative text in the notes. China Mobile: we need a procedure to deal with this error handling. DT proposed to include these changes in the error messages that they had brought in the discussion paper. In any case the error messages were to be worked on in CT4 so an LS would be sent to them. This was agreed. BT: "silently discard" wording is used when there is an overload.	revised	No	S3‑182563
		S3‑182563	Error handling for SBA authentication and authorization in service layer	China Mobile	CR	-	Yes	Yes	agreed	No		S3‑182447
		S3‑182522	Error handling for N32 Application Layer Security	Nokia	other	Approval	Yes	YesVodafone proposed to have the error handling optional. Ericsson: error handling being optional is stepping on CT4's (stage 3) territory.	revised	No	S3‑182564
		S3‑182564	Error handling for N32 Application Layer Security	Nokia	other	Approval	Yes	Yes	merged	No	S3‑182550	S3‑182522
		S3‑182173	Clause 5.9.3.3 - Modification on integrity requirement on N32	ZTE Corporation	CR	Approval	Yes	YesDT didn’t agree with this change; it is not modified inline.NCSC agreed.	not pursued	No
		S3‑182506	Clarification to the protection of attributes by the SEPP	Deutsche Telekom AG	CR	Approval	Yes	Yes	revised	No	S3‑182565
		S3‑182565	Clarification to the protection of attributes by the SEPP	Deutsche Telekom AG	CR	Approval	Yes	Yes	agreed	No		S3‑182506
		S3‑182422	Mitigation against fraudulent registration attack between SEPPs	Huawei, Hisilicon	CR	Approval	Yes	YesNCSC: this is not needed. There was no support for this document so it was not pursued.	not pursued	No
		S3‑182342	Message flows including SEPP	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑182197	Removal of JWE/JWS profile from 33.501	Ericsson	other	Approval	Yes	YesMCC warned about renaming clauses and moving content around. The clauses should be voided and the new content added to a new clause.	merged	No	S3‑182550
		S3‑182459	References to encrypted IEs in the rewritten HTTP message	Ericsson	other	Approval	No	Yes	withdrawn	Yes
		S3‑182460	N32-f context	Ericsson	other	Approval	No	Yes	withdrawn	Yes
		S3‑182461	Message flows including SEPP	Ericsson	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑182562	LS on N32 error signalling	Deutsche Telekom	LS out	Approval	Yes	Yes	approved	No
		S3‑182672	Draft CR on Application layer security on the N32 interface	Nokia	draftCR	Approval	Yes	Yes	revised	No	S3‑182673
		S3‑182673	Draft CR on Application layer security on the N32 interface	Nokia	draftCR	Approval	Yes	YesIt merges all content for the draft CR.	approved	No		S3‑182672
		S3‑182697	Clarifications in clause 13.5	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑182700	Application layer security on the N32 interface	Nokia	CR	Agreement	Yes	Yes	agreed	No
7.1.13.2	Other	S3‑182273	CR to add a missing step to discover an NF producer instance during Access Token Request	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑182641
		S3‑182641	CR to add a missing step to discover an NF producer instance during Access Token Request	Nokia,Nokia Shanghai Bell,Ericsson,Huawei	CR	Agreement	Yes	Yes	agreed	No		S3‑182273
		S3‑182274	CR to add Access Token Request procedure for a specific NF service producer	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑182642
		S3‑182642	CR to add Access Token Request procedure for a specific NF service producer	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑182274
		S3‑182384	NRF Access Token Service	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑182641
		S3‑182453	Adding OAuth related authorization services for SBA security	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182670
		S3‑182670	Adding OAuth related authorization services for SBA security	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182453
		S3‑182385	Clarifications on OAuth access token scope	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑182641
		S3‑182318	CR to remove Editor’s Note on additional claims in the access token	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	YesHuawei didn't agree with removing the scope. Nokia agreed with putting it back.	revised	No	S3‑182566
		S3‑182566	CR to remove Editor’s Note on additional claims in the access token	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑182318
		S3‑182319	CR to remove Editor’s Note on additional parameters that may be required in step 1 of Figure 13.4.1.1-2	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S3‑182567
		S3‑182567	CR to remove Editor’s Note on additional parameters that may be required in step 1 of Figure 13.4.1.1-2	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑182319
		S3‑182343	Authentication for token-based authorization	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑182317	CR on mandatory ciphering of access tokens by NRF in inter-PLMN scenarios	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	YesEricsson commented that this was not needed (Cyphering with a token). NCSC: more work is needed in the reference to the document [45] that is about sing-in.	not pursued	No
		S3‑182643	CR on mandatory ciphering of access tokens by NRF in inter-PLMN scenarios	Nokia,Nokia Shanghai Bell	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑182381	Removal of MAC based OAuth2.0 token verification	Ericsson	CR	Agreement	Yes	YesChina Mobile and Huawei didn’t agree with the change. Vodafone: we may have different security levels considering that we have concepts like Edge Computing.	not pursued	No
		S3‑182383	Removal of token validation by NRF	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182568
		S3‑182568	Removal of token validation by NRF	Ericsson,Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑182383
		S3‑182320	CR to remove Editor’s Note on verification of claims in the access token	Nokia,Nokia Shanghai Bell	CR	Agreement	Yes	Yes	merged	No	S3‑182568
		S3‑182382	OAuth Client Registration up to implementation	Ericsson	CR	Agreement	Yes	YesORANGE didn’t like to remove the reference to the SA2 document. No reason to make it implementation specific.DT supported this.	not pursued	No
		S3‑182388	HTTP basic authentication to NRF	Ericsson	CR	Agreement	Yes	YesDT: if we use dummy values why do we authenticate at all? We need to consult CT4 about it. Huawei didn't agree with this either.	not pursued	No
		S3‑182389	NF Instance ID in HTTP basic authentication username in Rel-15	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑182452	Clarification on authentication and authorization in SBA	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182569
		S3‑182569	Clarification on authentication and authorization in SBA	Huawei, Hisilicon,Ericsson, Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑182452
		S3‑182465	Clarifications and editorials to clause 13.1 (Transport security for service based interfaces)	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182570
		S3‑182570	Clarifications and editorials to clause 13.1 (Transport security for service based interfaces)	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182465
		S3‑182345	Clarifications and editorials to clause 13.3 (authentication and static authorization between network functions)	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑182569
		S3‑182326	Agenda and notes of SA3 conference call on remaining Rel-15 SBA work	Deutsche Telekom AG	discussion	Information	Yes	Yes	noted	No
		S3‑182327	Agenda and notes of CT4/SA3 conference call on N32	Deutsche Telekom AG	discussion	Information	Yes	Yes	noted	No
		S3‑182328	Agenda and notes of SA3 conference call on N32	Deutsche Telekom AG	discussion	Information	Yes	Yes	noted	No
		S3‑182494	Agenda and notes of 27th June conference call on remaining Rel-15 SBA work	Qualcomm Incorporated	report	Information	Yes	Yes	noted	No
		S3‑182344	Clarifications and editorials to clause 13.1 (Transport security for service based interfaces)	Ericsson	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑182462	Authentication for token-based authorization	Ericsson	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑182463	Clarifications and editorials to clause 13.1 (Transport security for service based interfaces)	Ericsson	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑182464	Clarifications and editorials to clause 13.3 (authentication and static authorization between network functions)	Ericsson	CR	Agreement	No	Yes	withdrawn	Yes
7.1.14	Privacy	S3‑182228	Clause 6.12.2-Adding Routing Indicator in SUCI	CATT, Ericsson , Vodafone, Huawei, NEC, China Mobile, Nokia, Nokia Shanghai Bell Labs, IDEMIA	CR	Agreement	Yes	Yes	revised	No	S3‑182513
		S3‑182513	Clause 6.12.2-Adding Routing Indicator in SUCI	CATT, Ericsson , Vodafone, Huawei, NEC, China Mobile, Nokia, Nokia Shanghai Bell Labs, IDEMIA	CR	Agreement	Yes	Yes	merged	No	S3‑182535	S3‑182228
		S3‑182514	Disucssion and clarification on SUCI parameters	Huawei, Hisilicon	discussion	Agreement	Yes	Yes	noted	No
		S3‑182374	Privacy – adding missing detials in SUCI content and format	Ericsson	CR	Agreement	Yes	YesQualcomm agreed with using 4 bits instead of 8 as proposed by Huawei in tdoc 514. Qualcomm: using the routing identifier bits is optional. It was agreed to have a field for the routing id. ORANGE: define a default value that means "not used". Huawei: not SA3's work, but CT4's.	revised	No	S3‑182535
		S3‑182535	Privacy – adding missing detials in SUCI content and format	CATT, Ericsson , Vodafone, Huawei, NEC, China Mobile, Nokia, Nokia Shanghai Bell Labs, IDEMIA	CR	Agreement	Yes	Yes	agreed	No		S3‑182374
		S3‑182515	LS on SUCI parameters clarification	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑182536
		S3‑182536	LS on SUCI parameters clarification	Huawei, Hisilicon	LS out	Approval	Yes	Yes	approved	No		S3‑182515
		S3‑182171	Clause 5.2.5 - Modification on subscriber privacy	ZTE Corporation	CR	Approval	Yes	YesIDEMIA: we cannot mandate proprietary schemes to be stored in the USIM. Ericsson agreed. Gemalto: the routing information should be listed as well.	revised	No	S3‑182635
		S3‑182635	Clause 5.2.5 - Modification on subscriber privacy	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑182171
		S3‑182172	Clause 5.8.2 - Modification on requirement on UDM storing key pair identifier	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑182375	Privacy - addressing ENs	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182571
		S3‑182571	Privacy - addressing ENs	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182375
7.1.15	Incoming and outgoing Lses	S3‑182125	Reply LS on initial NAS message protection	C1-183727	LS in		Yes	YesThis LS was already replied in the previous meeting.	withdrawn	Yes
		S3‑182126	Reply LS on initial NAS message protection	S2-187505	LS in		Yes	Yes	replied to	No
		S3‑182632	Reply to: LS on initial NAS message protection	NTT-Docomo	LS out	approval	Yes	Yes	approved	No
		S3‑182128	Provision of ngKSI to UE at EAP-Request/AKA'-Challenge	C1-184942	LS in		Yes	Yes	replied to	No
		S3‑182129	Reply LS on AUSF/UDM instance selection and SUCI parameters	C4-184576	LS in		Yes	Yes	noted	No
		S3‑182130	Response to “Reply LS on AUSF/UDM instance selection and SUCI parameters”	C6-180361	LS in		Yes	Yes	noted	No
		S3‑182131	Reply LS to “LS on AUSF/UDM instance selection and SUCI parameters”	S2-186257	LS in		Yes	Yes	noted	No
		S3‑182132	LS OUT on TLS and inter PLMN routing	C4-184612	LS in		Yes	Yes	noted	No
		S3‑182133	LS OUT on TLS and inter PLMN routing	C4-185493	LS in		Yes	Yes	replied to	No
		S3‑182630	Reply to: LS OUT on TLS and inter PLMN routing	NTT-Docomo	LS out	approval	Yes	Yes	approved	No
		S3‑182157	UE capability related to integrity protection of DRBs	R2-1804056	LS in		Yes	YesThis LS was treated already in the previous meeting.	withdrawn	Yes
		S3‑182135	Reply LS on avoiding race condition in 5G AKA	C4-185320	LS in		Yes	Yes	noted	No
		S3‑182136	LS OUT on OAuth 2.0	C4-185505	LS in		Yes	Yes	replied to	No
		S3‑182629	Reply to: LS OUT on OAuth 2.0	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑182143	Reply LS on Security aspects of supporting LTE connected to 5GC	R2-1809162	LS in		Yes	Yes	replied to	No
		S3‑182145	LS on UE identity for PO calculation	R2-1810941	LS in		Yes	Yes	replied to	No
		S3‑182144	LS on inactive security	R2-1809177	LS in		Yes	Yes	replied to	No
		S3‑182146	LS on security requirements for RRC connection release	R2-1810960	LS in		Yes	Yes	replied to	No
		S3‑182147	LS on connection re-establishment security	R2-1810965	LS in		Yes	Yes	replied to	No
		S3‑182150	LS on security handling when deploying UDSF	S2-187506	LS in		Yes	Yes	replied to	No
		S3‑182214	Discussion paper on S3-182150 KSEAF storage in UDSF	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182215	draft_Reply LS to S3-182150 security handling when deploying UDSF	Nokia,Nokia Shanghai Bell	LS out		Yes	Yes	revised	No	S3‑182547
		S3‑182547	Reply LS to S3-182150 security handling when deploying UDSF	Nokia,Nokia Shanghai Bell	LS out	-	Yes	YesThere was no consensus on this LS, and given that SA2 would not meet before the next SA3 meetng, this was noted.	noted	No		S3‑182215
		S3‑182519	Response to 3GPP SA2 liaison S2-183036 on ‘general status of work’	BBF	LS in		Yes	Yes	noted	No
7.1.16	Others	S3‑182419	Editorial correction to TS 33.501	NEC Corporation	CR	Approval	Yes	Yes	agreed	No
		S3‑182441	Addition of definitions and corrections to references	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	revised	No	S3‑182582
		S3‑182582	Addition of definitions and corrections to references	Nokia, Nokia Shanghai Bell	CR	-	Yes	YesNokia pointed out that the corrected definition on “authentication data” in this CR points to a related topic that needs to be addressed. CT4 29.505 and SA3 33.501 have a different meaning of “authentication data” related to UDM/UDR. Also Nudr service details related to security are missing. It was asked how to solve this and which group is responsible? Nokia encouraged to discuss the details offline and offered to take the lead. Nokia aso stated that the background was available in an email sent to the SA3 reflector.	agreed	No		S3‑182441
		S3‑182436	Generic description of security elements	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	revised	No	S3‑182613	S3‑181892
		S3‑182613	Generic description of security elements	Nokia, Nokia Shanghai Bell	CR	-	Yes	Yes	agreed	No		S3‑182436
		S3‑182439	Collection of editorial changes	Nokia, Nokia Shanghai Bell	CR		Yes	Yes	revised	No	S3‑182528
		S3‑182528	Collection of editorial changes	Nokia, Nokia Shanghai Bell,LG	CR	-	Yes	Yes	agreed	No		S3‑182439
		S3‑182512	CR for 33.501 - Editorial correction of 6.7.2	LG Electronics	CR	Agreement	Yes	Yes	agreed	No
		S3‑182511	CR for 33.501 - Editorial correction of 6.9.3	LG Electronics	CR	Agreement	Yes	Yes	merged	No	S3‑182528
		S3‑182438	Editorial changes to clause 9	Nokia, Nokia Shanghai Bell	CR		Yes	YesEricsson: these services are described in our specification. MCC: not possible to "un-void" clauses. It should have been rev 2. Ericsson: clause 9.5.1 is referring to the very same spec. Not necessary.	revised	No	S3‑182664	S3‑181895
		S3‑182664	Editorial changes to clause 9	Nokia, Nokia Shanghai Bell	CR	-	Yes	Yes	agreed	No		S3‑182438
		S3‑182329	CR-slice-management-security	Huawei, HiSilicon, China Mobile, China Unicom, CATR, CATT	CR		Yes	YesColin (BT) asked whether it was about management of network slices as signalling. MCC queried whether network slicing management security was part of the objectives of the 5G phase one security WID. ORANGE commented that it was part of the objectives of this WID to work on 5G security issues that were being done in other working groups (SA5 in this case). MCC commented that it may be argued that a revised WID for 5G Phase one would be needed to add this or a new WID to add this new security feature. The CR was finally agreed.	agreed	No
		S3‑182524	WI Summary for 5G_Ph1-sec	NTT DOCOMO INC.	WI summary	Endorsement	Yes	Yes	revised	No	S3‑182633
		S3‑182633	WI Summary for 5G_Ph1-sec	NTT DOCOMO INC.	WI summary	Endorsement	Yes	Yes	endorsed	No		S3‑182524
		S3‑182451	Discussion on charging fraud attack	Huawei, Hisilicon	discussion	Endorsement	Yes	YesVodafone commented that a SID would be useful to study the different fraud possibilites but Tim wasn't convinced that a solution or an implemented fix would be enough. Docomo and ORANGE agreed. A SID could be useful. Qualcomm commented that the visited network had to be trusted. They weren't sure of what could be done here. Qualcomm asked Huawei to bring more details in order to consider a Study Item. It was agreed that Huawei would bring more details in the next meeting.	noted	No
		S3‑182669	revised WID 5G Phase one security	NTT-Docomo	WID revised	Agreement	Yes	Yes	agreed	No
7.2	Security Assurance Specification for 5G (SCAS_5G) (Rel-16)
7.2.1	NR Node B (gNB) (TS 33.511)	S3‑182525	Update to WID 5G SCAS	Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, China Unicom, CATT, Deutsche Telekom, ZTE, Samsung, KPN, NEC, British Telecom, China Mobile, Ericsson	WID revised	Approval	Yes	YesEricsson was concerned about the amount of resources spent on this work and whether this was used in GSMA and so on. The progress was slow on SCAS.	revised	No	S3‑182593	S3‑182332
		S3‑182593	Update to WID 5G SCAS	Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, China Unicom, CATT, Deutsche Telekom, ZTE, Samsung, KPN, NEC, British Telecom, China Mobile, Ericsson	WID revised	Approval	Yes	Yes	agreed	No		S3‑182525
		S3‑182303	skeleton of TS 33511	Huawei, Hisilicon	draft TS	Approval	Yes	Yes	approved	No
		S3‑182304	scope of TS 33511	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑182305	security requirements and corresponding test cases for gNB	Huawei, Hisilicon	pCR	Approval	Yes	YesNEC: some requirements are internal to the product and not possible to test. E.g. 4.2.2.1.Z. Huawei commented that this was following the same pattern as the SCAS for eNodeB. Nokia didn’t agree with this pCR.	noted	No
		S3‑182332	Update to WID 5G SCAS	Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, China Unicom, CATT, Deutsche Telekom, ZTE, Samsung, KPN, NEC, British Telecom, China Mobile	WID revised	Approval	Yes	Yes	revised	No	S3‑182525
		S3‑182592	Draft TS 33.511	Huawei	draft TS	Approval	Yes	Yes	approved	No
7.2.2	Access and Mobility Management Function (TS 33.512)
7.2.3	User Plane Function (UPF) (TS 33.513)	S3‑182504	Skeleton for TS 33.513	Samsung	draft TS		Yes	Yes	revised	No	S3‑182595
		S3‑182595	Skeleton for TS 33.513	Samsung	draft TS	-	Yes	Yes	approved	No		S3‑182504
		S3‑182505	Scope for TS 33.513 SCAS UPF	Samsung	pCR		Yes	Yes	approved	No
		S3‑182596	Draft TS 33.513	Samsung	draft TS	Approval	Yes	Yes	approved	No
7.2.4	Unified Data Management (UDM) (TS 33.514)	S3‑182420	Skeleton for TS 33.514 SCAS UDM	NEC Corporation	pCR	Approval	Yes	YesChina Mobile: why do we have a general security requirements clause and a specific requirements clause? Samsung: the general requirements are for all the network entities.	revised	No	S3‑182598
		S3‑182598	Skeleton for TS 33.514 SCAS UDM	NEC Corporation	pCR	Approval	Yes	YesClause 4 is gone.	approved	No		S3‑182420
		S3‑182421	Scope proposal for TS 33.514 SCAS UDM	NEC Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑182597	Draft TS 33.514	NEC	draft TS	Approval	Yes	Yes	approved	No
7.2.5	Session Management Function (SMF) (TS 33.515)	S3‑182306	skeleton of TS 33515	Huawei, Hisilicon	draft TS	Approval	Yes	Yes	revised	No	S3‑182599
		S3‑182599	skeleton of TS 33515	Huawei, Hisilicon	draft TS	Approval	Yes	Yes	approved	No		S3‑182306
		S3‑182307	scope of TS 33515	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑182600	Draft TS 33.515	Huawei	draft TS	Approval	Yes	Yes	approved	No
7.3	eMCSec R16 security (MCXSec) (Rel-16)	S3‑182127	LS on [Temporary group call – user regroup] and [Temporary group – broadcast group call]	C1-184907	LS in		Yes	Yes	noted	No
		S3‑182160	Reply LS on temporary group regroup procedures	S6-181287	LS in		Yes	Yes	noted	No
7.4	Other work areas
7.4.1	SAE/LTE Security	S3‑182298	Alignment of terminology in RRCConnctionReestablsihment Procedure in R14	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182602
		S3‑182602	Alignment of terminology in RRCConnctionReestablsihment Procedure in R14	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182298
		S3‑182299	Alignment of terminology in RRCConnctionReestablsihment Procedure in R15	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182603
		S3‑182603	Alignment of terminology in RRCConnctionReestablsihment Procedure in R15	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182299
		S3‑182349	LTE EDT - Updates in suspend/resume	Ericsson	CR	Agreement	Yes	YesHuawei: RAN2 has gone already gone for 16 bits so let's move on. Ericsson: this is a new feature; I don’t understand why this is not integrity protected. This document was taken offline.It was decided to send an LS to RAN2 as well (S3-182605).	revised	No	S3‑182604
		S3‑182604	LTE EDT - Updates in suspend/resume	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑182349
		S3‑182605	LS on security aspects of EDT	Ericsson	LS out	Approval	Yes	Yes	approved	No
7.4.2	IP Multimedia Subsystem (IMS) Security
7.4.3	Network Domain Security (NDS)	S3‑182166	Discussion on the Scope and Future Use of the NDS IP and AF Specifications	Juniper Networks	discussion		Yes	Yes	noted	No
		S3‑182167	Update NDS/IP scope with application layer crypto profiles	Juniper Networks	CR		Yes	Yes	revised	No	S3‑182606
		S3‑182606	Update NDS/IP scope with application layer crypto profiles	Juniper Networks	CR	-	Yes	Yes	agreed	No		S3‑182167
		S3‑182168	Update NDS/IP scope with application layer crypto profiles	Juniper Networks	CR		Yes	Yes	not pursued	No
		S3‑182607	Update NDS/IP scope with application layer crypto profiles	Juniper Networks	CR	-	No	Yes	withdrawn	Yes
		S3‑182169	Clarify NDS/AF intro regarding crypto profiles	Juniper Networks	CR		Yes	Yes	revised	No	S3‑182608
		S3‑182608	Clarify NDS/AF intro regarding crypto profiles	Juniper Networks	CR	-	Yes	Yes	agreed	No		S3‑182169
		S3‑182170	Clarify NDS/AF intro regarding crypto profiles	Juniper Networks	CR		Yes	Yes	noted	No
		S3‑182609	Clarify NDS/AF intro regarding crypto profiles	Juniper Networks	CR	-	No	Yes	withdrawn	Yes
		S3‑182198	JWE and JWS profiles	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑182606
7.4.4	UTRAN Network Access Security
7.4.5	GERAN Network Access Security
7.4.6	Generic Authentication Architecture (GAA)
7.4.7	Security Aspects of Home(e)NodeB (H(e)NB)
7.4.8	Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)	S3‑182107	[MCSec] 33180 R14. Examples of MC service ID shall be URI	Airbus DS SLC	CR		Yes	Yes	revised	No	S3‑182543
		S3‑182543	[MCSec] 33180 R14. Examples of MC service ID shall be URI	Airbus DS SLC	CR	-	Yes	Yes	agreed	No		S3‑182107
		S3‑182556	[MCPTT] 33179 R13. Examples of MC service ID shall be URI	Airbus DS SLC	CR	-	Yes	Yes	agreed	No
		S3‑182108	[MCSec] 33180 R15. Examples of MC service ID shall be URI	Airbus DS SLC	CR		Yes	Yes	revised	No	S3‑182544
		S3‑182544	[MCSec] 33180 R15. Examples of MC service ID shall be URI	Airbus DS SLC	CR	-	Yes	Yes	agreed	No		S3‑182108
		S3‑182110	[MCSec] 33180 R14. Clarification for MIKEY-SAKKE values	Airbus DS SLC	CR		Yes	YesAlex (BT) commented that adding changes to editor's notes was not a valid procedure for a frozen spec, it was better to wait.	revised	No	S3‑182545
		S3‑182545	[MCPTT 33180 R14. Clarification for MIKEY-SAKKE values	Airbus DS SLC	CR	-	Yes	Yes	agreed	No		S3‑182110
		S3‑182557	[MCPTT] 331179 R13. Clarification for MIKEY-SAKKE values	Airbus DS SLC	CR	-	Yes	Yes	agreed	No
		S3‑182111	[MCSec] 33180 R15. Clarification for MIKEY-SAKKE values	Airbus DS SLC	CR		Yes	Yes	revised	No	S3‑182546
		S3‑182546	[MCSec] 33180 R15. Clarification for MIKEY-SAKKE values	Airbus DS SLC	CR	-	Yes	Yes	agreed	No		S3‑182111
		S3‑182112	[MCSec] 33180 R15. Clarification for MIKEY-SAKKE values	Airbus DS SLC	CR		No	Yes	withdrawn	Yes
		S3‑182220	[MCPTT] 33179 R13 Fix XML schema	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑182221	[MCSec] 33180 R14 Fix XML schema	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑182222	[MCPTT] 33180 R15 Fix XML schema (mirror)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑182601
		S3‑182601	[MCPTT] 33180 R15 Fix XML schema	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑182222
		S3‑182223	[MCSec] 33180 R14 FC values for MCData	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑182224	[MCSec] 33180 R15 FC values for MCData (mirror)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑182225	[MCSec] 33180 R15 registered media type	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑182226	[MCSec] 33220 R14 FC values for MCData	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S3‑182227	[MCSec] 33220 R15 FC values for MCData (mirror)	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No
7.4.9	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑182308	EDCE5 security requirements and corresponding test cases for MeNB	Huawei, Hisilicon	CR	Approval	Yes	YesNEC: 4.2.2.1.E is too detailed. Nokia had also some issues that had to be taken offline.	not pursued	No
		S3‑182611	EDCE5 security requirements and corresponding test cases for MeNB	Huawei, Hisilicon	CR	Approval	No	Yes	withdrawn	Yes
		S3‑182316	Clarifications in TS 33117	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson didn’t agree with the second change, since it was ambiguous. Leaving the door open NEC didn’t agree with the editor's note. Huawei agreed to remove it but they noted that the issue was still open. MCC commented that this CR would need to correct the issue in lower releases.	revised	No	S3‑182612
		S3‑182612	Clarifications in TS 33117	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182316
		S3‑182647	Clarifications in TS 33117	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑182330	SBA Security in the Context of 5G SCAS Work	Deutsche Telekom AG, Nokia	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑182331	Document Skeleton for TS 33.512, based on TS 33.116	Deutsche Telekom AG	draft TS	Approval	Yes	Yes	revised	No	S3‑182594
		S3‑182594	Document Skeleton for TS 33.512, based on TS 33.116	Deutsche Telekom AG	draft TS	Approval	Yes	Yes	approved	No		S3‑182331
		S3‑182337	Closing the open Action Item for implementing one NESAS Pilot Finding in SCAS specification	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182346	Update to LS on Implementation of NESAS Pilot Findings in SCAS specifications	Nokia, Nokia Shanghai Bell	LS out	Approval	Yes	YesHuawei didn't agree with the second paragraph.	revised	No	S3‑182701
		S3‑182701	Update to LS on Implementation of NESAS Pilot Findings in SCAS specifications	Nokia, Nokia Shanghai Bell	LS out	Approval	Yes	Yes	approved	No		S3‑182346
7.4.10	Security Aspects of Narrowband IOT (CIoT)	S3‑182142	Security related agreements on Early Data Transmission	R2-1808869	LS in		Yes	Yes	noted	No
		S3‑182148	LS on EDT procedures and AS NAS interaction (R2-1712077)	R3-183574	LS in		Yes	Yes	noted	No
		S3‑182473	Clarifications on the calculation of NAS-MAC for RRCConnection re-establishmentwith Control Plane CIoT optimisations (Rel-14)	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑182614
		S3‑182614	Clarifications on the calculation of NAS-MAC for RRCConnection re-establishmentwith Control Plane CIoT optimisations (Rel-14)	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑182473
		S3‑182474	Clarifications on the calculation of NAS-MAC for RRCConnection re-establishmentwith Control Plane CIoT optimisations (Rel-15)	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑182615
		S3‑182615	Clarifications on the calculation of NAS-MAC for RRCConnection re-establishmentwith Control Plane CIoT optimisations (Rel-15)	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑182474
7.4.11	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)	S3‑182348	EDCE5 – Fixing contradicting and insecure scg/sk counter handling in 33.401 from 36.331	Ericsson	CR	Agreement	Yes	YesNokia didn't agree with this. Stick to one counter; RAN2 is wrong, so we need to tell them with an LS (S3-182616).	not pursued	No
		S3‑182616	LS on using same counters in EDCE5	Ericsson	LS out	Approval	Yes	Yes	approved	No
7.4.12	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.4.13	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)	S3‑182153	Reply LS on CAPIF4xMB	S6-180727	LS in		Yes	Yes	replied to	No
		S3‑182617	Reply to: LS on CAPIF4xMB	Samsung	LS out	approval	Yes	YesAnswering the question on authentication and authorization.	approved	No
		S3‑182154	Reply LS on CAPIF4xMB	S6-180944	LS in		Yes	Yes	noted	No
		S3‑182162	Reply LS on CAPIF specification work in SA3	S6-181290	LS in		Yes	Yes	noted	No
		S3‑182275	Security requirements for API invoker onboarding and offboarding	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182618
		S3‑182618	Security requirements for API invoker onboarding and offboarding	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182275
		S3‑182276	Modifications on Security procedures for API invoker onboarding	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182610
		S3‑182610	Modifications on Security procedures for API invoker onboarding	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182276
		S3‑182277	Clarification on Security protections in CAPIF-1 and CAPIF-2 reference point	Huawei, Hisilicon	CR	Approval	Yes	YesNEC ommented that it's up to the operator to appy security protection, in the first change. This was taken offline.	revised	No	S3‑182619
		S3‑182619	Clarification on Security protections in CAPIF-1 and CAPIF-2 reference point	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182277
		S3‑182216	[CAPIF_Sec] 33122 R15 access token profile	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑182620
		S3‑182620	[CAPIF_Sec] 33122 R15 access token profile	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑182216
		S3‑182282	Access token profile	Huawei, Hisilicon	CR	Approval	Yes	YesMotorola commented that the whole access token was to be defined in the annex, so this was needed.It was agreed to reword it.	merged	No	S3‑182620
		S3‑182278	Clarification on access token verification	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182621
		S3‑182621	Clarification on access token verification	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182278
		S3‑182218	[CAPIF-Sec] 33122 correct note in clause 6.5.2.1	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	revised	No	S3‑182622
		S3‑182622	[CAPIF-Sec] 33122 correct note in clause 6.5.2.1	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	agreed	No		S3‑182218
		S3‑182236	Removal of comment texts	NEC Corporation	CR	Agreement	Yes	Yes	not pursued	No
		S3‑182280	FC value in TS 33.220	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182623
		S3‑182623	FC value in TS 33.220	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182280
		S3‑182281	Adding FC value to TS 33.122	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182624
		S3‑182624	Adding FC value to TS 33.122	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑182281
		S3‑182472	Assignment of FC values to AEFPSK derivation	Samsung	CR		Yes	Yes	merged	No	S3‑182624
		S3‑182495	Assigning FC value to TS 33.122	Samsung	CR		Yes	Yes	merged	No	S3‑182623
		S3‑182217	[CAPIF-Sec] 33122 R15 FC values for CAPIF	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑182219	[CAPIF-Sec] 33220 R15 FC values for CAPIF	Motorola Solutions UK Ltd.	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑182517	Security requirements on the CAPIF-3e/4e/5e reference points	China Telecommunications	CR	Approval	No	Yes	withdrawn	Yes
7.4.14	PLMN RAT selection (Steering of Roaming) (Rel-15)	S3‑182134	LS on Nausf_SoRProtection service	C4-185319	LS in		Yes	Yes	noted	No
		S3‑182156	LS on Guidance on Way Forward for Steering of Roaming	SP-180621	LS in		Yes	Yes	noted	No
		S3‑182137	Reply LS on SoR mechanism	C6-180295	LS in		Yes	Yes	noted	No
		S3‑182470	Updates on Security Mechanism for Steering of Roaming	Samsung, Qualcomm Incorporated, T-Mobile USA	CR		Yes	Yes	agreed	No
		S3‑182493	Handling of initial value of CounterSoR	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑182397	Steering of Information using Secure Packet	Intel Corporation (UK) Ltd	CR		Yes	Yes	withdrawn	Yes
		S3‑182572	LS Reply on Control Plane Solution for Steering of Roaming in 5GS	GSMA	LS in	discussion	Yes	YesPostponed until receiving some guidance from plenary.	postponed	No
7.4.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑182118	Use of SCEF anchored non-IP PDN Connections with BEST	Convida Wireless, InterDigital, Inc.	discussion	Agreement	Yes	Yes	noted	No
		S3‑182119	Adding BEST Support for non-IP PDN Connections that Terminate at the SCEF	Convida Wireless, InterDigital, Inc.	CR	Approval	Yes	Yes	revised	No	S3‑182626
		S3‑182626	Adding BEST Support for non-IP PDN Connections that Terminate at the SCEF	Convida Wireless, InterDigital, Inc.	CR	Approval	Yes	Yes	agreed	No		S3‑182119
		S3‑182120	[Draft] LS on Specification of the EAS-C/U interfaces for BEST	Convida Wireless, InterDigital, Inc.	LS out	Agreement	Yes	Yes	revised	No	S3‑182674
		S3‑182674	LS on Specification of the EAS-C/U interfaces for BEST	InterDigital, Inc.	LS out	Agreement	Yes	Yes	approved	No		S3‑182120
		S3‑182149	Reply LS on new BEST Service	S2-187226	LS in		Yes	Yes	noted	No
		S3‑182456	CR to TS 33.163 (BEST) - correction of Tag values	Vodafone España SA	CR	Agreement	Yes	Yes	revised	No	S3‑182627
		S3‑182627	CR to TS 33.163 (BEST) - correction of Tag values	Vodafone España SA	CR	Agreement	Yes	Yes	agreed	No		S3‑182456
		S3‑182457	CR to TS33.163 (BEST) - clarification of error conditions	Vodafone España SA	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑182458	CR to 33.163 - Clarification as to when the Serving Network TLV is required	Vodafone España SA	CR	Agreement	Yes	Yes	agreed	No
7.4.16	Other work items	S3‑182450	Clarification on motivation and privacy concerns for BT and WLAN measurement collection in MDT	China Mobile	discussion		Yes	YesBT: there's an integrity issue, you can set the SSID to anything you like (spoofing).The initial connection cannot be trusted. Vodafone: we are concerned about the provisioning aspects of the SSID as well. Nokia: How does the bluetooth improve the privacy? There is no use for Bluetooth in this case. China Mobile replied that the operator must have the user consent at first. The user knows that the operator will collect something. Alec (Interdigital) commented that the user consent was not enough to ensure privacy. The identity should not be given. Giving away the location would not help either if they capture the user's Bluetooth beacon. Ericsson: it's not up to us to discuss the usefulness of this.Integrity and confidentiality protection would secure this case enough. Docomo: the operator wants to collect their own Bluetooth beacon, not the user's.They only measure WLAN APs with a certain name as well. A major issue is the use of fake base stations. How to do self-configuration in a secure way would be useful to work on a future work item. Vodafone: roamers have an issue.	noted	No
7.5	New Work Item proposals	S3‑182266	Discussion-slice-management-security	Huawei, HiSilicon, China Mobile, China Unicom, CATR, CATT	discussion	Endorsement	Yes	YesORANGE didn’t see the need to have a WID on this topic.	noted	No
		S3‑182267	WID slicing management security	Huawei, HiSilicon, China Mobile, China Unicom, CATR, CATT	WID new	Approval	Yes	Yes	noted	No
		S3‑182334	New WID on security aspects of single radio voice continuity from 5G to 3G	China Unicom, Huawei, HiSilicon, ZTE, CATT, OPPO	WID new		Yes	YesAlex(BT): in 5G we rely on VoLTE. Scenarios 2 and 3 are unclear since I don’t know what we are standardising. ORANGE commented that the current percentage of completion of the study (50%) may not justify this work item. Ericsson asked about the status of the study in SA2. It was commented that SA2 hadn’t completed the study yet.	revised	No	S3‑182671
		S3‑182671	New WID on security aspects of single radio voice continuity from 5G to 3G	China Unicom, Huawei, HiSilicon, ZTE, CATT, OPPO	WID new	-	Yes	YesORANGE asked if the study was considered as finsihed and the TR sent for approval. BT proposed to send it for information, given that the spec was still missing the SA requirement. Huawei commented that the SA2 WID was to be finished in December. The Chair commented that SA3 usually finished a cycle later than SA2 and that there was no rush. This was a Rel-16 Work Item. Docomo: impact on 5G security needs to be clarified before we go for a WID. The Chair noted the WID and asked China Unicom to bring the WID back for the next meeting. The TR 33.856 was to be sent for information to SA.	noted	No		S3‑182334
8	Studies
8.1	Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)	S3‑182471	Mending MCC EditHelp Comments	Deutsche Telekom AG	pCR	Agreement	Yes	Yes	approved	No
		S3‑182502	Discussion on Key Issues of FS_SBA_Sec	Deutsche Telekom AG	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182503	Introducing a new set of key issues to TR 33.855	Deutsche Telekom AG	pCR	Approval	Yes	YesEricsson: this is not in scope of the study. Deutsche Telekom commented that the former living document had not enough content. ORANGE: is the intention to stop the Study now or we continue to add content in the next release? DT commented that they didn’t see realistic to finish the study in this meeting. MCC commented that if SA3 was going beyond the initial scope and objectives of the Study, they had to revise the Study. Ericsson: routing issues should be added. Vodafone didn’t want to see this closed; there were open issues and the study was still useful for Rel-16. The Rel-15 version of SBA was not robust enough to be implemented. ORANGE supported Vodafone. Ericsson queried whether the study was going to be with a Rel-15 scope or including enhancements for Rel-16. Nokia: there are a couple of open issues not closed in Rel-15. We don’t want to close it now. Vodafone: don’t send it for approval for the next Plenary. BT: what is more interesting is what goes to 33.501. No need to carry on with this TR, close it. Huawei: close the TR. ORANGE: approving this document will leave the study incomplete. Ericsson: the original commitment was to copy the living document into a TR, and save time, This is taking more time than planned. We should close now and open a new Study Item. Vodafone objected to closing the Study.DT preferred to keep it open too. ORANGE would also object to closing the study.	approved	No
		S3‑182683	TR 33.855	Deutsche Telekom	draft TR	Approval	Yes	Yes	approved	No
8.2	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)	S3‑182454	TS 33.834 - editorial updates	Vodafone España SA	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑182455	Draft LS to ETSI SCP regarding the integration of LTKUP solution 4B into the OTA specifications.	Vodafone España SA	LS out	Agreement	No	Yes	withdrawn	Yes
		S3‑182466	LTKUP: solution#5 evaluation	Gemalto N.V.	pCR	Approval	Yes	YesVodafone: this may misinterpret key issue 5. Vodafone commented that there were issues left and that they wanted to continue the study.	revised	No	S3‑182696
		S3‑182696	LTKUP: solution#5 evaluation	Gemalto N.V.	pCR	Approval	Yes	Yes	approved	No		S3‑182466
		S3‑182702	Draft TR 33.834	Vodafone	draft TR	Approval	Yes	Yes	approved	No
8.3	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)	S3‑182251	Performance aspects for the new 256-bit algorithms	CATT	pCR	Approval	Yes	Yes	revised	No	S3‑182537
		S3‑182537	Performance aspects for the new 256-bit algorithms	CATT	pCR	Approval	Yes	YesThere were many concerns on this document so it had to be noted. Vodafone proposed a conference call for the following week to have documents like this as an input.	noted	No		S3‑182251
		S3‑182468	Support of 256-bit algorithms: references	Gemalto N.V.	pCR	Approval	Yes	YesNCSC: 64 bits is only legacy, it should be 96bits and longer. Vodafone wanted the first change removed.	revised	No	S3‑182675
		S3‑182675	Support of 256-bit algorithms: references	Gemalto N.V.	pCR	Approval	Yes	Yes	approved	No		S3‑182468
		S3‑182469	Support of 256-bit algorithms: changes	Gemalto N.V.	pCR	Approval	Yes	YesNCSC objected to the first change. There were many other concerns on this document so it was finally noted.	noted	No
		S3‑182676	Draft TR 33.841	Vodafone	draft TR	Approval	Yes	Yes	approved	No
8.4	Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)	S3‑182289	a proposal for the key issue on protecting the SRVCC capability of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson didn’t agree with this scenario. Huawei commented that this scenario was coming from SA2. Nokia agreed with Ericsson. They didn’t agree with this key issue. Qualcomm agreed with this key issue.	revised	No	S3‑182684
		S3‑182684	a proposal for the key issue on protecting the SRVCC capability of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑182289
		S3‑182290	a proposal for protecting the SRVCC capability of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑182686
		S3‑182686	a proposal for protecting the SRVCC capability of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑182290
		S3‑182336	Evaluation for solution #1.1	China Unicom	pCR		Yes	YesEricsson: the parameter is not new.	revised	No	S3‑182688
		S3‑182688	Evaluation for solution #1.1	China Unicom	pCR	-	Yes	Yes	approved	No		S3‑182336
		S3‑182288	evaluation of solution 1.1 for KI#1	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: remove "basis of normative work".	revised	No	S3‑182687
		S3‑182687	evaluation of solution 1.1 for KI#1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑182288
		S3‑182338	Evaluation for solution #1.2	China Unicom	pCR		Yes	YesEricsson: keep the evaluation but the last sentence seems not to be aligned with SA2.	revised	No	S3‑182689
		S3‑182689	Evaluation for solution #1.2	China Unicom	pCR	-	Yes	Yes	approved	No		S3‑182338
		S3‑182347	Evaluation for solution #1.3	China Unicom	pCR		Yes	Yes	revised	No	S3‑182690
		S3‑182690	Evaluation for solution #1.3	China Unicom	pCR	-	Yes	Yes	approved	No		S3‑182347
		S3‑182291	conclusion for key issue on protecting the SRVCC capability in initial NAS message	Huawei, Hisilicon	pCR	Approval	Yes	YesHuawei: SA2 has concluded on this issue. ORANGE: has SA2 decided to go for normative work? Huawei replied that they have an existing WID.	revised	No	S3‑182691
		S3‑182691	conclusion for key issue on protecting the SRVCC capability in initial NAS message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑182291
		S3‑182391	Propose the content of conclusions	China Unicom	pCR		Yes	YesAlex (BT): if this is the conclusion the TR misses the condition from SA plenary that moving down to UMTS would not cause any impact on 5G. Huawei: this is the conclusion of the key issues only. It was agreed to add an editor's note on this: "Confirmation that solutions do not weaken 5G security (including privacy) for operators not using 5G to UMTS SRVCC needs to be confirmed, as required by SA plenary study agreement."	revised	No	S3‑182692
		S3‑182692	Propose the content of conclusions	China Unicom	pCR	-	Yes	Yes	approved	No		S3‑182391
		S3‑182286	editorial modification on TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑182693
		S3‑182693	editorial modification on TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑182286
		S3‑182685	Draft TR 33.856	China Unicom	draft TR	Approval	Yes	Yes	approved	No
		S3‑182703	Cover sheet for TR 33.856	China Unicom	TS or TR cover	Approval	Yes	YesTR 33.856 is sent for information.	approved	No
8.5	Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)	S3‑182428	A scenario on UAV Nav in AKMA	China Mobile	pCR		Yes	YesORANGE: we don’t need new scenarios here unless they bring any substantial change in the architecture. Interdigital supported this. Companies had many issues with the scenario described here. 429 and 577 were opened to show new scenarios and try to figure out whether these scenarios brough key issues and architecture changes. Huawei: scenarios belong to SA1. We normally have key issues instead of scenarios in our TRs. ORANGE clarified that the scenarios could be brought as justification for the key issue in a discussion paper. ORANGE reminded that this was an internal TR, not intended for sharing externally. This had to be taken offline.	noted	No
		S3‑182429	A scenario on V2X communication in 5G	China Mobile	pCR		Yes	Yes	not treated	No
		S3‑182518	A scenario on secure communication for shared bikes	Alibaba (China) Group., Ltd., China Mobile	pCR	Approval	Yes	Yes	noted	No		S3‑182339
		S3‑182577	A scenario on secure communication for shared bikes	Alibaba (China) Group., Ltd., China Mobile	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑182262	Key issue for fitting GBA into 5G core network functions	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182261	Key issue on keys used in GBA	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182430	Discussion and pCR for secure tranferring between network and 3rd party in AKMA	China Mobile, DT, KPN, LG electronics, Alibaba (China) Group., Ltd.	pCR		Yes	Yes	not treated	No
		S3‑182283	Key Issue on mutual authentication between UE and BSF	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182432	Discussion and pCR for decoupling secure procedure with specific protocol in AKMA	China Mobile, KPN, LG electronics, Alibaba (China) Group., Ltd.	pCR		Yes	Yes	not treated	No
		S3‑182526	Discussion and pCR for identity key issue of AKMA	China Mobile, DT, KPN, Alibaba (China) Group., Ltd.	pCR		Yes	Yes	noted	No		S3‑182431
		S3‑182628	Discussion and pCR for identity key issue of AKMA	China Mobile, DT, KPN, Alibaba (China) Group., Ltd.	pCR	-	Yes	Yes	withdrawn	Yes
		S3‑182508	New key issue on Privacy of subscriber and application user	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑182520	AKMA Architecture for Non-3GPP Credential Download	Alibaba (China) Group., Ltd., China Mobile	pCR	Approval	Yes	Yes	noted	No		S3‑182395
		S3‑182578	AKMA Architecture for Non-3GPP Credential Download	Alibaba (China) Group., Ltd., China Mobile	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑182339	A scenario on secure communication for shared bikes	Alibaba (China) Group., Ltd.	pCR	Approval	Yes	Yes	revised	No	S3‑182518
		S3‑182395	AKMA Architecture for Non-3GPP Credential Download	Alibaba (China) Group., Ltd.	pCR	Approval	Yes	Yes	revised	No	S3‑182520
		S3‑182431	Discussion and pCR for identity key issue of AKMA	China Mobile, DT, KPN, Alibaba (China) Group., Ltd.	pCR		Yes	Yes	revised	No	S3‑182526
		S3‑182695	Key Issue on secure communication between UE and 3rd party application server	China Mobile	pCR	Approval	Yes	YesClause 3.1 (offline discussion bullets) was endorsed. ORANGE considered that submitting a new key issue this late was not appropriate and the he needed more time to study it.	noted	No
8.6	Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)	S3‑182109	New KI proposal for TR 33.861 on CIoT security	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑182235	Key issue proposal for FS_CIoT_sec_5G	NEC Corporation	pCR	Agreement	Yes	Yes	not treated	No
		S3‑182114	New KI proposal for TR 33.861 on CIoT security	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑182116	New KI proposal for TR 33.861 on CIoT security	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑182467	Key Issue on Authentication	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑182694	Key Issue on Authentication	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑182246	pCR to TR33.861: Authentication of a group of CIoT devices	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182407	New key issue for integrity protection of small data	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑182408	New key issue for encryption of small data	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑182264	Key issue on security for small data transmission	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182113	New KI proposal for TR 33.861 on CIoT security	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑182115	New KI proposal for TR 33.861 on CIoT security	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑182247	pCR to TR33.861: Secure Communication for a group CIoT devices	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182322	For Information: Discussion document on dealing with maliciously behaving devices	KPN N.V.	discussion	Information	Yes	Yes	not treated	No
		S3‑182323	For Information: Potential new key issue	KPN N.V.	other	Information	Yes	Yes	not treated	No
		S3‑182248	Key Issue on gNB Protection from CIoT DoS attack	Huawei, Hisilicon, China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑182263	Key issue on DoS attack on the network for CIoT	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182405	New key issue for security key storage	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑182300	Key Issue on IoT Terminal Security Monitoring	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182210	Key issue avoiding AS encryption for application security enabled UE	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑182510	New key issue on flexible security of CIoT devices	LG Electronics	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑182404	New key issue for security key refreshing	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑182509	New key issue on provisioning of CIoT devices	LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑182117	New KI proposal for TR 33.861 on CIoT security	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑182406	New key issue for security key and authentication tag size	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑182324	For Information: A potential new solution for dealing with maliciously behaving devices	KPN N.V.	other	Information	Yes	Yes	not treated	No
8.7	Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)	S3‑182152	LS on devices behind 5G-RG accessing the 5GC	S3i180377	LS in		Yes	Yes	postponed	No
		S3‑182309	skeleton of TR 33807	Huawei, Hisilicon	draft TR	Approval	Yes	Yes	approved	No
		S3‑182310	scope of TR33807	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182158	New KI proposal for TR 33.807 on security of the Wireless and Wireline Convergence for the 5G system architecture	InterDigital, Inc.	pCR	Approval	Yes	Yes	not treated	No
		S3‑182498	Key Issue on Access to 5GC from UEs that do not support NAS	Motorola Mobility, Lenovo	pCR	Approval	Yes	Yes	not treated	No
		S3‑182497	Key Issue on Registration and NAS transport for trusted non-3GPP access	Motorola Mobility, Lenovo	pCR	Approval	Yes	Yes	not treated	No
		S3‑182315	new requirement of truted access	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182311	new requirement of 5G RG	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182312	new requirement of NAS security	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182313	new requirement of multi NAS connection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑182314	new requirement of UP security	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
8.8	Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)	S3‑182151	Reply LS on clarification on Restricted Operator Services	S2-181407	LS in		Yes	Yes	postponed	No
		S3‑182211	Key issue providing temperory security for PARLOS PDU session	Nokia, Nokia Shanghai bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑182252	Proposed Skeleton for TR	SPRINT Corporation	draft TR	Agreement	Yes	Yes	approved	No
		S3‑182253	P-CR proposing Background clause text	SPRINT Corporation	pCR	Agreement	Yes	Yes	not treated	No
		S3‑182254	P-CR proposing Introduction clause text	SPRINT Corporation	pCR	Agreement	Yes	Yes	not treated	No
		S3‑182255	P-CR proposing Scope clause text	SPRINT Corporation	pCR	Agreement	Yes	Yes	not treated	No
		S3‑182256	P-CR proposing Requirements, assumptions and constraint clause text	SPRINT Corporation	pCR	Agreement	Yes	Yes	not treated	No
		S3‑182412	Support for Unauthenticated UEs access to RLOS using EPC	Intel Corporation (UK) Ltd	pCR		Yes	Yes	not treated	No
		S3‑182416	EPC solution for RLOS access	Intel Corporation (UK) Ltd	pCR		Yes	Yes	noted	No
		S3‑182631	EPC solution for RLOS access	Intel Corporation (UK) Ltd	pCR	-	No	Yes	withdrawn	Yes
		S3‑182496	Key Issue on PARLOS Security	Motorola Mobility, Lenovo	pCR	Approval	Yes	Yes	not treated	No
8.9	Other study areas	S3‑182449	Discussion on clarification of concept of slice authentication	China Mobile	discussion	Endorsement	Yes	YesORANGE: cat 1 and cat 2 can be discarded. I can agree with cat 3, this slice authentication comes after a succesful primary authentication. I agree with the conclusion. Colin (BT) agreed with cat 3 as well. China Mobile asked to be minuted that the SA3 preference was on cat 3. ORANGE added that this would be with some modification on the objectives of the Study Item in 2212.	noted	No
8.10	New study item proposals	S3‑182212	SID on Enhanced network Slicing	Nokia, Nokia Shanghai Bell,NEC, Huawei, HiSilicon,Motorola Mobility, Lenovo	SID new	Approval	Yes	YesHuawei: less about network slicing than it is stated. ZTE: network slice security belongs to phase two. The Chair commented that this was coming from an agreement from last meeting. China Mobile: we need to clarify the authentication in the network slice context. We have a discussion paper about this in 449. From this document it was preffered to go for cat 3. ORANGE commented that SA2 had ths in their study. Ericsson: the last bullet is a bit out of scope of this SID, it should belong to another SID. Vodafone agreed. Qualcomm: inter-slice security isolation? Where is this defined?ORANGE and Gemalto wanted to keep this bullet. Huawei: add privacy issues. ORANGE: privacy is in our terms of reference. We always take it into account. Interidigital: all security issues are part of the ToR.	revised	No	S3‑182665
		S3‑182665	SID on Enhanced network Slicing	Nokia, Nokia Shanghai Bell,NEC, Huawei, HiSilicon,Motorola Mobility, Lenovo	SID new	Approval	Yes	Yes	agreed	No		S3‑182212
		S3‑182244	Study of 5G System Security Phase-2	Huawei, Hisilicon,	SID new	Approval	Yes	Yes	revised	No	S3‑182625
		S3‑182625	Study of KDF negotiation for 5G System Security	Huawei, Hisilicon,	SID new	Approval	Yes	YesORANGE: overlapping with our study in LTE-CUP. AT&T supported this SID. Qualcomm: RAN related stuff should go to a different SID. A single SID with a long list of objectives woud be too much and this is the way other 3GPP WGs are working this way. ORANGE supported this.	agreed	No		S3‑182244
		S3‑182249	Study on 5G security enhancement	Apple Computer Trading Co. Ltd	SID new	Approval	Yes	YesORANGE: privacy was covered in 5G phase one already. Interdigital: during fake base station attack, identifiers can be leaked. NCSC: these studies seem to affect only the UE, are studying impact on the core? Apple replied that the core was covered. T-Mobile: overlap with the Huawei SID. The Chair commented that there had been a privacy study item in the past whose results were not satisfactory. ORANGE proposed some rewording regarding privacy. The objectives were also simplified. Ericsson: giving a handbook of threats to 5G is giving a bad image. Let's focus on solutions and not study the threats. Ericsson commented that there was agreement on having focused studies and that they could come back in the next meeting with the different studies. Discussing the content during the present meeting would be time consuming. Huawei agreed.	revised	No	S3‑182634
		S3‑182634	Study on 5G security enhancement against false base stations	Apple Computer Trading Co. Ltd	SID new	Approval	Yes	Yes	revised	No	S3‑182704	S3‑182249
		S3‑182704	Study on 5G security enhancement against false base stations	Apple Computer Trading Co. Ltd	SID new	Approval	Yes	Yes	agreed	No		S3‑182634
		S3‑182250	New WID on Security of the enhancement to the 5GC location services	CATT	SID new	Agreement	Yes	YesORANGE: some statements are normative. Qualcomm: in SA2 they consider translating what we have in LTE in the 5G system. Security threats are not clear. We don’t think that this is SID is needed. A SID could be needed depending on RAN's work such as broadcast aspects. Ericsson: we should take a look at any work that SA2 is doing.We support this SID with a simplified objective.	revised	No	S3‑182678
		S3‑182678	New SID on Security of the enhancement to the 5GC location services	CATT	SID new	Agreement	Yes	Yes	agreed	No		S3‑182250
		S3‑182265	The SID on security for 5G URLLC	Huawei, HiSilicon	SID new	Approval	Yes	YesQualcomm: we have seen this before and rejected it. What's new? Huawei: SA2's progressed and they have security issues that need to be taken into account here. Vodafone: we would trigger this SID with an LS from SA2. Docomo: we should start working on our own and not wait for SA2 to start any kind of work. A discussion paper would have been helpful to explain to us what the issues are instead of "security issues were detected". Qualcomm supported this. ORANGE also wanted a discussion paper on what SA2 is doing and the security issues that are identified in their work. Interdigital: asking SA2 for the security issues? That's our job. Huawei clarified that SA2 would finish their study in September.	revised	No	S3‑182679
		S3‑182679	The SID on security for 5G URLLC	Huawei, HiSilicon	SID new	Approval	Yes	Yes	agreed	No		S3‑182265
		S3‑182333	Discussion on Security Assurance for 3GPP Virtualized Network Products	Nokia, Nokia Shanghai Bell, China Mobile	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182378	Security enhancements in LTE	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑182379	Security enhancements in 5G	Ericsson	discussion	Endorsement	Yes	YesQualcomm: we cannot limit to these two points.	noted	No
		S3‑182423	Discussing about the necessity of SCAS for 3GPP virtualized network products	China Mobile	discussion	Discussion	Yes	Yes	noted	No
		S3‑182424	Discussing about ToE of SCAS for 3GPP virtualized network products	China Mobile	discussion	Decision	Yes	Yes	noted	No
		S3‑182425	Discussing about the SECAM and SCAS for 3GPP virtualized network products	China Mobile	discussion	Decision	Yes	Yes	noted	No
		S3‑182426	Implications of Network Function Virtualisation	BT plc	discussion	Discussion	Yes	Yes	noted	No
		S3‑182427	New SID on SECAM and SCAS for 3GPP virtualized network products	China Mobile, Nokia, Nokia Shanghai Bell, China Unicom, CAICT, CATT, ZTE	SID new		Yes	YesAlex (BT): it misses whether we have to make changes in the architecture in order to virtualize it. Ericsson: this assumes impact on our architecture and we want to avoid that. Enhancement on the existing architecture is not what SCAS is about. NCSC: let's extend it beyond SCAS. The Chair commented that this could duplicate work done in other groups like ETSI ISG NFV. Better to separate SCAS activities from architecture enhancements. Colin (BT): deployment issues are in scope of GSMA. Ericsson: we will not be doing security assurance for platforms (e.g. proposed by ETSI NFV). Nokia: this is a study, there is no normative output here. Ericsson conceded given that this was a study.	revised	No	S3‑182681
		S3‑182681	New SID on SECAM and SCAS for 3GPP virtualized network products	China Mobile, Nokia, Nokia Shanghai Bell, China Unicom, CAICT, CATT, ZTE	SID new	-	Yes	Yes	agreed	No		S3‑182427
		S3‑182444	Intro to FS_VERTICAL_LAN_SEC	Nokia, Nokia Shanghai Bell	discussion		Yes	Yes	noted	No
		S3‑182445	SID_FS_VERTICAL_LAN_SEC	Nokia, Nokia Shanghai Bell	SID new		Yes	Yes	revised	No	S3‑182682
		S3‑182682	Study on Security for 5GS Enhanced support of Vertical and LAN Services	Nokia, Nokia Shanghai Bell	SID new	-	Yes	Yes	agreed	No		S3‑182445
		S3‑182677	Study on the supporting of perfect forward secrecy for 5G Authentication and Key Agreement Protocols	Huawei	SID new	Agreement	No	Yes	withdrawn	Yes
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑182102	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑182105	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑182699
		S3‑182699	Work Plan input from Rapporteurs	MCC	other	-	No	Yes	noted	No		S3‑182105
10	Future Meeting Dates and Venues	S3‑182104	SA3 meeting calendar	MCC	other		Yes	Yes	revised	No	S3‑182698
		S3‑182698	SA3 meeting calendar	MCC	other	-	Yes	Yes	noted	No		S3‑182104
11	Any Other Business
12	Close