TDoc list

Tdoc List

2019-06-28 16:12

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‑191800	Agenda	WG Chairman	agenda		Yes	Yes	approved	No
3	IPR and Anti-Trust Law Reminder
4	Meeting reports
4.1	Approval of the report from previous SA3 meeting(s)	S3‑191801	Report from last SA3 meeting/s	MCC	report		Yes	Yes	approved	No
4.2	Report from SA Plenary	S3‑191803	Report from last SA meeting	WG Chairman	report		Yes	Yes	noted	No
4.3	Report from SA3-LI
5	Items for early consideration	S3‑191840	LS reply on Nudr Sensitive Data Protection	S2-1906761	LS in		Yes	Yes	noted	No
		S3‑191841	Reply LS on Nudr Sensitive Data Protection	SP-190581	LS in		Yes	YesVodafone queried if changes implemented in Rel-15 had to be reversed. The Chair replied that was the case. NTT-Docomo: massive security work needed here, not even ready for Rel-16. It was decided to send an LS to SA2 and CT4 and postpone the reply to SA for the next meeting.	postponed	No
		S3‑192277	Reply to: Reply LS on Nudr Sensitive Data Protection	Nokia	LS out	approval	Yes	YesIt was clarified that changes in Rel-15 were needed in CT4. The Chair replied that this was not what was asked in SA. ORANGE: we never said that we had a specific authentication that shall be used. Proprietary algorithms used currently by operators will not work. Alex(BT): as specified this resolves in 5G weaker than 4G, due to the use of proprietary algorithms by operators. Anja(Nokia): this means that we are in the same situation as last meeting. Gemalto replied that last meeting was about a new feature in the storage in the UDM whereas this was a correction. The Chair commented that this may lead to a correction in a CT4 specification. Who supports sending the LS: Telecom Italia, Nokia, ORANGE,China Mobile, BT, Gemalto,Docomo,Hpe supported sending the LS. Ericsson didn’t support sending the LS.	revised	No	S3‑192456
		S3‑192456	LS on Nudr Sensitive Data Protection	Nokia	LS out	approval	Yes	Yes	approved	No		S3‑192277
		S3‑192057	LS-UDR	Nokia	LS out	Approval	Yes	Yes	noted	No
		S3‑191985	Material related to UDM-ARPF-UDR discussion	Nokia, Nokia Shanghai Bell	discussion	Information	Yes	Yes	noted	No
		S3‑191862	Moving Forward on Storing Authentication Data	Hewlett-Packard Enterprise	discussion	Endorsement	Yes	YesVodafone: there would be security interoperability issues between the ARPF and UDR, no assurance for backwards compatibility.There is no time to do any security assesments anymore for Rel-15. It was clarified that SA3 was requrested to align with stage 3. Huawei: against adding requirements for this in 33.501 Rel-16. Alex(BT): we need to accept that SA made the decision of keeping the UDR. All companies were OK with that in SA, except Vodafone. Go with the Plenary's decision, keep it in Rel-15 "it's in the UDR", and look at it in Rel-16. The Chair commented that the issue on Rel-15 would the priority and work forward in Rel-16 would be discussed afterwards.	noted	No
		S3‑192140	Discussion of credential data protection	China Mobile	discussion	Endorsement	Yes	YesKPN, Nokia disagreed with the Rel-15 proposal. Something had to be done in Rel-15. Huawei supported this.	noted	No
		S3‑191984	Discussion on UDM-UDR-ARPF issues	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	YesVodafone found quite a lot to disagree in here. The document seems to imply that we take the SA's view as long term. The Chair clarified that SA3 will follow the guidance of SA in Rel-15. There is no choice here. Some proposals wanted to add something in Rel-15, some proposals said that nothing should be done in Rel-15. Vodafone: implementation problems as Rel-15 is showing now. Gemalto: Authentication data and suscription credentials are different concepts and SA is confusing them. Vodafone: there is a problem with addressing the storage of sensitive data in the UDR or proprietary repository. China Mobile: Rel-15 is frozen in SA3 too, no need to change anything in there. ORANGE: the definition of subscription credentials need to change. Georg Mayer (SA Chair) commented that these were defined in CT4 specifications. The deployment may be done differently but then they would not follow CT4 specs. Extending the definition or putting a note would be helpful. ORANGE: add a note: "Security storage in the UDR is out of scope of this document". Anders (HP): we cannot say all storage is out of scope.	noted	No
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑191836	LS on Ciphering solution for broadcast of Assistance Data	R2-1908473	LS in		Yes	Yes	replied to	No
		S3‑191941	Nokia comments on R2-1908473 UE DL assistance data.	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	Yes	noted	No
		S3‑191942	Draft reply LS on R2-1908473 UE DL assistance data.	Nokia , Nokia Shanghai Bell	LS out		Yes	Yes	revised	No	S3‑192268
		S3‑192268	Reply LS on Cuiphering solution for broadcast of Assistance Data	Nokia , Nokia Shanghai Bell	LS out	-	Yes	Yes	approved	No		S3‑191942
		S3‑191924	Ciphering of broadcast assistance data for UE-based positioning	Qualcomm Incorporated	discussion	Decision	Yes	YesEricsson: integrity protection is needed. Qualcomm replied that the agreement was that integrity protection was not needed. Interdigital: passive attacks are considered? When the UE is receiving coordinates from the gNodeB?. Qualcomm: high location accuracy is needed for some Ues, apps or the operator. Access control is for Ues that are subscribed for it. This is an use case that needed cyphering. Alf (Docomo): keystream could be used for something else. A predicted or extracted keystream should be looked at. Vodafone: publishing the location of the gNodeBs is a usual procedure among operators. It's publicly available data. Qualcomm: there is no security risk when using cyphering the static broadcast assistance data. Ericsson: add a reminder that Unicast uses NAS security and integrity protection can be added.	noted	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA	S3‑191837	GTP Recovery Counter & GSN node behaviour	GSMA	LS in		Yes	YesNokia: the choice of options require some study from SA3. Vodafone: we need a study item for this, and reply to them with an LS that we will do a study. Better not to postpone this LS. The Chair noted that this was an LS asking CT4 and not SA3, so no specific action for SA3 was required. Nokia: CT4 will not give a proper answer on the security of this.	replied to	No
		S3‑192269	Reply to: GTP Recovery Counter & GSN node behaviour	Nokia	LS out	approval	Yes	YesIt was agreed to send an LS reply where it would be stated that SA3 will look into this matter.	approved	No
		S3‑191845	Diameter IPX Network End-to-End Security Solution	GSMA	LS in		Yes	YesVodafone: I expect CRs for TS 33.401 as a result of this.A study item is needed. Iko (KPN): there is non 3GPP functionality here, that does not concern us. NCSC agreed with KPN. Nokia: on the Diameter solution we can give some feedback in the next meeting. AT&T: IETF has been working on Diameter security for years. How is it that GSMA has better security expertise on this issue? Vodafone commented that they had better knowledge of how the networks are implemented and deployed.	replied to	No
		S3‑192270	Reply to: Diameter IPX Network End-to-End Security Solution	KPN	LS out	approval	Yes	Yes	approved	No
