TDoc list

Tdoc List

2018-05-25 14:56

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‑181600	Agenda	WG Chairman	report		Yes	Yes The Chair commented that finishing 5G items was a priority for the meeting and anything else would be secondary. Qualcomm commented that LS should be considered early since RAN groups and others were having their meetings during the same week.	approved	No
3	IPR and Anti-Trust Law Reminder
4	Meeting Reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑181601	Report from last SA3 meeting	MCC	report		Yes	Yes	approved	No
4.2	Report from SA Plenary
4.3	Report from SA3-LI
5	Items for early consideration
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑181609	LS on LMR Interworking Terminology	C1-182644	LS in		Yes	Yes	noted	No
		S3‑181616	Response to LS on encrypting broadcasted positioning data and LS on provisioning of positioning assistance data via LPPa for broadcast	R2-1806307	LS in		Yes	Yes	noted	No
		S3‑181617	Reply LS to SA3 on encryption of broadcast positioning information	R2-1806308	LS in		Yes	Yes 786 has a reply LS proposal. Commented in 920.	replied to	No
		S3‑181707	Discussion Paper of CIoT Early Data Transmission (EDT)	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes Ericsson: we see no security issues with the new key. No threat. Qualcomm: no point with keeping the old keys.Samsung agreed. Ericsson:The source generates a new key and gives it to the target. We are not breaking any security requirement. This had to be taken offline. Tdocs related: 860, 708,778,615.	noted	No
		S3‑181708	Draft Reply LS to SA2 regarding EDT	Huawei, Hisilicon	LS out	Approval	Yes	Yes	noted	No
		S3‑181778	Reply LS on security keys for generation of shortResumeMAC-I for UP EDT	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
		S3‑181785	Security solution for encryption of broadcast positioning information	Qualcomm Incorporated	LS out	Approval	Yes	Yes	revised	No	S3‑181926
		S3‑181926	Security solution for encryption of broadcast positioning information	Qualcomm Incorporated	LS out	Approval	Yes	Yes Incorporates Ericsson's comments in 920.	approved	No		S3‑181785
		S3‑181786	On the ciphering of broadcasted positioning data	Qualcomm Incorporated	other	Endorsement	Yes	Yes	noted	No
		S3‑181920	Comments on S3-181786 “On the ciphering of broadcasted positioning data”	Ericsson	discussion	Endorsement	Yes	Yes Qualcomm agreed with this proposal.	endorsed	No
		S3‑181925	Reply LS to RAN2 on Bluetooth/WLAN measurement collection in MDT	S5-183626	LS in	discussion	Yes	Yes Qualcomm: why is Bluetooth wanted here? China Mobile: connection IDs may imply some privacy issues. RAN2 will reply and put SA3 in copy. BT: collecting data in MDT brings privacy concerns in general. We have seen this before. Docomo: collecting SSIDs has brought problems in Europe before. This LS was taken offline in order to understand better the issue.	postponed	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA
6.5	OMA
6.6	TCG	S3‑181647	TCG progress report	InterDigital, Inc.	report	Information	Yes	Yes 1. TCG – Highlights New/modified work items none Publication of new or revised deliverables (incremental changes from the status reported at SA3#91) o TCG TMS Use Cases v2 – to be published May 2018 o TCG SNMP MIB for TPM-based Attestation – public review May 2018 2. Meetings TCG Members Meeting in San Diego, CA – 18-22 June 2018 TCG Members Meeting in Lisbon, PT – 15-18 October 2018 MPWG meets every Thursday at 10-11 ET TMS WG meets every Monday and Friday at 12-13 ET	noted	No
6.7	oneM2M
6.8	TC-CYBER
6.9	ETSI NFV security
6.10	Other Groups
7	Work Areas
7.1	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)	S3‑181688	Correction and Clarification for EDCE5	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑181773	Clarify that both split bearers and SCG bearer may need security resources at the SgNB	Qualcomm Incorporated	CR	Agreement	Yes	Yes Huawei: we need corrections in other places. Where these needed to be corrected in other places was taken offline.	revised	No	S3‑181927
		S3‑181927	Clarify that both split bearers and SCG bearer may need security resources at the SgNB	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑181773
		S3‑181770	Referencing algorithm and key derivation description for EN-DC that exist in TS 33.501	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑181771	Assigning FC values to TS 33.501	Qualcomm Incorporated	CR	Agreement	Yes	Yes Related to tdoc 883.	revised	No	S3‑181928
		S3‑181928	Assigning FC values to TS 33.501	Qualcomm Incorporated,LG	CR	Agreement	Yes	Yes	agreed	No		S3‑181771
		S3‑181772	Adding FC values to TS 33.501	Qualcomm Incorporated	other	Approval	Yes	Yes	noted	No
7.2	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
7.2.1	Key hierarchy	S3‑181729	Clause 6.2.3-Editorial_reference_wording_error correction -based on Living CR S3-181434	CATT	CR	Approval	Yes	Yes	revised	No	S3‑181995	S3‑181434
		S3‑181995	Clarifications to: Key hierarchy, key derivation, and distribution scheme	CATT,NEC,ZTE,Ericsson,Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑181729
		S3‑181720	Improvements for key derivation an distribution scheme	Huawei, HiSilicon	other	Agreement	Yes	Yes Overlapping with 752.	merged	No	S3‑181996
		S3‑181728	Clause 6.2.2-Editorial_reference_wording_error correction -based on Living CR S3-181578	CATT	CR	Agreement	Yes	Yes	merged	No	S3‑181996	S3‑181578
		S3‑181664	Improvements for key derivation an distribution scheme	Huawei, HiSilicon	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑181996	Reference corrections in clause 6	Huawei, NEC,CATT,HiSilicon	CR	Agreement	Yes	Yes	agreed	No		S3-181578
7.2.2	Key derivation	S3‑181752	Resolving an EN on event(s) that triggers the storage of Keys in clause 6.2.2.2	NEC Corporation	CR	Agreement	Yes	Yes Qualcomm didn’t agree with this CR.Authentication shouldn’t trigger the storage.	merged	No	S3‑181996
		S3‑181764	Updates to Key distribution and derivation scheme (keys in network entities)	NEC Corporation	CR	Agreement	Yes	Yes Qualcomm: the figure displays too much and it's hard to read. The content will be added to 996.	not pursued	No		S3‑181354
		S3‑181765	Updates to Key distribution and derivation scheme (keys in UE)	NEC Corporation	CR	Agreement	Yes	Yes	merged	No	S3‑181996
7.2.3	Mobility	S3‑181680	CR on Cluase 6.6 UP security mechanism with security policy	Nokia	other	Approval	Yes	Yes Huawei: This is limiting the available resources as decided by RAN.	revised	No	S3‑181999
		S3‑181999	CR on Clause 6.6 UP security mechanism with security policy	Nokia	other	Approval	Yes	Yes	merged	No	S3‑181987	S3‑181680
		S3‑181753	Calculation of NAS MAC included in NAS Container at N2 HO	Ericsson	CR	Agreement	Yes	Yes Two options to choose from in 753 and 783. This was taken offline (although it seemed that most companies wanted 783).	revised	No	S3‑182062
		S3‑182062	Calculation of NAS MAC included in NAS Container at N2 HO	Ericsson,Qualcomm	CR	Agreement	Yes	Yes Ericsson stated that clause 6.9.2.3.3 needed further clarification. This was agreed to be added to the meeting report.	merged	No	S3‑181979	S3‑181753
		S3‑181783	NAS MAC calculation for NASC and text clarifications on Cluase 6.9.2.3.3 and 6.9.2.3.4 (changes to S3-181511)	Qualcomm Incorporated	other	Agreement	Yes	Yes	merged	No	S3‑182062
		S3‑181754	UE handover handling - corrections and clarifications	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑182062	S3‑181511
		S3‑181755	Network N2-handover handling - corrections and clarifications	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑182062	S3‑181511
		S3‑181756	Network Xn-handover handling – correction of indicator name	Ericsson	other	Agreement	Yes	Yes	noted	No		S3‑181511
		S3‑182052	Network Xn-handover handling – correction of indicator name	Ericsson	other	Agreement	No	Yes	withdrawn	Yes
		S3‑181787	Updates to clause 6.9.3	NEC Corporation	CR	Agreement	Yes	Yes Revised content is in S3-182004.	not pursued	No		S3‑181511
		S3‑181880	Clarifications to 6.9.2 key handling in handover (rev of CR0125)	LG Electronics	CR	Agreement	Yes	Yes	revised	No	S3‑182005	S3‑181354
		S3‑182005	Generalization of key derivation in NG-RAN to cover both gNBs and ng-eNBs	LG Electronics,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181880
		S3‑182004	Updates to clause 6.9.3	NEC	other	Approval	Yes	Yes Revised content from S3-181787, it shows the changes from 511.	merged	No	S3‑181979
7.2.4	AS security	S3‑181861	Discussion on RAN2 LS on reporting Integrity check failure for DRB to network	Samsung	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181873	[DRAFT] Reply LS to S3-181619 (R2-1806490) on reporting Integrity check failure for DRB to network from RAN WG2	Lenovo	LS out		Yes	Yes Qualcomm had a preference for this solution rather than the one in 861. Nokia and Intel as well. Ericsson commented that the Samsung proposal in 861 was a useful feature. Huawei and Interdigital agreed with Samsung. Qualcomm: when having the CRC failure the UE will recover in the next transmission. If there is a man in the middle there is no guranteee that the report will reach the network. KPN agreed that this was a rare case, there was no added value in this reporting. BT supported Samsung: it should be reported back. Docomo added that this report had to be integrity protected, it didn’t seem to be an useful feature. This discussion was taken offline.	revised	No	S3‑181998
		S3‑181998	Reply LS to S3-181619 (R2-1806490) on reporting Integrity check failure for DRB to network from RAN WG2	Lenovo	LS out	-	Yes	Yes	approved	No		S3‑181873
		S3‑181859	Discussion on RAN2 LS on security for inactive state	Samsung	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181706	Reply SA3 LS on security for inactive state	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑181997
		S3‑181997	Reply SA3 LS on security for inactive state	Huawei, Hisilicon	LS out	Approval	Yes	Yes	approved	No		S3‑181706
		S3‑181693	Security Negotiation for RRC INACTIVE	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182061
		S3‑182061	Security Negotiation for RRC INACTIVE	Huawei, Hisilicon,Ericsson,Qualcomm,Intel,Samsung	CR	Approval	Yes	Yes	agreed	No		S3‑181693
		S3‑181694	Key Handling at RRC state transitions	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑182060
		S3‑182060	Key Handling at RRC state transitions	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑181694
		S3‑181784	Security handling at RRC state transitions (changes to S3-181456)	Qualcomm Incorporated	other	Agreement	Yes	Yes	merged	No	S3‑182060
		S3‑181860	Discussion on RAN2 LS on security keys for generation of shortResumeMAC-I	Samsung	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181695	Security Mechanisms for Dual Connectivity Architecture for MR-DC with 5GC	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑181985
		S3‑181985	Security procedures for dual connectivity	Huawei, Hisilicon,Qualcomm,Ericsson	CR	Approval	Yes	Yes	agreed	No		S3‑181695
		S3‑181774	Filling is some of the details on dual connectivity for TS 33.501	Qualcomm Incorporated	other	Approval	Yes	Yes	merged	No	S3‑181984
		S3‑181848	Dual Connectivity - introduction	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181984	S3‑181517
		S3‑181849	Dual Connectivity - dc procedures	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181984	S3‑181517
		S3‑181850	Dual Connectivity - other procedures	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181984	S3‑181517
		S3‑181851	Dual Connectivity - keys and algorithms	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181984	S3‑181517
		S3‑181852	Dual Connectivity - other security mechanisms	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181984	S3‑181517
		S3‑181637	Correction for TS 33.501 subclause 6.6.1	InterDigital, Inc.	CR	Approval	Yes	Yes Ericsson: the first change is confusing.Whatever applies to a PDU session applies to all DRBs serving that PDU session.	merged	No	S3‑181987
		S3‑181986	Correction for TS 33.501 subclause 6.6.1	InterDigital, Inc.	CR	Approval	No	Yes	withdrawn	Yes
		S3‑181897	Update in clause UP security mechanism and Xn-HO procedure	OPPO	CR	Approval	Yes	Yes	not pursued	No
		S3‑181705	Unauthenticated Emergency Calls can use NEA0	Huawei, Hisilicon	CR	Approval	Yes	Yes ORANGE: no need for a new requirement. Huawei: we can make it a note. Ericsson didn't agree with the addition in the requirement clause.	not pursued	No
		S3‑181788	Correcting Figure 6.13-1 on gNB periodic local authentication procedure	NEC Corporation	CR	Approval	Yes	Yes	revised	No	S3‑181988	S3‑181340
		S3‑181988	Correcting Figure 6.13-1 on gNB periodic local authentication procedure	NEC Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑181788
		S3‑181840	Corrections of references to sub-clauses	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑181987	Clarifications to: UP security mechanisms	Interdigital,Huawei, LG	CR	Agreement	Yes	Yes	agreed	No		S3‑181520
		S3‑182085	LS to RAN2 on Dual Connectivity	Ericsson	LS out	discussion	Yes	Yes	approved	No
