TDoc list

Tdoc List

2019-08-30 17:51

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‑192500	Agenda	WG Chairman	agenda		Yes	Yes	revised	No	S3‑192978
		S3‑192978	Agenda	WG Chairman	agenda	-	Yes	Yes	approved	No		S3‑192500
3	IPR and Anti-Trust Law Reminder
4	Meeting Reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑192501	Report from last SA3 meeting/s	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‑192506	LS on Broadcast of Location Assistance Data for NR	S2-1908104	LS in		Yes	Yes	noted	No
		S3‑192509	Reply LS on DL-only UE-based positioning	S2-1908624	LS in		Yes	Yes	noted	No
6.2	IETF
6.3	ETSI SAGE	S3‑192535	256 bit radio interface algorithm performance	ETSI SAGE	LS in		Yes	YesVodafone commented that proper feedback was needed, from as many companies as possible. Nokia: single/multiple core is for UE or network side? Vodafone: both. Nokia: Multi-CPU for the core side should be assumed.	postponed	No
		S3‑192980	Reply to: 256 bit radio interface algorithm performance	Qualcomm	LS out	approval	Yes	Yes	noted	No
		S3‑192946	On the requirements for 256-bit algorithms	Qualcomm Incorporated	other	Endorsement	Yes	YesErisson: reuse hardware or optimizations? Vodafone: it can be any of those. NTT-Docomo: exluding here AD modes that may be more efficient. CATT supported this proposal. Ericsson: we don’t want to have new hardware for these but to reuse what is available. Huawei: Bottleneck in the UE not in the network. Vodafone: send an LS back to SAGE or we will be stalling their work on 256-bit algorithms. This was agreed.	noted	No