6.5	OMA
6.6	TCG	S3‑191814	TCG progress report	InterDigital, Inc.	report	Information	Yes	YesHighlights: • Publication of new or revised deliverables (incremental changes from the status reported at SA3#95) • TCG TPM 2.0 Auto Thin Profile – publication in June 2019 • TCG Trusted Attestation Protocol (TAP) Info Model – publication in June 2019 • TCG Trusted Attestation Protocol (TAP) Use Cases – public review June 2019 • TCG TPM 2.0 r1.55 – X.509 Certs & Attached Components – public review May 2019 • TCG TSS 2.0 TAB and Resource Manager – published April 2019 • TCG TSS 2.0 TPM Command Transmission Interface (TCTI) – published April 2019 • TCG TSS 2.0 System Level API (SAPI) – public review April 2019 • TCG TSS 2.0 Enhanced System Level API (ESAPI) – public review April 2019 • TCG PC Client Device Driver Design Principles for TPM 2.0 – public review February 2019 • TCG Platform Certificate Profile – public review February 2019 • 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/ Problem Space - Verifiable remote attestation - architecture and secure protocols - Solutions spanning from IoT devices to Data Center systems and Cloud infrastructure - Compact implementation solutions for resource-constrained systems - Composition and correlation for complex systems (e.g., rack-mount routers) - Primary support for CBOR Web Token (CWT) https://tools.ietf.org/html/rfc8392 - Secondary support for JSON Web Token (JWT) https://tools.ietf.org/html/rfc7519 - Multiple security components (GP SE, TCG TPM, TCG DICE, TCG MARS, etc.) 2. Meetings • TCG Annual Members Meeting in Warsaw, Poland – 10-13 June 2019 o Sessions of Cyber Resilience, Network Equipment, DICE, IoT, Industrial, etc. o Kickoff of Measurement and Attestation RootS (MARS) in Embedded Systems • TCG Annual Members Meeting in Toronto, Canada - 15-17 October 2019 • MPWG meets every Thursday at 10-11 ET • TMS WG meets every Monday and Friday at 12-13 ET • CyRes WG meets every Wednesday at 11-12:30 ET	noted	No
6.7	oneM2M
6.8	TC-CYBER
6.9	ETSI NFV
6.10	CVDs and Research	S3‑191848	Handling of UE radio network capabilities in 4G and 5G	GSMA	LS in		Yes	Yes	replied to	No
		S3‑192271	Reply to: Handling of UE radio network capabilities in 4G and 5G	NTT-Docomo	LS out	approval	Yes	YesIncludes agreement on proposal 1 in tdoc 992.	approved	No
		S3‑192265	Reply LS on Handling of UE radio network capabilities in 4G and 5G	R2-1908467	LS in	Information	Yes	Yes	replied to	No
		S3‑191939	Nokia comments on GSMA LS on UE radio capability exchange	Nokia	discussion		Yes	YesORANGE: what's the privacy issue? Nokia: fingerprinting of the device. The device type can be identified, software version, capability. Also whether the user has instantiated a particular application, watssapp or whatever. ORANGE: for 5G the IMSI is cyphered, not the same problem. We cannot hide the IMSI so it's not possible to provide backward compatibility in 4G. Besides, in Nokia's examples of privacy issues the user's identity is never exposed. Futurewei: this has been discussed before with RAN2. They don’t have a problem with mandating for the security in the Uecapabilityenquiry procedure. NTT-Docomo: I agree with the issue in 5G with device fingerprinting.	noted	No
		S3‑191938	Nokia comments on R2-1908467 reply LS to GSMA UE capability	Nokia	discussion	Endorsement	Yes	YesFuturewei supported this proposal.	noted	No
		S3‑191992	Proposal for handling of UE radio network capabilities in 4G and 5G	Ericsson	discussion	Endorsement	Yes	YesFuturewei supported proposal 1 and 4. ORANGE: combine 1 and 2 in a new proposal 5. Nokia: proposal 2 doesn’t address the issue and 3 is a new issue. Vodafone also liked proposal 1. The Chair saw that most companies supported proposal 1. Qualcomm liked proposal 2, Docomo supported proposal 1 and 2. In case RAN2 had issues with proposal 2, the shalls could be replaced with "should".	noted	No
		S3‑191809	Draft LS to RAN2 on UECapabilitiesEnquire after AS SMC	Futurewei	LS out	Approval	Yes	Yes	noted	No
		S3‑191940	Nokia comments on GSMA LS on UE radio capbility exchange	Nokia, Nokia Shangahi Bell	LS out	Approval	Yes	Yes	noted	No
		S3‑192266	Impersonation Attacks in 4G Networks	GSMA	LS in	Discussion	Yes	YesQualcomm: we are already studying UP IP for LTE. If we have this, the attack cannot be launched. Docomo: the billing issue is not here. You cannot create more traffic. Qualcomm was uncomfortable with replying with details to a paper that was not public yet. It was agreed to reply without much detail.	replied to	No
		S3‑192272	Reply to: Impersonation Attacks in 4G Networks	Nokia	LS out	approval	No	Yes	approved	No
6.11	Other Groups	S3‑191833	NGMN 5G End-to-End Architecture Framework	NGMN	LS in		Yes	Yes	noted	No
		S3‑191844	LS on the availability of and requesting feedback on the stable draft TR 103 582 from ETSI STF555 - "Study of use cases and communications involving IoT devices in emergency situations	ETSI SC EMTEL	LS in		Yes	YesDocomo: we should feedback requirements for roaming users need to be clear with regards to PWS messages in IoT devices.There is some work in SA1 and CT1 for ePWS. If we receive more LS about this work we should keep EMTEL in the loop.	noted	No
		S3‑192267	LS on withdrawal of TS 103 383 “Smart Cards; Embedded UICC; Requirements Specification	ETSI TC SCP	LS in	Information	Yes	YesORANGE took the action point of preparing the CRs. A reply to this LS when the CRs were agreed would be done for the next meeting. Telecom Italia queried why the GSMA document was more important than the TCP document. Vodafone commented that the GSMA document was more widely implemented. ORANGE: SCP document is requirements-only and the GSMA documents has more things than requirements. Nokia: shouldn't we add other references after removing this one? ORANGE replied that it wasn't necessary.	postponed	No
		S3‑192273	Removing references in TS 33.501 of TS 103 383	ORANGE	discussion	Information	Yes	YesCRs will come next meeting.	noted	No
7	Work Areas
7.1	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
7.1.1	Key hierarchy	S3‑192052	Mandating time based generation of SQNs	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesEricsson didn't agree with this recommendation. There are problems in the deployments when having different clocks. There are other ways of mitigating this attack. Qualcomm: our understanding was to enhance the authentication to address this problem. We have a key issue related to this for the study item. It was agreed to follow this in the related study work.	not pursued	No
7.1.2	Key derivation	S3‑192073	Clarification on length of EARFCN-DL in key derivation	Huawei, Hisilicon	CR	Approval	Yes	YesRelated to tdoc 1971 (ZTE).	not pursued	No
		S3‑192135	Revisit the KAUSF desynchronization problem	China Mobile	discussion	Endorsement	Yes	YesNokia didn’t agree with this scenario. If the authentication happened already, how can the attacker trigger another authentication? Only the AMF can do this. Alex (BT) didn't see the issue here,it's just error handling when there is a de-synchronization. Qualcomm agreed: the system will recover itself.	noted	No
		S3‑192139	KAUSF synchronziation between the UE and AUSF	China Mobile	CR	Approval	Yes	Yes	not pursued	No
		S3‑191971	length of ARFCN-DL	ZTE Corporation	CR	Agreement	Yes	YesVodafone: Why is the length coded in two bytes? What's the point of the first 00? Qualcomm: it was defined like that (look at L0). Nokia: this is not a new parameter, why do we need a new definition?	agreed	No
7.1.3	Mobility	S3‑191972	uplink NAS Count for KeNB derivation in idle mode mobility to EPS	ZTE Corporation	CR	Agreement	Yes	YesOverlap with tdocs 1916,1917. This had to be taken offline.	not pursued	No
		S3‑192004	Security handling in registration procedure at AMF reallocation caused by slicing	Ericsson	discussion	Endorsement	Yes	Yes	revised	No	S3‑192262
		S3‑192262	Security handling in registration procedure at AMF reallocation caused by slicing	Ericsson Hungary Ltd	discussion	Endorsement	Yes	Yes	noted	No		S3‑192004
7.1.4	AS security
7.1.5	NAS security	S3‑191911	Discussion on possible solutions to AMF relocation issues	Qualcomm Incorporated	discussion	Endorsement	Yes	YesOverlaps with 2148.Huawei didn’t agree and preferred to go for their proposal in 2148.	noted	No
		S3‑191912	Missing security context handling during registration procedures	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑192148	Solving registraiton failure in ilde mobility registration procedure with AMF Reallocation	China Telecom, Huawei, Hisilicon	CR	Approval	Yes	YesChina Mobile disagreed with this proposal. It wouldn’t work against a false base station attack. Ericsson: we may be finding security holes in this olution and it needs to be studied more carefully. Qualcomm: what happens when the AMF doesn’t talk to the old AMF and it doesn’t pull the old security context? Huawei warned that if this was not solved in Release 15 there would backward compatibility issues in Release 16. Qualcomm: Intra-AMF connection within a network would avoid this problem in Release 15. ZTE: We prefer a solution that doesn't impact the UE. The Chair asked the delegates if there was any chance of having this solved in Release 15. Noamen commented that more CRs would be welcome for the next meeting. Martin (AT&T): if we don’t solve this, we are getting to the situation of having to use a proprietary solution and it will cause once again that nothing will be standardized with many proprietary solutions already in the market. It was proposed to send an LS to CT1. This was discussed in tdoc 2281.	not pursued	No
		S3‑192159	Discussson paper on AMF reallocation	China Telecom, Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑192219	Clarification to Initial NAS message protection	Samsung	CR	Approval	Yes	YesMCC asked if this issue needed to be fixed, why it wasn't done in Rel-15. This was brought as TEI16, and it could be flagged out in SA.Samsung replied that it had been rejected to do it in Release 15 in the previous meeting, but in release 16 it was only introducing a new characteristic in the UE, not a new feature. Ericsson wasn't sure if this was affecting SA2's procedures and SA3 may have to consult them firstly.	revised	No	S3‑192282
		S3‑192282	Clarification to Initial NAS message protection	Samsung	CR	Approval	Yes	YesSmall changes as proposed by Suresh (Nokia). Futurewei suggested to reword the consequences if not approved on the CR cover.	agreed	No		S3‑192219
		S3‑192281	LS on registration issues in the AMF re-allocation	Huawei	LS out	Approval	Yes	YesThe Chair warned that if this had an impact on Rel-15 stage 3, this could be rejected by CT groups. Vodafone commented that CT groups were meeting in the same location as SA3 next time, so this could be discussed with them. It was argued that this could have some impact on backward compatibility and the release could be discussed with CT.	approved	No
		S3‑192353	Report from session on registation failures with AMF reallocation	Huawei	report	Information	Yes	Yes	noted	No
		S3‑192454	AMF reallocation	Huawei	discussion	Endorsement	Yes	YesIt takes the problem description of S3-192159 to be forwarded in the LS S3-192281.	noted	No
7.1.6	Security context	S3‑191979	uplink NAS Count for Kasme derivation in idle mode mobility to EPS	ZTE Corporation	CR	Agreement	Yes	YesSuresh (Nokia) didn’t agree with this change. ZTE: we guarantee that we use always the same value this way when the last COUNT is increased. Huawei: we agree with the problem they're trying to solve, not with the solution here.Scenario too specific, NAS uplink count value would be the more generic problem. It was agreed the existence of the problem, but the resolution/clarification needed to be taken offline.	revised	No	S3‑192284
		S3‑192284	uplink NAS Count for Kasme derivation in idle mode mobility to EPS	ZTE Corporation	CR	Agreement	Yes	Yes	agreed	No		S3‑191979
7.1.7	Visibility and Configurability	S3‑191884	SoR-MAC-IUE verification failure handling by UDM	NEC Europe Ltd	CR	Agreement	Yes	YesThe Chair asked if this had impact on stage 3. NEC couldn’t answer. Ericsson: if it's a malicious AMF why it would forward the malitious message? Vodafone: if there is no match it would just fail. Qualcomm: this is a CT1 problem, not to be addressed here. Samsung added that this increased complexity.	not pursued	No
		S3‑191955	Clarification on Procedure for steering of UE in VPLMN during mobility registration update	Intel China Ltd., NEC	CR		Yes	YesQualcomm: this scenario doesn’t apply here. Vodafone agreed; this only takes place in the initial registration.	not pursued	No
7.1.8	Primary authentication	S3‑191986	Definition of authentication subscription data	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesDocomo: second change should not be part of a definition, it's a requirement. Alf (Docomo): on the subscription credential(s) definition: these kind of discussion should not happen in a definition clause. This is not even a proper defintion format. The first definition on authentication subscription data was also discussed. Vodafone and MCC expressed their concerns that the definition was not used anywhere in the specification. Telecom Italia: a list of full parameters that are subscription credentials cannot be even agreed in SA3 so we cannot expect that CT groups assume them. Telecom Italia wished that it was clear for the operator that the security processes in the second note were not described anywhere else. MCC also noted that the term "in the present release" was redundant and just saying "not defined" would be clear enough.	revised	No	S3‑192276
		S3‑192276	Definition of authentication subscription data	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesNTT-Docomo: happy with this, but we need to verify that the definitions are being used in the text of the spec and that they are still correct. Maybe send a LS and have a conference call in between meetings.Gemalto and ORANGE agreed. NTT-Docomo: this should lead to a study item in Rel-16. Alf (Docomo): allowing the storage in the UDR goes beyond making a definition, things are being stored in the ARPF throughout the spec and we need to modify those parts as well. ORANGE disagreed with the requirements on the UDM. It was commented that this document would serve as a baseline for further work for the next meeting, but in the end the document was noted. Telecom Italia: realistic to have UDR co-located/inside the ARPF? This would mean different requirements to be considered. Hpe: implementation issue. Tim (Vodafone) proposed to organize a conference call before the next meeting. Adrian (Qualcomm) will chair the call. Minutes were to be created and delivered to the next SA3 meeting. Georg (SA Chair) proposed to sync with CT4 on the call.	not pursued	No		S3‑191986
		S3‑191936	Requirements on UDM/ARPF	Gemalto, Nokia	CR	Approval	Yes	YesORANGE: why are the UDM and ARPF together? Nokia: we are not consider them as separate identities and SA2 is wrong in their specification. Vodafone didn't support the CR. The main issue comes from the virtualization, and the virtualization study should take care of this. The same with the following CRs. Alf(Docomo): we would need a WID to have something normative agreed in Rel-16. I'd rather have a separate SID rather than putting it into the virtualization. The Chair commented that the objective was to create CRs to follow SA's guidance on the Release 15 open issues. Alex (BT): this CR doesn't fix the security issue requested in SA, which is the key storage not being done somewhere else necessarily ideal. This is not easy work and it needs further consideration. He suggested to drop the standardization in Rel-15 and fix it properly in Release 16. That would save a lot of time. Telecom Italia: practical consequences of doing nothing? The Chair understood that there would be none. Alex: the risk exists in 4G equally.In practical terms for the implementations in Rel-15 is to reduce the level of virtualization in some of the interfaces around ARPF. We leave it to the vendors to solve this. This was left open for offline discussion.	not pursued	No
		S3‑192334	Requirements on UDM/ARPF	Gemalto, Nokia	CR	Approval	No	Yes	withdrawn	Yes
		S3‑192055	Update on ARPF	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesVodafone: same comment as the previous CR. We only need to change the definition. Alex (BT): UDM cannot encrypt this. ORANGE didn’t agree with the second change at all. This had to be taken offline.	not pursued	No
		S3‑192054	Missing UDR description in alignment with 29.505	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesORANGE: having the "may be stored in the UDR" means that it is possible to store it somewhere else than the UDM. We need to require the storage somewhere with a "shall". Vodafone objected to this contribution as well.	not pursued	No		S3‑191420
		S3‑192053	Requirement on UDR	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesTelecom Italia: the "e,g, permanent key" is not enough. We are not being precise enough. Alex (BT): the requirement should be on the subscription to the UDR data only. And the authentication is separable from the authentication of any other type of data.	not pursued	No
		S3‑192046	Requirements for credential storage in the UDR	Ericsson	CR	Agreement	Yes	YesVodafone: not for Rel-15, but good input for virtualization.	not pursued	No
		S3‑192056	Adding Nudr service	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesORANGE: don't agree with the bullet "identifier store in UDM/ARPF…". It's implementation specific. Nokia: this is what's done in CT4. China Mobile: this looks like a new feature rather than a correction. Vodafone rejeted the document.	not pursued	No		S3‑191421
		S3‑192182	Clarification on authentication vector generation	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesORANGE: don’t agree with the sentence about the proprietary repository of the operator. Not part of the standard. Vodafone rejected the document as well: Not Rel-15, better for virtualization part.	not pursued	No
		S3‑192259	Authentication Data Storage in 5G UDR for Release 15	Hewlett-Packard Enterprise	CR	Approval	Yes	YesORANGE: not happy with the second change as it looks like a new requirement modifying the existing requirement. Alf (NTT-Docomo): similar problems with the second change. Vodafone: is trust boundary defined anywhere? They agreed with the rest of the change. The second change seemed to be allowing and forbidding SA3 at the same time. Alex (BT): you're forbidding anyone in the network to access the UDR except the ARPF.I get the concept but it's far more nuanced. ORANGE; "shall reside" is an implementation issue, not our problem here.	not pursued	No
		S3‑191881	[DRAFT] LS to SA2 for Moving Forward on Storing Authentication Data	Hewlett-Packard Enterprise	LS out	Approval	Yes	Yes	noted	No
		S3‑191882	[DRAFT] LS to CT4 for Moving Forward on Storing Authentication Data	Hewlett-Packard Enterprise	LS out	Approval	Yes	Yes	noted	No
		S3‑191999	Correction of reference to draft-ietf-emu-rfc5448bis	Ericsson	CR	Agreement	Yes	YesQualcomm didn't agree with the change. No update here until the IETF document is updated. The change should also be done in Rel-16. not Rel-15. Qualcomm: leave the annex F as it is in Rel-15. As for the rest, wait until the IETF is updated. ORANGE supported this. China Mobile: we don’t reference drafts in 3GPP. The Chair clarified that this draft-referencing was currently done in 3GPP. The Chair added that the use of a reference in an editor's note was incorrect according to the current procedure with CT1. Qualcomm: delete the editor's note in Release 15 and follow Annex F; come back with this issue in Release 16, where it will not produce any issues. This was kept open in order to resolve the reference issue. Finally not pursued but he way forward will be performed for the next meeting.	not pursued	No
		S3‑192154	Issues on not removing the authentication result in the UDM	Huawei, Hisilicon	discussion	Discussion	Yes	Yes	noted	No
		S3‑192155	Removing the authentication result in the UDM	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: this is not needed. Qualcomm supported this.	not pursued	No
		S3‑192161	Removing the authentication result in the UDM	Huawei, Hisilicon	CR	Approval	Yes	YesSame comments as 2155. The Chair commented that Huawei was welcome to bring a key issue to the study for the next meeting in order to understand better the scenario.	not pursued	No
7.1.9	Secondary authentication
7.1.10	Interworking	S3‑191916	Issues of resetting NAS COUNT values in 5G to 4G mobility	Qualcomm Incorporated	discussion	Endorsement	Yes	YesQualcomm insisted that there was an issue to be considered here.	noted	No
		S3‑191917	NAS Count values in the mapped EPS security context in 5GS to EPS change	Qualcomm Incorporated	CR	Agreement	Yes	YesEricsson: The COUNT value was created for replay protection. If we set the values the same as in 4G we'll be having some issues. Qualcomm: our choice is the simplest, otherwise we need to address this in other WG's specs like CT4. The MME is not aware about the idle mobility between 5G and 4G, for the MME we are only in 4G. This had to be taken offline.	not pursued	No
		S3‑191923	Reply LS on handling of native non-current 5G NAS security context	Qualcomm Incorporated	LS out	Approval	Yes	YesQualcomm: The problem is that there is integrity protection in the Registration request only when there is a native 5G security context. When moving from 5G to 4G the UE shall discard the 5G security context to avoid problems. This wasn't clear for Huawei.	revised	No	S3‑192279
		S3‑192279	Reply LS on handling of native non-current 5G NAS security context	Qualcomm Incorporated	LS out	Approval	Yes	Yes	approved	No		S3‑191923
		S3‑191995	Recommendation to run AKA after IW HO from 4G to 5G	Ericsson	CR	Agreement	Yes	YesNokia: why the recommendation? Ericsson: this is due to the written text under step 10. To take care of the "else" part of this statement. ORANGE wanted to add some statement for the operator. Vodafone: if we have a mapped 5G security context recommended at some point in the authentication why does it go here? Huawei: this is not needed. Docomo: we agreed not force this reauthentication. If you come from a mapped 4G context that is coming from a mapped 5G context you would need this. An operator recommended policy would have an unclear situation where to be applied. It was agreed to refer to the operator's policy and what triggers this. Docomo add a note about the reason for the triggering being the mapped context coming from the 3G context, otherwise there is no way of tracking why we are doing this whenever operators are switching off the 3G network. Nokia commented that this would give an additional requirement on the AMF. This was taken offline.	revised	No	S3‑192285
		S3‑192285	Recommendation to run AKA after IW HO from 4G to 5G	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑191995
		S3‑192218	Description of issue of security context transfer following the handover from EPS to 5GS	Huawei, Hisilicon	discussion	Discussion	Yes	YesQualcomm disagreed with the scenario. Option 2 was not backward compatible hence not possible for Rel-15. Ericsson preferred option 1, although the CR was based on option 2. Nokia wasn't convinced about the issue.	noted	No		S3‑192156
		S3‑192151	Clarification on security context transfer during handover from S1 mode to N1 mode	Huawei, Hisilicon	CR	Approval	Yes	YesBased on option 2 of tdoc 2218. Huawei: There may be issues that need further study here. Qualcomm didn’t see any issues.	not pursued	No
		S3‑192156	Description of issue of security context transfer following the handover from EPS to 5GS	Huawei, Hisilicon	CR	Discussion	Yes	Yes	revised	No	S3‑192218
		S3‑192157	Discussion on the inconsistency of eKSI in idle mode mobility from 5GS to EPS over N26	Huawei, Hisilicon	discussion	Approval	No	Yes	withdrawn	Yes
		S3‑192158	Clarification on the eKSI in idle mode mobility from 5GS to EPS over N26	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: we might have to involve CT1 here. The Chair clarified that CT1 may not do anything else for Release 15. This was left open for discussion.	not pursued	No
		S3‑192162	Changes on handover from EPS to 5GS over N26	Huawei, Hisilicon	CR	Approval	Yes	YesORANGE: maybe you have to remove NOTE 2 as well.	agreed	No
7.1.11	non-3GPP access
7.1.12	NDS
7.1.13	Service based architecture
7.1.13.1	Interconnect (SEPP related)
7.1.13.2	Other
7.1.14	Privacy	S3‑192226	Modification on the usage of Identity Request	Apple (UK) Limited	CR	Endorsement	Yes	Yes	revised	No	S3‑192280
		S3‑192280	Modification on the usage of Identity Request	Apple (UK) Limited	CR	Endorsement	Yes	YesORANGE: Identity request is part of the registration procedure. Docomo: There is value in this. Make it Rel-16. It protects the privacy of a single UE and it prevents DoS attacks. Qualcomm: we have this clarified in another clause. Not needed. Ahmad (Futurewei): the UE shall ignore if the request is coming out of the authentication procedure; I'm not sure if this is included in Release 15. Nokia: AMF can reauthenticate the UE anytime it wants, by sending the auth request to the UE. This is not needed. Qualcomm: we agreed to remove the requirement due to an LS from CT1 (S3-191121). Why adding this again? CT1 would have an issue. Intel: this is already covered somewhere else. Apple: we need to reconsider this. Qualcomm: after checking CT1 specs, we have found that this is not correct.	not pursued	No		S3‑192226
7.1.15	Incoming and outgoing Lses	S3‑191846	LS on support of non-3GPP only UE and support for PEI in IMEI format	S2-1904836	LS in		Yes	Yes	replied to	No
		S3‑192278	Reply to: LS on support of non-3GPP only UE and support for PEI in IMEI format	BT	LS out	approval	Yes	YesIt was agreed to reply with "Reuse the same as in 3GPP access."	approved	No
		S3‑191847	Response LS on support of non-3GPP only UE and support for PEI in IMEI format	s3i190363	LS in		Yes	Yes	noted	No
		S3‑191839	Further LS relating to “Response LS on reporting all Cell IDs in 5G”	S2-1906170	LS in		Yes	Yes	noted	No
		S3‑191830	Reply LS on Security failure of NAS container in HO command	C1-193708	LS in		Yes	YesAready taken care of.	noted	No
		S3‑192264	LS on handling of native non-current 5G NAS security context after an inter-system change from S1 mode to N1 mode in idle mode	C1-193944	LS in	Information	Yes	YesQualcom's response reply in tdoc 923.	replied to	No
		S3‑191832	Reply LS on Clarification for N32 security	C4-192467	LS in		Yes	Yes	noted	No
		S3‑191842	Reply LS on Clarification request on NF authorization in UE Reachability Notification Request procedure	S2-1906636	LS in		Yes	Yes	noted	No
		S3‑191831	LS on handling of native non-current 5G NAS security context after an inter-system change from S1 mode to N1 mode in idle mode	C1-193944	LS in		Yes	Yes	withdrawn	Yes
7.1.16	Others	S3‑192142	Correnction of Reference	China Mobile	CR	Approval	Yes	Yes	revised	No	S3‑192333
		S3‑192333	Correnction of Reference	China Mobile	CR	Approval	Yes	YesChanges on the cover sheet.	agreed	No		S3‑192142
		S3‑192248	Privacy protection for non-3GPP in 33.402	Apple (UK) Limited	discussion	Agreement	Yes	Yes	revised	No	S3‑192274
		S3‑192274	Privacy protection for non-3GPP in 33.402	Apple (UK) Limited	discussion	Agreement	Yes	Yes	noted	No		S3‑192248
		S3‑192231	Privacy protection for non-3GPP in 33.402	Apple (UK) Limited	CR	Endorsement	Yes	Yes	revised	No	S3‑192275
		S3‑192275	Privacy protection for non-3GPP in 33.402	Apple (UK) Limited	CR	Agreement	Yes	YesORANGE: This is not applicable for 5G but only for 4G. Telecom Italia agreed. Ericsson: this is a category B CR (new feature) and it needs a WID. Huawei was also concerned about this since even 5G could be impacted. ORANGE preferred to discuss a study item on this. Ericsson: backward compatibility, bidding down, LI impact. Alex(BT): there are far more security holes in 4G that have preference over this one. I don’t mind having a study, though. I'd rather go to 5G issues first.	not pursued	No		S3‑192231
		S3‑192244	LS on Integrity protection data rate enumeration	Apple	LS out	Decision	Yes	Yes	revised	No	S3‑192434
		S3‑192434	LS on Integrity protection data rate enumeration	Apple	LS out	Decision	Yes	YesVodafone asked to minute: this means that handsets will provide integrity protection at full rate/fastest speed possible. This is clearly a big problem, as a note for the companies rejecting this LS. ORANGE supported Vodafone. Alex (BT) supported Vodafone as well. Not all handsets high end and low end, will support this capability, it is not realistic. Vodafone asked to be minuted: we are disgusted that our customers will be insecure. ORANGE asked for reasons for not sending this LS but there was no reason given. This statement was asked to be minuted as well.	noted	No		S3‑192244
		S3‑192245	UP IP data rate	Apple (UK) Limited	discussion	Decision	Yes	YesVodafone supported this. No backward compatibilities issues here.ORANGE supported the LS as well. Alf (Docomo): Handsets that cannot do integrity protection are limited to 64Kb/s in software and in hardware have a determined supported data rate. I hope this will not be required. Colin (BT): concerns on something in the network not supporting this and having to be dropped down due to the high requirements. Vodafone: customers will need this integrity protection. Alf: If you have chispets that can do those values while supporting higher data rates there is no point in supporting this. Qualcomm: this proposal should be discussed in RAN2 if they want to revisit this. The Chair asked if this was for Rel-15 or Rel-16. Apple replied that ideally Rel-15 and if not rel-16. The Chair commented that Rel-15 was frozen and no more changes could be done as requested by CT groups. Nokia asked whether this values were coming from, what they were based on. Alex (BT): I support needing high data rates, but review CT1 specs for these values. This was taken offline.	noted	No
7.2	Security Assurance Specification for 5G (SCAS_5G) (Rel-16)
7.2.1	NR Node B (gNB) (TS 33.511)	S3‑191961	Add abbreviation and correct references	Futurewei Technologies	CR	Agreement	Yes	Yes	agreed	No
		S3‑192006	STRIDE diagram for the gNB	Ericsson	discussion	Discussion	Yes	YesHuawei: Is this for the TR or TS? Ericsson: this is for discussion purposes only. Assest and threats would be the next step.	noted	No
7.2.2	Access and Mobility Management Function (TS 33.512)	S3‑192163	Completing TS 33.512	Huawei, Hisilicon, Deutsche Telekom AG	pCR	Approval	Yes	Yes	revised	No	S3‑192288
		S3‑192288	Completing TS 33.512	Huawei, Hisilicon, Deutsche Telekom AG	pCR	Approval	Yes	Yes	approved	No		S3‑192163
		S3‑192179	Addition of AMF-related Security Problem Descriptions	Huawei, Hisilicon	CR	Approval	Yes	YesNokia: what happens if we have incorrect handling in X.2.2.3? The title needs to be changed. Nokia: remove the "waste of time" statement. Ericsson: who's the attacker here? Can you clarify it in the text? Ericsson suggested some other editorials to be fixed as well. It was clarified that this was intended to be input for the draftCR (which appears as a baseline). The CR is not pursued but the input to the draftCR is revised into tdoc 2286.	not pursued	No
		S3‑192286	Addition of AMF-related Security Problem Descriptions	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No
		S3‑192287	DraftCR on Assests and threats specific to the AMF	Huawei	draftCR	Approval	Yes	Yes	approved	No
		S3‑192403	Draft TS 33.512	Huawei	draft TS	Approval	No	Yes	eft for email approval	No
7.2.3	User Plane Function (UPF) (TS 33.513)	S3‑192164	Completing TS 33.513	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192291
		S3‑192291	Completing TS 33.513	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192164
		S3‑192165	Adding UPF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: SBI interfaces should be listed too.	not pursued	No
		S3‑192289	Adding UPF critical assets and threats to TR 33.926	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No
		S3‑192290	DraftCR on Aspects of the network product class UPF	Huawei	draftCR	Approval	Yes	Yes	approved	No
		S3‑192292	Draft TS 33.513	Samsung	draft TS	Approval	No	Yes	eft for email approval	No
7.2.4	Unified Data Management (UDM) (TS 33.514)	S3‑192130	Adding references, definitions and abbreviations to SCAS UDM	NEC Europe Ltd	pCR	Approval	Yes	Yes	approved	No		S3‑191885
		S3‑192134	Adding introduction text to SCAS UDM	NEC Europe Ltd	pCR	Approval	Yes	Yes	merged	No	S3‑192296	S3‑191886
		S3‑191888	New test case to SCAS UDM: SoR-MAC-IUE verification failure handling	NEC Europe Ltd	pCR	Approval	Yes	Yes	noted	No
		S3‑192167	Adding UDM critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson: list SBI interfaces here, only reference points are mentioned. Huawei: the SBI interfaces area already specified somewhere else. It was agreed to address it later by adding an editor's note. Revised to include some comments from Ericsson's as well. Not pursued since its intention was to be a draftCR. Content will go into tdoc 294.	not pursued	No
		S3‑192294	Adding UDM critical assets and threats to TR 33.926	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No
		S3‑192221	Completing TS 33.514	Huawei, Hisilicon, NEC	pCR	Approval	Yes	YesOverlap with tdoc 2134.	revised	No	S3‑192296	S3‑192166
		S3‑192296	Completing TS 33.514	Huawei, Hisilicon, NEC	pCR	Approval	Yes	Yes	approved	No		S3‑192221
		S3‑192136	Adding content to clause 4.2.3, 4.3 and 4.4 in SCAS UDM	NEC Europe Ltd	pCR	Approval	Yes	Yes	approved	No		S3‑191887
		S3‑191885	Adding references, definitions and abbreviations to SCAS UDM	NEC Europe Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑192130
		S3‑191886	Adding introduction text to SCAS UDM	NEC Europe Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑192134
		S3‑191887	Adding content to clause 4.2.3, 4.3 and 4.4 in SCAS UDM	NEC Europe Ltd	pCR	Approval	Yes	Yes	revised	No	S3‑192136
		S3‑192166	Completing TS 33.514	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192221
		S3‑192293	Draft TS 33.514	NEC	draft TS	Approval	No	Yes	eft for email approval	No
		S3‑192295	DraftCR on aspects specific to the network product class UDM	Huawei	draftCR	Approval	Yes	Yes	approved	No
7.2.5	Session Management Function (SMF) (TS 33.515)	S3‑192168	Adding test case for UE security policy comparison during handover	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192298
		S3‑192298	Adding test case for UE security policy comparison during handover	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192168
		S3‑192169	Completing TS 33.515	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192300
		S3‑192300	Completing TS 33.515	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192169
		S3‑192170	Adding SMF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesHuawei: add a paragraph on protecting the user traffic data. Ericsson: charging ID uniqueness is not security related. In the end, it was decided to leave it. This CR was not pursued but the content will go into a draft CR in tdoc 2297.	not pursued	No
		S3‑192297	DraftCR on Adding SMF critical assets and threats to TR 33.926	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑192181	Adding a test case for charging id uniqueness	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192301
		S3‑192301	Adding a test case for charging id uniqueness	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192181
		S3‑192299	Draft TS 33.515	Huawei	draft TS	Approval	No	Yes	eft for email approval	No
7.2.6	Authentication Server Function (AUSF) (TS 33.516)	S3‑192172	Adding AUSF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	Yes. This CR was not pursued but the contents will go into tdoc 302.	not pursued	No
		S3‑192302	Adding AUSF critical assets and threats to TR 33.926	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑192042	STRIDE diagram for the AUSF	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑192043	Attack tree for sensitive data in AUSF	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑192044	AUSF assets and threats	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑192045	Living document: AUSF aspects in 33.926	Ericsson	draftCR	Approval	Yes	YesOverlap with tdoc 172.	merged	No	S3‑192302
		S3‑192171	Completing TS 33.516	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192303	Draft TS 33.516	Ericsson	draft TS	Approval	Yes	Yes	approved	No
7.2.7	Security Edge Protection Proxy (SEPP) (TS 33.517)	S3‑192143	Living Document: New Annex for the SEPP in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	revised	No	S3‑192304
		S3‑192304	Living Document: New Annex for the SEPP in TR 33.926	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	approved	No		S3‑192143
		S3‑192186	Threat Analysis of Incorrect Handling for Protection Policies Mismatch by the SEPP	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	revised	No	S3‑192305
		S3‑192305	Threat Analysis of Incorrect Handling for Protection Policies Mismatch by the SEPP	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesClarify the mistmatch in the threat description. Removes IPX provider in the threat description and it fixes some typos.	approved	No		S3‑192186
		S3‑192189	Test Case: Correct Handling of Protection Policy Mismatch in the SEPP	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192306
		S3‑192306	Test Case: Correct Handling of Protection Policy Mismatch in the SEPP	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192189
		S3‑192192	Threat Analysis on Weak JWS Algorithm	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	revised	No	S3‑192308
		S3‑192308	Threat Analysis on Weak JWS Algorithm	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesRemoving examples from the threat description.	approved	No		S3‑192192
		S3‑192194	Test Case: JWS Profile Restriction in the SEPP	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192309
		S3‑192309	Test Case: JWS Profile Restriction in the SEPP	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192194
		S3‑192180	Updating SEPP critical assets and threats in TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesIt overlaps with 2184. The CR (should have been a draftCR) is not pursued butThe content will be merged into 310.	not pursued	No
		S3‑192184	Threat Analysis on Exposure of Confidential IEs in N32-f message	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	revised	No	S3‑192310
		S3‑192310	Threat Analysis on Exposure of Confidential IEs in N32-f message	Nokia, Nokia Shanghai Bell,Huawei	draftCR	Approval	Yes	Yes	approved	No		S3‑192184
		S3‑192197	Updating TS 33.517 with the Threat Reference for the Test Case in 4.2.2.5	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑192311
		S3‑192173	Completing TS 33.517	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192311
		S3‑192311	Completing TS 33.517	Huawei, Hisilicon,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑192173
		S3‑192307	Draft TS 33.517	Nokia	draft TS	Approval	Yes	Yes	approved	No
7.2.8	Network Resource Function (NRF) (TS 33.518)	S3‑192174	Updating TS 33.518	Huawei, Hisilicon, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192312	Draft TS 33.518	Nokia	draft TS	Approval	Yes	Yes	approved	No
7.2.9	Network Exposure Function (NEF) (TS 33.519)	S3‑192175	Completing TS 33.519	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192314
		S3‑192314	Completing TS 33.519	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192175
		S3‑192176	Adding NEF critical assets and threats to TR 33.926	Huawei, Hisilicon	CR	Approval	Yes	YesNot pursued as the content will go into the draftCR in tdoc 313.	not pursued	No
		S3‑192313	Adding NEF critical assets and threats to TR 33.926	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No
		S3‑192315	Draft TS 33.519	ZTE	draft TS	Approval	No	Yes	eft for email approval	No
7.2.10	Others	S3‑192137	Living Document: General SBA/SBI aspects in TS 33.117	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	revised	No	S3‑192316
		S3‑192316	Living Document: General SBA/SBI aspects in TS 33.117	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	approved	No		S3‑192137
		S3‑192177	adding critical assets and threats to TR 33.926 for general SBA/SBI aspects	Huawei, Hisilicon	CR	Approval	Yes	YesRevised content will go to the contribution to the draftCR in 317.	not pursued	No
		S3‑192317	adding critical assets and threats to TR 33.926 for general SBA/SBI aspects	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No
		S3‑192138	Addition Assets and Threats for Generic NFs	Nokia, Nokia Shanghai Bell	CR	Approval	Yes	YesContent is merged in 317.	not pursued	No
		S3‑192178	Update of living Document: General SBA/SBI aspects in TS 33.117	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	revised	No	S3‑192318
		S3‑192318	Update of living Document: General SBA/SBI aspects in TS 33.117	Huawei, Hisilicon	draftCR	Approval	Yes	Yes	approved	No		S3‑192178
		S3‑192141	Updating the Living Document with Threat References	Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	merged	No	S3‑192318
7.3	eMCSec R16 security (MCXSec) (Rel-16)	S3‑191834	Observations on standards and technical constraints from 3rd MCX remote Plugtests	ETSI CTI	LS in		Yes	YesMotorola commented that CT1 proposed that everything went all through them, given that there was an additional LS from CT1 to which SA3 will reply directly instead of this one. CTI will be in copy in that LS whereas this one will be noted.	noted	No
		S3‑191861	[33.180] R16 - Fix hash result (mirror)	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No
7.4	Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16)	S3‑191989	Living doucment for 5G_UTRAN_SEC	China Unicom	draftCR		Yes	YesEricsson noted that this needed to show the changes are revision marks.	revised	No	S3‑192335
		S3‑192335	Living doucment for 5G_UTRAN_SEC	China Unicom	draftCR	-	No	Yes	approved	No		S3‑191989
		S3‑192067	Dicussion on security handling after voice call ends	Huawei, Hisilicon	discussion	Endorsement	Yes	YesAlex (BT): the call drops down to the lower technology and stays down as agreed in SA. This is against that and I object to this proposal.	noted	No
		S3‑192068	security handling after voice call ends	Huawei, Hisilicon	CR	Approval	Yes	Yes	not pursued	No
		S3‑192011	SRVCC keys	China Unicom	draftCR		Yes	Yes	approved	No
		S3‑192012	key generation in MME_SRVCC	China Unicom	other		Yes	YesQualcomm: this implies additional signalling that we don’t need. It overlaps with our proposal in 903. It was agreed to go for Qualcomm's contribution that deleted the editor's note where both overlapped.	noted	No
		S3‑192010	Rename the derived key	China Unicom	draftCR		Yes	Yes	merged	No	S3‑192336
		S3‑191903	Proposed updates to the draft CR on SRVCC from 5G to UTRAN CS	Qualcomm Incorporated	other	Approval	Yes	YesDeleting the editor's note that’s being modified by China Unicom in 2012.	revised	No	S3‑192336
		S3‑192336	Proposed updates to the draft CR on SRVCC from 5G to UTRAN CS	Qualcomm Incorporated,China Unicom	other	Approval	Yes	Yes	approved	No		S3‑191903
		S3‑191904	Assigning a FC value to TS 33.501 for K5GSRVCC calculation	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑192337
		S3‑192337	Assigning a FC value to TS 33.501 for K5GSRVCC calculation	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑191904
		S3‑191905	Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑192338
		S3‑192338	Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑191905
		S3‑191906	Revision of SRVCC WID	Qualcomm Incorporated	WID revised	Agreement	Yes	YesORANGE: it doesn’t make sense to keep the UICC being modified "don’t know". IDEMIA and Gemalto disagreed with having to revise the WID to change the impact.	agreed	No