7.2.5	NAS security	S3‑181781	missing implementation of merging S3-181566 to S3-181511	Qualcomm Incorporated	other	Agreement	Yes	Yes	merged	No	S3‑181979
		S3‑181690	Discussion on Protection of initial NAS message	Huawei, Hisilicon	discussion	Approval	Yes	Yes	noted	No
		S3‑181767	Discussion on the incoming LS from SA2 on initial NAS protection	Qualcomm Incorporated	other	Discussion	Yes	Yes Ericsson: Partial cyphering mechanism. How important is this for Rel-15? Better to postpone it for Rel-16. In CT1 the partial cyphering mechanism will be treated in Rel-16. Qualcomm: initial registration, I cannot use the upper parameters. Nokia: better to introduce it earlier, Rel-15, and use it. KPN and Deutsche Telekom supported Qualcomm. This was finally noted.	noted	No
		S3‑181769	Proposed updates to the CR on initial NAS protection (S3-181544)	Qualcomm Incorporated	other	Approval	Yes	Yes Ericsson: we need to wait for CT1's reply to the LS before removing this Editor's note.	revised	No	S3‑181934
		S3‑181934	Proposed updates to the CR on initial NAS protection (S3-181544)	Qualcomm Incorporated	other	Approval	Yes	Yes	merged	No	S3‑181935	S3‑181769
		S3‑181727	Remove Initial NAS Message Protection Solution from clause 6.4.6	Huawei, Hisilicon	other		Yes	Yes	noted	No
		S3‑181691	Draft Reply LS to SA2 on initial NAS message protection	Huawei, Hisilicon	LS out	Approval	Yes	Yes	merged	No	S3‑181933
		S3‑181768	LS response on Initial NAS message protection	Qualcomm Incorporated	LS out	Approval	Yes	Yes	revised	No	S3‑181933
		S3‑181933	LS response on Initial NAS message protection	Qualcomm Incorporated	LS out	Approval	Yes	Yes	approved	No		S3‑181768
		S3‑181681	Discussion paper Clause 6.9.5.2 clarification on completion of NAS SMC	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181682	CR Clause 6.9.5.2 clarification on completion of NAS SMC	Nokia	other	Approval	Yes	Yes	merged	No	S3‑181979
		S3‑181779	Using Registration Accept to change the security context on the other access	Qualcomm Incorporated	other	Approval	Yes	Yes	noted	No
		S3‑181847	Multiple NAS connections	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181980	S3‑181547
		S3‑181683	Discussion EN on Simultaneous NAS connections context.	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181910	CR for Deletion of Editor Notes in 6.4.2	Nokia	other	Approval	Yes	Yes	merged	No	S3‑181980
		S3‑181725	Delete Editor’s Note of Multiple NAS connections	Huawei, Hisilicon	other	Agreement	Yes	Yes Qualcomm didn't agree with deleting the editor's note. It would affect the deregistration of UEs when there is a multiple connection. Ericsson also had an issue with deleting the editor's note, but didn’t agree with Qualcomm's proposal. Qualcomm proposed to reword the editor's note to describe better the problem. It was agreed to minute the description of the problem rather than adding another editor's note.	merged	No	S3‑181980
		S3‑181766	Updates on key handling for registration via 5G-RAN	NEC Corporation	other	Approval	Yes	Yes Ericsson agreed with the changes but suggested to make it more generic instead of adding the values here. Some part willl go to 981 and some part will go to 982.	approved	No	S3‑181981
		S3‑181777	Resolving action item on collision between S3-181512 and S3-181547 from SA3 #91	Qualcomm Incorporated	other	Discussion	Yes	Yes	noted	No
		S3‑181844	Update to clause 6.7.2 and Annex F.4	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181983	S3‑181518
		S3‑181879	Clarfication to 6.4.1 NAS security general	LG Electronics	CR	Agreement	Yes	Yes	agreed	No
		S3‑181692	Remove initial NAS message protection solution from clause 6.4.6	Huawei, Hisilicon	CR	Approval	No	Yes	withdrawn	Yes
		S3‑181701	Delete the EN in section 6.4.2	Huawei, Hisilicon	CR	Approval	No	Yes	withdrawn	Yes
		S3‑181684	CR to delete EN on Simultaneous NAS connections context	Nokia	other	Approval	Yes	Yes	withdrawn	Yes
		S3‑181935	Remove EN for initial NAS message protection	Qualcomm	CR	Agreement	Yes	Yes	agreed	No		S3‑181544
		S3‑181979	Clarifications to: Security handling in mobility	Qualcomm,ZTE,NEC	CR	Agreement	Yes	Yes	revised	No	S3‑182092	S3‑181511
		S3‑182092	Clarifications to: Security handling in mobility	Qualcomm,ZTE,NEC	CR	Agreement	Yes	Yes	agreed	No		S3‑181979
		S3‑181980	Multiple NAS connections	Ericsson,ZTE,Huawei,Qualcomm,Nokia	CR	Agreement	Yes	Yes It was endorsed that SA3 still needs to look at some of the mobility use cases in multi-NAS to ensure the procedures for handling NAS Security context do not cause problems. An example of when they may be an issue is when the UE performs a mobility procedure on 3GPP and causes the non-3GPP access to move AMF. The new AMF may not be able to use the security context that was in use on the old AMF (e.g. due to horizontal K_AMF change or different supported algorithms on the AMFs). This means that once the non-3GPP context has moved to the new AMF, the UE and new AMF will not be able to exchange secured NAS messages using the old security context.	agreed	No		S3‑181547
		S3‑181981	Clarifications to: Security handling in state transitions	NEC,Nokia,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181456
		S3‑181982	Authentication for Untrusted non-3GPP Access	NEC,Huawei,Nokia,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181574
		S3‑181983	CR for Clause Security algorithm selection, key establishment and security mode command procedure	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181518
7.2.6	Security context	S3‑181759	Sending ABBA to the UE with ngKSI	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑181760	Update to clause 6.7.2: ngKSI and ABBA	Ericsson	other	Agreement	Yes	Yes	revised	No	S3‑182006	S3‑181518
		S3‑182006	Update to clause 6.7.2: ngKSI and ABBA	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181983	S3‑181760
		S3‑181761	Update to clause 6.1.3: ngKSI and ABBA	Ericsson	other	Agreement	Yes	Yes Nokia and Huawei didn’t agree with step 12 of the figure. This was removed.	revised	No	S3‑182007	S3‑181453
		S3‑182007	Update to clause 6.1.3: ngKSI and ABBA	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181990	S3‑181761
		S3‑181762	Update to Annex B: ngKSI and ABBA	Ericsson	other	Agreement	Yes	Yes	revised	No	S3‑182008	S3‑181470
		S3‑182008	Update to Annex B: ngKSI and ABBA	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181993	S3‑181762
		S3‑181776	Resolving the editor’s note on the ABBA parameter	Qualcomm Incorporated	other	Approval	Yes	Yes MCC commented that the note had normative language. The "needs to be" was reworded and the second sentence removed. Ericsson: How does the UE know about the length? Qualcomm: it's in the IE, as defined by CT1.	merged	No	S3‑181929
7.2.7	Visibility and Configurability
7.2.8	Primary authentication	S3‑181802	Resolving Editor’s Note on USIM	Orange Romania	CR	Agreement	Yes	Yes ORANGE clarified that there is no reference to the ETSI SSP work, only this Editor's note. Qualcomm wanted to be minuted that SSP should be added as a solution when it's ready from ETSI SCP and complies with the 33.501 security requirements. ORANGE commented that this would come later in a proper CR that had to be discussed. They wanted to mention the release in the minutes. Ericsson: SA plenary said that SSP is release independent. ORANGE: it cannot be included in Rel-15 since it will be over in June. Vodafone: it will be a new feature, it will require updates in CT6 specs and it will have to go to the next release for this reason. There was disagreement whether to mention the Release in the minutes when deleting the editor's note, so the CR had to be taken offline. Eventually the decision was to remove the editor's note and have minuted: ETSI SCP is working on a new secure element called SSP. The SSP can be included as another solution where the USIM can reside on, if the SSP is defined in the Release 16 timeframe and if it complies with the security requirements defined in TS 33.501.	agreed	No
		S3‑181649	Statement on urgency of alignment of ETSI SSP with 3GPP release 15	GSMA	LS in		Yes	Yes	noted	No
		S3‑181749	Updates to clause 6.1.1.1	NEC Corporation	CR	Agreement	Yes	Yes Ericsson,Nokia: it's not clarifying anything here.	not pursued	No		S3‑181460
		S3‑181757	Update to clause 6.1.3: clarification on EAP notifications	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181990	S3‑181453
		S3‑181758	Correction to: 3GPP 5G profile for EAP-AKA'	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑181991
		S3‑181991	Correction to: 3GPP 5G profile for EAP-AKA'	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181758
		S3‑181790	Corrections to section 5.1.2 Authentication and Authorization	China Mobile Com. Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑181868	Clarification of the error handling if 5G-GUTI was used	Motorola Mobility, Lenovo	draftCR		Yes	Yes	merged	No	S3‑181990	S3‑181453
		S3‑181719	Clause 6.1.2-Clarification to authentication method selection-based on Living CR S3-181465	CATT, China Mobile	CR	Agreement	Yes	Yes	not pursued	No		S3‑181465
		S3‑181726	Clause 6.1.3- Editorial_reference_wording_error correction -based on Living CR S3-181453	CATT	CR	Agreement	Yes	Yes	merged	No	S3‑181990	S3‑181453
		S3‑181730	Clause 6.3.1.4-Reference_wording_error correction -based on Living CR S3-181455	CATT	CR	Agreement	Yes	Yes	revised	No	S3‑181992	S3‑181455
		S3‑181992	Clause 6.3.1.4-Reference_wording_error correction -based on Living CR S3-181455	CATT	CR	Agreement	Yes	Yes	agreed	No		S3‑181730
		S3‑181718	Annex B-Wording correction -based on Living CR S3-181470	CATT	CR	Agreement	Yes	Yes	revised	No	S3‑181993	S3‑181470
		S3‑181993	Clarifications to: Using additional EAP methods for primary authentication	CATT	CR	Agreement	Yes	Yes	agreed	No		S3‑181718
		S3‑181990	Clarifications to: Authentication procedures	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181453