6.4	GSMA
6.5	TCG	S3‑192520	TCG progress report	InterDigital Communications	report	Information	Yes	Yes1. TCG – Highlights Publication of new or revised deliverables (incremental changes from the status reported at SA3#95-BIS) • TCG RIV: Network Equipment Remote Attestation – public review June 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG Trusted Attestation Protocol (TAP) Info Model – publication August 2019 • TCG Trusted Attestation Protocol (TAP) Use Cases – public review August 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG Mobile Device Runtime Integrity Preservation – public review August 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG TPM 2.0 Auto Thin Profile – publication August 2019 • TCG TSS 2.0 Enhanced System Level API (ESAPI) – publication August 2019 • TCG TSS 2.0 System Level API (SAPI) – publication August 2019 • TCG TSS 2.0 TPM Command Transmission Interface (TCTI) – public review July 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG Storage: Configurable Namespace Locking Examples – public review July 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG Storage: PYRITE – public review in June 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG Storage: RUBY – public review in June 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG Storage: OPAL Shadow MBR for Multiple Namespaces – public review June 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG TPM 2.0 r1.55 – X.509 Certs & Attached Components – public review May 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • TCG TPM 2.0 Auto Thin Protection Profile – published February 2019 • TCG PC Client Device Driver Design Principles for TPM 2.0 – public review February 2019 http://www.trustedcomputinggroup.org/specifications-public-review/ • IETF Remote ATtestation ProcedureS (RATS) WG in IETF Security Area About: https://datatracker.ietf.org/wg/rats/about/ Charter: https://datatracker.ietf.org/doc/charter-ietf-rats/ Documents: https://datatracker.ietf.org/wg/rats/documents/ • draft-ietf-rats-eat-01 The Entity Attestation Token (EAT) • draft-birkholz-rats-basic-yang-module-01 YANG Module for Basic Challenge-Response-based Remote Attestation Procedures • draft-birkholz-rats-information-model-00 An Information Model for Assertions used in RATS • draft-birkholz-rats-reference-interaction-model-01 Reference Interaction Model for Challenge-Response-based Remote Attestation • draft-birkholz-rats-tuda-00 Time-Based Uni-Directional Attestation • draft-fedorkow-rats-network-device-attestation-00 Network Device Attestation Workflow • draft-richardson-rats-usecases-04 Use cases for Remote Attestation common encodings • draft-tschofenig-rats-psa-token-02 Arm's Platform Security Architecture (PSA) Attestation Token 2. Meetings • TCG Annual Members Meeting in Toronto, Canada - 15-17 October 2019 • TCG Members Meeting in Miami, Florida USA – 10-13 February 2020 • MPWG meets every Thursday at 10-11 ET • TMS WG meets every Monday and Friday at 12-13 ET • CyRes WG meets every Wednesday at 11-12:30 ET 3. Conclusion It is proposed to add the contents of this contribution in the appropriate section, similar to “Reports and Liaisons from other Groups – TCG” of SA3#96 meeting report.	noted	No
6.6	oneM2M
6.7	TC-CYBER
6.8	ETSI NFV
6.9	CVDs and Research	S3‑192600	Way forward on CVD and research	CableLabs, BT, Nokia	discussion	Endorsement	Yes	YesVodafone wasn’t comfortable to having a closed group when everything done in SA3 public. On the other hand, there were weaknesses and failures that may need to be treated not publicly, so both worlds had to live together somehow. CableLabs commented that this discussion was intended for public research papers. Vodafone commented that SA3 still needed a place to discuss sensitive issues in private. Alf (NTT-Docomo) commented that this could be done away from the SA3 process, any comments or discussions could be done privately between companies any time. 3GPP papers and work were public and companies could have their own discussions outside the 3GPP environment. The Chair commented that there was no need to have a formal process for this in 3GPP and it should be done outside SA3's official involvement. Alex (BT) clarified that any intent to have a closed group in SA3 could be violating 3GPP working procedures. Orange and Huawei supported this.The general that this was the way to go and no closed groups should be set up. Alf (NTT-Docomo): we may be missing a statement in the 3GPP website clarifying to researchers the way to bring in papers that fix standard security issues, by doing it via a 3GPP member company. Apple: create an agenda item for research papers. China Mobile: this is usually done by companies already. They can always bring CRs to fix the security issues and that should be treated as a response. Several companies argued that there were other agenda items where this could be done. T-Mobile: not our job to review research papers, this is done internally in our own companies. We can bring contributions to the appropriate agenda items after internal consideration.	noted	No		S3‑191623
6.10	Other Groups	S3‑192505	Wireline Access Security requirements	BBF	LS in		Yes	YesVodafone: mention what 33.501 is relevant to and not what is not relevant to. Alf (NTT-Docomo): errors in the attached document. E.g. it's 256 bits and not bytes.	replied to	No
		S3‑192512	LS on withdrawal of TS 103 383 “Smart Cards; Embedded UICC; Requirements Specification”	ETSI TC SCP	LS in		Yes	YesOrange brought 4 CRs for this meeting to address this issue; these were in another agenda item and agreed.	replied to	No
		S3‑192986	Reply to: LS on withdrawal of TS 103 383 “Smart Cards; Embedded UICC; Requirements Specification”	Orange	LS out	approval	Yes	Yes	approved	No
		S3‑192513	LS on SG11 activities related to improvement of the SS7 security including for digital financial services	ITU-T SG11	LS in		Yes	YesBT recommended the group to read the attached documents as there were some points of interest for operators.	noted	No
		S3‑192533	LS from TC SmartM2M STF547 to 3GPP SA1 Cc SA3	ETSI TC SmartM2M	LS in		Yes	Yes	noted	No
7	Work Areas
7.1	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
7.1.1	UDR	S3‑192514	Reply LS on Nudr Sensitive Data Protection	SP-190581	LS in		Yes	YesVodafone: we had an extended discussion on this LS and we have CRs for this meeting. We can note it. Other companies argued that a reply may be needed, so it was kept open.	noted	No
		S3‑192933	Minutes of SA3/CT4 call on Nudr sensitive data protection	SA3 Vice-chair (Qualcomm Incorporated)	other	Information	Yes	Yes	noted	No
		S3‑192586	Summary of updates to S3-192276 from last meeting	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑192587	Definition of authentication subscription data and update to UDM requirement	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesOrange and Vodafone had some specific comments that were taken offline (specifically on clause 5.8). Vodafone: we were told that security had to be unespecified in release 15 so as not to interfere with CT.This is not necessary.	revised	No	S3‑192987	S3‑191986
		S3‑192987	Definition of authentication subscription data and update to UDM requirement	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑192587
		S3‑192588	Requirement on UDR	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesVodafone had issues with adding this in Release 15. Orange: in one document you say it is left for implementation and in the other you are defining requirements.There is no time to work on this in Release 15. Let's not address this in Release 15 as pointed out to us by SA.	not pursued	No		S3‑192053
		S3‑192589	Missing UDR description in alignment with 29.505	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesVodafone,NTT-Docomo and Orange didn’t agree with this.Only the change in the abbreviation update was agreed. Orange added that they didn’t see the consequences in stage 3 if the word "authentication" wasn't added to subscription data in the new text. Leave to CT4 to decide which kind of subscription data is stored. NTT-Docomo replied that CT4 needed a separate place to store authentication method. Vodafone replied that this wasn't what was agreed during joint discussions with CT4. NTT-Docomo added that the abbreviation change was only kept if used in the CRs or specification. Orange: HSM is not used in the text.	revised	No	S3‑192988	S3‑192054
		S3‑192988	Missing UDR description in alignment with 29.505	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑192589
		S3‑192591	Adding Nudr service	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesNokia added that this coud be done in Release 16 and proposed to not pursue it.	not pursued	No		S3‑192056
		S3‑192590	Update on ARPF	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesAlf (NTT-Docomo): the ARPF just stores the long-term key,"may" is not necessary. Gemalto agreed with this. Vodafone pointed out that no standardization had to be done in Release 15 as agreed with SA.Alex (BT): this asssumes that the only attack is decrypting the data in UDR. You can also replace whatever is in the UDR. Let's do it properly in Release 16, including all possible attacks.	revised	No	S3‑192989	S3‑192055
		S3‑192989	Update on ARPF	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S3‑192590
		S3‑193083	Discussion on UDR related contributions	Nokia	discussion	discussion	Yes	Yes	endorsed	No
7.1.2	Incoming and outgoing related Lses
7.1.3	Other 5G security aspects	S3‑192530	Corrections for Definitions and Abbreviations clauses	AT&T, Interdigital, Nokia	CR	Approval	Yes	YesOrange: SE is not the adequate abbreviation. Ericsson didn't find the definition precise enough. Qualcomm didn't find the change needed. China Mobile didn’t agree with having it as a logical identity, since it could be a physical protection. Gemalto supported this. Nokia: the term is used 22 times and it is part of the UDM/UDR discussion. Orange commented that the term secure environment was self-explanatory.	not pursued	No
		S3‑192624	Correcting references	ZTE Corporation	CR	Agreement	Yes	YesEricsson: second change refer directly to TS 33.210 instead.	revised	No	S3‑192990
		S3‑192990	Correcting references	ZTE Corporation	CR	Agreement	Yes	Yes	agreed	No		S3‑192624
		S3‑192625	Removing editor notes	ZTE Corporation	CR	Agreement	Yes	YesAlf (NTT-Docomo): the reasons for change are not clear. Some additional typos were suggested to be fixed in the text of the specification.	revised	No	S3‑192991
		S3‑192991	Removing editor notes	ZTE Corporation	CR	Agreement	Yes	Yes	agreed	No		S3‑192625
		S3‑192540	Correction of text on access authentication for untrusted access	BlackBerry UK Limited	CR	Agreement	Yes	YesTreated as item for early consideration. Lenovo: the WLAN part is out of scope for us. We don’t want to see this. Nokia didn’t agree either, although the reference correction should be left. Tao (CableLabs) supported the above companies. Blackberry commented that in CT1 they needed to define a procedure to select ANI, but they couldn't since this SA3 specification didn’t have a requirement for that. Huawei: you can fall back to Release 8 and use LTE security.	revised	No	S3‑192979
		S3‑192979	Correction of text on access authentication for untrusted access	BlackBerry UK Limited	CR	Agreement	Yes	Yes	agreed	No		S3‑192540
		S3‑192793	Modification of the message name in the key derivation during handover	CATT	CR	Agreement	Yes	YesEricsson: not a FASMO change. This is not needed. Alf (NTT-Docomo): this is being used in SA2 and we have a chance of aligning stage 3 with SA2.	not pursued	No
		S3‑192708	Clarification on the topology hiding in SBI	Huawei, Hisilicon	CR	Approval	Yes	YesNokia: this is too long and confusing. Ericsson: CT4 has decided to do this in Release 16. Let's not interfere with them. China Mobile also wondered why this was needed in Release 15 and it should be a new feature in Release 16. This was taken offline.	not pursued	No
		S3‑192947	Aligning KAUSF storage at the UE with SoR and UPU procedures	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑192862	Security of RRC UE capability transfer procedure in 5GS	Ericsson	CR	Agreement	Yes	YesQualcomm: this won’t work with CIoT Ues that don’t support AES security.it's probably OK to release 15 (we don’t support CIoT optimizations there) but not for the other releases.	agreed	No
		S3‑192792	Discussion on the procedure of secondary authentication	China Mobile	discussion	Discussion	Yes	YesHuawei: this point has been clarified already in SA2 already.Just one clarification is needed in step 8. Nokia: Exchange of MAC and IP will happen later than step 8. China Mobile: this may impact SA2 specifications so we need to know if they accept this kind of change. Ericsson was OK with this approach.	not pursued	No
		S3‑192794	Adjust the proceudure of GPSI and IP/MAC notification	China Mobile	CR	Approval	Yes	YesHuawei: call flow needs to be updated. Qualcomm: the baseline is wrong, showing only some steps.	revised	No	S3‑192992
		S3‑192992	Adjust the proceudure of GPSI and IP/MAC notification	China Mobile	CR	Approval	Yes	Yes	agreed	No		S3‑192794
		S3‑192777	Clarification for Secondary Authentication	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192993
		S3‑192993	Clarification for Secondary Authentication	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192777
		S3‑192929	Discussion on leaving AMF relocation solutions to after Rel-15	Qualcomm Incorporated	discussion	Endorsement	Yes	YesZTE supported the proposal.Huawei didn’t since they had an alternative in another document. They commented that it wasn't a decision for SA3 but for SA2. Nokia pointed out that SA2 had been already consulted with an LS, so the decision could be postponed until their response. Nokia supported Qualcomm for this proposal. China Mobile didn’t agree and considered this needed in Release 15.	noted	No
		S3‑192930	Discussion on possible solutions to AMF relocation issues	Qualcomm Incorporated	discussion	Discussion	Yes	YesThis discussion was taken offline.	noted	No		S3‑191911
		S3‑192887	Discussion about AMF re-allocation and slicing	Ericsson	discussion	Approval	Yes	YesHuawei just supported number 7. China Mobile didn’t support proposal 2. Ericsson commented that the purpose was to send an LS on the agreed proposals after offline discussion (tdoc 889 was the baseline for that LS). Huawei: the term default AMF is not adequate, since it's an SA2 term. Ericsson replied that SA3 could ask them to re-adapt that term to SA3's conclusions. This was taken offline.	noted	No
		S3‑192888	AMF re-allocation and slicing	Ericsson	CR	Approval	Yes	YesNokia: no need to have a new clause on this. This was left offline together with the related documents.	not pursued	No
		S3‑192615	Discussion on registration with AMF re-allocation	ZTE Corporation	discussion	Discussion	Yes	Yes	noted	No
		S3‑192617	Security for registration with AMF re-allocation	ZTE Corporation	CR	Agreement	Yes	YesNokia didn't believe that this was solving the issue. Huawei agreed.	not pursued	No
		S3‑192711	Discussing registration failure in registration procedure with AMF reallocation	Huawei, Hisilicon, CAICT	discussion	Endorsement	Yes	Yes	noted	No
		S3‑192710	Solving registration failure in registration procedure with AMF reallocation	Huawei, Hisilicon, CAICT	CR	Approval	Yes	YesEricsson: we disagree with having the UE accepting protected messages. This had to be taken offline.	not pursued	No
		S3‑192709	Claification on UE context transfer in registration with AMF reallocation via direct NAS reroute	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm: the UE is not impacted, but the cover page says the same. The last sentence refers to the UE's behaviour which also implies UE impact. This was left offline.	revised	No	S3‑193058
		S3‑193058	Claification on UE context transfer in registration with AMF reallocation via direct NAS reroute	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192709
		S3‑192616	Discussion on Identity Request with AMF re-allocation	ZTE Corporation	discussion	Discussion	Yes	Yes	noted	No
		S3‑192618	LS on registration and identity request issues with AMF re-allocation	ZTE Corporation	LS out	Approval	Yes	Yes	noted	No
		S3‑192889	LS on AMF reallocation between Network Slices	Ericsson	LS out	Approval	Yes	Yes	noted	No
		S3‑192630	Discussion on the handling of native non-current 5G NAS security context after an inter-system change from S1 mode to N1 mode in idle mode	Intel Deutschland GmbH	discussion	Decision	Yes	Yes	endorsed	No
		S3‑192631	Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility	Intel Deutschland GmbH	CR	Agreement	Yes	YesHuawei: remove the word "current" from the new text. Samsung: this is not aligned with the discussion paper. They suggested some rewording for that. Qualcomm had a similar CR in the next contribution.	revised	No	S3‑192997
		S3‑192997	Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility	Intel Deutschland GmbH,Qualcomm	CR	Agreement	Yes	Yes	agreed	No		S3‑192631
		S3‑192941	NAS Count values in the mapped EPS security context in 5GS to EPS change	Qualcomm Incorporated	CR	Agreement	Yes	YesIntel didn’t agree with the notes.The first part was agreed and incorporated into the revision of Intel's document. Nokia: the notes should be made normative text. Qualcomm: CT1 can develop their solution based on this note. Alf (NTT-Docomo) clarified that SA3 was doing stage 2. Ericsson replied that stage 3 needs to know when this procedure is triggered.	merged	No
		S3‑192682	Description of issue of security context transfer following the handover from EPS to 5GS	Huawei, Hisilicon	discussion	Discussion	Yes	YesEricsson: this is a valid problem.	noted	No
		S3‑192683	Security context transfer following the handover from EPS to 5GS	Huawei, Hisilicon	CR	Approval	Yes	YesQualcomm: this is pure network behaviour (not UICC and ME impacted). They also wanted to precise timing conditions for stage 3 for the target AMF mapping the new 5G security context. NTT-Docomo: operators will need some implementation options for this configuration. They later withdrew this comment after offline discussions.	revised	No	S3‑192998
		S3‑192998	Security context transfer following the handover from EPS to 5GS	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192683
		S3‑192717	Changes on handover from 5GS to EPS over N26	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: this should be done in 8.6.2. It was commented that this was done already somewhere else. Qualcomm:sentence above 8.3.2 is not needed. Remove as editorial.	revised	No	S3‑192999
		S3‑192999	Changes on handover from 5GS to EPS over N26	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192717
		S3‑192940	Issues of resetting NAS COUNT values in 5G to 4G mobility	Qualcomm Incorporated	discussion	Endorsement	Yes	YesThere seemed to be an agreement on having an issue here. Qualcomm solution brought some sympathies like from Ericsson, but it required some more discussions since Huawei wasn't convinced at all. Nokia: KNodeB needs to be addressed.	noted	No		S3‑191916
		S3‑192563	NAS Count values in the mapped EPS security context in 5GS to EPS change	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑191917
		S3‑192996	Notes of the offline session on AMF relocation	NTT-Docomo	report	Information	Yes	Yes	noted	No
		S3‑193084	LS on security asepcts of AMF re-alocation procedure	Qualcomm	LS out	Approval	Yes	Yesthis was split into two different versions: 195 and 196.	revised	No	S3‑193195
		S3‑193195	Draft LS on security asepcts of AMF re-alocation procedure	Ericsson	LS out	Approval	Yes	Yes	merged	No	S3‑193197	S3‑193084
		S3‑193194	Notes of the second offline session on AMF relocation	NTT-Docomo	report	Information	Yes	Yes	noted	No
		S3‑193196	Draft LS on security asepcts of AMF re-alocation procedure	Huawei	other	discussion	Yes	YesThis contains part of the LS in tdoc 084.	revised	No	S3‑193197
		S3‑193197	LS on security asepcts of AMF re-alocation procedure	Qualcomm	LS out	Approval	Yes	Yes	approved	No		S3‑193196
7.2	Security Assurance Specification for 5G (SCAS_5G) (Rel-16)
7.2.1	NR Node B (gNB) (TS 33.511)	S3‑192635	Categorization of the test cases and other editorial corrections	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesMCC commented that it was not possible to renumber the clauses in an approved specification. Huawei commented that there were CRs from the last meeting correcting editorial errors in these clauses. Possible conflicts had to be checked offline.	revised	No	S3‑193003
		S3‑193003	Editorial corrections on the threat references of some test cases	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesKeeping only editorials.	agreed	No		S3‑192635
		S3‑192763	Update requirements and test cases for gNB SCAS	Huawei, Hisilicon	CR	Approval	Yes	YesNokia: in 33.117 this was already conditional. Not sure that this test case is needed. MCC: The new clause has the wrong numbering, and there seems to be missing clauses from the baseline and a hangning paragraph.	revised	No	S3‑193004
		S3‑193004	Update requirements and test cases for gNB SCAS	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192763
		S3‑192823	Test cases referring to TS 33.117	Ericsson	CR	Agreement	Yes	YesHuawei suggested to handle these test cases for the next meeting in order to introduce modifications and not to remove them. Nokia agreed with Ericsson; no need to modify, but remove them. Reformulate or convert them to negative tests: Steffan (Deutsche Telekom) There was an agreement that the relevant test cases have a problem that needed to be addressed for the next meeting. .	not pursued	No	S3‑193001
		S3‑193001	Test cases referring to TS 33.117	Ericsson	CR	Agreement	No	Yes	withdrawn	Yes		S3‑192823
		S3‑192833	Correction to test case requirement reference	L.M. Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No
7.2.2	Access and Mobility Management Function (TS 33.512)	S3‑192824	Test cases referring to TS 33.117	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193002	Test cases referring to TS 33.117	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑192976	Comments on S3-192824	Huawei Technologies Co. Ltd.	discussion	Approval	Yes	Yes	noted	No
		S3‑192714	Adding AMF critical assets and threats to TS 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesDraft CR agreed in the last meeting changed to a CR. Ericsson: N26 interface AMF to MME should be added here in critical assets.	revised	No	S3‑193005
		S3‑193005	Adding AMF critical assets and threats to TS 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192714
		S3‑193087	Draft TS 33.512	Huawei	draft TS	Approval	Yes	Yes	approved	No
7.2.3	User Plane Function (UPF) (TS 33.513)	S3‑192715	Adding UPF critical assets and threats to TS 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑193006
		S3‑193006	Adding UPF critical assets and threats to TS 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesMCC pointed out that the introduction clause in the annex was referring to the whole document and not the specific annex, so this had to be reworded.	agreed	No		S3‑192715
		S3‑192716	Editorial change on TS 33.513	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193009	Cover sheet TS 33.512 for approval	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
		S3‑193010	Cover sheet TS 33.513 for approval	Samsung	TS or TR cover	Approval	Yes	Yes	approved	No
		S3‑193024	Draft TS 33.513	Samsung	draft TS	Approval	Yes	Yes	approved	No
7.2.4	Unified Data Management (UDM) (TS 33.514)	S3‑192576	Editorial corrections for SCAS UDM TS 33.514 v0.5.0	NEC Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑192697	Editorial change on TS 33.514	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192696	UDM critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesHuawei:the reference clause doesn't match the current baseline of 33.926. MCC added that the references were not used in the text,so the new references had to be removed.	revised	No	S3‑193008
		S3‑193008	UDM critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192696
		S3‑193007	Draft TS 33.514	NEC	draft TS	Approval	Yes	Yes	approved	No
		S3‑193011	Cover sheet TS 33.514 for approval	NEC	TS or TR cover	Approval	Yes	Yes	approved	No
7.2.5	Session Management Function (SMF) (TS 33.515)	S3‑192712	Adding SMF critical assets and threats to TS 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑193012
		S3‑193012	Adding SMF critical assets and threats to TS 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesIssue with the introduction of the annex as the previous documents.	agreed	No		S3‑192712
		S3‑192713	Editorial change on TS 33.515	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑193013
		S3‑193013	Editorial change on TS 33.515	Huawei, Hisilicon	pCR	Approval	Yes	YesExecutions steps in 4.2.2.1.3 had to be checked.	approved	No		S3‑192713
		S3‑193014	Draft TS 33.515	Huawei	draft TS	Approval	Yes	Yes	approved	No
		S3‑193015	Cover sheet TS 33.515 for approval	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
7.2.6	Authentication Server Function (AUSF) (TS 33.516)	S3‑192698	AUSF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑193016
		S3‑193016	AUSF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192698
		S3‑192699	Editorial change on TS 33.516	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193017	Draft TS 33.516	Ericsson	draft TS	Approval	Yes	YesMCC warned that the document didn’t have any definitions and abbreviations. Ericsson commented that they would bring a CR for the next meeting to finish these clauses.	approved	No
		S3‑193018	Cover sheet TS 33.516 for approval	Ericsson	TS or TR cover	Approval	Yes	Yes	approved	No
7.2.7	Security Edge Protection Proxy (SEPP) (TS 33.517)	S3‑192602	Living Document: New Annex for the SEPP in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	revised	No	S3‑193138
		S3‑193138	Living Document: New Annex for the SEPP in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	approved	No		S3‑192602
		S3‑192700	Editorial changes on SEPP critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesThis is converting the living document into a CR, but Nokia commented that there was still some input for the lviing documents so this was kept open.	revised	No	S3‑193139
		S3‑193139	Adding SEPP critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192700
		S3‑192657	Threat analysis on misplacement of encrypted IE in JSON object by IPX	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesHuawei: this is not needed. There are no threats. Nokia: we have described an attack, of course there are threats.	revised	No	S3‑193085
		S3‑193085	Threat analysis on misplacement of encrypted IE in JSON object by IPX	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	approved	No		S3‑192657
		S3‑192658	Test Case: No misplacement of encrypted IE in JSON object by IPX	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193086
		S3‑193086	Test Case: No misplacement of encrypted IE in JSON object by IPX	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192658
		S3‑192660	Add the missing expected format of evidence	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192701	Editorial change on TS 33.517	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193019	Draft TS 33.517	Nokia	draft TS	Approval	Yes	YesMCC urged the Rapporteurs to add acronyms to the specifications, especially TS since most of them were not present in TR 21.905.	approved	No
		S3‑193198	Cover sheet TS 33.517 for approval	Nokia	TS or TR cover	Approval	Yes	Yes	approved	No
7.2.8	Network Resource Function (NRF) (TS 33.518)	S3‑192603	Living Document: New Annex for the NRF in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Decision	Yes	Yes	approved	No
		S3‑192702	Adding NRF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesThis is converting the living document into a CR.	revised	No	S3‑193020
		S3‑193020	Adding NRF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesIt removes the new changes and it maintains the original changes from the living document.	agreed	No		S3‑192702
		S3‑192703	Editorial change on TS 33.518	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193022	Draft TS 33.518	Nokia	draft TS	Approval	Yes	YesMCC pointed out that all SCAS specs needed a note explaining why 33.501 release 15 was being referenced instead of the same release as the current TS, if there would be backward compatibility problems if this wasn't done, etc.. It was agreed that Rapporteurs brought CRs for the same meeting to add such note. It was also noted that "v15" was not correct and "release 15" should be written instead.	approved	No
		S3‑193023	Cover sheet draft TS 33.518 for approval	Nokia	TS or TR cover	Approval	Yes	YesMCC commented that unfinished work should appear in "outstanding issues": e.g. definitions, abbreviations and test cases that needed to be brought.	approved	No
7.2.9	Network Exposure Function (NEF) (TS 33.519)	S3‑192626	Adding abbreviation	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑193025
		S3‑193025	Adding abbreviation	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑192626
		S3‑192704	Adding NEF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑193027
		S3‑193027	Adding NEF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesRewording the Introduction to refer to the annex and not the whole document, and fixing editorials as suggested as Ericsson.	agreed	No		S3‑192704
		S3‑193026	Draft TS 33.519	ZTE	draft TS	Approval	Yes	Yes	approved	No
7.2.10	Other 5G SCAS aspects	S3‑192601	Living Document: General SBA/SBI aspects in TS 33.117	Nokia, Nokia Shanghai Bell	draftCR	Decision	Yes	Yes	approved	No
		S3‑192706	Update of living Document: General SBA/SBI aspects in TS 33.117	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑193029
		S3‑193029	Addition of general SBA/SBI aspects in TS 33.117	Huawei, Hisilicon,Nokia	CR	Approval	Yes	YesComments on the clause numbering provided by MCC. The spec baseline had to be checked.	agreed	No		S3‑192706
		S3‑192705	Adding critical assets and threats for general NFs to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: the title of the annex is not descriptive of the network product class. This was revised to change the title.	revised	No	S3‑193030
		S3‑193030	Adding critical assets and threats for general NFs to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192705
		S3‑193028	Cover sheet TS 33.519 for approval	ZTE	TS or TR cover	Approval	Yes	Yes	approved	No
7.3	eMCSec R16 security (MCXSec) (Rel-16)	S3‑192519	Clarifications for Protected MCData	Airbus DS SLC	CR	Agreement	Yes	YesMotorola: this is not needed. NCSC agreed. Samsung: too many stage 3 parameters. This is not needed.	revised	No	S3‑193021
		S3‑193021	Clarifications for Protected MCData	Airbus DS SLC	CR	Agreement	Yes	Yes	not pursued	No		S3‑192519
		S3‑192963	Algorithm Negotiation	Samsung	CR	Agreement	Yes	YesNCSC preferred to follow the way of not changing the algorithms but the key length of the algorithms. The contribution was taken offline.	not pursued	No
		S3‑193043	Algorithm Negotiation	Samsung	CR	Agreement	No	Yes	withdrawn	Yes
7.4	Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16)	S3‑192918	Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑193047	S3‑192338
		S3‑193047	Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑192918
		S3‑192923	Correction to figure in draft CR for 5G to UTRAN CS SRVCC	Qualcomm Incorporated, China Unicom	other	Approval	Yes	Yes	revised	No	S3‑193044
		S3‑193044	Correction to figure in draft CR for 5G to UTRAN CS SRVCC	Qualcomm Incorporated, China Unicom	other	Approval	Yes	Yes	approved	No		S3‑192923
		S3‑192922	Draft CR for SRVCC 5G to UTRAN	China Unicom, Qualcomm Incoporated	draftCR	Approval	Yes	YesIt was argued whether the CR could be ready for the current meeting to finalise the work for once and all, but the Rapporteur needed to be consulted since she was absent.	revised	No	S3‑193045	S3‑192335
		S3‑193045	Draft CR for SRVCC 5G to UTRAN	China Unicom, Qualcomm Incoporated	draftCR	Approval	Yes	Yes	approved	No		S3‑192922
		S3‑193046	Security for SRVCC 5G to UTRAN CS	Qualcomm,China Unicom	CR	Agreement	Yes	YesQualcomm commented that China Unicom had agreed to help on this CR, but no confirmation from them had been received.	agreed	No