7.5	Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16)	S3‑192215	Editorial correction of CAPIF-3e/4e/5e requirements clause	Samsung	CR	Approval	Yes	Yes	agreed	No
		S3‑191937	Requirement on authenticating unpublish requests	Ericsson	CR		Yes	YesSamsung: we don't need this requirement, it’s already covered.	not pursued	No
		S3‑192213	Security procedures for CAPIF-3e/4e/5e reference points	Samsung	CR	Approval	Yes	YesNokia didn't agree with this contribution. NCSC: N32 is quite heavy weight, more complicated than it appears here.	not pursued	No
		S3‑192214	Security aspects of CAPIF-7/7e reference points	Samsung	CR	Approval	Yes	Yes	revised	No	S3‑192339
		S3‑192339	Security aspects of CAPIF-7/7e reference points	Samsung	CR	Approval	Yes	YesThird change goes away.	agreed	No		S3‑192214
7.6	Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)	S3‑192125	draftCR for URLLC TS	Huawei, Hisilicon	draftCR	Approval	Yes	YesQualcomm: some parts of this are still in the air and we need some conclusions before agreeing on this. Let's wait for the next meeting. Nokia supported this. Huawei commented that this was a living document and could be changed anytime according to the discussions. Qualcomm didn’t agree with the introduction either. It was decided to come back to the next meeting with this. It was the general idea that the objective was to introduce this content in an annex to TS 33.501, so it was expected to bring back a similar contribution to the next meeting.	noted	No
7.7	Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)	S3‑192058	NPN references in existing text	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesORANGE didn't agree with this CR. There was no previous agreement on adding an Annex.They had some other issues that were shared by Gemalto.Vodafone didn’t agree with referencing to Annex Z this way. Anja(Nokia) commented that she would bring another proposal for the next meeting. Gemalto: each time there's a new annex, the 5G core part would be impacted and we would need to be changing it constantly.	not pursued	No
7.8	Other work areas
7.8.1	SAE/LTE Security	S3‑191954	Clarification of NIA0 with SgNB for UE NR capability	Intel China Ltd.	CR		Yes	YesEricsson: there is impact on CT1. Qualcomm was fine with the change.	agreed	No
7.8.2	IP Multimedia Subsystem (IMS) Security
7.8.3	Network Domain Security (NDS)
7.8.4	UTRAN Network Access Security
7.8.5	GERAN Network Access Security
7.8.6	Generic Authentication Architecture (GAA)
7.8.7	Security Aspects of Home(e)NodeB (H(e)NB)
7.8.8	Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)	S3‑191829	LS on ETSI Plugtest standards Issues	C1-193601	LS in		Yes	Yes	replied to	No
		S3‑192332	Reply to: LS on ETSI Plugtest standards Issues	Motorola Solutions	LS out	approval	Yes	Yes	approved	No
		S3‑191860	[33.180] R15 - Fix hash result	Motorola Solutions Germany	CR	Agreement	Yes	Yes	agreed	No