7.2.9	Secondary authentication	S3‑181669	ID binding for 2nd Authentication	Huawei, HiSilicon, China Southern Power Grid, China Unicom	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑181670	Discussion on ID binding for 2nd Authentication	Huawei, HiSilicon, China Southern Power Grid, China Unicom	discussion	Endorsement	Yes	Yes ORANGE: the secondary authentication credentials will stop the second UE from accessing the network with the USIM. SIM lock would also solve the issue. Qualcomm: no requirements for the DN-AAA should be made here. The Chair commented that IoT was not to be treated in Rel-15 as agreed for phase one. Qualcomm: we have studied this use case for MTC and implemented it. Interdigital: this logging is illegal in some countries.	noted	No
		S3‑181712	ID linkage verification in secondary authentication	Huawei, HiSilicon, China Southern Power Grid, China Unicom	other	Agreement	Yes	Yes	revised	No	S3‑182032
		S3‑182032	ID linkage verification in secondary authentication	Huawei, HiSilicon, China Southern Power Grid, China Unicom	other	Agreement	Yes	Yes	noted	No		S3‑181712
		S3‑181733	Clause 11.1.2 Add EAP failure processing-based on Living CR S3-181569	CATT, China Mobile	CR	Approval	Yes	Yes Ericsson: we usually don’t specify failure cases or if we do, we need to specify what happens afterwards. ORANGE: why does the UPF need to be notified? Ericsson: to release resources, but this is not in our scope. The last change was kept in 2038 which was merged in the CR in 2037.	not pursued	No		S3‑181569
		S3‑182038	Clause 11.1.2 Add EAP failure processing-based on Living CR S3-181569	CATT, China Mobile	other	Approval	Yes	Yes	merged	No	S3‑182037
		S3‑181751	Clarification on UE ID in clause 11.1.2	NEC Corporation	CR	Approval	Yes	Yes	not pursued	No		S3‑181569
		S3‑182037	Corrections to secondary authentication procedure	Huawei,HiSilicon,Interdigital, CATT,NEC,Nokia	CR	discussion	Yes	Yes	agreed	No		S3‑181569
		S3‑182039	Clarification on UE ID in clause 11.1.2	NEC	other	Agreement	Yes	Yes	merged	No	S3‑182037
7.2.10	Interworking	S3‑181667	Adding further details for EPS to 5G interworking	Huawei, HiSilicon	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑181685	CR Clause 6.3.1.2 Unused AVs from legacy MME	Nokia	other	Approval	Yes	Yes	merged	No	S3‑182040
		S3‑181722	Adding further details for EPS to 5G interworking	Huawei, HiSilicon	other	Agreement	Yes	Yes	revised	No	S3‑182089
		S3‑182089	Adding further details for EPS to 5G interworking	Huawei, HiSilicon	other	Agreement	Yes	Yes	merged	No	S3‑182041	S3‑181722
		S3‑181780	Kamf' derivation in EPS to 5GS HO	Qualcomm Incorporated	other	Agreement	Yes	Yes First change merged in 2042, Second change merged into tdoc 929.	merged	No	S3‑182042
		S3‑181782	clairifications and updates on EPS to 5GS HO in clause 8.4	Qualcomm Incorporated	other	Agreement	Yes	Yes	revised	No	S3‑182041
		S3‑181841	Clarifications to used NAS COUNT’s at mapping of security contexts	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑182042	S3‑181571
		S3‑181842	Corrections and clarifications to Handover from EPS to 5GS over N26	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑182041	S3‑181570
		S3‑181843	Corrections and clarification to handover from 5GS to EPS over N26	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑182043	S3‑181329
		S3‑181846	Corrections and clarifications to idle mode mobility from EPS to 5GS over N26	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑181896	Clarifications to: Security handling in state transitions	Nokia, Ericsson, Huawei, HiSilicon	CR		Yes	Yes	not pursued	No		S3‑181456
		S3‑182040	Clarifications on unused 5G authentication vectors, and remaning authentication data	Nokia,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181349
		S3‑182041	Clarifications to: Handover from EPS to 5GS over N26	Qualcomm	CR	Agreement	Yes	Yes	revised	No	S3‑182093	S3‑181570
		S3‑182093	Clarifications to: Handover from EPS to 5GS over N26	Qualcomm	CR	Agreement	Yes	Yes	agreed	No		S3‑182041
		S3‑182042	Clarifications to Mapping of Security Contexts	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181571
		S3‑182043	KeNB derivation in 5GS to EPS handover	Ericsson	CR	discussion	Yes	Yes	agreed	No		S3‑181329
7.2.11	non-3GPP access	S3‑181686	CR clarifications to Clause 7.2 on UE Id in EAP-5G.	Nokia	other	Approval	Yes	Yes	revised	No	S3‑182044
		S3‑182044	CR clarifications to Clause 7.2 on UE Id in EAP-5G.	Nokia	other	Approval	No	Yes	merged	No	S3‑181982	S3‑181686
		S3‑181833	Certificate-based N3IWF authentication in non-3GPP access	Ericsson	discussion	Endorsement	Yes	Yes	revised	No	S3‑181917
		S3‑181834	Use of certificates for IKEv2 in non-3GPP access	Ericsson	other	Agreement	Yes	Yes	revised	No	S3‑182045	S3‑181574
		S3‑182045	Use of certificates for IKEv2 in non-3GPP access	Ericsson,Qualcomm,Nokia	other	Agreement	Yes	Yes	merged	No	S3‑182982	S3‑181834
		S3‑181917	Commenting contribution on S3-181833 "Certificate-based N3IWF authentication in non-3GPP access"	Motorola Mobility, Lenovo	discussion		Yes	Yes Qualcomm: Implement in 33.501 what was agreed for ePDG in 33.402.	noted	No		S3‑181833
7.2.12	NDS	S3‑181836	Discussion of the content on the protection of IP based interface and the gNB internal interfaces	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑181837	Clarification of the IPsec implementation requirements	Ericsson	CR	Agreement	Yes	Yes MCC commented that it wasn't possible to change the title and content to something completely different. It was suggested to add it as a new sub-clause. Also, that it was better to mention "shall be done as in RFCxx" instead of "shall be implemented as in RFCxx".	revised	No	S3‑182046
		S3‑182046	Clarification of the IPsec implementation requirements	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181837
		S3‑181838	Protection of internal gNB interfaces	Ericsson	CR	Agreement	Yes	Yes ORANGE: bringing security gateways back? They didn’t agree with having this possiblity. Huawei had some issues with this CR since it was giving some implementation proposals that had incomplete scenarios. They commented that requirements from other clauses were repeated here. All different deployment issues needed to be evaluated here. Ericsson pointed out that protection in F1 needed to be finished this meeting.	revised	No	S3‑182047
		S3‑182047	Protection of internal gNB interfaces	Ericsson	CR	Agreement	Yes	Yes ORANGE asked to be minuted: For the Next meeting DTLS over SCTP should be a separated clause. The reference to RFC 6083 needs to be fixed as well.	agreed	No		S3‑181838
		S3‑181839	Introduction of DTLS for protection of Xn-C and N2 itnerfaces	Ericsson	CR	Agreement	Yes	Yes TIM: what's the advantage here of adding this new option when it is said that Ipsec is better? Ericsson: if IPSEC is used. It is optional to use it. ORANGE: we may need to modify TS 33.210.	revised	No	S3‑182048
		S3‑182048	Introduction of DTLS for protection of Xn-C and N2 itnerfaces	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181839
		S3‑181867	Authorization of Application Function’s requests	Samsung, MSI, Huawei	CR	Approval	Yes	Yes	agreed	No
7.2.13	Service based architecture
7.2.13.1	Interconnect (SEPP related)	S3‑181817	Clause structure proposal for the application layer solution	Ericsson	CR	Agreement	Yes	Yes It was commented that this CR should not be implemented if the exception sheet for 33.501 was approved in the plenary. In case that the exception wasn't approved the CR could be brought later as cat-F. 817 was converted into a draftCR in 937. Its contents were agreed and moved there.	not pursued	No
		S3‑181937	Clause structure proposal for the application layer solution	Ericsson,Nokia	draftCR	Agreement	No	Yes	approved	No
		S3‑181732	pCR to Living doc: Protection Policies	KPN N.V.	other	Approval	Yes	Yes Juniper: policy per NF in 4.3.6.4? That would be complex. KPN agreed: One policy per NF service would be better. Huawei didn’t agree with 4.3.6.6.	revised	No	S3‑181941
		S3‑181941	pCR to Living doc: Protection Policies	KPN N.V.	other	Approval	Yes	Yes	approved	No		S3‑181732
		S3‑181734	Protection policies SEPP and NF	KPN N.V.	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181818	Format of message protection policies	Ericsson	other	Approval	Yes	Yes	noted	No
		S3‑181944	Format of message protection policies	Ericsson	other	Approval	No	Yes	withdrawn	Yes
		S3‑181819	Protection policies for N32 interface	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181820	Issuing of protection policies	Ericsson	other	Approval	Yes	Yes	noted	No
		S3‑181946	Issuing of protection policies	Ericsson	other	Approval	No	Yes	withdrawn	Yes
		S3‑181821	Requirements for the format of message protection policies	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181791	Discussion on security policy provisioning for SEPP	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes Ericsson: you may configure directly in the SEPP, not in another node. Nokia, Docomo agreed with Ericsson.	noted	No
		S3‑181793	Security policy provisioning for SEPP to SBA Living Document	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No
		S3‑181796	Security policy provisioning for SEPP	Huawei, Hisilicon	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181922	SBA: Initial handshake between two SEPPs	Nokia	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181643	Clause 13.5 - Authentication for SEPP capability negotiation	ZTE Corporation, China Mobile	CR	Approval	Yes	Yes Ericsson: this will be there in all SEPPs, it won't be optional. Deutsche Telekom: SEPP to SEPP is always in a TLS tunnel. There was a misunderstanding in what was existing, so the CR was finally not pursued.	not pursued	No
		S3‑181644	Clause 13.5 - Failure on SEPP capability negotiation	ZTE Corporation, China Mobile	CR	Approval	Yes	Yes Huawei: no need for additional messages to express the failure, the original response message can be used for that.	not pursued	No
		S3‑181891	SBA: Discussion paper on SEPP to SEPP N32 message structure	Nokia	discussion	Approval	Yes	Yes	noted	No
		S3‑181908	SBA: HTTP Message rewriting	Nokia, NTT DOCOMO	CR	Agreement	Yes	Yes Ericsson doubted about the efficiency of this procedure. They suggested to check with CT4 whether this was efficient. Do we have the competence to decided whether this is efficient enough? Nokia agreed.	not pursued	No
		S3‑181739	Options for integrity protection of the N32 interface	NCSC	discussion	Endorsement	Yes	Yes Ericsson: it seems cumbersome. Better to use authenticated encryption all the time.	noted	No
		S3‑181890	SBA: Message protection using JOSE	Nokia, NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑181948
		S3‑181948	SBA: Message protection using JOSE	Nokia, NCSC	CR	Agreement	Yes	Yes	not pursued	No		S3‑181890
		S3‑181822	Applying JWE and JWS for N32 application layer solution	Ericsson	other	Approval	Yes	Yes	noted	No
		S3‑181949	Applying JWE and JWS for N32 application layer solution	Ericsson	other	Approval	No	Yes	withdrawn	Yes
		S3‑181823	Using JWE and JWS for protecting JSON objects	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181948
		S3‑181824	JWE and JWS profiles	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181811	Annex: Rationale for integrity protection of the N32 interface	NCSC	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181614	Reply LS on the documentation of security requirements for API design	C4-183467	LS in		Yes	Yes	replied to	No
		S3‑181889	SBA: Annex G – End to End Message flow between SEPPs	Nokia	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181716	Discussion on Malicious Messages on N32	Deutsche Telekom AG	discussion	Endorsement	Yes	Yes On proposal 4,Vodafone: it would be useful to log and detect these received messages in order to find out who the sender was. After that the message is discarded. DT wanted to have proposal 4 as a requirement in TS 33.501. Ericsson commented that SA3 needed to be more precise with the anti-spoofing mechanisms. ORANGE supported to have anti-spoofing protection mentioned in the specification. Juniper: why not having it for a future SCAS for SEPP?	revised	No	S3‑181950
		S3‑181950	Discussion on Malicious Messages on N32	Deutsche Telekom AG	discussion	Endorsement	No	Yes	endorsed	No		S3‑181716
		S3‑181798	Discussion on protection against fraudulent PLMN ID attack between different PLMNs	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes DT: Validating the message itself and doing a cross check is different from what Huawei proposes.	noted	No
		S3‑181803	Protection against fraudulent PLMN ID attack between different PLMNs	Huawei, Hisilicon	CR	Agreement	Yes	Yes DT: it needs more details. Ericsson: in the app layer solution we are introducing what Huawei wants.Nokia agreed. Companies were fine with the requirement introduced in this CR.	revised	No	S3‑181955
		S3‑181955	Addition of SBA security requirements for SEPP and NF	Deutsche Telekom,Huawei	CR	Agreement	No	Yes Only the requirement stays. Requirements from 950 are incorporated here.	agreed	No		S3‑181803
		S3‑181806	Analysis and pCR for malicious message over N32	China Mobile Com. Corporation	other	Approval	Yes	Yes KPN: the solution needs more work, it's a bit thin. Juniper commented that the document needed some language check. KPN: this is describing authenticated and integrity messages that need a standard to describe how they are dropped. I don’t agree with this. Nokia didn’t support this either.	noted	No
		S3‑181885	SBA: HTTP Message rewriting	Nokia, NTT DOCOMO	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑181945	Living document: SBA for 5G phase one	China Mobile	other	Approval	Yes	Yes	approved	No
		S3‑181947	Rationale for integrity protection of the N32 interface	NCSC	other	Approval	Yes	Yes	approved	No
		S3‑182091	LS on status of security solution for interoperator interconnect (SEPP to SEPP communication)	Docomo	LS out	Approval	Yes	Yes	approved	No
