TDoc list

Tdoc List

2018-04-20 13:57

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‑181100	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‑181101	Report from last SA3 meeting	MCC	report		Yes	Yes Action item on SCAS: open (to be fulfilled by Anja (Nokia). Action item on GSMA documents publicly available. MCC commented that Vodafone had assured that all documents referenced were publicly available. MCC will double check this.	approved	No
4.2	Report from SA Plenary	S3‑181103	Report from last SA meeting	WG Chairman	report		Yes	Yes Docomo: let's use this late drop/ an extended timeline for the N32 interface? some companies want it for Rel-15. Christine (Ericsson): we depend on CT4 to do this. The Chair commented that 33.501 will have to be 100% complete in June. Alf: there is a lot of work pending even if we bring it to 100%. The Chair commented that if it is not 100% complete SA3 would have to be very clear that it wasn’t complete, so CT groups could be aware of this. Huawei: there are a couple of SA5 LS referring to some interfaces that need to be secured as well. We would need to have this in Rel-15 as well.	noted	No
4.3	Report from SA3-LI
5	Items for early consideration
6	Reports and Liaisons from other Groups
6.1	3GPP Working Groups	S3‑181109	LS on encrypting broadcasted positioning data and LS on provisioning of positioning assistance data via LPPa for broadcast	C1-180643	LS in		Yes	Yes It was decided to note all three LS and wait for RAN's response.	noted	No
		S3‑181110	LS on encrypting broadcasted positioning data and on provisioning of positioning assistance data via LPPa for broadcast	C4-182150	LS in		Yes	Yes	noted	No
		S3‑181111	LS on encrypting broadcasted positioning data and LS on provisioning of positioning assistance data via LPPa for broadcast	S2-182415	LS in		Yes	Yes	noted	No
		S3‑181120	Reply LS on EDT procedures and AS NAS interaction	R3-181573	LS in		Yes	Yes	noted	No
		S3‑181122	Reply LS on clarification on Restricted Operator Services	S2-181407	LS in		Yes	Yes Qualcomm: Legacy UEs will not accept this RLOS access. We agree with SA2. It was agreed to postpone this LS to the August meeting. There is an Study Item on this in tdoc 185.	postponed	No
		S3‑181124	LS to BBF on general status of work	S2-183036	LS in		Yes	Yes Marcus (Huawei) commented that there was a related WID on this in tdoc 216.	noted	No
		S3‑181125	LS on Guidance on UE WiFi MAC Address inclusion in LTE Positioning Protocol	SP-180234	LS in		Yes	Yes	noted	No
		S3‑181550	Reply LS to SA3 on encryption of broadcast positioning information	R2-1806308	LS in	Discussion	Yes	Yes	postponed	No
		S3‑181554	Response to LS on encrypting broadcasted positioning data and LS on provisioning of positioning assistance data via LPPa for broadcast	R2-1806307	LS in	discussion	Yes	Yes	postponed	No
6.2	IETF
6.3	ETSI SAGE
6.4	GSMA	S3‑181429	LTE and the upcoming 5G standard	GSMA	LS in		Yes	Yes Colin (BT): it's true that there is no user plane integrity protection in LTE. We don't mandate in 5G but we say support, mandating depends on policy. We cannot mandate thue "use". Alf (Docomo): a number of apps running in the phone do not properly verify the service they are talking to, and this is a bigger problem than the website itself. Hans (DT): this is an attack to be considered seriously. We need to decided if the 64Kbits minimu integrity protection is supported by SA3 or we need the integrity protection for everything. Qualcomm: in 5G we have mandated the support of integrity protection, and all the way up to full rate. For LTE we may need to consider it. Alf (Docomo): we cannot get to a complete solution during this meeting.gNodeB may switch off integrity protection if it is overloaded, this is an issue to be studied. Sander(KPN): there are things that can be done at application layer level. Not an attack only to LTE.	replied to	No
		S3‑181443	Reply to: LTE and the upcoming 5G standard	NTT-Docomo	LS out	approval	Yes	Yes It was commented that some work should be done in SA3 about DNS attacks. The Chair commented that 3GPP CVD was on its way to solve these kind of issues.	approved	No
6.5	OMA
6.6	TCG	S3‑181128	TCG progress report	InterDigital, Inc.	report	Information	Yes	Yes 1. TCG – Highlights New/modified work items none Publication of new or revised deliverables (mostly incremental changes from the status reported at SA3#90) o TCG Device Identifier Composition Engine – published March 2018 o TCG SNMP MIB for TPM-based Attestation – public review April 2018 o TCG PC Client Platform Reset Attack Mitigation v1.1 – public review March 2018 o TCG Protection Profile PC Client Specific TPM v1.1 – public review March 2018 o TCG Guidance for Securing Network Equipment – published January 2018 o TCG Trusted Mobility Solutions Use Cases v2 – public review January 2018 o TCG Trusted Software Stack (TSS) specs – public review January 2018 o TCG TPM 2.0 Automotive Thin Profile v1.1 – public review January 2018 o TCG Storage Interface Interactions (SIIS) – public review January 2018 2. Meetings TCG Members Meeting in San Diego, CA – 18-22 June 2018 TCG Members Meeting in Lisbon, PT – 15-18 October 2018 MPWG meets every Thursday at 10-11 ET TMS WG meets every Monday and Friday at 12-13 ET	noted	No
6.7	oneM2M
6.8	TC-CYBER
6.9	ETSI NFV security
6.10	Other Groups	S3‑181107	Statement on urgency of alignment of ETSI SSP with 3GPP release 15	GSMA	LS in		Yes	Yes Postponed for the next meeting, in LaJolla, where the editor's note should be solved.	postponed	No
		S3‑181108	Reply LS on Statement on urgency of alignment of ETSI SSP with 3GPP release 15	SP-180240	LS in		Yes	Yes	noted	No
7	Work Areas
7.1	EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)	S3‑181197	Correction and Clarification for EDCE5	Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No
		S3‑181323	Discussion on resolution of the editor’s notes in EN-DC clauses of TS 33.401	Qualcomm Incorporated	discussion	Discussion	Yes	Yes This way forward was endorsed by the group.	endorsed	No
7.2	Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)
7.2.1	Key hierarchy	S3‑181147	Modification on key hierarchy	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181434
		S3‑181357	Correction of KAUSF source for 5G AKA	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181434
		S3‑181372	Update of information on Keys for AUSF in home network	NEC Europe Ltd	CR	Approval	Yes	Yes	revised	No	S3‑181434
		S3‑181434	Corrections on key hierarchy,key derivation, and distribution scheme	NEC Europe Ltd, ZTE Corporation, Ericsson,Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑181372
		S3‑181337	Clause 6.2.3.2 EN on Kausf identification	Nokia	CR	Approval	Yes	Yes	merged	No	S3‑181434
		S3‑181355	Discussion on KAUSF identifier	Ericsson	discussion	Agreement	Yes	Yes	noted	No
		S3‑181356	Identifier for Kausf	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑181464
		S3‑181464	Identifier for Kausf	Ericsson	CR	Agreement	No	Yes	merged	No	S3‑181460	S3‑181356
		S3‑181380	Resolving EN on Kausf identification	NEC Europe Ltd	CR	Approval	Yes	Yes Nokia: there is only one KAUSF, what's the use case for a separate identifier? There cannot be multiple KAUSF. Ericsson: might be needed for the UE. Qualcomm: we don’t want the KAUSF used to track the UE. DT and ZTE agreed with Nokia and Qualcomm.	not pursued	No
7.2.2	Key derivation	S3‑181325	Discussion on the freshness parameter for K_AMF derivation	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes Ericsson: this is not a bidding down attack. The gNodeB cannot convince the AMF to user other algorithms. The UE and AMF have different versions of Kmf so the NAS security will fail and this would become a DoS attack. Nokia,NEC,Huawei supported the NAS COUNT solution. Ericsson: we want to avoid the situation when the source AMF is delivering the same key to a different target AMF. Qualcomm: but why introducing a new parameter? The Chair asked for a show of hands: NONCE supporting companies: Ericsson, ZTE NAS COUNT: Intel, NEC,Huawei, Qualcomm,Nokia It was finally agreed to use the NAS COUNT solution.	endorsed	No
		S3‑181326	K’AMF derivation and NASC protection at N2 based handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑181510
		S3‑181510	K’AMF derivation and NASC protection at N2 based handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes The agreed part on 6.9 goes into tdoc 511.	merged	No	S3‑181454	S3‑181326
		S3‑181163	Add condition for reset NAS COUNTs	ZTE Corporation	CR	Approval	Yes	Yes	revised	No	S3‑181512
		S3‑181512	Add condition for reset NAS COUNTs	ZTE Corporation	CR	Approval	Yes	Yes It was noted that there was a clash between this document and 547. Qualcomm had the action point to review it.	agreed	No		S3‑181163
		S3‑181354	Generalization of key derivation in NG-RAN to cover both gNBs and ng-eNBs	Ericsson	CR	Agreement	Yes	Yes Qualcomm: on 6.11, details regarding LTE need to be added. This was agreed and noted for a future contribution.	agreed	No
		S3‑181133	Update clause reference for key identification	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181434
		S3‑181137	Remove redundant description on SN name construction	ZTE Corporation	CR	Approval	Yes	Yes KPN didn’t agree with removing the text.	not pursued	No
		S3‑181151	Editorial modification on key setting and key lifetimes	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181434
		S3‑181511	Clarifications to: Security handling in mobility	Qualcomm	CR	Agreement	Yes	Yes	agreed	No
7.2.3	Mobility	S3‑181140	Reconstruct for security handlings	ZTE Corporation	CR	Approval	Yes	Yes Ericsson: it's too early since it's a major restructuring and there are other documents changing these clauses here. Better to bring it back during the next meeting.	not pursued	No
		S3‑181142	Add description for NAS and AS algorithm selection	ZTE Corporation	CR	Approval	Yes	Yes Ericsson,Nokia: this information is already present in the TS.	not pursued	No
		S3‑181352	NONCE as input to horizontal key derivation and calculation/verification of NAS MAC-I in NASC	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181152	Editorial modification on key handling in mobility registration update	ZTE Corporation	CR	Approval	Yes	Yes Huawei,NEC,Ericsson: this is not editorial.	not pursued	No
		S3‑181353	Corrections and clarifications on handover handling	Ericsson	CR	Agreement	Yes	Yes Huawei needed more time to evaluate this. It was decided to bring it back during the next meeting.	not pursued	No
		S3‑181138	Remove of K_AMF_CI	ZTE Corporation	CR	Approval	Yes	Yes	revised	No	S3‑181513
		S3‑181513	Remove of K_AMF_CI	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181511	S3‑181138
		S3‑181222	Update security mechanism in Xn-HO procedre	Huawei; HiSilicon	CR	Approval	Yes	Yes Nokia and Samsung didn’t understand the scenario and the contribution was taken offline.	revised	No	S3‑181555
		S3‑181555	Update security mechanism in Xn-HO procedre	Huawei; HiSilicon	CR	Approval	Yes	Yes 6.7 will go to 518 and clause 6.6 will go to 520.	merged	No	S3‑181520	S3‑181222