7.8.9	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)	S3‑192037	Corrections on IP packet forwarding	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑192038	Corrections on IP packet forwarding	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑192319
		S3‑192319	Corrections on IP packet forwarding	Ericsson	CR	Agreement	Yes	YesFixing some cover page errors.	agreed	No		S3‑192038
		S3‑192039	Corrections on IP packet forwarding	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑192320
		S3‑192320	Corrections on IP packet forwarding	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑192039
		S3‑192040	Threat analysis for OAM configurator spoofing	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑192041	Living document: generic assets and threats	Ericsson	draftCR	Approval	Yes	Yes	revised	No	S3‑192321
		S3‑192321	Living document: generic assets and threats	Ericsson	draftCR	Approval	Yes	Yes	approved	No		S3‑192041
		S3‑192092	Propose fuzz tests run 100 000 times	Huawei, Hisilicon	CR	Approval	Yes	YesEricsson wasn't sure about stating out a number like 10000. Huawei: there should be a baseline about the number of runs for the tester. It was agreed to remove the number. Some errors on the CR cover page were also pointed out.	revised	No	S3‑192322
		S3‑192322	R16_Carification for Fuzz tests run	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192092
		S3‑192093	R15_clarification for Fuzz tests run	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192323
		S3‑192323	R15_clarification for Fuzz tests run	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192093
		S3‑192094	R14_clarification for Fuzz tests run	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192324
		S3‑192324	R14_clarification for Fuzz tests run	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192094
		S3‑192095	Clairication on the intention of the requirment	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192325
		S3‑192325	Clairication on the intention of the requirment	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192095
		S3‑192096	R15_Mirror_Clairication on the intention of the requirment	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192326
		S3‑192326	R15_Mirror_Clairication on the intention of the requirment	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192096
		S3‑192097	R14_Mirror_Clairication on the intention of the requirment	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192327
		S3‑192327	R14_Mirror_Clairication on the intention of the requirment	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192097
		S3‑192098	A document is needed to show the support features	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192350
		S3‑192350	A document is needed to show the support features	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192098
		S3‑192099	R15_Mirror_A document is needed to show the support features	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192351
		S3‑192351	R15_Mirror_A document is needed to show the support features	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192099
		S3‑192100	R14_Mirror_A document is needed to show the support features	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192352
		S3‑192352	R14_Mirror_A document is needed to show the support features	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192100
		S3‑192101	Align account numbers in testcase with the requirement	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192329
		S3‑192329	Align account numbers in testcase with the requirement	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192101
		S3‑192102	R15_Mirror_Align account numbers in testcase with the requirement	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192330
		S3‑192330	R15_Mirror_Align account numbers in testcase with the requirement	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192102
		S3‑192103	R14_Mirror_Align account numbers in testcase with the requirement	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑192331
		S3‑192331	R14_Mirror_Align account numbers in testcase with the requirement	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑192103
7.8.10	Security Aspects of Narrowband IOT (CIoT)
7.8.11	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)
7.8.12	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.8.13	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
7.8.14	PLMN RAT selection (Steering of Roaming) (Rel-15)
7.8.15	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)	S3‑192007	Discussion Document on the evolution of BEST	VODAFONE Group Plc	discussion	Discussion	No	Yes	withdrawn	Yes
7.8.16	Other work items	S3‑192008	WID on BEST Test Specificationd for HSE and UE	VODAFONE Group Plc	WID new	Agreement	Yes	YesQualcomm: test specs are developed in RAN5. Vodafone: we did it for TUAK and all algorithms we've had in the past. Qualcomm: test specs that we agree that are in our scope.RAN5 write tests not only for RAN, but for other groups.Interoperability and protocol performance test cases are done in RAN5. They even have for IMS. Interdigital agreed. Vodafone: RAN5 has no expertise for this work. Alf (Docomo): ask RAN5 with an LS. Vodafone: we will not go to RAN5 under any circumstances. MCC: this cannot be done for Release 15 as a Rel-16 version of TS 33.163 already exists and the work will be done there. This had to be taken offline.	noted	No
7.9	New Work Item proposals	S3‑192047	New WID on evolution of Cellular IoT security for the 5G System	Ericsson	WID new	Agreement	Yes	YesVodafone: the WID doesn’t detail enough the justification and objectives. MCC agreed, it seemed too brief and it needed some more wording.	revised	No	S3‑192354
		S3‑192354	New WID on evolution of Cellular IoT security for the 5G System	Ericsson	WID new	Agreement	Yes	Yes	agreed	No		S3‑192047
		S3‑192104	WID on Security of the Wireless and Wireline Convergence for the 5G system architecture	Huawei, Hisilicon	WID new	Approval	Yes	YesVodafone: the objectives need rewording.	revised	No	S3‑192355
		S3‑192355	WID on Security of the Wireless and Wireline Convergence for the 5G system architecture	Huawei, Hisilicon	WID new	Approval	Yes	Yes	agreed	No		S3‑192104
8	Studies
8.1	Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)	S3‑192035	Correction of implementation of S3-191671	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192246	Discussion paper on resource level authorization using OAuth 2.0 access tokens	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑192247	Key Issue on resource level authorization during service access	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192412
		S3‑192412	Key Issue on resource level authorization during service access	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192247
		S3‑192249	pCR – Solution for resource level authorization using access tokens	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192258	pCR to 33.855 on NF authorization with SeCoP	NTT DOCOMO INC.	pCR	Approval	Yes	Yes	approved	No		S3‑192256
		S3‑192250	Discussion paper on policy-based authorization for indirect communication	Nokia, Nokia Shanghai Bell	discussion	-	Yes	Yes	noted	No
		S3‑192251	pCR on Policy based authorization for Indirect communications	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192413
		S3‑192413	pCR on Policy based authorization for Indirect communications	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesORANGE: SA2 is using the term SCP for something else. Change the name.	approved	No		S3‑192251
		S3‑192033	New solution: Token-based authorization for Scenario D using stateless SeCoP	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑192439
		S3‑192439	New solution: Token-based authorization for Scenario D using stateless SeCoP	Ericsson	pCR	Approval	Yes	YesAdding two editor's notes.	approved	No		S3‑192033
		S3‑192034	New solution: Token-based authorization for Scenario C using stateless SeCoP	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑192440
		S3‑192440	New solution: Token-based authorization for Scenario C using stateless SeCoP	Ericsson	pCR	Approval	Yes	YesAdding three new edtior's notes.	approved	No		S3‑192034
		S3‑192150	Solution for NF service consumer verification during service access authorization	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192441
		S3‑192441	Solution for NF service consumer verification during service access authorization	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192150
		S3‑192152	Evaluation of solution #15 in TR 33.855 - Delegated "Subscribe-Notify" interaction Authorization	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192153	Update of solution #19 in TR 33.855 - Authorization within a NF Set	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192442
		S3‑192442	Update of solution #19 in TR 33.855 - Authorization within a NF Set	Huawei, Hisilicon,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑192153
		S3‑192253	Solution for Authorization of NFs within a NF Set	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑192442
		S3‑192254	pCR to 33.855 on SeCoP distribution	NTT DOCOMO INC.	pCR	Approval	Yes	Yes	revised	No	S3‑192443
		S3‑192443	pCR to 33.855 on SeCoP distribution	NTT DOCOMO INC.	pCR	Approval	Yes	Yes	approved	No		S3‑192254
		S3‑192252	pCR on NF to SeCoP interface security in service-mesh based deployments	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192255	pCR on removing EN in Solution #21	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192444
		S3‑192444	pCR on removing EN in Solution #21	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192255
		S3‑192256	pCR to 33.855 on NF authorization with SeCoP	NTT DOCOMO INC.	pCR	Approval	Yes	Yes	revised	No	S3‑192258
		S3‑192365	Minutes of the SBA offline session	Ericsson	report	Information	Yes	Yes	noted	No
		S3‑192438	Draft TR 33.855	Ericsson	draft TR	Approval	No	Yes	eft for email approval	No