7.2.13.2	Other	S3‑181717	LS on Security Requirements for API Design	Deutsche Telekom AG	LS out	Agreement	Yes	Yes	revised	No	S3‑181936
		S3‑181936	LS on Security Requirements for API Design	Deutsche Telekom AG	LS out	Agreement	Yes	Yes	approved	No		S3‑181717
		S3‑181826	TLS and routing: solution selection and LS discussion	Ericsson	other	Approval	Yes	Yes	approved	No
		S3‑181923	Comments to S3-181826	Nokia	discussion	Discussion	Yes	Yes	withdrawn	Yes
		S3‑181827	draft LS on TLS and inter-PLMN routing	Ericsson	LS out	Approval	Yes	Yes ORANGE: do we need a reply from CT4 only or also from SA2? Ericsson clarifed that CT4's response was enough.	revised	No	S3‑181956
		S3‑181956	LS on TLS and inter-PLMN routing	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑181827
		S3‑181921	TLS and Routing Solutions Update	Ericsson	other	Approval	Yes	Yes After Nokia's query, Ericsson clarified that Authentication and authorization in step 2 wasn't needed for this context. Revised to introduce this change.	revised	No	S3‑181957
		S3‑181957	TLS and Routing Solutions Update	Ericsson	other	Approval	Yes	Yes	approved	No		S3‑181921
		S3‑181918	New solution for Security of Service Based Architecture	Telecom Italia S.p.A., InterDigital	other	Approval	Yes	Yes KPN didn’t support this. Docomo: which entity would generate the keys? We would need a key generation entity that everybody would have to trust, and then who's reponsible for the policy? Docomo: no time to work this out and incorporate this solution into the TS. Lot of details are missing.	revised	No	S3‑181958	S3‑181865
		S3‑181958	New solution for Security of Service Based Architecture	Telecom Italia S.p.A., InterDigital	other	Approval	Yes	Yes	approved	No		S3‑181918
		S3‑181792	Corrections to section 13.4.1.1	China Mobile Com. Corporation	CR	Approval	Yes	Yes There were several issues with the CR cover page that needed to be taken care of. The CR didn’t display the whole clause where the change was happening either.	revised	No	S3‑181959
		S3‑181959	Corrections to section 13.4.1.1	China Mobile Com. Corporation	CR	Approval	No	Yes	agreed	No		S3‑181792
		S3‑181666	SBA_NF service access authorization discussion	Huawei, HiSilicon	discussion	Endorsement	Yes	Yes Ericsson pointed out that CT4 was working with this issue and that a reponse to the LS would be needed.	noted	No
		S3‑181825	Authentication and authorization clarifications	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181960	S3‑181486
		S3‑181721	Clarifications on service authorization	Huawei, HiSilicon	other	Agreement	Yes	Yes	revised	No	S3‑182034
		S3‑182034	Clarifications on service authorization	Huawei, HiSilicon	other	Agreement	Yes	Yes	merged	No	S3‑181962	S3‑181721
		S3‑181639	Correction for TS 33.501 subclause 4.1	InterDigital, Inc.	CR	Approval	Yes	Yes	revised	No	S3‑181961
		S3‑181961	Correction for TS 33.501 subclause 4.1	InterDigital, Inc.	CR	Approval	Yes	Yes	revised	No	S3‑182050	S3‑181639
		S3‑181807	Discussion of error handling in service layer procedures	China Mobile Com. Corporation	discussion	Discussion	Yes	Yes Juniper and ORANGE didn’t agree with the second issue:it would bring DoS attacks. Docomo: an authorization failure wouldn't be a bad thing. Nokia: if there's an error during service discovery, then it is out of our scope but in CT4's scope. This was eventually noted.	noted	No
		S3‑181810	pCR for error handling in service layer procedures	China Mobile Com. Corporation	other	Approval	Yes	Yes	noted	No
		S3‑181642	Clause 13.3 - Remove of transport layer protection procedure	ZTE Corporation, China Mobile	CR	Approval	Yes	Yes	merged	No	S3‑181960
		S3‑181646	Clause 13.4.1 - No registration for NF service consumer	ZTE Corporation, China Mobile	other	Approval	Yes	Yes	merged	No	S3‑181962
		S3‑181714	TR Skeleton for FS_SBA-Sec	Deutsche Telekom AG	other	Approval	Yes	Yes	revised	No	S3‑181964
		S3‑181964	TR FS_SBA-Sec	Deutsche Telekom AG	other	Approval	No	Yes	revised	No	S3‑182090	S3‑181714
		S3‑182090	TR FS_SBA-Sec	Deutsche Telekom AG	other	Approval	No	Yes	approved	No		S3‑181964
		S3‑181715	Incorporating Living Doc Contents into FS_SBA-Sec TR	Deutsche Telekom AG	other	Approval	Yes	Yes	noted	No
		S3‑181916	Commets on S3-181715	KPN N.V.	other	Approval	Yes	Yes	noted	No
		S3‑181812	Living Document-Security of Service Based Architecture of 5G phase 1	China Mobile Com. Corporation	other	Approval	Yes	Yes	noted	No
		S3‑181665	Clarifications on service authorization	Huawei, HiSilicon	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑181794	New solution for Security of Service Based Architecture	TIM, InterDigital	other	Approval	Yes	Yes	withdrawn	Yes
		S3‑181865	New solution for Security of Service Based Architecture	TIM, InterDigital	other	Approval	Yes	Yes	revised	No	S3‑181918
		S3‑181960	Clarifications to: Protection at the network or transport layer, Authorization and authentication between network functions and the NRF	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182035	S3-181486
		S3‑182035	Clarifications to: Protection at the network or transport layer, Authorization and authentication between network functions and the NRF	Ericsson	CR	Agreement	No	Yes	agreed	No		S3‑181960
		S3‑181962	The granularity of NF service discovery	China Mobile	CR	Agreement	Yes	Yes	agreed	No		S3‑181487
		S3‑181966	Cover sheet TR SBA	Deutsche Telekom	other	Approval	Yes	Yes	approved	No
		S3‑182000	Resolving Editor’s Note on Requirements for OpenAPI specifications	Deutsche Telekom	other	discussion	Yes	Yes	approved	No
		S3‑182012	LS OUT on OAuth2.0	C4-184465	LS in	discussion	Yes	Yes	replied to	No
		S3‑182033	Reply to: LS OUT on OAuth2.0	Huawei	LS out	approval	Yes	Yes	approved	No
7.2.14	Privacy	S3‑181731	Clause 6.12.2-Routing registration request using SUCI-based on Living CR S3-181496	CATT	CR	Agreement	Yes	Yes	revised	No	S3‑182053	S3‑181496
		S3‑182053	Clause 6.12.2-Routing registration request using SUCI-based on Living CR S3-181496	CATT	CR	Agreement	Yes	Yes The content of this CR will be brought in a future meeting waiting for SA2's results.	not pursued	No		S3‑181731
		S3‑181750	Editorial correction to clause 6.12.5 on SIDF	NEC Corporation	CR	Agreement	Yes	Yes Vodafone objected to having "shall" in here. This is a box that deconceals the SUPI. If using mobile encryption, the rest of the sentence is correct. This was finally reworded in the revision.	revised	No	S3‑181932
		S3‑181932	Editorial correction to clause 6.12.5 on SIDF	NEC Corporation,Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑181750
		S3‑181711	ME-USIM negotiation for SUCI calculation in ME	Apple, Deutsche Telekom, Sony, KPN, China Mobile, Qualcomm Incorporated, BT Group,Intel	CR	Agreement	Yes	Yes IDEMIA didn’t agree with the reason for the change. It could be done with an applet. Vodafone: CT6 created a new PDU function over the top incorrectly, by misunderstanding SA3 text in this spec. We need a file where we can use existing SIMs.	revised	No	S3‑181967	S3‑181496
		S3‑181967	ME-USIM negotiation for SUCI calculation in ME	Apple, Deutsche Telekom, Sony, KPN, China Mobile, Qualcomm Incorporated, BT Group,Intel	other	Agreement	Yes	Yes	merged	No	S3‑181970	S3‑181711
		S3‑181828	discussion paper: Protection scheme selection using legacy USIM	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑181829	CR to 5.2.5: Protection scheme selection using legacy USIM	Ericsson	other	Agreement	Yes	Yes Second requirement and Note stay.	noted	No		S3‑181462
		S3‑181830	CR to 6.12.2: Protection scheme selection using legacy USIM	Ericsson	other	Agreement	Yes	Yes	noted	No		S3‑181496
		S3‑181919	Nokia comments on S3-181830 Protection scheme selection	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181724	Mac key length in Annex C	Huawei, HiSilicon	other	Agreement	Yes	Yes	noted	No
		S3‑181763	CR to include MAC in SUCI	NEC Corporation	other	Approval	Yes	Yes Huawei: MAC verified only by the HPLMN. If the routing info is changed this will be erroneous. Qualcomm: this doesn’t bring any benefit.	noted	No
		S3‑181709	IV generation for ECIES	Apple,Ericsson	other	Agreement	Yes	Yes NCSC: the rational doesn’t give a reason for this change.	merged	No	S3‑181968
		S3‑181968	IV generation for ECIES	Apple,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181495
		S3‑181831	Clarification on counter for ECIES	Ericsson	other	Agreement	Yes	Yes	revised	No	S3‑181969	S3‑181495
		S3‑181969	Clarification on counter for ECIES	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181968	S3‑181831
		S3‑181832	SUCI – length corrections to Profile and	Ericsson	other	Agreement	Yes	Yes	merged	No	S3‑181968	S3‑181495
		S3‑181795	Remove the editors note in section 6.12.1	China Mobile Com. Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181970
		S3‑181876	Prevention of PEI modification	Motorola Mobility, Lenovo, OPPO, vivo, Qualcomm	draftCR	Approval	Yes	Yes ORANGE didn’t agree with the requirement.This was reworded to " the PEI shall be securely stored in the UE". Qualcomm proposed "integrity protected" and this was included.	revised	No	S3‑181971	S3‑181462
		S3‑181971	Prevention of PEI modification	Motorola Mobility, Lenovo, OPPO, vivo, Qualcomm	draftCR	Approval	No	Yes	merged	No	S3‑182036	S3‑181876
		S3‑181704	IV generation for ECIES	Apple Inc, Ericsson	CR	Agreement	No	Yes	withdrawn	Yes		S3‑181495
		S3‑181970	Clarification to Subscription identifier privacy	China Mobile	CR	Agreement	Yes	Yes	agreed	No		S3‑181496
		S3‑182036	Clarifications to requirements	Lenovo,Nokia, Gemalto,CATT,Lenovo,Motorola Mobility,Ericsson,ZTE	CR	Agreement	Yes	Yes	agreed	No		S3‑181462
		S3‑182055	LS on clarifications to subscription privacy	Vodafone	LS out	Approval	Yes	Yes	approved	No