7.2.4	AS security	S3‑181324	Reply LS on Security aspects of supporting LTE connected to 5GC	Qualcomm Incorporated	LS out	Approval	Yes	Yes	revised	No	S3‑181448
		S3‑181192	Discussion on RRC-INACTIVE state Security	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes Ericsson had some issues: - Proposal two is too far-fetched. The UE is basically inactive. What did change in 5G to require this? - Avoid challenging decisions with RAN. Samsung supported Huawei, there is a need for a mechanism for changing algortihms. Ericsson: The UE is in INACTIVE state here. Just bring the UE to connected state and do the usual procedure in LTE. The proposal may olverload the INACTIVE procedure.The algorithm change scenario is a very rare case. As soon as the target UE detects that the change is needed, comes back to connected state. Nokia supported Ericsson. Huawei: SA3 is asked to evaluate the security aspect of this proposal from RAN2. Huawei: we cannot assume that the target gNodeB supports the same algorithm as the UE. Ericsson replied that this would mean a weakness in LTE for something that is widely deployed. Huawei proposes a LS reply in 225. On Proposal 2, it was agreed that RAN2 should decide, but Ericsson wanted to understand the threat cleary. It was agreed not to have a CR for this meeting.	noted	No
		S3‑181374	Key handling at transitions between RRC-INACTIVE and RRC-CONNECTED	Samsung	CR		Yes	Yes	not pursued	No
		S3‑181303	RRC INACTIVE - Discussion on various security aspects	Ericsson	discussion	Discussion	Yes	Yes	noted	No
		S3‑181304	RRC_INACTIVE - security handling at state transition	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181305	RRC_INACTIVE – security handling at mobility	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181225	Draft Reply LS to RAN2 on security for inactive state.	Huawei; HiSilicon	LS out	Approval	Yes	Yes Ericsson: what's the security threat? Huawei: no security negotiation between target gNodeB and UE. This was agreed to include it in the LS. Huawei: let's mention the security issues and let RAN2 decide. Huawei and Ericsson had to go offline to discuss their proposal number 2.	revised	No	S3‑181450
		S3‑181302	[DRAFT] LS on security for inactive state	Ericsson	LS out	Approval	Yes	Yes	merged	No	S3‑181450
		S3‑181194	Introduction for Dual Connectivity	Huawei, Hisilicon	CR	Approval	Yes	Yes The figure 6.10.1.2-1 is not in scope of the dual connectivity. The overlapping documents had to go offline. A draftCR was created to compile all the inputs: 517.	not pursued	No
		S3‑181195	Dual Connectivity Architecture for MR-DC with 5GC	Huawei, Hisilicon	CR	Approval	Yes	Yes Content move to 517.	not pursued	No
		S3‑181312	Proposal for Dual Connectivity	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181313	Dual Connectivity - Introduction	Ericsson	CR	Agreement	Yes	Yes Content moved to 517.	not pursued	No
		S3‑181318	Discussion on the format to specify the dual connectivity procedure when attached to a 5G core	Qualcomm Incorporated	discussion	Discussion	Yes	Yes	noted	No
		S3‑181223	AS SMC Handling- update	Huawei; HiSilicon	CR	Approval	Yes	Yes	merged	No	S3‑181456
		S3‑181224	AS SMC Handling-registration	Huawei; HiSilicon	CR	Approval	Yes	Yes Nokia and Ericsson didn’t agree with removing the "only".	revised	No	S3‑181518
		S3‑181518	Clarifications to: Security algorithm selection, key establishment and security mode command procedure	Huawei, Hisilicon, LG Electronics, ZTE Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑181224
		S3‑181121	LS on secured Signalling-only connection	RP-180590	LS in		Yes	Yes Tdoc 181 addresses this.	replied to	No
		S3‑181451	Reply to: LS on secured Signalling-only connection	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑181335	CR for secure signalling only connections	Nokia	CR	Approval	Yes	Yes Ericsson: let's wait for the response to our LS in 451 in the next meeting.	not pursued	No
		S3‑181309	UP security policy	Ericsson	CR	Agreement	Yes	Yes Related to the LS in 493. Huawei didn’t support the document. Qualcomm: this is still under discussion in SA2.	not pursued	No
		S3‑181339	CR for Corrections in Clause 6.6 UP Security mechanisms	Nokia	CR	Approval	Yes	Yes Ericsson: let's decide: shall we mandate confidentiality protection for IP based PDU sessions? Qualcomm: let's come back to this in the next meeting, until SA2 and RAN2 have progressed on this issue. Docomo: if there's a possibility for downgrading security, we should tell RAN2. Qualcomm replied that there several options being discussed and that if confidentiality protection wasn't ensured there would be a rejection.	not pursued	No
		S3‑181280	F1-C Protection	Orange Spain	CR	Approval	Yes	Yes	revised	No	S3‑181440
		S3‑181440	F1-C Protection	Orange Spain,Deutsche Telekom,KPN,Huawei,HiSilicon	CR	Approval	Yes	Yes Ericsson: IPSec for these interfaces is not cloud friendly. TLS or dTLS are preferred. We agree with the last requirement.	agreed	No		S3‑181280
		S3‑181331	Discussion on ng-eNB related security specification	Qualcomm Incorporated	discussion	Discussion	Yes	Yes	noted	No
		S3‑181257	Modification for algorithm names	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑181520
		S3‑181520	Clarifications to: UP security mechanisms	Huawei, Hisilicon, LG Electronics	CR	Approval	Yes	Yes	agreed	No		S3‑181257
		S3‑181266	Editorial corrections of clause 6.5	LG Electronics	CR	Agreement	Yes	Yes	merged	No	S3‑181521
		S3‑181267	Editorial corrections of clause 6.6	LG Electronics	CR	Agreement	Yes	Yes	revised	No	S3‑181522
		S3‑181522	Editorial corrections of clause 6.6	LG Electronics	CR	Agreement	Yes	Yes	merged	No	S3‑181520	S3‑181267
		S3‑181268	Editorial corrections of clause 6.7	LG Electronics	CR	Agreement	Yes	Yes	merged	No	S3‑181518
		S3‑181340	Misleading title given to clause 6.13	Nokia	CR	Approval	Yes	Yes	agreed	No
		S3‑181521	Clarifications to: RRC security mechanisms	LG	CR	Agreement	Yes	Yes	agreed	No
7.2.5	NAS security	S3‑181141	Add description for key handing during multiple registration in same PLMN	ZTE Corporation	CR	Approval	Yes	Yes Ericsson: no need for a new clause, there are existing clauses where we can have this. The content is overlapping with other many contributions.	merged	No	S3‑181547
		S3‑181139	Remove EN for initial NAS message protection	ZTE Corporation	CR	Approval	Yes	Yes Ericsson: keep only the last two changes.	revised	No	S3‑181544
		S3‑181544	Remove EN for initial NAS message protection	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑181139
		S3‑181148	Editorial modification on initial NAS message protection	ZTE Corporation	CR	Approval	Yes	Yes Ericsson: the description is already in SA2 procedure and it is not security related. Huawei agreed and step 2 modification was removed.	merged	No	S3‑181544
		S3‑181320	Not sending SUCI in response to a hash failure	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes Ericsson agreed that there was no need with sending the SUCI again, but they agreed with asking CT1 as well. It was agreed to send the LS.	endorsed	No
		S3‑181146	Modification on NAS SMC procedure	ZTE Corporation	CR	Approval	Yes	Yes Ericsson: we have no network security policy, we have ABBA. There's a major rewrite here and we have many suggestions to improve this. On the other hand, we don’t dissapprove. Overlapping with 1319.	revised	No	S3‑181546
		S3‑181546	Modification on NAS SMC procedure	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181518	S3‑181146
		S3‑181162	Authentication procedure is common for multiple registration in same PLMN	ZTE Corporation	CR	Approval	Yes	Yes Ericsson: there is no common NAS security context defined anywhere. There was an agreement on the fundamentals but the wording couldn't be agreed.	merged	No	S3‑181547
		S3‑181308	Multiple NAS connections	Ericsson	CR	Agreement	Yes	Yes It was agreed to have all multi NAS input into the revision of this CR.	revised	No	S3‑181547
		S3‑181547	Multiple NAS connections	Ericsson, ZTE Corporation, Huawei, Hisilicon, Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		S3‑181308
		S3‑181321	Proposed solution for handling the NAS security when registered via 3GPP and non-3GPP in the same PLMN	Qualcomm Incorporated	discussion	Discussion	Yes	Yes It was agreed to add an editor's note in 6.4.2.	noted	No
		S3‑181322	Addding the procedures for handling security context when multiply registered on one PLMN	Qualcomm Incorporated	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181217	NAS SMC procedure of multi NAS connection	Huawei; HiSilicon	CR	Approval	Yes	Yes	merged	No	S3‑181547
		S3‑181134	Second RR protection for multiple registration in same PLMN	ZTE Corporation	CR	Approval	Yes	Yes Ericsson preferred to have their contribution in 308, and considered this to be misplaced, a bit of an overload.	merged	No	S3‑181547
		S3‑181218	The initial value of NAS COUNT in multi NAS connection	Huawei; HiSilicon	CR	Approval	Yes	Yes Nokia: better to start from zero. Huawei agreed.	not pursued	No
		S3‑181307	NAS COUNTs	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181547
		S3‑181135	Discussion on authentication and NAS SMC handling with race condition	ZTE Corporation	discussion	Endorsement	Yes	Yes Ericsson on proposal one: why including ABBA in the transferred context? We prefer to remove this part. Ericsson wanted to avoid starting authentication in one AMF and terminating it in another. Qualcomm found the first proposal wrong for the 3GPP-only case. Ericsson: this case is valid when an UE in a non 3GPP network goes into a 3GPP network during the authentication procedure. It's better to finish the initial auth in the initial leg than starting the authentication again. Qualcomm: proposal one does not work when there is no multi-NAS, so I would like to include this. Docomo: Proposal 1189 would avoid proposal altogether. Ericsson didn’t agree with this. On proposal two: Ericsson didn't think this was needed, it is already covered somewhere else. Qualcomm and Nokia either. ZTE: How to procceed with NAS SMC multiple registration should be decided before continuing with proposal two. There wasn't support for proposal two. On proposal three: Ericsson wanted to remove the inclusion of the derivation parameter in the transferred context.Qualcomm also wanted to clarify that this proposal was for multi-NAS only.	revised	No	S3‑181548
		S3‑181548	Discussion on authentication and NAS SMC handling with race condition	ZTE Corporation	discussion	Endorsement	Yes	Yes	endorsed	No		S3‑181135
		S3‑181136	Rules on concurrent running of authentication and NAS SMC procedure	ZTE Corporation	CR	Approval	Yes	Yes Ericsson didn’t agree with the restructuring.	revised	No	S3‑181549
		S3‑181549	Rules on concurrent running of authentication and NAS SMC procedure	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No		S3‑181136
		S3‑181189	clarify UE concurrency rule	NTT DOCOMO	CR	Agreement	Yes	Yes Ericsson: this is needed but it doesn’t take care of proposal one in 1135. Docomo asked to be minuted: Point of completion of the primary authentication is FFS, as a reminder for the next meeting.	revised	No	S3‑181566
		S3‑181566	clarify UE concurrency rule	NTT DOCOMO	CR	Agreement	Yes	Yes	merged	No	S3‑181511	S3‑181189
		S3‑181144	Modification on SMS over NAS	ZTE Corporation	CR	Approval	Yes	Yes	revised	No	S3‑181567
		S3‑181567	Clarification on SMS over NAS	ZTE Corporation, Ericsson, Huawei, Hisilicon	CR	Approval	Yes	Yes	agreed	No		S3‑181144
		S3‑181193	Resolving Editor Note on One-Step SMS over NAS	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑181567
		S3‑181299	Removal of security mechanism for MO SMS one step procedure	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181567
		S3‑181319	Correcting the anti-bidding down parameter in figure 6.7.2-1	Qualcomm Incorporated	CR	Agreement	Yes	Yes Abbreviations part was accepted and going to the definitions CR.	merged	No	S3‑181546
		S3‑181517	Security procedures for dual connectivity	Huawei,Ericsson, Qualcomm	draftCR	Approval	Yes	Yes	approved	No
		S3‑181545	LS on not sending the SUCI in response to a hash failure	Qualcomm	LS in	Approval	Yes	Yes	approved	No
7.2.6	Security context	S3‑181132	USIM 5G security parameters storage trigger	ZTE Corporation	CR	Approval	Yes	Yes Qualcomm didn’t agree with this CR. Gemalto: number of entries for 5G parameters is up to CT6.	not pursued	No
		S3‑181358	CR to Clause 10.2.1 on Emergency Call redirection	Nokia	CR	Approval	Yes	Yes	revised	No	S3‑181568
		S3‑181568	CR to Clause 10.2.1 on Emergency Call redirection	Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑181358
7.2.7	Visibility and Configurability	S3‑181379	TS 33.501 Resolving Editors notes 5.10.1 Security Visibility	BT plc	CR	Approval	Yes	Yes Vodafone: most customers will not understand this. It's a bit confusing. ORANGE: this annex goes beyond the scope of 3GPP. Docomo, Qualcomm: only remove the editor's note. No other change should happen. ORANGE supported this. Vodafone: add an editor's note on what to show to the user and when. Docomo replied that this discussion had taken part already and it was agreed that this was exposed at application level. Qualcomm: too late for Rel-15 for such editor's note.	revised	No	S3‑181565
		S3‑181565	TS 33.501 Resolving Editors notes 5.10.1 Security Visibility	BT plc	CR	Approval	No	Yes	agreed	No		S3‑181379