7.5	Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF) (Rel-16)	S3‑192955	Security procedures for CAPIF-7/7e reference points	Samsung	CR	Agreement	Yes	Yes	agreed	No
		S3‑192956	Security procedures for CAPIF-3e/4e/5e reference points	Samsung	CR	Agreement	Yes	YesNokia had doubts about referencing both 210 and 310. This was taken offline.	agreed	No
7.6	Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)	S3‑192766	draftCR for URLLC	Huawei, Hisilicon	draftCR	Approval	Yes	YesEricsson preferred to move content to an annex instead of deleting the text.	revised	No	S3‑193048
		S3‑193048	draftCR for URLLC	Huawei, Hisilicon, Qualcomm	draftCR	Approval	Yes	Yes	approved	No		S3‑192766
		S3‑192942	Skeleton of URLLC	Qualcomm Incorporated	draftCR	Agreement	Yes	Yes	merged	No	S3‑193048
		S3‑192873	Introduction to URLLC services	Ericsson	draftCR	Approval	Yes	Yes	merged	No	S3‑193048
		S3‑192874	Retaining AS security keys for redundant data transmission in user plane	Ericsson	draftCR	Approval	Yes	YesQualcomm: there is nothing new here, what is the reference for?	noted	No
		S3‑192875	Redundant paths using Dual Connectivity for URLLC services - introduction	Ericsson	draftCR	Approval	Yes	Yes	merged	No	S3‑193048
		S3‑192876	Redundant paths using Dual Connectivity for URLLC services – security keys derivation	Ericsson	draftCR	Approval	Yes	YesQualcomm: this clause is not needed. Huawei agreed, but the content could be added to the introduction. This was agreed.	merged	No	S3‑193048
		S3‑192877	Redundant paths using Dual Connectivity for URLLC services - security policy aspects	Ericsson	draftCR	Approval	Yes	YesThe use of "should" in the second paragraph had to be removed given that Qualcomm argued that this had to be a "shall" and there was no agreement.	merged	No	S3‑193048
		S3‑192878	Redundant paths using Dual Connectivity for URLLC services – UP security activation status	Ericsson	draftCR	Approval	Yes	Yes	merged	No	S3‑193048
7.7	Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)	S3‑192593	Endorsement of CR on Non-public network security	Qualcomm, Nokia, Nokia Shanghai Bell	discussion	Agreement	Yes	Yes	noted	No
		S3‑192592	Security for non-public networks - update to S3-192453	Qualcomm, Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	YesThe note on Z.2.2 was reworded as Orange had issues with it. There was an agreement on non-3GPP credentials from a previous meeting and this had to be checked offline. There was also an added clarification for the use of non AKA EAP methods. Telecom Italia: Non AKA could be confusing, it could also be TLS. Public networks non standalone are also considered here? Nokia replied that these were also considered apart and discussed offline and done in TS 33.501. Telecom Italia commented that in that case the annex was incomplete without his scenario. Orange agreed to add an editor's note on this part (security aspects for other NPN issues including integrated non public networks are FFS). Interdigital: non-AKA should be defined here. It doesn’t stand for a generic AKA but for a specific AKA. Orange preferred not to go for a definition for this term,but replace it with the specific 5G-AKA or EAP-AKA' where it corresponds. It was argued that non-AKA implied both and nothing was needed to be done for the sake of legibility of the text.	revised	No	S3‑193049
		S3‑193049	Security for non-public networks - update to S3-192453	Qualcomm, Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	YesOrange objected to NOTE 2: not clear how the credentials EAP-AKA' and 5G AKA are stored. ORANGE TO PROVIDE EXACT WORDING. Thales commented that there had been previous agreement on the note. The Chair clarified that this was a draft CR in any case.	approved	No		S3‑192592
		S3‑192577	Security for non-public networks	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	CR		Yes	Yes	revised	No	S3‑193051
		S3‑193051	Security for non-public networks	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	CR	-	Yes	Yes	agreed	No		S3‑192577
		S3‑192924	Some proposed editorial changes to NPN draft CR	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	other	Approval	Yes	Yes	approved	No
		S3‑192927	SUCI privacy for SNPN	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	other	Approval	Yes	YesGemalto and IDEMIA argued that the first sentence was preventing the storage in the USIM and that wasn't true. Alf (NTT-Docomo) pointed out that privacy was needed and offerend to rephrase the first sentence to address Gemalto's comments. Orange asked if the privacy topic mentioned here would go any further, and Qualcomm replied that this was enough. Alf (NTT-Docomo): add a requirement on SUPI privacy shall protect the privacy of the SUCI. Orange didn't agree with this since it would not be clear where and how this would happen. Qualcomm: privacy may happen outside the USIM. Orange: don't mandate it in the ME. It was also agreed to change the title of the clause to address the SUPI instead of the SUCI. This was taken offline.	revised	No	S3‑193050
		S3‑193050	SUCI privacy for SNPN	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	other	Approval	Yes	Yes	approved	No		S3‑192927
7.8	Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)	S3‑192508	Reply LS on RRC Connection Re-Establishment for CP for NB-IoT connected to 5GC	S2-1908553	LS in		Yes	Yes	noted	No
		S3‑192511	Reply LS on authentication of group of IoT devices	S2-1908632	LS in		Yes	Yes	noted	No
		S3‑192977	Reply LS on authentication of group of IoT devices	S1-192816	LS in	discussion	Yes	Yes	noted	No
		S3‑192959	DraftCR - Proposed skeleton for supporting 5G CIoT	Ericsson, Nokia	draftCR		Yes	YesThe definition was controversial, as Huawei didn’t agree with it. The definition was removed. Vodafone pointed out that several other clauses could be affected and not only under 6. This was agreed to be checked for the next meeting. An editor's note was added on the alignment with SA2 and RAN.	revised	No	S3‑193052
		S3‑193052	DraftCR - Proposed skeleton for supporting 5G CIoT	Ericsson, Nokia	draftCR	-	Yes	Yes	approved	No		S3‑192959
		S3‑192961	DraftCR-Control Plane Optimization for CIoT in 5G	Ericsson	draftCR		Yes	YesNokia: not part of the study and even in LTE we didn’t do this. Huawei: not sure if this is aligned with SA2 and RAN either on the gNodeB. Nokia commented that this needed more study and proposed to postpone this part.	noted	No
		S3‑192775	Security handling in Control Plane User Data for Control Plane Optimization for 5GS CIoT	Huawei, Hisilicon	other	Approval	Yes	YesNokia: security for the control plane hasn't been handled yet in the study. This can be addressed in the next meeting. Qualcomm: no need to rush, the second paragraph is still being discussed in CT1. Martin (AT&T) commented that no assumptions could be done in the control plane since there were still numerous discussions in CT1. This topic was postponed for the next meeting.	noted	No
		S3‑192776	Protection of Non-IP Data Delivery (NIDD) interfaces	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No
		S3‑192948	New Solution for botnet threats caused by improper CIOT device usage	NIST, ATT, SPRINT, CABLE LABS, CISCO	pCR	Approval	Yes	Yes	revised	No	S3‑192960
7.9	Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC) (Rel-16)	S3‑192760	skeleton of 5WWC	Huawei, Hisilicon	other	Approval	Yes	YesEricsson: better to add another subclause than renaming existing ones. Nokia agreed with this.MCC commented that it was better to add subclauses for the wireline access and the non-3GPP access: 7a and 7b.	revised	No	S3‑193053
		S3‑193053	skeleton of 5WWC	Huawei, Hisilicon	draftCR	Approval	Yes	YesThis will be the living document that captures the inputs of this agenda item.	approved	No		S3‑192760
		S3‑192581	Add a new Annex for the authentication of non-5GC NAS capable devices in WWC	CableLabs, Charter Communications, Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility, Ericsson, Comcast, Rogers Communications	draftCR	Agreement	Yes	YesOrange: this procedure will not be mandated, so the annex should be informative. Deutsche Telekom: you need to add the acronym and definition of W-AGF. Telecom Italia queried whether this was for the study, then the CR would not be valid. It was clarified that this was a draft CR for the normative work item. Finally it was agreed to merge this into the living document/ draft CR that would introduce all 5WWC changes. There was some discussion about the term "N5GC device": Orange warned that there were two terms for the devices in SA2 and that in SA3 they had to be more specific and use only one.It was proposed to use "Non 5GC device" and this was agreed. Interdigital questioned using a flow diagram from SA2 that would have to be updated every time it was changed in that WG.	revised	No	S3‑193054
		S3‑193054	Add a new Annex for the authentication of non-5GC NAS capable devices in WWC	CableLabs, Charter Communications, Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility, Ericsson, Comcast, Rogers Communications	draftCR	Agreement	Yes	Yes	approved	No		S3‑192581
7.10	Security aspects of Enhanced Network Slicing (eNS_SEC) (Rel-16)	S3‑192726	Slice-specific authentication	Huawei, HiSilicon	draftCR	Agreement	Yes	YesNokia: postpone this for next meeting. Vodafone: how is the network going to agree with what methods are going to be used? We need a framework, there are lot of options. Telecom Italia: the slice is internal by definition, not be confused with secondary autentication. Huawei conceded and promised to bring contributions to address all concerns.	noted	No
7.11	Other work areas
7.11.1	SAE/LTE Security	S3‑192861	Security of RRC UE capability transfer procedure in EPS	Ericsson	CR	Agreement	Yes	YesNokia: not only control optimization UEs but applicable for all UEs. NTT-Docomo: if the UE does not AES security this is not going to work.This doesn’t provide security for control optimized Ues/ CIoT. They wanted to create an action item/editor's note to provide the missing part in the future; an additional problem that needed to be fixed. It was commented that this was enoug to respond to the LS but the CIoT scenario needed to be considered as well in the future. The Chair commented that a quick answer was needed since this affected release 15; if the new problem was in release 15, this would need to be told to other WGs. This was taken offline.	revised	No	S3‑193074
		S3‑193074	Security of RRC UE capability transfer procedure in EPS	Ericsson	CR	Agreement	Yes	Yes	not pursued	No		S3‑192861
7.11.2	IP Multimedia Subsystem (IMS) Security
7.11.3	Network Domain Security (NDS)	S3‑192578	General NDS/IP SEG support for non-SBA interfaces	Juniper Networks	CR		Yes	Yes	revised	No	S3‑193000
		S3‑193000	General NDS/IP SEG support for non-SBA interfaces	Juniper Networks	CR	-	Yes	YesRevised given that the document could not be opened by some (including MCC).	agreed	No		S3‑192578
7.11.4	UTRAN Network Access Security
7.11.5	GERAN Network Access Security
7.11.6	Generic Authentication Architecture (GAA)
7.11.7	Security Aspects of Home(e)NodeB (H(e)NB)
7.11.8	Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)	S3‑192516	Reply LS on ETSI Plugtest standards issues	S6-191525	LS in		Yes	Yes	noted	No
7.11.9	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑192652	Additional Critical Assets and Threats to PGW Annex R16	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	revised	No	S3‑193033
		S3‑193033	Additional Critical Assets and Threats to PGW Annex R16	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑192652
		S3‑192653	Additional Critical Assets and Threats to PGW Annex R15	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesIt was clarified that the CR should be cat-F.	revised	No	S3‑193031
		S3‑193031	Additional Critical Assets and Threats to PGW Annex R15	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑192653
		S3‑192654	Adding Threat References to PGW Test Cases R15	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesChanged the category to A and creating a new CR to do the correction in release 14.	revised	No	S3‑193035
		S3‑193035	Adding Threat References to PGW Test Cases R15	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	Yes	agreed	No		S3‑192654
		S3‑192707	Clarification on test cases in TR 33.117	Huawei, Hisilicon	CR	Approval	Yes	YesDeutsche Telekom objected to deleting the last two bullets in the second change. It was noted that the cover sheet referred to the wrong release and it had the wrong categroy.	revised	No	S3‑193036
		S3‑193036	Clarification on test cases in TR 33.117	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192707
		S3‑192761	Update testcase of 4.2.4.1.1.2 and 4.2.4.1.1.3	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑192762	Update test cases for 4.3.2.3,4.3.2.4, and 4.3.2.5	Huawei, Hisilicon	CR	Approval	Yes	YesDeutsche Telekom wasn't fine with this.	not pursued	No
		S3‑192764	Update requirements and test cases for eNB SCAS	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑193041
		S3‑193041	Update requirements and test cases for eNB SCAS	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192764
		S3‑193032	Additional Critical Assets and Threats to PGW Annex R14	Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑193034	Adding Threat References to PGW Test Cases R14	Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑193037	Clarification on test cases in TS 33.117	Huawei	CR	Agreement	Yes	Yes	agreed	No
		S3‑193038	Clarification on test cases in TS 33.117	Huawei	CR	Agreement	Yes	Yes	agreed	No
		S3‑193039	Update testcase of 4.2.4.1.1.2 and 4.2.4.1.1.3	Huawei	CR	Agreement	Yes	Yes	agreed	No
		S3‑193040	Update testcase of 4.2.4.1.1.2 and 4.2.4.1.1.3	Huawei	CR	Agreement	Yes	Yes	agreed	No
		S3‑193042	Update requirements and test cases for eNB SCAS	Huawei	CR	Agreement	Yes	Yes	agreed	No
7.11.10	Security Aspects of Narrowband IOT (CIoT)	S3‑192510	Reply LS on Mobile-terminated Early Data Transmission	S2-1908629	LS in		Yes	YesSecurity issues: Huawei didn’t think there were any. It was then discussed whether to acknowledge the security issues and just say that it would require additional work.This was agreed.	replied to	No
		S3‑193059	Reply to: Reply LS on Mobile-terminated Early Data Transmission	Nokia	LS out	approval	Yes	YesConfirming SA2's assumption.	approved	No
		S3‑192582	Discussion paper on MT EDT LS from SA2	Nokia, Nokia Shangahi Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑192767	Discussion on security of MSG2 MT-EDT solution	Huawei, Hisilicon	discussion	Decision	Yes	Yes	noted	No
		S3‑192768	Reply LS on Security of MT-EDT	Huawei, Hisilicon	LS out	Approval	Yes	Yes	noted	No
		S3‑192857	[DRAFT] Reply LS on Mobile-terminated Early Data Transmission	Ericsson	LS out		Yes	Yes	noted	No
		S3‑192858	Disucssion on security of MT-EDT	Ericsson	discussion		Yes	YesQualcomm, Intel: no need for message 4 solution. Nokia: we should answer both message 2 and 4 solutions.	noted	No
		S3‑192934	Discusson on SA2 LS for MT EDT	Qualcomm Incorporated	discussion	Endorsement	Yes	YesEricsson: no need to take RAN considerations here. Huawei supported this.	noted	No
		S3‑192935	Reply LS on MT EDT	Qualcomm Incorporated	LS out	Approval	Yes	Yes	noted	No