8.2	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)
8.3	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
8.4	Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
8.5	Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)	S3‑192187	Meeting minutes of AKMA conference calls	China Mobile	report	Information	Yes	Yes	noted	No
		S3‑192211	Meeting minutes of AKMA conference call on 4th June	China Mobile	report	Information	Yes	Yes	noted	No
		S3‑192190	Work Plan for moving forward AKMA	China Mobile	discussion		Yes	Yes	noted	No
		S3‑192146	New KI: AKMA push	Huawei, Hisilicon	pCR	Approval	Yes	YesQualcomm: not sure that we need this. GBA Push is not really used. There is no use case for this.Vodafone commented that it was used. ORANGE: reword the requirement.	revised	No	S3‑192428
		S3‑192428	New KI: AKMA push	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192146
		S3‑192160	Solution for AKMA push	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: remove the evaluation. Ericsson: User identity should be clarified in step one of the figure.	revised	No	S3‑192429
		S3‑192429	Solution for AKMA push	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192160
		S3‑192263	New solution: Integrating GBA to 5GC	Ericsson Hungary Ltd	pCR	Approval	Yes	YesORANGE didn't support bringing old GBA into 5G. Something new should be created. Qualcomm and China Mobile supported this. Out of scope. Vodafone: how are GBA services evolving into 5G then?	noted	No		S3‑192005
		S3‑192220	Implicit bootstrapping using NEF as the AKMA Anchor Function	Nokia, Nokia Shanghai Bell, China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑192000	Solution 2 evaluation	Ericsson	pCR	Approval	Yes	YesORANGE: second bullet point in the advantages needs to go away. Qualcomm: authentication procedure overhead needs to be pointed out.	revised	No	S3‑192450
		S3‑192450	Solution 2 evaluation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192000
		S3‑192001	Solution 3 evaluation	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑192451
		S3‑192451	Solution 3 evaluation	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192001
		S3‑191877	Update of solution #17 - Efficient key derivation for e2e security	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑191890	Resolving Editor’s Notes and adding conclusion to solution #18	NEC Europe Ltd	pCR	Approval	Yes	Yes	approved	No
		S3‑191891	Resolving Editor’s Notes and adding conclusion to solution #20	NEC Europe Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑192002	Solution #15 updates including evaluation update	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑192003	Solution #13 evaluation	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑192065	Resovle Editor's notes in Solution for Key freshness in AKMA	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192126	Evaluation for solution	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192196	Individual Evaluation of solution #6	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑192198	Individual Evaluations of solution #7- #12	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑192207	Evaluation of solution#1- Introducing third party key to AKMA	China Mobile	pCR		Yes	Yes	not treated	No
		S3‑191878	AKMA solution set analysis	KPN	discussion	Discussion	Yes	Yes	noted	No
		S3‑192201	Discussion on AKMA overall evaluation methodology	China Mobile, ZTE Corporation	discussion	Endorsement	Yes	YesVodafone: no evaluation on how this evolves from GBA here. This is replacing GBA. Qualcomm: don’t mix GBA and AKMA.They're different. This is a separate document. ORANGE didn’t understand the classification of the key issues.	noted	No
		S3‑192204	skeleton of clause 7- evaluation and conclusion	China Mobile	pCR		Yes	YesORANGE: 7.5 will be the API on the UE, not implementations.	revised	No	S3‑192427
		S3‑192427	skeleton of clause 7- evaluation and conclusion	China Mobile	pCR	-	Yes	Yes	approved	No		S3‑192204
		S3‑191889	Discussion on AKMA overall conclusions	NEC Europe Ltd	discussion	Endorsement	Yes	YesKPN disagreed with the contribution. Qualcomm: endorse proposal one. Nokia supported this. The Chair asked for a show of hands: ORANGE, Nokia, ZTE,Qualcomm,china mobile,Huawei, NEC supported proposal one. Ericsson, KPN,Gemalto, Vodafone didn’t support endorsing this.	noted	No
		S3‑192193	Editorial Changes to TR 33.835 v0.4.0	China Mobile	pCR	Approval	Yes	Yes	approved	No
		S3‑191892	Editorial corrections of AKMA TR 33.835 v0.4.0	NEC Europe Ltd	pCR	Approval	Yes	Yes	approved	No
		S3‑192005	New solution: Integrating GBA to 5GC	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑192263
		S3‑192430	Draft TR 33.835	China Mobile	draft TR	Approval	No	Yes	eft for email approval	No
8.6	Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)	S3‑191893	Editorial correction of TR 33.861	NEC Europe Ltd	pCR	Approval	Yes	Yes	approved	No
		S3‑192106	Update Solution 17 to Supplement Missing Part When Merging with S3-191389	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191872	New KI: Sleep deprivation attacks to CIOT terminals	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: this will not work as it is proposed. Intel agreed and commented that the UE has to wake up to verify the integrity protection anyway. Futurewei: 5G-TMSI cannot be leaked. They also disagreed with the contribution. Alf: delete requirements, keep the key issue for security analysis purposes. Ericsson: we agree with Futurewei, 5G-TMSI is sent after security activation. There was no support for this paper.	noted	No
		S3‑192111	Key Issue for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: S-TMSI size, which is RAN2's concern, is not addressed here. Nokia: Impact of S-TMSI truncation needs a security issue. We will not make the decision of truncating but we need to study the security implications. This would mean rewriting the key issue to address the concerns of RAN2 raised in their LS.	revised	No	S3‑192393
		S3‑192393	Key Issue for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192111
		S3‑191810	Update of Solution Solution #4	Futurewei	pCR	Approval	Yes	Yes	approved	No
		S3‑191835	LS on RRC Connection Re-Establishment for CP for NB-IoT connected to 5GC	R2-1908264	LS in		Yes	Yes	replied to	No
		S3‑191943	Nokia comments on R2-1908264 LS on RRC Connection Re-establishment	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	YesHuawei: this is not a security perspective. Nokia: without an ID the solution will not work.	noted	No
		S3‑191811	Evaluation of Solution #4	Futurewei	pCR	Approval	Yes	Yes	noted	No
		S3‑192397	Evaluation of Solution #4	Futurewei	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑192016	CIOT: add evaluation to solution #4	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191952	Evaluation to Security solution 4 for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT)	Intel China Ltd.	pCR	Approval	Yes	Yes	noted	No
		S3‑191909	Evaluation of the integrity protection provided by EDT solutions #4 and #18	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: in LTE the air interface has no user plane,there is no such bidding down attack. The LTE technology does not support integrity protection. Qualcomm: integrity protection is added in order to have it modified it over the air. Why are we having integrity protection then?	noted	No
		S3‑191876	Update of Solution #6 - Use of UE Configuration Update	KPN	pCR	Approval	Yes	Yes	approved	No
		S3‑192071	Delete EN in solution12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191879	Proposal for editor's note in FS_CIoT_sec_5G solution #15	Philips International B.V.	pCR	Approval	Yes	YesNokia didn’t agree with the change. Futurewei wasn't convinced about the way the editor's notes were handled either.The first two changes went away.	revised	No	S3‑192398
		S3‑192398	Proposal for editor's note in FS_CIoT_sec_5G solution #15	Philips International B.V.	pCR	Approval	Yes	Yes	approved	No		S3‑191879
		S3‑192105	Address EN in solution 17	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson was concerned about how the black list was maintained since the constant change would lead to an increase in signalling. Otherwise they agreed with the change.	approved	No
		S3‑192107	Add Evaluation for Solution 17	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia had the same comment as Ericsson in the previous contribution: maintaining the black list would cause overhead. Ericsson: in the practice they would be multiple black lists. Nokia: this gets complex when considering the mobility part.	revised	No	S3‑192399
		S3‑192399	Add Evaluation for Solution 17	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192107
		S3‑192013	CIoT: Update to Solution #18	Ericsson	pCR	Approval	Yes	YesFuturewei: "potential enhancement" is not referring to anything. I'm against this. Remove reference to key issue integrty protection. This was agreed.	revised	No	S3‑192400
		S3‑192400	CIoT: Update to Solution #18	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192013
		S3‑192014	CIoT: Evaluation to Solution #18	Ericsson	pCR	Approval	Yes	YesOverlapping with 806, 953.	revised	No	S3‑192401
		S3‑192401	CIoT: Evaluation to Solution #18	Ericsson,Futurewei,Intel	pCR	Approval	Yes	Yes	approved	No		S3‑192014
		S3‑191806	Evaluation of Solution Solution #18	Futurewei	pCR	Approval	Yes	Yes	merged	No	S3‑192401
		S3‑191953	Evaluation to Security solution 18 for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT)	Intel China Ltd.	pCR	Approval	Yes	Yes	merged	No	S3‑192401
		S3‑192108	Add Details and Evaluation for Solution 19	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192402
		S3‑192402	Add Details and Evaluation for Solution 19	Huawei, Hisilicon	pCR	Approval	Yes	YesAdding an editor's note on the group of misbehaving UEs as proposed by Ericsson.	approved	No		S3‑192108
		S3‑191920	Solution for integrity protection of EDT	Qualcomm Incorporated	pCR	Approval	Yes	YesFuturewei objected to having this solution because there was a whole study item dedicated to this: user plane integrity protection. This didn’t belong here. Qualcomm: Evaluation in solution 4 and 18 that there is a bidding down risk but we don’t have proper protection against that. Qualcomm: what is the key issue for? Futurewei: it's for when we don’t use the user plane integrity protection completely. Intel supported Qualcomm but proposed to add the evaluation later when the UP IP study had a conclusion.	noted	No
		S3‑192018	CIOT: New solution for UP IP in PDCP to protect UL EDT data in Msg3	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191951	Security solution for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) with legacy fall back	Intel China Ltd.	pCR	Approval	Yes	Yes	revised	No	S3‑192328
		S3‑192328	Security solution for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) with legacy fall back	Intel China Ltd.	pCR	Approval	No	Yes	noted	No		S3‑191951
		S3‑192017	CIOT: Optional support of RRC Inactive in eMTC connected to 5GC	Ericsson	pCR	Approval	Yes	YesFuturewei: If you read RAN2 agreement, NB-IoT is not supported.	noted	No
		S3‑191871	Mitigate DDoS Attacks on RAN based on RAN coordination	Huawei, HiSilicon	pCR	Approval	Yes	YesSamsung didn’t agree with this.	noted	No
		S3‑192019	DDoS protection based on NWDAF and Overload Control	Ericsson	pCR	Approval	Yes	YesHuawei: out of scope of this key issue. The key issue is about how to detect and what to do after detection.	noted	No
		S3‑192115	Solution for Protection of NAS Redirection Message	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: There is a requirement in Rel-15 and there is impact on UE and network, an overhead increase. Remove the evaluation and add another editor's note on why legacy mechanisms are not used here.	revised	No	S3‑192404
		S3‑192404	Solution for Protection of NAS Redirection Message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192115
		S3‑191873	A solution to protect CIOT terminals from sleep deprivation attacks	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192112	Solution for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192452
		S3‑192452	Solution for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192112
		S3‑192113	Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC	Huawei, Hisilicon	LS out	Approval	Yes	Yes	revised	No	S3‑192394
		S3‑192394	Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC	Huawei	LS out	Approval	Yes	Yes	approved	No		S3‑192113
		S3‑192015	CIoT: Conclusion to KI#2 and KI#3	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191812	Conclusion for KI#2 for RRC based solutions	Futurewei	pCR	Approval	Yes	Yes	noted	No
		S3‑191813	Conclusion for KI#3 for RRC signaling based solutions	Futurewei	pCR	Approval	Yes	Yes	noted	No
		S3‑192114	Conclusion for KI#2 and KI#3 of frequent CIoT Ues	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192109	Discussion Paper for Mitigation of DDoS Attack	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes	noted	No
		S3‑192110	conclusion for KI#4	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: no need to do normative work. We agree with SA2 on the fact that we can rely on existing mechanisms. KPN: both Ericsson's (tdoc 2021) and Huawei's conclusions are not correct.	noted	No
		S3‑192021	Conslusion for KI#4	Ericsson	pCR	Approval	Yes	YesSupported by Nokia.	noted	No
		S3‑191870	Conclusion to KI #5	Huawei, HiSilicon	pCR	Approval	Yes	YesDiscussed together with tdoc 2020. Ericsson: the solution will not make a difference if the attacker is a bit more sophisticated. Supported by Qualcomm.	noted	No
		S3‑192020	Conslusion for KI#5	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191980	Conclusion on Key Issue #7	Lenovo, Motorola Mobility	pCR		Yes	YesEricsson: the conclusion is better rely on existing mechanisms. Nokia: this is not necessary.	noted	No
		S3‑192392	Draft TR 33.861	Ericsson	draft TR	Approval	No	Yes	eft for email approval	No
8.7	Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)	S3‑191838	Reply LS on Authentication for UEs not Supporting NAS	S1-191595	LS in		Yes	YesORANGE: they seem to interpret the requirement in a different way. They are not really answering our question.A laptop is not an IoT device.	noted	No
		S3‑191843	LS to BBF on WWC status	S2-1906821	LS in		Yes	Yes	noted	No
		S3‑192083	Delete Editor's in Solution#3 and add evaluation	Huawei, Hisilicon	pCR	Approval	Yes	YesDiscussed with 2222 and 2223. Vodafone: we shouldn’t write in a spec that we need input from BBF unless it's in an editor's note. MCC agreed with this. Nokia: we conclude with what's in our scope and in case BBF comes up with a solution we can update the study.	merged	No	S3‑192382
		S3‑192222	Resolve Editor’s Note in solution 3	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192382
		S3‑192382	Resolve Editor’s Note in solution 3	Nokia, Nokia Shanghai Bell,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑192222
		S3‑192223	WWC - Evaluation of Solution #3	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑192382
		S3‑192084	Delete Editor's in Solution#5 and add evaluation	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192383
		S3‑192383	Delete Editor's in Solution#5 and add evaluation	Huawei, Hisilicon,Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑192084
		S3‑192225	WWC - Resolve Editor’s Note in solution 5	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑192383
		S3‑192232	WWC - Evaluation of Solution #5	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑192383
		S3‑192085	Conclusion on KI#1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192077	Add requirement to KI#2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192089	Merge S3-191319 to solution 4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192228	WWC - Resolve Editor’s Note on Authentication in solution 4	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192385
		S3‑192385	WWC - Resolve Editor’s Note on Authentication in solution 4	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192228
		S3‑192230	WWC - Resolve Editor’s Note on trust in solution 4	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesTaken care of in 2089.	noted	No
		S3‑192224	WWC - Evaluation of Solution #4	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑191988	Conclusion for Key Issue #5	Lenovo, Motorola Mobility	pCR		Yes	Yes	approved	No
		S3‑191987	Removal of Editor’s Note and Addition of Evaluation	Lenovo, Motorola Mobility	pCR		Yes	Yes	revised	No	S3‑192386
		S3‑192386	Removal of Editor’s Note and Addition of Evaluation	Lenovo, Motorola Mobility	pCR	-	Yes	Yes	approved	No		S3‑191987
		S3‑192227	Resolve Editor’s Note in solution 6	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	merged	No	S3‑192386
		S3‑191983	Conclusion for Key Issue #6	Lenovo, Motorola Mobility	pCR		Yes	Yes	approved	No
		S3‑192078	Add threat and requirement to KI#10	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192233	WWC - Add conclusion on KI #10	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192080	Add threat and requirement to KI#11	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192387
		S3‑192387	Add threat and requirement to KI#11	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192080
		S3‑192234	WWC - Add conclusion on KI #11	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192079	Add requirement to KI#12	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE, Ericsson: we need a threat for this requirement.	revised	No	S3‑192388
		S3‑192388	Add requirement to KI#12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192079
		S3‑192087	Solution on Line ID protection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192090	Conclusion on KI#12	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192235	WWC - Add conclusion on KI #12	Nokia, Nokia Shanghai Bell	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑192236	WWC - Add conclusion on KI #12	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192389
		S3‑192389	WWC - Add conclusion on KI #12	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192236
		S3‑192081	Add requirement and delete EN for KI#14	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: Keep the key issue and say that the scenario is not in scope of this document.	revised	No	S3‑192390
		S3‑192390	Add requirement and delete EN for KI#14	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192081
		S3‑192086	Conclusion on KI#14	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192391
		S3‑192391	Conclusion on KI#14	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192086
		S3‑192082	Add requirement and delete EN for KI#15	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192088	Mapping SUCI to SUPI	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192091	Conclusion on KI#16	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑191949	DraftCR - update Annex B to support the authentication of non-3GPP devices	CableLabs, Charter, Nokia, Nokia Shanghai Bell	draftCR	Discussion	Yes	Yes	revised	No	S3‑192283
		S3‑192283	DraftCR - update Annex B to support the authentication of non-3GPP devices	CableLabs, Charter, Nokia, Nokia Shanghai Bell	draftCR	Discussion	Yes	YesORANGE: changes in B.1 not necessary. Some re-wording is needed as there is normative meaning in an informative annex.	noted	No		S3‑191949
		S3‑191883	DraftCR - update Annex B to support the authentication of non-3GPP UE	CableLabs	draftCR	Discussion	No	Yes	withdrawn	Yes
		S3‑192384	Draft TR 33.807	Huawei	draft TR	Approval	No	Yes	eft for email approval	No