7.2.8	Primary authentication	S3‑181157	Discussion on using a key left at the AUSF for fast re-authentication	ZTE Corporation	discussion	Endorsement	Yes	Yes Qualcomm: Fast reauthentication is not necessary in 5G, it doesn't bring any benefit so there is no need to mandate it. Nokia agreed with the above statement, they didn’t think it was urgent. Huawei supported ZTE; fast reauthentication is used in LTE and it reduces the load in the HSS. Ericsson commented that 5G AKA is a new feature and a radical redesign shouldn’t be done at this stage. Alf( Docomo): it's an optimization and we have to analize whether we need to optimize. The Chair proposed to take this work to phase two. This was agreed.	noted	No
		S3‑181261	Fast Re-authentication Process for EAP-AKA’	Huawei, Hisilicon, China Mobile	CR	Approval	Yes	Yes	not pursued	No
		S3‑181240	Primary reauthentication Procedure	Intel China Ltd.	CR	Agreement	Yes	Yes	not pursued	No
		S3‑181377	Authentication method indication for 5G	NEC Europe Ltd	CR	Approval	Yes	Yes	not pursued	No
		S3‑181382	Fast re-authentication procedure	NEC Europe Ltd	CR	Approval	Yes	Yes	not pursued	No
		S3‑181158	Add description for authentication using a key left at the AUSF - general	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑181159	Add description for authentication using a key left at the AUSF – EAP-AKA'	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑181160	Add description for authentication using a key left at the AUSF – 5G AKA	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑181161	Add description for fast re-authentication of multiple registration	ZTE Corporation	CR	Approval	Yes	Yes	not pursued	No
		S3‑181344	Corrections to 5G AKA	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑181453
		S3‑181453	Clarifications to: Authentication procedures	Ericsson, KPN N.V., Nokia, ZTE Corporation, Huawei, Hisilicon, NTT DOCOMO	CR	Agreement	Yes	Yes	agreed	No		S3‑181344
		S3‑181345	Handling of synchronization failure	Ericsson	CR	Agreement	Yes	Yes Overlaps with 298. It was commented that it was not possible anymore to delete the clause and renumber, given that it's a TS under change control.	merged	No	S3‑181453
		S3‑181346	Corrections to EAP-AKA’	Ericsson	CR	Agreement	Yes	Yes The Annex A changes will go into tdoc 455. The rest is merged into 453.	merged	No	S3‑181453
		S3‑181349	Clarifications on unused 5G authentication vectors, and remaning authentication data	Ericsson	CR	Agreement	Yes	Yes ZTE: one auth vector for 5G as agreed, so we don’t have unused vectors. Ericsson: we try to clarify that the vector is used. ZTE found this situation hard to understand. They suggested a note for this.	merged	No	S3‑181453
		S3‑181351	Corrections related to authentication related services	Ericsson	CR	Agreement	Yes	Yes Some part will go to 453	merged	No	S3‑181453
		S3‑181298	Editorial modification for message names in the 5G-AKA	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑181453
		S3‑181165	Resolution of Editor's Note on authentication vectors	KPN N.V.	CR	Agreement	Yes	Yes Nokia: this "transformed auth vector" is confusing. This was taken offline. Clause 3 will go into tdoc 475.	merged	No	S3‑181453
		S3‑181166	Resolution of Editor's note on key left at AUSF	KPN N.V.	CR	Agreement	Yes	Yes	merged	No	S3‑181460
		S3‑181167	Deletion of Editor's Notes in clause 6.1.2 and 6.1.3 and restructuring	KPN N.V.	CR	Agreement	Yes	Yes	revised	No	S3‑181461
		S3‑181461	Deletion of Editor's Notes in clause 6.1.2 and 6.1.3 and restructuring	KPN N.V.	CR	Agreement	Yes	Yes	merged	No	S3‑181453	S3‑181167
		S3‑181287	AUSF requirements	Nokia	CR		Yes	Yes MCC commented that this change was not allowed, since it was introducing a new clause by renaming an existing one. Docomo proposed just to Void clause 5.6 to move the the SEAF requirements.ORANGE warned that this could break any references to the moved clauses. Qualcomm proposed to add the requirements in sub clauses.	merged	No	S3‑181462
		S3‑181290	Clarification to home control	Nokia	CR		Yes	Yes	revised	No	S3‑181463
		S3‑181463	Clarifications to: Linking increased home control to subsequent procedures	Nokia	CR	-	Yes	Yes	agreed	No		S3‑181290
		S3‑181291	Deletion of ed.note related to key left at AUSF	Nokia	CR		Yes	Yes	merged	No	S3‑181460
		S3‑181292	Resolving ed.note in 6.1.3.1	Nokia	CR		Yes	Yes	merged	No	S3‑181453
		S3‑181293	Clause 6.1.2 on auth method selection - clarification	Nokia	CR		Yes	Yes	revised	No	S3‑181465
		S3‑181465	Clarifications to: Initiation of authentication and selection of authentication method	Nokia,ZTE	CR	-	Yes	Yes	agreed	No		S3‑181293
		S3‑181375	Authentication method negotiation for 5G	NEC Europe Ltd	CR	Approval	Yes	Yes	not pursued	No
		S3‑181154	Editorial modification on authentication method selection	ZTE Corporation	CR	Approval	Yes	Yes Qualcomm and Nokia didn’t find this to be clarifying anything. The reference change was accepted.	revised	No	S3‑181466
		S3‑181466	Editorial modification on authentication method selection	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181465	S3‑181154
		S3‑181294	AMF requirements	Nokia	CR		Yes	Yes Qualcomm, Huawei: we don’t need this. Discussions on whether to put these as security requirements or requirements on how these functionalities work.	not pursued	No
		S3‑181288	UDM requirements	Nokia, Gemalto	CR		Yes	Yes ORANGE: .."accordance with other 3GPP specifications" , can you concrete which ones? Nokia: 33.401 would be an example. It was agreed to remove this part of the sentence and combine both sentences. Requirements in 5.8.2 were reworded.	revised	No	S3‑181467
		S3‑181467	UDM requirements	Nokia, Gemalto	CR	-	Yes	Yes	merged	No	S3‑181462	S3‑181288
		S3‑181190	Clarification for perceived potential AKA race condition	NTT DOCOMO	CR	Agreement	Yes	Yes Nokia commented that TS 29.500 captures already this in stage 3. Docomo: it's clear hop by hop but we need to consider the end-to-end case. This is not covered by HTTP2. DT agreed. Huawei supported Nokia. Nokia: if there is a doubt let's check with CT4 through an LS. Ericsson: this is in response to a vulnerability disclosure issue that didn't consider other than documents than 33.501. It was agreed to send an LS to CT4 and keep this document open if the response was coming by the end of the week. Docomo commented that there had been no response from CT4 in this meeting so some text would be drafted for tne next meeting among the interested companies.	not pursued	No
		S3‑181156	Editorial modification on 5G AKA	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181453
		S3‑181153	Editorial modification on EAP-AKA'	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181453
		S3‑181350	Corrections to the lengths of input parameters in A.2 and A.4	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181454
		S3‑181296	SN Id parameter length	Nokia	CR		Yes	Yes	revised	No	S3‑181469
		S3‑181469	SN Id parameter length	Nokia	CR	-	Yes	Yes	merged	No	S3‑181454	S3‑181296
		S3‑181347	Corrections on ngKSI and SUPI handling with EAP TLS	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑181470
		S3‑181470	Clarifications to: Using additional EAP methods for primary authentication	Ericsson, Nokia, Huawei, HiSilicon, NTT DOCOMO	CR	Agreement	Yes	Yes	agreed	No		S3‑181347
		S3‑181348	Revocation of certificates with EAP-TLS	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑181471
		S3‑181471	Revocation of certificates with EAP-TLS	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181470	S3‑181348
		S3‑181359	CR for NAI Clarification	Nokia	CR	Approval	Yes	Yes ORANGE: there is no such a case in SA2. The change in the normative part is not acceptable. Also, no normative language in the Annex B (which is informative).	revised	No	S3‑181472
		S3‑181472	Add Realm part in NAI	Nokia	CR	Approval	Yes	Yes	merged	No	S3‑181470	S3‑181359
		S3‑181260	Editorial changes over subclause B.1	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑181472
		S3‑181454	Clarifications to: Key derivation functions	Nokia,Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑181455	Clarifications to: Security contexts	KPN,Ericsson, Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑181456	Clarifications to: Security handling in state transitions	Nokia,Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S3‑181457	Corrections to: Security procedures for non-service based interfaces	Docomo	CR	Agreement	No	Yes	withdrawn	Yes
		S3‑181458	Corrections related to authentication related services	Ericsson,Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑181289
		S3‑181460	Clarifications to: Authentication framework	Ericsson, KPN N.V., Nokia, NTT Docomo	CR	Agreement	Yes	Yes	agreed	No
		S3‑181462	Clarifications to: Requirements	Nokia, Gemalto, CATT, Lenovo, Motorola Mobility, Ericsson, ZTE	CR	Agreement	Yes	Yes It was asked to be minuted the following: *Reason for change:* S3-181287: Alignment between 23.501/23.502 and 33.501 specs needed to avoid duplication. AUSF is security related NF. AUSF requirements are not specified in SA3 spec yet. S3-181467: SIDF is service from UDM. Requirements missing. S3-181226: redundant requirement S3-181227: unclarity which operator’s decision S3-181492: shift of SBA related requirements needed S3-181500: Missing PEI requirements S3-181155: Useless category for Serving network authorization S3-181439: editorial collection related to clause 5 S3-181577: wrong references on NIA and NEA algs S3-181581: implement change agreed in last meeting: tamper resistant hardware to be replaced by USIM (in SA3#90bis, ed.note was added, but USIM not) *Summary of change:* S3-181287: Using the restructering exercise where SEAF requirements are moved under AMF to rename clause 5.6 and capture AUSF requirements here. S3-181467: Corrections to title and including S3-181226: remove redundant requirement S3-181227: based on home operator’s decision (“home” added) S3-181492: void of NEF clause, shift of text and addition of NRF related requirements under SBA S3-181500: Include PEI requirements similar to IMEI. S3-181155: Remove of useless category for Serving network authorization S3-181439: editorial collection related to clause 5 S3-181577: correcting references on NIA and NEA algs to refer to Annex D S3-181581: replace tamper resistant hardware with “USIM” *Consequences if not approved:* No alignment. No requirements for the most important security function in home network. PEI storage and handling in the ME is unclear. Missing references.	agreed	No
		S3‑181468	LS on avoiding race conditions in 5G AKA	KPN	LS out	Approval	Yes	Yes	approved	No
7.2.9	Secondary authentication	S3‑181248	Discussion on ID binding in Secondary Authentication	Huawei, Hisilicon, China Southern Power Grid	discussion	Endorsement	Yes	Yes	revised	No	S3‑181431
		S3‑181431	Discussion on ID binding in Secondary Authentication	Huawei, Hisilicon, China Southern Power Grid,China Unicom	discussion	Endorsement	Yes	Yes	noted	No		S3‑181248
		S3‑181249	ID binding in Secondary Authentication	Huawei, Hisilicon, China Southern Power Grid	CR	Approval	Yes	Yes	revised	No	S3‑181432
		S3‑181432	ID binding in Secondary Authentication	Huawei, Hisilicon, China Southern Power Grid	CR	Approval	Yes	Yes Nokia: no requirements for the AAA server. The text in step 13 was made a note. Ericsson: we don’t agree with the changes.We are changing the SA2 procedure and misusing the GPSI for authentication. Qualcomm and ORANGE didn’t support this contribution either. Huawei: GPSI is not used for seconday authentication here. This was taken offline.	not pursued	No		S3‑181249
		S3‑181367	Error Correction in subclause 11.1.1	InterDigital, Inc.	CR	Approval	Yes	Yes	merged	No	S3‑181569
		S3‑181250	Updates to Secondary Authentication Procedure	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑181569
		S3‑181569	Updates to Secondary Authentication Procedure	Huawei, Hisilicon, Interdigital, CATT, NEC, Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑181250
		S3‑181228	Clause 6.11.1-2 Editorial and wording errors correction	CATT	CR	Approval	Yes	Yes	merged	No	S3‑181569
		S3‑181373	Removal of error in step 10 from the figure	NEC Europe Ltd	CR	Approval	Yes	Yes	merged	No	S3‑181569
7.2.10	Interworking	S3‑181327	Discussion on the freshness parameter for KAMF derivation in EPS to 5GS mobility	Qualcomm Incorporated	discussion	Endorsement	Yes	Yes Ericsson: it feels wrong to use the NH.	postponed	No
		S3‑181328	K’AMF derivation at EPS to 5GS mobility	Qualcomm Incorporated	CR	Agreement	Yes	Yes	postponed	No
		S3‑181256	Adding further details for EPS to 5G interworking	Huawei, Hisilicon	CR	Approval	Yes	Yes	postponed	No
		S3‑181330	KgNB derivation in EPS to 5GS handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes	revised	No	S3‑181570
		S3‑181570	Clarifications to the handover from EPS to 5Gs over N26	Qualcomm Incorporated,Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181330
		S3‑181310	Clarifications for algorithm selection, counter setting and key derivation in mapped security contexts	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑181571
		S3‑181571	Clarifications for mapping of security contexts	Ericsson	CR	Agreement	Yes	Yes Changes to Annex A go to 454.	agreed	No		S3‑181310
		S3‑181311	NAS MAC-I in IW HO from EPS to 5GS	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181570
		S3‑181329	KeNB derivation in 5GS to EPS handover	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑181300	Clarification of NAS MAC computation for TAU protection, algorithm selection and security activation during idle mode mobility from 5GS to EPS	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑181572
		S3‑181572	Clarification of NAS MAC computation for TAU protection, algorithm selection and security activation during idle mode mobility from 5GS to EPS	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181300
		S3‑181301	Clean up of clause on idle mode mobility from 5GS to EPS	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181572
7.2.11	non-3GPP access	S3‑181219	non-3GPP access when security context is available	Huawei; HiSilicon	CR	Approval	Yes	Yes Qualcomm: this clause is getting overloaded with content, better to include the info in a separate clause. Nokia agreed. Ericsson didn’t see it clear.	revised	No	S3‑181573
		S3‑181573	non-3GPP access when security context is available	Huawei; HiSilicon	CR	Approval	Yes	Yes	merged	No	S3‑181574	S3‑181219
		S3‑181282	Clarification for KN3IWF delivery in authentication	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑181575
		S3‑181575	Clarification for KN3IWF delivery in authentication	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑181574	S3‑181282
		S3‑181363	CR to Clause 7.2.1 Non-3gpp access registration EN	Nokia	CR	Approval	Yes	Yes	merged	No	S3‑181574
		S3‑181383	Security aspects of handover between 3GPP and untrusted non-3GPP accesses	NEC Europe Ltd	CR	Approval	Yes	Yes ZTE: already covered by multiple registration, we don’t need this. NEC: this scenario is mentioned in the SA2 document. Qualcomm:this is already covered.Ericsson supported this.	not pursued	No
		S3‑181398	Need for certificate-based N3IWF authentication in non-3GPP access	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181399	Use of certificates for IKEv2 in non-3GPP access	Ericsson	CR	Agreement	Yes	Yes Qualcomm: there is security value in the removed part of step 5. There are operators who could use this.Besides, it's open to DoS attacks on the UE if we don’t leave it. Lenovo supported Qualcomm. Ericsson: this is a big impact on the whole system since the operator has to provide certificates to all Ues. Qualcomm: some operators have implemented this already.	not pursued	No
		S3‑181574	Clarifications on clause 7.2	Huawei	CR	Agreement	Yes	Yes	agreed	No
7.2.12	NDS
7.2.13	Service based architecture
7.2.13.1	Interconnect (SEPP related)	S3‑181164	LS Reply on SBI Design and its Security Implications	C4-182244	LS in		Yes	Yes	replied to	No
		S3‑181473	Reply to: LS Reply on SBI Design and its Security Implications	NTT-Docomo	LS out	approval	Yes	Yes	approved	No
		S3‑181274	Discussion of potential issues in JSON parsers	NCSC	discussion	Discussion	Yes	Yes	noted	No
		S3‑181276	Adding context to SBA API requirements	NCSC	other	Approval	Yes	Yes NTT-Docomo: upgrade this document to a TR. Vodafone supported this. Tim pointed out that working with living documents was a very bad habit in SA3. It was commented that a new Study Item could be created and approved in one go with the TR.	merged	No	S3‑181474
		S3‑181427	SBA: A framework for application layer protection scheme in SEPP	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181395	Application layer solution for N32: rewriting of HTTP message into JSON objects	Ericsson	other	Approval	Yes	Yes	approved	No
		S3‑181418	Authorization across N32 - pCR to Living Document: Security of Service Based Architecture of 5G phase 1	NTT DOCOMO	other	Approval	Yes	Yes Nokia: error handling with a "shall" is too strong. Docomo: if you reject a message you need to send back an error.	revised	No	S3‑181479
		S3‑181479	Authorization across N32 - pCR to Living Document: Security of Service Based Architecture of 5G phase 1	NTT DOCOMO	other	Approval	Yes	Yes	approved	No		S3‑181418
		S3‑181244	N32 message anti-spoofing within the SEPP	Deutsche Telekom AG	other	Approval	Yes	Yes Ericsson: this is too detailed for a normative text. Vodafone: this will go into a TR.No need to write such editors' notes. Huawei: this is more requirements than a solution. Their document 285 also dealt with this issue.They asked for the second bullet to be removed. Docomo: certificate check should be put in there. On the second bullet Docomo commented: any SEPP can put any IP address in there. This was taken offline.	revised	No	S3‑181480
		S3‑181480	N32 message anti-spoofing within the SEPP	Deutsche Telekom AG	other	Approval	Yes	Yes	approved	No		S3‑181244
		S3‑181402	pCR: Local configuration of message protection policy in SEPP	Nokia	other	Approval	Yes	Yes Ericsson: This is a solution description with several alternatives but it is written with normative language.	revised	No	S3‑181482
		S3‑181482	pCR: Local configuration of message protection policy in SEPP	Nokia	other	Approval	Yes	Yes	approved	No		S3‑181402
		S3‑181403	Remote provisioning of message protection policies in partner SEPPs	Nokia	other	Approval	Yes	Yes	revised	No	S3‑181483
		S3‑181483	Remote provisioning of message protection policies in partner SEPPs	Nokia	other	Approval	Yes	Yes	approved	No		S3‑181403
		S3‑181285	Discussion on fraudulent Registration Request threats	Huawei, Hisilicon	discussion	Approval	Yes	Yes Nokia:Solution 1 is adding load to the UDM. Huawei: we are not proposing solution one.	noted	No
		S3‑181297	Prevent fraudulent Registration Request attack	Huawei, Hisilicon	other	Approval	Yes	Yes Ericsson questioned whether SA3 had agreed on this threat. Docomo: this seems to be about serving network impersonation. Ericsson proposed to create a key issue and have this as one of the possible solutions that can be evaluated. Docomo: the key issue is network function authorization in roaming scenarios. It can be any other message than registration.	revised	No	S3‑181481
		S3‑181481	Prevent fraudulent Registration Request attack	Huawei, Hisilicon	other	Approval	Yes	Yes	approved	No		S3‑181297
		S3‑181396	Rel-15 fallback solution for Interconnect (N32)	Ericsson	discussion	Endorsement	Yes	Yes	withdrawn	Yes
		S3‑181243	Agenda and notes of conference call on SEPP security policies	Deutsche Telekom AG	discussion	Information	Yes	Yes	noted	No
		S3‑181394	SBA: Example for SEPP Protection Policies	Ericsson	discussion	Information	Yes	Yes	noted	No
		S3‑181242	Agenda and notes of conference call on SEPP protection mechanisms	Deutsche Telekom AG	discussion	Information	Yes	Yes	noted	No
		S3‑181397	To-Do-list for application layer solution	Ericsson	discussion	Information	Yes	Yes	noted	No
		S3‑181435	Way forward for Interconnect (N32) security	Ericsson, Deutsche Telekom, Nokia	discussion	Endorsement	Yes	Yes Nokia: Give a general solution for end-to-end and enhance it for Rel-16. Docomo: get the functionality in Rel-15 and fix it with cat F CRs. We don’t want IPX interconnects pre Rel-15 and post Rel-15. I prefer to have this in Rel-15 if we are close enough to completion and then fix with cat-F CRs. There is still time. ORANGE agreed with this. This had to be taken offline.	revised	No	S3‑181509
		S3‑181509	Way forward for Interconnect (N32) security	Ericsson, Deutsche Telekom, Nokia	discussion	Endorsement	Yes	Yes	endorsed	No		S3‑181435
		S3‑181508	SBA evening session report	Qualcomm	report	Information	Yes	Yes	noted	No
		S3‑181519	LS on SA3 status on security-related API requirements	Deutsche Telekom	LS out	Approval	No	Yes	withdrawn	Yes
7.2.13.2	Other	S3‑181258	Correct typo in SBA Authorization	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑181484
		S3‑181484	Correct typo in SBA Authorization	Huawei, Hisilicon	CR	Approval	Yes	Yes	merged	No	S3‑181487	S3‑181258
		S3‑181405	SBA Authentication issues	Ericsson	discussion	Endorsement	Yes	Yes Nokia proposed to add service layer authentication not to be specified in Rel-15 in proposal one. This was agreed. The rest of proposal one was also modified to add an explicit chain of trust.	revised	No	S3‑181485
		S3‑181485	SBA Authentication issues	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No		S3‑181405
		S3‑181406	Intra PLMN NF to NF authentication	Ericsson	CR	Agreement	Yes	Yes DT: When reliying on token based authentication I'm not sure that we should mandate TLS. The "shall" is a "should".	revised	No	S3‑181486
		S3‑181486	Intra PLMN NF to NF authentication	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S3‑181406
		S3‑181408	SBA: Token Based Authorization for the inter-PLMN case	Ericsson	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181425	SBA: Commenting contribution on S3-181408	Nokia	discussion	Decision	Yes	Yes	noted	No
		S3‑181381	Editor’s Note on NRF to NRF authentication when there is a non transparent proxy (SEPP) between them	Nokia	CR	Agreement	Yes	Yes The change was agreed and merged into 486.	merged	No	S3‑181486
		S3‑181385	Editor’s Note on per UE subscription level authorization in NRF	Nokia	CR	Agreement	Yes	Yes	merged	No	S3‑181487
		S3‑181206	The granularity of NF service discovery	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑181487
		S3‑181487	The granularity of NF service discovery	Huawei, Hisilicon,Nokia	CR	Approval	Yes	Yes	agreed	No		S3‑181206
		S3‑181205	Verification of claims in the token during service access request	Huawei, Hisilicon	CR	Approval	Yes	Yes Ericsson commented that the editor's note versed on the possiblity of the token being signed. It was commented that there was much behind this editor's note and that further discussions were needed. A new CR would be brought for the next meeting.	not pursued	No
		S3‑181407	SBA: Inter-PLMN routing and TLS issues	Ericsson	discussion	Discussion	Yes	Yes Docomo didn’t agree with the bump in TLS. Nokia suggested some changes that were accepted in the revision.	noted	No
		S3‑181409	Inter PLMN routing and TLS: Solution Options	Ericsson	other	Approval	Yes	Yes	revised	No	S3‑181490
		S3‑181490	Inter PLMN routing and TLS: Solution Options	Ericsson	other	Approval	Yes	Yes	approved	No		S3‑181409
		S3‑181286	AUSF clarification	Nokia	CR		Yes	Yes MCC commented that the clauses should be voided, not deleted. ORANGE expressed concerns on voiding clauses that may be referenced by other groups. It was taken offline to wait for some feedback from SA2.	merged	No	S3‑181458
		S3‑181289	UDM clarification	Nokia	CR		Yes	Yes	revised	No	S3‑181458
		S3‑181295	NRF and NEF requirements	Nokia	CR		Yes	Yes	revised	No	S3‑181492
		S3‑181492	NRF and NEF requirements	Nokia	CR	-	Yes	Yes	merged	No	S3‑181462	S3‑181295
		S3‑181236	Living Document: Security of Service Based Architecture of 5G phase 1	China Mobile Group Device Co.	other		Yes	Yes	revised	No	S3‑181474
		S3‑181474	Living Document: Security of Service Based Architecture of 5G phase 1	China Mobile Group Device Co.	other	-	Yes	Yes	approved	No		S3‑181236
		S3‑181438	Editorial changes to clause 9	Nokia	CR	Agreement	Yes	Yes This needed some cleaning up for which there was no time for the current meeting.	not pursued	No
7.2.14	Privacy	S3‑181226	Clause 5.8 Remove a redundant requirement	CATT	CR	Agreement	Yes	Yes	merged	No	S3‑181462
		S3‑181191	Clause 5.2.5 Add a requirement for routing SUCI	CATT,China Mobile	CR	Agreement	Yes	Yes KPN: add "in the unencrypted part" in the requirement. Ericsson: routing information is already mentioned, do we need this? It was proposed to send an LS to SA2. The document was taken offline.	not pursued	No
		S3‑181229	Clause 6.12.2 Add routing assistance indicator in SUCI	CATT	CR	Agreement	Yes	Yes Vodafone: rejecting handsets that haven’t been sold by companies is not allowed in many countries. Some companies wouldn’t want to update the USIM, so where is the roaming information coming from? Vodafone didn't disagree with this, but thought it was incomplete. ORANGE: the requirement does not include any security part, it looks like something from a CT group. Interdigital: this requirement affects privacy. China Unicom supported CATT's proposal.	not pursued	No
		S3‑181343	SIDF - NF discovery with SUCI	Ericsson	CR	Agreement	Yes	Yes Docomo: operators need to pre-provision this in the UE.There is a need to standardise the pre-provision of routing information. I don’t agree with using the Home Network public key identifier . Qualcomm: enforce different entities to use different keys seems to be a good idea. ORANGE: this is not a SA3 issue, it's a CT1 issue. We don’t know all the other routing aspects that are being handled by other groups. NEC: we need to standardise these parameters. Interdigital didn’t agree with having this. Vodafone: SA3 has an interest in protecting the routing information. ORANGE: send an LS to CT1and SA2 to check how they see the routing so we know whether we need to protect the information. KPN supported this. NEC, Qualcomm: mandate the routing information with a "shall". This was taken offline.	not pursued	No
		S3‑181386	UDM routing information in SUCI	NEC Europe Ltd	CR	Approval	Yes	Yes Same topic as tdoc 343. Nokia: something like this should not be mandated. It was agreed to include this in the LS in 494.	not pursued	No
		S3‑181269	Use type parameter for asymmetric key encryption schemes	LG Electronics	discussion	Discussion	Yes	Yes	noted	No
		S3‑181270	Use type information as a SUCI construction input paramter in Annex C	LG Electronics	CR	Agreement	Yes	Yes	revised	No	S3‑181449
		S3‑181449	Use type information as a SUCI construction input paramter in Annex C	LG Electronics	CR	Agreement	Yes	Yes ORANGE didn’t agree with this. Same concerns as the last meeting. Qualcomm: not a good practice to use things for IMSI privacy for other use cases. They didn’t agree with this either.	not pursued	No		S3‑181270
		S3‑181334	Delete Editor’s Note in C.3.4.3	Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No
		S3‑181495	Clarifications to: Protection schemes for SUCI	NTT-Docomo,Ericsson,Huawei,Nokia	CR	Agreement	Yes	Yes	agreed	No
		S3‑181393	SUCI - readiness to protection schemes update in future	Ericsson	CR	Agreement	Yes	Yes	revised	No	S3‑181496
		S3‑181496	Clarifications to: Subscription identifier privacy	Ericsson, CATT, NEC, Docomo, Nokia, Qualcomm	CR	Agreement	Yes	Yes	agreed	No		S3‑181393
		S3‑181182	Discussion paper on Subscription id format	Nokia	discussion	Endorsement	Yes	Yes	noted	No
		S3‑181341	SUCI - protection schemes identifiers	Ericsson	CR	Agreement	Yes	Yes Qualcomm: no need to have 8 bits, 4 bits are enough. We don’t need more space than the space used for supporting algorithms. MCC: the NOTE is giving normative information, it shouldn't be a note. Also reword "Currently…" for "the defined values are". Ericsson: we are assigning values for the proprietary scheme. How many values should we assign? Qualcomm replied that 8 values but Ericsson found them too many and suggested 4 instead.	revised	No	S3‑181497
		S3‑181497	SUCI - protection schemes identifiers	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181495	S3‑181341
		S3‑181342	SUCI - protection schemes output sizes	Ericsson	CR	Agreement	Yes	Yes	merged	No	S3‑181495
		S3‑181230	Clause 6.12.2 Wording and correction related to SUCI	CATT	CR	Approval	Yes	Yes	revised	No	S3‑181498
		S3‑181498	Clause 6.12.2 Wording and correction related to SUCI	CATT	CR	Approval	Yes	Yes	merged	No	S3‑181496	S3‑181230
		S3‑181227	Clause 5.2.5 Privacy requirement clarification	CATT	CR	Approval	Yes	Yes	merged	No	S3‑181462
		S3‑181233	Clause 6.12.4 Remove some redundant content	CATT	CR	Approval	Yes	Yes KPN didn’t agree with the last two changes. ORANGE and Nokia didn’t agree with the CR.	not pursued	No
		S3‑181187	Clarification UE responding with SUCI to identifier request	NTT DOCOMO	CR	Agreement	Yes	Yes	merged	No	S3‑181476
		S3‑181371	Resolving EN on sending SUCI in the Identifier Response message	NEC Europe Ltd	CR	Approval	Yes	Yes	revised	No	S3‑181476
		S3‑181476	Resolving EN on sending SUCI in the Identifier Response message	NEC Europe Ltd,Docomo	CR	Approval	Yes	Yes	merged	No	S3‑181496	S3‑181371
		S3‑181333	Limiting SUCI in Identifier Response	Qualcomm Incorporated	CR	Agreement	Yes	Yes Docomo agreed with the concept but not with the wording. Nokia agreed. Revised to change the wording.	revised	No	S3‑181499
		S3‑181499	Limiting SUCI in Identifier Response	Qualcomm Incorporated	CR	Agreement	Yes	Yes	merged	No	S3‑181496	S3‑181333
		S3‑181179	Generation and Rotation of 5G-GUTI	Apple Computer Trading Co. Ltd	CR	Approval	Yes	Yes ORANGE: subscription is managed by the home network and 5G-GUTI by the serving network. Ericsson: this was one of the key issues in the TR and there were many discussions on this topic and we shouldn’t reopen them now. It should be left for phase two. Docomo: GUTI should be changed after every exposure and here it is after every unexposure. This needs to be discussed. It was taken offline.	not pursued	No
		S3‑181271	Missing PEI requirements	Motorola Mobility, Lenovo	CR	Approval	Yes	Yes	revised	No	S3‑181445
		S3‑181445	Missing PEI requirements	Motorola Mobility, Lenovo	CR	Approval	Yes	Yes It was agreed to remove the new clause. ORANGE: the second requirement was discussed in the study phase, and we concluded that it should be in Rel-16. Todor didn’t agree with the first requirement, but it was agreed to reword it. Qualcomm and Docomo supported the second requirement.It was capturing a requirement that it is already in LTE. Docomo: the agreement is that we want to send the PEI only when there is a NAS security setup.	revised	No	S3‑181500	S3‑181271
		S3‑181500	Missing PEI requirements	Motorola Mobility, Lenovo	CR	Approval	Yes	Yes	merged	No	S3‑181462	S3‑181445
		S3‑181272	Missing PEI requirements	Motorola Mobility	LS out	Approval	Yes	Yes ORANGE: format of IMEI is not SA3 specific. It was not needed anymore after discussions in tdoc 500 and hence it was noted.	noted	No
		S3‑181180	Introduction of the Subscription Concealed Identifier to EPC	Apple Computer Trading Co. Ltd	CR	Approval	Yes	Yes ORANGE: this is 5G affecting 33.401 and our Work Item doesn’t have this in scope. We need a new WID for this new mechanism. Vodafone didn’t support this mechanism. There were other ways much less harmful ways to protect the IMSI. Docomo: this could have impact on other groups, better to have a study. Qihoo 360: we support the IMSI privacy in LTE, like in here.	not pursued	No
		S3‑181129	Use of PKI to Mitigate Vulnerabilities in 3GPP Networks	AT&T, MITRE, Interdigital, TCG	discussion	Discussion	Yes	Yes	noted	No
		S3‑181170	Introduction of the Subscription Concealed Identifier to EPC	Apple Computer Trading Co. Ltd	CR	Approval	No	Yes	withdrawn	Yes
		S3‑181237	Clause 6.12.5 Add SIDF decryption process description	CATT	CR	Approval	No	Yes	withdrawn	Yes
		S3‑181238	Clause 6.12.5 Add SIDF decryption process description	CATT	CR	Approval	Yes	Yes Ericsson: redudant, we have very similar text in the annex C.3.3. ORANGE agreed. Revised to reference this annex.	not pursued	No
		S3‑181494	LS on AUSF/UDM instance Selection and SUCI parameters	Nokia	LS out	Approval	Yes	Yes	approved	No
7.2.15	Incoming and outgoing LSes	S3‑181112	LS on one step MO SMS procedure	C1-181759	LS in		Yes	Yes	replied to	No
		S3‑181446	Reply to: LS on one step MO SMS procedure	Ericsson	LS out	approval	Yes	Yes	approved	No
		S3‑181115	NGMN Paper on 5G End-to-End Architecture Framework	NGMN	LS in		Yes	Yes BT: The sections on Network slicing, CU/DU split are worth checking out. The Chair encouraged companies to review this document.	noted	No
		S3‑181116	5G Security – Package 3: Mobile Edge Computing / Low Latency / Consistent User Experience Updated version	NGMN	LS in		Yes	Yes	noted	No
		S3‑181117	UE capability related to integrity protection of DRBs	R2-1804056	LS in		Yes	Yes Related discussion in 309.	postponed	No
		S3‑181447	Reply to: UE capability related to integrity protection of DRBs	Intel	LS out	approval	No	Yes	withdrawn	Yes
		S3‑181118	LS on Security aspects of supporting LTE connected to 5GC	R2-1804108	LS in		Yes	Yes	replied to	No
		S3‑181448	Reply to: LS on Security aspects of supporting LTE connected to 5GC	Qualcomm	LS out	approval	Yes	Yes	approved	No		S3‑181324
		S3‑181119	LS on security for inactive state	R2-1804136	LS in		Yes	Yes	replied to	No
		S3‑181450	Reply to: LS on security for inactive state	Huawei, Ericsson	LS out	approval	Yes	Yes Discussions on the security algorithm negotiation: Ericsson and Nokia didn’t consider that a new mechanism was required. It was commented that this was a RAN2 decision and not SA3's. It was agreed to have this sentence on the LS.	approved	No
		S3‑181181	Discussion paper on RP-180590/S3-181121	Nokia	discussion	Endorsement	Yes	Yes Huawei: registration procedure is separate from service request, all scenarios described in SA2 that require this signalling only connections is only for DRB. Huawei commented that they hadn't seen any SA3 related scenario or use case. Ericsson supported Huawei. Docomo: I understand that we are looking at scenarios where no DRB is being set up. One of these scenarios is MDT. I don’t see this in the discussions. I don’t understand why they are asking us about a RAN internal problem. Nokia:: scenarios are an issue for SA2 or RAN groups. We need a mechanism for this. DT agreed with Nokia. Ericsson commented that mechanisms already existed and it was up to the other groups to decide how to do the procedure. Docomo: I understand that they are asking for scenarios in the LS. Huawei: RRC security context is established separately from user plane context. The use case is to be defined by SA2.	noted	No
		S3‑181184	draft_Reply LS to RP-180590 Secure signalling AS context	Nokia	response	Approval	Yes	Yes	revised	No	S3‑181451
		S3‑181430	LS on paging with IMSI/SUCI in 5GS	C1-181791	LS in		Yes	Yes Discussed together with tdoc 183.	replied to	No
		S3‑181452	Reply to: LS on paging with IMSI/SUCI in 5GS	Nokia	LS out	approval	Yes	Yes	approved	No
		S3‑181183	Discussion paper on C1-181791 LS on Paging with IMSI/SUPI	Nokia	discussion	Endorsement	Yes	Yes Ericsson: not a new topic for us, we have sent an LS about it already. We are in CC. It's already clear that there is an issue for privacy. It's a discussion between CT1 and SA2. We have stated our opinion already. It was agreed to send an LS response.	endorsed	No
		S3‑181123	LS response on User Plane Security Policy	S2-182787	LS in		Yes	Yes	noted	No
		S3‑181491	LS on security aspects of supporting LTE connected to 5GC	C1-182485	LS in	discussion	Yes	Yes	noted	No
		S3‑181493	LS on UE capability related to integrity protection of DRBs	C1-182603	LS in	discussion	Yes	Yes Qualcomm: Max data rate supported from the UE to the network is currently beign discussed in SA2 and RAN2. We cannot progress until they have concluded the discussion on this issue.	noted	No
7.2.16	Others	S3‑181150	Editorial modification on reference	ZTE Corporation	CR	Approval	Yes	Yes	agreed	No
		S3‑181155	Editorial modification on authentication and authorization requirement	ZTE Corporation	CR	Approval	Yes	Yes	merged	No	S3‑181462
		S3‑181188	Editorials to 33.501	NTT DOCOMO	CR	Agreement	Yes	Yes	revised	No	S3‑181439
		S3‑181439	Editorials to 33.501	NTT DOCOMO	CR	Agreement	Yes	Yes	revised	No	S3‑181576	S3‑181188
		S3‑181576	Editorials to 33.501	NTT DOCOMO	CR	Agreement	Yes	Yes Clause 5 goes to 462. Clause 6.1.2 goes to 465. Clause 6.1.4 goes to 463. 6.8 goes to 456. Annex A goes to 454. 6.1.1 goes to 460. 6.12 goes to 496. 6.2 is removed.	agreed	No		S3‑181439
		S3‑181411	Reference corrections in clause 5	Nokia	CR		Yes	Yes Ericsson: the references should go to Annex D instead.	revised	No	S3‑181577
		S3‑181577	Reference corrections in clause 5	Nokia	CR	-	Yes	Yes	merged	No	S3‑181462	S3‑181411
		S3‑181412	Reference corrections in clause 6	Nokia	CR		Yes	Yes	revised	No	S3‑181578
		S3‑181578	Reference corrections in clause 6	Nokia	CR	-	Yes	Yes	agreed	No		S3‑181412
		S3‑181413	Reference corrections in clause 8	Nokia	CR		Yes	Yes	revised	No	S3‑181579
		S3‑181579	Reference corrections in clause 8	Nokia	CR	-	Yes	Yes	agreed	No		S3‑181413
		S3‑181414	Collection of editorial corrections	Nokia	CR		Yes	Yes	revised	No	S3‑181580
		S3‑181580	Collection of editorial corrections	Nokia	CR	-	Yes	Yes Change 1 to 569. Change 2 to 454. Change 3 in this document and merged in 470.	merged	No	S3‑181470	S3‑181414
		S3‑181143	Modification on UE’s subscribe privacy requirement	ZTE Corporation	CR	Approval	Yes	Yes	revised	No	S3‑181581
		S3‑181581	Modification on UE’s subscribe privacy requirement	ZTE Corporation	CR	Approval	Yes	Yes Only third change stays.	merged	No	S3‑181462	S3‑181143
		S3‑181145	Modification on NEF requirement	ZTE Corporation	CR	Approval	Yes	Yes ORANGE, Nokia didn’t support this.	not pursued	No
		S3‑181149	Modification on gNB’s requirement	ZTE Corporation, China Mobile	CR	Approval	Yes	Yes Huawei didn’t support this. BT and ORANGE either.	not pursued	No
		S3‑181207	Authorization mechanism for NEF-AF interface	Huawei, Hisilicon	CR	Approval	Yes	Yes Nokia: authorization is covered by SA2.	not pursued	No
		S3‑181186	Editorials to 33.501	NTT DOCOMO	CR		Yes	Yes	withdrawn	Yes
		S3‑181436	Changes to definition clause for drafting rule conformity	Nokia	CR	Agreement	Yes	Yes	revised	No	S3‑181475
		S3‑181475	Clarifications to definitions and abbreviations	Nokia,KPN	CR	Agreement	Yes	Yes	agreed	No		S3‑181436
		S3‑181437	Editorial changes to clause 10 and 12	Nokia	CR	Agreement	Yes	Yes	revised	No	S3‑181582
		S3‑181582	Editorial changes to clause 10 and 12	Nokia	CR	Agreement	No	Yes	agreed	No		S3‑181437
		S3‑181478	Working procedure and table of clause-CRs	Nokia	discussion	discussion	Yes	Yes The work of Anja(Nokia) was appreciated by the group.	noted	No
7.3	Mission Critical Security Enhancements (eMCSec) (Rel-15)	S3‑181177	[eMCSec] 33180 R15 various technical clarifications	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
		S3‑181424	[eMCSEC] Removal of Editor’s note in Clause 5.1.3.1.	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181176	[eMCSec] 33180 R15 migration user authentication	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
		S3‑181175	[eMCSec] 33180 R15 media mixing note	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
		S3‑181420	[eMCSEC] Resolution of editor’s notes within Clause 10 on logging, audit and discreet monitoring.	NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑181489
		S3‑181489	[eMCSEC] Resolution of editor’s notes within Clause 10 on logging, audit and discreet monitoring.	NCSC	CR	Agreement	Yes	Yes	agreed	No		S3‑181420
		S3‑181174	[eMCSec] 33180 R15 Interconnection references clarification	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
		S3‑181422	[eMCSEC] Addition of test vector for MIKEY-SAKKE UID	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181419	[eMCSEC] Removal of Editor’s note in Clause I.3.4	NCSC	CR	Agreement	Yes	Yes	revised	No	S3‑181488
		S3‑181488	[eMCSEC] Removal of Editor’s note in Clause I.3.4	NCSC	CR	Agreement	Yes	Yes	agreed	No		S3‑181419
7.4	Security Architecture for the Mobile Communication System for Railways (MONASTERY_SEC) (Rel-15)
7.5	Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
7.6	Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)	S3‑181208	Scope of CAPIF security	Huawei, Hisilicon	pCR	Approval	Yes	Yes Motorola: T8 interface already appears in TS 23.222 Annex B. We are doing security for TS 23.222. Samsung: the document does not consider the need of harmonization. It harmonizes or it doesn’t. There was no support for this document.	noted	No
		S3‑181368	CAPIF re-organizing	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181529
		S3‑181529	CAPIF re-organizing	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181540	S3‑181368
		S3‑181540	CAPIF re-organizing	NEC Corporation,Huawei,Samsung	pCR	Approval	Yes	Yes	approved	No		S3‑181529
		S3‑181171	[CAPIF] 33.122 Functional Security Model	Motorola Solutions Danmark A/S	pCR	Approval	Yes	Yes	approved	No
		S3‑181209	Security requirements for service API discovery	Huawei, Hisilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑181360	CAPIF requirements	NEC Corporation	pCR	Approval	Yes	Yes China Mobile: what is additional level of authentication? NEC: I want to express that there should be something more. Nokia,Samsung: this requirement is not needed.	noted	No
		S3‑181384	CAPIF – Topology Hiding	Samsung, MSI	pCR		Yes	Yes Nokia: clarification by adding transport security layer.	revised	No	S3‑181538
		S3‑181538	CAPIF – Topology Hiding	Samsung, MSI	pCR	-	Yes	Yes	approved	No		S3‑181384
		S3‑181365	Security procedure for onboarding API invokers to CAPIF	NEC Corporation	pCR	Approval	Yes	Yes	merged	No	S3‑181514
		S3‑181392	CAPIF – API Invoker on boarding	Samsung	pCR		Yes	Yes	revised	No	S3‑181514
		S3‑181514	CAPIF – API Invoker on boarding	Samsung,NEC	pCR	-	Yes	Yes	approved	No		S3‑181392
		S3‑181213	Derivation of the key AEFPSK	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑181515
		S3‑181362	Binding of communication endpoins to the derivation of AEFpsk	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑181387	CAPIF – Key Derivation	Samsung, MSI	pCR		Yes	Yes	revised	No	S3‑181515
		S3‑181515	CAPIF – Key Derivation	Samsung, MSI	pCR	-	Yes	Yes	approved	No		S3‑181387
		S3‑181214	Security credentials for TLS before initiating TLS connection	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑181390	CAPIF – Update on CAPIF-2e Security procedure	Samsung	pCR		Yes	Yes	approved	No
		S3‑181215	TLS-PSK ciphersuites for security method of CAPIF-2e reference point	Huawei, Hisilicon	pCR	Approval	Yes	Yes Revised to Refer to 33.210 Annex D.	revised	No	S3‑181539
		S3‑181539	TLS-PSK ciphersuites for security method of CAPIF-2e reference point	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181215
		S3‑181370	Authentication between API invoker and AEF upon the service invocation	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑181211	Authorization mechanism for CAPIF-2 reference point	Huawei, Hisilicon	pCR	Approval	Yes	Yes This proposal was agains the restructuring proposed by NEC in 529.	merged	No	S3‑181540
		S3‑181391	CAPIF – Update on CAPIF-2 authorization	Samsung	pCR		Yes	Yes	merged	No	S3‑181540
		S3‑181210	Authorization mechanism for CAPIF-2e reference point	Huawei, Hisilicon	pCR	Approval	Yes	Yes	merged	No	S3‑181516
		S3‑181364	Security procedure for the AEF to obtain API invoker’s authorization rights	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑181389	CAPIF – Editor’s note resolution on authorization mechanism	Samsung, MSI	pCR		Yes	Yes	revised	No	S3‑181516
		S3‑181516	CAPIF – Editor’s note resolution on authorization mechanism	Samsung, MSI	pCR	-	Yes	Yes	approved	No		S3‑181389
		S3‑181366	Clarification of access token generation to clause 5.2.2.3 Method 3 – Token Based authorization	NEC Corporation	pCR	Approval	Yes	Yes	revised	No	S3‑181507
		S3‑181507	Clarification of access token generation to clause 5.2.2.3 Method 3 – Token Based authorization	NEC Corporation,Samsung, Motorola Solutions, Huawei	pCR	Approval	Yes	Yes	revised	No	S3‑181541	S3‑181366
		S3‑181541	Clarification of access token generation to clause 5.2.2.3 Method 3 – Token Based authorization	NEC Corporation,Samsung, Motorola Solutions, Huawei	pCR	Approval	Yes	Yes Modifying step 4 as proposed by Nokia.	approved	No		S3‑181507
		S3‑181369	API invoker obtaining authorization from CAPIF core fuction to access service API	NEC Corporation	pCR	Approval	Yes	Yes	noted	No
		S3‑181212	Security method between API invoker and API exposing function	Huawei, Hisilicon	pCR	Approval	Yes	Yes Nokia: the new text doesn’t fit into this clause. NEC agreed. They admitted that the document didn’t have the right place to include this. It was agreed to make it into an editor's note stating that the paragraph had to be moved.	revised	No	S3‑181542
		S3‑181542	Security method between API invoker and API exposing function	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181212
		S3‑181361	Editorial corrections to TS 33.122 v0.1.0	NEC Corporation	pCR	Approval	Yes	Yes	approved	No
		S3‑181537	Draft TS 33.122	Samsung	draft TS	Approval	Yes	Yes	approved	No