7.11.11	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)
7.11.12	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.11.13	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
7.11.14	PLMN RAT selection (Steering of Roaming) (Rel-15)	S3‑192632	Add missing message flow for Procedure for steering of UE	Intel Deutschland GmbH	CR	Agreement	Yes	YesVodafone: the bullet points now don’t reflect the change in the figure. Ericsson: is this a correction? Intel replied that this was aligned with SA2. On the other hand, this didn’t have to updated according to Release 16 changes since there was no significant impact.	revised	No	S3‑193060
		S3‑193060	Add missing message flow for Procedure for steering of UE	Intel Deutschland GmbH	CR	Agreement	Yes	Yes	agreed	No		S3‑192632
7.11.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑192579	Minor corrections to 33163	Juniper Networks	CR	Approval	Yes	Yes	revised	No	S3‑193061
		S3‑193061	Minor corrections to 33163	Juniper Networks	CR	Approval	Yes	Yes	agreed	No		S3‑192579
		S3‑192580	Minor corrections to 33163	Juniper Networks	CR	Approval	Yes	Yes	revised	No	S3‑193062
		S3‑193062	Minor corrections to 33163	Juniper Networks	CR	Approval	Yes	Yes	agreed	No		S3‑192580
		S3‑192655	Discussion Document on how to use BEST as a bearer for services and as a means to provide multiple secure channels over 1 bearer	Vodafone España SA	discussion	Discussion	Yes	Yes	noted	No
7.11.16	Other work items	S3‑192668	Removing references of TS 103 383 in TS 35.231	Orange	CR	Approval	Yes	Yes	revised	No	S3‑192982
		S3‑192982	Removing references of TS 103 383 in TS 35.231	Orange	CR	Approval	Yes	Yes	agreed	No		S3‑192668
		S3‑192669	Removing references of TS 103 383 in TS 35.231	Orange	CR	Approval	Yes	Yes	revised	No	S3‑192983
		S3‑192983	Removing references of TS 103 383 in TS 35.231	Orange	CR	Approval	Yes	Yes	agreed	No		S3‑192669
		S3‑192671	Removing references of TS 103 383 in TS 35.231	Orange	CR	Approval	Yes	Yes	revised	No	S3‑192984
		S3‑192984	Removing references of TS 103 383 in TS 35.231	Orange	CR	Approval	Yes	Yes	agreed	No		S3‑192671
		S3‑192672	Removing references of TS 103 383 in TS 35.231	Orange	CR	Approval	Yes	Yes	revised	No	S3‑192985
		S3‑192985	Removing references of TS 103 383 in TS 35.231	Orange	CR	Approval	Yes	Yes	agreed	No		S3‑192672
7.12	New Work Item proposals	S3‑192605	New WID on Security aspects of enhancements to the Service-Based 5G System Architecture	Nokia, Nokia Shanghai Bell	WID new	Agreement	Yes	YesIt was pointed out that there were open items in the study that shouldn't be included in the objectives yet (e.g. N9). NCSC preferred to have N9 interface included in the objectives. Nokia commented that if not decided for the study, a CR could cover all the N9 issues separately. The Chair clarified that even for that CR a WID would be needed as recently pointed out by SA (new features to be covered with new WIDs and not TEI16 CRs). Ericsson had issues with the objectives. This was taken offline and awating for the end of the discussions in the study.	revised	No	S3‑193055
		S3‑193055	New WID on Security aspects of enhancements to the Service-Based 5G System Architecture	Nokia, Nokia Shanghai Bell	WID new	Agreement	Yes	Yes	agreed	No		S3‑192605
		S3‑192636	WID of 5GFBS	Apple	WID new	Approval	Yes	YesOrange: there is no conclusion in the study that allows us to go for normative work. No objection to normative work for false base station, only for starting the normative work now.Qualcomm and BT were of the same opinion. NTT-Docomo proposed to postpone this until the study was finished. Qualcomm: we should focus on studying solutions and evaluating them before starting the normative work. CableLabs: lot of research papers on this, important to start normative work.	revised	No	S3‑192994
		S3‑192994	WID of 5GFBS	Apple	WID new	Approval	Yes	Yes	noted	No		S3‑192636
		S3‑192661	WID for LTE normative work for UPIP	Vodafone España SA	WID new	Agreement	Yes	YesVodafone: the SID presented for this meeting has too many changes to have the WID as it is now. Qualcomm suggested to note it since it was better to wait for the study. Vodafone commented that they would bring it for the next meeting.	noted	No
		S3‑192828	New WID on security of the enhancement to the 5GC location services	CATT	WID new	Agreement	Yes	YesVodafone: I would like to see these features as optional for the supervision of these measurements. This may have privacy issues. AT&T commented that this was not the case of a third party making use of this data. This was not a concern for this group and that would take privacy too far. Rules and regulations of a specific country were not part of this study. Colin (BT): it needs to be optional because the results can be corrupted or forged. Alf(NTT-Docomo: add privacy as an objective. Christine (Ericsson): make clear that if data is collected, that data should not be sent. Nokia replied that the UE would collect only if configured for that. It would be a deployment choice, optional. The Chair asked if there were any objections to this WID and Vodafone reiterated his comment on the privacy issue and the optionality. Marcus (Huawei): if they say in SA2 that this feature is optional, our work in here would be optional as well. Alex agreed with Vodafone, given the controversy of the topic. They didn’t mind these capabilities but not having any restrictions wouldn't be very clever. This was taken offline.	revised	No	S3‑193056
		S3‑193056	New WID on security of the enhancement to the 5GC location services	CATT	WID new	Agreement	Yes	Yes	agreed	No		S3‑192828
		S3‑192830	New WID on security aspect of network analytic services	China Mobile M2M Company Ltd.	WID new	Approval	Yes	YesVodafone: normally we should have a discussion paper presenting this or a previous study item. They saw no rush for not having a discussion paper first. Nokia: a study is not needed for this. It's about security between two network functions defined in TS 33.501. Ericsson: agree with being an usual network domain security. China Mobile: no study item needed, just small requirements and in that case we wouldn't be able to reach the release 16 deadline and we would have no security solution in this release for this issue. It was clarified that the WID could be brought to plenary together with the necessary CRs in one go in case there were timing problems. The Chair asked if any offline discussion would help. Vodafone still found problematic not being able to discuss with a paper first.	noted	No
		S3‑192859	New WID on Authentication and Key Management for Applications based on 3GPP credential in 5G	China Mobile	WID new	Approval	Yes	YesOrange: why involving SA2? China Mobile: for architecture issues. This was taken offline.	revised	No	S3‑193178
		S3‑193178	New WID on Authentication and Key Management for Applications based on 3GPP credential in 5G	China Mobile	WID new	Approval	Yes	Yes	agreed	No		S3‑192859
		S3‑192883	Work item on integrating GBA to 5GC	Ericsson, Vodafone	WID new	Approval	Yes	YesQualcomm: this is a good idea and should be kept separate from the AKMA work item. We don’t know about the impact on the ME and UICC. Vodafone: this is changing GBA specs and the AKMA WID is changing TS 33.501, so that's why they have to be separate. Huawei: no study item for this, and there are GBA functions that need consideration when treated in a service based architecture. We would need to consult SA2 about this. Ericsson replied that SA2 had looked at this and it was concluded that a Service Based Interface was needed. Vodafone clarified that this was coming from the results from the AKMA study. Nokia commented that GBA was a standalone specification in LTE. Martin (AT&T) replied that GBA would not be the same case in 5G. Qualcomm argued that the deadlines were too tight and that the WID should enter into the release 17 timeline.	revised	No	S3‑193200
		S3‑193200	Work item on integrating GBA to 5GC	Ericsson, Vodafone	WID new	Approval	Yes	Yes	agreed	No		S3‑192883
		S3‑192907	New WID on Security aspects of SEAL	Samsung	WID new	Approval	Yes	YesNokia: is this part of Release 16? Samsung: it's part of Release 16 in SA6 and CT. Vodafone: no discussion documents to support this. Why is it important to agree on this WID now if we have no documents discussing this? AT&T supported this WID and commented that the work was complete in SA6 and there was a request to do the security part. Colin (BT): representatives of vertical industries in SA6? It's hard to understand their requirements if they don’t attend 3GPP meetings. We would need their input. Samsung replied that they were there and had requirements on the security aspects. Vodafone: where is the security evaluation to be done in SA3? Nokia: ideally we would need an LS from SA6 at least to make an assesment on the security implications. Qualcomm: objectives are too broad. This had to be taken offline.	revised	No	S3‑193071
		S3‑193071	New WID on Security aspects of SEAL	Samsung	WID new	Agreement	Yes	Yes	agreed	No		S3‑192907
		S3‑192909	New WID on Security for NR Integrated Access and Backhaul	Samsung	WID new		Yes	Yes	revised	No	S3‑193073
		S3‑193073	New WID on Security for NR Integrated Access and Backhaul	Samsung	WID new	-	Yes	Yes	agreed	No		S3‑192909
		S3‑193072	Analysis of SEAL	Samsung	discussion	discussion	Yes	Yes	noted	No
8	Studies
8.1	Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)	S3‑192609	eSBA: pCR to update Evaluation of Solution #16	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193064
		S3‑193064	eSBA: pCR to update Evaluation of Solution #16	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192609
		S3‑192606	eSBA: pCR to update Solution #21	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesHuawei: no need for stateful for this scenario.	approved	No
		S3‑192607	eSBA: pCR to update Evaluation of Solution #21	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192802	Update of Solution #23 (Token-based authorization for Scenario D using stateless SeCoP)	Ericsson	pCR	Approval	Yes	YesHuawei: make sure that this is aligned with release 15. Nokia: in deployments where there are hierarchical NRFs you have to rely on an implicit trust model. In those scenarios the trust model relies on delegated trust.	approved	No
		S3‑192804	Evaluation for Solution #23 (Token-based authorization for Scenario D using stateless SeCoP)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193066
		S3‑193066	Evaluation for Solution #23 (Token-based authorization for Scenario D using stateless SeCoP)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192804
		S3‑192803	Update of Solution #24 (Token-based authorization for Scenario C using stateless SeCoP)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193067
		S3‑193067	Update of Solution #24 (Token-based authorization for Scenario C using stateless SeCoP)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192803
		S3‑192805	Evaluation for Solution #24 (Token-based authorization for Scenario C using stateless SeCoP)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193068
		S3‑193068	Evaluation for Solution #24 (Token-based authorization for Scenario C using stateless SeCoP)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192805
		S3‑192694	eSBA: new solution for NF service consumer verification during service access authorization in indirect communication scenario	Huawei, Hisilicon	pCR	Approval	Yes	YesNTT-Docomo: the solution doesn't have any value for scenarios where there are multiple SeCoPs. Nokia supported this. Ericsson: list all the disadvantages in the evaluation, otherwise we won't agree on this. An editor's note was added to address the scenarios where the solution didn’t work.	revised	No	S3‑193069
		S3‑193069	eSBA: new solution for NF service consumer verification during service access authorization in indirect communication scenario	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192694
		S3‑192612	eSBA: Add conclusion on KI #22	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson and Nokia disagreed with the conclusions for scenario D. Conflict with the following contirbution.	merged	No	S3‑193070
		S3‑192806	Conclusion of Key Issue #22 (Authorization of NF service access in indirect communication)	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193070
		S3‑193070	Conclusion of Key Issue #22 (Authorization of NF service access in indirect communication)	Ericsson,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑192806
		S3‑192815	New solution: Authorization between Network Functions in Scenario D	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192614	eSBA: Add conclusion on KI #23	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193174
		S3‑193174	eSBA: Add conclusion on KI #23	Nokia, Nokia Shanghai Bel,Ericssonl	pCR	Approval	Yes	Yes	approved	No		S3‑192614
		S3‑192816	Conclusion of Key Issue #23: NF to NF authentication and authorization in Indirect communication	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑193174
		S3‑192807	New solution: Telescopic FQDN for the SeCoP	Ericsson	pCR	Approval	Yes	YesIt was agreed to send an editor's note about the stage 3 solution for routing. The evaluation was also removed.	revised	No	S3‑193075
		S3‑193075	New solution: Telescopic FQDN for the SeCoP	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192807
		S3‑192610	eSBA: Add conclusion on KI #20	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193077
		S3‑193077	eSBA: Add conclusion on KI #20	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192610
		S3‑192813	Conclusion of Key Issue #20: Protection of SeCoP interfaces	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑192814	Conclusion of Key Issue #21: Secure message transport via the SeCoP	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193078
		S3‑193078	Conclusion of Key Issue #21: Secure message transport via the SeCoP	Ericsson	pCR	Approval	No	Yes	approved	No		S3‑192814
		S3‑192688	Dealing with the EN of solution #19 in TR33.855	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192689	New solution for authorization within a NF Set in the roaming scenario	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192808	New solution: Token-based authorization for NF Sets / NF Service Sets by existing methods	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193079
		S3‑193079	New solution: Token-based authorization for NF Sets / NF Service Sets by existing methods	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192808
		S3‑192628	eSBA: Add conclusion on KI #24	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesIt was concluded that info from SA2 was needed, hence no conclusion was to be obtained during the present meeting.	noted	No
		S3‑192809	Conclusion of Key Issue #24 (Service access authorization within a NF Set or a NF Service Set)	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑192811	Update of Key issue #26: Protection of N9 interface	Ericsson	pCR	Approval	Yes	YesJuniper,China Mobile supported this. There was no clear requirement.	approved	No
		S3‑192860	Resolving EN in 33855 6.18 N9 NDS/IP	Juniper Networks	pCR	Agreement	Yes	Yes	noted	No
		S3‑192611	eSBA: Add conclusion on KI #26	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesChina Mobile: no difference between this and the current requirement in 33.501. Nokia: we need to make changes to cover this interface. China Mobile disagreed and added that it was already covered. Juniper: it’s written somewhere else that we need to rewrite the requirement. Ericsson: better clarify that this applies to the roaming interface.	revised	No	S3‑193081
		S3‑193081	eSBA: Add conclusion on KI #26	Nokia, Nokia Shanghai Bell, Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑192611
		S3‑192810	Conclusion of Key Issue #26: Protection of N9 interface	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑193081
		S3‑192818	UP Gateway deployments	Ericsson	pCR	Approval	Yes	YesHuawei: we need feedback from SA2 for the deployment options and see if there are any security concerns in them. Deustche Telekom supported querying SA2. China Mobile as well. Revised to add some editor's notes.	revised	No	S3‑193082
		S3‑193082	UP Gateway deployments	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192818
		S3‑192629	eSBA: Add conclusion on KI #27	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesChina Mobile: too early for this conclusion. We need to check with sA2. Alex (BT): SA asked to finish this in release 15 and it's delaying deployments. Christine (Ericsson) suggested to add abullet list in the conclusion. This was revised to introduce these changes. Alf (NTT-Docomo): conclude now and send an LS to SA2. This is not normative. China Mobile: I don’t think this solution is solving the problem. Deutsche Telekom: We need a solution and we have several of them available. It's not for SA3 to decide alone and we can get feedback from SA2 on the available solutions. A number was given for a possible LS to SA2 and this was taken offline.	revised	No	S3‑193095
		S3‑193095	eSBA: Add conclusion on KI #27	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192629
		S3‑192687	Update of solution #15 in TR 33.855	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: the evaluation needs to show the disadvantages of the solution as well. This was taken offline.	revised	No	S3‑193097
		S3‑193097	Update of solution #15 in TR 33.855	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192687
		S3‑192812	Conclusion of Key Issue #28: Service access authorization in the delegated "Subscribe-Notify" scenarios	Ericsson	pCR	Approval	Yes	YesHuawei and Nokia didn’t agree with the conclusion.	noted	No
		S3‑192608	eSBA: pCR to update Evaluation of Solution #26	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192817	New Solution: resource level authorization using access tokens	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193098
		S3‑193098	New Solution: resource level authorization using access tokens	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192817
		S3‑192613	eSBA: Add conclusion on KI #29	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193099
		S3‑193099	eSBA: Add conclusion on KI #29	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192613
		S3‑192693	Resolving the ENs in Solution #25	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: benefit to the existing solution should be clarified in the evaluation.	revised	No	S3‑193100
		S3‑193100	Resolving the ENs in Solution #25	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192693
		S3‑192531	Resolving EN in 33855 6.18 N9 NDS/IP	Juniper Networks	pCR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑193065	Draft TR 33.855	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
		S3‑193076	LS to CT4 on ESPA using indirect communication	NTT-Docomo	LS out	Approval	Yes	Yes	approved	No
		S3‑193080	LS to SA2 on ESPA NF sets	NTT-Docomo	LS out	Approval	Yes	Yes	approved	No
		S3‑193096	LS to SA2 on UP gateway function	Deutsche Telekom	LS out	Approval	Yes	Yes	approved	No