7.2.15	Incoming and outgoing LSes	S3‑181650	UE capability related to integrity protection of DRBs	R2-1804056	LS in		Yes	Yes	noted	No
		S3‑181618	LS on UE capability related to integrity protection of DRBs	S2-184513	LS in		Yes	Yes Qualcomm: The security parameter should be integrity protected and preferably confidentiality protected. If the signalling is in the NAS is not clear that the first is achieved. Nokia: The limitation is at AS level, not at NAS level. Qualcomm replied that the parameters should be sent to the RAN in an integrity protected way. Vodafone: this is the best way for a good bidding down protection.	replied to	No
		S3‑181930	Reply to: LS on UE capability related to integrity protection of DRBs	Qualcomm	LS out	approval	Yes	Yes	approved	No
		S3‑181621	LS response on LS on Support User Plane Encryption in UP security policy	S2-184225	LS in		Yes	Yes	noted	No
		S3‑181620	Reply LS on User Plane Security Policy	R3-182437	LS in		Yes	Yes	noted	No
		S3‑181622	LS response on LS on UP Security Policy	S2-184226	LS in		Yes	Yes	noted	No
		S3‑181619	LS on reporting Integrity check failure for DRB to network	R2-1806490	LS in		Yes	Yes Related to tdoc 861.	replied to	No
		S3‑181624	Response LS on authentication related services provided by AUSF and UDM	S2-184229	LS in		Yes	Yes	noted	No
		S3‑181625	Reply LS one step MO SMS procedure	S2-184442	LS in		Yes	Yes	noted	No
		S3‑181626	Reply LS on secured Signalling-only connection	S2-184507	LS in		Yes	Yes	noted	No
		S3‑181627	LS response on Initial NAS message protection	S2-184510	LS in		Yes	Yes 690, 767,769,727,691 and 768 are related to this LS.	replied to	No
		S3‑181628	Reply LS on paging with IMSI/SUCI in 5GS	S2-184512	LS in		Yes	Yes	noted	No
		S3‑181631	5G for Industrial Communication	5G-ACIA	LS in		Yes	Yes	noted	No
		S3‑181906	Reply LS on security for inactive state	R2-1806457	LS in		Yes	Yes Related docs are 706, 784,859,693,694. Ericsson: this is a RAN2 agreement and there is no security concern to be solved in SA3. We cannot revert RAN2 decisions. Samsung: the same key should not be used, that's the concern. Ericsson: it is not clear what the requirement is. The source node knows all the keys, what is that we are trying to hide to the source node? Qualcomm: the UE receives the NCC, it derives the new key and then it can forget the previous key. This discussion was taken offline.	replied to	No
		S3‑182082	LS on OAuth2.0	C4-184465	LS in	discussion	Yes	Yes	withdrawn	Yes
		S3‑182083	Reply LS on AUSF/UDM instance selection and SUCI parameters	C4-184576	LS in	discussion	Yes	Yes	postponed	No
		S3‑182084	LS on TLS and inter PLMN routing	C4-184612	LS in	discussion	Yes	Yes	replied to	No
		S3‑182088	Reply to: LS on TLS and inter PLMN routing	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑182086	Reply LS on initial NAS message protection	C1-183727	LS in	discussion	Yes	Yes Qualcomm: they have two meetings before we meet again, so we should send a response this meeting.	replied to	No
		S3‑182087	Reply to: Reply LS on initial NAS message protection	Qualcomm	LS out	approval	Yes	Yes	approved	No
7.2.16	Others	S3‑181607	33.501 after implementation of approved CRs of SA3#91	NTT DOCOMO INC.	other	Information	Yes	Yes	noted	No
		S3‑181909	Correction for TS 33.501 clauses 3.1, 5.3.10, 5.11.2, and 6.9.2.3.4	InterDigital, Inc.	CR	Approval	Yes	Yes	not pursued	No
		S3‑181797	Eidtorials Corrections to 33.501	China Mobile Com. Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑181895	Collection of editorial changes	Nokia	CR		Yes	Yes	not pursued	No		S3‑181438
		S3‑181748	Clarifications to definitions and abbreviations	NEC Corporation	CR	Approval	Yes	Yes	revised	No	S3‑182049	S3‑181475
		S3‑182049	Clarifications to definitions and abbreviations	NEC Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑181748
		S3‑181723	Clarifications to Definitions and Abbreviations	Huawei, HiSilicon	other	Agreement	Yes	Yes	merged	No	S3‑182049
		S3‑181789	Corrections to section 4.1 Security domains	China Mobile Com. Corporation	CR	Approval	Yes	Yes	agreed	No
		S3‑181893	Generic security domain description clarification	Nokia	CR		Yes	Yes It clashes with 961.	merged	No	S3‑182050
		S3‑182050	Correction for TS 33.501 subclause 4.1	Nokia,Interdigital	CR	-	Yes	Yes	agreed	No		S3‑181961
		S3‑181892	Generic description of security elements	Nokia	CR		Yes	Yes ORANGE: we never saw that the AUSF could be outside the operator's network. Qualcomm: we have this in the TS already, it's not new.	not pursued	No
		S3‑181894	Integrating SEAF requirements under AMF	Nokia	CR		Yes	Yes Qualcomm: we don’t need this. It was clarified that these requirements were being moved. Qualcomm commented that there was a clause dedicated to SEAF requirements already and they should have gone there.	not pursued	No
		S3‑181641	Correction for TS 33.501 subclause 5.11.2	InterDigital, Inc.	CR	Approval	Yes	Yes	revised	No	S3‑182051
		S3‑182051	Correction for TS 33.501 subclause 5.11.2	InterDigital, Inc.	CR	Approval	Yes	Yes	agreed	No		S3‑181641
		S3‑181870	Clarification to Emergency Session handling	Motorola Mobility, Lenovo	draftCR	Approval	Yes	Yes Qualcomm: it doesn't bring any value.	noted	No		S3‑181568
		S3‑181882	Clarifications to Annex A : Key derivation functions – FC values (rev of CR0155)	LG Electronics	CR	Agreement	Yes	Yes	revised	No	S3‑181929	S3‑181454
		S3‑181929	Clarifications to Annex A : Key derivation functions – FC values (rev of CR0155)	LG Electronics	CR	Agreement	Yes	Yes	agreed	No		S3‑181882
		S3‑181883	5G FC values in 33.220	LG Electronics	CR	Agreement	Yes	Yes	merged	No	S3‑181928
		S3‑181881	Clarifications to Annex D.3 Integrity algorithms	LG Electronics	CR	Agreement	Yes	Yes	agreed	No
		S3‑181663	Security options for 33.501	Huawei, HiSilicon	CR	Agreement	Yes	Yes ORANGE commented that this didn’t add anything to the specification. No one seemed to see the use for this.	not pursued	No
		S3‑181710	Security procedures for dual connectivity	Huawei,Ericsson, Qualcomm	draftCR	Approval	Yes	Yes	revised	No	S3‑181984	S3‑181517
		S3‑181984	Security procedures for dual connectivity	Huawei,Ericsson, Qualcomm	draftCR	Approval	Yes	Yes	approved	No		S3‑181710
		S3‑181845	Discussion on the need for exception sheet on TS 33.501	Ericsson	discussion	Discussion	Yes	Yes The Chair asked the room if companies thought that there was a need for an exception sheet: ORANGE, KPN, Vodafone supported this. Qualcomm: RAN groups will not complete dual connectivity until September so we may have to continue working on it. The general feeling was that an exception sheet was needed in order to complete SBA. The Chair asked to be very precise with the reasons for having this exception agreed in the plenary. Everything else should be frozen and topics that need to be completed needed to be precised. Nokia commented that SA3 didn’t know if dual connectivity work was needed so it was better not to mention it. BT clarified that the late drop referred to ASN.1 and not to very late 5G features, so SA3 should not use this for the exception. It was agreed to have an exception sheet only for the SBA topic.Ericsson pointed out that not all SBA was open so it should be detailed what issues in SBA security were needed. The Chair asked if there was any understanding of issues in RAN that may impact SA3. Ericsson commented that dual connectivity was work in progress and that they could bring cat-F CRs to address this in SA3. The Chair commented that he would mention this issue in his report and that the SA Chair would mention it as well in TSG RAN.	noted	No
		S3‑181633	Correction for TS 33.501 subclause 5.11.2	InterDigital, Inc.	CR	Approval	Yes	Yes	withdrawn	Yes
		S3‑181634	Correction for TS 33.501 subclause 6.9.2.3.4	InterDigital, Inc.	CR	Approval	Yes	Yes	withdrawn	Yes
		S3‑181638	Correction for TS 33.501 Section 3.1	InterDigital, Inc.	CR	Approval	Yes	Yes	withdrawn	Yes
		S3‑181640	Correction for TS 33.501 subclause 5.3.10	InterDigital, Inc.	CR	Approval	Yes	Yes	withdrawn	Yes
		S3‑181668	Clarifications to Definitions and Abbreviations	Huawei, HiSilicon	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑182080	Exception sheet 5G security phase one	NTT-Docomo	WI exception request	Agreement	No	Yes	agreed	No