8.8	Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)	S3‑191925	Proposed conclusion for PARLOS	Qualcomm Incorporated, Intel, Samsung, Sprint, Verizon UK Ltd	pCR	Approval	Yes	YesAdd an editor's note on the mitigations. Second part was removed. It was asked to be minuted: The group agreed that solution one is considered to be too complex to be the way forward.	noted	No
		S3‑191926	pCR: Resolution of EN in Solution 2 evaluation	Qualcomm Incorporated, Intel, Samsung, Sprint, Verizon UK Ltd	pCR	Approval	Yes	Yes	not treated	No
		S3‑191944	Way forward on Emergency solution for PARLOS	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesDocomo: part of the evaluation contains part of the solution. An editor's note was added for this.	revised	No	S3‑192380
		S3‑192380	Way forward on Emergency solution for PARLOS	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191944
		S3‑192229	pCR to 33.815 on authentication of network	NTT DOCOMO INC.	pCR	Approval	Yes	YesSprint: there is a requirement that reads that the user is always informed of whether they are using RLOS. RLOS is not only for calls as well. NTT-Docomo: if the user is not aware, we have the threat. If the UE-user interface fulfils the requirement, that's fine, but the issue is there. SA1 is giving a solution. Vodafone: our consumers are not aware, they don't know what RLOS is about. BT supported this. ORANGE supported NTT-Docomo's contribution. The feature should not impact the users and this is essential. Qualcomm: I don’t agree putting this key issue. We have discussed this with other 3GPP groups like SA1 and SA2. Vodafone: this is setting up a massive fake base station issue. BT: the user will be directed to confirm actions that he doesn’t understand. Alex (BT): if we don’t document this we will get CVDs about this in the future. False base stations are a real threat and this needs to be included. The Chair suggested to record the key issue and the threat without a requirement. NTT-Docomo: there is a solution in SA1's specification. We need the requirement to align with what SA1 has agreed. It was agreed to capture SA1's text, and a note on the user's interaction for incerasing their awareness.	revised	No	S3‑192378
		S3‑192378	pCR to 33.815 on authentication of network	NTT DOCOMO INC.	pCR	Approval	Yes	Yes	approved	No		S3‑192229
		S3‑192237	pCR to 33.815 on user awareness of PARLOS service	NTT DOCOMO INC.	pCR	Approval	Yes	YesNokia supported adding a note on the user interacting and selecting the RLOS service as done in the previous contribution. The same note was added as a baseline. Same changes as the previous contribution as well. Vodafone: what happens with IoT devices? Docomo answered that NB-IoT are excluded, the other are not.	revised	No	S3‑192379
		S3‑192379	pCR to 33.815 on user awareness of PARLOS service	NTT DOCOMO INC.	pCR	Approval	Yes	Yes	approved	No		S3‑192237
		S3‑192381	Draft TR 33.815	Sprint	draft TR	Approval	No	Yes	eft for email approval	No
8.9	Study on 5G security enhancement against false base stations	S3‑191807	Secuirty threat for RRCResumeRequest tampering.	Futurewei	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑191808	Solution for protecting RRCResumeRequest against tampering	Futurewei	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑191868	Address EN in solution #1	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192238	UE capability protection	Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192206	Resolving EN on New and Last serving gNB interactions	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192208	Evaluation of Solution#2	Samsung	pCR	Approval	Yes	Yes	revised	No	S3‑192447
		S3‑192447	Evaluation of Solution#2	Samsung,Apple	pCR	Approval	Yes	Yes	approved	No		S3‑192208
		S3‑192241	update of solution #2	Apple	pCR	Approval	Yes	Yes	merged	No	S3‑192447
		S3‑192116	Solution for Protection of RRC Reject Message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192410
		S3‑192410	Solution for Protection of RRC Reject Message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192116
		S3‑192117	Solution for Protection of NAS Reject Message	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192411
		S3‑192411	Solution for Protection of NAS Reject Message	Huawei, Hisilicon	pCR	Approval	No	Yes	noted	No		S3‑192117
		S3‑191990	New solution (SERSI - SERving network controlled SI signatures)	Ericsson	pCR	Approval	Yes	YesFuturewei didn’t agree with the new solution, only the delta should be shown. Ericsson: we have shown different aspects of the same solution in other TRs. Apple supported this solution. ORANGE: protection before the first registration is not covered. There was some strong disagreement with some other parts and the document was noted.	noted	No
		S3‑192209	Updates to Solution#7 on obtaining accurate clock information	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192210	Deletion of EN on Location update reject in Solution#7	Samsung	pCR	Approval	Yes	Yes	not treated	No
		S3‑192212	Assessment of solution #7 to Annex A.3	Samsung	pCR	Approval	Yes	YesEricsson: sharing aspects are missing.It was sugested to add an editor's note on this assesment.	revised	No	S3‑192449
		S3‑192449	Assessment of solution #7 to Annex A.3	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑192212
		S3‑192239	update of Certificate based solution	Apple	pCR	Approval	Yes	Yes	not treated	No
		S3‑192242	update of solution #14	Apple	pCR	Approval	Yes	Yes	noted	No
		S3‑191922	Evaluation of the shared key based MIB/SIB protection solution	Qualcomm Incorporated	pCR	Approval	Yes	Yes	noted	No
		S3‑192261	Comments of S3-191922	Futurewei Technologies	pCR	Approval	Yes	Yes	noted	No
		S3‑192072	A solution to MIB and SIB protection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191863	Resolve EN on signaling details of how the UE hands over to false base station	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191864	Handover Attempts failure counter	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191865	Solution #4: Resolving EN on network verification of the hashes of MIB/SIBs	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191866	Solution #4: Resolving EN on Impact on UE power consumption	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191867	Solution #4: Details on the hash algorithm used for MIB/SIB hashes	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191869	Enabling UE to detect FBS	Huawei, HiSilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192118	Solution for Avoiding UE connecting to False Base Station during Conditional Handover	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191956	Security solution for UE to avoid connecting to the false base station during a handover procedure	Intel China Ltd.	pCR		Yes	Yes	not treated	No
		S3‑191991	Conclusion on KI#3'S second requirement (reactive action)	Ericsson	pCR	Approval	Yes	Yes	not treated	No
		S3‑191950	Evaluation to Solution 6.6	Intel China Ltd.	pCR	Approval	Yes	Yes	not treated	No
		S3‑191982	Update of Solution #15	Lenovo, Motorola Mobility	pCR		Yes	Yes	not treated	No
		S3‑192145	Resolving the ENs in solution #5	Huawei, Hisilicon, Lenovo, Motorola Mobility	pCR	Approval	Yes	Yes	not treated	No
		S3‑192240	update of Key issue#7	Apple	pCR	Approval	Yes	Yes	withdrawn	Yes
		S3‑191921	Evaluation against MitM false base station attacks	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes	not treated	No
		S3‑192243	Meeting minutes of SA3 5GFBS conference call on June 2th	Apple	pCR	Information	Yes	Yes	not treated	No
		S3‑192409	Report from offline discussions on 5GFBS	Apple	report	Information	Yes	Yes	noted	No
		S3‑192448	Draft TR 33.809	Apple	draft TR	Approval	Yes	Yes	left for email approval	No
8.10	Study of KDF negotiation for 5G System Security
8.11	Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)	S3‑191945	Addressing EN in solution#1	Nokia, Nokia Shanghai bell	pCR	Approval	Yes	YesLenovo: You don’t want the serving network know all users' IDs. Huawei: this solution provides protection of User ID for the slice authentication between UE and serving network. This statement was added.	revised	No	S3‑192363
		S3‑192363	Addressing EN in solution#1	Nokia, Nokia Shanghai bell	pCR	Approval	Yes	Yes	approved	No		S3‑191945
		S3‑192260	Evaluation for solution #4	InterDigital, Inc.	pCR	Approval	Yes	YesNokia clarified that this was compliant with SA2's work.	approved	No		S3‑191819
		S3‑192199	A Solution to authentication method negotiation	Huawei, HiSilicon	pCR	Approval	Yes	YesEricsson: what is the reason for re-iventing the EAP negotiation?Nokia, ORANGE had also problems with this contribution.	noted	No
		S3‑191929	Conclusion to KI #1 (slice authentication)	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: not right for key issue 1.	revised	No	S3‑192366
		S3‑192366	Conclusion to KI #1 (slice authentication)	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191929
		S3‑191930	Conclusions to KI#2 (AMF Key separation)	Huawei, HiSilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192367
		S3‑192367	Conclusions to KI#2 (AMF Key separation)	Huawei, HiSilicon	pCR	Approval	Yes	YesIt was clarified that there was no conclusion was reached given that the use case in SA2 was not concluded either.	approved	No		S3‑191930
		S3‑191932	Add evalution to solution 3	Huawei, HiSilicon	pCR	Approval	Yes	YesORANGE objected to having this approved and preferred to to postpone the evaluation.There are some considerations in the solution that haven’t been sufficiently assesed.	noted	No
		S3‑191931	Conclusions to KI#3 (NSaaS)	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191946	2. Addressing EN in KI#4.	Nokia, Nokia Shanghai bell	pCR	Approval	Yes	YesLenovo: editor's note not addressed properly. The user could be compromised by the AMF and over the air protection would not be enough. Qualcomm: we have a big problem if the AMF is compromised, it is trusted.	noted	No
		S3‑191981	Removal of Editor’s Notes of solution #5	Lenovo, Motorola Mobility	pCR		Yes	YesORANGE: considerations of provisioning of public keys are being made when removing these editor's notes. We need to add a note on saying that these mechanisms will not be studied. The contribution found some additional opposition and it was finally noted.	noted	No
		S3‑191933	Amendment to solution 6	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: what is being protected here? Is there any additional protection apart from NAS security? Huawei: EAP mechanisms. Qualcomm: this breaks the EAP model. You cannnot encypt the EAP ID (which is the user ID) you cannot do any routing. ORANGE: we don’t have stable requirements today that justify the statement "meets the requirement of the key issue". This was left open.	noted	No
		S3‑192022	Adding evaluation and resolving EN in Solution 7	Ericsson	pCR	Approval	Yes	YesORANGE: remove the evaluation. We don’t have the requirement for this. Huawei agreed with the document.	revised	No	S3‑192369
		S3‑192369	Adding evaluation and resolving EN in Solution 7	Ericsson	pCR	Approval	Yes	YesFirst change was kept, evaluation was removed.	approved	No		S3‑192022
		S3‑192149	Evaluation to solution #9 and conclusion to KI#5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192370
		S3‑192370	Evaluation to solution #9 and conclusion to KI#5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192149
		S3‑192023	Discussion paper on NSSAI in AS layer protection	Ericsson	pCR	Discussion	Yes	YesORANGE: encrypting the NSSAI brings a lot of overhead.	noted	No
		S3‑191934	Solution details on solution 8	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: RAND per UE or per NSSAI? Huawei replied that per UE. Nokia suggested that this would have to be clarified. Ericsson: if the UE goes to IDLE and the RAND removes the context? Huawei: you would need to restart.	revised	No	S3‑192371
		S3‑192371	Solution details on solution 8	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191934
		S3‑191935	Evalution for solution 8	Huawei, HiSilicon	pCR	Approval	Yes	YesNokia: Complexity in gNB needs to be considered. Qualcomm: add an editor's note on what happens when the UE changes of NG-RAN node.	revised	No	S3‑192372
		S3‑192372	Evalution for solution 8	Huawei, HiSilicon	pCR	Approval	Yes	Yes	approved	No		S3‑191935
		S3‑191910	Adding some details to solution #10 on protecting S-NSSAI at AS layer	Qualcomm Incorporated	pCR	Approval	Yes	YesNokia didn’t find this very clear. The procedure to allocate and refresh the needed parameters needs to be clarified. An editor's note was added for this. Interdigital: add an editor's note on the encrypted NSSAI per UE. They were also concerned on the possibility of user tracking.	revised	No	S3‑192373
		S3‑192373	Adding some details to solution #10 on protecting S-NSSAI at AS layer	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑191910
		S3‑191816	Discussion on S-NSSAI privacy protection	InterDigital, Inc.	discussion	Endorsement	Yes	YesNokia: this increases the complexity. ORANGE: the requirement on confidentiality protection of the NSSAI should be applied here. I prefer it to run in the RAN network. This is also adding complexity.	noted	No
		S3‑191817	Protection of S-NSSAI transmitted in the AS layer using T-S-NSSAI	InterDigital, Inc.	pCR	Approval	Yes	YesQualcomm: If the S-TMSI is stationary a dictionary attack is possible. Nokia agreed. An editor's note was agreed on this point. An sdditional editor's note were added as requested by Nokia.	revised	No	S3‑192374
		S3‑192374	Protection of S-NSSAI transmitted in the AS layer using T-S-NSSAI	InterDigital, Inc.	pCR	Approval	Yes	Yes	approved	No		S3‑191817
		S3‑191818	Protection of S-NSSAI transmitted in the AS layer	InterDigital, Inc.	pCR	Approval	Yes	Yes	noted	No
		S3‑191826	TR 33.813 - Evaluation for Solution X - S-NSSAI transmitted in the AS layer using T-S-NSSAI	InterDigital, Inc.	pCR	Approval	Yes	YesIt was clarified that this evaluated tdoc 817. ORANGE: this is still under study, as we have added editor's notes in tdoc 817. An editor's note was added to express that more evaluation was needed.	revised	No	S3‑192375
		S3‑192375	TR 33.813 - Evaluation for Solution X - S-NSSAI transmitted in the AS layer using T-S-NSSAI	InterDigital, Inc.	pCR	Approval	Yes	Yes	approved	No		S3‑191826
		S3‑191827	TR 33.813 - Evaluation for Solution Y - S-NSSAI transmitted in the AS layer	InterDigital, Inc.	pCR	Approval	Yes	Yes	noted	No
		S3‑191947	Adding text to Clause 9 Recommendations	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	revised	No	S3‑192376
		S3‑192376	Adding text to Clause 9 Recommendations	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesRemoving the "shall"s as suggested by MCC and removing the second point.	approved	No		S3‑191947
		S3‑191948	Draft WID for normative work on eNS.	Nokia, Nokia Shangahi Bell	WID new	Approval	Yes	YesHuawei: make it more generic. Vodafone preferred to have it more specific, more detailed. ORANGE: no reference to SA2's work. MCC commented that this was a feature, not a WID. They added that the normative CRs in 33.501 would be part of the objectives and not the justification. The SA2 work in parent WIDs table should be added in the related work items.	revised	No	S3‑192377
		S3‑192377	WID for normative work on eNS.	Nokia, Nokia Shangahi Bell	WID new	Agreement	Yes	Yes	agreed	No		S3‑191948
		S3‑192364	Draft TR 33.813	Nokia	draft TR	Approval	No	Yes	eft for email approval	No