7.7	PLMN RAT selection (Steering of Roaming)	S3‑181113	LS on a potential USIM solution for PLMN and RAT selection policies for roaming	C6-170696	LS in		Yes	Yes	noted	No
		S3‑181114	Reply LS on PLMN and RAT selection policies for roaming	S2-182723	LS in		Yes	Yes Already taken into account.	noted	No
		S3‑181281	Living Document: Security of PLMN/RAT selection policies for roaming	Orange Spain	other	Endorsement	Yes	Yes	revised	No	S3‑181503
		S3‑181503	Living Document: Security of PLMN/RAT selection policies for roaming	Samsung	other	Approval	Yes	Yes	approved	No		S3‑181281
		S3‑181332	Updates to Solution #6 in SoR Living Doc	Qualcomm Incorporated, T-Mobile US	other	Approval	Yes	Yes	revised	No	S3‑181426
		S3‑181426	Updates to Solution #6 in SoR Living Doc	Qualcomm Incorporated, T-Mobile US, DT	other	Approval	Yes	Yes Vodafone: VPLMN will not allow the message go throguh but you want to be in that network. How do you deal with operators excluding the steering of roaming?There will be operators who will not implement this. ORANGE: if a country has no VPLMNs not implementing this, what happens with the UE? Qualcomm: the UE will select the PLMN as described by CT1. ORANGE didn’t agree with the conclusion, so it was removed. Qualcomm commented that a solution was needed for the next meeting and a technical vote may be necessary.	revised	No	S3‑181502	S3‑181332
		S3‑181502	Updates to Solution #6 in SoR Living Doc	Qualcomm Incorporated, T-Mobile US, DT	other	Approval	Yes	Yes	approved	No		S3‑181426
		S3‑181428	LS on SoR mechanism	S3i180141	LS in		Yes	Yes BT: there are some countries where turning on encryption would be a problem. ORANGE: LI aspects are to be assessed, it should be done in the next meeting. Qualcomm agreed, but not to add it to their solution presented in the current meeting. Ericsson commented that this was already in the living document.	noted	No
		S3‑181477	Reply LS on SoR mechanism	C1-182490	LS in	Discussion	Yes	Yes Qualcomm proposed to respond with option B. Huawei: how is the USIM preconfigured with the list? If the HPLMN doesn’t know where the UE is going? They prefered option A. The preference was option B. ORANGE: we are building a solution in the fly that wasn't in the scope of 5G. Steering of roaming is about business relationships; we cannot make a solution without business requirements and we haven’t had any contact and input with GSMA. We should take this to Rel-16.There is no WID about this in 3GPP. T-Mobile: this is captured in SA1. The Chair commented that this is a LS coming from CT1. ORANGE: the requirement from SA1 doesn’t need this. CT1 has started work that hasn’t been agreed at all in 3GPP. The Chair commented that this issue should be discussed at SA plenary level, and not in SA3. SA3's task was to respond CT1. T-Mobile: it’s about security concerns on the options here. Vodafone: option B is better but it misses how to protect the message, and the confidentiality and integrity protection. ORANGE: we cannot do this work in Rel-15. Qualcomm wanted this to go for Rel-15. The issue needed to be discussed at Plenary level. Let's answer that option B is the way to go. Ericsson agreed. It was agreed to send the LS with the preference to option B. The Chair commented that if something had to be done, like stopping the activity, it should be done in another group and not in SA3. ORANGE: if confidentiality protection needs to be switched off as per LI requirements we wouldn't be able to carry out the security analysis properly. We cannot guarantee that this can be done in Rel-15. KPN: ORANGE can object to this work in the SA plenary.	replied to	No
		S3‑181501	Reply to: Reply LS on SoR mechanism	Samsung	LS out	approval	Yes	Yes	approved	No