8.2	Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
8.3	Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)	S3‑192753	Implicite AKMA authenticaiton procedure	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192884	Evaluation of solution 13	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192885	Solution #15 updates including evaluation update	Ericsson	pCR	Approval	Yes	YesVodafone: nowhere it's said whether the solution is good or bad. No advantages or disadvantages. Added an editor's note for this.	revised	No	S3‑193169
		S3‑193169	Solution #15 updates including evaluation update	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192885
		S3‑192675	Discussion on the conclusion of AKMA architecture and authentication procedures	China Mobile, Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑192677	Conclusion on AKMA architecture and authentication procedure	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesCompeting solution with 886. The Chair asked for a show of hands: - Reusing KAUSF based solution: KPN, Orange, Samsung, Qualcomm, Nokia, China Mobile,Huawei,BT (tdoc 677) --> 9 companies. - Not reusing KAUSF (tdoc 886): Vodafone, Ericsson, CableLabs. --> 3 It was agreed to remove solution 2. Huawei had a solution overlapping with this contribution. Qualcomm proposed to focus on this for the next meeting.	revised	No	S3‑193170
		S3‑193170	Conclusion on AKMA architecture and authentication procedure	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192677
		S3‑192886	Conclusion for AKMA architecture and authentication	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑192564	Resolving Editor’s Notes and adding conclusion to solution #20	NEC Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑192565	conclusion for KI #9	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑192566	conclusion for KI #15	NEC Corporation	pCR	Approval	Yes	YesQualcomm and Nokia didn’t agree with the text.	noted	No
		S3‑192788	Resovle Editor's notes in Solution for Key freshness in AKMA	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: why using RAND? This was removed.	revised	No	S3‑193171
		S3‑193171	Resovle Editor's notes in Solution for Key freshness in AKMA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192788
		S3‑192521	Corrections for TR 33.835	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑192532	New KI for TR 33.835 - roaming environment	InterDigital Communications	pCR	Approval	Yes	YesEricsson: Anchor is in home network; is the roaming meaningful here? Also, remove second requirement. Qualcomm: we just concluded the architecture we are going to use, and this is not the architecture we agreed to conclude. I question the whole key issue but we can look at this in the normative work. Colin (BT) didn’t find it necessary. There is still home control. Orange was happy with the requirements and they could go to general requirements clause so they didn’t depend on the solution. They were useful for the normative work. It was commented that the requirements still needed work.	noted	No
		S3‑193172	New KI for TR 33.835 - roaming environment	InterDigital Communications	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑192537	New KI for TR 33.835 – environments where a UICC, or a SIM card, is not available to subscribers	InterDigital Communications	pCR	Approval	Yes	YesOrange, Vodafone objected to this contribution. Nokia supported it.	noted	No
		S3‑192539	New KI for TR 33.835 – browser environment	InterDigital Communications	pCR	Approval	Yes	YesQualcomm: AKMA is designed to use with any application, we don’t need to specify the browser in particular.	noted	No
		S3‑192691	Resolving the EN in AKMA push, and adding the evaluation	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192853	Conclusion on key issue #2	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑192854	Evaluation of solution #6	China Mobile M2M Company Ltd.	pCR	Approval	Yes	Yes	not treated	No
		S3‑192855	Evaluation of solution#1	China Mobile M2M Company Ltd.	pCR	Approval	Yes	Yes	not treated	No
		S3‑192856	Evaluations of solution #7- #12	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑192881	New solution: Integrating GBA to 5GC	Ericsson, Vodafone	pCR	Approval	Yes	Yes	not treated	No
		S3‑192882	New conclusions for GBA in 5GC	Ericsson, Vodafone	pCR	Approval	Yes	Yes	not treated	No
		S3‑192664	Discussion on the conclusion of AKMA architecture and authentication procedures	China Mobile M2M Company Ltd.	discussion	Endorsement	No	Yes	withdrawn	Yes
		S3‑192674	Conclusion on AKMA architecture and authentication procedure	China Mobile M2M Company Ltd.	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑193168	Draft TR 33.835	China Mobile	draft TR	Approval	No	Yes	left for email approval	No
		S3‑193177	Cover sheet for TR 33.835 information	China Mobile	TS or TR cover	Approval	Yes	Yes	approved	No
8.4	Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)	S3‑192957	Manufacture Usage Description Discussion	NIST, ATT, SPRINT, CABLE LABS, CISCO	discussion	Discussion	Yes	Yes	noted	No
		S3‑192916	New KI: Botnet threats caused from improper CIOT device usage	NIST, ATT, SPRINT, CABLE LABS, CISCO	pCR	Approval	Yes	YesHuawei: no need for the key issue and the requirement is too solution-specific. This is conflicting/overlapping with key issue 4. Colin (BT): how are devices identified? CableLabs: this is additional info on the device. Identification is not an issue here. Qualcomm: this is not specific to 3GPP access, not sure if this is in scope. We need something to establish trust between device and capabilities otherwise it can be compromised.	revised	No	S3‑193101
		S3‑193101	New KI: Botnet threats caused from improper CIOT device usage	NIST, ATT, SPRINT, CABLE LABS, CISCO	pCR	Approval	Yes	Yes	approved	No		S3‑192916
		S3‑192769	Address EN in key issue 13 and solution 20	Huawei, Hisilicon	pCR	Approval	Yes	YesMCC commented that the change still had the same meaning as an editor's note. Ericsson commented that the first editor's note should stay in order to follow SA2's work. NTT-Docomo also wanted to keep it since it was an outstanding issue that needed to be addressed.	revised	No	S3‑193102
		S3‑193102	Address EN in key issue 13 and solution 20	Huawei, Hisilicon	pCR	Approval	Yes	YesRemoval of the last editor's note only.	approved	No		S3‑192769
		S3‑192895	Evaluation to Sol#4	Ericsson, Intel	pCR	Approval	Yes	YesQualcomm suggested some rewording in the last paragraph.	revised	No	S3‑193104
		S3‑193104	Evaluation to Sol#4	Ericsson, Intel	pCR	Approval	Yes	Yes	approved	No		S3‑192895
		S3‑192967	Clarification in Solution 12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192747
		S3‑192538	Proposal for editor's note in FS_CIoT_sec_5G solution #15	Philips International B.V.	pCR	Approval	Yes	Yes	approved	No
		S3‑192773	Address EN in solution 19	Huawei, Hisilicon	pCR	Approval	Yes	YesEricssson: add statement in the efficiency part about the solution based on this.	revised	No	S3‑193105
		S3‑193105	Address EN in solution 19	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192773
		S3‑192939	Evaluation of Solution 20: RRC Reestablishment in RLF	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑192771	Address EN in solution 21	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192960	New Solution for botnet threats caused by improper CIOT device usage	NIST, ATT, Sprint, Cable Labs, Cisco	pCR	Approval	Yes	Yes	noted	No		S3‑192948
		S3‑192789	Mitigate DDoS Attack on RAN based on RAN coordination	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: editor's note on synchronising the list in RAN.	revised	No	S3‑193106
		S3‑193106	Mitigate DDoS Attack on RAN based on RAN coordination	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192789
		S3‑192897	CIOT: New solution for UP IP in PDCP to protect UL EDT data in Msg3	Ericsson, Qualcomm Incorporated,Intel	pCR	Approval	Yes	Yes	approved	No
		S3‑192898	CIOT: New solution for protection of NAS Redirection message	Ericsson	pCR	Approval	Yes	YesHuawei: editor's note on signalling overhead.	revised	No	S3‑193107
		S3‑193107	CIOT: New solution for protection of NAS Redirection message	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192898
		S3‑192651	Proposal for Key Issue#1 Conclusion	Philips International B.V.	pCR	Approval	Yes	YesEricsson: Change in PDCP makes it complicated. We don’t support this.	noted	No
		S3‑192896	Conclusion on KI#2	Ericsson, Qualcomm Incorporated, Intel	pCR	Approval	Yes	YesMCC commented that the text read like an editor's note, but it was fine as long as this was updated once the study in 33.853 was concluded as the text said.	approved	No
		S3‑192774	Discussion on Mitigation of DDoS attack	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑192518	Conclusion for KI#4	KPN, Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192894	Conclusion on KI#4	Ericsson, Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑192893	Conclusion on KI#5	Ericsson, Qualcomm Incorporated	pCR	Approval	Yes	YesNokia supported this conclusion.	noted	No
		S3‑192790	conclusion on KI#5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192772	Conclusion for Key Issue #11	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson preferred to wait for the next meeting since they had a competing solution.	noted	No
		S3‑192770	Conclusion for Key Issue #13	Huawei, Hisilicon	pCR	Approval	Yes	YesQualcomm: remove the second paragraph.	revised	No	S3‑193108
		S3‑193108	Conclusion for Key Issue #13	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192770
		S3‑193103	Draft TR 33.861	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
8.5	Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)	S3‑192604	Reply LS on Wireline Access Security Requirements	CableLabs	LS out	Approval	Yes	YesEricsson: there is a typo in BBF's LS, as they refer to security requirements in 23.501. CableLabs clarified that they were an organization with several operators as members. Colin (BT): we have to add requirements ourselves for this.	revised	No	S3‑192981
		S3‑192981	Reply LS on Wireline Access Security Requirements	CableLabs	LS out	Approval	Yes	Yes	approved	No		S3‑192604
		S3‑192754	Address two Editor’s Note of solution 4	Huawei, Hisilicon	pCR	Approval	Yes	YesTelecom Italia: Is W-5GAN something other than a network element? Where is the calculation described performed? Huawei: We agreed last meeting that W-5GAN will construct the SUCI. It is defined in SA2 as a network element. Ericsson: this is not exactly the agreement we had. Just remove the editor's note and don’t add new text since it is covered somewhere else.	revised	No	S3‑193109
		S3‑193109	Address two Editor’s Note of solution 4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192754
		S3‑192755	Address two Editor’s Note of solution 6	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192796	Removal of EN in Solution #7	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192799	Editorial changes to Solution #7	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192800	Evaluation of Solution #7	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑193111	Evaluation of Solution #7	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑192756	Address an Editor’s Note and add evaluation for solution 7	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: you need keys and integrity protection.	noted	No
		S3‑192757	Add evaluation for solution 8	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: DTLS is also used. Huawei:it's part of the NDS/IP in the same clause as 33.501. Nokia: what is the evaluation if it is only stating what's in the solution? Huawei: this wording is used everywhere else in the TR.	approved	No
		S3‑192795	Conclusion for KI#7 and KI#8	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192758	Add conclusion for KI#2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑193112
		S3‑193112	Add conclusion for KI#2	Huawei, Hisilicon	pCR	Approval	Yes	YesOnly first change is kept.	approved	No		S3‑192758
		S3‑192798	Conclusion on KI#9	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192797	Conclusion on KI#15	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193192
		S3‑193192	Conclusion on KI#15	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192797
		S3‑192759	completing TR 33807	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑193110	Draft TR 33.807	Huawei	draft TR	Approval	No	Yes	left for email approval	No
		S3‑193179	Cover sheet TR 33.807 for approval	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
8.6	Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)	S3‑192583	Addressing EN in PARLOS Evaluation clause 7.2.3	Nokia, Nokia Shangahi Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193118
		S3‑193118	Addressing EN in PARLOS Evaluation clause 7.2.3	Nokia, Nokia Shangahi Bell	pCR	Approval	Yes	YesChanges in the evaluation clause were kept. The solution changes are merged in 114 as suggested by Qualcomm.	approved	No		S3‑192583
		S3‑192747	Clarification in Solution 12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192967
		S3‑192913	P-CR: Editorial cleanup of editor's notes	Sprint Corporation	pCR	Agreement	Yes	Yes	approved	No
		S3‑192943	A solution to providing some network authorisation in PARLOS	Qualcomm Incorporated	pCR	Approval	Yes	YesVodafone: we need some kind of warning to the user about the service. NTT-Docomo: we can warn the customers by other means (like recommending them to remove the USIM).	revised	No	S3‑193114
		S3‑193114	A solution to providing some network authorisation in PARLOS	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑192943
		S3‑192944	Proposed conclusion on providing some network authorisation in PARLOS	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑193116
		S3‑193116	Proposed conclusion on providing some network authorisation in PARLOS	Qualcomm Incorporated,Spring	pCR	Approval	Yes	Yes	approved	No		S3‑192944
		S3‑192945	Security aspects of RLOS	Qualcomm Incorporated	other	Discussion	Yes	Yes	noted	No
		S3‑192962	P-CR: Proposed conclusion for PARLOS	Sprint Corporation	pCR	Agreement	Yes	Yes	merged	No	S3‑193116
		S3‑192964	P-CR: Proposed recommendations for PARLOS	Sprint Corporation	pCR	Agreement	Yes	Yes	merged	No	S3‑193116
		S3‑193117	P-CR: Proposed recommendations for PARLOS	Sprint Corporation	pCR	Agreement	No	Yes	withdrawn	Yes
		S3‑192965	pCR to 33.815 clarifying requirements on Parlos	DOCOMO Communications Lab.	pCR	Approval	Yes	YesSprint: leave it to the regulator to block it or not. NTT-Docomo: we cannot leave it to regulators from the IMSI side. Change It so you don’t mention a particular country.	revised	No	S3‑193115
		S3‑193115	pCR to 33.815 clarifying requirements on Parlos	DOCOMO Communications Lab.	pCR	Approval	Yes	Yes	approved	No		S3‑192965
		S3‑192966	Proposed presentation cover sheet for PARLOS 33.815	Sprint Corporation	TS or TR cover	Agreement	Yes	Yes	approved	No
		S3‑193113	Draft TR 33.815	Sprint	draft TR	Approval	No	Yes	left for email approval	No