8.12	Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)	S3‑191874	Requirement for key issue 5 in TR 33.814 (FS_eLCS_Sec)	Philips International B.V.	pCR	Approval	Yes	YesSprint: what about the fake measurements that are obtained by the UE but where the UE doesn't know that they are fake (e.g. spoofed messages)? Add a statement saying that the messages faked by the source are not covered. ESA: limit the scope of the requirement, as 5G positioning service can come from RAN dependent or RAN independent accesses. Ericsson: the solution for this problem doesn’t need to be standardised. Qualcomm: it's a "should" requirement and add mechanisms to ensure the reliability of the location. Alf: clarify which part needs to be standardised. Huawei: keep the requirement, watch the solution. Ericsson: we need to be specific on what problem needs to be solved.	noted	No
		S3‑192069	Address EN in key issue 5	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191875	New solution to key issue 5 in TR 33.814 (FS_eLCS_Sec)	Philips International B.V.	pCR	Approval	Yes	Yes	noted	No
		S3‑192070	A solution to identify UEs that provides faked/altered location estimate or measurements	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑191962	pCR to TR33.814 - Key issue for the ciphering key management of broadcast assistance data	CATT	pCR	Approval	Yes	YesEricsson, Qualcomm: this is not needed. Nokia: SA2 hasn’t decided whether the key is stored in the AMF yet. We don’t support this document.	noted	No
		S3‑191965	pCR to TR33.814 - The solution for the ciphering key management of broadcast assistance data	CATT	pCR	Approval	Yes	Yes	noted	No
		S3‑192027	Resolving EN in KI#4	Ericsson	pCR	Approval	Yes	YesHuawei: don’t remove "system". Qualcomm: the 5GS includes the UE and the core network, we don’t need the change. The editor's note can be removed. Alex (BT): LCS is a server-control applicationwhereas this reads like the UE will implement the provacy and user's consent in the handset. Qualcomm: SA2 has done this work already, no need to work on this requirement anymore. Huawei supported this.	noted	No
		S3‑191968	pCR to TR33.814 - Add reference for TR 33.814	CATT	pCR	Approval	Yes	Yes	revised	No	S3‑192359
		S3‑192359	pCR to TR33.814 - Add reference for TR 33.814	CATT	pCR	Approval	Yes	YesIt Includes the content where the reference is used.	approved	No		S3‑191968
		S3‑191969	pCR to TR33.814 - Addition of definition and abbreviation	CATT	pCR	Approval	Yes	Yes	approved	No
		S3‑191966	pCR to TR33.814 - The analysis of security architecture of eLCS	CATT	pCR	Approval	Yes	YesEricsson didn’t agree with this.	noted	No
		S3‑191967	pCR to TR33.814 - Conclusions for TR33.814	CATT	pCR	Approval	Yes	YesHuawei: let's go through the evaluations first before approving this conclusion. Alex (BT): the second point should be something like "no new mechanisms are needed". Dependent on tdoc 2076.	revised	No	S3‑192362
		S3‑192362	pCR to TR33.814 - Conclusions for TR33.814	CATT	pCR	Approval	Yes	Yes	approved	No		S3‑191967
		S3‑192024	Conclusion on KI#1 (bluetooth positioning)	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192025	Conclusion on KI#2 (TBS positioning)	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192026	Conclusion on KI#3 (WLAN positioning)	Ericsson	pCR	Approval	Yes	Yes	approved	No
		S3‑192076	Add evualtion to solution 4	Huawei, Hisilicon	pCR	Approval	Yes	YesAlex (BT): we have to assume that the serving network is behaving. This and other remarks were added into the evaluation.	revised	No	S3‑192361
		S3‑192361	Add evualtion to solution 4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192076
		S3‑192028	Conclusion on KI#4 (privacy control)	Ericsson	pCR	Approval	Yes	YesHuawei, Qualcomm didn’t agree as it was covered by SA2 already.	noted	No
		S3‑192360	Draft TR 33.814	CATT	draft TR	Approval	Yes	Yes	approved	No
8.13	Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)	S3‑192123	Remove the paragraph of Introduction	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑192124	Remove the unnecessary ENs of Key issue part	Huawei, Hisilicon	pCR	Approval	Yes	YesORANGE: removing the last editor's note is not editorial.	revised	No	S3‑192345
		S3‑192345	Remove the unnecessary ENs of Key issue part	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192124
		S3‑191994	URLLC: Table with available solutions in the TR	Ericsson	pCR	Approval	Yes	Yes	revised	No	S3‑192346
		S3‑192346	URLLC: Table with available solutions in the TR	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑191994
		S3‑191894	Evaluation text for solution #5 in TR 33.825	NEC Europe Ltd	pCR	Approval	Yes	Yes	noted	No
		S3‑191913	Evaluation of solution #5: Security for redundant data transmission	Qualcomm Incorporated, Ericsson, Nokia	pCR	Approval	Yes	Yes	revised	No	S3‑192347
		S3‑192347	Evaluation of solution #5: Security for redundant data transmission	Qualcomm Incorporated, Ericsson, Nokia	pCR	Approval	Yes	Yes	approved	No		S3‑191913
		S3‑191914	Conclusion on KI #1 for Study on the security for URLLC	Qualcomm Incorporated, Ericsson, Nokia	pCR	Approval	Yes	YesDiscussed together with tdoc 2120.	revised	No	S3‑192348
		S3‑192348	Conclusion on KI #1 for Study on the security for URLLC	Qualcomm Incorporated, Ericsson, Nokia,Huawei	pCR	Approval	Yes	Yes	approved	No		S3‑191914
		S3‑192120	Deleting the EN of conclusion 7.1	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑192348
		S3‑191915	Conclusion on KI #2 for Study on the security for URLLC	Qualcomm Incorporated, Ericsson, Nokia	pCR	Approval	Yes	YesDiscussed together with tdoc 2122. Huawei: make it more generic, not only over-the-air.	merged	No	S3‑192349
		S3‑192122	conclusion for key issue 2	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192349
		S3‑192349	conclusion for key issue 2	Huawei, Hisilicon,Qualcomm	pCR	Approval	Yes	Yes	approved	No		S3‑192122
		S3‑191993	URLLC: Recommendation for KI#3	Ericsson	pCR	Approval	Yes	Yes	merged	No	S3‑192357
		S3‑192119	conclusion for key issue 3	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192357
		S3‑192357	conclusion for key issue 3	Huawei, Hisilicon,Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192119
		S3‑192121	Deleting the EN of conclusion 7.4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑192358
		S3‑192358	Deleting the EN of conclusion 7.4	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192121
		S3‑192344	Draft TR 33.825	Huawei	draft TR	Approval	No	Yes	eft for email approval	No
8.14	Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)	S3‑192183	Meeting notes of NFV SCAS conf call	China Mobile	other		Yes	Yes	noted	No
		S3‑192048	Scope of a SECAM SCAS for 3GPP virtualized network products	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192062	Scope of SECAM evaluation for 3GPP virtualized network products	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192063	Scope of SECAM Accreditation for 3GPP virtualized network products	China Mobile	pCR	Approval	Yes	YesAlex (BT) disagreed. This is outside of the scope of the 3GPP, and he didn’t agree with the new text in the gap anlysis. An editor's note was added on the evaluation of the differences between the two types of network classes for acreditation purposes.	revised	No	S3‑192436
		S3‑192436	Scope of SECAM Accreditation for 3GPP virtualized network products	China Mobile	pCR	Approval	Yes	Yes	approved	No		S3‑192063
		S3‑192064	Adding roles in SECAM for 3GPP virtualized network products into clause 4.6	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesAlex (BT): more of an answer, not a real gap analysis.The text doesn’t fit the title. ORANGE: the text needs a language check. ORANGE: remove the last clause. Added a new editor's note on further analysis needed as well.	revised	No	S3‑192437
		S3‑192437	Adding roles in SECAM for 3GPP virtualized network products into clause 4.6	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑192064
		S3‑192127	Adding contents into clause 4	China Mobile	pCR	Approval	Yes	Yes	noted	No
		S3‑192128	Adding writing process overview into clause 5.1	China Mobile, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	not treated	No
		S3‑192129	Adding general description and ToE into clause 5.2.1 and 5.2.2	China Mobile	pCR	Approval	Yes	Yes	not treated	No
		S3‑192061	Scope of SECAM evaluation for 3GPP virtualized network products	China Mobile, Nokia, Nokia Shanghai Bell	pCR		No	Yes	withdrawn	Yes
		S3‑192435	Draft TR 33.818	China Mobile	draft TR	Approval	Yes	Yes	approved	No
8.15	Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)	S3‑191901	Security for non-public networks	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	YesORANGE needed more differentiation between non-standalone and standalone networks. This had to be taken offline.	revised	No	S3‑192453
		S3‑192453	Security for non-public networks	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	draftCR	Approval	Yes	Yes	approved	No		S3‑191901
		S3‑191902	Proposed conclusion details for key issue #1.1 in TR 33.819	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No		S3‑191496
		S3‑192050	Cleaning of 33819-040	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑192049	TR terminology	Nokia, Nokia Shanghai Bell	discussion	Endorsement	Yes	Yes	noted	No
		S3‑192051	Headline clash in TR resolved	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	approved	No
		S3‑191820	Solution for (D)DoS attack mitigation in PNI NPN	InterDigital, Inc.	pCR	Approval	Yes	YesHuawei: not in the scope of 3GPP. Qualcomm disagreed, as CAG ID was not long enough for them.	noted	No
		S3‑191821	Solution for (D)DoS attack mitigation in PNI NPN	InterDigital, Inc.	pCR	Approval	Yes	YesHuawei: not in the scope of SA3. It is not a security solution. The Chair commented that there was a key issue about this. Nokia supported Interdigital, they considered it within scope.	revised	No	S3‑192341
		S3‑192341	Solution for (D)DoS attack mitigation in PNI NPN	InterDigital, Inc.	pCR	Approval	Yes	YesAdding an editor's note in the evaluation addressing Ericsson's comment (FFS for the case of one CAG ID is left).	approved	No		S3‑191821
		S3‑191815	Evaluation for solution for (D)DoS attack mitigation in PNI NPN for KI#6.1	InterDigital, Inc.	pCR	Approval	Yes	Yes	noted	No
		S3‑192217	Resolution of Editor’s note in Solution #3	Samsung	pCR	Approval	Yes	YesEricsson: It doesn’t remove the privacy concern for this solution. It was agreed to reword the editor's note to make it a note.	revised	No	S3‑192342
		S3‑192342	Resolution of Editor’s note in Solution #3	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑192217
		S3‑192216	Conclusion to Key Issue #6.1	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑192195	TR 33.819 – KI #6.2 – Threats and Requirements	InterDigital, Inc.	pCR	Approval	Yes	YesDiscussed together with tdoc 974.	merged	No	S3‑192343	S3‑191828
		S3‑191974	Security threats and requirements on CAG ID privacy	ZTE Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑192343
		S3‑192343	Security threats and requirements on CAG ID privacy	ZTE Corporation,Interdigital	pCR	Approval	Yes	Yes	approved	No		S3‑191974
		S3‑191973	CAG ID privacy	ZTE Corporation	discussion	Discussion	Yes	Yes	noted	No
		S3‑191900	Proposed solution to key issue 6.3 on modifying the CAG list	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No
		S3‑192060	Secure device identity creation for UEs in SNPNs	Nokia, Nokia Shanghai Bell	pCR	Endorsement	Yes	Yes	noted	No
		S3‑192059	Key issue on Secure device identity creation for constrained devices	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑191895	New Key Issue on Identification of Multiple NPN Subscriptions	NEC Europe Ltd	pCR	Approval	Yes	YesORANGE: subscription to several PLMNs doesn’t mean that you are connected to all of them at the same time. The number of valid active contexts here does not correspond to what's agreed in SA2. Qualcomm: it's possible to have multiple subscriptions although is not standardized. This contribution on the other hand is out of scope of SA3. Interdigital was in favour of the contribution although with an editor's note. Ericsson didn't find this necessary either. Qualcomm, IDEMIA didn’t support it either.	noted	No
		S3‑191896	Solution for Identification and Selection of Multiple NPN Subscriptions	NEC Europe Ltd	pCR	Approval	Yes	Yes	noted	No
		S3‑191897	New Key Issue on separation and storage of multiple NPN credentials	NEC Europe Ltd	pCR	Approval	Yes	YesORANGE: we have decided not to handle the storage of security credentials.Qualcomm, Gemalto agreed. NEC: the intent is different, it's about how to store.	noted	No
		S3‑191898	Solution for separation of multiple NPN credentials	NEC Europe Ltd	pCR	Approval	Yes	Yes	noted	No
		S3‑191819	Evaluation for solution #4	InterDigital, Inc.	pCR	Approval	Yes	Yes	revised	No	S3‑192260
		S3‑191828	TR 33.819 – KI #6.2 – Threats and Requirements	InterDigital, Inc.	pCR	Approval	Yes	Yes	revised	No	S3‑192195
		S3‑192340	Draft TR 33.819	Nokia	draft TR	Approval	No	Yes	eft for email approval	No