7.8	Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec)(Rel-15)
7.9	Security Assurance Specification for 5G (SCAS_5G) (Rel-16)
7.9.1	NR Node B (gNB) (TS 33.511)
7.9.2	Access and Mobility Management Function (TS 33.512)
7.9.3	User Plane Function (UPF) (TS 33.513)
7.9.4	Unified Data Management (UDM) (TS 33.514)
7.9.5	Session Management Function (SMF) (TS 33.515)
7.10	Other work areas
7.10.1	SAE/LTE Security	S3‑181198	Correction and Clarification for the handling of KASME	Huawei, Hisilicon	CR	Approval	Yes	Yes	revised	No	S3‑181505
		S3‑181505	Correction and Clarification for the handling of KASME	Huawei, Hisilicon	CR	Approval	Yes	Yes Changing 4G with EPS.	agreed	No		S3‑181198
		S3‑181376	Clarifying the condition when ePDG sends its certificate in untrusted non-3GPP access	Nokia	CR	Agreement	Yes	Yes	revised	No	S3‑181506
		S3‑181506	Clarifying the condition when ePDG sends its certificate in untrusted non-3GPP access	Nokia	CR	Agreement	Yes	Yes	agreed	No		S3‑181376
7.10.2	IP Multimedia Subsystem (IMS) Security
7.10.3	Network Domain Security (NDS)
7.10.4	UTRAN Network Access Security
7.10.5	GERAN Network Access Security
7.10.6	Generic Authentication Architecture (GAA)
7.10.7	Multimedia Broadcast/Multicast Service (MBMS)
7.10.8	Security Aspects of Home(e)NodeB (H(e)NB)
7.10.9	Security Aspects related to Machine-Type Communication ((e)MTC)
7.10.10	Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)
7.10.11	Security of MCPTT (MCPTT)
7.10.12	Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)
7.10.13	Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)
7.10.14	New GPRS algorithms for EASE (EASE_ALGOs_SA3)
7.10.15	Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP)
7.10.16	Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
7.10.17	Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec)
7.10.18	Security of the Mission Critical Service (MCSec)	S3‑181172	[MCSEC] 33180 R14 EN clause 5.1.3.1	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	withdrawn	Yes
		S3‑181423	[MCSEC] Removal of Editor’s note in Clause 5.1.3.1.	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181421	[MCSEC] Addition of test vector for MIKEY-SAKKE UID	NCSC	CR	Agreement	Yes	Yes	agreed	No
		S3‑181173	[MCSec] 33180 R14 technical clarifications	Motorola Solutions Danmark A/S	CR	Agreement	Yes	Yes	agreed	No