7.3	Mission Critical Security Enhancements (eMCSec) (Rel-15)	S3‑181608	Reply LS on protected payload message types	C1-182577	LS in		Yes	Yes	noted	No
		S3‑181904	[eMCSEC] Inclusion of MCData message types as defined by CT1	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181913	[eMCSEC] Making Annex J normative	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181915	[eMCSEC] Reply LS on protected payload message types and Elements for Authenticating Requests (EARs)	NCSC	LS out	Approval	Yes	Yes	revised	No	S3‑181951
		S3‑181951	[eMCSEC] LS on Elements for Authenticating Requests (EARs)	NCSC	LS out	Approval	Yes	Yes	approved	No		S3‑181915
		S3‑181629	Reply LS to SA3 on Security Gateway notification to group members	S6-180726	LS in		Yes	Yes	noted	No
		S3‑181905	[MCSEC] LS on removal of Temporary Group Regroup procedures	NCSC	LS out	Approval	Yes	Yes	revised	No	S3‑181952
		S3‑181952	[MCSEC] LS on removal of Temporary Group Regroup procedures	NCSC	LS out	Approval	Yes	Yes	approved	No		S3‑181905
		S3‑181902	[eMCSEC] Addition of note to say that temporary group regroup mechanism is not secured.	NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑181953
		S3‑181953	[MCSEC] Addition of note to say that temporary group regroup mechanism is not secured.	NCSC	CR	Agreement	Yes	Yes	agreed	No		S3‑181902
		S3‑181606	[eMCSec] 33180 R15 technical clarification for a proxy usage	Airbus DS SLC	CR	Agreement	Yes	Yes	revised	No	S3‑181940
		S3‑181940	[eMCSec] 33180 R15 technical clarification for a proxy usage	Airbus DS SLC	CR	Agreement	No	Yes	agreed	No		S3‑181606
		S3‑181658	[eMCSec] 33180 R15 Migration KMS clarification	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑182030
		S3‑182030	[eMCSec] 33180 R15 Migration KMS clarification	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No		S3‑181658
		S3‑181914	[eMCSEC] Definition of KMS Redirect Request message format	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181900	[eMCSEC] Definition of KMS XML Schema namespace	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181924	LS on Removal of LTE specific terminology from Group Communication System Enablers TS 22.468	S1-181249	LS in	discussion	Yes	Yes NCSC commented that there is no reference in the current TS but there is in the TR. This will be fixed in the next meeting and an action item was recorded for this. ORANGE asked about the meaning of removing "over LTE". If this means that whatever works in 4G works in 5G this would not work since some security features don’t work in 5G. This might imply that a TR for 5G would be needed since the architecture in 5G is different. ORANGE understood that what SA3 had done till now was for 4G. Ericsson commented that this was not the purpose of the LS, but just changing the reference. NCSC: they have only changed the name of the document, not the content. The functionality has not changed. There was confusion in the room on the impact of this LS on SA3, including topics outside Mission Critical. Ericsson commented that the LS should be noted. This is just about removing references and consider this for the future. Qualcomm agreed. Motorola commented that there was a WID on Mission Critical in 5G. The Chair found that the general opinion was to send an LS in search of clarification.	replied to	No
		S3‑182031	Reply to: LS on Removal of LTE specific terminology from Group Communication System Enablers TS 22.468	NCSC	LS out	approval	Yes	Yes	approved	No
7.4	Security Architecture for the Mobile Communication System for Railways (MONASTERY_SEC) (Rel-15)
7.5	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.6	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)	S3‑181613	LS on Security for NEF Northbound APIs	C3-182459	LS in		Yes	Yes	replied to	No
		S3‑181635	Draft Reply LS to LS on Security for NEF Northbound APIs	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑182013
		S3‑182013	Reply LS to LS on Security for NEF Northbound APIs	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑182014	S3‑181635
		S3‑182014	Reply LS to LS on Security for NEF Northbound APIs	Huawei, Hisilicon	LS out	Approval	Yes	Yes	approved	No		S3‑182013
		S3‑181696	Security requirements for API invoker onboarding	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑182001
		S3‑182001	Security requirements for API invoker onboarding	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181696
		S3‑181911	[CAPIF_SEC] 33.122 Update to API onboarding	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑181977	S3‑181656
		S3‑181977	[CAPIF_SEC] 33.122 Update to API onboarding	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑182016	S3‑181911
		S3‑182016	[CAPIF_SEC] 33.122 Update to API onboarding	Motorola Solutions Germany	pCR	Approval	Yes	Yes	approved	No		S3‑181977
		S3‑181737	pCR on Onboarding procedure	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181972
		S3‑181972	pCR on Onboarding procedure	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑181737
		S3‑181872	CAPIF – API invoker onboarding EN resolution	Samsung, MSI	pCR	Approval	Yes	Yes	revised	No	S3‑181989
		S3‑181989	CAPIF – API invoker onboarding EN resolution	Samsung, MSI	pCR	Approval	Yes	Yes	revised	No	S3‑182017	S3‑181872
		S3‑182017	CAPIF – API invoker onboarding EN resolution	Samsung, MSI	pCR	Approval	Yes	Yes	approved	No		S3‑181989
		S3‑181740	pCR on integrating subclause 6.1 into 6.3	NEC Corporation	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑181738	pCR on introducing offboarding procedure	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181973
		S3‑181973	pCR on introducing offboarding procedure	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑182018	S3‑181738
		S3‑182018	pCR on introducing offboarding procedure	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑181973
		S3‑181698	Relocation of topology hiding	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑182002
		S3‑182002	Relocation of topology hiding	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑182020	S3‑181698
		S3‑182020	Relocation of topology hiding	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑182002
		S3‑181697	Authorization aspects for discovering	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑181700	Security procedures for updating security method	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑182003
		S3‑182003	Security procedures for updating security method	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181700
		S3‑181654	[CAPIF_SEC] 33.122 EN in clause 6.3.1	Motorola Solutions Germany	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑181741	pCR on CAPIF-1e security procedure	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181974
		S3‑181974	pCR on CAPIF-1e security procedure	NEC Corporation,Samsung, Motorola,Huawei	pCR	Approval	Yes	Yes	revised	No	S3‑182021	S3‑181741
		S3‑182021	pCR on CAPIF-1e security procedure	NEC Corporation,Samsung, Motorola,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑181974
		S3‑181871	Clarification on CAPIF–2e Security	Samsung, Huawei	pCR	Approval	Yes	Yes	merged	No	S3‑181974
		S3‑181912	[CAPIF_SEC] 33.122 Update to Method 3	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑181978	S3‑181657
		S3‑181978	[CAPIF_SEC] 33.122 Update to Method 3	Motorola Solutions Germany,Samsung,NEC	pCR	Approval	Yes	Yes	revised	No	S3‑182022	S3‑181912
		S3‑182022	[CAPIF_SEC] 33.122 Update to Method 3	Motorola Solutions Germany,Samsung,NEC	pCR	Approval	Yes	Yes	approved	No		S3‑181978
		S3‑181875	CAPIF – Method 3 clarifications	Samsung R&D Institute India	pCR	Approval	Yes	Yes	merged	No	S3‑181978
		S3‑181743	pCR on clarifcation of access token generation in CAPIF-2e method 3	NEC Corporation	pCR	Approval	Yes	Yes	merged	No	S3‑181978
		S3‑181976	pCR on clarifcation of access token generation in CAPIF-2e method 3	NEC Corporation	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑181742	pCR on clarification of authroization information in CAPIF-2, 2e procedures	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181975
		S3‑181975	pCR on clarification of authroization information in CAPIF-2, 2e procedures	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑181742
		S3‑181874	CAPIF – Method 2 clarification	Samsung, MSI	pCR	Approval	Yes	Yes BT: Inter operator communication is not independent of the third party. Alf (Docomo) commented that it was worth considering extending the scope of TS 33.310. This was noted as a possible action point in future meetings.	approved	No
		S3‑181651	[CAPIF_SEC] 33.122 Restructure of clause 5	Motorola Solutions Germany	pCR	Approval	Yes	Yes	noted	No
		S3‑181652	[CAPIF_SEC] 33.122 Onboarding flow	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑181942
		S3‑181942	[CAPIF_SEC] 33.122 Onboarding flow	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑182023	S3‑181652
		S3‑182023	[CAPIF_SEC] 33.122 Onboarding flow	Motorola Solutions Germany	pCR	Approval	Yes	Yes	approved	No		S3‑181942
		S3‑181653	[CAPIF_SEC] 33.122 Authentication and Authorization flow	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑181943
		S3‑181943	[CAPIF_SEC] 33.122 Authentication and Authorization flow	Motorola Solutions Germany	pCR	Approval	Yes	Yes Huawei: not comfortable to describe the same thing in two places. Motorola: this is all informative. The is written in a generic way so the procedure will not impact the flow. It was agreed to move both 942 and 943 into an informative annex.	revised	No	S3‑182024	S3‑181653
		S3‑182024	[CAPIF_SEC] 33.122 Authentication and Authorization flow	Motorola Solutions Germany	pCR	Approval	Yes	Yes	approved	No		S3‑181943
		S3‑181747	pCR on editorial correction	NEC Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑181699	Editorial corrections and deleting Editor's Note to TS 33.122 v0.2.0	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑182025
		S3‑182025	Editorial corrections and deleting Editor's Note to TS 33.122 v0.2.0	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181699
		S3‑181655	[CAPIF_SEC] 33.122 Remove ENs	Motorola Solutions Germany	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑181746	pCR on introduction clause	NEC Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑181877	CAPIF support for NEF external exposure interface	Samsung, MSI, Huawei	CR		Yes	Yes It was commented that the categroy should be B.	agreed	No
		S3‑181878	CAPIF support for T8 interface	Samsung, MSI, Huawei	CR	Approval	Yes	Yes	agreed	No
		S3‑181744	Alignment of CAPIF specs	NEC Corporation	discussion	Endorsement	Yes	Yes	endorsed	No
		S3‑181745	[DRAFT] LS on CAPIF specification work in SA3	NEC Corporation	LS out	Approval	Yes	Yes	revised	No	S3‑182019
		S3‑182019	LS on CAPIF specification work in SA3	Samsung	LS out	Approval	Yes	Yes	revised	No	S3‑182027	S3‑181745
		S3‑182027	LS on CAPIF specification work in SA3	Samsung	LS out	Approval	Yes	Yes	approved	No		S3‑182019
		S3‑181630	Reply LS on CAPIF4xMB	S6-180727	LS in		Yes	Yes Postponed since this affected Rel-16.	postponed	No
		S3‑181656	[CAPIF_SEC] 33.122 Update to API onboarding	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑181911
		S3‑181657	[CAPIF_SEC] 33.122 Update to Method 3	Motorola Solutions Germany	pCR	Approval	Yes	Yes	revised	No	S3‑181912
		S3‑182015	Draft TS 33.122	Samsung	draft TS	Approval	Yes	Yes	approved	No
		S3‑182028	Cover sheet TS 33.122	Samsung	draft TS	Approval	Yes	Yes	approved	No