8.16	Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)	S3‑192009	pCR to TR33.935 - Addition of Diffie - Helman Key agreements section	VODAFONE Group Plc	pCR	Agreement	No	Yes	withdrawn	Yes
8.17	Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)	S3‑191880	Proposal for FS_UP_IP_Sec Key Issue #3 and 5: Zero-overhead user plane integrity protection on the link layer	Philips International B.V.	pCR	Approval	Yes	YesEricsson: this was already noted and our opinion is the same. Vodafone: this is technically correct and I see no reason not to document this solution. Qualcomm agreed with Ericsson. There were technical comments that haven’t been addressed. Philips: Technical comments have been taken care of. Nokia, Futurewei: remove the evaluation. Nokia: it affects multiple protocol stacks, PHY and MAC for sure.Add an editor's note on this. Qualcomm proposed several editor's notes to record their concerns.	revised	No	S3‑192422
		S3‑192422	Proposal for FS_UP_IP_Sec Key Issue #3 and 5: Zero-overhead user plane integrity protection on the link layer	Philips International B.V.	pCR	Approval	Yes	Yes	approved	No		S3‑191880
		S3‑191899	New solution for KI #4	NEC Europe Ltd	pCR	Approval	Yes	YesQualcomm: too much high level. More detail is needed. An editor's note was added to detail this better in the future. Telecom Italia: I don’t understand bullet 3 in 6.x.3.	revised	No	S3‑192423
		S3‑192423	New solution for KI #4	NEC Europe Ltd	pCR	Approval	Yes	Yes	approved	No		S3‑191899
		S3‑192036	UP IP: New key issue for UE indicating support of UP IP in NR PDCP with a ng-eNB connected to 5GC	Ericsson	pCR	Approval	Yes	YesQualcomm: we need the key issue but it is valid for all options except option 2. Remove all references to NR PDCP, it should be E-UTRAN. Qualcomm: clarify what UE we are talking about in the requirement.	revised	No	S3‑192425
		S3‑192425	UP IP: New key issue for UE indicating support of UP IP in NR PDCP with a ng-eNB connected to 5GC	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192036
		S3‑192131	New solution: Integrity Protection of packet header in the User Plane	China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑192132	New solution: Integrity Protection of packet header in the User Plane	China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑192133	New solution: Integrity Protection of packet header in the User Plane	China Mobile	pCR	Approval	Yes	YesNokia, Qualcomm: this is not feasible. Letf open for offline discussions.	revised	No	S3‑192455
		S3‑192455	New solution: Integrity Protection of packet header in the User Plane	China Mobile	pCR	Approval	Yes	YesThe evaluation was removed and an editor's note added as proposed by Qualcomm.	approved	No		S3‑192133
		S3‑192203	Evaluation of Solution#1	Samsung	pCR	Approval	Yes	YesEricsson: remove "completely". Qualcomm: your solution only protects DNS queries.It doesn’t address the attacks due to lack of integrity protection. Apple: remove the last sentence.	revised	No	S3‑192426
		S3‑192426	Evaluation of Solution#1	Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑192203
		S3‑192205	Conclusion to Key Issue #5	Samsung	pCR	Approval	Yes	Yes	noted	No
		S3‑192424	Draft TR 33.853	Vodafone	draft TR	Approval	No	Yes	eft for email approval	No
8.18	Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)	S3‑191849	Virtualisation Study Conf Call Output	BT plc	pCR	Approval	Yes	Yes	approved	No
		S3‑191850	pCR Virtualisation Study Key Issue 10 Merger with Key issue 1 (was S3-191569)	BT plc	pCR	Approval	Yes	Yes	approved	No
		S3‑191851	Virtualisation Study Key Issue 11 (was S3-191570)	BT plc	pCR	Approval	Yes	Yes	approved	No
		S3‑191852	Virtualisation Study Key Issue 12 (was S3-191571)	BT plc	pCR	Approval	Yes	Yes	revised	No	S3‑192368
		S3‑192368	Virtualisation Study Key Issue 12 (was S3-191571)	BT plc	pCR	Approval	Yes	Yes	approved	No		S3‑191852
		S3‑191853	Virtualisation Study Key Issue 19 (was S3-191580)	BT plc	pCR	Approval	Yes	Yes	revised	No	S3‑192395
		S3‑192395	Virtualisation Study Key Issue 19 (was S3-191580)	BT plc	pCR	Approval	Yes	Yes	approved	No		S3‑191853
		S3‑191854	Virtualisation Study Key Issue 20 (was S3-191581)	BT plc	pCR	Approval	Yes	Yes	revised	No	S3‑192446
		S3‑192446	Virtualisation Study Key Issue 20 (was S3-191581)	BT plc	pCR	Approval	Yes	Yes	approved	No		S3‑191854
		S3‑191855	Virtualisation Study Key Issue 21 (was S3-191582)	BT plc	pCR	Approval	Yes	Yes	approved	No
		S3‑191856	Virtualisation Study Key Issue 22 (was S3-191583)	BT plc	pCR	Approval	Yes	Yes	revised	No	S3‑192396
		S3‑192396	Virtualisation Study Key Issue 22 (was S3-191583)	BT plc	pCR	Approval	Yes	Yes	approved	No		S3‑191856
		S3‑191857	Virtualisation Study Key Issue 23 (was S3-191583)	BT plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑191858	Virtualisation Study Key Issue 24 (was S3-191585)	BT plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑191859	Virtualisation Study Key Issue 25 (was S3-191587)	BT plc	pCR	Approval	Yes	Yes	not treated	No
		S3‑192445	Draft TR 33.848	BT	draft TR	Approval	Yes	Yes	approved	No
8.19	Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)	S3‑191977	Modification on linkability issue1	ZTE Corporation	pCR	Approval	Yes	YesVodafone: why the change in the clause numbering? Zte: just correcting a mistake. Vodafone: why is the requirement deleted? ZTE: this was hard to achieve. Gemalto: no need to remove the requirement. Vodafone: the new text needs rewriting.	revised	No	S3‑192431
		S3‑192431	Modification on linkability issue1	ZTE Corporation	pCR	Approval	Yes	Yes	approved	No		S3‑191977
		S3‑191927	A key issue on forward secracy	Huawei, HiSilicon	pCR	Approval	Yes	YesVodafone: LTKUP mitigates this in a separate study.	noted	No
		S3‑191996	Co-existence of LTKUP and PFS	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑191997	New KI: Leakage of long-term key	Ericsson	pCR	Approval	Yes	YesVodafone: very improbable case which will require a substantial amount of work. ORANGE supported this. Alex (BT): the only way of attacking here would be not to secure the UDR.	noted	No
		S3‑191907	Key issue on protecting the SQN during a re-synchronisation procedure in AKA	Qualcomm Incorporated	pCR	Approval	Yes	YesNCSC supported Qualcomm. Apple supported the solution. It was agreed to modify the requirement to replace void with "should protect against the effect of". Qualcomm commented that this meant updating the SID since it was very specific in its scope.This could be done for the next meeting.	revised	No	S3‑192433
		S3‑192433	Key issue on protecting the SQN during a re-synchronisation procedure in AKA	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑191907
		S3‑192147	New KI: KAUSF storing at UE side	Huawei, Hisilicon	pCR	Approval	Yes	YesEricsson: not in scope. Qualcomm also disagreed with this.	noted	No
		S3‑192185	Updating UDM with UE registration status	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	YesEricsson: not in the scope of the study. Apple: requirements look like solutions. Qualcomm: not in the scope of the study.	noted	No
		S3‑191963	Solution for anchor keys security	Gemalto N.V.	pCR	Approval	Yes	Yes	noted	No
		S3‑192188	Discussion paper UE initiated PFS	Nokia, Nokia Shanghai bell	discussion	Discussion	Yes	Yes	noted	No
		S3‑191998	New solution: EAP-AKA´ PFS	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑191928	A solution to forward secracy	Huawei, HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192191	pCR UE initiated PFS	Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	Yes	noted	No
		S3‑191975	Structure RAND for authentication	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑191964	Mitigation against linkability issue	Gemalto N.V.	pCR	Approval	Yes	Yes	not treated	No
		S3‑191976	Handling of Sync failure	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑191908	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‑192066	mitigate the linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑192144	New solution for the linkability attack	Huawei, Hisilicon	pCR	Approval	Yes	Yes	not treated	No
		S3‑191978	Conclusion on linkability issues	ZTE Corporation	pCR	Approval	Yes	Yes	not treated	No
		S3‑192432	Draft TR 33.846	Ericsson	draft TR	Approval	No	Yes	eft for email approval	No
8.20	Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)	S3‑192074	KI on protection of F1-U	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑192075	KI on toplogy discovery	Huawei, Hisilicon	pCR	Approval	Yes	YesNokia: configuration issue, this topology discovery is not needed. It was agreed to remove the requirement.	revised	No	S3‑192405
		S3‑192405	KI on toplogy discovery	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑192075
		S3‑192029	New KI: Protection of recovery from backhaul-RLF	Ericsson	pCR	Approval	Yes	YesFuturewei: Why is RLF recovery mechanism signalled? Ericsson: this is done below F1 interface IPSec. Futurewei: remove security threats and requirements. Add "reference to transportation layer for RLF recovery messages is FFS". Samsung: communication between the nodes to be confirmed with RAN2.	revised	No	S3‑192407
		S3‑192407	New KI: Protection of recovery from backhaul-RLF	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192029
		S3‑192030	New solution: Secure recovery from backhaul-RLF	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑192031	Update to solution #2.1 (Authentication and authorization of IAB Node)	Ericsson	pCR	Approval	Yes	YesORANGE: IAB nodes are authenticated to the Home network, into the UDM. IAB nodes are like Ues but the storage is not handled at all. The credentials for the IAB node are handled like the UE? This is not mentioned here. Futurewei: why are not we referencing the clauses and now it's the whole specification? Samsung supported this. Telecom Italia: why are the other clauses of other specifications staying?	revised	No	S3‑192408
		S3‑192408	Update to solution #2.1 (Authentication and authorization of IAB Node)	Ericsson	pCR	Approval	Yes	Yes	approved	No		S3‑192031
		S3‑192032	New solution on authentication and authorization of IAB Node in 5G	Ericsson	pCR	Approval	Yes	Yes	noted	No
		S3‑192200	Updates on IAB Node authentication and authorization solution	Samsung	pCR	Approval	Yes	Yes	approved	No
		S3‑192202	Establishment of F1 security association using Shared Key	Samsung	pCR	Approval	Yes	Yes	approved	No
		S3‑191918	Evaluation of solution #4.1: F1 interface security for IAB	Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	S3‑192414
		S3‑192414	Evaluation of solution #4.1: F1 interface security for IAB	Qualcomm Incorporated	pCR	Approval	Yes	Yes	approved	No		S3‑191918
		S3‑191919	Conclusion of KI #4.1: F1 interface security for IAB	Qualcomm Incorporated	pCR	Approval	Yes	YesHuawei: too early to reach a conclusion. Samsung: we support this contribution. AT&T as well as they believed this needed to be finished in a timely manner.	approved	No
		S3‑192406	Draft TR 33.824	Samsung	draft TR	Approval	No	Yes	eft for email approval	No
8.21	Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)	S3‑191822	Solution for Privacy protection for unicast messages over PC5	InterDigital, Inc.	pCR	Approval	Yes	YesLG: more explanation about Kd session ID is needed. Add an editor's note on this. This was agreed. Editor's note: protection of messages; more explanation is needed. Editor's note on why the number of messages is different from SA2 spec (2 instead of 3). MCC: Reformulate NOTE not to mention SA2 but refer to stage 2 work.	revised	No	S3‑192415
		S3‑192415	Solution for Privacy protection for unicast messages over PC5	InterDigital, Inc.	pCR	Approval	Yes	Yes	approved	No		S3‑191822
		S3‑191823	Solution for Security for eV2X unicast messages over PC5	InterDigital, Inc.	pCR	Approval	Yes	YesLG: there is no ProSe for NR yet. Qualcomm proposed another editor's note for comparison with SA2's procedures.	revised	No	S3‑192417
		S3‑192417	Solution for Security for eV2X unicast messages over PC5	InterDigital, Inc.	pCR	Approval	Yes	Yes	approved	No		S3‑191823
		S3‑191824	Solution for Security for eV2X unicast messages over PC5	InterDigital, Inc.	pCR	Approval	Yes	Yes	revised	No	S3‑192418
		S3‑192418	Solution for Security for eV2X unicast messages over PC5	InterDigital, Inc.	pCR	Approval	Yes	YesAdding several editor's notes addressing comments from Qualcomm among others.	approved	No		S3‑191824
		S3‑191825	Solution for Privacy protection for unicast messages over PC5 using rekeying	InterDigital, Inc.	pCR		Yes	YesQualcomm proposed an editor's note on integrity protection of SMC being cyphered causing an impact. This was agreed.	revised	No	S3‑192419
		S3‑192419	Solution for Privacy protection for unicast messages over PC5 using rekeying	InterDigital, Inc.	pCR	-	Yes	Yes	approved	No		S3‑191825
		S3‑191957	Update of key issue #2 on PC5 unicast mode	LG Electronics	pCR	Approval	Yes	YesQualcomm: rewording of requirements would be benefitial.	revised	No	S3‑192420
		S3‑192420	Update of key issue #2 on PC5 unicast mode	LG Electronics	pCR	Approval	Yes	Yes	approved	No		S3‑191957
		S3‑191958	Solution for security of V2X service authorisation	LG Electronics	pCR	Approval	Yes	Yes	approved	No
		S3‑191959	Discussion on the reply LS for PC5 unicast groupcast security protection	LG Electronics	discussion	Discussion	Yes	Yes	noted	No
		S3‑191960	Reply LS on PC5 unicast and groupcast security protection	LG Electronics	LS out	Approval	Yes	Yes	revised	No	S3‑192421
		S3‑192421	Reply LS on PC5 unicast and groupcast security protection	LG Electronics	LS out	Approval	Yes	YesTaking comments from Interdigitals contribution in 2257. It was clarifed that the original LS from SA2 had been replied already, so for database purposes this was a new LS instead of a reply.	approved	No		S3‑191960
		S3‑192257	Comments to S3-191960 [DRAFT] LS on PC5 unicast and groupcast security protection	InterDigital, Inc.	LS out	Approval	Yes	Yes	noted	No
		S3‑192416	Draft TR 33.836	LG	draft TR	Approval	Yes	Yes	approved	No
8.22	Other study areas
8.23	New study item proposals	S3‑191970	New SID on Study on user plane security termination point in 5GC	CATT, China Unicom, Qihoo360	SID new	Approval	Yes	YesORANGE: UP protection protect the data sent over the air only.Is this protection to be built on top of the current protection or to be a replacement? If it's a replacement, we need to see how and who's providing the keys and this has legal implications. I don’t think we are going anywhere with this. Qualcomm: it would be part of the study. Vodafone: EN-DC already does this. Qualcomm: there is a need for this, and it's not intended to be a replacement. Solutions should be restricted to the UPF. If this is the case we will support. Huawei: this may not meeting LI requirements. It's problematic. Nokia: this was studied in SA2 in CIoT. They didn't go along wih these proposals for Rel-16. Work should start in SA2 and then we will follow. Alf (Docomo): I don’t see the problem with LI. I don’t think there is time for this now and this is a proposal for Rel-17. I disagree with having SA2 starting the job. ORANGE and Huawei objected to this. Interdigital and Qualcomm conditionally supported this. The Chair wondered if it was appropriate to start bringing Rel-17 WIDs at this stage where priority relied on Rel-16 work. Eventually this was noted.	noted	No
		S3‑192356	New SID on Study on user plane security termination point in 5GC	CATT, China Unicom, Qihoo360	SID new	Approval	No	Yes	withdrawn	Yes
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑191802	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑191805	Work Plan input from Rapporteurs	MCC	other		Yes	YesTo be done next meeting.	noted	No
10	Future Meeting Dates and Venues	S3‑191804	SA3 meeting calendar	MCC	other		Yes	YesNov 2020 may be IF3. Some resistance to have adhoc meetings in 2020. The Chair commented that these were reserved dates and not confirmed meetings. Preliminary dates for 2021 to be discussed during the next meeti	noted	No
11	Any Other Business
12	Close