7.10.19	Security Aspects of Narrowband IOT (CIoT)
7.10.20	Other work items	S3‑181400	Use of fields in CMPv2	Ericsson	CR	Agreement	Yes	Yes Nokia: this may be a problem for existing implementations. Huawei agreed with Nokia, not needed.	not pursued	No
		S3‑181401	TLS 1.3	Ericsson	CR	Agreement	Yes	Yes Deutsche Telekom supported adding TLS and agreed with having it in Rel-15. NCSC: it is saying already that the highest TLS version on both endpoints shall be used and this could lead to problems. Mandating TLS 1.3 is not ideal. Qualcomm was concerned about mandating it for Rel-15. Recommend it for Rel-15 and mandate it for Rel-16. It is too late for Rel-15. Comments were taken and it was agreed to bring it back during the next meeting, The Chair commented that there was a draft IETF mentioned there and the Chair would tell them.	not pursued	No
7.11	New Work Item proposals	S3‑181178	WID eMCSec R16 security	Motorola Solutions Danmark A/S	WID new	Agreement	Yes	Yes	revised	No	S3‑181504
		S3‑181504	WID eMCSec R16 security	Motorola Solutions Danmark A/S	WID new	Agreement	Yes	Yes Qualcomm: specify what security issues we are dealing with. MCC commented that this had to be a feature and the parent WIDs were related WIDs instead. After this and some other editorials were fixed, the document was agreed.	agreed	No		S3‑181178