8.7	Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)	S3‑192778	Wayforward for TR 33.809	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑192863	Way forward - KI#1 Proposal#1 UE caps	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung, Apple	pCR	Approval	Yes	YesIt was clarified that no additonal normative work is needed since this had been taken care of in a CR for TS 33.501. This was introduced in the conclusion.	revised	No	S3‑193173
		S3‑193173	Way forward - KI#1 Proposal#1 UE caps	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung, Apple	pCR	Approval	Yes	Yes	approved	No		S3‑192863
		S3‑192734	Address EN in solution #1	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192642	Protection of UeapabilityInformation	Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192780	Address EN in solution 16	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192864	Way forward - KI#1 Proposal#2 RRC reject	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Apple	pCR	Approval	Yes	YesSamsung preferred to keep this open until the next meeting. They didn't agree with the evaluation. Qualcomm: put the evaluation in the solution, it's not part of the text now. Qualcomm: the point is to add the reason why we got to this conclusion with a proper evaluation, especially for external readers who may come with additional papers in the future.They were OK with the conclusion but just wanted to add some more text into the conclusion part from the analysis. Huawei didn’t agree with this contribution.	noted	No
		S3‑192779	Discussion on Conclusion for Protection of RRC Reject message	Huawei, Hisilicon	discussion	Decision	Yes	Yes	noted	No
		S3‑192781	Conclusion for Key Issue #1 for RRC Reject	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192782	LS to RAN2 on Protection of RRC Reject Message	Huawei, Hisilicon	LS out	Approval	Yes	Yes	not treated	No
		S3‑192949	Resolving EN on New and Last serving gNB interactions	Samsung	pCR	Approval	Yes	YesApple: we need more time to evaluate the solution.	noted	No
		S3‑192865	Way forward - KI#1 Proposal#3 RRC Resume	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Apple	pCR	Approval	Yes	YesQualcomm: we don’t have a solution for this way forward. I agree with this conclusion, but the solution was removed. Orange agreed.	noted	No
		S3‑192783	Update on Protection of RRC Resume Request message	Huawei, Hisilicon	pCR	Approval	Yes	YesApple didn't agree with the solution.	noted	No
		S3‑192784	Conclusion for Key Issue #1 for RRC Resume Request Protection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192950	Solution for Resumecause protection	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192785	Solution for Protection of NAS Reject Message	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson and Qualcomm didn't agree: NAS messages from the serving network is a bit weird.	noted	No
		S3‑192786	Conclusion for Key Issue #1 for NAS Reject	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192637	Conclusin of key issue#2	Apple	pCR	Approval	Yes	YesCompeting with 791 and 866. Qualcomm asked to have a better description of the solutions in order to decide better, not a rushed conclusion should be done. Orange: specially if the solution chosen has security issues. The Chair asked for a show of hands for the support of this document: CableLabs, Apple,BT,Ericsson,Philips. Then the Chair asked for another show of hands: No support of concluding now key issue #2: Orange, Qualcomm, Huawei. NTT-Docomo,Nokia, Vodafone, Deutsche Telekom. Who wants to conclude key issue #2: ZTE, Samsung,Ericsson, Apple, Intel.	noted	No
		S3‑192791	conclusion on KI#2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192866	Way forward - KI#2 Proposal#4 SI protection	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, AT&T, NIST, CATT, China Unicom, Apple, Samsung	pCR	Approval	Yes	YesQualcomm: we cannot reach a conclusion now, it's premature. We like the Huawei approach, but this needs further analysis. Orange: in this case we have several several solutions with advantages and disadvantages, it’s not like the AKMA situation.	noted	No
		S3‑193140	Way forward - KI#2 Proposal#4 SI protection	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, AT&T, NIST, CATT, China Unicom, Apple, Samsung	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑192951	Updates to Solution#7 on obtaining accurate clock information	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192952	Deletion of EN on Location update reject in Solution#7	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192585	FBS add text to evaluation clause 6.7.3	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑192638	Update for Solution#7	Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192620	Assessment and evaluation of solution #9	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑192643	Update of Solution#11	Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192639	Evaluation for solution#14	Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192938	Evaluation of the shared key based MIB/SIB protection	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No		S3‑191922
		S3‑192968	The solution to protect MIB/SIB information	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No		S3‑192748
		S3‑192936	Alternative shared key based MIB/SIB protection	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No
		S3‑192867	Way forward - KI#3 Proposal#5 False RBS detection	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics	pCR	Approval	Yes	YesNTT-Docomo: not a conclusion Just send the LS and then write the conclusion. Qualcomm: we already have an informative annex in 33.501. What's the value of this here without an evaluation? UE-based approaches, network-based approaches in the market already, we need to be more informative about this. Qualcomm: RAN will not give us an useful answer for an LS. A draft LS was available in tdoc 739.	noted	No
		S3‑192740	Conclustion for Key issue #3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192739	LS to RAN2 on FBS detection	Huawei, HiSilicon	LS out	Approval	Yes	YesNTT-Docomo found this OK. Huawei clarified that the two solutions would be attached to the LS. Orange: study not finished, make it clear that more solutions may be available and these are not the final options. Qualcomm: are we asking RAN2 to evaluate the solutions? Huawei replied that this was not a security issue. Qualcomm replied that no questions were asked but an evaluation was being asked. The Chair commented that this had been done in the past.	revised	No	S3‑193175
		S3‑193175	LS to RAN2 on FBS detection	Huawei, HiSilicon	LS out	Approval	Yes	Yes	approved	No		S3‑192739
		S3‑192731	Solution#4: resolving EN network verification of the hashes of MIB/SIBs	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192732	Solution#4: Resolving EN Impact on UE power consumption	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192733	Solution #4: Details on the hash algorithm used for MIB/SIB hashes.	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192787	Solution for Avoiding UE connecting to False Base Station during Conditional Handover	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192868	Way forward - KI#3 Proposal#6 False RBS handover	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192633	Security solution for UE to avoid connecting to the false base station during a handover procedure	Intel Deutschland GmbH	pCR	Approval	Yes	Yes	not treated	No
		S3‑192729	Resolve EN "signaling details of how the UE hands over to false base station	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192730	Resolve the second and third EN in Solution #6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192738	Evaluation of solution #6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192735	Enabling UE to detect FBS	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192736	preventing the UE from reselecting to the false base station	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192737	Avoiding UE from Suffering More MitM Attacks by Handover	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192869	Way forward - KI#4 Proposal#7 SON poisoining	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics	pCR	Approval	Yes	Yes	not treated	No
		S3‑192686	Conclusion on KI#5 of TR 33.809	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192870	Way forward - KI#5 Proposal#8 Auth replay	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung, Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192685	Resolving the ENs in solution #5	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	not treated	No
		S3‑192743	Update of Solution #15	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	not treated	No
		S3‑192871	Way forward - KI#6 Proposal#9 radio jamming	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Apple, Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192872	Way forward - KI#7 Proposal#10 MitM	Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192937	Evaluation against MitM false base station attacks	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	not treated	No
		S3‑192640	5G paging security issue caused by false base station	Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192641	solution for new key issue of 5G paging security issue caused by false base station	Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192644	Meeting minutes of 5GFBS July conference call on July 18th	Apple	discussion	Information	Yes	Yes	not treated	No
		S3‑192645	Meeting minutes of 5GFBS August conference call on August 8th	Apple	discussion	Information	Yes	Yes	not treated	No
		S3‑193176	Draft TR 33.809	Apple	draft TR	Approval	No	Yes	left for email approval	No
8.8	Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)	S3‑192852	Reference syntax updates	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192829	Modification of solution#1	China Mobile	pCR	Approval	Yes	YesThis scenarion was not covered earlier. No need to address it right now. Interdigital: SA1 is covering this now in a WID (LUCIA). Orange: this is going beyond slices, and some part of this may be covered by SA5. SA2 will handle LUCIA in their own WID and then SA3 will create a WID based on what SA2 is doing.	noted	No
		S3‑192718	Adding evalution to solution 3	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: slice specific authentication doesn’t depend on NSaaS.	noted	No
		S3‑192746	User ID privacy	Lenovo, Motorola Mobility, Huawei	discussion	Approval	Yes	Yes	noted	No
		S3‑192742	Removal of Editor’s Notes of solution #5	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesNokia: no solutions are offered but editor's notes are gone. Orange: keep the editor's notes. Ericsson: the serving network is trusted, that's the asssumption. Keep the first editor's note at least. Qualcomm preferred to keep the editor's notes.	noted	No
		S3‑192720	Addressing EN in solution 6	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia didn’t agree with the removal of the editor's note. Orange commented that there was a mismatch between the editor's note and the justification.No mechanism can be defined without an interface defined in 3GPP. Potential additional text to help resolving the editor's note was taken offline.	revised	No	S3‑193120
		S3‑193120	Addressing EN in solution 6	Huawei, HiSilicon	pCR	Approval	No	Yes	noted	No		S3‑192720
		S3‑192721	Adding evalution to solution 6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192848	Adding evaluation to Solution 7	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193121
		S3‑193121	Adding evaluation to Solution 7	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192848
		S3‑192722	Addressing ENs in solution 8	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192584	Update to Solution 8 protecting NSSAI in AS layer	Nokia, Nokia Shanghai Bell, Ericsson	pCR	Approval	Yes	YesHuawei only agreed with the first paragraph. This was kept in the revision.	revised	No	S3‑193122
		S3‑193122	Update to Solution 8 protecting NSSAI in AS layer	Nokia, Nokia Shanghai Bell, Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192584
		S3‑192931	Resolving editor’s notes on solution #10 in TR 33.813	Qualcomm Incorporated	pCR	Approval	Yes	YesOn the yellow text; Ericsson commented that management will be very complex.	revised	No	S3‑193123
		S3‑193123	Resolving editor’s notes on solution #10 in TR 33.813	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑192931
		S3‑192528	TR 33.813 - update for solution #11	InterDigital Communications	pCR	Approval	Yes	YesHuawei: third paragraph not OK. Nokia:in the solution part. all base stations under one AMF need to know all these hash values for routing the NAS messages to a particular AMF. Interdigital replied that it was by an update in the provisioning. It was decided to add an editor's note under step 5. Qualcom proposed to remove the first paragraph.	revised	No	S3‑193124
		S3‑193124	TR 33.813 - update for solution #11	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑192528
		S3‑192627	Solution on privacy protection of NSSAI	ZTE Corporation	pCR	Approval	Yes	YesOrange: add editor's notes on Home network control performance, how allocation of T-NSSAI is made. Interdigital: editor's note on effectiveness with idle mobility.	revised	No	S3‑193125
		S3‑193125	Solution on privacy protection of NSSAI	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑192627
		S3‑192719	Conclusions to KI #3	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192725	Conclusions to KI #4	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192723	Conclusions to KI #6	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192851	Conclusion on KI#6	Ericsson, Nokia	pCR	Approval	Yes	Yes	noted	No
		S3‑192849	Discussion on AUSF role	Ericsson	discussion	Endorsement	Yes	YesQualcomm: this is not a security issue. Ericsson: we agreed to use something and SA2 has agreed to use something else. Nokia checked with SA2 colleagues and they replied that they did it for the routing in roaming situations. Lenovo agreed with Ericsson.	noted	No
		S3‑192850	Draft LS on AUSF role	Ericsson	LS out	Approval	Yes	YesZander (Huawei): I agree that there is no security reason behind having the AUSF. Qualcomm added that there was no security either with including it. Marcus (Futurewei): the AUSF could introduce security problems, we don’t know. This had to be taken offline; there was disagreement on the possibility of security issues due to introducing the AUSF.	revised	No	S3‑193126
		S3‑193126	LS on AUSF role	Ericsson	LS out	Approval	Yes	Yes	approved	No		S3‑192850
		S3‑192744	New Key Issue on Rejected S-NSSAI Revokation	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesZander (Huawei): it's about cancelation not revocation. This is misleading. Nokia: no standardised procedure when the primary authentication is cancelled, why do we have it here? Vodafone favoured having this key issue, whereas Interdigital had some concerns. Ericsson: if this is stage 3 issue as Lenovo said, why is this being treated here? Lenovo replied that it touched authentication issues. Nokia: we cannot mandate a particular behaviour in this scenario. It was taken offline to see if it was possible to add an editor's note to reach an agreement.	revised	No	S3‑193201
		S3‑193201	New Key Issue on Rejected S-NSSAI Revokation	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑192744
		S3‑192745	Solution on Slice Authentication Revokation	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	noted	No
		S3‑192724	Amendment to eNS WID	Huawei, HiSilicon	pCR	Approval	Yes	YesZander(Huawei) commented that key issue 3,4 and 6 were to be removed. This was intended to conclude the WID. The vice chair (NTT-Docomo) commented that this seemed to be content for the WID summary input hat is usually sent to plenary to describe work items. No need to update the WID after the work has been done. It was clarified that this was an update of the WID agreed in Sapporo and that it hadn't been seen in SA plenary yet. Orange: why the key issues in a WID? We never do this. Vodafone: reject this document, we have a WID already.	noted	No
		S3‑193119	Draft TR 33.813	Nokia	draft TR	Approval	No	Yes	left for email approval	No
8.9	Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)	S3‑192676	Complete the Evaluation for Solution #4	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesVodafone: not clear if you are recommending it or rejecting it.	revised	No	S3‑193127
		S3‑193127	Complete the Evaluation for Solution #4	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192676
		S3‑192971	conclusion on KI#4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No		S3‑192751
		S3‑192678	Conclusion on Key Issue #4	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192822	Draft CR as a living baseline for 5GS LCS normative work	Ericsson	draftCR	Approval	Yes	YesIt was clarified that this was merely for information. Qualcomm commented that a separate specification may be needed instead and that the level of details for stage 3 parameters was too high. The vice Chair (NTT-Docomo) clarified that there was a WID for the current meeting and this could be a possible output for that WID.	noted	No
		S3‑192748	The solution to protect MIB/SIB information	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192968
		S3‑193128	Draft TR 33.814	CATT	draft TR	Approval	No	Yes	left for email approval	No
		S3‑193129	Cover sheet TR 33.814 for approval	CATT	TS or TR cover	Approval	Yes	Yes	approved	No
8.10	Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)	S3‑192765	Completing 33825	Huawei, Hisilicon	pCR	Approval	Yes	YesTelecom Italia: why is the editor's note converted into a note? Huawei replied that there was no conclusion about that in the study. Colin (BT): low latency specific work hasn’t been done in this document.	approved	No
		S3‑193130	Draft TR 33.825	Huawei	draft TR	Approval	No	Yes	left for email approval	No
		S3‑193131	Cover sheet 33.825 for approval	Huawei	TS or TR cover	Approval	Yes	Yes	approved	No