7.7	PLMN RAT selection (Steering of Roaming)	S3‑181610	LS on modification of solution for PLMN and RAT selection policies for roaming based on SA2 comments	C1-182779	LS in		Yes	Yes	noted	No
		S3‑181611	Reply LS on SoR mechanism	C1-182829	LS in		Yes	Yes	noted	No
		S3‑181612	Reply LS on SoR mechanism	C1-182830	LS in		Yes	Yes	replied to	No
		S3‑182009	Reply to: Reply LS on SoR mechanism	Samsung	LS out	approval	No	Yes	withdrawn	Yes
		S3‑181702	Discussion on SoR using ETSI Secure Packet	Intel Deutschland GmbH	discussion		Yes	Yes Vodafone: this is not new, it's what we can do now. T-Mobile: CT1 has developed a solution for SoR and we need to develop the security for that sollution. This is part of that solution. ORANGE: CT1 has proposals to change the solution during their current meeting. SA3-LI still has to reply to their LS so it's still an open solution. ORANGE: we can work on the solution in the living document, but nothing for the TS until they have somethinf stable. Intel agreed to go for the living document. Qualcomm: this is an existing solution, but CT1 is doing a control plane procedure that is missing from here.	noted	No
		S3‑181703	SoR Living Doc: Secure Packet Solution for Steering of Roaming	Intel Deutschland GmbH	other		Yes	Yes ORANGE: remove the conclusion. Intel agreed to do this. ORANGE: you propose another secure channel between UICC and UDM, so you need to maintain two secure channels. Vodafone: this causes huge amounts of loading in UDM. Qualcomm had multiple issues with the document. The solution was not complete for them. Gemalto: it's a candidate solution that should be part of the document. Vodafone: we agreed with CT1 not to use the auth mechanism and not to interact with the authenticate commands.	noted	No
		S3‑181855	Steering of Roaming: new Key Issue	KPN N.V.	other	Approval	Yes	Yes Vodafone: HPLMN choosing between the networks that the UE can see is not a standardization issue. Qualcomm: this is not a security issue. T-Mobile agreed.	noted	No
		S3‑181856	Steering of Roaming: New Solution	KPN N.V.	other	Approval	Yes	Yes	noted	No
		S3‑181869	Security Mechanism for Steering of Roaming	Samsung, Qualcomm Incorporated, Ericsson, T-Mobile US	CR	Approval	Yes	Yes Nokia, Interdigital,Huawei,Deutsche Telekom,NEC supported this contribution. Vodafone,IDEMIA and ORANGE didn't support this for the TS, only for the living document. Vodafone queried the purpose of the living document. Qualcomm replied that the living document would analize all the issues and help to develop a solution. Since CT1 has progressed, there is no point in working on the living document. The Chair proposed to escalate this CR to SA plenary. Vodafone: in CT1 there are substantial CRs about this issue. ORANGE: there are CRs in CT1 by the same companies proposing this CR here. Qualcomm replied that such CRs were not changing the CT1 solution at all. ORANGE: we can't rely on what they are doing this week in their meeting. Qualcomm replied that the baseline was the LS that was sent to SA3. Samsung commented that there was an alignment with the stage 2 work of CT1. Alf (Docomo) queried the objecting companies about the implications of objecting to this solution. No security for their solution? Alf added that this was the wrong place to evaluate CT1's design and object to it. BT commented that this CR should be cat-B as it was adding a new security feature.	revised	No	S3‑182010
		S3‑182010	Security Mechanism for Steering of Roaming	Samsung, Qualcomm Incorporated, Ericsson, T-Mobile US	CR	Approval	Yes	Yes The Chair proposed to have this CR agreed having minuted the objections from the companies. Vodafone,IDEMIA and ORANGE objected to this CR. After offline discussions with the MCC manager it was commented that a working agreement could be announced. The Chair declared that he would do this and hence this was noted in the minutes and sent to be published in the 3GPP website (http://www.3gpp.org/specifications-groups/working-agreements).	agreed	No		S3‑181869
		S3‑181857	Update to the SoR living doc: finalizing the high level requirements and key issues	Ericsson	other	Agreement	Yes	Yes Vodafone commented that a CR for SoR had gone through so there was no point inhaving this document and the next two. This was finally approved to be included in the Living Document.	approved	No
		S3‑181858	Update to the SOR living doc: conclusions	Ericsson	other	Agreement	Yes	Yes	approved	No
		S3‑181907	Living Document: Security of PLMN/RAT selection policies for roaming	Samsung	other		Yes	Yes	revised	No	S3‑182011
		S3‑182011	Living Document: Security of PLMN/RAT selection policies for roaming	Samsung	other	-	Yes	Yes Vodafone asked what the proper way of closing a living document was. He queried whether there was more work anticipated or not once that the CR was agreed here and approved in the plenary. Qualcomm: let's wait for the other groups, in case they ask of something else. The Chair commented that the living document could stay since companies were free of bringing documents whenever they wanted to.	approved	No		S3‑181907
7.8	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)(Rel-15)
7.9	Security Assurance Specification for 5G (SCAS_5G) (Rel-16)
7.9.1	NR Node B (gNB) (TS 33.511)
7.9.2	Access and Mobility Management Function (TS 33.512)
7.9.3	User Plane Function (UPF) (TS 33.513)
7.9.4	Unified Data Management (UDM) (TS 33.514)
7.9.5	Session Management Function (SMF) (TS 33.515)
7.10	Other work areas
7.10.1	SAE/LTE Security	S3‑181648	Discussion on the Impact of enabling user plane integrity protection	Vodafone España SA	discussion	Information	Yes	Yes DT, Docomo supported this document. China Mobile commented that they had done a similar exercise and agreed with the proposal. They commented that VoLTE traffic will grow more and more and it should be considered. Ericsson commented that the scope could be enlarged: privacy enhancement for example. Vodafone proposed to have a SID brought directly in to the plenary to speed up the work.They didn't think that such a study would not be agreable at this meeting. Qualcomm, TIM, ORANGE: let's discuss the scope of this Work Item in SA3. They had concerns of having this SID being sent directly to SA Plenary. The Chair commented that sending the SID directly to the plenary would bring the wrong message. TIM wasn't in favour of sending the SID to SA directly either. Vodafone commented that they would push for an LS to SA3 in SA plenary instead but they thought that no progress in two meetings was showing a bad image.	noted	No
		S3‑182072	LS on user plane integrity protection in LTE	Vodafone	LS out	Approval	Yes	Yes	approved	No
7.10.2	IP Multimedia Subsystem (IMS) Security
7.10.3	Network Domain Security (NDS)
7.10.4	UTRAN Network Access Security
7.10.5	GERAN Network Access Security
7.10.6	Generic Authentication Architecture (GAA)
7.10.7	Multimedia Broadcast/Multicast Service (MBMS)
7.10.8	Security Aspects of Home(e)NodeB (H(e)NB)
7.10.9	Security Aspects related to Machine-Type Communication ((e)MTC)
7.10.10	Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)
7.10.11	Security of MCPTT (MCPTT)	S3‑181659	[MCPTT] 33.179 R13 Add GMK management	Motorola Solutions Germany	CR	Agreement	Yes	Yes	revised	No	S3‑181938
		S3‑181938	[MCPTT] 33.179 R13 Add GMK management	Motorola Solutions Germany	CR	Agreement	Yes	Yes It was clarified that the information was already present in the Rel-13 and Rel-14 versions of the spec and that this correction was for alignment.	agreed	No		S3‑181659
		S3‑181898	[MCPTT] Definition of KMS XML Schema namespace	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181660	[MCPTT] 33.179 R13 Fix annex E.6.3 reference	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No
7.10.12	Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)
7.10.13	Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)
7.10.14	New GPRS algorithms for EASE (EASE_ALGOs_SA3)
7.10.15	Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP)
7.10.16	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
7.10.17	Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec)
7.10.18	Security of the Mission Critical Service (MCSec)	S3‑181605	[MCSec] 33180 R14 technical clarification for a proxy usage	Airbus DS SLC	CR	Agreement	Yes	Yes	revised	No	S3‑181939
		S3‑181939	[MCSec] 33180 R14 technical clarification for a proxy usage	Airbus DS SLC	CR	Agreement	No	Yes	agreed	No		S3‑181605
		S3‑181901	[MCSEC] Addition of note to say that temporary group regroup mechanism is not secured.	NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑181954
		S3‑181954	[MCSEC] Addition of note to say that temporary group regroup mechanism is not secured.	NCSC	CR	Agreement	Yes	Yes	agreed	No		S3‑181901
		S3‑181903	[MCSEC] Inclusion of MCData message types as defined by CT1	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181899	[MCSEC] Definition of KMS XML Schema namespace	NCSC	CR	Agreement	Yes	Yes	agreed	No
7.10.19	Security Aspects of Narrowband IOT (CIoT)	S3‑181615	LS on security keys for generation of shortResumeMAC-I for UP EDT	R2-1806285	LS in		Yes	Yes	replied to	No
		S3‑181994	Reply to: LS on security keys for generation of shortResumeMAC-I for UP EDT	Samsung	LS out	approval	Yes	Yes Qualcomm, Ericsson,DT: preference for the new key for the second answer.	approved	No
		S3‑181623	LS on UE differentiation in NB-IoT	R3-182509	LS in		Yes	Yes	noted	No
7.10.20	Other work items	S3‑181735	Discussion on use of TLS 1.3 in 3GPP	NCSC	discussion	Endorsement	Yes	Yes Docomo: TLS 1.3 we cannot influence. We are not doing any traffic engineering for OAM interfaces (traffic prioritzation, for example). The suggestions were endorsed, but it was decided not to send an LS to SA2.	endorsed	No
		S3‑181815	TLS 1.3	Ericsson	CR	Agreement	Yes	Yes China Mobile didn’t agree with having draft versions of RFCs being mandated here. The Chair clarified that SA3 usually works with draft RFCs and this is watched over as a normal 3GPP process. ORANGE: this draft is pretty stable in IETF.	revised	No	S3‑182056	S3‑181401
		S3‑182056	TLS 1.3	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181815
		S3‑181816	TLS 1.3	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑182057
		S3‑182057	TLS 1.3	Ericsson	CR	Agreement	Yes	Yes Keep TLS 1.1 not recommended.	agreed	No		S3‑181816
7.11	New Work Item proposals	S3‑181632	Considerations for CIoT Security work in 5G Phase 2	InterDigital, Inc.	discussion	Endorsement	Yes	Yes Ericsson: we have work based on GBA and we have also piggibacked some other work in SA2 work. ORANGE: we don’t need to copy their requirements in our documents, just refer them. Interdigital's concerns had already been taken into account.	noted	No
		S3‑181661	Discussion on WID on Network Slicing Security	Huawei, HiSilicon, CMCC, China Unicom, CATR, CATT	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181662	New WID on Network Slicing Management Security	Huawei, HiSilicon, CMCC, China Unicom, CATR, CATT	WID new	Agreement	Yes	Yes ORANGE: our SA5 delegate believes it's a bit premature to go for this security work. Wait for SA5 to finish their architecture before starting the work in SA3. Huawei commented that was not the input they got from their delegates in SA5. ORANGE: SA5 has no architecture for the management. We have no architecture to work on. I suggest to have this WID presented in August. Huawei: what they have in their TS is sufficient. Vodafone: does this include the ME and the UE? Huawei replied that they were not included and that they would clarify this in the WID description. ORANGE: it's about OAM interfaces, not so much about the core network. Ericsson: the info we get from our delegates is that the part that we need to secure, will be done in Rel-16. Vodafone believed that this was obvious and it wasn't needed, as this could be considered as a VPN or TLS for securing it. Huawei agreed and commented that this could be written in the specification. Vodafone suggested to have a better argument in the justification. ORANGE: let's wait for results from their meeting in June since TS 28.533 has hardly any content.They also commented that there was some risk that their work would be pushed to Rel-16. BT: support of slices need support in the visited network as well. ORANGE didn't think this was part of SA5's work. Vodafone: make it generic for external party and the operator. The Chair suggested to follow closely what SA5 was doing and bring the WID together with the solutions in the SA3 August meeting for one step approval provided that their progress could allow it.	noted	No