8	Studies
8.1	Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-15)
8.2	Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)	S3‑181336	Delete Editor’s note in subclause 6.2.2.1	Huawei, Hisilicon	CR		Yes	Yes	agreed	No
		S3‑181338	add definitions and abbreviations for TR33.843	Huawei, Hisilicon	CR		Yes	Yes	revised	No	S3‑181543
		S3‑181543	add definitions and abbreviations for TR33.843	Huawei, Hisilicon	CR	-	Yes	Yes	agreed	No		S3‑181338
8.3	Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)	S3‑181106	Reply LS on the status of work on interfaces	S5-181455	LS in		Yes	Yes ORANGE: the first point is not answering the question. The most relevant interfaces according to my colleague in SA5 are still in stage 1 phase.	noted	No
		S3‑181259	Discussion on SA5 LS	Huawei, Hisilicon	discussion	Endorsement	Yes	Yes ORANGE: their work will go beyond May, so SA3 cannot finnish before them. Huawei commented that this wasn't the information they had from their colleagues in SA5 and from what was said in the LS. The Chair asked Huawei if the architecture was defined. Huawei replied that their architecture is not based on SA2's work but on an information model. ORANGE commented that the specification only has a few requirements but no architecture is present in the document. Huawei commented that since there was no agreement between the SA5 delegates SA3 had to stick to what the LS said, and they mentioned finishing in June. The Chair commented that SA3 could always ask for an extension if SA5 was late. ORANGE: we should not tie this to the work in phase one of 5G. Huawei: the work in SA5 is not a Study Item. ORANGE: then we need to bring a WID to complete the work. ORANGE: it is premature to discuss the rest of the proposals. Huawei commented that they could bring a WID proposal for the next meeting in order to do normative work. Huawei: if they finish the work in June (Rel-15), what happens with the security for that? The Chair replied that it was normal to finish a cycle later and that should be pointed out in SA plenary. It was asked to be minuted: SA3 activity is dependant on SA5 progress on this topic. A WID was needed to do the normative work. It was also pointed out that the network slicing work would not be complete without the security work performed by SA3. Huawei was worried that SA3 were to be blamed on the delay of the network slicing work, but the Chair replied that this was a common issue and it was hard to avoid given the short time scales given to SA3 to perform their work,	noted	No
		S3‑181251	Authentication and authorization for slice management interface	Huawei, Hisilicon	pCR	Approval	Yes	Yes ORANGE: There are assumptions that are beyond SA5's work. These should be removed (6.y.2.2.4). It is hard to do these assumptions without an architecture. ORANGE: there are a lots of "shalls" and this is a study.	revised	No	S3‑181556
		S3‑181556	Authentication and authorization for slice management interface	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181251
		S3‑181220	new KI of UP security parameters management	Huawei; HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑181221	solution of UP security policy management	Huawei; HiSilicon	pCR	Approval	Yes	Yes	noted	No
		S3‑181262	NSST integrity protection solution	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑181263	NSST confidentiality protection solution	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑181254	Security options	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑181433
		S3‑181433	Security options	Huawei, Hisilicon	pCR	Approval	Yes	Yes ORANGE: which functionality of SA5 specification is this related to? SA5 doesn't define the characteristics of a specific slice.We protect the interface and the template (we don’t care about the content of the template).	noted	No		S3‑181254
		S3‑181253	Update to overview clause	Huawei, Hisilicon	pCR	Approval	Yes	Yes ORANGE insisted that this based on work on 23.501 (out of scope) and on an architecture that is not defined. Huawei: the figure is a general overview that provides useful information. There was disagreement between ORANGE and Huawei and this had to be taken offline. Finally noted.	noted	No
		S3‑181252	OAuth based authorization for access to management functions	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No
		S3‑181557	Draft TR 33.811	Huawei	draft TR	Approval	No	Yes	left for email approval	No
8.4	Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)	S3‑181130	33.834 - References	InterDigital, Inc.	pCR	Approval	Yes	Yes	merged	No	S3‑181525
		S3‑181416	pCR to 33.843 - collection of editorial fixes	Vodafone Group Plc	pCR	Approval	Yes	Yes	revised	No	S3‑181523
		S3‑181523	pCR to 33.843 - collection of editorial fixes	Vodafone Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑181416
		S3‑181131	Solution #6 Editor’s Note resolution	InterDigital, Inc.	pCR	Approval	Yes	Yes	revised	No	S3‑181525
		S3‑181525	Solution #6 Editor’s Note resolution	InterDigital, Inc.	pCR	Approval	Yes	Yes It fixes the references.	approved	No		S3‑181131
		S3‑181246	LTKUP: clarifications for solution #5	Gemalto N.V.	pCR	Approval	Yes	Yes	revised	No	S3‑181526
		S3‑181526	LTKUP: clarifications for solution #5	Gemalto N.V.	pCR	Approval	Yes	Yes Rewording as proposed by ORANGE and Vodafone.	approved	No		S3‑181246
		S3‑181264	pCR to TR 33.834 – clarifications to key issue 1	Vodafone Group Plc	pCR	Approval	Yes	Yes Gemalto: the requirements are not written as such, this is a threat analysis. ORANGE: low/high risk are very difficult to evaluate in a solution. It was agreed to revise removing the changes in the requirements clause.	revised	No	S3‑181527
		S3‑181527	pCR to TR 33.834 – clarifications to key issue 1	Vodafone Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑181264
		S3‑181265	pCR to TR 33.834 – clarifications to key issue 2	Vodafone Group Plc	pCR	Approval	Yes	Yes	revised	No	S3‑181528
		S3‑181528	pCR to TR 33.834 – clarifications to key issue 2	Vodafone Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑181265
		S3‑181273	pCR to TR 33.834 – new key issue, undetected key leakage	Vodafone Group Plc	pCR	Approval	Yes	Yes G&D: Note and bullet with "it is unlikely.." should go out as they are not true. ORANGE agreed. ORANGE: it is late to add key issues and requirements at this stage. It doesn’t give time to people to bring solutions and evaluate them. Gemalto supported this. Vodafone: broadly speaking this doesn’t change the evaluation. This is in the document already. I'm happy to remove 8.Y as well. Alf (Vice Chair) asked who was in favour of this document, but there was very little support for this. The Vice Chair clarified that Key issues that break security should be taken care of, even if they come at a late stage.	noted	No
		S3‑181275	pCR to TR 33.834 – updated evaluation of solution #3	Vodafone Group Plc	pCR	Approval	Yes	Yes	revised	No	S3‑181530
		S3‑181530	pCR to TR 33.834 – updated evaluation of solution #3	Vodafone Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑181275
		S3‑181378	pCR to TR 33.834 – updated evaluation of solution #1	Vodafone Group Plc	pCR	Approval	Yes	Yes ORANGE opted to remove the new text in the conclusion. Vodafone found this as a showstopper for the study. They found it essential to have this evaluation and not inlcuding this would make them object to the approval of the TR. The Vice Chair adviced both companies to have offline discussions and solve their differences before next meeting. KPN supported Vodafone. SA3 would not evaluate properly the solution when removing this sentence. G&D: the user interaction part is already mentioned in the TR, so there is no point with duplicating it. Qualcomm supported Vodafone.	noted	No
		S3‑181388	pCR to TR 33.834 – updated evaluation of solution #2	Vodafone Group Plc	pCR	Approval	Yes	Yes G&D: a paragraph from the key issue is copy-pasted in the solution. Vodafone: because it is essential. It was agreed to make a summary instead of copying it.	revised	No	S3‑181531
		S3‑181531	pCR to TR 33.834 – updated evaluation of solution #2	Vodafone Group Plc	pCR	Approval	No	Yes	approved	No		S3‑181388
		S3‑181404	pCR to TR 33.834 – updates to solution #4	Vodafone Group Plc	pCR	Approval	Yes	Yes ORANGE: Mention that there may be Low impact on the HSS. Not protected against Man in the Middle in some use cases. Gemalto:"preferred" among the 4 solutions, clarify this in the conclusion.	revised	No	S3‑181532
		S3‑181532	pCR to TR 33.834 – updates to solution #4	Vodafone Group Plc	pCR	Approval	Yes	Yes	approved	No		S3‑181404
		S3‑181410	pCR to TR 33.834 – updates to solution #5	Vodafone Group Plc	pCR	Approval	Yes	Yes Gemalto didn’t agree with having a conclusion like this.	noted	No
		S3‑181415	pCR to TR 33.834 – updates to solution #6	Vodafone Group Plc	pCR	Approval	Yes	Yes ORANGE: Let's add that the solution doesn't provide enough information to provide a conclusion. MCC: instead of editor's notes, refer to "not addressed in this document".	revised	No	S3‑181534
		S3‑181534	pCR to TR 33.834 – updates to solution #6	Vodafone Group Plc	pCR	Approval	No	Yes	approved	No		S3‑181415
		S3‑181247	LTKUP: conclusion	Gemalto N.V.	pCR	Approval	Yes	Yes	noted	No
		S3‑181417	pcr TO 33.834 - Addition of Conclusion (comment to S3-181247)	Vodafone Group Plc	pCR	Approval	Yes	Yes It was agreed that the outcome of this study was not to recommend any future normative work based on its outcome.This was captured in the revision.	revised	No	S3‑181535
		S3‑181535	pcr to 33.834 - Addition of Conclusion (comment to S3-181247)	ORANGE	pCR	Approval	Yes	Yes	approved	No		S3‑181417
		S3‑181524	Draft TR 33.834	Vodafone	draft TR	Approval	No	Yes	approved	No
		S3‑181533	Conclusion of solution #5	Gemalto	pCR	Approval	Yes	Yes	approved	No
		S3‑181536	Cover sheet 33.834	Vodafone	TS or TR cover	Approval	No	Yes	withdrawn	Yes