8.11	Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)	S3‑192832	Adding gap analysis into clause 4.3.1	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑192834	Adding contents into clause 4.4	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑192835	Adding contents into clause 4.5	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑192836	Resolving editor’s note and adding example of role instantiation into clause 4.6	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑192837	Adding contents into clause 4.7	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑192838	Adding contents into clause 4.8	China Mobile	pCR	Approval	Yes	Yes	revised	No	S3‑193181
		S3‑193181	Adding contents into clause 4.8	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑192838
		S3‑192839	Adding contents into clause 4.8	China Mobile M2M Company Ltd.	pCR	Approval	Yes	Yes	approved	No
		S3‑192840	Adding writing process overview into clause 5.1	China Mobile M2M Company Ltd.	pCR	Approval	Yes	Yes	approved	No
		S3‑192841	Adding the description of the parts in SCAS documents and ToE into clause 5.2.1 and 5.2.2	China Mobile M2M Company Ltd.	pCR		Yes	Yes	revised	No	S3‑193182
		S3‑193182	Adding the description of the parts in SCAS documents and ToE into clause 5.2.1 and 5.2.2	China Mobile M2M Company Ltd.	pCR	-	Yes	Yes	approved	No		S3‑192841
		S3‑192842	Adding the description of Generic Vitualized Network Product model of type 1	China Mobile	pCR	Approval	Yes	YesFuturewei suggested to update the figure in the future for more accuracy, and this was added in an editor's note. Nokia: FFS how ETSI defined interfaces are mapped to 3GPP interfaces. CableLabs: add references where the ETSI interfaces are explained.	revised	No	S3‑193183
		S3‑193183	Adding the description of Generic Vitualized Network Product model of type 1	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑192842
		S3‑192843	Adding the description for generic virtualized network product model of type 2	China Mobile M2M Company Ltd.	pCR	Approval	Yes	Yes	revised	No	S3‑193184
		S3‑193184	Adding the description for generic virtualized network product model of type 2	China Mobile M2M Company Ltd.	pCR	Approval	Yes	Yes	approved	No		S3‑192843
		S3‑192844	Adding the description for generic virtualized network product model of type 3	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑192845	Adding SPD for virtualized network products into clause 5.2.3	China Mobile M2M Company Ltd.	pCR	Approval	Yes	Yes	not treated	No
		S3‑192846	Adding Generic assets and threats of GVNP for type 2 into clause 5.2.3.3	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑192847	Adding Generic assets and threats of GVNP for type 3 into clause 5.2.3.4	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑193180	Draft TR 33.818	China Mobile	draft TR	Approval	No	Yes	left for email approval	No
8.12	Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)	S3‑192594	TR33.819 update as baseline - editorial	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192595	Adding intro to 33.819	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesThe introducion needed rewording.	noted	No
		S3‑192598	Secure device identity creation for UEs in SNPNs	Nokia, Nokia Shanghai Bell, Perspecta Labs, Interdigital	pCR	Approval	Yes	Yes	noted	No
		S3‑192599	Key issue on Secure device identity creation for constrained devices	Nokia, Nokia Shanghai Bell, Perspecta Labs, Interdigital	pCR	Approval	Yes	YesOrange: secure somethng we don’t know the nature of. Not keen on having this key issue. Gemalto: key issue details are solution specific and I support Orange. Other comments: Non-3GPP identities, difficult to define them. Not known about the identity, we cannot state how to secure it. There were 4 companies objecting, 5 companies supporting. This was taken offline.	revised	No	S3‑193193
		S3‑193193	Key issue on Secure network credentials creation for constrained devices	Nokia, Nokia Shanghai Bell, Perspecta Labs, Interdigital	pCR	Approval	Yes	Yes	noted	No		S3‑192599
		S3‑192596	TSC update	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192597	TSC key issue on time synchronization	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesBT: what is confidentiality protection doing here if it is not plain text? It's not doing much.	revised	No	S3‑193133
		S3‑193133	TSC key issue on time synchronization	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192597
		S3‑192953	Conclusion to Key Issue #6.1	Samsung	pCR	Approval	Yes	YesInterdigital: too early for this conclusion. Ericsson agreed about the conclusion.	revised	No	S3‑193134
		S3‑193134	Conclusion to Key Issue #6.1	Samsung	pCR	Approval	Yes	YesEvaluation change stayed.	approved	No		S3‑192953
		S3‑192526	TR 33.819 - DH based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	YesEricsson: effectiveness of the solution against false base stations needs to be evaluated as well. This was added in an editor's note. Qualcomm: Adding Diffie Hellman undermines the security of broadcast. CableLabs: best if you send a hash of CAG ID. NCSC reminded that using Diffie Hellman is not quantum safe. It was revised in order to add a number of editor's notes to address all comments.	revised	No	S3‑193135
		S3‑193135	TR 33.819 - DH based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑192526
		S3‑192527	TR 33.819 - hash based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	Yes	revised	No	S3‑193136
		S3‑193136	TR 33.819 - hash based solution for CAG ID privacy	InterDigital Communications	pCR	Approval	Yes	YesAdding several editor's notes addressing Huawei's comments.	approved	No		S3‑192527
		S3‑192529	TR 33.819 - Update for solution 9	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No
		S3‑192954	New solution for CAG ID privacy	Samsung,Intel	pCR	Approval	Yes	YesIntel supported this contribution.	approved	No
		S3‑192619	Security solution for CAG	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑192690	Solution for CAG ID protection	Huawei, Hisilicon	pCR	Approval	Yes	YesInterdigital: not sure if this is compatible with existing SA2 procedures. An editor's note was added for this.	revised	No	S3‑193141
		S3‑193141	Solution for CAG ID protection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192690
		S3‑192928	Solution for the privacy protection of CAG ID using NAS signalling	Qualcomm Incorporated	pCR	Approval	Yes	YesQualcomm wanted to send an LS to SA2 so they could check the solution. It was too early for this for Samsung.	approved	No
		S3‑193142	LS on sending CAG-ID in NAS signalling	Qualcomm Incorporated	LS out	Approval	Yes	Yes	approved	No
		S3‑192925	Proposed conclusion to key issue 6.3 on modifying the CAG list	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑192926	Adding modification of CAG list security to the draft CR	Qualcomm Incorporated	other	Approval	Yes	Yes	approved	No
		S3‑192751	conclusion on KI#4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192971
		S3‑193132	Draft TR 33.819	Nokia	draft TR	Approval	No	Yes	left for email approval	No
8.13	Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)	S3‑192656	pCR to TR33.935 - Addition of Diffie - Helman Key agreements section	Vodafone España SA	pCR	Agreement	Yes	Yes	withdrawn	Yes
8.14	Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)	S3‑192536	Proposal to solve ED notes in solution#4: Zero-overhead user plane integrity protection on the link layer	Philips International B.V.	pCR	Approval	Yes	YesQualcomm disagreed with the document and opted for having it noted. Samsung had similar issues with this document.	noted	No
		S3‑192647	Update to Key issue#5 in UP IP	Apple	pCR	Approval	Yes	YesNokia: impact on the PDCP protocol? Apple answered that she thought so. Suresh (Nokia): the impact is not captured here.	revised	No	S3‑193143
		S3‑193143	Update to Key issue#5 in UP IP	Apple	pCR	Approval	Yes	YesImproving the English.	approved	No		S3‑192647
		S3‑192648	Solution to key issue#5 in UP IP	Apple	pCR	Approval	Yes	YesQualcomm: the attacker could still attack the data part of the packet. I don’t think this solution works. Deutsche Telekom: this doesn't solve the problem. Vodafone didn't find this solution workable either.	noted	No
		S3‑192659	pCR to 33.853 - addition of solution for LTE	Vodafone España SA	pCR	Agreement	Yes	YesNEC: this introduces more complexity. They didn’t agree with the contribution. Deutsche Telekom: one thing is deployment and another is technical viability. We cannot discard it just because we think it will not be deployed. BT and CableLabs agreed. Qualcomm: first two options should go and some more technical details on the others need to be added. Vodafone asked for support in order to create an EPC version of this paper for next meeting.	revised	No	S3‑193144
		S3‑193144	pCR to 33.853 - addition of solution for LTE	Vodafone España SA	pCR	Approval	Yes	Yes	approved	No		S3‑192659
		S3‑192662	CR to 33.401 - Addition of User Plane Integrity Protection	Vodafone España SA	draftCR	Agreement	No	Yes	withdrawn	Yes
		S3‑192728	Resolving the Editor's note for Solution 5 in TR 33.853	China Mobile	pCR	Approval	Yes	YesQualcomm: I don't believe this is true, but maybe we could send an LS to a RAN group to ask for their opinion. The editor's note should stay. Colin (BT):	revised	No	S3‑193145
		S3‑193145	Resolving the Editor's note for Solution 5 in TR 33.853	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑192728
		S3‑192801	New Solution for a UE connected to 5GC indicating its support of UP IP over eUTRA	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193146
		S3‑193146	New Solution for a UE connected to 5GC indicating its support of UP IP over eUTRA	Ericsson	pCR	Approval	Yes	YesAdding an editor's note adressing Nokia's concerns. Changes in notation as proposed by Qualcomm.	approved	No		S3‑192801
		S3‑192902	Resolving Editor’s Note in Solution #1	Samsung	pCR	Approval	Yes	YesQualcomm didn’t agree with this analysis. Nokia didn’t agree with the new sentence. There was no support for this paper.	noted	No
		S3‑192905	Conclusion to Key Issue #5	Samsung	pCR		Yes	Yes	noted	No
		S3‑193147	Draft TR 33.853	Vodafone	draft TR	Approval	No	Yes	left for email approval	No
8.15	Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)	S3‑192973	Virtualisation Study Key Issue 22 was S3-191857	BT plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑192974	Virtualisation Study Key Issue 23 was S3-191858	BT plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑192975	Virtualisation Study Key Issue 24 was S3-191859	BT plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑192541	TR 33.848 Annex - Administration of Virtualisation	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑193088
		S3‑193088	TR 33.848 Annex - Administration of Virtualisation	NCSC	pCR	Approval	Yes	Yes	noted	No		S3‑192541
		S3‑192542	TR 33.848 Annex - Virtualisation Security Questions	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑193089
		S3‑193089	TR 33.848 Annex - Virtualisation Security Questions	NCSC	pCR	Approval	Yes	Yes	noted	No		S3‑192542
		S3‑192543	TR 33.848 Clarifications for Section 4	NCSC	pCR	Approval	Yes	Yes	noted	No
		S3‑192544	TR 33.848 Security Threats and Requirements for Key Issue 1	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑193090
		S3‑193090	TR 33.848 Security Threats and Requirements for Key Issue 1	NCSC	pCR	Approval	Yes	Yes	noted	No		S3‑192544
		S3‑192890	Threats and Requirements for Key Issue #2	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193091
		S3‑193091	Threats and Requirements for Key Issue #2	Nokia, Nokia Shanghai Bell	pCR	Approval	No	Yes	approved	No		S3‑192890
		S3‑192545	TR 33.848 Security Requirements for Key Issue 3	NCSC,Nokia	pCR	Approval	Yes	Yes	merged	No	S3‑193092
		S3‑192891	Threats and Requirements for Key Issue #3	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193092
		S3‑193092	Threats and Requirements for Key Issue #3	Nokia, Nokia Shanghai Bell	pCR	Approval	No	Yes	noted	No		S3‑192891
		S3‑192546	TR 33.848 Security Threats and Requirements for Key Issue 4	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑193093
		S3‑192892	Threats and Requirements for Key Issue #4	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑193093
		S3‑192547	TR 33.848 Security Threats and Requirements for Key Issue 5	NCSC	pCR	Approval	Yes	Yes	merged	No	S3‑193094
		S3‑193093	TR 33.848 Security Threats and Requirements for Key Issue 5	NCSC,Nokia	pCR	Approval	Yes	Yes	noted	No		S3‑192546
		S3‑192899	Threats and Requirements for Key Issue #5	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑193094
		S3‑193094	Threats and Requirements for Key Issue #5	Nokia, Nokia Shanghai Bell,NCSC	pCR	Approval	No	Yes	noted	No		S3‑192899
		S3‑192548	TR 33.848 Security Threats and Requirements for Key Issue 6	NCSC	pCR	Approval	Yes	Yes	noted	No
		S3‑192549	TR 33.848 Security Threats and Requirements for Key Issue 7	NCSC	pCR	Approval	Yes	Yes	noted	No
		S3‑192550	TR 33.848 Security Threats and Requirements for Key Issue 8	NCSC	pCR	Approval	Yes	Yes	noted	No
		S3‑192900	Threats and Requirements for Key Issue #8	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑192551	TR 33.848 Security Threats and Requirements for Key Issue 9	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192552	TR 33.848 Security Threats and Requirements for Key Issue 10	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192553	TR 33.848 Security Threats and Requirements for Key Issue 11	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192554	TR 33.848 Security Threats and Requirements for Key Issue 12	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192555	TR 33.848 Security Threats and Requirements for Key Issue 13	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192901	Threats and Requirements for Key Issue #13	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑192556	TR 33.848 Security Threats and Requirements for Key Issue 14	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192557	TR 33.848 Security Threats and Requirements for Key Issue 15	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192558	TR 33.848 Security Threats and Requirements for Key Issue 16	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192559	TR 33.848 Security Requirements for Key Issue 17	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192904	Threats and Requirements for Key Issue #17	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑192560	TR 33.848 Security Requirements for Key Issue 18	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192906	Threats and Requirements for Key Issue #18	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑192561	TR 33.848 Security Requirements for Key Issue 19	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192908	Threats and Requirements for Key Issue #20	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑192562	TR 33.848 Security Threats and Requirements for Key Issue 21	NCSC	pCR	Approval	Yes	Yes	not treated	No
		S3‑192910	Threats and Requirements for Key Issue #21	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑192958	Categorization of the Key Issues	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	not treated	No
		S3‑193063	Notes on the evening session on SIV	BT	report	Information	Yes	Yes	noted	No
		S3‑193185	Draft TR 33.848	BT	draft TR	Approval	Yes	Yes	left for email approval	No
8.16	Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)	S3‑192919	Update of Authentication Enhancements SID	Qualcomm Incorporated	SID revised	Agreement	Yes	Yes	revised	No	S3‑193186
		S3‑193186	Update of Authentication Enhancements SID	Qualcomm Incorporated	SID revised	Agreement	Yes	YesIncluding the new dates.	agreed	No		S3‑192919
		S3‑192879	New KI: Security of session anchor keys in case the long-term key is leaked	Ericsson	pCR	Approval	Yes	YesVodafone objected to this key issue. Orange wasn't happy with this either. Thales didn't support this either and commented that this had been brought several times before and rejected. Vodafone: this needs to be updated with the discussions we've had before: rewording the key issue especially. Ericsson decided to keep discussing this offline and bring an update for the next meeting.	noted	No
		S3‑192680	Key issue to mitigate the SUPI guessing attacks	China Mobile	pCR	Approval	Yes	YesOrange: more details on the attack are needed. Bring a discussion paper for this for the next meeting. Ericsson: I don’t see the relation of this with the objectives of the study.	noted	No
		S3‑192692	Key issue on the authenticaiton result storage in the UDM	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: out of scope of the objectives of the study. Vodafone: the title is the solution, not the key issue. Huawei commented that last meeting SA3 decided to bring this key issue. Deutsche Telekom: the wording of the key issue is too focused on the solution already. Orange: editor's note on the improvement of the key issue details. Remove threats and requirements. Ericsson: link it better with the study objectives.	revised	No	S3‑193187
		S3‑193187	Key issue on the authenticaiton result storage in the UDM	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192692
		S3‑192920	Proposed re-wording of the requirement in key issue #4.1 in TR 33.846	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑192880	New Solution:EAP-AKA´ PFS	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑192622	Handling of Sync failure	ZTE Corporation	pCR	Approval	Yes	YesThales: replace ME with UE. Orange: remove the evaluation. Vodafone: key issues are oddly numbered throughout the document. Can we give an action to the Rapporteur to fix the skeleton and clause numbering? Apple: security risk of using a fixed key is FFS.	revised	No	S3‑193189
		S3‑193189	Handling of Sync failure	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑192622
		S3‑192681	A Solution for Key Isssue#2.1 and key issue #4.1 in TR 33.846	China Mobile	pCR	Approval	Yes	Yes	revised	No	S3‑193190
		S3‑193190	A Solution for Key Isssue#2.1 and key issue #4.1 in TR 33.846	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑192681
		S3‑192972	mitigate the linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	YesQualcomm: remove changes from scope. Ericsson wanted some more details in the description of the solution.	revised	No	S3‑193191	S3‑192752
		S3‑193191	mitigate the linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192972
		S3‑192621	Structure RAND for authentication	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑192663	33.846: mitigation against linkability attack	THALES	pCR	Approval	Yes	Yes	not treated	No
		S3‑192684	New solution for linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192921	Using MACS to provide freshness for the protection of SQN during a re-synchronisation procedure in AKA	Qualcomm Incorporated	pCR	Approval	Yes	Yes	not treated	No		S3‑191908
		S3‑192970	Proposed solution on protecting the SQN during a re-synchronisation procedure in AKA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No		S3‑192750
		S3‑192623	Conclusion on linkability issues	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑192679	Key issue to mitigate the SUPI guessing attacks	China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑193188	Draft TR 33.846	Ericsson	draft TR	Approval	No	Yes	left for email approval	No