8	Studies
8.1	Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-15)
8.2	Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
8.3	Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)	S3‑181863	Addition of authorization for slice management interface solution	China Mobile,Huawei	pCR	Approval	Yes	Yes ORANGE: what's the local policy about? China Mobile: it's operator dependent. ORANGE: verification by IP address is not viable from security perspective. Ericsson: the paragraph starts with mutual authentication.	approved	No		S3‑181800
		S3‑181864	Addition of security procedures between network slicing management functions	China Mobile, Huawei	pCR	Approval	Yes	Yes	revised	No	S3‑182064	S3‑181804
		S3‑182064	Addition of security procedures between network slicing management functions	China Mobile, Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑181864
		S3‑181673	Evaluation of Authentication for slice management interface solution	Huawei, HiSilicon, CMCC	pCR	Approval	Yes	Yes	revised	No	S3‑181931
		S3‑181931	Evaluation of Authentication for slice management interface solution	Huawei, HiSilicon, CMCC,CATR, China Mobile, China Unicom,CATT	pCR	Approval	Yes	Yes	revised	No	S3‑182065	S3‑181673
		S3‑182065	Evaluation of Authentication for slice management interface solution	Huawei, HiSilicon, CMCC,CATR, China Mobile, China Unicom,CATT	pCR	Approval	Yes	Yes	approved	No		S3‑181931
		S3‑181835	Adding Evaluation for Solution 1.1 of TR33.811	CATR, China Mobile, China Unicom	pCR	Approval	Yes	Yes	merged	No	S3‑181931
		S3‑181674	Evaluation of OAuth based authorization for access to management functions solution	Huawei, HiSilicon, CMCC	pCR	Approval	Yes	Yes	revised	No	S3‑182066
		S3‑182066	Evaluation of OAuth based authorization for access to management functions solution	Huawei, HiSilicon, CMCC	pCR	Approval	Yes	Yes	approved	No		S3‑181674
		S3‑181801	Evaluation of integrity protection of NSST	China Mobile Com. Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑182029
		S3‑182029	Evaluation of integrity protection of NSST	China Mobile Com. Corporation,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑181801
		S3‑181671	Evaluation of NSST integrity protection solution	Huawei, HiSilicon	pCR	Approval	Yes	Yes	merged	No	S3‑182029
		S3‑181672	Evaluation of NSST confidentiality protection solution	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑182067
		S3‑182067	Evaluation of NSST confidentiality protection solution	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181672
		S3‑181676	Conclusions	Huawei, HiSilicon, CMCC	pCR	Approval	Yes	Yes ORANGE didn’t support having in the specification that the normative work should be done in the same release as the normative work in SA5.The last sentence should be removed. They didn't support the second bullet either. It should state that the preferred solution is 1.1 for future normative work. Ericsson supported not restricting the options for the normative work. Both bullets were reworded in the revision.	revised	No	S3‑182068
		S3‑182068	Conclusions	Huawei, HiSilicon, CMCC	pCR	Approval	Yes	Yes	approved	No		S3‑181676
		S3‑181675	Security options	Huawei, HiSilicon	pCR	Approval	Yes	Yes ORANGE objected to this document. BT supported this as long as the indications had a more proper security language. ORANGE: the table is not correct and goes beyond the scope of slicing. TIM didn’t support this contribution either. This was finally noted since there was not much support for it.	noted	No
		S3‑181862	Definition and abbreviation	China Mobile, Huawei	pCR	Approval	Yes	Yes ORANGE: many of these abbreviations are not used in the document. Ericsson confimed this. MCC: don’t refer to draft versions.	revised	No	S3‑182069	S3‑181799
		S3‑182069	Definition and abbreviation	China Mobile, Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑181862
		S3‑181678	Introduction	Huawei, HiSilicon, CMCC	pCR	Approval	Yes	Yes ORANGE: TR 33.899 was never approved. MCC: better refer to documents rather than working groups.	revised	No	S3‑182070
		S3‑182070	Introduction	Huawei, HiSilicon, CMCC	pCR	Approval	Yes	Yes	approved	No		S3‑181678
		S3‑181677	Overview	Huawei, HiSilicon	pCR	Approval	Yes	Yes ORANGE didn’t see the benefit of having an overview at all. Ericsson: network slice as a service is an optional feature in the SA5 work, which is not implied here. The overview of key issues should be in the end of the document, not here. ORANGE proposed to remove the entire clause 4 instead. There was no support for this document, so it was noted.	noted	No
		S3‑181679	Editorial and removing ENs	Huawei, HiSilicon, CMCC	pCR	Approval	Yes	Yes	approved	No
		S3‑181799	Definition and abbreviation	China Mobile Com. Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181862
		S3‑181800	Addition of authorization for slice management interface solution	China Mobile Com. Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181863
		S3‑181804	Addition of security procedures between network slicing management functions	China Mobile Com. Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181864
		S3‑182063	Draft TR 33.811	Huawei	draft TR	Approval	Yes	Yes	approved	No
		S3‑182071	Cover sheet TR 33.811	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
8.4	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)	S3‑181884	pCR to TR33.834 - New Key Issue - Synchronisation of long term keys	Vodafone España SA	pCR	Approval	Yes	Yes ORANGE: we had a conclusion in the TR. What’s the plan now? Vodafone: we objected to the conclusion and we didn’t close the work item yet since we objected having this TR sent for approval. There are several issues that we have found as key issues that justify this study to carry on in Rel-16. ORANGE: we have concluded the study item and now we bring more key issues. ORANGE: the meeting report from last meeting stated that Vodafone would bring new key issues, but that doesn't mean that we agreed with the new key issues being brought. KPN supported Vodafone and was unhappy the way the study seemed to have been ended. Gemalto supported KPN.	approved	No
		S3‑181886	pCR to TR 33.834 – new key issue, undetected key leakage	Vodafone España SA	pCR	Approval	Yes	Yes	approved	No
		S3‑181887	pCR to TR 33.834 - new key issue - Impacts of frequent use of LTKUP procedures	Vodafone España SA	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑181888	pCR to 33.834 - new key issue - User interaction as part of the LTKUP procedures	Vodafone España SA	pCR	Approval	Yes	Yes	noted	No
		S3‑182058	Draft TR 33.834	Vodafone	draft TR	Approval	Yes	Yes	approved	No
8.5	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)	S3‑181736	Requirement for and impact of a longer MAC	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑182073
		S3‑182073	Requirement for and impact of a longer MAC	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑181736
		S3‑181805	Discussion on inconsistent AKA algorithms between UE and UDM	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181808	Requirement for AKA algorithm negotiation between UE and UDM	Huawei, Hisilicon	pCR	Approval	Yes	Yes NCSC: this is very normative and it is bringing assumptions we haven’t agreed on. Qualcomm didn't find this needed at all. ORANGE supported Qualcomm. Vodafone: not written in the same style as the other items in the same clause. It's all normative when the other clauses deal with coexistence. The Chair commented that Huawei would need some offline explanations to the companies who didn’t support this contributed, hence this was noted.	noted	No
		S3‑181809	AKA algorithm negotiation between UE and UDM	Huawei, Hisilicon	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑182074	Draft TR 33.841	Vodafone	draft TR	Approval	Yes	Yes	approved	No
8.6	Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)	S3‑181775	Generalising key issue #1 in the TR 33.856	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑181645	new KI for security algorithm handling	ZTE Corporation, China Unicom	pCR	Approval	Yes	Yes ORANGE didn't find the requirement clear. Given that there was no understanding of this requirement it was noted.	noted	No
		S3‑181689	a proposal for the emergency session in SRVCC of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes BT: the last sentence in the solution details doesn' make much sense.	revised	No	S3‑182076
		S3‑182076	a proposal for the emergency session in SRVCC of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181689
		S3‑181866	Solution for KI#2	Motorola Mobility, Lenovo	pCR		Yes	Yes	merged	No	S3‑182076
		S3‑182075	Draft TR 33.856	OPPO	draft TR	Approval	No	Yes	approved	No
8.7	Other study areas	S3‑181813	Skeleton of authentication and key management for applications and 3GPP services based on 3GPP credential in 5G	China Mobile Com. Corporation	other	Approval	Yes	Yes	approved	No
		S3‑181814	Scope of authentication and key management for applications and 3GPP services based on 3GPP credential in 5G	China Mobile Com. Corporation	other	Approval	Yes	Yes	revised	No	S3‑182054
		S3‑182054	Scope of authentication and key management for applications and 3GPP services based on 3GPP credential in 5G	China Mobile Com. Corporation,Deutsche Telekom	other	Approval	Yes	Yes	approved	No		S3‑181814
		S3‑181853	Skeleton proposal for TR on CIoT security (FS_CIoT_sec_5G)	Ericsson	other	Agreement	Yes	Yes	approved	No
		S3‑181854	Scope proposal for TR on CIoT security (FS_CIoT_sec_5G)	Ericsson	other	Agreement	Yes	Yes	revised	No	S3‑182078
		S3‑182078	Scope proposal for TR on CIoT security (FS_CIoT_sec_5G)	Ericsson	other	Agreement	Yes	Yes	approved	No		S3‑181854
		S3‑182077	Draft TR 33.8bc authentication and key management for applications and 3GPP services based on 3GPP credential in 5G	China Mobile	other	Approval	Yes	Yes	approved	No
		S3‑182079	Draft TR CIoT security	Ericsson	other	Approval	Yes	Yes	approved	No
8.8	New study item proposals	S3‑181636	Study on security aspects of encrypted traffic detection and verification	China Unicom, China Telecom, China Mobile, OPPO, ZTE, Huawei, HiSilicon, Intel, CATR, CATT, Alibaba Inc., Motorola Mobility, Lenovo	SID new	Agreement	Yes	Yes Interdigital: solutions limited to the SA2 study? Or we can bring more? OPPO: we depend on the architecture design of SA2. Ericsson: SA2 may bring other solutions, but we will work on the final agreed solution in SA2. Qualcomm supported this. The objectives should be updated with this. Sandvine supported this work item and pointed out that it would be very useful for operators. IDEMIA: we don’t know if there's impact on the UICC. Qualcomm: in SA2 the UICC is not impacted and we will follow their work. Docomo objected to implying that SA3 would study any deep packet inspection, breaking encryption procedures. T-Mobile supported this study. The Chair commented that it could be an issue in the SA plenary to introduce supporting companies that don't come to SA3 and advised the Rapporteur to take this into account. ORANGE found the objective very solution specific and didn’t understand the use cases. Deutsche Telekom preferred to bring this back into the next meeting and wait for SA2's progress the following week and being aligned with them. The Chair suggested the authors to refine this for the next meeting and have offline discussions with the companies who preferred to align with SA2 activity. For this reason the study was noted.	revised	No	S3‑182059
		S3‑182059	Study on security aspects of encrypted traffic detection and verification	China Unicom, China Telecom, China Mobile, OPPO, ZTE, Huawei, HiSilicon, Intel, CATR, CATT, Alibaba Inc., Motorola Mobility, Lenovo	SID new	Agreement	Yes	Yes	noted	No		S3‑181636
		S3‑181687	Discussion paper on Network Slice enhancements SID	Nokia	discussion	Endorsement	Yes	Yes ORANGE: not slice specific authentication but studying it feasibility of having it. Make it clear that this is not replacing primary authentication. TIM: requirements from NGMN or we wait for requirements coming from SA1? ORANGE: we need to see the use cases and requirements from SA1, study whether this is really needed. What are the service requirements leading us to do this study? See first what's being done in SA1. Ericsson pointed out that there is work being done in SA2 and that could be the base for SA3's work.	noted	No
		S3‑181713	New Study on Security Aspects of the 5G Service Based Architecture	Deutsche Telekom AG	SID new	Approval	Yes	Yes It was clarified that SBA security work for Rel-15 would finish by the end of the current meeting. Ericsson queried on the timescales of this SID. Deutsche Telekom commented that work could continue in the next meetings given that this was a study item. KPN was worried that the content of the living document wasn't proper for a TR. Clarification would require quite some time. The Chair commented that it could be decided later to drop the TR or refine it properly. It was asked to be minuted that the TR wouldn't become a mere container for diverse solutions. It was agreed to send it for information for SA#80.	revised	No	S3‑181963
		S3‑181963	New Study on Security Aspects of the 5G Service Based Architecture	Deutsche Telekom AG	SID new	Approval	Yes	Yes It was commented that a SID would be needed for a Rel-16 study of SA2 activity in Rel-16. DT: changes in Rel-16 will be quite substantial. Vodafone: it is more sensible to have a TR for both Rel-15 and Rel-16. Nokia supported having separate SIDs. This was agreed in the end.	agreed	No		S3‑181713
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑181602	SA3 Work Plan	MCC	Work Plan		Yes	Yes Vodafone: LTKUP is not complete, it should continue in Rel-16. ORANGE replied that a conclusion had been approved already.This discussion was taken to the LTKUP agenda item.	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑181604	Work Plan input from Rapporteurs	MCC	other		Yes	Yes V2X work item is 100% completed (the Work Plan shows 90%).	revised	No	S3‑181965
		S3‑181965	Work Plan input from Rapporteurs	MCC	other	-	No	Yes	noted	No		S3‑181604
10	Future Meeting Dates and Venues	S3‑181603	SA3 meeting calendar	MCC	other		Yes	Yes	revised	No	S3‑182081
		S3‑182081	SA3 meeting calendar	MCC	other	-	Yes	Yes May or November 2019 could be in Singapore. NAF and Huawei were to discuss that and come back with a reponse for the next meeting.	noted	No		S3‑181603
11	Any Other Business
12	Close