8.5	Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)	S3‑181245	Impacted NextGen Areas	NCSC	pCR	Approval	Yes	Yes KPN: We need an introduction clause which explains the assumption of an attacker with a quantum computer. MCC pointed out that there was quite a bit of normative text that needed to be reworded.	revised	No	S3‑181558
		S3‑181558	Impacted NextGen Areas	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑181245
		S3‑181284	Non-random IVs in CTR mode	NCSC	pCR	Approval	Yes	Yes	revised	No	S3‑181459
		S3‑181459	Non-random IVs in CTR mode	NCSC	pCR	Approval	Yes	Yes	approved	No		S3‑181284
		S3‑181126	Section 8, Size of the integrity protection tag MAC-I	Vodafone, AT&T, MITRE, NIST, InterDigital, TCG	pCR	Approval	Yes	Yes NCSC and Ericsson wanted to clarify that 8.z was not the conclusion of the specification. Vodafone: remove reference to ETSI SAGE.	revised	No	S3‑181560
		S3‑181560	Section 8, Size of the integrity protection tag MAC-I	Vodafone, AT&T, MITRE, NIST, InterDigital, TCG	pCR	Approval	No	Yes	approved	No		S3‑181126
		S3‑181168	Security of MAC algorithms and tags	InterDigital, Inc.	pCR	Approval	Yes	Yes NCSC didn’t understand this. It looked like general comments but it didn’t fit anywhere.	noted	No
		S3‑181127	Co-existence of different size keys and MAC-I tags	AT&T, Vodafone, NIST, MITRE, InterDigital, TCG	pCR	Approval	Yes	Yes KPN: How do you secure against bidding down when having 128 and 256 bits? Vodafone: this requires further investigation.	revised	No	S3‑181561
		S3‑181561	Co-existence of different size keys and MAC-I tags	AT&T, Vodafone, NIST, MITRE, InterDigital, TCG	pCR	Approval	Yes	Yes	approved	No		S3‑181127
		S3‑181196	Reduce complex of Key Derivation Function negotiation	Huawei, Hisilicon	pCR	Approval	Yes	Yes Ericsson: it is a bit strange to propose something else like this,instead of bringing it directly.	revised	No	S3‑181563
		S3‑181563	Reduce complex of Key Derivation Function negotiation	Huawei, Hisilicon	pCR	Approval	No	Yes	approved	No		S3‑181196
		S3‑181283	Requirement for AKA algorithm negotiation between UE and UDM	Huawei, Hisilicon	pCR	Approval	Yes	Yes Qualcomm: we already support 256 bits, no need for this document. ORANGE: we don’t define the algorithms in 3GPP. The operators can support hundreds of algorithms if they want.	noted	No
		S3‑181277	pCR to TR 33.841- Clarification on two algorithms for resilience	Vodafone Group Plc, AT&T, Interdigital, NIST, MITRE	pCR	Approval	Yes	Yes ORANGE: we standardise the outputs and inputs of algorithms but not the algorithms themselves. Tuak and MILENAGE are not standardised. Vodafone: these two algorithms are standardised. It was decided to note it and come back to the next meeting with something else.	noted	No
		S3‑181278	pCR to TR 33.841- Individual algorithms	Vodafone Group Plc	pCR	Approval	Yes	Yes CATT: the ZUC information is not up to date. Gemalto: 13.1.1 (seems perfectly acceptable as the basis for 3GPP algorithms". It seems that it's too early to say this.	revised	No	S3‑181564
		S3‑181564	pCR to TR 33.841- Individual algorithms	Vodafone Group Plc	pCR	Approval	No	Yes Vodafone commented that links to ZUC, SNOW 3G, Tuak, MILENAGE and AES would be added during the next meeting.	approved	No		S3‑181278
		S3‑181169	Assessment of the MAC tag size	NIST	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑181279	Requirements and impact of a longer MAC	NCSC	pCR	Approval	No	Yes	withdrawn	Yes
		S3‑181559	Draft TR 33.841	Vodafone	draft TR	Approval	No	Yes	approved	No
8.6	Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)	S3‑181199	skeleton of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes MCC commented that the title, template and logo were wrong.	revised	No	S3‑181551
		S3‑181551	skeleton of TR33.856	Huawei, Hisilicon,China Unicom	pCR	Approval	Yes	Yes	approved	No		S3‑181199
		S3‑181314	Skeleton of FS_5G_UTRAN_SEC	China Unicom	pCR	Approval	Yes	Yes	merged	No	S3‑181551
		S3‑181200	a proposal for the scope of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑181552
		S3‑181552	a proposal for the scope of TR33.856	Huawei, Hisilicon,China Unicom	pCR	Approval	Yes	Yes ORANGE wanted to have more clarification on the roaming scenario. The international roaming scenario didn’t seem to be clear and proposed that China Unicom to bring a contribution for the next meeting. DT: There shouldn't be any impact in the HPLMN, I support ORANGE.	approved	No		S3‑181200
		S3‑181315	Scope of FS_5G_UTRAN_SEC	China Unicom	pCR	Approval	Yes	Yes	merged	No	S3‑181552
		S3‑181201	a proposal for the introduction of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑181553
		S3‑181553	a proposal for the introduction of TR33.856	Huawei, Hisilicon,China Unicom	pCR	Approval	Yes	Yes ORANGE don’t list impact on the user experience. This is a security study. BT: I object to the inclusion of scenarion 2 and 3. This violate the agreement in SA. The use case involves an operator using VoLTE roaming from 5G to UTRAN. ORANGE: don’t use "shall" for the support of service continuity from 5G to UTRAN. It was agreed to bring back the sentence for the next meeting.	approved	No		S3‑181201
		S3‑181316	Introduction of FS_5G_UTRAN_SEC	China Unicom	pCR	Approval	Yes	Yes	merged	No	S3‑181553
		S3‑181202	a proposal for the key issue of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes Key issues had to be aligned with SA2 work. An editor's note was added to that effect.	revised	No	S3‑181584
		S3‑181584	a proposal for the key issue of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes It was noted that 3G referred to UTRAN CS. MCC commented that they should be potential security requirements.	approved	No		S3‑181202
		S3‑181203	a proposal for the key derivation without direct interface between AMF and MSC server of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes ORANGE pointed out that the user experience would be highly impacted here.	revised	No	S3‑181585
		S3‑181585	a proposal for the key derivation without direct interface between AMF and MSC server of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181203
		S3‑181204	a proposal for the key derivation with interface between AMF and MSC server of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	revised	No	S3‑181586
		S3‑181586	a proposal for the key derivation with interface between AMF and MSC server of TR33.856	Huawei, Hisilicon	pCR	Approval	Yes	Yes	approved	No		S3‑181204
		S3‑181317	Key issue of IMS Emergency Session Handling	China Unicom	pCR	Approval	Yes	Yes	revised	No	S3‑181587
		S3‑181587	Key issue of IMS Emergency Session Handling	China Unicom	pCR	Approval	Yes	Yes	approved	No		S3‑181317
		S3‑181583	Draft TR 33.856	China Unicom	draft TR	Approval	No	Yes	approved	No
8.7	Other study areas	S3‑181241	Discussion on Prevention of Fraud Call	China Mobile Group Device Co.	discussion		Yes	Yes BT agreed with the problem.However what needs to be done is at ITU level and not 3GPP.	noted	No
8.8	New study item proposals	S3‑181239	Discussion of 5G phase-2 work	KPN N.V.	discussion	Agreement	Yes	Yes Vodafone: we need normative SBA work completed by the end of Rel-16. ORANGE supported this contribution.	noted	No
		S3‑181185	New SID on security aspects on support of PARLOS	SPRINT Corporation	SID new	Agreement	Yes	Yes Colin (BT) suggested to mention the Credit Card Industry for the credit card numbers issue.	revised	No	S3‑181441
		S3‑181441	New SID on security aspects on support of PARLOS	SPRINT Corporation	SID new	Agreement	Yes	Yes	agreed	No		S3‑181185
		S3‑181216	SID on security of 5WWC	Huawei; HiSilicon	SID new	Agreement	Yes	Yes Colin (BT): privacy for individual users in the residential use case should be included. This was taken offline. Alf( Docomo): timeline is too optimistic. The Chair commented that the timeline could always be adjusted.	revised	No	S3‑181442
		S3‑181442	SID on security of 5WWC	Huawei; HiSilicon	SID new	Agreement	Yes	Yes	agreed	No		S3‑181216
		S3‑181231	Discussion for the security assurance of 3GPP virtualized network functions	China Mobile Group Device Co.	discussion		Yes	Yes Vodafone commented that the number of SIDs was already too large and some careful consideration was needed in order to reduce the number of meetings. ORANGE referred to the plenary recommendation on reducing the number of meetings per year per working group. Huawei supported having this SID. DT: this is not high priority. Not a bad idea, but not urgent to do in rel-16. ORANGE: the biggest problem is the scope, how much is done here and how much is done in ETSI. Alex (BT): good idea but not with this scope. Limit it to the capabilities we need from the platform and ask ETSI NFV to fix it.Just use case scenarios and API capabilities. ZTE supported this work. Docomo was in favour of having this. There is an understanding of NFV at this stage and SCAS for this makes sense. I also understand Tim's concern. We need more meetings to reduce the current workload. BT: it needs to be done and it will be very complex. Ericsson was in favour of any SCAS work. If we get the SCAS for non virtualised network functions, we will look after to the virtualised network functions.This study seems to be out of scope, though. Nokia: we are not sure how this would fit into the whole SCAS. It needs to be done later. China Unicom considered this as a high priority work for network operators. Alex (BT) preferred to check this in future meetings, not now. Huawei: there is no intention in NFV to do any SCAS work. It is clearly under our scope.	noted	No
		S3‑181232	New SID on SCAS for 3GPP virtualized network functions	China Mobile Group Device Co.	SID new		Yes	Yes The Chair recommended some offline discussions to delimit the scope and bring it back in the August meeting.	noted	No
		S3‑181234	Discussion on authentication and key management for applications based on 3GPP credential in 5G IoT	China Mobile Group Device Co.	discussion		Yes	Yes	noted	No
		S3‑181235	Study on authentication and key management for applications based on 3GPP credential in 5G IoT	China Mobile Group Device Co.	SID new		Yes	Yes Vodafone: fine with this, but worried about the wording in the objectives suggesting another specification when these are minor changes in GBA and BEST. Qualcomm: align with 5G IoT work in SA2.	revised	No	S3‑181562
		S3‑181562	Study on authentication and key management for applications based on 3GPP credential in 5G IoT	China Mobile Group Device Co.	SID new	-	Yes	Yes	agreed	No		S3‑181235
		S3‑181255	New SID on security of URLLC in 5G system	Huawei, Hisilicon	SID new	Approval	Yes	Yes Qualcomm: in SA2 the scope is restricted in the connected mode of the UE. I don’t see that having an impact on SA3. Let’s wait for SA2 to see if there is any security impact. My RAN colleagues have told me that they haven't even started the work. It is too early to bring this. Deutsche Telekom: same as Qualcomm. Let's wait and see. BT agreed, it was too early. The Chair commented that the general understanding was that the SID was too early and it was necessary to wait for other groups to progress on their work.	noted	No
		S3‑181306	Study on evolution of Cellular IoT security for the 5G System	Ericsson	SID new	Agreement	Yes	Yes	revised	No	S3‑181444
		S3‑181444	Study on evolution of Cellular IoT security for the 5G System	Ericsson	SID new	Agreement	Yes	Yes ORANGE: I asked in SA2 about this.There are no key issues such as these in SA2. I don’t siupporving both groups working on the same things (last bullet in objectives). Vodafone didn't agree with the remove provisioning part. Ericsson: let's not anticipate what SA2 does, we work on their work anyway. DT supported ORANGE and Vodafone. ORANGE: let's make it very clear that we are based solely on SA2, not other groups. Vodafone: no rush, we can decide next meeting. KPN: DoS attacks in scope of this WID? Ericsson confirmed this. Sony considered that it was worth having SA1 as a referenced group in the objectives,since they are giving us requirements. ORANGE: I want to avoid that if SA2 concludes in their study that there will be no provisioning, we have to conclude the same. ORANGE pointed out that SA3 should stick to the SA2's agreements. Qualcomm: there may be security requirements that go against SA2's conclusions. Vodafone supported ORANGE: we don’t want to study provisioning when there are groups not studying it. Qualcomm agreed with this. ORANGE wanted to mention specifically SA2 and not 3GPP groups in general working on provisioning. It was asked to be minuted as agreement: If provisioning is not treated in SA2, SA3 will not be consider it in this study. .	agreed	No		S3‑181306
9	Work Plan and Rapporteur Input
9.1	Review of work plan	S3‑181102	SA3 Work Plan	MCC	Work Plan		Yes	Yes	noted	No
9.2	Rapporteur input on status of WID or SID	S3‑181105	Work Plan input from Rapporteurs	MCC	other		Yes	Yes	noted	No
10	Future Meeting Dates and Venues	S3‑181104	SA3 meeting calendar	MCC	other		Yes	Yes	revised	No	S3‑181588
		S3‑181588	SA3 meeting calendar	MCC	other	-	Yes	Yes	noted	No		S3‑181104
11	Any Other Business
12	Close