8.17	Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)	S3‑192665	IAB-node: terminology change	THALES, ORANGE	pCR	Approval	Yes	YesZte: A change more intended for a TS than for a TR. Orange: everything we write in SA3 is about the UE and not the MT. MT is a radio concept, but we go beyond the radio part in SA3. Ericsson: SA2 also uses MT.	revised	No	S3‑193148
		S3‑193148	IAB-node: terminology change	THALES, ORANGE	pCR	Approval	Yes	YesAdding an editor's note on the terminology.	approved	No		S3‑192665
		S3‑192825	IAB: Assumptions related to key hierarchy in IAB architecture in 5G	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑193150
		S3‑193150	IAB: Assumptions related to key hierarchy in IAB architecture in 5G	Ericsson	pCR	Approval	Yes	YesAddressing the comments on the use of MT.	approved	No		S3‑192825
		S3‑192969	Key issue on removal of USIM card in IAB node	Huawei, Hisilicon	pCR	Approval	Yes	YesOrange: I don't understand the key issue. Nokia: this is a deployment issue. Qualcomm didn’t agree either. There was no support for this key issue.	noted	No		S3‑192749
		S3‑192911	Requirement on authorization of IAB Node	Samsung	pCR	Approval	Yes	YesQualcomm: what does "evaluated" mean in the requirement? This was reworded.	revised	No	S3‑193151
		S3‑193151	Requirement on authorization of IAB Node	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑192911
		S3‑192912	Solution for authorization of IAB Node	Samsung	pCR	Approval	Yes	YesQualcomm: the description is incomplete.	revised	No	S3‑193152
		S3‑193152	Solution for authorization of IAB Node	Samsung	pCR	Approval	Yes	YesChange in clause 6.3.1.1 removed.	approved	No		S3‑192912
		S3‑192914	Evaluation of solution #2.1	Samsung	pCR	Approval	Yes	YesOrange: the solution is not clear. I cannot evaluate this.	noted	No
		S3‑192915	Evaluation of solution #3.1	Samsung	pCR	Approval	Yes	YesQualcomm opposed to having this. This was noted.	noted	No
		S3‑192917	Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑192826	KI #2.3: security threats and potential requirements	Ericsson	pCR	Approval	Yes	YesQualcomm and Huawei disagreed with the security requirement. This was gone. Nokia: add an editor's note on additional threat parameters that could be included here.	revised	No	S3‑193153
		S3‑193153	KI #2.3: security threats and potential requirements	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192826
		S3‑192827	New solution: secure recovery from backhaul-RLF	Ericsson	pCR	Approval	Yes	YesQualcomm had numerous comments and preferred to have it noted. Huawei had the same opinion.	noted	No
		S3‑193149	Draft TR 33.824	Samsung	draft TR	Approval	No	Yes	left for email approval	No
8.18	Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)	S3‑192534	LS on the call for proposals for an internationally agreed Vehicular Multimedia Architecture	ITU-T FG-VM	LS in		Yes	Yes	noted	No
		S3‑192507	Reply LS to Reply LS on protection of PC5-RRC messages for sidelink unicast communication	S2-1908229	LS in		Yes	Yes	noted	No
		S3‑192522	33.836 - solution #1 update	InterDigital Communications	pCR	Approval	Yes	YesEricsson proposed adding an editor's note on which messages are integrity protected and trackability problem.The second editor's note was brought back instead.	revised	No	S3‑193154
		S3‑193154	33.836 - solution #1 update	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑192522
		S3‑192523	TR 33.836 - update for solution #2	InterDigital Communications	pCR	Approval	Yes	YesLG: the first editor's note should stay, as we need additional clarifiation. Is there Prose architecture for NR implied? Interdigital said so, and LG replied that there was no ProSe architecture in release 16. A note should be added.	revised	No	S3‑193155
		S3‑193155	TR 33.836 - update for solution #2	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑192523
		S3‑192524	TR 33.836 - solution #3 update	InterDigital Communications	pCR	Approval	Yes	YesSame case as previous contribution, and the same editor's note was added as suggested by LG. Ericsson proposed to highlight the difference between this and solution 2.	revised	No	S3‑193157
		S3‑193157	TR 33.836 - solution #3 update	InterDigital Communications	pCR	Approval	Yes	Yes	approved	No		S3‑192524
		S3‑192525	TR 33.836 solution #4 update	InterDigital Communications	pCR	Approval	Yes	Yes	revised	No	S3‑193158
		S3‑193158	TR 33.836 solution #4 update	InterDigital Communications	pCR	Approval	Yes	YesSame editor's notes about 5G Prose were added.	approved	No		S3‑192525
		S3‑192571	new solution on privacy protection for unicast	NEC Corporation	pCR	Approval	Yes	YesLG was not happy about NOTE 2 and proposed to remove it. Interdigital added that the solution didn’t consider the trackability and linkability of identities.Qualcomm considered the point as valid and an editor's note was added.	revised	No	S3‑193159
		S3‑193159	new solution on privacy protection for unicast	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑192571
		S3‑192634	eV2X: New solution for Security for eV2X unicast messages over PC5	Intel Deutschland GmbH	pCR	Approval	Yes	Yes	revised	No	S3‑193160
		S3‑193160	eV2X: New solution for Security for eV2X unicast messages over PC5	Intel Deutschland GmbH	pCR	Approval	Yes	YesMotorola: replay protection should be addressed. This was taken offlie. Interdigital had multiple comments that were addressed in editor's notes.	approved	No		S3‑192634
		S3‑192932	Proposed solution for deriving PC5 layer keys based on higher layer keys	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑193161
		S3‑193161	Proposed solution for deriving PC5 layer keys based on higher layer keys	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑192932
		S3‑192649	Update to Key issue#5 in eV2X	Apple	pCR	Approval	Yes	YesInterdigital: this requirement is not enough.	noted	No
		S3‑192569	new KI on privacy protection for broadcast	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑193162
		S3‑193162	new KI on privacy protection for broadcast	NEC Corporation	pCR	Approval	Yes	YesAdding an editor's note as proposed by Ericsson.	approved	No		S3‑192569
		S3‑192570	new solution on privacy protection for broadcast and groupcast	NEC Corporation	pCR	Approval	Yes	YesLG: No requirement to justify 6.Y.2.1 in 3GPP for Unicast. Remove the whole clause. Qualcomm didn’t understand why introducing PC5 signalling; besides, according to SA2's agreements on broadcast and groupcast this solution is not needed.	noted	No
		S3‑192741	V2X Group Key Provisioning	Lenovo, Motorola Mobility	pCR	Approval	Yes	YesInterdigital proposed an editor's note on the solution working our of coverage. This was agreed. An additional editor's note on SA2's decision on the group management was also added.	revised	No	S3‑193163
		S3‑193163	V2X Group Key Provisioning	Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	approved	No		S3‑192741
		S3‑192572	new KI on increasing robustness and reliability in L2 ID update procedure	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑192573	new solution on increasing robustness and reliability in L2 ID update procedure	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑192574	new KI on minimizing the impact of privacy protection mechanism in the application layer communication	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑193164
		S3‑193164	new KI on minimizing the impact of privacy protection mechanism in the application layer communication	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑192574
		S3‑192575	new solution on minimizing the impact of privacy protection mechanism in the application layer communication	NEC Corporation	pCR	Approval	Yes	YesLG: revise the figure to address the unicast case. The evaluation was also removed.	revised	No	S3‑193165
		S3‑193165	new solution on minimizing the impact of privacy protection mechanism in the application layer communication	NEC Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑192575
		S3‑192695	New KI: Key issue on UP security policy handling for PC5 and Uu interface	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑193166
		S3‑193166	New KI: Key issue on UP security policy handling for PC5 and Uu interface	Huawei, Hisilicon	pCR	Approval	Yes	YesJust to remove "SA5" next to the reference.	approved	No		S3‑192695
		S3‑192727	Solution on Cross-RAT PC5 control authorization indication	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192568	terminology alignment on groupcast	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑193167
		S3‑193167	terminology alignment on groupcast	NEC Corporation	pCR	Approval	Yes	YesLG asked to remove the added requirements.	approved	No		S3‑192568
		S3‑192567	Editorial corrections for eV2X SI TR 33.836 v0.3.0	NEC Corporation	pCR	Approval	Yes	YesMCC commented that the existent text: "However no IE has been defined for the for the cross-RAT PC5 control authorization indication. It has been decided that SA3 shall make a decision on this matter " needed re-wording.	approved	No
		S3‑193137	LS on link layer ID update	NEC	LS out	Approval	No	Yes	withdrawn	Yes
		S3‑193156	Draft TR 33.836	LG	draft TR	Approval	No	Yes	left for email approval	No
8.19	Other study areas	S3‑192819	ARPF Deployment models	Ericsson	discussion	Discussion	Yes	Yes	not treated	No
		S3‑192820	Security Parameter Storage	Ericsson	discussion	Discussion	Yes	Yes	not treated	No
		S3‑192821	Privacy Aspects of ARPF deployment	Ericsson	discussion	Discussion	Yes	Yes	not treated	No
		S3‑192666	Update to TR33.xxx Storage of Secure Parameters in a 5G system - addition of content to section 4	Vodafone España SA	discussion	Decision	No	Yes	withdrawn	Yes
		S3‑192667	Update to TR33.xxx Storage of Secure Parameters in a 5G system - addition of content to section 5	Vodafone España SA	discussion	Decision	No	Yes	withdrawn	Yes
		S3‑192670	Update to TR33.xxx Storage of Secure Parameters in a 5G system - addition of KI - Long term key leakage	Vodafone España SA	discussion		No	Yes	withdrawn	Yes
		S3‑192673	Update to TR33.xxx Storage of Secure Parameters in a 5G system - addition of KI - discovery of correct privacy service	Vodafone España SA	discussion	Decision	No	Yes	withdrawn	Yes
		S3‑192646	Discussion on 5G UE privacy when connecting to EPC	Apple	discussion	Agreement	Yes	Yes	not treated	No
		S3‑192750	Proposed solution on protecting the SQN during a re-synchronisation procedure in AKA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192970
		S3‑192752	mitigate the linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192972
8.20	New study item proposals	S3‑192517	Issues with encryption of satellite backhaul	TNO, Avanti, iDirect, University of Surrey, SES	discussion	Discussion	Yes	YesNokia: which 3GPP node has an impact? TNO: the backhaul is confidentially protected according to our specs; this would be a similar case to the SEPPs when connecting different networks, so that would impact our requirement. Nokia: but there is no impact on 3GPP nodes then. NTT-Docomo: profiling PEP for use in NDS? Not much else to do and not really a high priority. TNO: this is intended for Release 17. Interdigital: redesign Ipsec here is the motivation? We are not the right place to change it. Qualcomm: you can use any technology to confidentiality protect the satellite link, not Ipsec necessarily. Not clear to me what we need to study.	noted	No
		S3‑192515	draftTR33.xxx Storage of sensitive credentials in 5G systems v0.0.1	Vodafone España SA	discussion		Yes	Yes	noted	No
		S3‑192650	EAP-AKA privacy enhancement in non-3GPP access to EPS	Apple	SID new	Approval	Yes	YesOrange: handle 3GPP and non-3GPP access. Rewrite to handle the privacy aspects EPS over 3GPP and non-3GPP accesses. Nokia: this would increase greatly the work, and there is no time. CableLabs supported the study. China Mobile agreed with Nokia, the scope would be too wide if extending to 3GPP access. Qualcomm: an attack can use a false base station, no value restricting to non 3GPP access. We had a look at this already, no need to have this SID. Operators can always move to 5G core. Vodafone: potential solutions seem to be changing features in 3GPP due to the non 3GPP side issues, when the latter should be the ones addressing them. Alex(BT) supported Orange and had sympathy for Qualcomm. No objection for the study, but it should be done properly by increasing the scope. Apple clarified that the release could be 17 if necessary. Vodafone warned that there were several companies that didn’t attend SA3 as supporters. There was a reminder that the signing companies committed to contribute and participate in the study work actively.	revised	No	S3‑192995
		S3‑192995	EAP-AKA privacy enhancement in non-3GPP access to EPS	Apple	SID new	Agreement	Yes	Yes	noted	No		S3‑192650
		S3‑192749	Key issue on removal of USIM card in IAB node	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192969
		S3‑192831	Discussion on study on user plane security termination point in 5GC	CATT	discussion	Endorsement	Yes	Yes	withdrawn	Yes
		S3‑192903	SID on Rel16 onwards Storage of Secure Parameters in a 5G system	Vodafone España SA	SID new	Agreement	Yes	YesCableLabs supported this SID. Deutsche Telekom: what is a secure parameter? It's about parameters to be secured. Vodafone: This is a section in CT4 identifying what parameters need to be secure. Nokia objected to this SID. Looking at security parameters could be done without a SID, business as usual. There are no objectives here, just have an understanding of the parameters which is part of the ongoing work with CT4. The objectives discussion had to be taken offline. MCC commented that there was no need to have release 16 in the title or acronym since it would apply to release 16 anyway. NTT-Docomo: not so simple to have everything done in Release 16. Nokia: the LS from CT4 asked us to consider, they didn’t request us.	revised	No	S3‑193057
		S3‑193057	SID on Storage of Secure Parameters in a 5G system	Vodafone España SA	SID new	Agreement	Yes	Yes	agreed	No		S3‑192903
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑192502	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑192504	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	revised	No	S3‑193202
		S3‑193202	Work Plan input from Rapporteurs	MCC	other	-	No	Yes	noted	No		S3‑192504
10	Future Meeting Dates and Venues	S3‑192503	SA3 meeting calendar	MCC	other		Yes	Yes	revised	No	S3‑193199
		S3‑193199	SA3 meeting calendar	MCC	other	-	Yes	Yes	revised	No	S3‑193203	S3‑192503
		S3‑193203	SA3 meeting calendar	MCC	other	-	Yes	Yes	noted	No		S3‑193199
11	Any Other Business